The dynamic between coders and testers has a significant impact on the quality of the Software product that is delivered. Keeping this dynamic healthy is one of the keys to successful Software Delivery.
"Quality is not an act. It is a habit" - Aristotle
Anything that is built for use by a third party must be inspected for quality so as to ensure it is fit for purpose. Software is no different.
The job of a coder is to build. The job of a tester is to break. No coder likes to see their work getting broken so there is a temptation to get defensive about it. However, a good coder understands that in order to make something that cannot be broken (within reasonable parameters), testing should be at the core of the development process. Embracing TDD and writing a comprehensive set of tests can help reduce the likelihood of the work being broken by a tester.
Now, consider this scenario. Coder Charlie has committed his work and has had it reviewed. The code has been deployed in the QA environment for testing by the QA team. Tester Terry finds an issue and sends a Slack message to Charlie. The conversation goes like this:
Terry: Hi Charlie. I've been testing item XYZ that you worked on. I found that, when we hit the submit button with the 'notify me' checkbox selected, there is a delay of at least 5 seconds in getting a response back.
Charlie: 5 seconds is too slow. It was pretty quick when I tested this on my machine. I will have a look.
<After some time>
Charlie: I checked and it seems the iNotify REST service invoked by the form responds slowly. It was quick when I was testing it during development. We will need to speak to the iNotify team to find out why it is now slow.
Terry: OK thanks for the info. We will initiate a conversation with iNotify about the speed issues.
Charlie: Great. Let me know if you need me in the conversation.
Terry: Will do, thanks.This scenario illustrates an integration issue. An external REST service had latency issues that the coder could do nothing about. The tester was unaware of the integration with an external service and the coder highlighted this fact so that the tester could proceed with escalating the issue with the relevant team.
What is more important in this interaction, however, is the manner in which the coder and tester communicate with each other. The tester was very specific about the issue at hand (rather than just saying 'it doesn't work'). This enabled the coder to perform a quick investigation without having to ask further questions. The coder then described exactly where the issue lay and the action to be taken. The entire conversation was both amicable and efficient.
Now, contrast the above interaction with the one below.
Terry: Hi Charlie. I've been testing item XYZ that you worked on. I found an issue.
Charlie: What's the issue?
Terry: It's a bit slow
Charlie: Which part is slow?
Terry: When we hit the submit button with the 'notify me' checkbox selected
Charlie: Do you mean you see a response after some delay?
Terry: Yes
Charlie: How long does it take?
Terry: Let me try it again
Terry: It takes at least 5 seconds
Charlie: OK that is slow. It was pretty quick when I tested this on my machine. I will have a look.
<After some time>
Charlie: I checked and it seems the rest service invoked by the form responds slowly. So it has nothing to do with me. It was quick when I was testing it during development.
Terry: Who would be able to help with this?
Charlie: It is an iNotify service so you will need to speak to the team handling that.
Terry: OK, will do thatWe can see how this interaction differs from the first one. Coder Charlie had to ask 4 questions to get an exact description of the issue. By this point, he was probably quite frustrated which shows in his 'it has nothing to do with me' declaration. Tester Terry then had to ask who would be able to help as the coder did not specify which rest service was slow.
This is an inefficient conversation that also lacks the amicability found in the first interaction. Such interactions do nothing to promote a healthy dynamic between coders and testers.
Recommendations
There are several recommendations to avoid such inefficiencies. Here I highlight four of them which I have found useful:
1. Involve Testers in the Requirements Definition:
Agile Software Development practices such as Scrum encourage a Sprint Planning ceremony during which items for the upcoming sprint are refined and scheduled. During refinement of each item, it is good practice to specify acceptance criteria. This is a definition of the desired outcome of the item. The item will be accepted as done only if it satisfies this criteria. Involving testers in defining the acceptance criteria will reduce the possibility of misunderstanding the requirements by both coders and testers. The development and testing process is then more likely to go smoothly as everyone has a common understanding on what needs to be achieved.
2. Encourage Coders to think like Testers:
It is possible for coders to get tunnel vision during development (i.e.) they don't think about what could go wrong. Testers on the other hand think about how to break the system and therefore always think about what could go wrong. Coders must get used to the habit of coding not just for the happy path but for unhappy paths as well. Incorrect inputs, edge cases, and the human nature of those that will use the system must be taken into consideration. This sort of thinking can be encouraged by having coders conduct occasional live demos to testers while testers ask questions about how different scenarios are handled.
3. Make Details Known to Testers:
Sometimes it helps for testers to be aware of implementation details. For example, if an external dependency such as a third-party REST service is involved, then it helps for testers to know about this so that they can perform any necessary integration tests. In general, it is good practice for coders to write a technical specification of their work before they implement it. Having testers go through such specifications will help them devise the best approach for testing and to provide more detailed feedback to the tester if an issue is found during testing.
4. Encourage Banter between Coders and Testers:
This is more of an exercise in soft skills. It is not uncommon for ego to play a part in the interaction between coders and testers, as they both try to defend their point of view. Ideally, there should be a unified point of view, which is what the first two recommendations focus on. However, for the odd occasion where the point of view varies, it helps if coders and testers have a healthy working relationship so that they don't let their ego get in the way. Both parties should keep an open mind and take in the opinions of the other party and work together to resolve the issue. Banter can be encouraged by involving testers in agile ceremonies, as stated earlier, and also by creating more situations where both parties interact with one another, professionally or casually.
Conclusion
A successful software delivery team relies on a healthy working relationship between coders and testers. Having respect for each other's role in the team and following recommendations as outlined above will go a long way in ensuring a smooth software delivery process.