Flavours of bugs and how to action it
- December 18, 2017
Have you heard people talk about defects and then you hear people talk about bugs? Some of us think it’s the same thing. It is most probably the most confusing thing but it is not the same.
My terminology for a defect and a bug is as follows. But you don’t have to agree, you can create your own. Although keep in mind, there is a difference between these two and you should be able to differentiate.
And then there is another category of issues that are caused by recent developments. I call those nasty little things “Escaping defects”.
Action items for a bug:
A bug is a classic just fix it situation. If the bug is not fixed you can’t close the US and you don’t meet the acceptance criteria. We never size bugs. The original US has all the size needed for designing, documenting, coding, automation testing, bug fixing and whatever else you may need to set it to “DONE”.
It is up to your team to decide to document bugs or not. If you have excellent communication then you may get bugs fixed using collaboration and you can skip the paperwork. But if your team have more remote team members, different time zones or hectic work environments then you can adopt for more formal documentation by creating a bug and linking it to the original story.
But you should never ever count bugs as a metric for code quality or QA effectiveness. This will only create a barrier between development and QA teams. Let the team, together figure out what quality means and hold everyone accountable for the quality of their work. The only thing what matters is what when a US is closed at an end of a sprint it should be bug free. After all, we won’t want to send a new feature in to the world when you know it’s flawed. The goal at the end of the sprint should be zero bugs.
Actions for a defect:
Defects are pre-existing issues fond in production. Generally, the older the product is the more defects you will have. But the nature of the bugs can be controversial.
We can never aim for zero bugs unless the system is very small or very new. There will always be bugs. Especially as the software grows. It’s inevitable. Bugs are prioritized by the product owner and sized by the team. Always consider ROI on fixing a bug or implementing a new feature. We need to know details such as,
We pull bugs from the product backlog and take them in to the sprints based on priority.
I believe measuring the number of bugs maybe useful. Not in measuring development quality but how much do users expectations differ from our understanding of the product.
In Sprint A, the team works on a story and in Sprint C the user reports the issue. After analysis the team figures that it was introduced in Sprint A. This happens all the time. We fix something, we break something. Ideally it should have been caught in Sprint A but it was not, hence we call these Escaping Bugs. We tag these bugs in JIRA or TFS with the label “escaping bugs”.
The team will analyze the bug and come up with a mechanism to improve their process going forward.
Now the number of Escaping bugs is a good measure for the team’s quality. But aiming for zero escaping defects might not be realistic especially for legacy systems, large code and code written by developers not in the company any longer. But I think tracking the number across sprints should demonstrate improvements based on learning, automation, process improvement and refactoring.