Bugs, not as simple as we tend to think (part 2)

Bugs are an important part of the work of testers, but for some reason we tend to take them for granted, and don’t invest the proper value and thoughts to them.

I am not saying they are the most important part of the process, but they are an incredibly useful output and measurement if you manage them correctly and know what you are looking for.

Bugs are also the cause of anger and miscommunication between teams, and when approached lightly can cause as much harm as good.

But let’s be clear, it’s fairly inevitable that your software has bugs in it…..almost all software does.

Today we want to continue talking about some important points that relate to bugs.


Do all teams need triage?

What is triage and how come we are using a medical term defined in war time to handle bugs in development practices???

Triage is an bureaucratic overhead, I try to avoid it as I try to avoid unneeded meetings.

I prefer to have a mechanism to escalate bugs we do not agree on their priority.  BTW, triage should not determine the severity of a bug, only the priority…


Severity, Priority or Both?

The answer is depending on what it is needed.

Just remember that priority is subjective, while severity is objective.

If you can, create a severity table…  Use even number of category, not uneven


What is it with this “zero bug backlog” idea or trend?

Nice idea, a bit overhipped, do not think it is an objective but maybe an indicator of a very agile process.  Still zero zero zero backlog sounds a bit strange as we may want to keep track of things we do not want to fix right now, specially when working on iterations…  So ok, we can make a story for it, but then we are just talking semantics.

  • All bugs should be fixed


Thanks for listening.

As usual let us know what you think in the comments or on Twitter

Don’t forget to like and subscribe to get more content like this


No comments yet.

Leave a Reply