When Ipsita Chatterjee started testing about a decade ago, her test manager and mentor told her, "A good tester is not one who finds the most defects, but one who closes the most defects." After years of developing her testing and test management skills, she couldn't agree more. She now asks herself, how can a tester close more defects? Her answer: by using a fine combination of product and technical knowledge, intuition, and personal skills. With that in mind, this article focuses on the definition of defect advocacy; why, when, and how to approach it; and a few ways of achieving it to an optimum level, which should help you release quality software applications.
What Is Defect Advocacy?
Defect advocacy is almost like selling a bug. It includes all the techniques that can be used to convince or even motivate a developer to fix a defect. When you find a defect in the product, a defect report alone sometimes does not motivate the developer enough to fix the problem. Developers frequently work within very tight schedules and prioritize the defects they have to fix based on their set of criteria, which does not necessarily address the requirements from the testing team. You have to convince them to fix the defects that leverage testing the most, However, because of this defect, one of the paths through the application was completely blocked and not tested at all. The defect report did not detail this defect, so the which essentially boils down to selling the defect reports and the defect statistics over the various testing phases.
Why Do We Need Defect Advocacy?
I once had the same defect open through at least three test cycles. It was not a critical defect, and it had a workaround. As a result, testing did not come to a halt. developer didn't fix it. I attended design reviews and was aware of how the application should have worked. I had a hunch that something was hidden by this defect, so I went into marketing mode and used my interpersonal skills to convince the developer that this fix was crucial to testing all of the system's paths.
I worked with him to reproduce the defect and detailed all the steps correctly. I presented a defect matrix that covered various releases to the project and test managers to point out that this defect was constantly being carried over to the next release--its status changed to retest each time. Finally, this gave us a chance to use the alternate system path for test execution. As I had expected, there were fifteen defects reported in that area. If we had not addressed the defect sooner, those fifteen defects may have been discovered later in the process or, even worse, after the application delivered to the customer.
Defect advocacy can help in more situations than the one stated above. One common scenario in which defect advocacy is advantageous is when we deliver a project in parts. In these projects, the development team usually defers most defects to later releases. This hinders in-house testing and leaves a lot of user acceptance scenarios to be executed by the customers. This creates backlog and rework toward the end of the project. And most of the time, this chaos isn't visible to the development team.
When Do We Need Defect Advocacy?
Defect advocacy can be used during most phases of the project in different ways, and it need not be used only by a test analyst. Any member of the project team can use this technique to persuade others to fix problems in requirements, the architectural design model, detailed design documentation, or the code. Bugs aren't confined to code, so the earlier in the lifecycle we can find and fix a defect, the better it is for the quality of the product.
For example, defect advocacy includes asking for clarification on ambiguous requirements so that you can develop a design to meet the specific requirement. If the architectural design model does not look into addressing performance issues, questioning the same issues and resolving the performance requirements at that stage will stop a catastrophe in the project delivery. This is also an example of defect advocacy. Persuading key people to eliminate design faults that will lead to defects in the code is also an example of defect advocacy.
Defect advocacy is used mostly during the code-testing phase, though it is helpful and effective in all phases. Statistics showing maximum effectiveness of defect advocacy are available only for the code-testing phase.
How Do We Implement Defect Advocacy?
As I discussed earlier, defect advocacy is like marketing a defect to the developer. You must convince the developer to spend her time fixing the defect. I've listed some selling techniques below, but understand that this list is not exhaustive--add whatever works for you.
- Create comprehensive defect reports. It often has been observed that a developer will avoid a defect assigned to
him or her because the defect report lacks enough detail to reproduce the defect. Insufficient defect reports can discourage her from investigating and analyzing the defect. As a result, the developer postpones fixing the bug. Having a detailed report can stop the developer from delaying fixes to an extent. - Research the defect thoroughly. Often the defect does not look that serious at first because the defect report does not reflect its true severity. If a defect report isn't ranked as serious or doesn't list any major implications, the developer will not prioritize it as an urgent fix. It is good practice for testers to investigate these kinds of defects in depth. The tester will come across other failures associated with the defect that will aid the developer in fixing the defect. If the defect is sporadic, trying to reproduce it repeatedly can give more details about the defect.
- Take ownership of the defect. It is easier to motivate a developer to fix a defect if you take ownership of the defect. It gives you an edge to get the defect fixed.
- Build rapport with the developer and then use it. Developers often look at testers as people who scrutinize their work. Testers must work toward developing a friendly rapport with the developers by working as a team. This can be handy when you want a defect fixed, because the developer will trust your judgment on the product and defect.
- Create test status reports. Most projects have team meetings at least once a fortnight. If the same defect keeps showing up over a few test cycles, the project and test managers--maybe even the project sponsor--will start to notice. This may put pressure on the development team to fix the defect, yet this is not the best way to implement defect advocacy and should be used with extreme caution.
Sometimes the developers may feel that the test team is trying to put development down by focusing on open defects that need to be fixed in the status report. - Get Management Involved. This is the last approach on my list because I never recommend it unless it is absolutely necessary. Putting pressure on the developers may be a quick fix for one defect, but this may lead to a loss of rapport between the tester and the developer. This should be used with extreme caution, and testers should exercise due diligence before going down this path.
Conclusion
From the above discussion, it is very evident that a normal defect reporting and resolution process is at times not enough to achieve quality in a software product. Even when the organization is mature in terms of having processes, human intervention and soft skills of a test analyst go a long way. In order to get the defects fixed that matter most to the testing cycles, the ultimate product quality depends on how defect advocacy skills are used. Defect advocacy is an excellent skill to pick up and develop with ones testing career, which can add a lot of value not only to the product quality, but also to your testing career.
