The bug reports must help to reproduce the problem with minimum efforts and help the developer to debug and fix the problem. The good bug reports contain most of the information required to stake holders to reproduce, analyze, debug and fix the problem in a given context.
Concerns
There are many instances in my experience where in which the bugs were returned to the testers or the bug reporters seeking more information / clarifications / steps etc.
Concerns
There are many instances in my experience where in which the bugs were returned to the testers or the bug reporters seeking more information / clarifications / steps etc.
- How often the developers says that the issue is non reproducible at their end and seek clear steps to reproduce the bug?
- How often the developers require more information from the bug reporters which is not part of Bug report?
- How often do we spend more time on investigating the bug even after the bug has been reported?
- How often, we were asked to provide test data for the issues
- How often, we were asked for test environment details around the issue
And the list goes on …
We are often a hurry or excitement to report the issue and may provide just basic info and ignore. Some of us are also under the impression that we don’t need to spend so much time of the bug reports and might be waste of time too. Most of the information around the issue will be available only when the issue has been found. It would be tough to provide the same data at a later time.
But in reality, we spend more time even after reporting the problem and try to provide the information asked by stake holders.
The problem lies with the quality of the bug report. We often tend to report the bug with minimum details around the problem and tend to ignore context driven information required for other stake holder to save time.
The Bug Summary
Make it simple and point to the actual problem. Keep in mind that its developer’s initial interaction & the same must grab the attention and points to the actual problem.
Steps to Reproduce
Describe the state of application and the pre-requisites. The flow of user actions and data provided is important. All the steps must be logical and we can remove redundant steps. It’s a good idea to have a relook on all the steps and try it on a fresh system.
Expected Behavior & Actual Behavior
The perceptions and views tend to differ always. It’s good the document the expected behavior and actual behavior of the system under test.
Test data
We provide lot of data to the systems under test at specific user actions. It’s important to list down this data and also capture data around the issue. Provide the following as part of bug report
1. The input data to the application
2. Screenshots around the Issue
3. The Log files
Test Environment
Test Environment plays key role in reproducing the issues and it’s the root cause for many of the non reproducible issues. We must take that extra mile to capture all the environment details like OS, databases, build numbers, browsers. There are no best practices here and we must capture information based on the context.
Bug Tracking Systems
We log bugs in bug tracking tool and assumes that all the things have been taken care. But if try to look at history and pattern of these bugs based releases or environments etc via bug databases, all the issues may not be present. We do miss out many attributes of bug databases that might help us to derive patterns, categorize over specific need in the long term.
Conclusion
The purpose of a bug report is to showcase that there is a problem that exists and let the developers see the failure. It must defend and advocate the reasons around the problem and finally helps to resolve the bug in the system
We are often a hurry or excitement to report the issue and may provide just basic info and ignore. Some of us are also under the impression that we don’t need to spend so much time of the bug reports and might be waste of time too. Most of the information around the issue will be available only when the issue has been found. It would be tough to provide the same data at a later time.
But in reality, we spend more time even after reporting the problem and try to provide the information asked by stake holders.
The problem lies with the quality of the bug report. We often tend to report the bug with minimum details around the problem and tend to ignore context driven information required for other stake holder to save time.
The Bug Summary
Make it simple and point to the actual problem. Keep in mind that its developer’s initial interaction & the same must grab the attention and points to the actual problem.
Steps to Reproduce
Describe the state of application and the pre-requisites. The flow of user actions and data provided is important. All the steps must be logical and we can remove redundant steps. It’s a good idea to have a relook on all the steps and try it on a fresh system.
Expected Behavior & Actual Behavior
The perceptions and views tend to differ always. It’s good the document the expected behavior and actual behavior of the system under test.
Test data
We provide lot of data to the systems under test at specific user actions. It’s important to list down this data and also capture data around the issue. Provide the following as part of bug report
1. The input data to the application
2. Screenshots around the Issue
3. The Log files
Test Environment
Test Environment plays key role in reproducing the issues and it’s the root cause for many of the non reproducible issues. We must take that extra mile to capture all the environment details like OS, databases, build numbers, browsers. There are no best practices here and we must capture information based on the context.
Bug Tracking Systems
We log bugs in bug tracking tool and assumes that all the things have been taken care. But if try to look at history and pattern of these bugs based releases or environments etc via bug databases, all the issues may not be present. We do miss out many attributes of bug databases that might help us to derive patterns, categorize over specific need in the long term.
Conclusion
The purpose of a bug report is to showcase that there is a problem that exists and let the developers see the failure. It must defend and advocate the reasons around the problem and finally helps to resolve the bug in the system
No comments:
Post a Comment