Bug-report: about using «incorrect» words

No doubts, a good bug report is a high quality document. Writing a bug report is an important task, because that’s the main point of communication between a tester, the developer and the project management. A well-written bug report will not only create a good relationship/relations between you and the developers, but will also save company resources to work with it.

Moreover, a good bug report must consist of a correctly written Summary. As a rule, the Summary consists of 150 characters or less. It is important to ensure that the Summary fully answers the following questions: What is the problem? Where and when is the problem reproduced?

It is also essential to understand that while writing the Summary  you need to clearly indicate the nature of the problem - in other words, to specify what exactly does not work. That is why it is not necessary to use words that describe the problem abstractly, without concretization, for example, nothing happens, incorrectly/correctly displayed, works wrong/right etc.

Here are some of the examples of the incorrect Summary:

1. Nothing happens after going to the page.
2. The «About company» section is displayed incorrectly.

Describing a bug in this way, the essence is completely incomprehensible, and, accordingly, it will be difficult to determine what to pay attention to and what exactly needs to be fixed.

The work of a programmer and a tester is a complex and interconnected process. Very often bugs introduced by a tester are corrected by developers «on the go». Therefore, the «incomprehensibly» described bug leads to a painful waste of time on understanding and reproducing it and as a result, to the loss of budget funds.

We can suggest a certain algorithm of actions to write a good Summary:

1. Understand the problem! Before writing a summary it is necessary for a tester to have a clear understanding of what the error is. 
2. Describe the error in details, taking into account all specifics of its reproduction. 
3. Remove all the unnecessary information, for example, the conditions that are not obligatory for the error existence, correct important details. 
4. Write the sentence according to «What? Where? When?» principle.
5. Check the sentence for compliance with the grammatical rules of the language in which the Summary is written. 
6. Shorten the length of the sentence, if it turns out to be too long. You can use synonyms, shortenings or commonly accepted abbreviations.

Based on the information above, here are  some examples of the correct Summary:

1. The blank page is displayed in the «Our projects» section after clicking the «Our projects» button.
2. Navigation buttons are not displayed in the «About the Company» section.

But, of course, in the process of testing there can be bugs that are impossible to describe clearly, for example:

( The «Calculator» app makes wrong calculations after various arithmetic operations).

Wrong calculations are made in the «Calculator» app after various arithmetic operations. 

In this case ,it is quite possible to determine what exactly the bug is. The tester can only see that the results given are clearly different from the expected ones. Therefore in such cases the bug is described in the «global» sense. But it is clear that the problem is hidden in some part of the code, (that) which affects the final result. That’s why in such bugs we allow the use of those very «forbidden words».

Besides, we can describe this problem in more detail in the extended description

For example, in the Summary and Actual result we indicate:  «The message about mistake is not shown in the postal address input field after entering the postal address without «@» symbol or without using the domain name»  

And in the Description we indicate that this situation is reproduced when trying to confirm with the empty field, when entering an email address without the «@» symbol or without using a domain name.

Thus, we do not lengthen the Summary of the bug, but at the same time we specify in what conditions the bug is reproduced. 

Also, do not forget that while writing the  bug report it is customary to indicate the same Actual result as the Summary, and in the Expected result - what should be displayed in the tester’s opinion. Describing the results ,the same rule as when creating the Summary is used (according to the What? Where? When? principle).

Examples of the correct formatting of the expected result:

1. The content is displayed in the «Our projects» section after clicking the «Our projects» button.
2. The navigation buttons are displayed in the «About the company» section.

It often happens that the use of incorrect words is allowed when compiling a checklist, but not while describing a bug. 

The difference is that when compiling a checklist, one can refer to the provided product layouts. However, often during the development process, the design of an application or a site can change , therefore, specifying the section location will only be harmful.

For example, the description of the «Products» section is displayed in the upper right side of the screen. 

If after that, it is moved to the left side, then the tester will consider it as a bug. 

So without specification, it will be enough to check the actual layout to confirm the correct location of the section.Therefore the description «The «products» section is displayed correctly on the screen» is valid.

You do not have to compare the correct spelling of a checklist and a bug. These are different documents that fulfil the task assigned. Something that works for one, is completely unacceptable for another. The checklist’s task is to describe the behavior as briefly as possible. 

In the bug report you need to accurately indicate the problem at the moment of testing.

The description «The «Products» section is displayed incorrectly on the page» does not describe the essence of the problem. 

The task of a good bug report is to describe the problem as clearly as possible and understandable not only for another tester, but for a person who is completely unfamiliar with the product. Therefore, it is important to indicate what is the reason for the incorrect behavior there. 

One of the option is to specify that «The «Products» section is cut by the borders of the screen/browser window on the page»

Everything will depend on the specific situation in which the bug is reproduced.

What exactly is the «incorrectness» of this bug? It is unclear from the description of the Summary what is the problem. Whether the sentence is outside the block or it is cut or written in the wrong format, or it contains grammatical or lexical mistakes. 

Bug is not a puzzle that the customer must solve. A good bug example is when a customer does not even need to watch a video or screenshot to understand the problem.

Again, as indicated above, there are acceptable options when enumeration of the incorrect values is time-consuming and it is better to write them down in the Description. In this case, the ‘’incorrect» words can be used. 

But in other situations, you still need to specify the problem. 

Here is another example of an «incorrect» description: 

«The table of contents is written incorrectly on the page.

Summing it up, it is necessary to understand that the quality of the completed bug report reflects the professional level of the tester and how competently it will be formed up - will directly affect the project final result. It is important to distinguish between situations in which the use of «incorrect» words is acceptable and in which is not. The best way to look at a bug from the side of a person who will read it and try to reproduce it. Do not forget that finding a bug is only a part of the done work. The correctness of its design is equally important.