From Seapine Labs

Posted by Cremerf

TestTrack's powerful, configurable workflow is one of its key features. The workflow is used to track the items in a given project, such as defects (TestTrack Pro), test executions (TestTrack TCM), or requirements (TestTrack RM).

Implementing the right workflow is key to getting the most out of TestTrack. Following is a simple tutorial that explains the various workflow components and how they work together.

Contents 1 Overview 2 Configuring the Workflow 2.1 The Process Flow 2.2 Configuring the Workflow in TestTrack 2.3 Summary 3 Enhancing the workflow 4 Need Help?

[edit] Overview

The TestTrack workflow consists of three main components:

• States

• Events

• State Transitions

States: A state represents a stage or a step in the process. States can either be Open or Closed. Any state with an attribute of Closed is closed in TestTrack and all rules and settings that apply to closed defects will apply, like notifying the defect submitter.

Events: An event represents an action. The action could be an assignment, a comment, or any action that may change the state of the defect. Best practice is to use verbs for event names. Important actions on the item that require tracking should be an event in the Workflow.

State Transitions: A state transition makes an event available at the specified state or states in the workflow. These are used to ensure that an action can only be performed at specific stages in the process. This is key in enforcing a process as you make an event available only after a required event has already taken place.

[edit] Configuring the Workflow

In this tutorial, I create a workflow for TestTrack Pro, but the same concepts apply to all TestTrack products.

First, I created a new TestTrack project and deleted all states (except for the Open state) and events from the workflow. Note that TestTrack creates a default workflow and you may only need to make minor modifications so this approach may not be the most practical. This approach is purely for learning purposes. Figure 1 shows the workflow diagram at this stage:

[edit] The Process Flow

The process flow I am going to implement for this worklow is a simple one. When an item is added to the project, it is reviewed to determine if it should be accepted or rejected. If rejected, the item is closed. If it is accepted, an effort estimate must be made.

In this scenario, the development effort is the only estimate needed. Once an estimate is entered, work can begin. The assignee will work on the item and update progress daily, entering the number of hours spent that day and hours left. After the development work is completed, the item is assigned to QA for verification. If it passes verification it is closed; otherwise, it is routed back to the developer for further action. Once the further action is completed, it is routed back to QA for verification. The hand off between development and QA may happen several times until the item is verified and closed.

[edit] Configuring the Workflow in TestTrack

To access the workflow configuration dialog, log in to the project and select Tools > Administration > Workflow.

In the Configure Workflow dialog you will see a tab for each of the workflow components (states, events, and transitions). Figure 2 shows the Configure Worflow dialog in the TestTrack Client after deleting all the mentioned objects.

The workflow already has one state, Open. According to the process flow outlined above, the item needs to be reviewed to determine if it should be fixed or rejected. Before this can be done, it must be assigned to a user to do the review. So, we need to create an assign event that is available from the Open state.

• Click the Events tab in the Configure Workflow dialog.
• Click the Add button. The Add Event dialog opens.
• Enter Assign in the name field.
• Optionally enter a description of the purpose of the event.
• This event will not update the status itself, so under Resulting States select <No State Change>.
• Under Assignments select Event Results in a New Assignment.
• Optionally choose to allow multiple assignments.
• The remainig options will be left with their default settings as this event's only purpose is to do assignments. Some of the remaining options will be covered in later events.

Figure 3 shows how the event is configured up to this point:

• Next, click the Custom tab.
• Under Custom Event Icon you can assign an icon for this event. The Icon is used when accessing the event from the Worflow toolbar and Activities menu. Note: Under the server installation directory there is a Workflow Icons directory where you can find several icons for use.
• Click the Add button to save the event.

The last thing we need to do is to set its transition. Right now the event is free floating and cannot be accessed from any state.

• Click the Transitions tab.
• Under State Transitions click Edit.
• The Edit State Trasitions dialog opens. This window is a table (or grid) where the columns are the events and the rows are the states. For each row (state), place a check under the column for each event that should be available from that state.
• Place a check under the Assign column on the Open row, as illustrated in Figure 4.

Now that we can assign an item, we can address how to implement the review process. We need to track the user that approves or rejects the item, as well as any notes and when it happened. We will also need to filter based on this, so we can get a list of only approved items, if needed.

Given these requirements, we will create an event for each action we want to track. Each event will take us to separate states, which will come in handy for filtering. We could create a single event that could result in either state, but this would complicate filtering or reporting on approve versus reject actions.

First, we will create the two states we need.

• Click the States tab and click the Add button.
• Enter Rejected for the State Name.
• Optionally enter a Description.
• Set the Attribute to Closed.

Figure 5 illustrates the configured state:

• Click OK to save the state.

Repeat the same steps above to create an Approved state. The only difference is that this state will have an attribute of Open.

Now we need to create the events that will take us to each state. These events are similar, except we will add a custom field to the reject event so the user can select the reason for rejecting the item.

• Click the Events tab and click on Add.
• Enter Approve as the name of the event.
• Select Approved as the resulting state.
• Select Event clears the current Assignment under Assignments.
• The remaining options are left with the default settings.

Figure 6 illustrates the event as it stands:

• Optionally click the Custom tab and assign an icon to this event.
• Click OK to save the event.

Next, we need to create the event we will use to reject an item and close it.

• Click the Add button again to create the next event.
• Enter Reject as the name of the event.
• Select Rejected as the resulting state.
• Select Event clears the current Assignment under Assignments.
• The remaining options are left with the default settings.
• Select the Custom tab and click on the Custom Fields... button.
• The Setup Custom Fields dialog opens.
• Click on Add....
• Enter Reason for the Field name.
• Enter Rejection Reason for the Long label.
• Enter REJ_REASON for the Field code.
• Select Pop-Up Menu for the Field type.
• Click the Setup Pop-up Menu Items... button and add the following values:
  • Not our bug
  • Fix not practical
  • Scope too great
  • Other
