Why not all errors need to be corrected to make an IT product better
2 + 2 = 3 2 + 2 = 5 2 + 2 = 4
When buying an IT product to solve various corporate problems, business customers most often think about its cost, functionality, convenience, integration capabilities, etc. These are not so obvious issues, such as the quality and level of technical support, they are already thinking in the second place.
But the quality of the final product to a large extent depends on how the developer organized the process of testing, identifying and fixing bugs, among developers known as "bugs" (from the English bug – a bug, any insect, virus, slang word that usually means an error in a programme). This question is asked by very few individual business customers.
We want to tell you about how developers identify and fix bugs, are suitable for testing. One approach is based on the Zero Bug Policy. Spoiler! We will tell you what the developers actually spend time on and why they don’t fix all the bugs.
Seven nannies
seven nannies
There is a well-known joke dedicated to the announcement of the new release "Optimized application performance, bug fixes, new ones added." In fact, fixing bugs and adding new ones is an eternal process, old bugs are fixed, but there are no less new ones.
This is especially noticeable when a large number of developers or even several project teams work on a software product, on a single code base. It is very difficult to synchronize their efforts and get the output completely error-free code. For example, one team saved the changes in the master branch, that is, in the main version of the code in the repository (repository). In turn, the other team is faced with a huge number of conflicts and is trying to fix them. As a result, all this goes into release, that is, into the final version of the product, suitable for ordinary users, and here an incredible amount of bugs pops up. And this is fraught with the loss of money, customers and, most importantly, a threat to the reputation of the developer.
So what to do in this situation? You can throw all your strength and resources into fixing errors, but how then can you engage in product development, improve existing ones and add new functions?
Out of sight, backlog out
broom sweeping
One big IT company just had a similar problem. Thanks to the recommendation of one of the specialists who worked in the company, it was decided to apply the approach Zero bug policy. Unfortunately, little has been written about him in Russian yet.
Its essence is as follows. When testers or users find any bug in the product and inform the developers about it, the latter decide whether this bug will be fixed or it does not affect the product’s performance, and therefore its correction may be delayed or completely excluded from backlog (task list). This bug is assigned the Won’t Fix status, after which it disappears forever from the field of view of developers. In some cases, bugs with this status are placed at the very end of the backlog. This means that the developers “get their hands on” to fix them only when all other tasks are solved.
But back to the already mentioned IT company. Its employees analyzed the entire list of detected bugs and sorted the problems found. Almost half of the errors were decided to be corrected in the near future, and more than half were assigned Won’t Fix status. All this work took about two months, after which the company decided to adopt Zero bug policy already on an ongoing basis. To date, this company has no more than 10 open tasks in the backlog. This allows you to focus on the implementation of new features.
Bug experts
ala experts what where when
How are bugs sorted? Who makes the decision that one error is critical and needs to be corrected, while on the other it is possible to continue to live in peace, or postpone its correction until later?
We will tell you how this process is organized using the concept of flexible project management (Agile). Everyone knows that Agile includes several techniques. We will take one of them as an example, namely SCRUM, since it is most often used in the world of software development.
The product owner or Scrum Product Owner is one of the key members of the project team. It is he who represents the interests of end users and makes every effort to maximize the value of the product. He is also responsible from the beginning to the end for the product backlog. The entire development team takes part in sorting bugs, but the last word is always for Product Owner. It determines which error will be fixed and which is marked as Won’t Fix.
In fact, everything is money. For example, if fixing a bug would not bring the company any financial return, but at the same time take a lot of time and resources, it would be better for such a bug to be assigned the Won’t Fix status and postpone fixing it until better times. In fact, the "owner of the product" is responsible for prioritizing and for the status of errors found.
In other words, everyone has “skeletons in the closet”. But if they do not have any effect on the performance of the product, do not impede the user’s actions, or hinder the integration processes, they can be completely ignored.
Selection criteria
cinderella picks rice from buckwheat
Such "minor" bugs are in the products of any developer.
For example, in the admin interface of the content management system it is impossible to enter a too long title for a section, article, etc. The developers decide not to fix this bug. After all, the correction takes time, resources, and you can just take and reduce the name to a certain number of characters. It is enough to simply warn the user that names longer than 30 characters are not supported.
The button is a little in the wrong color, interface elements located two pixels to the left of what is required – all these are errors that do not affect either usability or the performance of the application. Therefore, they can potentially be attributed to Won’t Fix.
Critical bugs are primarily those that are handled by many clients who lead or can lead to the fact that clients will lose money due to flaws in programmers. All this defines the Product Owner, who is obliged to know the product like the back of his hand, and not only to understand its functionality, but also to understand how business customers use it, what application scenarios exist in a particular company.
Collective mind
many brains come together in a common field
Zero Bug Policy is often associated with a Service Level Agreement (SLA). Typically, developers have several lines of technical support.
The first receives an error message from the user and collects all the necessary data for its reproduction and analysis, and then transfers all this information to the second line. The specialists of the second line reproduce this error on workstations or servers on which the same version of the product is installed as the user. If the error is reproduced, as the user claims, then information about it falls into the active sprint, that is, a list of tasks for developers.
The first and second technical support lines, as well as the developers, have SLAs. The more critical the bug, the stricter the SLA standards for fixing it. There is also a general SLA for troubleshooting: from customer contact to getting the corrected code in production. The decision on whether to assign the Won’t Fix status to the bug or not to assign it is made by the second line of technical support. However, her verdict is not final. First of all, its employees are guided by the principles and rules of the current sprint. In addition, there is a collection of expectations from developers, from customers, from the business development department.
If a controversial situation arises when all these factors are taken into account, then the last word will be precisely behind the second line of support and, of course, Product Owner.
Satisfied means productive
great human happiness
Why is all this a development company needs? One reason is the increased motivation of developers. Fixing bugs is a routine and unpleasant job, which not everyone likes to do. Implementing new features is much more interesting than fixing the mistakes of your colleagues. This increases productivity and productivity. Finally, in this way, without sacrificing quality, one can seriously save on the maintenance of testers, leaving one or two specialists in the company instead of a whole department.
Why do users and business customers need this? The business is developing, it is constantly facing new challenges that need to be addressed with the help of IT products. And if developers spend most of their time eliminating insignificant errors, rather than improving the functionality of their creations, they risk staying far behind their competitors. Business will choose those who are moving forward, while keeping the quality bar at a high level.
That's all. Read more about Equio Company can be found on their official website.
And on the Otus website you can familiarize yourself with our courses and visit your interests free webinars.
