jira
Using JIRA, defects should be reported with a 'one line description' which describes the defect as clearly as possible (this line will be visible in summary lists on project wiki pages), and with a complete description which has enough detail to reproduce the defect, and clearly describes what the expected outcome should be.
The Version the defect is found in should be specified. (This should be the SVN tag of the release).
User names and dates should be added automatically.
The submitter may assign the defect to the person most responsible, or if not known assign it to Bruc and he will then re-assign.
A defect may be reassigned at any time.
Notification lists should be set up and the default is usually adequate. If additional notifications beyond the default are required, this should be done manually.
Other required defect reporting fields are:
Type
The submitter should specify the type of entry (bug=defect)
| Name | Description |
|---|---|
| Bug | A problem which impairs or prevents the functions of the product. |
| Improvement | An improvement or enhancement to an existing feature or task. |
| New Feature | A new feature of the product, which has yet to be developed. |
| Task | A task that needs to be done. |
| Sub-task | The sub-task of the issue |
Priority
The submitter should assign a priority according to understanding, and this priority may be revised as a result of defect review.
| Name | Description |
|---|---|
| Blocker | Blocks development and/or testing work, production could not run. |
| Critical | Crashes, loss of data, severe memory leak. |
| Major | Major loss of function. |
| Minor | Minor loss of function, or other problem where easy workaround is present. |
| Trivial | Cosmetic problem like misspelt words or misaligned text. |
Resolution
When the developer resolves the defect, they should add the Resolution type.
| Name | Description |
|---|---|
| Fixed (Default) | A fix for this issue is checked into the tree and tested. |
| Won't Fix | The problem described is an issue which will not be fixed in this release. Should be reviewed in future release. |
| Duplicate | The problem is a duplicate of an existing issue. put duplicated issue by doing "linking" functionality and put the duplicated issue in comment |
| Incomplete | The problem is not completely described. |
| Cannot Reproduce | All attempts at reproducing this issue failed, or not enough information was available to reproduce the issue. Reading the code produces no clues as to why this behavior would occur. If more information appears later, please reopen the issue. |
Defect Status Transition
Defect Status Transition supported by JIRA used by MAMS is
| Status | Description |
|---|---|
| Open | The issue is open and ready for the assignee to start work on it. |
| In Progress | This issue is being actively worked on at the moment by the assignee. |
| Reopened | This issue was once resolved, but the resolution was deemed incorrect. From here issues are either marked assigned or resolved. |
| Resolved | A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed. |
| Closed | The issue is considered finished, the resolution is correct. Issues which are closed can be reopened. |
The defect submitter (or QA staff if so requested by submitter) should closethe defect when the resolution is confirmed/accepted. If the person closing the defect is not satisfied that it is correctly resolved, it should be reopened.
Defect Reviews
Defect Reviews should be held periodically, with sorted defect lists as input, and defect reports evaluated and priorities re-assiged as necessary.
