WISE Defect Report Tracking System

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. Alternately, if the reported problem still persists, the originator will move the defect to open state if the fix provided did not actually fix the problem reported

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. How serious is this problem? Do not confuse severity with priority -- these two concepts are related, but not the same. Generally, the severity of the problem falls into one of four classes:

sev 1 - showstopper: The submitter cannot do anything without a fix to this problem, they are dead in the water. There are no workarounds. Ypically, a fix is expected immediately.
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. However, there is a standard way of dealing with the problem that everyone knows about. People are used to working around this, so the fix can wait. 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.

priority

The priority of the problem. Do not confuse this field with "severity", which embodies a similar idea, but is not the same. Priority defines the order in problems should be worked on. Usually, high-severity problems are also high-priority, but this need not be the case. The priority field allows the manager to fine-tune the order in which problems are worked on. Usually, as work items are fixed, new work items are raised in priority, without changing the severity.

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. See also "target" below.

target

The "target" field indicates when the fix will be published. This is usually some name denoting a release or build, such as "beta06" or "gold", etc. The target field offers a more convenient way of sorting through the listing than the duedate field.

duplicate

The number of a duplicate issue, if this defect has been classified as a duplicate of another.

Draft of 1 May, 1997 -- Linas Vepstas -- Version 0.2