May 20, 2011

How To Make a TestTrack Field Required Based on State or Field Value

Helix ALM
TestTrack allows you to set fields as required, which applies throughout the entire lifecycle of an item. Sometimes, however, you may want to set a field as required based on the workflow state or another field. You can use triggers to ensure a field has a value before it reaches a state, or to ensure a field has a value based on another field. In both instances, the mechanics are the same, and this applies to all development, test, and requirement artifacts tracked by TestTrack. There  are three main components to using triggers to make a field required based on state or another field value:
  1. Filter - The filter returns the situation you want to prevent. The filter could just check to see if a field is empty or <not set>. It could also see if another field is set or has a value.
  2. Action to Trigger On - When do you want to enforce this? Is it before the item reaches a state? Is it anytime the item is saved?
  3. Action - For this example, I'm using the prevent action. I can also create a message that is displayed to the user to let them know that the field needs to be completed.

Requiring  a Field Value Based on State

In this example, a trigger is used to make sure the Risk field is set before a Requirement enters the "Ready for Review" state. To set this up, go to Tools > Administration > Automation Rules... and select the Triggers tab. To set up the rule, click Add. [caption id="attachment_8422" align="aligncenter" width="285"]Add Trigger Dialog Add Trigger Dialog[/caption] After the rule name is set, create a filter that returns requirements that have the Risk field not set. The following screenshot shows a filter that returns requirements that do not have the Risk field set: [caption id="attachment_8423" align="aligncenter" width="380"]Restriction for Filter Restriction for Filter[/caption] The next step is to configure when TestTrack will evaluate the filter. In this example, I want TestTrack to look at requirements that do not have the Risk field set before they make it to the "Ready for Review" state. Under Trigger When, choose "Requirement enters Ready for Review state". [caption id="attachment_8424" align="aligncenter" width="260"]Trigger When Tab Trigger When Tab[/caption] The last step is to set the action. Use the Prevent action to make sure a requirement doesn't make it to the "Ready for Review" state if the Risk field is not set. You can also enter a message that is displayed for the user to explain why the action can't be performed. [caption id="" align="aligncenter" width="285"]Prevent Action and Message Prevent Action and Message[/caption]

Triggering on Event versus Entering a State

If you are familiar with the TestTrack workflow, you know an item reaches a state by the use of a workflow event. When you set up triggers, you can also choose to trigger when a workflow event is added to the item. So what's the difference? If you need to prevent a condition before an item reaches a state, regardless of where in the workflow it is coming from, then you trigger before it enters the state. If you need to prevent a condition before the item reaches a state, but only when it comes from a certain direction in the worflow, then you choose to trigger on the event. Consider the following workflow: [caption id="attachment_8433" align="aligncenter" width="514"]Requirement Workflow (partial) Requirement Workflow (partial)[/caption] In this workflow, an item can get to the "Ready for Review" state by using the "Ready for Review" and the "Changes Made" events. Since I want to enforce the rule regardless of which event was used to get to the "Ready for Review", I chose to trigger when the requirement enters the "Ready for Review" state. If I only wanted to enfore the rule when it enters the state via the "Ready for Review" event, then I would have triggered when the event was added to the requirement.

Requiring  a Field Value Based on Another Field

As I mentioned before, the mechanics are the same, so let's focus on what you would do differently. It's common to use the Defect object in TestTrack to track more than just defects (e.g., Feature Requests, Questions and Change Requests). It doesn't make sense to set the "Steps to Reproduce" field as required for these. But for defects, this field is very important. So how do you do solve this? Use a trigger similar to the one configured above to prevent a user from creating a defect if the Steps to Reproduce field is blank and the defect type is one that needs the steps. The filter would need to not only check that the Steps to Reproduce field is empty, it would also need to check the Type field in the Defect. [caption id="attachment_8458" align="aligncenter" width="598"]Add Filter Window Add Filter Window[/caption] The previous screenshot shows a filter that returns any defects in TestTrack that have the Steps to Reproduce field blank and of type that would require steps to reproduce. Next, you need to decide when you want to enforce the trigger. For example, you could enforce it when a defect is added or when it reaches a specific point in the workflow. In this example, I'm going to require it when the "Defect is Created". If you want to enforce this all the time, in case the Type field is changed after the defect is added, add a second rule that uses the same filter, but triggers when the defect is changed. The action is the same as the other rule. Use the Prevent action to let the user know the steps to reproduce must be provided. The following screenshot shows the summary of the rule. [caption id="attachment_8462" align="aligncenter" width="384"]Trigger Summary Trigger Summary[/caption]