How to make bug reports
The answer to the topic "Common errors in the preparation of bug reports . "
The rules for creating entries in the bug tracker in each company are different - it depends on the company’s policy, the development technology used by the bug tracker, the type of project and much more. But in any case, a good bug report has certain characteristics.
In short, a good bug report allows you to:
1. reproduce the problem (it is not always possible, but we must strive).
2. understand what the problem is and what is its importance.
')
How to write a good bug report?
First you need to prepare. If you find a bug, do not instantly run into the bug tracker and write "nothing works!". Reproduce the error. Reproduced? Fine. Not reproduced? So, something you did not consider. Remember what you did.
Reproduced again? Hooray! And now minimize the number of steps to play, make sure that there is nothing superfluous.
If any input data is used, make sure that they do not contain too much (does the editor really drop this whole hefty piece of text, and not one character from it?).
When you understand exactly what data and what your actions lead to the problem, briefly formulate its essence - think up the title of the bug report. Describe the problem in as much detail and as specific as the title allows, without being carried away by its length :)
An example of a bad headline: “Everything hangs when I paste text from the clipboard”
An example of a “better” title: “The editor freezes when pasting text containing the character N from the clipboard with Ctrl + V”
Allenary : You can still mention the principle of “What? Where? When?". In most cases, it helps to write a good title / detailed description, for example,
What: incorrect data calculation
Where: on the NNN page
When: after entering and the field Y is a negative value.
Try not to write phrases like “I click on the link”, “I press the button” and the like. Both the title and steps descriptions are a guide to action for those who will correct the problem, so it is better to formulate how to click on the link, click on the button.
Now open the bug tracker, start filling out the bug report form.
Write down the title .
In some bug trackers, the “Detailed Description” and “Steps to Playback” fields are different, in some they are not.
If the “ Detailed Description ” field is present, describe the problem in more detail in it - specify those details that you had to omit in the title. If you understand the cause of the problem (the outdated formula is used for calculations, some value is not taken into account, etc.) - write everything here too. If you do not know - better not guess.
If there is no separate Affect version field in the error record form, then indicate the version here.
" Steps to play " - the main field to fill in the bug report.
Record the steps you identified. As already mentioned, steps must be necessary and sufficient to reproduce the problem. Do not write extra. Necessary, too, do not miss :)
After describing the steps, be sure to write the result - what happened.
Further here describe the expected result, if necessary. Of course, you should not write "The editor does not fall," but if, for example, the results of calculations do not correspond to the expected ones, then this should be indicated.
Thus, the description of the steps to play should look something like this:
If you need source files, data, dumps, etc. - immediately attach. Of course, files should contain only the information necessary to reproduce the error. Clean up all unnecessary.
If the problem is with visual display, then the screenshot is required - it will be possible to understand the error without reproducing steps. Khizhnyak : In the screenshots, it is better to indicate the place with an error. Arrow or just a stripe of a contrasting color. Great accelerates the "reading" of the screenshot.
But it’s completely unnecessary to insert screenshots into every bug report: please do not produce unnecessary entities. If it does not help in reproducing the problem - do not waste time on its manufacture.
By the way, about the video playback error: it can help except to confirm that the problem really is, just to reproduce it is difficult. But how often do you record the screen in advance? :)
For the rest of the fields.
Severity, Priority.
The presence of these fields and the values ​​in these fields differ from bugtracker to bugtracker.
Severity is a bug's criticality from the point of view of a tester: a feature, a typo in the text, a minor problem, a significant problem, a product crash, a blocking problem, etc.
Priority - the priority with which the problem should be fixed.
If there are both fields, then the tester, as a rule, exposes only Severity, and Priority - the senior tester / senior programmer / manager or any other person responsible for this business.
If there is only one field, then expose it.
“What is the priority to put the bug?” There is no definite answer to this question, it all depends on each specific case. But try not to get carried away and not to put all the bugs in a row high or critical priority, really assess their criticality for the project.
Environment - is in all bug trackers. This is the software and hardware environment in which the problem manifests itself.
Specify the version of the operating system, the availability of service packs, bit depth.
If your project depends on some components - their presence and version is required! .NET, JRE / JDK and other SDKs.
Interpreted language? The interpreter version is a must!
For web projects - the browser, installed plugins, if it affects the work of the project. If something does not work in one browser, then check if it works in others.
In which version to fix, to whom to appoint - depends on the policy within the company. Do not know what to put? Ask a colleague.
The article is supplemented with correct comments from the comments.
The rules for creating entries in the bug tracker in each company are different - it depends on the company’s policy, the development technology used by the bug tracker, the type of project and much more. But in any case, a good bug report has certain characteristics.
In short, a good bug report allows you to:
1. reproduce the problem (it is not always possible, but we must strive).
2. understand what the problem is and what is its importance.
')
How to write a good bug report?
First you need to prepare. If you find a bug, do not instantly run into the bug tracker and write "nothing works!". Reproduce the error. Reproduced? Fine. Not reproduced? So, something you did not consider. Remember what you did.
Reproduced again? Hooray! And now minimize the number of steps to play, make sure that there is nothing superfluous.
If any input data is used, make sure that they do not contain too much (does the editor really drop this whole hefty piece of text, and not one character from it?).
When you understand exactly what data and what your actions lead to the problem, briefly formulate its essence - think up the title of the bug report. Describe the problem in as much detail and as specific as the title allows, without being carried away by its length :)
An example of a bad headline: “Everything hangs when I paste text from the clipboard”
An example of a “better” title: “The editor freezes when pasting text containing the character N from the clipboard with Ctrl + V”
Allenary : You can still mention the principle of “What? Where? When?". In most cases, it helps to write a good title / detailed description, for example,
What: incorrect data calculation
Where: on the NNN page
When: after entering and the field Y is a negative value.
Try not to write phrases like “I click on the link”, “I press the button” and the like. Both the title and steps descriptions are a guide to action for those who will correct the problem, so it is better to formulate how to click on the link, click on the button.
Now open the bug tracker, start filling out the bug report form.
Write down the title .
In some bug trackers, the “Detailed Description” and “Steps to Playback” fields are different, in some they are not.
If the “ Detailed Description ” field is present, describe the problem in more detail in it - specify those details that you had to omit in the title. If you understand the cause of the problem (the outdated formula is used for calculations, some value is not taken into account, etc.) - write everything here too. If you do not know - better not guess.
If there is no separate Affect version field in the error record form, then indicate the version here.
" Steps to play " - the main field to fill in the bug report.
Record the steps you identified. As already mentioned, steps must be necessary and sufficient to reproduce the problem. Do not write extra. Necessary, too, do not miss :)
After describing the steps, be sure to write the result - what happened.
Further here describe the expected result, if necessary. Of course, you should not write "The editor does not fall," but if, for example, the results of calculations do not correspond to the expected ones, then this should be indicated.
Thus, the description of the steps to play should look something like this:
Steps to play:
1. Open ...
2. Click ...
3. Enter in the field ... the value of N1
4. Enter in the field ... the value of N2
4. Click the Calculate button
Result:
The Result field displays V1 .
Expected Result:
The Result field displays V2 .
If you need source files, data, dumps, etc. - immediately attach. Of course, files should contain only the information necessary to reproduce the error. Clean up all unnecessary.
If the problem is with visual display, then the screenshot is required - it will be possible to understand the error without reproducing steps. Khizhnyak : In the screenshots, it is better to indicate the place with an error. Arrow or just a stripe of a contrasting color. Great accelerates the "reading" of the screenshot.
But it’s completely unnecessary to insert screenshots into every bug report: please do not produce unnecessary entities. If it does not help in reproducing the problem - do not waste time on its manufacture.
By the way, about the video playback error: it can help except to confirm that the problem really is, just to reproduce it is difficult. But how often do you record the screen in advance? :)
For the rest of the fields.
Severity, Priority.
The presence of these fields and the values ​​in these fields differ from bugtracker to bugtracker.
Severity is a bug's criticality from the point of view of a tester: a feature, a typo in the text, a minor problem, a significant problem, a product crash, a blocking problem, etc.
Priority - the priority with which the problem should be fixed.
If there are both fields, then the tester, as a rule, exposes only Severity, and Priority - the senior tester / senior programmer / manager or any other person responsible for this business.
If there is only one field, then expose it.
“What is the priority to put the bug?” There is no definite answer to this question, it all depends on each specific case. But try not to get carried away and not to put all the bugs in a row high or critical priority, really assess their criticality for the project.
Environment - is in all bug trackers. This is the software and hardware environment in which the problem manifests itself.
Specify the version of the operating system, the availability of service packs, bit depth.
If your project depends on some components - their presence and version is required! .NET, JRE / JDK and other SDKs.
Interpreted language? The interpreter version is a must!
For web projects - the browser, installed plugins, if it affects the work of the project. If something does not work in one browser, then check if it works in others.
In which version to fix, to whom to appoint - depends on the policy within the company. Do not know what to put? Ask a colleague.
The article is supplemented with correct comments from the comments.
Source: https://habr.com/ru/post/156099/
All Articles