Supporting Multiple Workflows in TestTrack

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.

9 thoughts on “Supporting Multiple Workflows in TestTrack

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

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

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

    Regards
    Javier

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

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

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

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

Post a Comment

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

Ready to Take the Next Step?

© 2015 Seapine Software. All Rights Reserved.

Privacy Policy | Site Map