In the course of dealing with defects, you often meet the need to pay attention to the requirement of a clearer formulation of the summary defect. And, over time, it repeats again and again. The same situation is observed in interviews with applicants for the position of testing engineer. Many companies pay little attention to this, but in a large project it can be a problem requiring solution.

So why do we write the wrong summary again and again?

First, there is no well-defined rule for constructing a summary. Everyone knows that it should be short and understandable and set up a person reading it for the correct perception of the actual description of the defect itself. Many agree that it must be unique in order to facilitate the search for duplicates, which in turn is a sign of the loss of team productivity, but at the same time everyone is wondering what the degree of uniqueness should be then. In general, duplicates can be born for three main reasons:

1. The summary of defects is mostly unclear. This leads to the fact that when searching for duplicates of its defect, the engineer can not recognize the defect by summary and is forced to often read a description of each such defect, which seriously increases the time of creation of each individual defect in the database. Therefore, most likely, he will not re-read the description carefully, so as not to reduce his productivity.
2. Engineers have not yet fully mastered the product itself and its associated subject area, and therefore create defects with various incomplete descriptions, but having the same source.
3. Incorrect planning of testing (for example, when the testing areas of 2 independent engineers overlap, and the search for duplicates is also complicated by reason No. 1).

In general, duplicates are quite a serious problem, leading to a decrease in the productivity of both the testing team and the programmers. Therefore, every reason must be eliminated separately. The ways of eliminating causes No. 2 and No. 3 are fairly obvious. The reason No. 2 is eliminated by additional trainings with formal time allocation for them when planning or in a natural way – engineers will eventually understand the product at a sufficient level themselves (the method of solution depends on the degree of influence of the cause on the problem). Reason number 3 is eliminated by more explicit planning of testing with explicit indication of the areas of responsibility of engineers at the points of integration of adjacent components). But the number one reason is systemic, and its elimination consists in the systematic assimilation of the rules for constructing summary, which should become part of your process and at the same time not complicate it, but simplify it.

Secondly, if the rules for building a summary are complex and fuzzy, they are partially or completely forgotten in the routine flow of tasks somehow or other.

Ways To Build a Summary

There are different ways to build a summary for today. Here, for example, two of them.

The first way:

1. Write down the description of the defect first.
2. Look at it carefully and select from it the key points.
3. Try to combine these key moments together.

The fact that you will end up as a result and will compile a summary of your defect.

The second way:

Write a description of the defect as follows:

1. Steps to play
2. Expected Result
3. The result obtained

If you have built the description correctly, the “Received result” will be the summary of your defect in general. If necessary, you can add the missing parts to it.

We suggest another way or the so-called “Where? What? When?” principle.

What is this principle?

Make an offer, in which the facts of the defect are stated in the following sequence:

1. Where ?: Where in the user interface or the architecture of the software product is the problem. And, start the sentence with a noun, not a preposition.
2. What ?: What happens or does not happen according to the specification or your view of the normal operation of the software product. In this case, indicate the presence or absence of the object of the problem, and not its content (it is indicated in the description). If the content of the problem varies, all known options are listed in the description.
3. When ?: At what point in the software product, at the onset of an event or under what conditions is the problem manifested.

Why should the sequence be exactly like this?

In this form unfamiliar defects are more conveniently sorted by summary as practice shows (after all, most likely, it is among the defects of other engineers that duplicates will be searched). If you are of a different opinion, come up with your own sequence, but it should become one for all members of the project without exception, otherwise you will not achieve the necessary result.

Here is an example of such a summary.

Let’s say you have a dialog “Convert Data” with the “Convert” button.

And when you press this button, you receive the error message “Error number …”.

Then the summary of the defect will consist of the following parts:

1. Where ?: The “Convert Data” dialog
2. What ?: the error message is displayed
3. When ?: when you click the “Convert”

The summary summary will be as follows:

The “Convert Data” dialog box displays an error message when you click the “Convert” button

All other parts must be indicated in the defect description.