Introduction:
Software issues can be tracked as bugs in highly customizable formats, but most have a few elements in common among them. Bugs can be submitted through issue tracking systems such as Jira or IBM’s ClearQuest. Fields in issue tracking systems can usually be added, removed, or edited as needed.
Requirements:
Optionally, an issue tracking system.
Procedure:
Once an issue is observed in a system under test (SUT), the issue can be tracked, until it is potentially resolved.
Most all issues have issue IDs that are usually assigned by tracking system (such as Jira or ClearQuest). This may be a long number/code.
A title or headline is the second easiest way to reference a bug. This is the bug’s title, and should be formatted as a sentence.
The bug’s submitter should be included, either as a full name, email address, or username.
The bug may have a category or subcategory related to the SUT.
It may be useful to note if this bug’s influence on the SUT causes crash.
The bug may be categorized as a defect, improvement, or other bug type, such as cosmetic.
Issue severity can be on a numeric scale, or can be written as terms such as “serious,” “minor,” “critical,” “normal,” “cosmetic.”
A bug can also be tracked by frequency or hit count.
The state of the bug can be terms such as “submitted,” “open,” “assigned,” “fixed,” “unresolved,” or “closed.” They usually begin as “submitted,” then “open,” then become “assigned” to a coordinator to dispatch the bug’s responsibility to a developer, or a developer directly. When the bug is “fixed” or “unresolved” by development, they will change the issue’s state. It may be up to the tester to mark the bug as “closed.” Usually, bugs remain in issue tracking systems for historical purposes, after closure. The tester is often the one to “close” a bug as they may need to verify the fix first.
Discussion between those involved with the bug can choose to communicate via email (usually for longer discussions), or through a notes/comments section of an issue. Notes are usually recorded with a username and timestamp for each entry.
The hardware configuration or test harness may also need to be captured and recorded for the bug.
Attachments, such as screenshots or log files may be included for the issue, optionally compressed to meet storage concerns.
The description/notes field is crucial for most bugs. It may recorded in a set of paragraphs as observations, but at the very least, should include: steps to reproduce (often numbered), expected results, and actual results.
The impact of the bug may need to be identified, as to what other systems/subsystems/software the bug affects.
There may be a way to view the history or tracking information for a bug too.
