The Web Site Development Template - NetResults Tracker Help

NetResults Tracker Help

The Web Site Development Template

Overview

The Web Site Development template supports a traditional web site development process. Typical of this process is the immediate posting of bug fixes to the web site being developed and maintained. This model assumes the following organizations are involved in the defect tracking process:

Development - Responsible for performing development tasks necessary to handle the request.

QA - Verifies that the request has been successfully implemented by the Development organization.

Build - Places the updated files onto the live server.

Quick Links

Projects - describes the projects available in this template.
Forms - explains the forms available in this template.
Fields - provides details about the fields configured by default.
Workflows - description of the workflow process.
Charts - sample charts available in this template.
Email - information about the default email notification rules.
Security - a summary about the security model in effect.

Projects

A default project called "Web Site Development" is available in this template and is visible to all user groups. This project can be customized and additional projects can be added via the Projects section.

Return to Topics List

Forms

A default form called "Issue" is available in this template, is associated with the "Web Site Development" Project and is visible to all user groups. This form can be customized and additional forms can be added via the Forms section.

Return to Topics List

Fields

The Issue form contains the following fields. Note that you can customize the database by adding to or removing fields, or changing any pulldown menu values via the Fields section. Field names with an asterisk are required by the system and cannot be removed from any form(s).

PRN* Numeric record identifier. Assigned at the time the issue is created.

Title A one line text summary of the problem. Set at the time the issue is created.

Product* Identifies the product related to the issue has been reported. Set at the time the issue is created.

Last Updated Date* The date and time the issue was last modified. Set automatically as the issue is processed through the workflow.

Browser Identifies the browser type related to the issue that has been reported. Set at the time the issue is created.

Platform Describes the hardware or software platform where the issue occurs. An example is the operating system (e.g. Windows XP). Set at the time the issue is created.

Problem URL URL of the web page where the issue was found. Set at the time the issue is created.

Request Type Classifies the issue. Possible values are: Bug, Contract Requirement, Customer Feedback, Customer Problem, Enhancement. Set at the time the issue is created.

Severity Describes the relative impact of the issue. Set at the time the issue is created.

Description Full description of the issue. Ideally describes the nature of the problem and how to reproduce the behavior. Set at the time the issue is created.

Reported By* Name of the user that reported the issue. Initially set to the name of the current user logged in. Set at the time the issue is created.

Date Reported The date the issue was created. Automatically initialized, and set at the time the issue is created.

Workaround Describes how to work around the reported issue. Set at the time the issue is created.

Status* Current state of the issue. Changes as the issue is processed through the workflow.

Substatus Describes the condition of the issue in the current state. Possible values are: None, In Progress. Optionally set by each user while processing the issue.

Assigned To* User the issue is currently assigned to for processing. Set either manually or automatically during processing of the workflow.

Operating System The operating system installed on the machine of the user who reported the issue. Set automatically when the ticket is created using the AutoFill feature.

Reporter's Web Browser The browser installed on the machine of the user who reported the issue. Set automatically when the ticket is created using the AutoFill feature.

Screen Size The screen size set on the machine of the user who reported the issue. Set automatically when the ticket is created using the AutoFill feature.

Estimated Size Used to enter an estimated amount of time it will take for a developer to fix the issue.

Fix Date Date when the issue was fixed. Set by Development when the issue is fixed. Automatically initialized to the current date/time.

Fix Detail A Description of the action taken by a developer to fix the issue. Set by Development when the problem is fixed.

Test Date Date when the fix was tested. Set by QA when the fix for the issue is tested. Automatically initialized to the current date/time.

Test Description A Description of the action taken by a QA Engineer to test the fix. Set by QA when the fix is tested.

Test URL A URL where the fix can be tested. Set by Developer when the issue is fixed.

Priority Describes the relative importance of handling this issue compared to other issues entered in the system.

Close Date Date when the issue was closed. Set by Process Manager when no development work will be done on an issue. Automatically initialized to the current date/time.

