Turn requirements into scenarios
Link each requirement to preconditions, stimulus, expected result and evidence. Replace vague statements such as correct operation or fast response with observable conditions and agreed limits.
Separate laboratory proof from installation-dependent checks. Emulation can exercise protocols but cannot establish actual sensor coverage, alignment or all load behavior. Carry those gaps into SAT.
Nominal and failure cases
Include complete flow, duplicate and out-of-order messages, outages, cancellation, invalid loads and restart with an open task. Verify coherent state, not merely an alarm on screen.
Use identifiable test data and repeatable initial conditions. Version the application, configuration and equipment model. Otherwise results may depend on leftovers from previous tests.
Load and observability
Represent mix, bursts and destination distribution. Uniform flow rarely exposes congestion. Measure per-stage response, queue age, resource use and backlog recovery.
Capture correlation between requests, commands and events so a failure can be assigned to its boundary. Screen recording helps but does not replace the states explaining the outcome.
Worked lost-completion test
The emulator executes T17 but suppresses completion. WCS follows the contracted query, wait or reconciliation behavior. When confirmation returns, T17 completes once. Repeat the event to check deduplication.
Record deviations, severity, ownership and acceptance conditions. FAT completion means that stage’s agreed evidence was accepted, not that the entire installation is ready for production.
Project verification criteria
- Link every requirement to a scenario and evidence.
- Version emulator, configuration and test data.
- Separate proven results from checks reserved for SAT.
Examples describe engineering decisions and test scenarios. Implemented interfaces, limits and features are defined by each project’s scope.