Manual Defect Tracking Software

From HaFrWiki
Revision as of 10:06, 7 December 2012 by Hjmf (talk | contribs) (Created page with "{{TOCright}} A work-flow for working with the '''Eventum Defect Tracking System''' <ref>[http://forge.mysql.com/wiki/Eventum Eventum] is a user-friendly and flexible issue tra...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

A work-flow for working with the Eventum Defect Tracking System [1], but can be used for any other DTS [2] .
The purpose of this page is to give an insight into the flow-of-work of a such a system. The projects can be managed using:

  • Categories. What kind of bug/error/issue is reported. Software bug, or a functional feature, or Support request.
  • Groups & Users. Relation of the users to roles, status, groups and their email addresses.
  • Priorities. The priority of the solving of the bug. Standard from critical' to 'low'.
  • Releases. The software release for the bug to be solved.
  • Statuses. Most important for the defect-tracking-work-flow. Which status is assigned to the bug/issue. The project needs a very tide and precise description for the status, because the Defect Tracking completely relies on the correct status updates for the reporting.

Categories

top The original Eventum categories have not been altered and are going to be used:

Title
Bug
Feature request
Technical Support

Groups & Users

top The groups and users can be found on the Eventum implementation and are always up-to-date.

Priorities

top This list is fixed and will not be extended.

Rank Title
1 Critical
2 High
3 Medium
4 Low

Releases

top At this moment we have not made a list of releases.
To be determined later...

Title Tentative date Status
     

Statuses

Bugzilla Lifecycle

Overview

  Status Resolution
Open 11. Unconfirmed - Is it a valid bug.
12. New - Bug is valid needs to be asigned.
13. Assigned - Bug is beeing solved or re-assigned.
14. Reopened - Resolved bug, but deemed incorrect.
 
Closed 15. Resolved - Resolved, waiting for verification.
16. Verified - Resolved correct, waits deployment.
17. Closed - Dead bug, resolved correctly.
18. Fixed - Fix is checked and tested.
19. Invalid - It is not a bug.
20. Wontfix - Will never be fixed.
21. Dplicate - Duplicate of another bug.
22. Worksforme - No reproduction of the bug can be made.
23. Moved - Moved to another place.
24. Untested - Issue can not be tested.

Details

Please add the following statuses for our project (Bugzilla). The already available statuses may be removed for our project.

Statuses (Open Context)
Rank Abbr Title Description Color
11 UNC UNCONFIRMED This bug has recently been added to the database. Nobody has validated that this bug is true. Users who have the "canconfirm" permission set may confirm this bug, changing its state to NEW. Or, it may be directly resolved and marked RESOLVED. #CCFFFF
12 NEW NEW This bug has recently been added to the assignee's list of bugs and must be processed. Bugs in this state may be accepted, and become ASSIGNED, passed on to someone else, and remain NEW, or resolved and marked RESOLVED. #CCFFFF
13 ASS ASSIGNED This bug is not yet resolved, but is assigned to the proper person. From here bugs can be given to another person and become NEW, or resolved and become RESOLVED. #99CC66
14 REO REOPENED This bug was once resolved, but the resolution was deemed incorrect. For example, a WORKSFORME bug is REOPENED when more information shows up and the bug is now reproducible. From here bugs are either marked ASSIGNED or RESOLVED. #6699CC
Statuses (Closed Bugs)
Rank Abbr Title Description Color
15 RES RESOLVED A resolution has been taken, and it is awaiting verification by QA. From here bugs are either re-opened and become REOPENED, are marked VERIFIED, or are closed #FFCC99
16 VER VERIFIED QA has looked at the bug and the resolution and agrees that the appropriate resolution has been taken. Bugs remain in this state until the product they were reported against actually ships, at which point they become CLOSED. #CCCCCC
17 CLO CLOSED The bug is considered dead, the resolution is correct. Any zombie bugs who choose to walk the earth again must do so by becoming REOPENED. There is some discussion if this should be a closed status or closed context. #FFFFFF
Resolved Statuses (Closed Context)
Rank Abbr Title Description Color
18 FIX FIXED A fix for this bug is checked into the tree and tested. #CCFFFF
19 INV INVALID The problem described is not a bug. #99CC66
20 WNT WONTFIX The problem described is a bug which will never be fixed. #6699CC
21 DUP DUPLICATE The problem is a duplicate of an existing bug. Marking a bug duplicate requires the bug# of the duplicating bug and will at least put that bug number in the description field. #FFCC99
22 WOR WORKSFORME All attempts at reproducing this bug were futile, and reading the code produces no clues as to why the described behavior would occur. If more information appears later, the bug can be reopened. #CCCCCC
23 MOV MOVED The problem was specific to a related product whose bugs are tracked in another bug database. The bug has been moved to that database. #FFFFFF

Eventum statuses

The table below is the list of Eventum statuses.

top

Deprecated
Rank Abbr Title Color
1 DSC discovery #CCFFFF
2 REQ requirement #99CC66
3 IMP implementation #6699CC
4 TST evaluation and testing #FFCC99
5 REL released #CCCCCC
6 KIL killed #FFFFFF

See also

top

Reference

top

  1. Eventum is a user-friendly and flexible issue tracking system that can be used by a support department to track incoming technical support requests, or by a software development team to quickly organize tasks and bugs.
  2. DTS: Defect Tracking System or Bug Tracking System. The most common abbreviation is DTS.