» Notes on bug handling
I have thoughts and opinions on handling bugs in software projects, and they all have been living in notes, and I want to get them more systematized.
- The goal of defect handling is providing a view of a software project’s health through the consistent processing and resolution of bugs, identifying critical bugs, and understanding what bugs are associated with features, products, and releases
- Hoye’s law: The biggest predictor of if a bug will be resolved successfully is if it is in front of the right persons to work on it
- Use consistent definitions:
- a P3 is a backlog item for every team
- a S1 is a block ship for every team
- Don’t conflate priority with severity
- Priority is a scheduling problem
- Severity is a release problem
- Triage means “What’s the next right thing?” for a bug
- Fix it now
- Put it in a backlog of work to schedule
- Get a question answered
- Close it
- Move it
- Make triage simple
- What are the minimum number of things you have to touch in a bug to know what the next right thing is?
- Close invalid bugs quickly
- Public Bug trackers are social media
- Bug trackers are not project management software
- Bug trackers are not code review software
- A task is not a defect
- An enhancement is not a defect