Page History
In the help article related to APIs, we looked at the basics of applying TCD to testing the business logic (e.g. successful payment given multitude of factors, their interactions and associated rules).
...
Some products are new and have not been evaluated and/or sold yet.
| Table of Contents |
|---|
Modeling in Test Case Designer
Both approaches described below are viable, and the choice will depend on the specific system & testing goals, as discussed in the “Decision Points” section later.
Approach 1 – Whole response profile per test case
This is similar to the model designed in the API article. We will have a TCD parameter for each eligible request and response attribute that a) varies in finite manner; b) needs to be validated.
...
One script with “Then” line per attribute would cover all scenarios:
...
| Info |
|---|
| If there are attributes that don’t have format variations, can’t be blank and therefore wouldn’t become TCD parameters, the steps & validations for those would be hardcoded (i.e. without <> syntax) in the script. |
Approach 2 – Attribute per test case
To enable this in TCD, we will “transpose” our thinking from Approach 1. We will have a pair of parameters – “Validation Element” (the list of all non-status response attributes we need to check) and “Validation Value” (the list of all non-status response values we need to check).
...
A single script with a single “Then” line would cover all scenarios, because the key wording is dynamically tied to the TC table:
Decision points
Approach 1 – Pros:
- If there is any validation dependency between response attributes, this approach has a much higher change to catch defects.
- Less vulnerable to setup costs per TC (i.e., in an absurd example, if each test requires a unique API token that costs $1000, then executing a test per response profile is much cheaper than a test per attribute).
...
- Will have a much lower chance to catch any interaction defects (i.e. if Value is not retrieved correctly only when unrelated 3rd party vendor is involved).
- More vulnerable to setup costs per TC (higher total setup cost in the “$1000 per token” example above).
...
“
| Info |
|---|
| "Number of tests” as a metric becomes irrelevant in this comparison since the number of steps per test and the corresponding execution time/effort are too different. |
Conclusion
Hopefully this article has demonstrated how Test Case Designer can be applied to use cases where n-way interactions are not really the priority anymore. The speed of scenario generation and the one-to-many scripting move into the spotlight, so the tool can still deliver benefits in either approach.
...