Common mistakes when compiling bug reports
On Habré a lot has been written about a good programming style, naming convention. And what about a good writing style for bug reports?
Of course, defects are stored in a bug tracking system, which imposes its limitations and requirements, of course, there are some internal rules for creating error reports, but still there is a human factor, as a result of which there are bugs that meet all the design rules, but absolutely incomprehensible even to fellow testers. A poorly described bug can get the Cannot reproduce resolution and be forgotten until it accidentally pops up at the customer.
In this article, I will try to describe the main problems of error reporting that I met during the year of work on a large project, as well as ways to improve them.
An example of such bugs: I can not create an account.
The system seems to be completely inoperative. What may happen with a more detailed study of the problem:
By the way, all these details (browser version, localization) in the playback steps may not be indicated.
Example : I hammered a nail into a wall. Then he worked with bolts, nuts and sheet metal. Problem: the spaceship does not fly.
The defect begins to be described as an epic: All actions taken in the morning, and with maximum detail. After a couple of paragraphs this bothers, and is added very briefly. Yes, there is a description of the problem, it is quite large, but completely useless to both the programmer who will fix it and the tester who will be tested.
Yes, sometimes it’s not obvious that this is really the same problem. But sometimes different manifestations of the same defect fall on different developers and then the confusion begins.
Such bugs usually have only a header. The playback steps are a link to the test-case (by the way, perhaps the programmer does not have access rights to such a resource), the expected result is the link (or attachment) of the 50-page documentation. In the commentary there may be a note that the playback steps are described in detail in defect No. NNN. As a complement - a log. All. For all 2 weeks of testing. All 50 megabytes. Well, screenshots of each step are a bonus.
Yes, it happens. Rarely (and therefore not the first in the list), but it happens
Example:
Title: Javascript error on the page. Next are the steps to get to this page itself, but the error message itself is not indicated anywhere and there are not even screenshots.
The abbreviated names of entities specific to a certain part of the system may not be clear even to people who have been working on the project for a long time. Also, a large number of abbreviations in the text makes it difficult to understand. The time taken to analyze such a defect significantly exceeds the time that was saved on writing a bug report. Common abbreviations and acronyms may be used, but do not abuse it.
Comment from 57DeD : The most common (at least of the ones I worked with) grief bug report didn’t enter the list: “Your program loads slowly, the icon is not in the same color, an error occurs when entering text, the menu item will not tell you which - Namely - does not work. And the weather is also bad - it is raining. ” (apparently, the developer needs to write Not Reproduced - the rain is already over)
It seems to me that these recommendations can improve the quality of the bug description:
1 Correct the required fields in the bug tracking system, prohibit attaching large files (if this is not an error video)
2. By analogy with code-review: Sometimes ask colleagues to look at a freshly generated error report. Perhaps they will tell you what to add and / or exclude from the description of the bug.
3. Check the bugbase before creating a new report - perhaps such a "beast" has already been recorded.
4. A middle ground is needed everywhere. Try to write without missing important steps, but also without chewing the obvious things
5. And do not forget about the golden rule - write error reports so that you enjoy reading them
Of course, defects are stored in a bug tracking system, which imposes its limitations and requirements, of course, there are some internal rules for creating error reports, but still there is a human factor, as a result of which there are bugs that meet all the design rules, but absolutely incomprehensible even to fellow testers. A poorly described bug can get the Cannot reproduce resolution and be forgotten until it accidentally pops up at the customer.
In this article, I will try to describe the main problems of error reporting that I met during the year of work on a large project, as well as ways to improve them.
1. Very general header bugs
An example of such bugs: I can not create an account.
The system seems to be completely inoperative. What may happen with a more detailed study of the problem:
- Such an account already exists (or invalid characters are entered in the account name), and the problem is that the error message did not appear (it is possible that only on a certain version of the browser);
- An account has been created, but no confirmation has been received by mail;
- Other options.
By the way, all these details (browser version, localization) in the playback steps may not be indicated.
2. Very detailed pre-steps, very brief description.
Example : I hammered a nail into a wall. Then he worked with bolts, nuts and sheet metal. Problem: the spaceship does not fly.
The defect begins to be described as an epic: All actions taken in the morning, and with maximum detail. After a couple of paragraphs this bothers, and is added very briefly. Yes, there is a description of the problem, it is quite large, but completely useless to both the programmer who will fix it and the tester who will be tested.
3. For each manifestation of an error, create a separate bug report
Yes, sometimes it’s not obvious that this is really the same problem. But sometimes different manifestations of the same defect fall on different developers and then the confusion begins.
4. A large number of attachments and links
Such bugs usually have only a header. The playback steps are a link to the test-case (by the way, perhaps the programmer does not have access rights to such a resource), the expected result is the link (or attachment) of the 50-page documentation. In the commentary there may be a note that the playback steps are described in detail in defect No. NNN. As a complement - a log. All. For all 2 weeks of testing. All 50 megabytes. Well, screenshots of each step are a bonus.
5. It is not indicated what exactly the error is.
Yes, it happens. Rarely (and therefore not the first in the list), but it happens
Example:
Title: Javascript error on the page. Next are the steps to get to this page itself, but the error message itself is not indicated anywhere and there are not even screenshots.
6. Use of specific abbreviations and abbreviations
The abbreviated names of entities specific to a certain part of the system may not be clear even to people who have been working on the project for a long time. Also, a large number of abbreviations in the text makes it difficult to understand. The time taken to analyze such a defect significantly exceeds the time that was saved on writing a bug report. Common abbreviations and acronyms may be used, but do not abuse it.
7. About everything and about nothing
Comment from 57DeD : The most common (at least of the ones I worked with) grief bug report didn’t enter the list: “Your program loads slowly, the icon is not in the same color, an error occurs when entering text, the menu item will not tell you which - Namely - does not work. And the weather is also bad - it is raining. ” (apparently, the developer needs to write Not Reproduced - the rain is already over)
It seems to me that these recommendations can improve the quality of the bug description:
1 Correct the required fields in the bug tracking system, prohibit attaching large files (if this is not an error video)
2. By analogy with code-review: Sometimes ask colleagues to look at a freshly generated error report. Perhaps they will tell you what to add and / or exclude from the description of the bug.
3. Check the bugbase before creating a new report - perhaps such a "beast" has already been recorded.
4. A middle ground is needed everywhere. Try to write without missing important steps, but also without chewing the obvious things
5. And do not forget about the golden rule - write error reports so that you enjoy reading them