Context driven information is the need of the hour and there is a huge value associated with the same. It's good to capture the context driven information in the bug reports. My initial experiences with bug reports way back in early 2000 have taught many lessons to improve upon.
Bug reports used to capture what is the problem with the system familiar to the user (tester) who reported the same. People spend very less time to capture all the details required and there are many reasons for the same. I hope some of the upcoming testers will also be in the similar situations.
Some of the Reasons people quote here
- We need to test more and less time to capture & write more information in the Bug Reports
- It's tough to capture all the information required
- System is complex & It's tough for the novice users to understand the bug reports
- You know capturing all the info is process driven & it may not be worth of efforts
- It some times boring activity to collate the info & push it
- I can reproduce it on my machine if developer needs it.
This list can go on…
I hope you have come across this situation at least once in your career.
This is my third post in the Bug Life Cycle Series and it's good to know the different users of your Bugs and their context with them. The mission of your bug report is to provide details and context of the problem and convey the importance of it with a user driven stories.
Your bug report must be the voice of customer and it need play the role of an advocate against the problem. Bug Advocacy from Cem Kaner is an excellent source to begin with. If the bug report unable to specify the need of the context, then it's better not to write any report
It's good to explore & capture some of the following problems
- Productivity
- Performance
- Usability
- Migration
- Stability etc
Try to link your issues with most suited functions listed above. It may not be obvious to other users in the system to explore & analyze the issues in that fashion.
There is another context associated with Bug Reports. That's with the stake holders of the project. The Bug Tracking system must give the right trends and identify the hot spots. Testers must capture the right kind of data to derive better valuable metrics over the bug repository.
Care must be taken to capture
- Capture all the Test Environment details
- Detailed classification on the feature. Classify to the maximum possible sub feature/component of the system
- Clarity on Severity & Priority
- Versions and Build Numbers (Affected & Fixed)
- Bug Classification (Requirements / Design / Implementation etc)
- Bug Types (Functional, Performance, Usability, Security etc)
- It can go on…
The above info helps a lot to identify the trends in bugs and focus on the unstable components / environments.
Final Thoughts
Push the entire context driven information to the bug repository at least for a release cycle and observe the results. Check back with your repository to identify the trends and risk associated with the release and I am sure that it will be in the similar lines of end user feedback.
Happy Testing…
No comments:
Post a Comment