Welcome to Software Testing Techie Blog!
Bug report sounds familiar, right? As testers, we all create one or more than one bug report in our everyday work but what mostly matters is how detailed do we create them? What details we put in and how other teams get benefit out of it.
I am going to share an example related to detailed bug report and how it affects the quality. Detailed bug report is one of the best gift you can give to your and also to development team.
Let's see how:
A detailed bug report should have 4 major things namely severity, steps to reproduce, expected result and actual result. There could be other fields depending on what defect tracking tool you are using for example, testing estimate, test cases reviewer etc.
Consider an easy example where user logs into a website and found that home screen is distorted. So Let's define all above 4 major areas:
1. Severity: Since it is related to Home screen which is the most important part of any application and can lead to bad user experience so severity should be set as "High or Highest".
2. Steps to reproduce: This is the area where you need to have a balance of words. It should not be so verbose that people get annoyed reading the whole thing and should not be incomplete at the same time. For the above example, steps to reproduced would be:
It is short and simple plus covers all the steps. Now the 3rd detail which is expected result.
3. Expected result: This is the field where you have to refer the requirement document (If there is an id for it) and give them the exact line number where it is mentioned that "how home screen should look". For example in above example, we can state that "Text of the Home Screen and Icons should be properly displayed", notice that expected result contains "should or must" since they are related to the requirements and should be followed by exact words defined in the requirements.
4. Actual result: This is the area where you have to exactly defined what you see. For our example, you can state that "All the Texts and Icons present on Home Screen are distorted". And also, you can attach a screenshot showing the real issue for reference. Visuals are more understandable than theory.
If the bug report is not detailed then development team might find it difficult to understand the bug and hence the quality of the fix will be affected. When all the steps are clearly defined, screenshots or other reference documents are attached and expected result is clear, bug can't stay for longer :)
Bug report sounds familiar, right? As testers, we all create one or more than one bug report in our everyday work but what mostly matters is how detailed do we create them? What details we put in and how other teams get benefit out of it.
 |
| BUG!! |
I am going to share an example related to detailed bug report and how it affects the quality. Detailed bug report is one of the best gift you can give to your and also to development team.
Let's see how:
A detailed bug report should have 4 major things namely severity, steps to reproduce, expected result and actual result. There could be other fields depending on what defect tracking tool you are using for example, testing estimate, test cases reviewer etc.
Consider an easy example where user logs into a website and found that home screen is distorted. So Let's define all above 4 major areas:
1. Severity: Since it is related to Home screen which is the most important part of any application and can lead to bad user experience so severity should be set as "High or Highest".
2. Steps to reproduce: This is the area where you need to have a balance of words. It should not be so verbose that people get annoyed reading the whole thing and should not be incomplete at the same time. For the above example, steps to reproduced would be:
It is short and simple plus covers all the steps. Now the 3rd detail which is expected result.
3. Expected result: This is the field where you have to refer the requirement document (If there is an id for it) and give them the exact line number where it is mentioned that "how home screen should look". For example in above example, we can state that "Text of the Home Screen and Icons should be properly displayed", notice that expected result contains "should or must" since they are related to the requirements and should be followed by exact words defined in the requirements.
4. Actual result: This is the area where you have to exactly defined what you see. For our example, you can state that "All the Texts and Icons present on Home Screen are distorted". And also, you can attach a screenshot showing the real issue for reference. Visuals are more understandable than theory.
If the bug report is not detailed then development team might find it difficult to understand the bug and hence the quality of the fix will be affected. When all the steps are clearly defined, screenshots or other reference documents are attached and expected result is clear, bug can't stay for longer :)
Comments
Post a Comment
Share your feedback