Is it a bad practice to iteratively try to deliver raw work to testers?

Question

Work organization

The essence of the problem is as follows. Imagine the work of a team that implements a certain feature.
The team leader (even if he is an analyst and also a product owner) described the requirements for developers - for the server and UI.
There is a user story in the requirements, but this is an applied development and it is quite difficult for programmers to understand.
The requirements also contain an approximate description of how to implement all this - UI elements and a general description of the principles of the API.
The backend programmer does his part of the work and roughly checks. It is difficult to check it in detail without UI.
The UI programmer does his part of the work, generally checks that his UI is alive with the API, but he does not delve into whether the server sends the correct data to him. And then both close the requirements.

After that, the tester takes up testing and first finds that there is no logic in the behavior of the product at all. He begins to walk between the programmers, together they begin to try to fix everything. As a result, it turns out that, firstly, there were a lot of bugs, and secondly, the programmers misunderstood the requirement, they didn’t read everything, and even every little thing was not taken into account in the requirements. Programmers correct what the tester does not like and the cycle repeats again and again until the whole team understands the task in the same way and the result becomes similar to what is expected in the requirements. After that, the task gets to be checked by the team leader, who already analyzes how well what turned out meets the expectations.

Those. here we use a tester at a stage when, in fact, nothing is ready at all. Raw versions are iteratively passed to him, and he first fights bugs, essentially coordinating programmers, and then fights misunderstandings of requirements, doing some of the work of an analyst.

Question: how widespread is the practice of such iterations of submitting a raw result for testing and how normal is it?
The second question is what is the best alternative?

Answer 1

This is a normal practice when a tester iteratively looks at raw options. In certain situations, this is better than making a ready-made version, debugging all the bugs by the programmers and understanding that something completely different was needed.
In order to avoid such situations, it is not bad to devote programmers at least in general terms to business logic, and to perform testing and debugging together, i.e. back-programmer, front-programmer and tester look at the operation of the system as a whole.
Another good practice in such a situation would be to involve an analyst and an architect who can see potential problems even at the stage of setting tasks for programmers.
And most importantly - everything depends very much on the level of developers in the team. Unfortunately, often in the same background they don’t see beyond their nose, hence the problems in the spirit of “buy milk, if there are eggs, take a dozen” ...

Answer 2

As a result, it turns out that, firstly, there were a lot of bugs, and secondly, the programmers misunderstood the requirement, they didn’t read everything, and even every little thing was not taken into account in the requirements. Programmers correct what the tester does not like and the cycle repeats again and again until the whole team understands the task in the same way and the result becomes similar to what is expected in the requirements.

After that, the task gets to be checked by the team leader, who already analyzes how well what turned out meets the expectations.

Um, if everything is so bad that you have to repeat the cycle over and over again, then where was the team leader who gave the original task all this time?
He should be involved in the first place, so that he either re-explains everything to the developers, or corrects his requirements so that they are clearer.
In my understanding, a team leader is one of the developers who controls their work on a daily basis, and does not wait until the finished product is brought to him in a month.
And yes, the tester helps developers understand the requirements correctly, but he should not beat his head against the wall alone. If something is not clear to the developers, they can raise their ass and go to the team lead, analysts, testers to understand the task correctly.

Answer 3

the tester's time is usually much cheaper than the developer's time, so spamming the raw code to him is quite acceptable, but all the logic and technical specifications must already be worked out by the analyst before development begins, and if the tester works for the analyst, then there are problems with the analyst in the project

Answer 4

No, it’s not normal, it’s normal when a technical specification is formalized, tests are written for it, and code is written for them. Only after that the code goes to the tester.