Log in / create account | Login with OpenID
DocForge
An Open Wiki For Software Developers

Bug report

From DocForge

A bug report is a document or record explaining the details of a bug found in a software package. Bug reports are typically created by beta testers and end users as they come across issues with software.

Bug reports usually include the following information:

  • From the person who found the bug
    • Date and time a bug was reported and/or found
    • The bug's severity, as perceived by the person who discovered it. Severity can be defined in a few ways:
      • Severity can be a simple prioritization, such as low/medium/high or 1/2/3. In this case a higher severity simply means it's more important than lower severity issues, from the perspective of the interested party. For example, a bug that prevents people from logging into a system and access any other feature would likely be considered high priority.
      • Severity can also be a measure of criticality. For example, a system crash would be critical, while an incorrectly sorted table would not. In this case severity would be a descriptive list, such as crash/usability/minor.
    • General description of the program behavior and bug
    • Detailed explanation of how to reproduce the bug
    • Identity of the person reporting the bug
  • From the testing manager and/or developer
    • The bug's severity - Some users have a tendency to mark every bug as critical or high priority. In this case a testing manager or developer will need to re-prioritize or the severity will be meaningless.
    • Status - The options available will depend on the workflow of the development team. This can be as simple as open/closed or as complex as pending review/in process/pending beta approval/approved beta/etc.
    • Programmers assigned to fix the bug

Bug reports are sometimes integrated into workflow systems that automatically notify interested parties as information changes. For example, a bug tracking system might notify a lead developer when a bug is added or email a tester when a bug's status is changed.

Reproducibility

Perhaps the most important information in a bug report are the steps to reproduce the issue. To analyze a bug a programmer must know all of the factors which cause it. It also helps to be able to walk through the steps to witness the issue personally. Finally, having the steps that revealed the issue will allow retesting with those steps once the bug is fixed.