Close Detail A Description of the reason for closing an issue. Set by the Process Manager when no development work will be done on an issue.

Defer Reason Describes the reason an issue will not be worked on until a later date.

Duplicate Record # Lists the record number of another previously-entered issue in the database which describes the same problem.

Date Released Date when the fix for the issue was released. Set by the Build Manager when the fix for the issue is released. Automatically initialized to the current date/time.

Deleted* Denotes whether the issue has been deleted.

Return to Topics List

Workflows

It is assumed that issues will be processed and moved through the workflow process by using the Task operation. A default workflow called "Web Site Issue Process" is available in this template and is associated with the "Issue" Form and is in use in the "Web Site Development" Project. You can customize the Web Site Issue Process workflow or add additional workflows via the Workflows section.

Reported
When an issue is created, it is set to the state Reported, and assigned to the Process Manager (process_mgr). It is assumed that the Process Manager is responsible for looking at all incoming issues and deciding how to process each one from a list of possible workflow paths. The Process Manager can choose one of the following:
- Start the process for the issue by selecting the transition called Schedule. This transition will assign the issue to the Development Manager (dev_mgr) and place the issue in the Scheduled state. The Process Manager can also enter a Priority for the issue when choosing this transition.
- Defer the processing of the issue by selecting the transition called Defer. This transition will place the issue in the Deferred state and assign it to the state manager of that state (process_mgr). The Process Manager can review deferred issues at a later time and decide whether processing will resume.
- Close the issue by selecting the transition called Close. This transition will place the issue in the Closed state and assign it to TBD (no one - since this issue will not be processed any further). The Process Manager will be required to enter a reason the issue was closed in the Close Detail field. The Close Date will be updated automatically.
- Mark the issue as a duplicate of another issue by selecting the transition called Mark Duplicate. This transition will place the issue in the Duplicate State and assign it to TBD (no one - since this issue will not be processed any further). The Process Manager will be required to enter the issue number of the original issue that describes the same problem.
This is implemented by:
Workflow Properties
- Defining Reported as the Default Add State when an issue is added
- Assigning the process_mgr user as the manager for the Reported and Deferred states
- Assigning dev_mgr as the manager for the Scheduled state
Transitions
- Defining transitions to move an issue to the Scheduled and Deferred states where the assignee is the State Manager for each respective state.
- Defining transitions to move an issue to the Closed and Mark Duplicate states where the assignee is TBD for each transition.
Task Fields
- Configuring Priority (optional) to be presented during the task operation for the transition to the Scheduled state.
- Configuring Defer Reason (required) to be presented during the task operation for the transition to the Deferred state.
- Configuring Close Detail (required) and Close Date (read only and initialized) to be presented during the task operation for the transition to the Closed state.
- Configuring Duplicate Record # (required) to be presented during the task operation for the transition to the Mark Duplicate state.
Scheduled
The Development Manager (dev_mgr) is assumed to be a manager responsible for assigning tasks to the developers for resolution. The Development Manager uses the transition Assign to Developer to assign the issue to a developer (dev_one), a member of the "Developers" user group. This places the issue in the In Development state. The Development Manager can also decide to defer a issue by choosing the Defer transition, which will place the issue in the Deferred state and assign it to the Process Manager (process_mgr).
This is implemented by:
Transitions
- Defining a transition to move an issue to the In Development state with the assignee to be chosen from a list of developers (User Group called "Developers")
- Defining a transition to move an issue to the Deferred state with the state manager as the assignee
Task Fields
- Configuring Defer Reason (required) to be presented during the task operation for the transition to the Deferred state
In Development
The Developer (dev_one) assigned to the issue makes the changes necessary to address the problem and can either update any progress made on the issue using the Update transition or can mark the task complete using the transition called Mark Fixed. The Mark Fixed transition allows the Developer to enter a description as well as a URL to be used by QA to test the fix, advances the state of the issue to Fixed, and assigns the issue to the QA Manager (qa_mgr). The Fix Date will be automatically set to the current date and time.
This is implemented by:
Workflow Properties
- Defining the qa_mgr as the manager for the Fixed state
Transitions
- Defining a transition with New State set to In Development and New Assignee set to "<Same Assignee>"
- Defining a transition to move an issue to the Fixed state where the assignee is the State Manager
Task Fields
- Configuring Fix Detail (required) to be presented during the Task operation for the Update transition. The Description field is presented as a read only task field for the Developer's reference when choosing this transition.
- Configuring the Fix Date (read only and initialized), Fix Detail (required), and Test URL (optional) to be presented during the Task operation for the transition to the Fixed state. The Description field is presented as a read only task field for the Developer's reference when choosing this transition.
Fixed
Once the issue has entered the Fixed state, the QA Manager (qa_mgr) assigns the issue to the QA Engineer (qa_one), a member of the QA user group, and advances the state to In Test by using the transition called Assign to QA Engineer.
This is implemented by:
Transitions
- Defining a transition to move an issue to the In Test state with the assignee to be chosen from a list of QA Engineers (User Group called "QA")
In Test
The QA Engineer (qa_one) verifies that the problem has been resolved, and then uses the transition Mark Tested to advance the issue to the Tested state and assigns the issue to the Build Manager (bld_mgr). If a problem has not been resolved and needs to be returned to Development, the QA Engineer can move the issue back to the In Development state and assign it to the developer who worked on the issue by using the Reject transition. For each of these possible paths, the QA Engineer enters information in the Test Description and Test URL fields. The Test Date is automatically updated.
This is implemented by:
Workflow Properties
- Configuring bld_mgr to be the manager of the Tested state
Transitions
- Defining a transition to move an issue to the Tested state where the assignee is the state manager
- Creating a transition to move an issue to the In Development state or <Previous State> where the assignee is the Last Assignee for the New State.
Task Fields
- Configuring Test Date (read only and initialized), Test Description (required), and Test URL (optional) to be presented during the Task operation for the transitions to the In Development and Tested states. The Fix Detail field is presented as a read only task field for the QA Engineer to reference when selecting this transition.
Tested
The Build Manager (bld_mgr) user is assumed to be the user in charge of packaging the product for release, and responsible for ensuring that all the desired fixes are included in the release. The Build Manager does what is necessary to make sure that the fix for the issue is included in the release, then advances the state of the issue to Released using the transition Release. The Date Released field is automatically updated.
This is implemented by:
Transitions
- Defining a transition to move the issue to the Released state where the assignee is TBD ("no one" as the processing for this issue has been completed).
Task Fields
- Configuring Date Released (read only and initialized) as a field to be presented during the task operation for the transition to the Released state
Released
This state indicates that processing of the issue is complete.
Closed
This state indicates that the issue will not be processed.
Deferred
This state indicates the decision on whether or not to process the issue has been deferred until a future date. The Process Manager can update an issue in this state by using the Update transition. The Update transition will keep the issue in the Deferred state and assigned to the same user (process_mgr). The fields Defer Reason and Priority are presented as optional fields during the task operation. The Process Manager is required to enter a history comment to describe what was changed within the issue when using the Update transition.
The Process Manager can decide to begin processing a issue by choosing the Schedule transition, which will place the issue in the Scheduled state and assign it to the State Manager (dev_mgr). The Process Manager can set the Priority field when choosing this transition.
This is implemented by:
Transitions
- Defining a transition called Update with Deferred selected as the New State (same state), <Same Assignee> set as the New Assignee and history comment required
- Creating a transition to move the issue to the Scheduled state and assign it to the state manager
Task Fields
- Configuring Defer Reason and Priority to be presented during the task operation for the transition to update a deferred issue
- Configuring Priority to be presented during the task operation for the Schedule transition

