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