Defect reports are a critical QA tool for managing communications between developers and testers and for monitoring the quality of the process. Defects can tell us alot about not only the software but also how well the SDLC process is working. Bad defect reports frustrate everyone and slow down the whole process for resolving the issues.
What are the goals of a defect report?
- To identify and resolve defects as quickly as possible
- To identify risk as early as possible
- To ensure the business requirements are met
- To provide enough information to accurately describe and reproduce the problem
How do we achieve this?
- Be clear and specific
- Avoid creating similar or duplicate defects, each duplicate is time wasted.
- Help pinpoint the problem quickly, provide additional information where possible (log files, screen captures)
- Do not combine multiple defects in one report
- Report the defect quickly, add additional information as you investigate further
- Create a clear one line description so that managers don’t have to open each defect in a summary report to know what the problem is.
Tips to Remember
- Try not to diagnose the problem, remember we are not developers
- Do not recommend how it should be fixed, remember we don’t design the product. Refer only to the design specifications as to how it was expected to behave.
- Try to cover all the possible questions in the report. Are other team members having to often ask you for more information?
- If the defect turns out to be “working as designed”, ensure the customer documentation explains this area clearly. If you misunderstood the requirements, so might the customer.