Tips for reviewing defects

We spend a lot of time talking about how to write good bug reports and how to advocate for issues you feel are important. But what if you're on the other side? What if you're reviewing defects and/or running the meeting where you assign priority and severity? What if you make the decision for what gets fixed?

Here are some tips that can help you make sense of what you're looking at. Note, these tips are focused on the way the bug report is written. It's difficult to talk about hard and fast rules for prioritization without knowing the specifics of the the project, project team, and context. It's also not intended to be in any way a complete list. Just some of the things you might think about...

• Try to identify any viewpoints that might be embedded in the defect report. If there is a bias to the report, don't let that necessarily influence your decision on how sever the issue is. Ask for clarifications or more data if needed.


• Ask yourself how your stakeholders would view the defect report. Switch viewpoints. What would they care about if they were in the room?


• Look for inconsistencies between defect reports and ask for clarifications. Why might something work in one instance but not in another? What information is missing that can help you (and the team reviewing) make sense of those inconsistencies?


• Try to understand the implications of the ticket. Look past what's reported and see if anything occurs to you about the nature of the bug. What does that mean for the project team?


• Is there any key information omitted or glossed over? Is there summary data without a link to the detailed data? Try to find areas where more research might need to be done before conclusions are drawn.