7 tips on how not to infuriate a colleague tester on his holiday
Today is the day of testers all over the world. On this occasion, we decided to help you look at the work of these specialists from different perspectives, so that the cooperation brings maximum benefit and minimum stress to all participants.
Photo: David Goehring CC BY
1. "Recheck once more, there is definitely no bug"
Let's start with the fundamental problem. The Ars Technica forum has an old branch in which one developer talks about a deep hatred for "pedantic" testers. It annoys him terribly that some testers spend hours searching for the smallest bugs. And what is most unpleasant, they still find them.
What can go wrong : Not everyone is willing to admit their mistakes. Someone starts an old song about “not a bug, but a feature”, trying to prove that everything was as it was intended. Others persistently ask to double-check the code and make sure that there is no bug. The tester just tries to do his job well, and instead of thanking him, he is sent for rechecking.
How to be : It's simple: if the tester found a defect in your code and you understand that he is right, it is better to recognize this fact. You both have the same goal - to release a debugged and working product. Humor helps to come to an understanding in this matter. Here is an article in which testers collected the "golden fund" of statements by developers trying to protect their code. We advise you to run through them and present how these “classic” phrases sound from the point of view of the tester.
2. “Before the release of the week. I hope you haven't planned other things for the next two days. ”
Sometimes the code comes to testers a few days before the release. Then they have to work in the trawl. Some QA specialists believe that colleagues simply underestimate their work. Allegedly, they think that the search for bugs is easy and fast, so they postpone debugging to the last moment.
What can go wrong : In the conditions of emergency work, testers are not only annoyed, but also lose their vigilance. The lack of time is one of the main reasons why testers miss bugs.
How to be : There are several development models. From the point of view of QA, there are two main approaches: cascade and Agile. In the first case, testers receive code snippets in stages. In the second case, they test the code in parallel with writing it.
Agile helps to involve QA specialists in the project in the early stages. Due to this, it is not necessary to test “one hour before the release”. In addition, this approach allows us not to look for bugs, but to prevent their appearance. If your testers complain about constant time trouble and miss bugs, take a look at this methodology.
Photo: Tim Regan CC BY
3. “I quickly corrected the code. Take a look, please"
Suppose your team works on a cascade model and is able to competently plan the development phase. Testers receive the code, and there seems to be enough time for debugging. But developers have a habit of making a minimum of effort at this stage. They get a detailed bug report, read it superficially, quickly eliminate obvious errors and send code for the next test cycle.
What can go wrong : The problem is that the code after surface changes often returns with even more bugs. The tester spent time writing a detailed report, and in response to it received some kind of a formal reply. He has to go this way a few more times just because the developer does not want to waste time on "minor bugs."
How to be : Obviously, do not hurry. But this is not enough. You need to figure out why you are not paying due attention to the report. If this is a banal laziness, only you can help yourself. There are other reasons. For example, you think that QA-engineers are flooding you with reports of minor bugs. Then you need to clarify this question at the management level - should testers distract you "on trifles." Most likely, the answer will be positive. Some product managers even ask developers to specifically add minor bugs to the code so that testers are always on guard. It is important to take this approach and treat bug reports with due attention.
4. “It seems I already figured out with this bug. But I do not remember exactly "
Sometimes the surface approach is a system problem. In some teams, bug reports are lost in time and space. No one responds to the reports properly, does not mark whether the problem has been resolved or is still in limbo.
What can go wrong : The developers eliminate some kind of bug, make, as it seems to them, “minor” changes to the code, forget to notify the testers about it and send the code to the release. As a result, the problem emerges when it is too late. And the “extreme” is often the tester.
How to be : The problem of chaos needs to be solved systemically. Disorder harms the development, so you have to completely rebuild the communication process in a team. Here you should take advantage of basic tips for establishing communication between developers and QA-engineers: determine the terminology; it is clear to formulate the requirements; Introduce a hierarchy of priorities for various bugs. As for the confusion with bugs, there is good practical advice: a) let the bugs report everything; b) further it is important to prioritize them; c) any closed bug implies that a functional test will be written; d) the status “decided” is assigned not by the developer, but by the tester. This approach ensures that the problem is really solved.
Photo: Tim Regan CC BY
5. “Why should I test this? I'm not a tester! ”
In some teams, the responsibility for debugging rests entirely with testers. Developers don't bother spending time on the most obvious unit tests. They are sure that this is not their job. By and large, it is, although there are different points of view on the issue (community opinions can be found here ).
What can go wrong : Testers in this situation have to deal with all the shortcomings in a row - even with the most primitive and stupid mistakes. Of course, it is annoying.
How to be : Many developers advocate independent tests before being sent to the QA department. This helps not only to relieve testers, but also to learn how to look at the product from the point of view of the critic and the user. It is believed that this is useful for professionals and the best way affects the final result. For those who do not want to bother to check themselves, there are automatic tools. They help to find the most obvious bugs. In any case, even if the team has QA engineers, a hard division into developers and QA is not the most optimal approach.
6. “Igor, today you work in a pair with Oleg. You'll like it"
Product managers are not limited to the cascading approach and Agile. Some of them like to experiment. For example, arrange pair programming and testing sessions.
What can go wrong : This is an effective way to catch bugs, but it also has disadvantages - people may not be happy with innovations. A QA specialist who is accustomed to working alone, on another floor and on his equipment, may simply be uncomfortable leaving the familiar environment. In addition, it may be trite not to arrange the experience and knowledge of a partner. As a result, instead of successful tests, product managers receive two dissatisfied employees.
How to be : The main advice - do not chop off the shoulder. Agile- and DevOps practices may seem attractive, but without proper preparation will not work.
7. "I will take your device for tests, don't you mind?"
The developer has time to start debugging, he asks the tester a device for tests “literally for 20 minutes” and removes it for long hours.
What can go wrong : Most often, the developer does not return the device to its place at all, and if it returns, it is completely discharged. Considering that testers can have parallel tasks on this device, this can not but annoy.
How to be : Set yourself reminders, glue stickers, do anything, but please return testers' things to the place and on time.
Photo: Dave Allen CC BY
And the main advice to developers and product managers, which suggests itself from all the previous ones: respect the work and time of others, and as often as possible put yourself in the place of a tester. After all, if it were not for him, the whole world would know about your bugs.