The Web Testing Companion: The Insider's Guide to Efficient and Effective
Tests
Lydia Ash
Forms and Templates: Defect-Tracking Database Fields
This section contains suggestions for a defect database. Have several
high-level areas with individual values contained therein. The next four
sections outline possible high-level areas, along with potential divisions
of these areas. Your own areas and breakdowns will likely be different,
but this is a point from which to start.
Opened
Opened By
Opened Date
Build
How Found
Opened By tracks the person who opened the issue. Opened
Date tracks what date and time the bug was opened.
Build is the build number that this bug was found on. If
this bug was found on a late build number, but can be reproduced on
an earlier build number, then that earlier number is generally entered
to track the earliest point in time for which the problem was able
to be reproduced.
How Found tracks how the bug was identified. Such fields
as Ad Hoc, Automation, BVTs, Bug Bash, Code Review, Customer, Dogfood,
Localization, Test Case Development, Test Pass, or Usability testing
are useful here.
Project
Project (if multiple projects)
Component
Area or Feature
Approving Body
Approval State
Target
Release Note
Project tracks the specific project that this bug is found
in. Some testing houses have several projects going on simultaneously.
If they do not have separate databases, then they will want to set
a field to separate the various groups' bugs.
Component relates to the specific project's components. If
this were an online business, such components might be Sign-Up, Ordering,
Help, Content, or others.
Area or Feature is relevant if there is a finer breakdown
than the component level.
Some organizations require bugs to be approved by management or
require approval after a certain point in the project. The Approval
State tracks what level of approval there is, and the Approving
Body tracks who set the state.
Target tracks when the bug needs to be fixed-by milestones
or releases, or even by dates.
Release Note is a simple Y/N field (or even a blank/Y field)
that allows the documentation team to easily find which bugs need
to be addressed on paper.
Status
Status
Assigned To
Issue
Severity
Priority
Updated by
Updated date
Status is the current status of the bug Typically
there are three states:
- Active. Active correlates to a bug being open and a fix being
planned at some point in the future for it.
- Resolved. Resolved should be only a short state for a bug because
it will then be assigned back to the tester who created the database
entry for him to close, with either the bug being fixed or another
resolution that he agrees with.
- Closed. Closed is what happens when bugs are not being considered
relevant any more. They can be closed because they have been fixed,
it has been decided never to fix the problem, because they were
the result of an external problem, or because they are not reproducible.
Assigned To tracks who the bug is assigned to. Many organizations
use at least one catch-all of Active or Developer as a general account
to assign bugs to so that they will be picked up by the proper groups.
Once a bug is closed, it is typically assigned to Closed so that it
does not pop up on anybody's personal queries of assigned bugs.
Issue is the type of problem that this bug represents. Typical
options here might be Accessibility, Malfunction, Code Defect, Spec
Change, Design Change Request, Customer, Corruption, Globalization,
Performance, Localization, Scalability, Resource Leak, Misc, Security,
Fit and Finish, or Assert, to track the particular classification
of the issue that is encountered.
Priority and Severity are typically rated on a 1-4
scale, although some companies use a 1-10 scale or a color system
(red, yellow, green). A 1-4 system easily breaks things into buckets,
while in a 1-10 system, the difference between a 5 and a 6 might not
be apparent. Colors are interpreted differently based on cultures,
and those who are colorblind may not understand them. A simple value
works best.
Updated By and Updated Date simply track who was the
last person to edit the bug and when did that edit occur.
Resolved
Resolution
Resolved By
Resolution Date
Build
Cause
Resolution tracks the resolution state for any single bug.
This can have any of the following aspects:
By Design.This is the design of the product as you want it to be.
Duplicate. There is already a bug tracking this issue (should reference
the bug #).
External. This is the result of another piece of software/hardware
that is out of our control-may include release notes or Help pages regarding
this, though.
Fixed. Programmer has fixed this, and it will be assigned back to
the tester to verify.
Not Repro. Cannot reproduce the stated problem; usually assigned back
to the tester to create a more compelling case or to follow up directly
with the developer to understand the issue.
Postponed. Will fix in a later release.
Won't Fix. Will never fix.
Not Yet Implemented. Not a developer-produced error, but a piece of
functionality that has not been added yet as planned-having lots of
bugs resolved this way indicates a disconnect in communication between
Development and Test.
Config. Problem is valid, but was due to a configuration on the server
or the client; may be useful to break this out into two resolutions
so you can track who misconfigures their servers/clients and what a
typical problem can be (for example, security settings).
Resolved By tracks who set the Resolution on the bug. Some
organizations frown on individuals setting bugs to a Resolved state
and prefer that committees do this. Resolution Date tracks
when the bug was set to Resolved or Closed.
Build can be filled in if there was a fix implemented, letting
users know when the fix was available in the code.
Cause tracks why this problem popped up. Such options as
Bad Design, Broke by Fix, Broken by Localization, No Code, No Previous
Spec, or Dev Error can track what caused the bug to happen.
|
|
|
wiley.com
