How do testers present the right information, in the right way, and at the right time to enable decisions to be made as to the importance and urgency of addressing bugs?
As testers, we exercise our skills, creativity and knowledge to find bugs in software. This can be intellectually challenging and difficult work. Once we have found a bug,we might think that we have overcome all the obstacles to succeed in doing so and that was it, the end of the bug story; however, the challenges do not stop there. Our task then is one of communication; to inform stakeholders what the issue is, and what its impacts could be. On top of that, the stakeholder isn’t necessarily one person, but could be multiple people in a variety of technical and non-technical roles, such as product owners, developers, or other testers. We aim to present facts and data in such a way that decision makers are able to make a well-informed decision about the issue. This is Bug Advocacy. In this article, we outline the means of becoming an effective Bug Advocate.
An important asset in Bug Advocacy is the bug report. The report should be written using clear language, so that stakeholders can understand the issue and clearly assess its severity. Other supporting material such as screenshots, recordings, stack traces and log snippets can be very helpful in communicating the issue.
A tester who is a good Bug Advocate will build a positive reputation within the team and the company. Building this reputation takes a combination of diligence and interpersonal skills. If the tester has shown that a bug has been diligently investigated, its source isolated, and related avenues of testing have been carried out, the developer can get to the heart of the issue quickly and the right fix can be implemented. On the other hand, if a developer has problems reproducing an issue, or if the steps to reproduce are overly complex, the likelihood of that developer fixing the issue becomes lower. In addition, testers who provide good, actionable information on issues will gain a favorable reputation with product owners.
Interpersonal skills are an integral part of Bug Advocacy. A tester needs to have empathy on multiple levels. The concerns and product usage by customers is the most important aspect, but the tester also needs to consider the needs of the business, personified by the product manager, as well as those of developers. The communication with product managers and project managers must help them make business decisions in the best-informed way. Developers are the creators of the product. They may have an emotional attachment to code they have written, and a sense of pride in what they do. It is important to avoid hurting their feelings while, at the same time, motivating them to want to fix the issue. One means of doing this, for example, is to ask questions rather than pointing out errors. This balance is a skill to be cultivated.
A caution: testers should remember that it is not up to them to determine whether a bug should be fixed, or not. This is for the business to decide, and that decision is sometimes that the bug represents too little risk to worry about, or that the investment required to fix the bug would not be cost effective. In cases like these, the tester needs to be able to step away from advocating for the issue and move on to the next challenge. If this is not done, divisions can be created within the team that can have an adverse effect on morale and efficiency. This does not mean testers should be dispassionate, but they must know when to let go.
As practices evolve to become more agile, it is becoming increasingly common for software development teams to work without writing bug reports. How should Bug Advocacy work then? In these instances, the communication is principally verbal, and a good live demonstration is key to comprehension of the bug. One benefit of this approach is that the developer and tester can collaborate, and reach a mutual understanding of the issue quickly. This can be a pairing exercise in which the developer and tester work together to resolve the issue. Care must be taken; however, to find the appropriate time to discuss the issue. A balance is required between addressing the bug in a timely manner and allowing developers to do their work without costly context switching.
To sum up, we can lay out what Bug Advocacy is not, and what it is. Bug Advocacy is not a platform for airing complaints about product or process; it is not an opportunity for blaming someone for an error they made; it is not about the tester’s agenda, and it is not about arguing or debating. Bug Advocacy is a presentation of the facts and data around a bug; it is an assessment of a bug’s impact and the consequences of not fixing it; it is tailored communication for a variety of stakeholders; it is a means of motivating people to want to fix the bug, and it is a time to reach a common understanding.
Jim Peers is currently a QA Manager at OXD, a former Test Manager at the Integrated Renewal Program at the University of British Columbia, and an alumni QA Practitioner from PLATO Testing.