A common request I hear from users is the need to support more than one workflow within a single TestTrack project. I call the concept workflow branching, but no matter what you call it the goal is to support multiple paths for a defect, testing artifact, or requirement to travel from creation to closure. This can be helpful if you’re handling different types of issues in the same project (defects and IT help desk tickets for example) or if you want to drive high priority issues through a more streamlined flow than features requests and non-critical bugs.

Three paths based on item type

Here is the start of a workflow with three “branches” that any given work item can travel. Getting this far is pretty straightforward; you need to create the four states and three events then set up the transition rules to define the actual pathways.

Create Workflow Branches

All of the initial work will be done within the workflow administration dialog, which can be accessed from the Tools > Administration > Workflow menu. On the States tab, click Add to start adding new workflow states (Fig. 1). On the Events tab, click Add to create the three new events which we’ll automate in just a minute (Fig. 2). Be sure you set the right resulting state, leave assignments unchanged, and turn off prompts for each event. Finally, click Edit under State Transitions in the Transitions tab to define the pathways (Fig. 3).

Fig. 1: Create your states

Fig. 2: Add workflow events

Fig. 3: Define the pathways.

Now if you click  Diagram Workflow, you should see something similar to the image at the top of this post. At this point, your branched workflow is usable but relies on someone deliberately applying an event to move new work items into the correct branch.

Automate Workflow Transitions

Software is great at executing mundane tasks consistently, so let’s set up TestTrack to handle assigning new items to the appropriate branch. To do that, we’re going to create some automation triggers via the Tools > Administration > Automation Rules menu. Go to the Triggers tab, and click Add to create your first rule. You’ll need three rules, one for each of the pathways in our branched workflow. Each will apply one of our three new events to every new item that is created in our TestTrack project.

  • Precondition – You’re going to want to filter by the specific set of criteria that determines if a new item goes down one of the three branched paths. A simple example would be Type == Feature Request.
  • Trigger When – Lots of options here, but for branching we want to watch new item creation.
  • Actions – Click Add, select Event, and choose the corresponding event based on the filtered criteria you just set up in Preconditions.

Trigger Rule Summary

Create a trigger for each branch, and then you’re ready to go live! More to come on interesting trigger conditions, and how to build out the actual workflow for a branch.

If you’re looking for help in getting your workflow setup, our Services team can help you remotely or at your location. The TestTrack Tune Up package specifically is a great option if you’re looking to get TestTrack up-to-date with the latest features, including workflow, user permissions, reporting, and data capture.

Share on Technorati . del.icio.us . Digg . Reddit . Slashdot . Facebook . StumbleUpon

Related posts:

  1. Up for Grabs Assignments
  2. How To Make a TestTrack Field Required Based on State or Field Value
  3. Three Quick Ways to Tweak the Default Requirements Workflow
  4. Using TestTrack Calculated Fields to Escalate Stagnant Issues
  5. Video: Analyzing a TestTrack Item’s Workflow History
9 Comments

Tags: , , ,

9 Comments to Supporting Multiple Workflows in TestTrack

Javier
May 21, 2013

At the end of your article you mentioned:
More to come on interesting trigger conditions, and how to build out the actual workflow for a branch.

Where can I find your article about build the actual workflow for a branch?

Thanks

Matt Harp
May 22, 2013

Javier, it doesn’t look there was actually any more to come unfortunately. I can’t find any blog posts since then that specifically look at creating a workflow path. As I find time this week or next, I’m going to work up a short blog post with example and then I’ll update the text here to link to that one. But probably won’t be live until early June.

There’s a (embarrassingly dated) workflow tutorial article on our Labs site. Lots of functionality/capabilities have changed since that was written, but the basic actions to create states and connect them with events and transition rules still apply.

http://labs.seapine.com/wiki/index.php/TestTrack_Workflow_Tutorial

Javier
June 13, 2013

Thanks Matt.
Please let me know once the post with examples that you mentioned in your 22-May comment is available.

Regards
Javier

Javier
June 13, 2013

Please ignore my previous comment, I just saw the link to your new post. Thanks a lot.

Javier
July 19, 2013

Hi Matt,

Following your instructions I implemented 3 different workflows for each of our issue types (in total 21 States and 41 Events).

Is working fine in our test project but in the Testtrack client menu under “Activities” we can see the 41 events every time (with not applicable ones correctly greyed out) but make it very hard to see the few that are active.

Is there any way to display in “Activities” menu only the available ones, the same way it does when using the web interface?

Thanks in advance

Javier Carrillo
GFG Group support manager

Matt Harp
July 19, 2013

Definitely, go to Tools > Admin > Project Options and on the first tab (General) there’s a Workflow Options block. Check the middle check-box there, and the Activities menu will only show events that can be applied to the selected artifacts.

Debbi Pannell
August 26, 2013

Hi Matt,

We’re implementing RM & TCM after many years of using Test Track Pro for tracking software defects. Needless to say, we have thousands of defects in various states and would rather not start over with a new project.

I’m trying to build a front-end that branches new items into RM, TTP, or TCM based on the Type (Requirement, Defect, Test Case) the user selects when entering a new item. The defects work well, but I can’t get the requirements or test cases to branch to their workflow. Is this even possible?

Any advice will be greatly appreciated. Thanks.

Debbi Pannell

Matt Harp
August 27, 2013

Debbi,

Each of those item types has their own workflow. So Requirements, Test Cases, Test Runs & Defects each have their own flow. You can do the branching within any of those item’s workflow and it works the same way as with defects, but you can’t automate the conversion of items.

For example, you can’t automate turning a defect into a requirement. That’s a manual process, you click a button on the Defect window then fill in the missing requirement details (you can pre-map fields under the Admin menu, to automatically copy data over from the defect to the requirement).

Does that help? If not, you could ping our Support team at support@seapine.com for some assistance.

[…] you know TestTrack supports multiple workflows? This can be helpful if you’re handling different types of issues in the same project (defects […]

Leave a comment

WP_Big_City

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

 

Spam Protection by WP-SpamFree