Defect reports communicate issues to developers and other stakeholders. When a defect is initially uncovered, it may be unclear whether it is a defect, an undocumented requirements change, a user error, or a misunderstanding. Some may resist calling something a “defect” because that implies “bad work” and might not reflect well on the team. Others may resist calling something a “requirements change” because that implies that requirements or design specifications were missed and changes may cost more money. Some organizations try to defuse this issue by changing the name to something less inflammatory, like “incident” or “issue” report. From a defect management perspective, what they are called is not an important issue. What is important is that the defect be quickly brought to the developers’ attention and formally controlled.
A good defect report should:
- Give sufficient and high-quality information to reproduce and fix the defect;
- Be well written; and
- Enable stakeholders to make wise decisions about which defects to fix.
Issues Should Be Reported and Acknowledged
Reporting a defect about someone else’s work can be difficult. Developers can feel frustrated and bitter toward testers when defects are found. When there is a debate on whether to report or fix a defect, both parties can feel aggravated and apprehensive. Care should be taken that all parties (to include the rest of the team – requirements, project management) are non-judgmental and unemotional. Most importantly, Quality Control and Development stakeholders must remember the ultimate project goal is to maximize the value of the application, and it is up to management/other stakeholders to decide that defects are handled correctly and given the right priority. This will enhance teamwork between Quality Control and Development.
Defect Reports Should Clearly State the Problem
A Developer should be able to easily replicate and fix a defect that has been identified. Don’t waste the developer’s time by including extraneous information. At Segue, we use Test Track Pro to report and track issues. Test Track Pro has a defect report template that ensures the correct level of detail is captured. Using a defect template becomes especially useful when documenting defects found in complex sytems. Here at Segue, we follow this process to support multiple Air Force information systems with a great number of specific acronyms and business cases. When we find defects in such systems, we often include screenshots and videos of these defects to reduce ambiguity and confusion. This enables the developers to quickly reproduce and fix bugs. The information included needs to be specific and should include a step-by-step account of the actions to reproduce the defect to avoid miscommunication. Do not skip seemingly “intuitive” steps or assume the developer knows and remembers the steps for every process. For example, it may not be sufficient enough to say “select the value,” if selecting the value can be accomplished by double clicking or checking a box or using a drop down menu. Also, do not use your defect report to make subjective criticisms; your report is to help stakeholders make an informed decision and that decision may be to NOT fix the defect.
To ensure pertinent information is documented, the following fields, which are a part of our defect template, should be required in your defect report.
- ID
- Description
- Product
- Steps to Replicate
- Release Version
- Actual Result
- ComponentFeature
- Expected Results
- Summary
- Reported By
Defect Resolution
Establishing a defect resolution process is great for the inevitable situation in which testers, requirements analysts, and developers are in dispute regarding a defect. For example, when a stakeholder reports a defect, but the developers do not believe it to be a defect or important issue, a quick-resolution process would be beneficial. While many approaches can address this situation, the two most effective are:
- Arbitration by the software owner: the customer using the software determines whether or not the problem is a defect.
- Arbitration by a software development manager: a senior manager of the software development department will be selected to resolve the dispute.
Defect reports are among the most important deliverables to come out of testing. They have a direct impact on the quality of the product, so a tester should take the time to create a great defect report. Cem Kaner, a Professor of Software Engineering, said “The best tester isn’t the one who finds the most bugs or who embarrasses the most programmers. The best tester is one who gets most bugs fixed.” As you can see, it is worth the effort to learn how to write effective defect reports.