Who about what, but I'm talking about bugs.

Last year I told you about the Bagel’s - an event held in our company for cleaning the backlog of bugs. The event is good and useful, but it solves the bug problem one-time. We have already held six Bagodelen, but the number of participants was gradually decreasing and it became obvious that the need for this event began to disappear. The main reason was the appearance of Zero Bug Policy. There are not many sources in Russian about it where you can read and find a convenient solution for yourself. In this article, I will talk about our approach to the topic and will read about your experience in the comments with pleasure.

What is it?

Zero Bug Policy (ZBP) is a rule-based error handling policy:

"When a new error appears, you must immediately decide to fix it in the near future, or close it as" Won't Fix "."

In this case, do not go to extremes: do not make mistakes at all or edit everything in a row. It is important to develop for yourself quality criteria for features that you are ready to give to users and consider the task completed after correcting all important errors.

Policy benefits

• Everyone knows how many open errors there are and this number is quite limited.
• Less time is required to find the task in the bug tracking system.
• There are no lengthy meetings to sort and re-prioritize the error backlog.
• It may become psychologically easier for you when you are not pressured by a bloated backlog.
• Upon correction, it is not necessary to recall what was there “a hundred years ago”, and again to plunge into the context.

Sounds great, but side effects are possible.

• Decreased product quality.
• Degradation of the testing team level. (Why waste time looking for tricky and complex bugs if they still don't get fixed?).
• A useful source of information (in the form of an open backlog) for new team members is lost.

And there is always a fear factor.

“So we will close the error, and what if a bright future comes when there is time to fix it?”

It is very unlikely that you will have extra time. It’s like storing old junk on the balcony: you do not lose hope to use one of these things, but most likely it will never happen.

Here we close the error, and the user sees it in the prod.

An upset user will write to support, which in turn will inform you. It will be necessary to review the priority of this error and re-decide whether to correct it or not.

Implementation

The hardest part is to get started. To do this, you need to find the time, resources, desire (underline necessary) to shovel the entire backlog of ancient errors and make a radical decision to correct or close.
Then, gather strength and correct the "survivors" after cleaning the mistakes.
And start living by the new rules.

Start dividing bugs into two categories:

• a bug found while testing a new feature;
• a bug found on prod / with regression.

If you find a bug when testing a new feature, you must immediately make a decision:

• fix the bug before the development / testing of the feature is completed;
• reclassify a bug (maybe this is actually Improvement);
• maybe you don’t have to get a bug at all if you are not going to edit it.
  At the break-in stage of the process, it is better to start and close such bugs with the “Won't Fix” resolution describing the reason for closing. Based on these data, you will be able to analyze defects and correctly develop quality criteria in your team.

And if there is a bug on the prod / with regression, then you need to decide what to do.

• Fix the bug and meet the deadline depending on the priority of the bug. The fix time is from "right now" to two sprints. If the bug has not been fixed in two sprints, then it should be closed.
• Change task type from “Bug” to “Improvement”.
• Close the bug with the resolution “Won't Fix” with a description of the reason for closing.

To determine the priority of the bug, we use a matrix that combines the criticality of the bug within a specific command and the frequency of occurrence.

Other details

The profit from using this approach is likely to be insignificant if you do not additionally change the processes and approaches in development and testing.

What will reduce the number of bugs when developing a new feature?

1. Use a wide range of technical and organizational practices (for example, implementing Quality Gates, Impact Analysis, Agile Testing).
2. Eliminate bug-generating locations by refactoring old code.
3. Correct errors quickly, which will reduce their impact in the future.
4. Write autotests to detect problem areas faster and
   prevent the recurrence of errors.

Metrics

In order not to draw conclusions on our feelings, we monitor ZBP metrics (I really like Tableau and use it to build reports). This allows you to track progress in dynamics and highlight emerging problems.

results

What are the results of work on ZBP with us?

We live in the real world, and in its purest form it was not possible to use politics.
Someone encountered a Legacy problem and the inability to fix some bugs for a limited time. Someone had a backlog accumulated over the years, it was just scary to approach him and they were in no hurry to begin this process.

But in general, many teams managed to parse their backlogs and set a certain bar on the number of open bugs. Teams began to better evaluate bugs and make faster decisions about the need for correction.

conclusions

• It takes a lot of effort to change your approach to working with bugs.
• For the process to work, it must become part of the engineering culture of the company.
• The team must strike a balance between error correction and sprint development.

All good and less bugs!