Return to Topics List

Sample Saved Charts

A set of sample saved charts are included in this template. The default Project and Form will be selected as part of the criteria. If your workgroup contains multiple projects and forms, these charts can be edited to include additional projects or choose a different form, if desired:

Project Status (default) [Users]

This metric will generate a pie chart, which displays the relative number of records in each possible state. It is designed to give you a quick breakdown of the overall status of a project. To limit the chart to a particular project or release, select a Saved Query that only displays (matches) the records for the project or release as the value for Input Records and click Show Chart.

Add Rate [Users]

This metric will generate two dimensional line chart with the number of records added during each week for the previous 26 weeks broken down by product (one line per product that has at least one record added in the last 26 weeks). It is designed to give you display trend information about the number of new reports (records added) for each product over the last six months.

Average Fix Time [Users]

This metric will generate a two dimensional bar chart with the average number number of days it takes to fix a problem, with one bar for each Severity. The time is calculated by using the difference between the Date Reported field and the Fix Date field of each input record. It is designed to easily see differences in how fast particular issues are fixed based on their Severity.

Fix Rate [Users]

This metric will generate a line chart, which shows the number of records that were fixed in each of the last 12 months. There is one line for each Request Type. And, the most recent month is a partial month (unless today is the last day of the month). A record is considered fixed if it moved into the Fixed state during the month. It can be used to view the number of fixes completed each month for the previous year. It allows you to distinguish by Request Type (e.g. Bug, Enhancement).

