Who about what, and I about bugs.

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

What is it?

Zero Bug Policy (ZBP) is an error-based policy based on the rule:

“If a new error appears, you should immediately decide to fix it in the near future, or close it as“ Won't Fix ”.”

You do not need to go to extremes: do not make mistakes at all or correct everything. It is important to work out for yourself the quality criteria for the features that you are ready to give to users and consider the task completed after correcting all the important errors.

Policy Benefits

• Everyone knows how many open errors there are and this number is rather limited.
• Less time is required to find the task in the bug tracking system.
• There are no lengthy meetings on sorting and re-prioritizing the backlog of errors.
• You may become psychologically easier when your bloated backlog does not put pressure on you.
• When correcting, it is not necessary to remember what was there “a hundred years ago,” and again to dive into the context.

It sounds great, but there may be side effects.

• Reduced product quality.
• Degradation of the testing team level. (Why waste time searching for cunning and complex bugs, if they are still not fixed?).
• A useful source of information (in the form of open backlog) for new team members is lost.

And there is always the fear factor.

“We will close the error, and suddenly a bright future will come when there is time to correct it”?

It is very unlikely that you will have extra time. It’s like storing old junk on a balcony: you don’t lose hope of using any of these things, but most likely it will never happen.

Here we will close the error, and the user will see it in the sale.

An upset user will write to the 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 the necessary) in order to shovel the whole backlog of ancient mistakes and make a radical decision to correct or close.
Then gather strength and correct the "survivors" after cleansing errors.
And start living by the new rules.

Start dividing bugs into two categories:

• a bug found when testing a new feature;
• bug found on the prode / when regreshne.

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

• fix the bug before the end of the development / testing features;
• reclassify the bug (maybe this is actually an improvement);
• it is possible, and not to get a bug at all, if you are not going to correct it.
  At the process run-in stage, it is better to start and close such bugs with the resolution “Won't Fix” with a description of 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 prode / when it is resigned, then it is necessary to decide what to do.

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

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

Other details

Profit from the use of this approach is likely to be insignificant, if you additionally do not begin to change the processes and approaches in the 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, the implementation of Quality Gates, Impact Analysis, Agile Testing).
2. Eliminate the generation of bugs by refactoring the old code.
3. Correct errors quickly, which will reduce their impact in the future.
4. Write autotests to detect problem areas faster and more.
   prevent the repetition of errors.

Metrics

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

results

What are the results of work on ZBP with us?

We live in the real world, and in a pure form to use the policy did not work.
Someone faced the problem of Legacy and the inability to fix some bugs in a limited time. Someone had backlog accumulated over the years, it was just scary to approach him and they were in no hurry to start this process.

But in general, many teams managed to disassemble their backlog and put a certain bar on the number of open bugs. Teams began to better evaluate bugs and make decisions about the need for corrections faster.

findings

• 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 company's engineering culture.
• The team must maintain a balance between the correction of errors and the development of the sprint.

All good and fewer bugs!