Common Mistakes in Bug Reporting
On Habré, quite a lot has been written about good programming style, naming convention. And about the good style of writing bug reports?
Of course, defects are stored in the bug-tracking system, which imposes its limitations and requirements, of course, there are some internal corporate rules for reporting errors, but there is still a human factor, resulting in bugs that meet all the design rules, but absolutely incomprehensible even to fellow testers. A badly described bug can get a resolution Cannot reproduce and be forgotten, until it accidentally pops up at the customer.
In this article I will try to describe the main problems of error reports that I met during the year of working on a large project, as well as ways to improve them.
')
An example of such a bug: I can not create an account.
It seems the system is completely inoperable. What can be 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 iron. Problem: the spaceship does not fly.
Defects begin to be described as epic: All actions taken since the morning, and with maximum detail. After a couple of paragraphs, it bothers, and they finish it very briefly. Yes, there is a description of the problem, it is quite large, but completely useless both for the programmer who will fix it and for the tester who gets it for testing.
Yes, sometimes it is not obvious that this is really the same problem. But sometimes different manifestations of the same defect fall on different developers and then confusion begins.
Such bugs usually have only a title. The playback steps are a link to the test-case (by the way, it is possible that the programmer does not have access rights to such a resource), the expected result is the link (or attachment) of the 50-page documentation. The comment may be a postscript that the playback steps are described in detail in the defect number NNN. In addition - log. The whole. For all 2 weeks of testing. All 50 megabytes. Well, screenshots of each step bonus.
Yes, it happens. Rarely (in this and not the first in the list), but it happens
Example:
Title: Javascript error on the page. Next are the steps to get to this very page, but nowhere is the error message indicated and even no screenshots.
Abbreviated names of entities specific to a certain part of the system may not be clear even to people who have been working on a project for a long time. Also a large number of abbreviations in the text makes it difficult to understand. The time spent on the analysis of such a defect significantly exceeds the time that was saved on writing an error report. You can use common abbreviations and acronyms, but do not abuse it.
Comment from 57DeD : The most common (at least one of those I worked with) was not included in the list: “Your program is loading slowly, the icon is of the wrong color, an error happens while entering text, the menu item doesn’t tell me what - just - does not work. And the weather is also bad - it is raining. ” (Apparently, the developer is required to write Not Reproduced - the rain has already ended)
It seems to me that these recommendations can improve the quality of the description of bugs:
1 Correctly configure the required fields in the bug-tracking system, prohibit attachment of large files (if this is not a video playback error)
2. Similar to code-review: Sometimes ask colleagues to look at the newly created error report. Perhaps they will tell you what to add and / or exclude from the description of the bug.
3. Check the bag base before creating a new report - perhaps such a "beast" is already recorded.
4. The golden mean is needed everywhere. Try to write without skipping important steps, but not chewing on 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 the bug-tracking system, which imposes its limitations and requirements, of course, there are some internal corporate rules for reporting errors, but there is still a human factor, resulting in bugs that meet all the design rules, but absolutely incomprehensible even to fellow testers. A badly described bug can get a resolution Cannot reproduce and be forgotten, until it accidentally pops up at the customer.
In this article I will try to describe the main problems of error reports that I met during the year of working on a large project, as well as ways to improve them.
')
1. Very general header bugs
An example of such a bug: I can not create an account.
It seems the system is completely inoperable. What can be 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 specific version of the browser);
- Account created, but did not receive confirmation 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, a very brief description.
Example : I hammered a nail into a wall. Then he worked with bolts, nuts and sheet iron. Problem: the spaceship does not fly.
Defects begin to be described as epic: All actions taken since the morning, and with maximum detail. After a couple of paragraphs, it bothers, and they finish it very briefly. Yes, there is a description of the problem, it is quite large, but completely useless both for the programmer who will fix it and for the tester who gets it for testing.
3. For each error, create a separate bug report.
Yes, sometimes it is not obvious that this is really the same problem. But sometimes different manifestations of the same defect fall on different developers and then confusion begins.
4. A large number of attachments and links
Such bugs usually have only a title. The playback steps are a link to the test-case (by the way, it is possible that the programmer does not have access rights to such a resource), the expected result is the link (or attachment) of the 50-page documentation. The comment may be a postscript that the playback steps are described in detail in the defect number NNN. In addition - log. The whole. For all 2 weeks of testing. All 50 megabytes. Well, screenshots of each step bonus.
5. It is not indicated what the error is.
Yes, it happens. Rarely (in this and not the first in the list), but it happens
Example:
Title: Javascript error on the page. Next are the steps to get to this very page, but nowhere is the error message indicated and even no screenshots.
6. The use of specific abbreviations and abbreviations
Abbreviated names of entities specific to a certain part of the system may not be clear even to people who have been working on a project for a long time. Also a large number of abbreviations in the text makes it difficult to understand. The time spent on the analysis of such a defect significantly exceeds the time that was saved on writing an error report. You can use common abbreviations and acronyms, but do not abuse it.
7. About everything and about anything
Comment from 57DeD : The most common (at least one of those I worked with) was not included in the list: “Your program is loading slowly, the icon is of the wrong color, an error happens while entering text, the menu item doesn’t tell me what - just - does not work. And the weather is also bad - it is raining. ” (Apparently, the developer is required to write Not Reproduced - the rain has already ended)
It seems to me that these recommendations can improve the quality of the description of bugs:
1 Correctly configure the required fields in the bug-tracking system, prohibit attachment of large files (if this is not a video playback error)
2. Similar to code-review: Sometimes ask colleagues to look at the newly created error report. Perhaps they will tell you what to add and / or exclude from the description of the bug.
3. Check the bag base before creating a new report - perhaps such a "beast" is already recorded.
4. The golden mean is needed everywhere. Try to write without skipping important steps, but not chewing on obvious things.
5. And do not forget about the golden rule - write error reports so that you enjoy reading them
Source: https://habr.com/ru/post/156069/
All Articles