đź’ˇ Short Summary - This is basically the title of the bug. This field is mandatory in all bug reports and it has to contain a short but accurate description of the bug. The best way to think of this summary is as effect and cause: what exactly is the problem and what causes it.
Examples:
“The app crashes when tapping the Settings button”
“Tapping on Forgot my password leads the user to an error page”
“The Try Again button is incorrectly displayed”
“Wrong message is displayed after login with the provided credentials”
💡 Actual Results - The “Actual Results” field should be where you give context to the summary. Not all bugs are straightforward and they might require more information about the conditions in which they are produced. The simple version should also contain the cause and effect format.
In 95% of all bugs, the perfect “Actual Results” entry should look something like this “When the user [performs action], then he will notice that the [effect occurs]”
Examples:
“When the user launches the app he will notice that the loading screen is improperly displayed.”
“When the user taps on the Settings button in the Main Menu screen he will notice that the app crashes.”
đź’ˇ Special Mentions: In this field, you should also include the location of the screen/menu in which the issue occurs and any additional notes. Additional notes are any modifiers that influence the issue in any way.
For example:
“Please note that this issue only occurs in the Main Menu, and does not occur in the Settings Menu”
“Please note that this issue only occurs when the user is logged in with a premium account”
“Please note that this issue only occurs under poor internet conditions”
Etc.
💡 Expected Results - The “Expected Results” field should contain the normal state of the app. In other words, it should be a description of what is the intended behavior in that situation.
Examples:
“The app should not crash when trying to log in with a valid account”
“User agreement should be displayed with the appropriate content”
💡 Component - The “Component” field varies in relation to the Test Cycle. For some, the “Component” field will refer to the location of the issue, in others to the type of test or major sections of the app. The information regarding these can easily be found in the Tester Spec document of each cycle and when reporting the issue it will usually be displayed in the form of a drop-down menu from which you can select the appropriate choice for your bug report.
💡 Reproducibility/Repro Rate - Any field that has the keyword “Repro” refers to how many times and in what conditions can a bug be reproduced. The field can be either a drop-down menu or a text field. What you should remember is that each issue needs to be tested several times in order to measure its reproducibility.
An issue can occur only once, always or seldom. That is why the minimum number a tester should try and reproduce the issue is 5. The repro, therefore, should be at least 1 out of 5 for any issue. bugs that only happen once are hard to prove and therefore most do not get accepted without an adequate proof (video evidence and/or logs). That is why you should try and narrow down the steps that lead to the bug and find out how you can trigger it repeatedly.
đź’ˇ Severity - This will give you the option to choose the severity of the issue between these 4 options: Critical, High, Medium and Low.
For more information about the correct severity of a bug please read ahead to the next chapter.
Comments
0 comments
Article is closed for comments.