7 tips, how not to exasperate a testing colleague in his holiday
Today the whole world celebrates the day of the tester. On this occasion, we decided to help you look at the work of these specialists from different points of view, so that cooperation would bring maximum benefit and minimum stress to all participants.
Photo: David Goehring CC BY
on the Ars Technica forum. old branch , in which one developer talks about a deep hatred of "pedantic" testers. He is terribly annoyed that some testing experts spend hours searching for the smallest bugs. And most unpleasant, they still find them.
What can go wrong : Not everyone is ready to admit their mistakes. Someone starts an old song about "not a bug, but a feature", trying to prove that everything was conceived. Others persistently ask to recheck the code and make sure that there is no bug. The tester simply tries to do his job well, but instead of giving it, he is sent for recheck.
How to be : It's simple: if the tester found a flaw in your code and you understand that he is right, it is better to recognize this fact. Both of you have the same goal - to release a well-functioning and working product. Humor helps to come to an understanding in this matter. Here is article , in which the testers collected a "gold fund" of statements by developers trying to protect their code. We advise you to go over them and imagine how these "classical" phrases sound from the point of view of the tester.
2. "Before the release of the week. I hope that for the next two days you did not plan other things "
Sometimes the code comes to the testers a few days before the release. Then they have to work in a job. Some QA-specialists consider that colleagues simply underestimate their work. Allegedly they think that the search for bugs is easy and fast, so they postpone debugging at the last minute.
What can go wrong : In an emergency, testers are not only annoyed, but also lose their vigilance. Shortage of time - one of the main reasons is , on which testers miss bugs.
How to be : There are several development models. From the point of view of QA distinguish two main approaches: cascading and Agile. In the first case, the testers receive code fragments in stages. In the second case, they test the code in parallel with its writing.
Agile helps to involve QA-specialists in the project in the early stages. Due to this, you do not have to test "one hour before the release". In addition, this approach allows you not to look for bugs, but to prevent their occurrence. If your testers complain about constant time pressure and skip bugs, take a closer look at this methodology.
Photo: Tim Regan CC BY
3. "I quickly corrected the code. Look, please, »
Let's say your team is working on a cascading model and is able to plan the development phases correctly. Testers get the code, and time for debugging seems to be enough. But the developers have a habit of making at this stage a minimum of effort. They receive a detailed bug report, read it superficially, quickly eliminate obvious errors and send the code to the next test cycle.
What can go wrong : The problem is that the code after surface changes is often returned with even more bugs. The tester spent time preparing a detailed report, and in response to him received some kind of an answer. He has to go this route a few more times just because the developer does not want to spend time on "minor bugs".
How to be : Obviously, do not rush. But this is not enough. You need to understand why you do not pay proper attention to the report. If this is trivial laziness, only you can help yourself. There are other reasons. For example, you think that QA-engineers fill you with reports about insignificant bugs. Then you need to clarify this issue at the management level - should the testers distract you "in detail". Most likely, the answer will be positive. Some product managers are even ask developers specifically add small bugs to the code so that testers are always on their guard. It is important to adopt this approach and treat the bug reports with due attention.
4. "It seems that I have already dealt with this bug. But I do not remember exactly "
Sometimes a superficial approach is a systemic problem. In some commands, bug reports are lost in time and space. No one reacts to reports properly, does not mark, whether the problem is solved or everything is still in limbo.
What can go wrong : Developers eliminate a bug, they make, as it seems, "minor" changes to the code, forget to notify the testers about this and send the code to the release. As a result, the problem pops up when it's too late. And the "extreme" is often a tester.
How to be : The problem of chaos should be solved systematically. Disorder harms the development, so you will have to completely rebuild the communication process in the team. Here you should take advantage of the basic tips for establishing communication between developers and QA-engineers: determine the terminology; it is understandable to formulate requirements; Enter a hierarchy of priorities for the various bugs. As for the confusion with bugs, there are good practical tips: 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 "resolved" is assigned not by the developer, but by the tester. This approach ensures that the problem will indeed be solved.
Photo: Tim Regan CC BY
5. "Why should I test this? I'm not a tester! "
In some teams, the responsibility for debugging lies entirely with the testers. Developers do not 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 question (the views of the community can be found here ).
What can go wrong : Testerovschikam in this situation have to deal with all the shortcomings in a row - even with the most primitive and stupid mistakes. Of course, this is annoying.
How to be : Many developers support self-tests before sending to QA-department. This helps not only to unload the testers, but also to learn to look at the product from the point of view of the critic and the user. There is an opinion that this is useful for professionals and better affects the final result. For those who do not want to trouble themselves with checks, 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 tandem with Oleg. You'll like it »
Product managers are not limited to a cascading approach and Agile. Some of them like to experiment. For example, arrange paired 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 thrilled with innovations. QA-specialist, who used to work alone, on the other floor and on his equipment, can simply be uncomfortable leaving the familiar environment. In addition, it can be trite not to meet the experience and knowledge of a partner. As a result, instead of effective tests, product managers receive two dissatisfied employees.
How to be : The main advice - do not cut from the shoulder. Agile- and DevOps-practices may seem attractive, but without proper preparation will not work.
7. "I'll take your device for tests, do not you mind?"
The developer has time to do debugging, he asks the testers for a test device "for literally 20 minutes" and is removed with it for long hours.
What can go wrong : Most often, the developer does not return the device at all, and if it does, it is completely discharged. Given that testers can have parallel tasks on this device, this can not but annoy.
How to be : Set yourself reminders, stick stickers, do anything, but please return the testers' stuff to the site and on time.
Photo: Dave Allen CC BY
And the main advice to developers and product managers, which begs from all the previous ones: respect someone else's work and time, and put yourself as often as possible on the test site. If it were not for him, the whole world would know about your bugs.
It may be interesting
Your post is very helpful to get some effective tips to reduce weight properly. You have shared various nice photos of the same. I would like to thank you for sharing these tips. Surely I will try this at home. Keep updating more simple tips like this. BBQ and Hog Roast buffet catering Bristol