How Can a Zero Bug Policy Help You Get Rid of Bug Debt?

In this article, I'll explain how I worked with my teams to reduce technical debt associated with bugs to a bare minimum. I can't guarantee that it's a universal formula; all I can say is that it worked for hundreds of teams and projects when it was implemented. So, my recommendation is that you try it out on one of your teams first, get feedback, and figure out what steps to take next. I started to wonder a few years ago how much time my departments were wasting when it came to technical debt, particularly technical debt related to bugs. It was only a minute before the industry shifted to cloud platforms, which exacerbated the problem due to the increasing pace of product releases, which have shifted from one or two per month to one per day.

I had a lot of ideas and questions about how to solve this problem in a way that is both efficient and practical. I couldn't find the right solution for me after researching known solutions; some of the suggested solutions were just too theoretical but not practical, and others were just too complicated for the lean environment I've tried to promote in my groups. At the end of the day, my goal was to foster a work environment that minimized technical debt while maintaining the quality of our products and the business value we provide to our customers. So, because of the benefits of removing the annoyances of bug management from software development, I decided to promote a "zero tolerance of bugs" policy.

I must admit that, while I was convinced it was the best approach, I didn't fully comprehend the concept at the time. Yes, it makes sense to use it, but I've never imagined or seen an environment where development teams can come close to achieving that goal, let alone zero bugs. After a few years of hard work and intense focus on the end goal, I was able to successfully implement my vision. Today, I can say that it was the correct decision. My departments can provide more value to our customers with zero known bugs, as opposed to increasing our technical debt in the past. I even discovered that my teams don't have to waste a lot of time determining the severity and priority factors for bugs.

We make sure that every stakeholder in the company has visibility into our work and what is going on at each stage of the release pipeline as part of all of our basic practices.

We also keep our release pipeline up to date so that we can deliver an increment product a few times a day. Last but not least, we are able to keep each user story small enough to have almost no dependencies on other stories. This allows our developers and testers to work more efficiently and on the entire codebase at the same time.

All of the above may appear to be very similar to what you would expect in an Agile working environment, but the main difference I made in my groups was the use of ATDD and TDD practices (Unit Tests, Per Programming, etc.) to harness the power of our engineers. We were able to automate 100% of our acceptance tests using these two practices, as well as build a robust deployment pipeline (CI/CD frameworks) that runs all of our functional tests, as well as performance and security tests that compare variations to a known baseline that we update per project. We can now ensure that every push to the trunk in the pipeline is covered by automated tests thanks to such a robust pipeline.

The following is a high-level diagram of our pipeline:

In action: the zero-bug policy

Now that I've visualized the pipeline, it's time to tackle the most important question: "How do we put the zero-bug policy in place?" If a bug is discovered during user acceptance testing or exploratory testing, the team member who worked on that user story immediately abandons all other tasks to fix the bug. The user story cannot be marked as "Done" until all bugs have been closed and verified, in order to increase visibility. The real benefit of this strategy is that the CI tests will always pass, and a working build will always be available.

When a member of the team fixes a bug, he must also write automated tests to cover the bug's path. We don't always log them into bug-tracking systems, which is another important aspect of this approach. This will save a significant amount of time during the bug life cycle (DLC). When a bug is discovered during exploratory sessions, it's simply more effective to approach the developer and say, "I think there might be an issue that I'd like to share, could you show it to me?" If he doesn't have time to fix it (for whatever reason), no problem; a new bug is created and assigned to that programmer, who will begin working on it as soon as he is ready.

Because there are always group discussions to derive acceptance tests for each user story, a development approach like this allows the team to have a good understanding of the business requirements and the value they deliver at all times. This approach may appear to be quite radical, but if you put together the right team and follow good engineering practices, you'll quickly discover that the number of bugs discovered while exploring software is extremely low.

To bring this post to a close. bugs don't bother you when you embrace the zero bug policy and practice it consistently and without excuses. One of the best indicators of successful implementation of this approach is the team's ability to communicate effectively with one another, reducing waste associated with bug logging and management, as well as the usual Ping-Ponging between programmers and testers.

It also eliminates the need to keep track of bug statistics, trends, and KPIs.

Finally, this is just one practice; what matters is that you provide a quality product to your customers.