Fix Totals [Users]

This metric will generate a stacked line chart, which shows the cumulative number of records that have been fixed as of the end of each month for the last twelve months. As with Fix Rate, there is one (filled) line for each Request Type and the most recent month is a partial month (unless today is the last day of the month). A record is considered Fixed if it has moved into the Fixed state at some point prior to the end of the month. It can be used to see running totals of issues that were fixed in the previous year, broken down by Request Type (e.g. Bug, Enhancement).

Project Summary [Users]

This metric will generate a table, which displays the numbers of records added for each product in each row of the table. Each column breaks down how many records are currently in each state. It is designed to give you a quick breakdown of the overall status of each project. To limit the chart to a particular project or release, select a Saved Query that only displays (matches) the records for the project or release as the value for Input Records and click Show Chart.

Severity Trend [Users]

This metric will generate a three dimensional bar chart that displays the number of records added during each of the last twelve weeks, broken down by Severity. It can be used to see if the severity of records being added is changing over time.

Test Fail Rate [Users]

This metric will generate a line chart, which displays the number of times QA rejected a fix (a record moved from "In Test" to "In Development") during each of the last twelve months. There is one line per product. The most recent month may be a partial month. It is used to see how many items that were marked as Fixed, subsequently failed quality assurance testing. Note: a single issue (record) may have failed multiple times.

Test Pass Rate [Users]

This metric will generate a line chart, which displays the number of times QA accepted (passed) a fix (a record moved from "In Test" to "Tested") during each of the last twelve months. There is one line per product. The most recent month may be a partial month. It is used to see how many items that were marked as Fixed, subsequently passed quality assurance testing.

Workload [Users]

This metric will generate bar chart, which displays the number of records assigned to each user. This can give you a rough idea of the current workload. If you have a field that represents the actual work required for a particular item (e.g. Estimated Size), you can create your own chart to total the value(s) of that field for each user and display it in a similar fashion.

Workload by Project [Users]

This metric will generate a table, which displays in each row the number of records currently assigned to a user. Each column breaks down how many records were reported against each product. This can give you a rough idea of the current workload by project.

Workload Status [Users]

This metric will generate a table, which displays in each row the number of records currently assigned to a user. Each column breaks down how many records are currently in each state. This can give you a rough idea of the current workload by status.

Return to Topics List

Email Notification

The Web Site Development template is set up to notify users as follows:

On Add or Delete of a Record: The current assignee, the manager for the current state, and the reporter of the issue are notified

