Automated testing executes software tests through tools or scripts with limited manual intervention. Treat tests as part of implementation: create them after the design and acceptance criteria, but before principal development, so misunderstandings surface early and confirmation bias is reduced. section 2.2.1
Use testing as a controlled progression through the software delivery lifecycle:
- Run integration, functional, and end-to-end tests as changes move through an automated pipeline. section 2.2.1
- Keep later environments based on the same commit SHA or tag as the initial environment. section 2.2.1
- Use multiple early testing instances and a preview environment before treating a change as a release candidate or production release. section 2.2.1 section 8.6
- Combine pipeline status checks with functional tests to detect both workflow failure and behavior failure. section 8.6
Platform change pipeline
A platform change progresses from an initial environment through hidden early test instances, integration, functional, and end-to-end tests, then reaches a preview environment before production. Throw-away infrastructure instances use the same pipeline-triggered workflow rather than a separate manual path. section 2.2.1 section 8.6
Figure 2.7 The software delivery lifecycle covers all stages from feature planning through running in production.
Follow the lifecycle from feature planning through production to see where automated testing controls progression. section 2.2.1
