Wednesday 13 June 2012

Bug counts as (bad) quality indicator.

The dev team at my company has a Agile approach to software development. So my toughs here are about what is working and why and what not, but this always depends about the context.
I'm going to define a bug, as a story written in the bug tracking system, with reproduction steps and observed vs expected behavior.

When we open a bug, we are using is as an artifact, as a tool to communicate stuff to do, stuff to fix.

When a important issue is detected, it gets fixed as soon as possible, maybe without opening a bug. The priority is to get the expected result back again, as soon as possible. Sometimes, it is because a bug. but this also happens because of bad configuration or bad usage of the tool. We really don't care so much, because the priority is to get it fixed.

If the bug is not so important, for whatever reason, then we open a bug in the bug tracking system. We do this so we don't forget to fix it for the next release. This allows us to go faster, to take some risks so we are able to deliver the features as fast as possible, we measure the risks and we decide that if it is good enough to go, but some minor details are worth to get fixed, we ship it first and we fix things later. This is buying technical debt, but we consider that the release has higher priority than the fix off all known bugs, this is why we open bugs, but it is also how we get a new release every week.

So the exact amount of bugs opened is not a measure of quality, it is just a list of known things that are worth to fix but are not a threat to the business.

If we punish the dev team with bug counts, we are going to spend time on sterile discussions about if a bug is a bug, or a feature, or a bad usage, or plainly who to blame, and we are also going to tailor our results depending on what is being measured. But we are not going to get more quality this way.

If we use the bug tracking system to measure the quality of the team, we will be perverting the core function of a bug tracking system, this is, to solve the known bugs.

By doing this way, the team has a clear goal, it is to get the new features out, running and adding value to the business, making the user experience better than it is today, and not lowering the bug count.

These are not only my ideas, but I wanted to make a short writing. If you feel like reading more, please take a look at:

Cem Kaners writing , Joe Strazzeres writing, Michael Boltons wrtings here and here

No comments:

Post a Comment

Atomic Habits book review

  Atomic Habits is becoming a popular book about dealing with you own habits. The book is an easy read, where concepts are presented in a wa...