...
See the part of the spec describing the System Under Test (SUT). This shows (in a simplifed way) the test environment. The general picture of a component being tested is as follows:
Here, the capability actually being tested (particularly truth conditions, e.g. pre- and post-conditions) is marked by the red arrow, e.g. a API call logically defined as 'create_ehr()'. These abstract definitions are formalised in the Abstract Platform spec, and are documented using UML and the usual class definition approach.
The actual thing being tested by any concrete test approach is of course the interface exposed for a concrete protocol - what the blue arrow points to in the first diagram. So for REST, we have a spec describing that, with definitions like the following.
So far so good. Now, in the conformance spec, we have a schedule table, with a row for each testable conformance point service call that looks like the following:
In this, in the second last column, is a logical test script, of which some are written, in Java / Java-like pseudo-code. E.g.
Then, in the last column, we have links to scripts for some tool (currently thought to be postman) for writing test scripts for the REST API. More columns would be added for other protocols.
Now, what we need to achieve is:
...