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. Some of the Reasons people quote here:

 (1)We need to test more and less time to capture & write more information in the Bug Reports

(2) It’s tough to capture all the information required

(3)System is complex & It’s tough for the novice users to understand the bug reports

(4)You know capturing all the info is process driven & it may not be worth of efforts Bug report must be the voice of customer and it need play the role of an advocate against the problem.

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:

(1)Productivity

(2)Performance

(3)Usability

(4)Migration

(5) 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.

(1)Care must be taken to capture,

(2)Capture all the Test Environment details

(3)Detailed classification on the feature. Classify to the maximum possible sub feature/component of the system

(4)Clarity on Severity & Priority

(5)Versions and Build Numbers (Affected & Fixed)

(6) Bug Classification (Requirements / Design / Implementation etc)

(7)Bug Types (Functional, Performance, Usability, Security etc)

The above information helps a lot to identify the trends in bugs and focus on the unstable components / environments.

Resource:

http://venkatreddy.in/2007/07/26/context-driven-information-for-bug-reports/