If you check Wikipedia, or google, you’ll likely come to the Consensus-version definition of Continuous Testing. That definition is fine, I guess, as far as it goes.
What it does not do in my book is provide enough of a litmus-test to say “Yes, this is, or is not, Continuous Testing.”
So I am proposing a definition with a little more meat on the bones. With something real, and not hand-wavy, people can disagree. That is okay. That is how progress has made.
I will say the term has come to mean only checks that run as part of a pipleine. At Excelon we can work with that, just as the term “Unit Tests” has come to mean automated checks that run in a tool like jUnit.
Continuous Testing is the process of executing setup, test execution, and teardown, of all automated checks. These tests run on a loop, for every version control change. Each change can be released to production without additional regression testing.
We worked to get that definition tight. As Anton de Saint-Exupery wrote “true perfection is achieved, not when there is nothing left to add, but when there is nothing left to take away.” We wanted each word to have maximal value. So, for example, the phrase “all automated checks.” In theory you could have some things you don’t run every time. Our Managing director, Matt Heusser, considered making that “of all run-every-time automated checks.” Any wider definition should include this greater term. It might be possible to come up with a better definition that covered more exception conditions Still, we found those three words just didn’t add enough value. The longer the definition, the more the actual message will be lost.
There are other infrastructure things you’ll likely need to do in order to eliminate regression testing. Multiple deploy points probably tops the list. With deploy points you can make a change to search with (some) confidence that the only feature at risk is search. Configuration flags can deploy dark then roll out to a limited user population or roll back. Extensive production monitoring and alerts advise the team of more problems earlier, before they can impact a large customer group. Observability makes it easy to debug complex problems in production. Those four, along with Continuous Testing, are mutually supportive, sort of like the old Twelve Practices of extreme programming. (If Matt gets the energy, he might pen something on Extreme Operations, or maybe not. The world doesn’t need a new manifesto, does it? For now maybe just call them the five cardinal virtues of DevOps. Now please don’t start and argument with me about the definition of virtue.)
For today, here’s a definition of Continuous Testing as it is being called and practiced that separates the wheat from the chaff.
Change our mind.