Testers and programmers. Teams dependent on one another pursuing a common goal – the perfect product. At the same time, specialists whose nature of work could hardly be more different. Everyone looks at the product from a different perspective and thus contributes to its perfect functioning. Smooth and close cooperation between programmers and testers is therefore essential.
But is it always smooth? Sometimes, there is a certain rivalry, perhaps a misunderstanding, between these two groups of specialists. We decided to look at some of the differences in the nature of the work of these two groups and try to help smooth out some of the situations that are encountered on normal working days.
Standa, who knows both groups very well, deals with the topic. He combines work on projects where he is a tester with a focus on automation (Java) with his own project where he works as a C++ developer.
How do programmers work?
Programmers are tasked with writing application or program code as specified by the architect. Programmers usually work “in flow”. Flow is a condition of deep, almost meditative engagement. In this state, there is a subtle feeling of euphoria and one usually does not realize the passage of time: “I started working. I looked up and realized three hours passed.”
It’s not possible to switch to this state arbitrarily, it takes at least 15 minutes of immersion and concentration before one can get into it. But it’s very easy to disrupt this flow. If someone is interrupting you every few minutes, the result is lower productivity and increasing irritation.
Dear testers, please keep this flow in mind when communicating with programmers and don’t always ask for answers right away. Whenever possible, try to choose a less intrusive way to communicate. E-mail is better than chat, chat is better than a phone call or sudden appearance. If possible, it is recommended to schedule personal communication or the time when the programmer will be available to you for acute troubleshooting.
How do testers work?
The job of testers is to look for bugs and defects in programmers’ code and point them out. A tester’s job usually involves frequent shifts in attention: during a day, a tester can sometimes perform dozens of unrelated tasks. The tester’s role on the project begins when they get a list of requirements for how the application or program should work. Based on this, the tester prepares test scenarios and waits for the developers to deliver the product in a ready-to-test version.
However, the tester cannot test only what is in the description. They have to look at all the functionalities in a broader perspective: Didn’t the new one break some of the old ones? Didn’t something stop working?
Dear developers, please don’t make rejections just because the bug is not in the description and therefore irrelevant or that the thing in question is not a bug but a feature. Rather, think of it as the tester helping you finish your work on a given task thanks to the discovered bug, so you won’t have to come back to it later when you no longer remember what you were actually programming.
There is no need to take constructively reported bugs personally
Finding mistakes in other people’s work is not an easy task, nor is constantly receiving notices of shortcomings or criticism. It’s also a very shaky foundation for good relations between these two groups of specialists. Let’s face it – no one likes criticism. Some people are more sensitive to it, some people cope with it better, but it’s simply not pleasant for anyone.
Sometimes, unnecessary and even harmful antagonism can arise between testers and programmers, destroying team spirit, spoiling relationships and creating conflict. Ideally, all project members must keep in mind that they have a common goal. They are not enemies or opponents, but colleagues who, ultimately, strive for the same thing. How to stay on that course?
Let’s face it, mistakes will exist, programmers and testers will make them, and very often both sides will be somewhat right in their disputes.
When you, testers, report bugs again in the future, remember the most important principle: The reported bug must be well described and justified. Show respect, perhaps a little more than in any other communication.
Explain why you think something is wrong. Ideally, provide a reference to the specifications or standards that the program must meet. If you just think “it would be better the other way around”, maybe your comment should be considered an improvement or a feature request.
And when you, developers, get bug reports from testers that need to be looked at, don’t take it personally. Try to rise above the initial natural reaction that you won’t do it and look at it from a broader perspective. Thanks to testing, you can move on, deliver a better result, create a better product.
In conclusion, we wish a lot of mutual understanding and fewer disagreements not only between teams of testers and programmers, and we also recommend dispassionate attitude and humour, which often solves everything.