Field |
Purpose |
| Title |
- A brief description of the problem.
- Say enough here so that the issue can be understood; keeping
details within the defect description.
- You are writing a "newspaper headline" here - concise, yet
describe what the issue is.
- Do not prefix the title with special codes - that is not
necessary with the new project structures.
|
| State |
- State indicates a fixed point in the life-cycle of an issue.
- There is a logical flow from one state to the next, which is
controlled via the "workflow" features within the tracking system, and usually controlled by the
administrator.
|
| Priority |
- Priority is the chief factor determining the order in which we
work on a task.
- It is not a judgment of importance to the customer.
- In theory, all priority 1’s should be addressed before priority
2’s, and so on.
- Therefore, it is the Product Manager who sets this field.
- "Thou Shalt Not Ship with [known] Priority
1 Bugs."
|
| Severity |
- Severity indicates the impact of the problem to the user.
- It may be correlated with a given set of Symptoms, but is primarily intended as an independent gradient of the
nature of the problem.
- The field is principally set by QA, acting as a customer
advocate.
|
| Issue Type |
requirement, documentation, packaging, etc.
See the detail page for far more information on this field. |
| Symptoms |
Symptoms indicate what the problem was, and are more useful for developers. |
| How Found |
Automated test, ad-hock, by customer, etc. |
| Found in Build |
The build number where the issue was first reported |
| Target Release |
The release by which the issue is expected to be
fixed. It serves as a filter that is independent from all other fields, and helps prioritize tasks for both developers and Project Managers. |
| Fixed in Build |
The build number where the developer expects the issue to be addressed.
Note: ideally, you have a "next build" value for this field, which the build process uses to go back and automatically set to the proper value upon the next build. |
| Closed in Build |
The build number where the issue has been closed/resolved, as verified by the test team (or by declaration of PM). |
| Resolution |
'Resolution' codes give greater detail on how or why an
issue had its state set to 'Validate' or 'Closed'. |
