Effective Bug Report: Difference between revisions
| Line 35: | Line 35: | ||
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?" | 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?" | ||
= | =Precondition= | ||
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. | 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. | ||
Revision as of 16:12, 28 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?"
Precondition
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.”
Attachments (visual proofs of bug such as screenshots, videos, logs)
It is standard practice to attach files to bug reports because it's easier to perceive information when it is displayed visually.
For example:
- Screenshot (it's convenient when the bug is highlighted with a circle or an arrow),
- Video (sometimes it could be difficult to describe the bug in words, so it's better to see it for yourself).
- Log-file.
Testing using BrowserStack can leverage multiple debugging options – text logs, visual logs (screenshots), video logs, console logs, and network logs. These make it easy for QAs and devs to detect exactly where the error has occurred, study the corresponding code and implement fixes.
Environment
A bug can appear in a particular environment and not others. For example, a bug appears when running the website on Firefox, or an app malfunctions only when running on an iPhone X. These bugs can only be identified with cross browser testing or cross device tests.
When reporting the bug that reproduces on specific environments QAs must specify it.
Severity/Priority
Every bug must be assigned a level of severity and corresponding priority. This reveals the extent to which the bug affects the system, and in turn, how quickly it needs to be fixed.
Levels of Bug Priority:
Low: Bug can be fixed at a later date. Other, more serious bugs take priority
Normal: Bug can be fixed in the normal course of development and testing.
High: Bug must be resolved at the earlier than task with less priority
Urgent: Bug must be resolved as soon as possible with current situation
Immediate: Bug must be resolved at the earliest as it affects the system adversely and renders it unusable until it is resolved.
Levels of Bug Severity (not necessary for now to note):
Low: Bug won’t result in any noticeable breakdown of the system
Minor: Results in some unexpected or undesired behavior, but not enough to disrupt system function
Major: Bug capable of collapsing large parts of the system
Critical: Bug capable of triggering complete system shutdown
Status
When a new defect is logged and posted for the first time. It is assigned a status as NEW.
In progress - developer take bug to fix.
Test - bug is ready to test for QA.
Closed - bug fixed.
Date of creation
The date the bug report was created makes by the system automatically.
Additional information about a bug can be added if needed
Can mention about the other area when the same issue occur which helps developer fixes the bug completed
| ID | 1 |
| Summery | Example |
| Example | Example |
| Example | Example |
| Example | Example |