04. Bug and Incident Management

Incident management is a basic point of efficiency within a development team. From how bugs are managed, it’s easy to tell whether or not an organization’s testers and developers feel as if they are a part of the same team, with the same goals. This assertion is not only aimed at developers, urging that they collaborate better with testers, but also at testers. Testers should avoid complaining (as they sometimes do) when a bug they reported doesn’t get fixed and must understand that not everything needs to be fixed, depending on the team’s global vision.

One poor incident management practice that we always find irksome at Abstracta is that with the hundreds of tools available for incident management, some teams still choose email as the designated channel for reporting bugs. Or worse, not using anything at all, and the tester simply taps the developer on the shoulder after finding a bug.

What’s the problem with reporting bugs without recording them with an adequate tool?

Basically, it’s impossible to follow up, keep a record, know the status of each incident (if it was already solved, verified, etc.), or even, if there’s a team of testers, have it clear what things were already reported by another tester that shouldn’t be reported again.

Of course, even when using an incident management tool, there will still be a need to speak face to face, but they do aid in adding clarification. For example, one can comment on and show directly, in the moment, what happened and thus communicate more effectively.

The following scheme summarizes a possible life cycle of a bug (there could be a thousand variations of this according to the team’s structure, size, etc).

One of the most typical mistakes in incident management that our team has seen while working with different companies across traditional and Agile environments has to do with the moment when a bug is deemed “fixed” and the developer marks it as closed.

It is important to remember that the tester must double check that a bug has been properly fixed before closing it!

First, the tester reports it and then the developer fixes it, but the person who should ultimately determine if it has been resolved is the tester that reported it in the first place. What if the developer thinks it’s gone, but upon further testing, it is still there? What if a new bug has been created in its place? A tester should always go back and check that the bug no longer exists in order to minimize risk.

There are several other valid variations of this scheme. For example, there could be someone with the responsibility of reviewing the incidents that come in and deciding which ones to fix and which ones not to fix. This situation could work within the flow above, whether it be the tester or the developer who marks a bug as “resolved,” “won’t fix,” or through a dialogue (via the tool or a different medium), both the tester and developer could decide together what is the appropriate decision, showing mutual agreement between the two.

At this point you may be wondering, “Why is this important for continuous testing?” As stated before, this is the main point of interaction between testers and developers, whether they are under the same roof, or in distant countries. Moreover, there are tools like Jira that allow traceability among the issues reported in the tool and code, which, in order to make the most of these features, everything must be well mechanized.

The most mature testing teams have a perfectly oiled incident resolution machine, (using a designated incident management tool) as the greatest interaction between testers and developers is in the back and forth of these mechanisms.