The modern software development landscape places a premium on speed. It’s good to be first to market. If you’re going to fail then you should fail fast. A rapidly evolving product can be shaped according to customer feedback, and fast turnaround allows you to stamp out defects and hone the software for your audience.

A continuous delivery pipeline enables you to act and deliver more quickly. But you need to build in quality metrics to ensure it retains a laser focus, and doesn’t become an out-of-control fire hose. It may require some front-loaded effort and resources to set an accurate measure, but the resultant software quality turns short term cost into long term savings.

Plan for quality

You can build the expectation of quality into your software development process from the start. Design your tests before a line of code is written. Create a test architecture that can be woven into your CD pipeline. Build a self-adjusting system that applies the right tests at the appropriate time in development, covering unit tests through to performance testing. That way you always have the real-time insight you need into your software quality.

Why wait?

Test-driven development can save time and resources. By waiting for functionality to be developed before writing up your automated functional tests you’re creating more steps to complete than is necessary, and slowing down the process.

You need real examples of each feature and piece of functionality in order to design and implement it anyway, so why not create them from the beginning? They can serve as acceptance tests and keep developers focused on the core requirements for your software.

This can only work if you ensure that you have group buy-in from day one. All stakeholders must be involved in the acceptance test design. If you fail to get the input you need about what constitutes a holistic view of your software quality, then you can expect feedback that raises new concerns down the line. By that time it will be more difficult and expensive to retro-fit new quality metrics.

Aim for automation

The more of your acceptance criteria you can automate, the better. It provides you with a mechanism for taking the temperature of your software whenever you want to, for a clear picture of its health.

Naturally, there will be acceptance tests that you can’t automate. You shouldn’t try to automate everything. There’s no substitute for human insight and it’s notoriously difficult to predict your end user’s first impressions.

Functional tests are ideal candidates for automation, provided your test architecture considers optimization for regression and remains flexible enough to accommodate new examples when required. For the most efficient use of your resources you need to build in an understanding of dependencies. You need control over the decision on what to test and when, based on the quality attributes you’re examining.

Failures will be flagged at the earliest eventuality for all stakeholders, maximizing your opportunity to address them quickly. By building these quality metrics into your CD pipeline you can go live with confidence.

About the Author/Viktor Clerc