March 7, 2006

Free Issue Tracking Template

Here's a free template of an Issue Tracking system I currently use.

Issue Number: A system-generated number that uniquely identifies the Issue.

Summary: This is a short, one-line statement that summarizes the issue.

Created: This system-generated field displays the date the Issue was created and the name of the person who created it.

Last Modified: This system-generated field displays the date the Issue was most recently modified and the name of the person who modified it. copyrightjoestrazzere

Closed: This system-generated field displays the date the Issue was closed and the name of the person who closed it.

Product: This is the product for which the issue applies. It will typically be selected from a list customized for the particular database and project.

Issue Type: This indicates the type of issue. The choices are:
  • Bug: This is a bug in the existing product
  • Feature Request: This is a request for a new feature
  • Task: This is a new development task
  • Hitlist: This is a hitlist (ie, customer-and-time-critical) issue
  • Flex: This issue holds anticipated Developer time off
  • Other: Anything else
Priority: This is a measure of the level of importance or urgency connected with this issue. The possible choices are:
  • Critical: This is the highest priority and should only be given to issues associated with customers being down, or when testing is blocked. These issues will often be added to the hitlist.
  • High: This priority is for serious issues that are causing the user a great amount of pain but can be managed in the short-term with a workaround.
  • Medium: This is the priority that should be given to most issues.
  • Low: This is for issues that are not very important. Easy workarounds exist for these issues.
Issue Build: This is the version of the product in which the issue was detected. When issues are detected during a development release, the full version-and-build numbers should be used (ex: 2.50.0421).  When the issues are detected in a GA release, just the major and minor version numbers may be used (ex: 5.10).

Target Ver: This is the version of the product in which the issue was (or will be) resolved. All version numbers should have one of the following forms: M.mm where M is the major version number, mm is the minor version number (ex: 2.50), or the code name of the Project in which the issue is to be fixed (ex: Havard).

Work Days: This indicates the Developer’s estimate of the days required to resolve the Issue.  This field typically only exists once the Issue reaches Accepted status.

Fix Build: Once fixed, this field indicates the full version-and-build in which the fix is expected to appear.  Once the fix is verified, this field indicates the full version-and-build number of the build used while verifying the fix.

Status: This describes the current state of the issue. The possible choices are:
  • New: This is the status that is given to all newly created issues.
  • Accepted: This is the status that is given to an issue that will be worked on for the next release.
  • Fixed: This is the status that is given to an issue that has been fixed (or implemented in the case of a feature request) and needs verification.
  • Closed: This is the status given to an issue that has been successfully verified.
  • Deferred: This is the status given to issues that will be fixed in a future release.
Assigned: This is the name of the person who currently owns the issue. For accepted issues this will be the developer who is responsible for providing the fix. For fixed issues, this will be the person responsible for verifying the fix.

Description: This is a continuous dialog contributed to by each owner of the issue. Typically, it starts with a description of the problem, the steps required to reproduce the problem, the expected results, and the actual results. It continues with a description of the solution entered by the developer who fixed the problem. It may further continue with notes from the verifier (especially in the case where the verification failed).
Each time more description text is added, the system automatically adds a time stamp.

Attachments: All files which help clarify the issue are attached here

Associated Tests: The Test Case associated with this Issue is linked here

Associated Issues: Any duplicate Issues are linked here.  Any other Issues which can help clarify this issue are also linked here.

Here's a sample Issue Report:




Issue Number:

1234

Summary:

Right-Click Menu is Missing the Delete Choice

Created:

2/21/06 at 10:43 AM by Joe Strazzere

Last Modified:

3/1/06 at 8:12 AM by Joe Strazzere

Closed:

3/1/06 at 8:12 AM by Joe Strazzere

Product:

Whiz-Bang

Issue Type:

Bug

Priority:

Medium

Issue Build:

2.50.0401

Target Ver:

2.50

Work Days:

1

Fix Build:

2.50.0406

Status:

Closed

Description:

When I right-click the Zerble object, the menu which appears does not include the "Delete" choice, as it did in prior versions.
Nothing unexpected appears in the server.log file.
The JavaScript console shows no errors.


To Reproduce:

- Open the Framis in the Whiz-Bang Editor

- Select one of the the Zerble objects which appear

- Right-click

- Note the choices in the pop-up menu



Expected Results:

- The pop-up menu choices should be Add, Edit, Delete, Save, Save As, Help, and Exit



Actual Results:

- Delete is missing, the rest are as expected.
- (see attached zerblemenu.jpg)


[Joe Strazzere - 2/21/06 10:43 AM]



The call to popUpMenuSelections was made without the isItDeleted modifier.  Should be fixed in the next build.

[Dee Veloper - 2/28/06 6:22 PM]



Verified in build 406 usig IE and Firefox.

[Joe Strazzere - 3/1/06 8:12 AM]

Attachments:

zerblemenu.jpg

Associated Tests:

142 - Zerble Object Right-Click Menu Choices

Associated Issues:

(none)