Bugs is a software thing

Bugs is a software thing.

In most business areas customers don’t pay for fixing issues. When you find a defect in your SLR camera, you just bring it back and get it fixed or get a new one for free. But in IT this is a norm when you pay for bug fixes as so this is some real functionality.

Ron Jeffries recently wrote a good story about defects. The main idea is defects shouldn’t be planned separately, they just have to be fixed and if it takes longer to release a feature we should factor this into estimates. In agile world we factor this into velocity.

But I’d like to touch base on why we usually try to plan and prioritize defects separately. Well, it is obvious, sometimes we have quite a few of them and some bugs take a lot of time.

As Kate mentioned in Ron’s story, we can minimize amount of bugs by learning from them. Correct. I’d also add that we can minimize amount of bugs by working in pairs and unit-testing. It’s rather obvious.

But the big thing which is not very well understood is that quite often bugs take a lot of time because of the way we tackle them.

I also quite often hear questions about the role of QA in agile projects. Many books just skip this question, people get confused and testing/bug fixing in a somewhat waterfall approach.

Let’s take a closer at a rather familiar loop many teams work in:

• developers implement a feature during iteration X
• when iteration X is over it is released for testing and being tested during X+1
• when testing is done, release goes to customers and they explore it during X+2

So what’s bad here? The delay in between implementation and feedback on it. It’s the root cause of everything else.

It takes a lot more time to fix a defect which is found after several weeks of work on other features, people just entirely lose context on it. Sometimes another developer has to fix defects in code of his colleagues which doesn’t speed things up.

When bugs arrive, the team works on another release already and can’t fix them immediately (the team can’t fix them immediately also because the context is lost), so bugs require some filing – clear description, steps to reproduce, severity, etc. All these things should be formally documented, testers can’t just explain them to developers. And some issue tracking systems are nasty.

Apparently, this way bugs affect schedule of subsequent releases. So bugs is a big thing now and require prioritization. Prioritization isn’t a simple thing, developers need to provide estimates, product owners have to make some tough decisions. It may be difficult to engage product owners, so delays become even bigger.

When a bug is fixed it needs to be retested, but there is again a delay between a bug fix and a another test, so we have some context switching for testers.

Actually, such a way often results in bigger and bigger delays between implementation and actual testing. Some teams come up with a really heavy-weight approach to stay on top of the bugs, but in fact they just slow things down even more.

To summarize, we get the following wastes:

• context switching (both for dev and test team)
• formal filing and tracking which drags time
• additional planning as a result (estimates, prioritization)

The key thing is to decrease delays, so the team should aim to test and fix defects almost immediately after implementation (let’s say during next 24 hours).

I heard about a brilliant approach to implement it. Unfortunately, I couldn’t implement this on one of my projects yet, but there are real projects which work in this way.

So in addition to a pair of programmers we also need a tester. They form a triplet (triple programming). The triplet works on each feature together:

• the tester take part in all discussions
• when developers work on a feature, the tester creates test cases
• when developers think the feature is ready it gets tested immediately, developers can take care of e-mails and other stuff during testing
• when a bug is found, the tester just shows it to developers, it is worked on immediately
• during delays the tester automates tests (developers can also help)
• after the tester is happy about quality, he shows the feature to customers
• any issues found during the demo are fixed immediately 

Apparently, some bugs are discovered later and go the tough way, but most of the time:

• defects do not require documenting
• defects are found and fixed in a reasonable time frame before people lose context
• explicit planning is not required

But again, the key thing is to get feedback ASAP, no matter how.

I welcome your comments.