etc. Most people probably see nothing wrong with this – both the people that ask the questions and the people responsible for tests, implementation or programming. However, if you carefully consider these questions, you could come to a completely different conclusion.
Let us imagine the situation where failure occurs immediately after the code is uploaded to the production servers. The person responsible for implementation asks the magical question: “Who tested it?”. The first and most important issue is – should this question even be asked in this situation? Is the issue of who tested or reviewed the code the most important thing at this moment? The answer is: “no”. In this situation, the most important thing is to rectify the failure. Only after this is done can we start thinking about why we were unable to locate the defect earlier. I wish to emphasise this: thinking, not asking: “Who tested it?”. I have the impression that, all too often, we focus on finding the culprit and freeing ourselves of the joint responsibility for the failure.
Team communication is key
This, however, is not the way. Not only do we not find the problem, we can also cause a number of other problems. What do I mean? People are different, and they may interpret the same message in various ways. One person will let the question slide. Another may take it very personally, causing him or her to lose confidence or become afraid of working with the given person or resulting in other consequences. It should be explicitly stated that blaming one person on the team is completely unreasonable. After all, the given functionality was described by someone else before, then it was coded by another person, tested and perhaps even code-reviewed. It may be the case that such a buggy code has passed through a fine sieve of automatic tests. The key issue is that something has been done wrong, not the fact that someone has made a mistake. The problem most likely does not lie with the person but with our process, or rather with its imperfections.
Target errors?
Well, unless we hired a saboteur. I do not believe that there are people in our industry that do their job incorrectly on purpose – I believe that the problem lies with the process. For instance, the task was insufficiently described, or the scope of tests was incorrectly defined. Perhaps the programmer forgot to tell the tester that the changes he or she had made would affect not only module A but also module B? Or that regression tests would be necessary? Or perhaps the tester, convinced of his or her extensive knowledge of the tested system, found that he or she had all the information necessary to test the given change or functionality and failed to ask the programmer about some detail? There may be many reasons, but I am convinced that most of them can be avoided by improving communication.
It is not wrong for someone who does nothing
Let us remember that regardless of the methodology guiding our work, we all play in the same team. We share a common goal, we are on the same side. When we ask “who tested it,” do we consolidate our team or perhaps undermine the relationship and ruin trust? Once more – the problem usually does not lie with the person but rather with the procedure. Let us find the problem, not the “culprit”. Only then will we improve the quality of our product and our work and create good atmosphere. Let us remember – everyone can make a mistake. It is not only the programmer that may have a worse day and make a mistake. The tester also may fail to notice or remember something. We are all human, and we all err – this is something we will never avoid. However, our work should be organised in a manner that lets us avoid such mistakes and minimise their number.
