Why Continuous Delivery Is Nothing without Real-Time Test Analysis

Pushing frequent releases of high-quality software to customers is beneficial for everyone. There's a great deal of business value in delivering software to the market faster than your competitors. Once realized, ideas can be rejected or pursued quickly. Customers can see their feedback shaping the product. Flaws, defects, and omissions can be addressed without delay.

But setting up a continuous delivery pipeline is about more than speed. How do you ensure that things don’t start breaking all over the place? It's an established fact that the later we encounter a defect or a problem in software development, the more expensive and difficult it is to fix. Accurately measuring quality and building it into the pipeline may seem like a lot of upfront effort, but it will pay dividends quickly.

Build Solid Foundations

You have to plan your continuous delivery pipeline with quality in mind from the outset. The only way to effectively do that is to design tests before development really begins, to continually collect metrics, and to build a test automation architecture integrated into your continuous delivery pipeline. The test automation architecture defines the setup of test tools and tests throughout the pipeline and should support flexibility and adaptability to help you meet your business objectives.

This test automation architecture should facilitate easy selection of just the right tests to be performed to match the flow of your software through your pipeline as it gets closer to release, from unit tests and code level security through functional and component testing to integration and performance testing. The further the software progresses along the pipeline, the greater the number of dependencies on other systems, data, and infrastructure components—and the more difficult it is to harmonize these variables. Making sane selections of tests to run at each moment in the pipeline becomes more and more important in order to focus on the area of interest.

Fail Fast

If we wait until functionality has been developed to write automated functional tests, we are creating a bottleneck. Designing tests during or at the end of a sprint is delaying feedback that we need right now. Why not apply the same test-driven development mindset we employ for unit tests to functionality? So, design tests as soon as possible; refining the backlog for subsequent sprints should include discussing and designing tests.

The development team is greatly helped when a set of examples of expected system behavior is available for each piece of functionality. These examples, with some syntactic guidelines and readily available tools, can serve as automated acceptance tests. Starting with failing tests and working to eliminate them maintains a laser focus on what developers should be doing. For this to work well, all stakeholders must get together at the beginning to design the acceptance tests.

The alternative is a drip-feed of failure as new stakeholders climb on board with fresh concerns as the software gets closer to release. The later a failure occurs, the more disruptive it is—and the more difficult it is to do anything to alleviate the relevant stakeholders’ concerns. Pull everyone in at the start, design the tests together, run the most important tests first, and start collecting the feedback you need about software quality from day one.

Automate and Optimize the Process

A concrete set of acceptance criteria in the form of automated tests gives you a clear signal about the health of your software. The easier it is to run these tests, the better, which is why you should automate where possible. There will be some intangibles that will prove tough to automate, but you may need them for a true measure of quality. Not all acceptance tests can or should be automated, but automating functional tests makes a great deal of sense.

It will be necessary from time to time to add new example test cases in to augment the existing functionality. It will also be necessary to optimize the tests available in the regression set to prevent this set from growing and containing superfluous tests.

You can't test everything all the time. Be pragmatic when you define which tests to run in any given situation. You need flexibility to select the right tests for inclusion and exclusion according to a variety of quality attributes.

Maintain a Real-Time Quality Overview

If a test is going to fail, it's better to know about it now. All the stakeholders should know about failures as soon as possible. If the software is passing your tests and meeting the acceptance criteria, then you can feel confident about the overall quality and proceed with the release.

Keeping things specific with examples and creating these acceptance tests as early as possible will increase the efficiency of your software development process. Furthermore, when possible reasons for failing tests can be identified through adequate monitoring, this may help to correct defects as soon as possible. The predictive value of trend analysis can help you take adequate measures before quality thresholds, such as a maximum duration for test execution, are breached.

Automated continuous qualification of all relevant test results (across all relevant test tools) is what enables you to provide real-time quality feedback. When this is built into your continuous delivery pipeline, you can ensure that your standards never slip.