Collaboration between a developer and a tester

Probably everyone who works in the field of IT has heard about the problem of interaction between developers and testers. There is a prejudice that developers dislike testers, and vice versa. Is it really so?

Of course, this is not a dogma, but a frequent problem of IT teams: the opposition between development and testing. There are many reasons for this, the main ones being:

• opposition of testing to their work by developers  – more often than not, developers «take care» of the product they created, they will painfully perceive defects in it relative to themselves;
• «testing for the sake of testing» – a big majority of testers  look at the specifics of the profession in a narrow way and consider their main goal to «break» the product;
• lack of understanding of the importance of testing – some developers do not believe that testing is a generally accepted, important, and appropriate profession, therefore they treat testers somewhat contemptuously;
• management problems – using an improper approach the mediation of project managers can, in addition to obvious positive results, give negative consequences in the form of confrontation.

In addition, the problem of interaction between developers and testers is often the presence of biases. This especially applies to experienced specialists. The essence of such situations is that a specialist (be it a tester or a developer) has a biased attitude towards the other side of cooperation through the prism of his views, experience, and perception. In science, this is called cognitive bias.

Among the most popular IT cognitive biases, we can highlight:

• framing is a frequently repeating similar scenario in the work that can dull the eye and prevent other aspects from being seen. Just as the tester may not see defects in the work according to the usual test scenario, the developer may not see problems in the code, rereading native lines for the hundredth time;
• retrospective bias is a situation in which facts and events are «fitted» to an already existing opinion or view. If the developer believes that the tester is simply trying to «crack» his code, then he will consider each bug or defect as nothing more than a kind of «assassination attempt» on the ideal product from his point of view;
• the effect of joining the majority is the superiority of the opinion of the majority over one's own. If almost the entire project team believes that the form should not have inline validation, and the tester understands that it is mandatory, then often the opinion of the majority overrides the opinion of one, even if this single opinion is more correct;
• negativity effect is revealed in a critical attitude to all moments of work. Whether the tester sees a bunch of bugs on every page of the site, or the developer thinks that everyone is trying to catch up to his work - one way or another, too negative a view has a bad effect on relationships;
• lost value - attempts to prove that the effort spent is worth the result. For example, if a tester spent a whole day testing a product and did not find a single bug, he will try to find at least some defect, so as not to feel that time was wasted.

With the understanding of the possible causes and nuances of confrontation, we will highlight tips to avoid, reduce, and predict conflict between developers and testers.

For testers:

• it is worth remembering that testers are looking for defects in the development product, not in the developer. The developer's work should be objectively and uncompromisingly evaluated without reference to personality or qualities;
• share your strategy with developers, don't keep key points of testing or bad spots in your head, thinking you'll flag it as a problem later - communicate with development;
• try to build a friendly relationship with the developers so everyone feels comfortable sharing thoughts or advice. Healthy working relationships are the key to successful cooperation;
• keep to the positive style of the problem report, it should not hurt anyone's feelings or show obvious dissatisfaction with the developer's work;
• avoid situations where you create a bug report just because you haven't fully understood the functionality. Study the specification and other available documentation, ask managers/developers if in doubt;
• in defect discussions, try to present the workflow inconsistency problem from a user perspective rather than a development defect. Instead of saying it's a defect, ask: If the user does this, will they get this, isn't this a conflicting/incorrect result? Shifting the focus to the end user is to some extent softening the degree of discussion of controversial points.

For developers:

• don't take defects in your own code as a doubt about your professionalism. The ability to recognize and correct a mistake is much more important than the mistake itself;
• it is necessary to remember that testing is not a confrontation with development, but an auxiliary lever on the way to achieving an ideal product, a shield against accusations of existing defects. It should be understood that the purpose of testers is not to degrade the development or its products, but on the contrary, to improve the final result everyone will benefit from;
• when QA asks for a meeting, it is worth at least finding time for a short discussion; a tester looking for answers is a bug fixed before it occurs;
• testers can ask any different or non-standard questions. These questions should be answered without any aggression not to make them feel guilty for raising the question;
• before claiming that «this is not a bug, but a feature», make sure that it really is, and not your laziness/pride/superiority that does not want to study the situation in more detail or fix the defect found.

In addition, an important lever on the path to synergy between testers and developers is cross-learning: developers and testers must learn from each other. A developer can help a tester understand the code base, along with any associated test code, while a tester can help a developer understand the test suite and the rationale behind the test methods involved. A tester who understands the code base will be in a better position to find trouble spots and areas of potential failure. A developer who understands the test suite and how to create better tests will create a more powerful product and write better test code.

Share ideas but don't put too much emphasis on implementation: Frequent communication between development and testing teams helps to generate more ideas from both sides. The developer can advise how to test this or that module best, and at the same time, the tester can show how to fix the bug.

And the most important thing is that everyone should try to create such an environment, in which cooperation will be carried out on the basis of mutual professional respect, without emphasis on personal qualities or shortcomings. Everyone should work with a sense of cooperation and open communication, and respect the profession and work of each team member.  The above-mentioned facts urge a synergistic team to be born, capable of conquering all challenges, starting with bugs and ending with the permanent imperfection of the world of technology.