• Optionally click the Choose Icon... to assign an icon to the event.
• Click OK to save the event.

The last thing we need to do for both events is set up the state transitions.

• Under the Edit State Transitions window place a check on the Open row under the Approve column and the Defer column.

Figure 7 illustrates the workflow diagram as it currently stands:

Next in our process flow is entering an estimate for development time. We are going to handle this as an event for a couple of reasons. First, making it an event allows us to insert it at a specific point in our flow. If it was just a field on the defect window, it could be set any time. Also, an event tracks who did it and when it happened.

Also, we are going to have this event result in a new state since we want to require that an estimate is entered before any coding can begin. Using a workflow event that does not change states would not allow this.

First, we create a new state named Estimated with an attribute of Open. Next we create the Estimate event. The event is created with the following settings:

• Resulting State is set to Estimated.
• The Assignments option is set to Event results in a new assignment. A development lead will enter the estimate and at the same time assign it to a resource to work on.
• The Time Tracking option is enabled and set to Hours from last entered event of this type. This setting should not matter much as it isn't likely that we'll have more than one instance of this event. Even then, we will only care about the estimate made in the last instance of this event, not the sum of all.

Once the event is created set the State Transitions so it is only available from the Approved state. Figure 8 illustrates the workflow with the new event and state:

We are now ready to implement the portion of the workflow that will deal with working with the actual defect. The process dictates that the individual will enter daily progress updates, including time remaining.

We will implement an event that the individual will use to indicate that progress has started. This will update the status to "Dev in Progress", from which an "Enter Progress" event will be available. Once work has been finished, the individual will perform a "Finalize" event which will assign it to QA for verification.

So we create a new state called Dev in Progress and set its attribute to Open. Next, we create a Start Work event with the following settings:

• Resulting State is set to Dev in Progress.
• All remaining settings are left intact except for Do not show the dialog box when entering this event, which should be checked.
• This will make it a silent event, meaning the user will not get a dialog. We are only concerned with the user and time that this event is performed, which is automatically recorded.

Next, create an Enter Progress event that will allow the individual working on the item to enter daily progress. The event is created with the following settings:

• The resulting state is set to No State Change.
• The Time Tracking options are enabled and set to display the Sum of hours from all events of this type. This will allow us to see the entire effort spent on this item when viewing it from the list window or reports.
• A custom field (text field with Decimal format) is created for the user to enter remaining work left.

We now have two new events, better set the state transitions before we forget! Set the Start Work to be available from the Estimated state and the Enter Progress event from the Work in Progress state.

Figure 9 below illustrates the workflow up to this point.

The next portion of the workflow is finalizing development and then assigning it to QA for verification.

• Create a state called Finalized, with an attribute of Open.
• Create an event called Finalize, setting its resulting state to Finalized. All other settings can be left as default.
• Set the state transition fo the Finalize event is available from the Dev in Progress state.

The Finalize event is used by the dev resource to indicate that the development work is complete. This event should only be entered if the last Enter Progress event had 0 remaining hours.

• Create a new state named Verified with its attribute set to Closed. Defects will go to this state if QA verification has passed.
• Create a new state named Verified failed with its attribute set to Open. Defects will go to this state if QA verification fails.
• Create a new event named Verify. This event will have two resulting states, Verified and Verified Failed. It must also clear the current assignment. All other settings can be left with the default values.
• Set the state transitions so the new Verify event is available from the Finalized state.

Since we are not as concerned with tracking the pass/fail ratio of users, we are using a single event. This also comes in handy for this tutorial, since it gives us an opportunity to have an event with multiple resulting states, which we have not had yet.

We are interested in tracking how often a dev resource starts work on a brand new item versus one that failed his or her work. To do this we will use a different workflow event to similar to the Start Work event.

• Create a workflow event named Resume Work.
• Set its resulting state to Dev in Progress.
• Remaining settings should be left as default.
• Set the state transitions so the event will be only available from the Verified Failed state.

Figure 10 illustrates the workflow as it now stands:

The main flow is finished. The next thing to look at are assignments. At this point, the Assign event is only available when the defect is first submitted. We need it to be available at other points in the workflow so assignments can be made. Remember that we configured the Estimate event to allow assignments, so making the Assign event available from the Estimated state might not make much sense.

For this example, the state transitions are set so the Assign event is available from the following states:

• Open - assign to user to determine approval
• Approved - assign to user to estimate effort (who will assign it to dev resource)
• Finalized - assign to QA resource to verify item
• Verified Failed - assign back to dev resource

Figure 11 shows the workflow diagram with the assign event made available to states listed above:

[edit] Summary

Following are screenshots that show the various windows of our configured workflow. First, figure 12 shows the list of all defined states:

Next, figure 13 illustrates the events defined for the workflow. Note that all of the icons chosen for the events came from the Workflow Icons directory:

Figure 14 summarizes all of the resulting states for the events listed on Figure 13. This was obtained from the Transitions tab.

Finally, figure 15 shows all of the state transitions.

[edit] Enhancing the workflow

The workflow we have configured could be further enhanced by using automation rules. Here are some ideas:

• Auto assign at certain points in the workflow. For example, when a defect enters the Verified Failed state, auto assign it to the dev resource that did the work.

• Enforce that the Finalize event can only be accepted if the last instance of the Enter Work event has 0 hours remaining.

• Use escalation rules to ensure that defects that sit untouched for extended periods of time are addressed.

[edit] Need Help?

If you have minor questions, the user guide should be able to answer this. You may also contact Seapine Support.

If you need help configuring the workflow, translating your process to TestTrack, or just want somebody to do it for you, contact Seapine Services.