Cloud-native and serverless systems create a different assurance problem from conventional monolithic applications. A test strategy can appear complete while missing the failure modes created by distributed execution, infrastructure configuration, permissions, retries and event-driven behaviour.
Assurance must reflect topology
Testing evidence should be segmented by where risk exists:
- Service-level integration: component interactions, API contracts and database behaviour.
- Environment-level integration: cloud services, IAM permissions, networking, configuration and infrastructure-as-code.
- Cross-system behaviour: end-to-end event flows, retry logic, dead-letter handling, timeouts and recovery.
- Operational evidence: observability, tracing, alerting, performance and failure diagnosis.
The danger of over-mocking
Mocks are useful for fast feedback, but excessive mocking removes exactly the behaviour that integration testing should expose. Permission boundaries, throttling, eventual consistency, routing, cloud-service configuration and infrastructure interaction cannot be proven by a stub that behaves exactly as the test expects.
Representative infrastructure, ephemeral environments, dedicated test accounts and reproducible infrastructure-as-code improve the evidential value of the test result.
Serverless requires layered evidence
- unit evidence for business logic separated from runtime wrappers;
- integration evidence against deployed endpoints and services;
- event-path testing for triggers, idempotency and retry behaviour;
- observability evidence showing that failures can be detected and diagnosed;
- latency and cold-start evidence where performance is business-critical.
A green dashboard is not enough
The assurance question is whether the test evidence represents the architecture and the operational risks that matter. Passing tests on the wrong layer can create false confidence. The stronger the distribution and infrastructure dependency, the more important it is that assurance examines evidence below the user interface.
Pipeline quality controls should reinforce this evidence rather than replace it. See CI/CD Quality Gates as Delivery Assurance Controls.
Independent assurance perspective
Enigma’s Evidence-to-Decision Assurance Model treats architecture, testing and operational evidence as parts of the same readiness judgement. The objective is not to mandate a particular framework or cloud pattern. It is to establish whether the evidence is sufficient for the client decision being made.