Accessibility: Bug Specification

Table of contents 1 References 2 Definitions 3 Bug Specification 3.1 Purpose 3.2 Remember 3.3 Bug Template 3.3.1 PROBLEM STATEMENT: 3.3.2 REPRO: 3.3.3 RESULTS: 3.3.4 EXPECTED RESULTS: 3.3.5 COMMENTS: 3.4 Definitions 3.4.1 SEVERITY 3.4.2 PRIORITY

References

Product Test Case Plan
Product Test Case Specification
Product Test Log
Product Test Summary
Product Bug Specification (current page)
Product Home

Definitions

FCS Release—(F)inal (C)ustomer (S)hipping Release

Bug Specification

Purpose

This is the template that should be used for all bugs when they are entered into Bugzilla. Here is an example.

Remember

Whenever you log a bug, please remember to add a comment with a bug reference (e.g., BUG459153) where the bug occurs in your test. You must use the syntax BUG[0-9][0-9][0-9][0-9][0-9][0-9] so it can be easily found when regressing bugs.

Bug Template

PROBLEM STATEMENT

More detailed expansion of summary. (The summary is a very abstract description of the problem required by Bugzilla to create a bug.)

REPRO

Detailed step-by-step instructions that instruct the reader how to reproduce the bug. The instructions should be detailed and clear enough that anyone (developer, community member, new employee) can reproduce the bug. Remember to include any special setup steps.

RESULTS

What happens what the REPRO steps are followed

EXPECTED RESULTS

What *should* happen when the REPRO steps are followed

COMMENTS

Any additional information

Bug Definitions

Here are some definitions to keep in mind when submitting a bug in Bugzilla:

SEVERITY

Define defect severity value by Bugzilla default severity definition. The severity describes the impact of a bug.

• Blocker: Prevents developers or testers from performing their jobs. Impacts the development process.
• Critical: Crash, loss of data, corruption of data, severe memory leak.
• Major: Major loss of function, as specified in the product requirements for this release, or existing in the current
• Normal: Non-major loss of function.
• Minor: Issue that can be viewed as trivial (e.g. cosmetic, UI, easily documented).
• Enhancement: Request for software enhancement, or any non-defect task or work item.

PRIORITY

Define defect priority value by Bugzilla default priority definition. The priority specifies the level of urgency to be resolved for the defect.

• P1-Urgent: Defects are urgent issues. Developers should try to fix P1 issues as soon as possible during the current iteration.
• P2-High: Defects must be resolved in this release. Developers should try to fix P2 issues during the next iteration.
• P3-Medium: Defects would like to be fix, but won’t hold shipment for them.
• P4-Low: Defects are not as strong as desirable.

Bugzilla has many fields that provide additional information (e.g., environment details, found in version, etc.). Please provide as much information as possible when logging bugs.