Defect Definition of Ready
I have already written about my thoughts on the Definition of Ready. The intent of that article is related to feature user stories.
Recently at my job, we spent a large deal of time reviewing vague regression defects as an entire team. In this meeting, we had ten team members spend two hours to prioritize ten defects.
Doing the math, assuming each member's time cost averages out to fifty dollars per hour, this equated out to $100 spent to prioritize each defect. Keep in mind, that figure does not include the time to clarify (person to person), reproduce, resolve, any churn as a result from the lack of clarity, and testing of each item.
( 10 members x $50/hr x 2 hrs ) / 10 defects = $100/defectIt made me realize, as a team we had never defined our expectations of minimum information needed before we convene as an entire group to prioritize and discuss. As a result, I proposed we have a Defect Definition of Ready.
References
I could not find articles specifically referencing a definition of ready in regards to a defect. Although, I found a large amount of good information related to writing a good bug report. The first link is a must-read for anyone interested in the topic.
So, at this point, you may be saying to yourself, “That seems like overkill.” Maybe. I doubt it. An extra minute spent adding the above information to a bug report can save hours of engineering time if it keeps someone from investigating the wrong thing, on the wrong device, without knowing that it only happens on the local network with yesterday’s build.
If your bug report is effective, chances are higher that it will get fixed. So fixing a bug depends on how effectively you report it. Reporting a bug is nothing but a skill and I will tell you how to achieve this skill.
Many people can write a defect report but only a few are able to write an effective defect report. There are some differences between average defect report and good/efficient defect report.
Definition of a Good Bug Report
A good bug report is one that describes the problem well enough that someone familiar with the project can understand and act on that bug report without talking to the person who wrote it.
Benefits
Many of the same benefits exist with a defined definition of ready for stories and defects.
- Avoids wastage of time
- Outside the explicit time spent, the amount of time wasted due to the interruption (Avoiding Interruptions may be much greater.
- Reduces churn
- Without explicit recreation steps, how do we (engineers) know the problem is fixed?
- Keeps the team members accountable to each other
- Fosters good relationships between testers and developers
Example Checklist
- Contains descriptive and explicit title
- Contains descriptive and effective summary
- Describes the problem at a high level, in a way that anyone familiar with the project can understand
- Contains steps that reproduce the defect
- “given (preconditions) when (actions) then (result)”
- Contains one logical defect
- Identifies the expected behavior
- Identifies the current behavior
- Identifies if defect already exists in production
- Identifies the priority
- Identifies the frequency
- Identifies the context
- the product, device or browser, and relevant configuration options
- user, role, and organization
- build number
- Considered if similar defect exists elsewhere
- Considered taking a screenshot
- Meets the definition of Good Bug Report
Revisions:
- Updated 03/07/2016 at 11:15 AM to include additional item in checklist, one logical.
Get In Touch
We'd love to hear from you! Whether you have a question about our services, need a consultation, or just want to connect, our team is here to help. Reach out to us through the form, or contact us directly via social media.
