Verifying the output of the pipeline steps is one of the most important aspects in Continuous Delivery. It increases the software quality by detecting potential errors before going live. Proper verification creates reliability in the processes. By writing software tests in general and regression tests in particular, developers become confident in changing and refactoring functionality. Ultimately, software tests enable us to automate development processes.

Building binaries already executes code level tests. Other tests contained in the project may be executed in separate pipeline steps, depending whether they operate at code level or a running container. End-to-end tests, especially, require a running environment.

After the application has been deployed on test environments, end-to-end tests can be executed there. Usually, a project contains several layers of tests, with separate responsibilities, running in separate steps. There can be a great variety of tests, depending on the project and used technology. The approach is always to execute pipeline steps and sufficiently verify the outcome. By doing so, the risk of breaking new or existing functionality and introducing potential errors is minimized. Especially, container orchestration frameworks with their production-ready nature support companies in the goal to ship scalable, highly available enterprise applications with high quality. Chapter 7, Testing, covers all different manifestations of testing, including its execution in Continuous Delivery pipelines.

Failing tests will immediately cause the pipeline to stop and will prevent the corresponding binary from being used further. This is an important aspect to enable fast feedback and also to enforce software quality in the process. Engineers should absolutely avoid to bypass steps of the normal process and other quick fixes. They contradict the idea of continuous improvement and building quality into the Continuous Delivery process and ultimately lead to errors. If a test or quality gate fails, the build has to break and either the application's code or the verification has to change.

Failing tests should not only break the build but also provide insights into why the step failed and record the result. This is part of the build's metadata.