How to Handle Expected Results in DesignWise
While we don’t recommend using Expected Results as Parameters, the approach can have merits. This article will explore options & tradeoffs.
That approach would be preferable in the majority of situations, and you are likely well aware of how the data-driven Expected Results in Manual auto-scripts facilitate it. However, there are a couple of alternatives to keep in mind.
DesignWise Automate
1) Assuming the approval from the automation engineers, you can use the following kind of syntax to specify the unique validations:
2) If that number is high, it is better to create multiple Scenario blocks using the {} syntax.
Side note: for the avoidance of doubt, these two methods are not limited to Expected Results/”Then” statements and can be used for any steps.
Forced Interactions
First, you can specify the conditions (even one).
Benefits:
- No need to repeat the scenario blocks which saves the time on 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 there as well.
Downsides:
- For complex dependencies, extra intervention in the algorithm could reduce the 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
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 be used for a single dependency as well, 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.
How
Step 1: Add a parameter with the possible outcomes as values
As you probably guessed, this approach could struggle with dependencies across 3 or more “actual” parameters as constraints get more and more complex. Some of the challenge can again be mitigated using the freeze/reimport combination.