During testing, a tester records their observations, findings, and other information useful to the developers or the management. All this data belongs to a test record, also called a bug report.
A detailed bug report is an important artifact produced during testing. It helps the team members with:
- Understand the problem,
- Steps to reproduce the problem,
- The environment and the specific conditions under which it happens, and
- The resolution if/when the developers fix the problem.
Here are a few bits of information that a good bug report should contain. Image Source: Bugzilla
|Title||A short headline that summarizes the problem. It shouldn’t be too long but just to give just the right information to the reader. It should be specific and accurate.|
|Description||The description should answer all the questions that are not explained by the title. It contains a detailed summary of the bug, its severity, and impact, steps to reproduce, expected results vs. the actual output.|
|Version||A lot of time can be wasted in trying to reproduce a bug in the wrong version of the product. Knowing the exact product version or the build number on which this bug was found is very useful to the developer in reproducing the bug.|
|Status||At any point, a bug can be either ‘Active’, ‘Ready for Testing’, or ‘Closed’. A bug becomes active when it is found, is ready for testing once the developer fixes it. A tester can mark it closed if the developer fixed it, or active if not.|
|Steps to Reproduce||Though the steps to reproduce the problem can be provided in the description, sometimes having a distinct field force the tester to think about them. They include each step one must take to successfully reproduce the problem.|
|Assigned To||Name of the developer or the tester to whom this bug is assigned.|
|Resolution||When a developer fixes the bug, they should include the cause for the bug and its resolution. It helps the team in the future when a similar bug resurfaces.|
Which bug logging tool is good?
You can refer to my article