Of course, a well-done bug report is a documentation of the highest quality. Creation of a first-rate bug report is a very important task because it is the main point of communication between QA specialists, managers, developers, and clients (in some ways). A well-done bug report doesn’t only make the interaction between the tester and developer better, but also saves all the company’s resources which have the task to create, modify and use it.
Additionally, a good bug report must have a well-written topic (Summary). Usually, a summary consists of about 120-150 symbols. It’s important to check if the created summary answers fully such questions: where’s the problem? How and under what circumstances is it reproduced?
Also, it’s important to understand, that while working with the problem, one should show the nature of the problem, – in other words, what exactly is working IMPROPERLY. It means, that tester shouldn’t use words and phrases which describe the problem lightly, figuratively, without detailed info, for example, nothing appears, works improperly, is set incorrectly and so on.
Examples of the incorrect description of a defect in a bug report
- Nothing happens when going to some page;
- Text block “About us” is displayed incorrectly.
If you write the bug description in such a way, the matter and message, which has to get one’s attention, won’t be clear. It will be hard to understand what exactly is working incorrectly and if it’s possible to fix this.
Work of QA specialist and developer is maximally complex and mutually reinforcing process. Sometimes it can happen, that those bugs which a tester mentions in the bug report, are being fixed by programmers in the process. It means, the bug that was described really complicatedly, leads to a big waste of time on its realizing and the next reproducing. As a result, the company loses some money under one project.
We can determine a special algorithm of actions, in the process of writing a really correct and useful Summary:
- Understand the origin of the problem personally! Before creating a Summary, QA specialist must see clearly where exactly the bug (defect) can be;
- Describe the bug in great detail, taking into account all details of its steps of reproduce;
- Delete all extra info from the description, for example, unnecessary conditions for appearing bug, specify all important details;
- Set all sentences in a logical order – What? Where? When?
- Check sentences for the compliance with all grammar rules;
- Shorten the sentence, if it’s too long. For example, you can use synonyms, some acronyms or common abbreviations.
Taking into account all, listed above, the good examples of great Summary are:
- There’s an empty page in the “About the company” section, after clicking the “About us” button;
- Navigation buttons aren’t seen in the “About us” section.
Naturally, sometimes during testing, QA specialist can find defects, which are difficult or impossible to describe, for example:
- “Calculator” program gives wrong calculations after different arithmetic operations.
In such a situation it is hard to see what exactly the defect is. QA specialist only sees that result, he/she has got, is quite different from the expected one. That’s why if such situations happen, a defect is described in a “global” understanding. But it’s clear from the very beginning that bug is located in the hidden part of the code, which influences a final result. Because of it, a tester can use only some “forbidden words” in a bug report.
Moreover, it’s possible to describe the problem in more extended form.
For example, in a Summary and an actual result, QA specialist can write: “A message about the bug isn’t shown in the E-mail address input field after the user enters the incorrect data”.
But in the main description, we say that such a situation is reproduced in the process of data verifying with the empty field after the e-mail address was entered without @ symbol or domain name.
So, we don’t make a defect Summary longer, but at the same time, we specify maximally the conditions that lead to a bug displaying.
Also, we shouldn’t forget that during a bug report creation, we mention the same info in actual result description and the Summary; but in the expected result description, we show what exactly should be displayed by QA specialist’s opinion. When we describe the results, we use the same rule as during the Summary field filling (with the logic – what? Where? When?).
Here’re examples of the correct description of Expected results:
- Content in the “Our services” section is displayed after clicking on the “About company” button;
- The block of navigation buttons is displayed in the “About us” page.
Sometimes the incorrect words and phrases are used during the check-list development, but not in the defect description.
The difference is, that working on a check-list, one can make reference to the developed project models. Design and functioning logic of the software can change several times during its development, so bug localization can harm this and further projects.
For example, the description “The “products” section is displayed in the top of the browser viewport”.
If the block is moved the bottom left part after this, a tester can consider it as a bug.
But without specifics, it’ll be enough to check an actual model to verify that the block is displayed correctly.
It’s necessary to write in the bug report about the problem at the time of test performing
A description like “The “Production” section is displayed on the page incorrectly” doesn’t describe the matter of the defect inside some part of the tested product. The prior task of a qualitative bug report is to describe the bug from the most intelligible and correct side in order to make it clear for both: the tester of this software and QA specialist, who isn’t familiar with details of this project.
It means, that this is really important to show what the impropriety of the system’s behavior is.
Also, you can write such a message: “The “Production” sectional is displayed only on the part of the page (bottom part of the block is cut by screen’s and/or browser’s sides)”.
It depends on the situation when such a defect can be reproduced.
There’re a lot of variations when a list of incorrect meanings occupies much space, and it will be better to place a defect description in the expanded part. Only in such a case, the group of “incorrect words” can be used.
But in most cases tester must specify the problem as qualitatively as it’s possible.
Here’s another example of incorrect bug description:
«Page description is done incorrectly».
Why such a bug description is wrong? From this Summary, we can’t see what exactly the bug is. Is the texting part wider than a visible viewport (there’s a horizontal scroll bar)? Is it cut by half or done in the wrong format? Or maybe it has some grammar mistakes.
A bug – is not a riddle that a developer should solve. The perfect example of the bug is when the programmer doesn’t need to look at the screenshot or video to understand the matter of defect.
In conclusion, we can say that the quality of created bug report influences many things such as professional level of QA specialist, how quickly the developers can understand the problem, etc. It’s important to see and distinguish situations when the usage of incorrect words and phrases is acceptable and when it will be better to avoid them. The best way is to look at the bug report as a person who isn’t a professional IT specialist and has a vague image about implemented functionality. Also, we shouldn’t forget that process of finding a bug is only a part of work during the project development. But at the same time, its correct and accurate description is as important as some part of software creation.