Effective Bug Report: Difference between revisions
| Line 79: | Line 79: | ||
=Expected Result= | =Expected Result= | ||
Describe the expected result after performing the last step to reproduce the bug. Be specific and detailed about what should have happened if everything had worked correctly. | Describe the expected result after performing the last step to reproduce the bug. Be specific and detailed about what should have happened if everything had worked correctly. | ||
Don’t just leave it at “the app is crashing, and it shouldn’t.” | |||
=Attachments (visual proofs of Bug such as screenshots, videos, logs)= | =Attachments (visual proofs of Bug such as screenshots, videos, logs)= | ||
Revision as of 20:00, 15 June 2023
An effective bug report should contain the following:
Bug ID
Title/Summary
Preconditions
Steps to reproduce
Expected Result
Actual Result
Attachments (visual proofs of bug such as screenshots, videos, logs)
Environment
Severity/Priority
Status
Date of creation
Additional information about a bug can be added if needed
Bug ID
Each bug should be given a unique identification number. Bug reporting tools automatically provide a unique number to the newly raised bugs. This field helps to identify the bug easily.
Title/Summary
A summary of the issue should be provided. The summary should be a concise statement that helps to identify the problem. Bug titles should be easy to understand, which would help identify the issue quickly. Try to briefly answer 3 questions: "What? Where? When?"
Preconditions
Provide some precondition steps before going to actually main flow, sometimes it is skipped as steps also mentioned in step to reproduce. Usually the precondition is picked from the relevant test case to save time of writing bug report.
Steps to reproduce
Steps are detailed instructions for the developer to follow in order to reproduce the bug. Just like assembling a chair purchased from the store, the instructions have to be in order and specific. If a step in the bug report is missing, there is a chance that the developer will not be able to reproduce the bug in order to fix it.
Here is an example:
Steps to reproduce:
1. Open https://bloomex.ca
2. Go to the “Lost password” page
3. Enter a valid email
4. Click on the “Send” button
Actual Result
Detail what the bug is actually doing, and how it is a distortion of the expected result.
Elaborate on the issue
Is the software crashing?
Is it simply pausing in action?
Does an error appear?
Or is it simply unresponsive?
Specificity in this section will be most helpful to developers. Emphasize distinctly on what is going wrong. Provide additional details so that they can start investigating the issue with all variables in mind. For example:
“Link does not lead to the expected page. It shows a 404 error.”
“When clicked, the button does not do anything at all.”
“The main image on the homepage is distorted on the iPhone X.”
Expected Result
Describe the expected result after performing the last step to reproduce the bug. Be specific and detailed about what should have happened if everything had worked correctly. Don’t just leave it at “the app is crashing, and it shouldn’t.”