What it does
Derives test conditions per spec operation and implements automated API tests covering happy path, negative and boundary (EP/BVA), authorization (decision-table role matrix plus object-level/IDOR checks), schema validation, state and side effects, and cross-cutting concerns. Uses typed clients derived from the spec, data-driven cases, and independent parallel-safe tests; runs them and reports coverage as counts.
When to use it
For API test automation — building or extending automated tests for an endpoint, resource, or feature against the OpenAPI/Swagger contract.
Prerequisites
qa.config.yml; OpenAPI/Swagger spec (stack.api_spec_path) as the test basis; framework present; tooling.api/language; environments base_url_api; test_data.
Output
ISO/IEC/IEEE 29119-3 Test Procedure Specification(s) (API scripts) under paths.tests_dir (api/ subtree) + Test Execution Log when run + a counts coverage summary.
Mechanics
How it works
- Read config, validate input, and resolve the target to spec operations
- Derive conditions per operation across the six categories
- Apply EP/BVA and a decision-table role matrix; add an IDOR/BOLA check
- Validate every response against the OpenAPI schema
- Data-drive repeated partitions; use spec-derived typed clients
- Keep tests independent, parallel-safe, and tagged by risk tier
- Implement, run with tooling.api, wire smoke into the PR gate
- Report coverage as counts (operations in scope/covered/deferred)
Why it works
The theory behind it
Automation (CT-TAE) at the component-integration / API level with black-box techniques over API inputs; OpenAPI spec is the test basis, so the spec defines correctness; API/integration points cluster defects (Principle 4).
CT-TAE · CTFL v4.0 §2.2.1 · §4.2
Example
See it in use
> /qa:api-automate "/orders"✓ Correct when Tests are generated from the OpenAPI spec with schema validation, CRUD, an auth/role matrix, and negative/boundary cases.