What it does
Classifies the integration level, picks an integration strategy, derives interface conditions and cases, and builds an interface coverage table; implements at the API/integration level where feasible.
When to use it
When testing interactions between components or between the system and external services/systems.
Prerequisites
qa.config.yml; paths.docs_dir; paths.tests_dir; tooling.mocking (service virtualization); tooling.contract; environments; risk_areas.
Output
ISO/IEC/IEEE 29119-3 Test Design Specification for the interfaces under test -> paths.docs_dir/INTEGRATION-TEST-<target>.md.
Mechanics
How it works
- Read config and resolve the integration target from arguments
- Classify each interface as component-integration vs system-integration
- Choose an integration strategy (top-down / bottom-up / functional, or big-bang) and record stubs/drivers/mocks
- Derive interface conditions and cases with EP, BVA, decision table; cover error/timeout/sequencing/transaction paths
- Build the interface coverage table and mark virtualized vs real externals
- Implement at the API/integration level, run against environments, report interface coverage as counts
Why it works
The theory behind it
The integration test levels (CTFL §2.2.1). Interfaces, not units, are the risk surface; incremental integration localizes the fault when something breaks. Integration points are where defects cluster (Principle 4).
CTFL v4.0 §2.2.1 · §4.2
Example
See it in use
> /qa:integration-test "checkout → payment-gateway"✓ Correct when It states an integration strategy (incremental) and uses stubs/drivers for the gateway.