30 Days of Testing, Day 27: 0 bug tolerance

(Heather) #1

Day 27 task: Investigate a 0 bug tolerance.

This task reminded me of a blog post from @punkmik not so long ago Experimenting with a 0 bug policy. I also found another one on my search Zero-Bug Software Development.

I must say, I think one of the companies I worked for did it quite well. We had the feeling that bugs in the backlog brought down team morale most importantly. Yes, bugs mean many other things but poor team morale is something to focus on in order to achieve a good product I feel.

Armed with this experience, when I started my last job one of the first tasks I aimed to achieve was investigate the bug backlog and check what was still relevant, were the priorities still the same, etc. I then paired with the relevant developers to reassess the priority that had been assigned to each bug. One thing we noticed was that lower priority bugs were actually the low hanging fruit. The devs suggested scheduling quick things (the lower priority items) such as typo fixes in with bigger features they were working on.

In a similar manner, with anything of a higher priority we assessed together whether they were bugs, things that needed UX/Project Management input (therefor a feature to be designed rather than a bug) or something that could be closed as soon to be implemented functionality would supersede or fix the issue.

When I finished, did we have 0 bugs? No, but we had more than halved the backlog. I think with full team buy in, a 0 bug policy in that instance was possible but it would have taken a lot of work.

Do you think a 0 bug tolerance is something your team could achieve? If you can will it be a big task to get there? If you already have a 0 bug tolerance, is it working for you and your team? Is it difficult to keep on top of it?

(Olly) #2

This one is from a tester on my team:
“Fun story, one of my last jobs implemented a zero bug policy at one point. Between working to clear the backlog and implementing new features as well as creating bespoke builds for potential clients, the new code was often rushed and we ended up opening more bugs than ever before. One new feature had over 100 bugs when it first entered testing. I’m not saying it was entirely the zero bug policy’s fault, there were a lot of terrible decisions being made around that time, but it certainly didn’t help much.”

(Heather) #3

I like this post from @davewesterveld which gave me a lot of food for thought about the importance/priority of implementing such a policy

(Dave) #4

Yeah interestingly (unrelated to this post), I just had a discussion with my boss on how to make sure I"m not trying to ‘do to much.’ Figuring out how to prioritize is a difficult (and important!) skill