search cancel

Inability to alter the test case priority


Article ID: 200663


Updated On:


CA Agile Requirements Designer


Inability to alter the test case priority depending upon the complexity of each path.

Different Test Complexity value for test case depending upon the value.

At the moment we can’t alter the test priority for a test case depending upon the flow.

The idea we have planned to use is creating a variable Complexity which would contain different values ranging from 1-10 depending upon the path it traverses

To understand this, please consider the following scenario.

Model Scenario: User tries to login to a system, and has option to choose from collection of 4 operation and depending upon certain predefined parameters an alert is generated.


For the Flow mentioned above, Complexity variable is defined  for each output at multi output block scenario1,  as follows.


And the value is resolved using the following TDM functionality.

@case(^Complexity ^<1,N/A, ^Complexity ^<4,4-Low,^Complexity ^<7,3-Medium,^Complexity ^<9,2-High,Critical)@


As of now we can’t  map the Test data- Complexity so created to the Path attribute test complexity.


We tried created stored path custom variable called Test Prio which we later assigned to Test Complexity



Note: In the above casewe have hard valued it to 3-Medium!

Is there any way where we can map the value of the test data variable Complexity  so created with the test prio  path custom variable so that different values are populated depending upon the flow?!

 (Also we tried using the complexity factor which is defined at block level, but weren’t able to achieve any concrete results)


If the proposed solution is not possible/feasible to create, do let us know how we can achieve the desired result with any other method.


Release : 2.8



This isn't properly supported yet in ARD, I do have one workaround that allows them to do what they want to do in ARD 3.1, specifically:

1. In ARD 3.1 you can have data-resolvable path description (each path will resolve it's description):

2. This can reference variables like the @case()@ statement in their document

3. You can map path description to a field very easily:

While this is an abuse of the path description, prior to 3.1 (when users would have to set these path descriptions individually by hand), it does let the client do what they need to do.

I will also note that, in future releases, we intend to make this easier by connecting the custom fields and test data more fully.

One other workaround they can consider is simply having ARD upload a file as an attachment to the target integration which includes the value of the "complexity" - but that obviously is not ideal easier.

We encourage the customer to upgrade to ARD 3.1.