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.
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