Context Driven Information About Bug Report

Dear Blog Reader,

Greeting,

In this post, i would like to explain & explore different stages or cycle of a Bug from it’s inception to closer. The Bug has been found and logged into the BTS (Bug Tracking System) and this is not just the end. Beside this, the bugs has to go through many stages till it die. It is always good to capture the context driven information in the bug report. My experiences with bug reports way back in my initial day's of my career had taught many lessons to improve upon.  
Bug reports is generally used to capture information about what is the problem with the system failure or when a defect exist in a system but mostly people spend very less time in capturing all the details required and there are many reasons for the same.
In general in our day today life, there may be some reasons/excuse what people may quote here;

• The System functionality and it's features are too complex and tough for novice user to understand the bug or it's reports.
• I can reproduce it on my machine if developer need it.  
• We get very less time to test. So we need to test more and give less time to capture & write more information in the Bug Reports.
• You know capturing all the info is process driven & it may not be worth of efforts or may be some times it is a boring stuff to collate the info & push it. :)

And the list goes on...
I hope you may have come across this situation at least once in your career but here the mission of your bug report is to provide details & context of the problem and convey the importance of it with a user driven stories. On another note, comprehensive report with accurate data always help the programmer/developer to locate or reproduce the error/bug inorder to make a fix. In short, your bug report must be like the voice of customer who play the role of an advocate against the problem.
Please make a note that the Bug Advocacy from Cem Kaner is an excellent and good source to begin with. If your report is unable to specify the need of the (bug) context, then it’s better to avoid writing such reports. Also in some case, it may not be feasible for other users using the system to explore & analyze the bug in that fashion. Another context associated with Bug Reports in relation with each stake holders of the project is that 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.
You should take some care about few parameters while capturing a bug/failure/error/defect/... which are listed below;

• The test environment should be a replica of the production environment and so while reporting a bug make sure to add all the Test Environment details.
• Add clarity about the Severity & Priority of the bug.
• Add detailed classification on the feature and also make sure to classify the maximum possible sub-feature/component of the system i.e. in short we can say the detailed steps where the bug was found (STEP TO REPRODUCE).
• Add info about the Bug types (i.e. Functional, Performance, Usability, Security etc).
• Versions and Build Numbers also play an important role in bug report which in turn help the programmer to deploy the build and reproduce the issue. Also there should be a build/version number added by the programmer which in turn help's the testing department to retest once the fix is available.
• Bug Classification would be useful incase if the bugs lies in Requirements or Design or Implementation work etc. (Optional).

Now a bug once pushed into the BTS may go through various stages (simple case is explained below) like;
When a bug/failure/error/defect is found it is always advisable to log that into the Bug Tracking System. At an initial stage, it will be treated as NEW Bug in the System and then would be ASSIGNED to the concerned developer/programmer for Resolution, once the test manager review it. The developer then INVESTIGATE and look in to the possibilities of the resolution & takes a call on Resolution for making a FIX or DEFFER the ticket over the information provided and ASSIGN the ticket back to Reporter/Tester. Tester would then validate (retest) the resolved issue in the build & check for the regression scenarios over the fix and finally if the bug/failure/error/defect is resolved it goes into the CLOSED state and then to archive or else the ticket is RE-OPENED/RE-ASSIGNED back to developer if the bug still exist in the system. Note this cycle continues till the defect move's into the Closed state. Finally check back & push the entire context driven information to the bug repository to identify the trends and risk associated with the release cycle incase if the same bug come back in any future release cycle.
I hope the above info may help a tester/QA who is new in pursuing a career in software testing. This article may help in identifying the trends in bugs and there cycle's to focus on the unstable components / environments.

Happy testing :)