Page History
...
Value expansions cover card types and currencies we rarely experience in production. They also add extra variety to the amounts for boundary and format testing. We can then add this rule – “Amount[with discount] <-> Discount[“-10.00”]”- and see how TCD quickly generates the scenarios:
Side note: Keep in mind that only value expansions are populated in the export (not “value – value expansion” syntax), so they won’t interfere with the scripting for execution – i.e. the csv table or the Automate script would have only “100.00”, not “100.00 – without discount – medium”.
...
While the request body is lacking variety, we are more interested in what we are getting back – the ability to retrieve the member details correctly regardless of the member type, address format, other characteristics. So, we create the Test Case Designer model based on the important factors from the response structure, not the request one. The corresponding simplified scope could look like this:
For some parameters, the values are not obvious and come from the format differences instead of the content ones. Typical examples include:
...
For any CRUD operation type, you can also consider adding the “environmental” variables such as the channel the request is sent from, versioning of the protocol, etc. You can see the draft generated scenarios below:
Typically, the data dictionary section in the API documentation provides a great start to building the Test Case Designer model. Just remember to look at both request and response variables, both mandatory and optional ones, and think about the core underlying variation for each.
...