Interactive testing - is it worth it?

Hello habrazhiteli.
It has long been an idea to share the idea of ​​interactive testing as one of the possible forms of organizing the process, but free time appeared only now, and I would like to use it. Although it would be too loud to call this “organization of the process”, rather, it’s just one of the successfully implemented teamwork approaches between the programmer and the tester. Below, I will share not so much some truths as my own (as it seems to me - positive) experience.

If anyone is interested - I ask under the cat.

In my (now) past work, or rather, in my team, an interactive review of the code is in very high demand - this is when the reviewer sits down to the author and performer of what has been written, and the review is live - the author shows and explains the meaning of the changes, and the reviewer looks and does remarks (if they appear). This is mainly due to the fact that the version control system (by the way, its own) does not provide for “postponing” the changes and sending them on the review before the actual commit to the repository. Therefore, we twist it out in ways, who are ready for what (who sends emails, if a colleague is abroad, but often (good, most developers are geographically in place) this is done). It may seem inconvenient from some side, but on the other hand it often reduces time and reduces risks, since problems identified during the review process will be resolved before the code enters the repository and pah-pah will break the assembly or functionality.
And so we thought with one developer in due time - but wouldn’t we apply a similar approach to testing? The idea is just as simple: the tester sits behind the programmer's machine and “on the fresh tracks” produces one or another level of testing. Further, if everything is good, the code is committed to the repository, and testers are waiting for the official build (naturally, the review of the code has already been done before).
We had repeated debates with the guys on this topic, and, to tell the truth, the majority is against this approach. Below I will try to bring all the pros and cons that took shape in the process of discussions and practice.
')
So, the pros:

• The time is reduced between the actual changes in the code and the testers getting the build, which they can, in fact, feel. Here, of course, assembly time plays a key role, as well as the proximity of the deadline. Our assembly takes an average of 2-2.5 hours. Add to this another half hour to an hour for the installation. Total - 2.5-3.5 hours. In normal times, this may not be critical, but when there is a release outside the window (or the banal end of the sprint (who works on scrum, he knows)), even an hour can play a role. And imagine that the build for some reason (not related to these changes) fell off - you have to wait even more.

• As experience shows (my personal), the most critical problems are found in the first 15-20 minutes (depending, again, on the complexity of the task and other things, but take the average variant). Given the first point, imagine how much time is saved if this testing is done before committing to the repository. Many times it happened that, sitting down at the developer’s car, I found in about 15 minutes about 2-3 critical and about 5 more non-critical, but nonetheless unpleasant problems.

• "Fresh" eye is always in store. If this is a new feature or a change in the UI, the view from the side (and even more so the tester) will only benefit. Even if everything was discussed and discussed earlier (design of docks, mocaps, etc.), there can always be a place for the opinion that in reality it does not look as good for the user as it could. It will be a plus if there is an opportunity to immediately give your doubts to the product owner (in my practice it was not difficult, because it was within the physical reach). As a result, changing the text of the message or the type of window takes a little time, and it is easier to change it right there, bypassing the lengthy process of assembling, file of the ticket (or the establishment of a new one) and the like.

But there are, of course, disadvantages:

• This practice is suitable only for new features or for fixes that affect a fairly large part of the existing functionality. In the case of small or too obvious fixes, there is practically no profit.

• This takes the tester's personal time, since it is done exclusively on a voluntary basis and (which is no secret), bypassing the bug-ticket life cycle process. Considering the moment that if you found problems in the first run, you will have to retest them again a second time (after fixing), plus re-test the functionality nearby (if suspicious), plus do the same on the official build that you will receive tomorrow.

• Not every developer will let a stranger (albeit a tester from his team) for his car. I don’t know what it is connected with, but there are all sorts of people - someone feels uncomfortable, even if people periodically go behind the back, and the other calmly gives you their domain password. This is natural, and you should put up with it.

• Basically, such practices, it seems to me, can only be applied by people who do not just work in their work, do not just worry about the fruits of their work, but are more or less fanatical in their work :)

Personally, I happened to use this practice with two developers (with one of them - for several years, with the other - once or twice). And always (I think) it brought only positive results. But considering that there are more of these opponents among colleagues than supporters, I can feel in my gut that there’s a trick somewhere, not obvious, I see. Therefore, it would be very interesting to hear your opinions.