Bug Reporting

From Informatics

Before entering a defect into the system make sure that it has not already been reported: identify the geWorkbench component where the problem appears and then use the Mantis filtering facility (Mantis uses the term "Category" for components) to verify that indeed there is no record of the bug in Mantis.

Defect reports need to contain a step by step description of the user actions that lead to a bug so that developers can unambiguously reproduce the erratic behavior. An example of a properly written defect report can be found here:

  http://wiki.c2b2.columbia.edu/mantis/view.php?id=400

Also, the report should indicate if the requested fix requires updating the end user documentation (online help, tutorials, user guide: see "Update documentation" below). Regarding the other fields in the Error Report screen:

• Category: This drop-down list contains one entry for each geWorkbench component (if something is missing, please contact one of the Mantis admins and request that the missing entry be added). Use the list to specify the component that the defect is pertinent to.
• Reproducibility: Self-explanatory. Ideally, this will always take the value "always".
• Severity: Use the value "feature" to indicate that the report is not for a defect but for a suggested enhancement. For defects use your judgement to determine if the severity is "minor" or "major". At present we are not use any of the other values for this field (trivial, text tweak, crash, block).
• Priority: Self-explanatory. Again, use judgement for making the appropriate call.
• Product version: Enter the CVS branch/tag where the defect was found. In most cases this will be either "Development" (indicating the main development branch) or the name of a system testing branch.
• Summary: One line summary description if defect.
• Description: Detailed step by step description of the user steps and the resulting erratic behavior observed.
• Scheduled for release: The default value is "development". If however the defect should be fixed in preparation for a particular release, enter here the release number (from the drop down). Filtering using this field will allow developers to identify bugs that need to be fixed for the release (versus lower priority defects which are not related to released components).
• Reviewer: Set the Reviewer field to the developer who will review the code.
• Update documentation: The value of this field should be set to "Yes" if the fix requested impacts documentation material (online help, tutorials, end user guide).