WISE Defect Report Tracking System
OBSOLETE -- Use bugtrack.wpl !
The WISE system is highly configurable. The current project that you are
working on has been configured to automate the tracking of software bugs (aka
defects, problem reports, isues, etc.). This page details the various states
that a problem report can be in, the roles that people can play in fixing the
defect, and the various options and fields that can be filled out, viewed and
changed in a problem report.
States
A reported software defect can be in one of a number of states. These are:
- open
- A defect has been noticed and reported by the defect originator, but no
further action has been taken. A developer may move the defect into working
, fixed or returned states.
- working
- A developer is working to fix the defect. Typically, the developer will
fill in a synopsis for the defect, and possibly alter the abstract to more
closely describe the problem. The developer will also assign a component, and
may possibly redefine the owner. A developer may move the defect into
working, fixed or returned states.
- fixed
- The developer has completed work on the defect, and it is now awaiting
integration into the system, and a build of the system. A builder may move the
defect into the built state if they successfully completed integration
and have published a build, or they may move it to the working state if
build/integration has failed and this defect is the cause of the failure.
- returned
- The developer has determined that the defect is inappropriate for some
reason, and has returned it to the originator. It may be inappropriate for a
variety of reasons: it may be unreproducible, it may be vague,
it maybe a request for an enhancement (which should be handled through
other channels) or it maybe a duplicate of another defect. In the later
case, the developer will indicate a duplicate defect. The originator may move
the defect into closed state if they agree with the classification, or
they may move it into open state if they do not agree.
- closed
- The originator agrees with the final outcome and resolution.
- built
- The builder has completed the integration and build of the source code
provided by the developer. The build has been published and is available to
the test team. The tester can move the defect into testing, verify
or working states.
- testing
- The tester is currently testing the build in which the fix appears.
Typically, regression, verification and/or system tests are run; these may
take days or weeks to complete. The tester can move the defect into verify
state if the published fix passes the tests, or they may move it into
working state if the tests have failed. Typically, the tester will provide
a due date for completion of testing.
- verify
- The published fix has passed the testing phase, and is awaiting
confirmation from the originator. The originator can move the defect into the
open or closed states. Typically, the originator will move the
defect to closed state if the published fix does indeed appear to fix
the reported problem, or to open state if whatever it was still doesn't
work.
Roles
A user may have one or more of the roles described below. Roles are assigned
statically, by the WISE administrator, and are hard-coded into the system. You
cannot change your role without the system administrators help.
- viewer
- The viewer may be someone anonymous, or merely someone who only has
authority to view current defect reports and/or to create new defect reports.
- developer
- The developer is a person who has authority to work on and fix reported
defects.
- builder
- The builder is a person who is responsible for accepting fixes from the
developer, and incorporating them into the system, and publishing the
resulting release.
- tester
- The tester is a person responsible for testing published builds, typically
by "soaking" them in a "bucket" of test cases..
- teamlead
- The teamlead has broad powers to reclassify the state and other aspects of
a defect track.
Other Fields
- Below follows a quick summary of the other fields in a defect report. Some
of these fields are read-only, and others are edit-able. Some fields may only
be edit-able by people in certain roles. Whether a field is edit-able or not
depends on the state of the defect, among other things. For example, once a
defect is closed, all fields, except for the log, become read-only.
- abstract
- A one-line summary of the defect report. The originator, a developer, and
the teamlead can edit the abstract.
- synopsis
- A paragraph or two describing the problem in greater detail.
- log
- A log of comments that can be read and appended to. The log helps record
the history of the defect.
- originator
- The person who originally reported the problem.
- owner
- The person currently responsible for moving the defect report to the next
stage.
- severity
- The severity of the problem. Generally, the severity of the problem falls
into one of four classes:
- sev 1 - emergency
- The submitter cannot do anything without a fix to this problem, they are
dead in the water. A fix is expected in 24-48 hours..
- sev 2 -- mustfix
- The problem is serious and should be fixed, but the submitter has an
alternate means to work around (hack around) the problem, and can proceed
until the true fix is delivered. Typically, a fix is expected within 2-4
weeks.
- sev 3 -- annoyance
- A true problem exists, and should be fixed some day. Until then, the
problem is an annoyance, an ugliness, a wart.
- sev 4 -- suggestion
- A comment, note, reminder or suggestion. A fix is not necessarily expected,
as a problem may not exist.
- state
- Described above. The state may be one of: open, working, returned, fixed,
built, testing, verify, closed.
- category
-
- The categorization of the defect:
accepted by developer, error acknowledged, unreproducible, or duplicate.
- component
- The subsystem in which the problem is believed to be located. For example,
this may be client, server, network, database, or documentation.
- duedate
- The expected date on which the defect will move to the next state.
- duplicate
- The number of a duplicate issue, if this defect has been classified as a
duplicate of another.
Draft of 6 January, 1997 -- Linas Vepstas -- Version 0.1