I’m coming back as my team was implementing this. It has only been a week, but there are two major upsides I have noticed already. It should be kept in mind we are a small team that was already pretty good and fixing any bug that comes up in testing so our backlog is pretty small.
The first is when going through our current bug backlog and changing the tickets to User Stories, we closed some bugs without converting them. Why? The “issue” was just too small to warrant a User Story. This made me realize it is easy to open a bug for a very small thing and just leave it in the backlog to die a long and slow death. So now we just aren’t opening them because when we touch that spot again we will likely notice and update it then.
Second, one area had so many issues we realized cleaning it up needed to be its own feature that is prioritized. We came to this conclusion because having all the issues in the description of the User Story became confusing and we needed to split the issues into tasks. After doing that the team lead and I talked and realized when this happens it is a sign that we need a Feature to clean up the issues.
I thought these findings were interesting because there seems to be some psychologically engrained thinking that a backlog of bugs is fine. Maybe that is because on some level there is a wide assumption that most of the tickets are small, piddly things that don’t really matter or impact the product; so we don’t need to look at them. On the flip side of that is the thought that a list of incomplete User Stories should be assessed and thought about more regularly.
I hope my ramblings made sense 
.
6 Likes
Ok, so the response to this article has been so fantasic you’ve all inspired @prescottlewis707 to turn the article into a 99 Minute Workshop!!!
The workshop will be on 24th May 2023 @ 7pm BST. You can register here:
Community collaboration at it’s finest!
9 Likes
Would love to see some of you there!!!
4 Likes
Please share the link to the 99 minute workshop with your network: Zero Bug Policy: The Myths And The Reality | Ministry of Testing
Would be much appreciated!!
4 Likes
Gratuitously thread bumping this. Look forward to having loads of people online this evening. Been looking forward to this all week.
2 Likes
After attending Lewis workshop I co-incidentally dug this draft I wrote back in March, out of a box I stashed it in…
(snip)
15 years on, my average day is thus.
- Prevaricate over whether I want to read the nightmare of an overnight test report, then read it anyway and identify one test to improve.
- Start troubleshooting an issue a dev is having with their environment, and forget all about the previous item.
- Spend time manual testing a workflow that a customer says is broken. Discover it’s not broken, but has friction points so raise an improvement ticket.
- Celebrate raising a ticket that you know might never get done, and return to your first task. Zero bugs policy is really a myth.
- Meetings/comms takes a load of my day. Example: Spend time trying to get marketing to attend a demo or explain their requirements to us properly so that you can get a smooth sign-off for next week’s release.
- Do some manual testing for the release, and still not fix the automated test issue your day started with.
The more senior you get, the more time you loose to comms and to helping other people with their tasks. So you gradually spend more time writing stuff down and more time creating helper tools.
(end snippet)
And that’s where I was at the time on zero bug policy. The workshop showed me that it’s far far harder, and frankly that most teams are chicken (eggs), not pigs (bacon) when it comes to zero bugs as a process. It has raised some more serious questions, will see how we progress on getting clues.
1 Like
As W.E Howden showed back in 1976 with his paper “Reliability of the Path Analysis Testing Strategy” there’s no such thing as bug-free software above a surprisingly low level of complexity.
1 Like
Once I read between the lines, 2 things did emerge for me about Zer0-BP.
- Don’t just add stuff to a backlog and waste time triaging low value tickets repeatedly, get your PO to help ensure junk does not even start to enter the backlog.
- Don’t have a large roadmap, it’s anti-agile, creates friction for new features and encourages “castle” developer mentalities. See point above.
1 Like