Continuous Testing for (a) DevOps World

Contributed Articles

Continuous Testing for (a) DevOps World

This article was originally published on The New Stack

Interest in continuous testing has been growing for five years now — yet the more we talk about it, the more polarized the discussion becomes. Complicating the conversation is the fact that Agile and DevOps are both driving the need for continuous testing, but both require distinctly different things from a quality perspective. For Agile, we need to test faster and earlier. But DevOps demands a more deep-seated shift.

Janye Groll, CEO of the DevOps Institute, and Wayne Ariola, chief marketing officer for Tricentis, discussed this topic at DevOps World last year. And the discussion is still relevant as we enter DevOps World 2019 this week. Exploring the role of continuous testing in a DevOps world, they discussed:

  • Where testing is at odds with the core tenets of DevOps.
  • Why we’re beyond “shift left.”
  • The challenges of DevOps testing at the enterprise level.

Here is the video, followed by a summary of some of the highlights from the discussion:

DevOps Speed Makes the Testing ‘Speed Bump’ Hurt More

Ariola: If you increase the speed of anything, the speed bumps you hit hurt more. I couldn’t think of a better analogy for testing because testing usually stops the process or the quality cadence that you require in order to reduce the risk to your organization. It’s something that is a start/stop process today, and that has to evolve. If you’re a Global 2000 organization with some web or mobile frontend interfaces that drive engagement, as well as a set of backend systems that actually process those transactions, you need to smooth out that cadence to allow the testing process to be continuous — what we call Continuous Testing.

Groll:   That’s really interesting because “no handoffs” is one of the mantras of DevOps—and certainly “shift left” is the other. When we start to look at traditional IT, testing was always a downstream activity. The agile teams would produce something, it would go into some type of release process, and QA would be engaged as part of that. However, there was a barrier because it could be a two-week sprint that had a two-month testing cycle ahead of it downstream…