Interactive testing - is the game worth the candle

    Hi, harangers.
    For a long time I had the idea to share the idea of ​​interactive testing as one of the possible forms of organizing the process, but free time appeared only now, which I would like to use. Although to call this “organization of the process” would be too loud, rather it is simply one of the successfully implemented approaches to working in a team between a programmer and a tester. Below I will share not so much some truths as my (as it seems to me - positive) experience.

    If anyone is interested - I ask for a cat.

    In my (now) past work, or rather, in my team, an interactive code review is in very high demand - this is when the reviewer sits down to the author and performer of the written, and the review happens live - the author shows and explains the meaning of the changes, and the reviewer looks and makes comments (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” changes and sending them for review until the actual commit to the repository. Therefore, we get out of the ways, who is doing what (who sends the emails if the colleague is foreign, but often (fortunately, the majority of developers are located locally) this is done). It may seem uncomfortable for some reason, but on the other, it often reduces time and reduces risks, because problems identified during the review process will be resolved before the code gets into the repository andpah-pah will break the assembly or functionality.
    And then we thought with one developer at the time - but should we apply a similar approach to testing? The idea is just as simple: the tester sits down at the programmer’s machine and “in the fresh tracks” performs one or another level of testing. Further, if everything is okay, the code is committed to the repository, and testers are waiting for the official build (the code review, of course, has already been done before).
    The guys and I had repeated debates on this subject, and, in truth, the majority are opposed to this approach. Below I will try to cite all the pros and cons that took shape in the process of discussion and practice.

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

    • As experience (my personal) shows, the most critical problems are detected in the first 15-20 minutes (it depends, again, on the complexity of the task and other things, but let's take the average option). Considering the first point, imagine how much time is saved if this testing is done before committing to the repository. It happened repeatedly that, sitting down at the developer's machine, in 15 minutes I found about 2-3 critical and about 5 non-critical, but nonetheless unpleasant problems.

    • A "fresh" eye is always for the future. If this is a new feature or a change in the UI, a look from the side (and even more so of the tester) will only benefit. Even if everything has been discussed and discussed earlier (design of docks, mocapas, etc.), there can always be a place for the opinion that in reality it looks and is not as good for the user as it could be. It will be a plus if you can immediately give your doubts to the product owner (in my practice, it was not difficult, because he was within physical reach). As a result, changing the message text or window type takes a little time, and it’s easier to change it right away, bypassing the painful and lengthy process of assembly, the ticket file (or creating a new one) and the like.


    But there are, of course, disadvantages:
    • This practice is only suitable 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 away the personal time of the tester, since it is done exclusively on a voluntary basis and (to be honest) bypassing the process of the life cycle of a ticket ticket. Considering the moment that if you find problems in the first run, you will have to drag them again a second time (after the fix), plus drag the functional next to it (if you suspect), plus do the same on the official assembly 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 this is connected with, but there are all kinds of people - someone feels uncomfortable, even if people periodically pass behind the back, and the other calmly gives you his domain password. This is natural, and you should come to terms with it.

    • Basically, such practices, it seems to me, can only be applied by people who do not just work their work, not just worry about the fruits of their activities, but are, to one degree or another, fanatics of their work :)


    Personally, I happened to apply a similar practice with two developers (with one of them - for several years, with the other - once or twice). And always (as it seems to me) this brought only positive results. But taking into account the fact that there are more opponents of this among colleagues than supporters, I can feel with my gut that somewhere there is a catch, not obvious, I see. Therefore, it would be very interesting to hear your opinions.

    Also popular now: