The Web Site Development Template

NetResults ProblemTracker

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 follow 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.

Data Record

The data record contains the following fields. Note that you can customize the database by adding to or removing fields, or changing any pulldown menu values. Field names with an asterisk are required by the system and cannot be removed from the data record.

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

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

Product* Identifies the product for which the record has been reported. Set at the time the record is created.

Browser Identifies the browser type for which the record has been reported. Set at the time the record is created.

Platform Describes the hardware or software platform where the problem occurs. Examples are the operating system (e.g. Windows 95), or the CPU (e.g. Intel Compatible). Set at the time the record is created.

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

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

Severity Describes how serious the problem is. Set at the time the record is created.

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

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

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

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

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

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

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

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

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

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

Date Tested Date when the fix was tested. Set by QA when the fix for the problem 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 for the fix is tested.

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

Priority Describes the relative importance of handling this record compared to other records entered in the system.

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

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

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

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

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

Deleted* Denotes whether the record has been deleted.

Workflow

It is assumed that records will be processed and moved through the workflow process by using the Task operation. The workflow implemented by the Web Site Development template is as follows:

State 1 - Reported
When a record 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 records 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 record by selecting the transition called Schedule. This transition will assign the record to the Development Manager (dev_mgr) and place the record in the Scheduled state. The Process Manager can also enter a Priority for the record when choosing this transition.
- Defer the processing of the record by selecting the transition called Defer. This transition will place the record in the Deferred state and assign it to the state manager of that state (process_mgr). The Process Manager can review deferred records at a later time and decide whether processing will resume.
- Close the record by selecting the transition called Close. This transition will place the record in the Closed state and assign it to TBD (no one - since this record will not be processed any further). The Process Manager will be required to enter a reason the record was closed in the Close Detail field. The Close Date will be updated automatically.
- Mark the record as a duplicate of another record by selecting the transition called Mark Duplicate. This transition will place the record in the Duplicate State and assign it to TBD (no one - since this record will not be processed any further). The Process Manager will be required to enter the record number of the original record that describes the same problem.
This is implemented by:
Workflow Properties
- Defining Reported as the Default Add State when a record 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 a record to the Scheduled and Deferred states where the assignee is the State Manager for each respective state.
- Defining transitions to move a record 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.
State 2 - 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 record to a developer (dev_one), a member of the "Developers" user group. This places the record in the In Development state. The Development Manager can also decide to defer a record by choosing the Defer transition, which will place the record in the Deferred state and assign it to the Process Manager (process_mgr).
This is implemented by:
Transitions
- Defining a transition to move a record 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 a record 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
State 3 - In Development
The Developer (dev_one) assigned to the record makes the changes necessary to address the problem and marks the task complete using the transition called Mark Fixed. This transition allows the Developer to enter a description and date of the fix as well as a URL to be used by QA to test the fix, advances the state of the record to Fixed, and assigns the record to the QA Manager (qa_mgr).
This is implemented by:
Workflow Properties
- Defining the qa_mgr as the manager for the Fixed state
Transitions
- Defining a transition to move a record to the Fixed state where the assignee is the State Manager
Task Fields
- 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.
State 4 - Fixed
Once the record has entered the Fixed state, the QA Manager (qa_mgr) assigns the record 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 a record to the In Test state with the assignee to be chosen from a list of QA Engineers (User Group called "QA")
State 5 - In Test
The QA Engineer (qa_one) verifies that the problem has been resolved, and then uses the transition Mark Tested to advance the record to the Tested state and assigns the record 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 record back to the In Development state and assign it to the developer who worked on the record 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 a record to the Tested state where the assignee is the state manager
- Creating a transition to move a record 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.
State 6 - 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 record is included in the release, then advances the state of the record to Released using the transition Release. The Date Released field is automatically updated.
This is implemented by:
Transitions
- Defining a transition to move the record to the Released state where the assignee is TBD ("no one" as the processing for this record 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
State 7 - Released
This state indicates that processing of the record is complete.
State 8 - Closed
This state indicates that the record will not be processed.
State 9 - Deferred
This state indicates the decision on whether or not to process the record has been deferred until a future date. The Process Manager can update a record in this state by using the Update transition. The Update transition will keep the record 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 record when using the Update transition.
The Process Manager can decide to begin processing a record by choosing the Schedule transition, which will place the record 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 record 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 record
- Configuring Priority to be presented during the task operation for the Schedule transition

Sample Saved Charts

A set of sample saved charts are included in this template. Click here to see details of these sample metrics.

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 record are notified

On Change of State to Released, Deferred, Duplicate or Closed
The user who reported the record is notified when a record 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 record are notified

Security

The Web Site Development template assumes a very simple security model reflecting a workgroup situation where all users are able to see any record. 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 records have been removed from users that are not managers or Admin. With this configuration, users can rely on the Task operation to move records through the workflow. This can be changed within the User Administration section of the Admin page.

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