On Change of State to Released, Deferred, Duplicate or Closed: The user who reported the issue is notified when an issue is moved to a state where processing is stopped

On Change of Assignment: Both the current assignee and the manager for the current state of the issue are notified

Return to Topics List

Security

The Web Site Development template assumes a very simple security model reflecting a workgroup situation where all users are able to see any issue. This is implemented by setting Enable Record Visibility option under General Preferences in the Administration Task page to No.

In addition, the privileges related to editing the field of the issues have been removed from users that are not managers or Admin. With this configuration, users can rely on the Task operation to move issues through the workflow. This can be changed within the User Accounts section of the Admin page.

Return to Topics List

Need Support? Chat now...

PRN*	Numeric record identifier. Assigned at the time the issue is created.
Title	A one line text summary of the problem. Set at the time the issue is created.
Product*	Identifies the product related to the issue has been reported. Set at the time the issue is created.
Last Updated Date*	The date and time the issue was last modified. Set automatically as the issue is processed through the workflow.
Browser	Identifies the browser type related to the issue that has been reported. Set at the time the issue is created.
Platform	Describes the hardware or software platform where the issue occurs. An example is the operating system (e.g. Windows XP). Set at the time the issue is created.
Problem URL	URL of the web page where the issue was found. Set at the time the issue is created.
Request Type	Classifies the issue. Possible values are: Bug, Contract Requirement, Customer Feedback, Customer Problem, Enhancement. Set at the time the issue is created.
Severity	Describes the relative impact of the issue. Set at the time the issue is created.
Description	Full description of the issue. Ideally describes the nature of the problem and how to reproduce the behavior. Set at the time the issue is created.
Reported By*	Name of the user that reported the issue. Initially set to the name of the current user logged in. Set at the time the issue is created.
Date Reported	The date the issue was created. Automatically initialized, and set at the time the issue is created.
Workaround	Describes how to work around the reported issue. Set at the time the issue is created.
Status*	Current state of the issue. Changes as the issue is processed through the workflow.
Substatus	Describes the condition of the issue in the current state. Possible values are: None, In Progress. Optionally set by each user while processing the issue.
Assigned To*	User the issue is currently assigned to for processing. Set either manually or automatically during processing of the workflow.
Operating System	The operating system installed on the machine of the user who reported the issue. Set automatically when the ticket is created using the AutoFill feature.
Reporter's Web Browser	The browser installed on the machine of the user who reported the issue. Set automatically when the ticket is created using the AutoFill feature.
Screen Size	The screen size set on the machine of the user who reported the issue. Set automatically when the ticket is created using the AutoFill feature.
Estimated Size	Used to enter an estimated amount of time it will take for a developer to fix the issue.
Fix Date	Date when the issue was fixed. Set by Development when the issue is fixed. Automatically initialized to the current date/time.
Fix Detail	A Description of the action taken by a developer to fix the issue. Set by Development when the problem is fixed.
Test Date	Date when the fix was tested. Set by QA when the fix for the issue is tested. Automatically initialized to the current date/time.
Test Description	A Description of the action taken by a QA Engineer to test the fix. Set by QA when the fix is tested.
Test URL	A URL where the fix can be tested. Set by Developer when the issue is fixed.
Priority	Describes the relative importance of handling this issue compared to other issues entered in the system.
Close Date	Date when the issue was closed. Set by Process Manager when no development work will be done on an issue. Automatically initialized to the current date/time.
Close Detail	A Description of the reason for closing an issue. Set by the Process Manager when no development work will be done on an issue.
Defer Reason	Describes the reason an issue will not be worked on until a later date.
Duplicate Record #	Lists the record number of another previously-entered issue in the database which describes the same problem.
Date Released	Date when the fix for the issue was released. Set by the Build Manager when the fix for the issue is released. Automatically initialized to the current date/time.
Deleted*	Denotes whether the issue has been deleted.