The Continuous Testing Model

Back in 2016, Dan Ashby wrote about the Continuous Testing Model, which emphasises the ability to test at every stage of the software development lifecycle.

What is The Continous Testing Model? Dan Ashby's Continuous Testing model argues that testing is not a phase or a tool, it is an activity that belongs at every single point in the DevOps loop. The standard DevOps infinity model (plan, code, build, test, release, deploy, operate, monitor) often omits testing from most stages, or treats it as one discrete step. Ashby's version places testing at each node.

Why it matters? It aligns quality practices with the more modern continuous development practices. The model makes the case that reducing testing to automation, or to a single pipeline stage, leaves most of the real risk unchecked. Testing is treated as investigation and information gathering throughout, exploratory, risk-based, and continuous, rather than a handoff that happens after development.

How it connects to continuous practices: The Continuous Testing model sits naturally alongside the broader shift in software development toward doing things continuously rather than in batches. Continuous integration, continuous delivery, continuous deployment — these practices all share the same underlying logic: shrink the feedback loop, catch problems earlier, and reduce the cost of change. Continuous Testing fits that same pattern. If you are integrating code continuously, you need to be testing continuously too. A pipeline that deploys fast but tests late is just shipping risk faster. 

The model also connects to the cultural side of DevOps, the idea that development, operations, and quality are not separate concerns handed off between teams, but shared responsibilities running in parallel. Continuous Testing makes that concrete for quality: it is not a department or a phase, it is a practice woven through every stage of the work.