DevOps had become a thing by then, and I asked Tom Lounibos, then the CEO of SOASTA, what he thought of the term DevTestOps.
“DevTestOps. DTO. I kind of like the speed element to it,” he said. “It sounds like a Camaro in the ‘70s.”
RELATED CONTENT:
Testing all the time
How does your solution help organizations find success with continuous testing?
A guide to continuous testing tools
It was catchy, and some in the industry tried to make it happen, but it was flawed, much as the term DevSecOps is flawed. In that 2012 column, I had even written, “Move over, DevOps. Well, more specifically, Dev, you slide over to the left, and Ops, you move a bit to your right. We’ve got to make room for Test.”
The problem, of course, is that the term still implied steps in a process, and too closely resembled waterfall practices of the day. DevTestOps was a handy way to let development teams know that test should no longer wait until the end of the development process, when fixing problems is costlier and harder to deal with. It was the beginning of the thinking that development should not be a linear process but rather a collaborative effort to ensure code worked correctly and was secure at all times.
In a continuous testing world, you’re testing during code creation, you’re testing during integration, you’re testing in your deployment pipeline, and you’re testing changes after software is delivered.
That is why DevTestOps, as a term, has not stood the test of time.
