We generally suggest drawing a line between system inputs and expected outcomes and then handling the latter ones in the scripts or even after export.

That approach would be preferable in most situations, and you are likely well aware of how the data-driven Expected Results in Manual scripts facilitate it.

However, using Expected Results as Parameters can have merits. This article will explore options & tradeoffs.

TCD Automate

If you are scripting in Automate, there are two primary ways to address the difference in outcomes: 1) conditional steps and 2) subsetting.

1) Assuming the approval from the automation engineers, you can use the following kind of syntax to specify the unique validations:

The left part of the equation is dynamic, and it changes based on the scenario. The right part is fixed, and it determines the step verbiage. If the equation is evaluated as TRUE, the step is performed; otherwise skipped. Multiple conditions could be stringed together with AND, OR, etc. This approach is preferable when the number of unique steps is low compared to the overall length of the script.

2) If that number is high, it is better to create multiple Scenario blocks using the {} syntax.

Within each block, you have the flexibility to write a completely different script if necessary. Depending on the overall length, you may consider putting each block on a separate tab in Automate and placing the subsetting {} value in the Background section.

Forced Interactions

Another feature is the internal variable (at the bottom of the dropdown list) which comes from the Forced Interactions tab. First, you can specify the conditions (even one).

Second, the algorithm populates the extra column on Scenarios. Lastly, the column is referenced in the Automate script (the variable is NOT available in the Manual option).

Benefits:

• No need to repeat the scenario blocks, which saves time on the creation & maintenance of hardcoded text.
• Simple dependencies are easy to implement and review with the stakeholders.
• If you switch the overall execution approach to just the data table, you will already have the expected result populated.

Downsides:

• For complex dependencies, extra intervention in the algorithm could reduce efficiency and unnecessarily increase the number of scenarios.
• If the whole column is not populated, the script will get the value “No expected outcome” for blanks, which a) could cause confusion; b) would need to be treated as “skip the step” by the automation framework.
  • You could side-step this challenge with the freeze/reimport combination.
• This does not support differences in multiple steps, only in 1 line.

Expected Results as Parameters

Finally, let’s talk about why & how we can deviate from the training recommendation.

Why: multiple simple dependencies throughout the flow (i.e., you can have multiple action-result parameter pairs to use in multiple steps)

This approach can also be used for a single dependency, in which case the only difference from Expected Outcome is that the parameter requires constraints instead of forced interactions.

The downsides are the potential complexity of constraints and the “cluttered” artifacts like Mind Map and Parameter/Scenarios tables. As you probably guessed, this approach would struggle with dependencies across 3 or more “actual” parameters.

Some of the challenges can again be mitigated using the freeze/reimport combination.

How

Step 1: Add a parameter with the possible outcomes as values

Step 2: Tie the trigger values to the respective outcome with constraints

Step 3: Reference the parameter in the script