If your job includes maintaining software quality and you approach your work from a DevOps mindset, QAOps is one of the terms you may be using these days. What is QAOps, what does it have to do with DevOps, and what does QAOps look like in practice? Keep reading for answers to these questions.
Defining QAOps
You may have noticed that the DevOps movement has spawned the creation of lots of DevOps offshoots, such as DevSecOps, DataOps and NetOps. Each of these spinoffs expands upon the DevOps concept by extending it to a new realm of IT operations, like security (in the case of DevSecOps), or network administration (in the case of NetOps). Thus, we live in a world where Ops now comes in many flavors (to use the terminology promulgated by the folks over at New Relic).
QAOps is one of those flavors (although it didn’t make New Relic’s list). Even though there is no official definition of QAOps, it can be defined in terms of two key principles:
Quality Assurance (QA) operations should be integrated into the CI/CD pipeline.
QA engineers should work closely with developers, IT Ops engineers and everyone else involved in the CI/CD pipeline. In other words, QA should not exist in a silo.
QAOps, then, takes the core ideas behind DevOps—the construction of an ever-flowing continuous delivery pipeline as the basis of software delivery, and the removal of the silos that separate the different teams that support that pipeline—and applies them to QA.
Achieving QAOps
What does QAOps look like in practice? The specifics will vary, of course, depending on the exact tools you use, how you organize your software delivery pipeline, and so on. But in general, operationalizing QAOps entails embracing the following high-level practices:
Automated testing. Although it’s not realistic to automate every test, you should strive to automate as many tests as possible—and automate those that will deliver the greatest benefit. Doing so is the only way to ensure that QA operations keep pace with the rest of the delivery pipeline.
Parallel testing. You also want your tests to run quickly so that they don’t slow down the delivery pipeline. Parallel testing (which means running multiple tests at once rather than performing tests serially) is a good way to ensure that this happens.
Test scalability. Your CI/CD pipeline will probably scale up and down. Your testing routines need to be able to do the same. Scalable testing requires having scalable infrastructure for hosting tests, as well as the ability to increase test speed when required.
Involving developers and IT Ops in QA work. As noted above, your QA team should not live in a silo if you want to make QA an integral part of your CI/CD pipeline. You can break down silos by doing things like involving your developers in writing software tests and asking Ops engineers to help identify user experience problems with production apps. This doesn’t mean that QA engineers should hand off these tasks entirely; the QA team should still own them. But it should strive to collaborate with other teams so that everyone has visibility into the QA process.
Perspectives on QAOps
QAOps is one of the less frequently used *Ops terms of the moment. Google produces only about 6,300 results when you search for the term, compared to more than half a million for DevSecOps and 14 million for NetOps, to cite just two comparative examples.
This suggests that relatively few people are using the term QAOps. And some folks question whether the word is useful at all, arguing that it’s just another example of people “making up stupid terms with ‘Ops’ appended at the end of them.”
On the other hand, there’s an entire book and (partially incomplete) website dedicated to QAOps. So it’s pretty clear that QAOps is a thing, at least among some members of the testing community.
In Defense of QAOps
Whether or not you think that the term QAOps should have been coined, and regardless of whether you choose to use it, I’d argue that the word is important because it has helped to draw more attention to the challenges and opportunities facing the QA community in the age of DevOps—even among people who think QAOps is a silly term.
That’s because the QAOps concept has helped to save QA specialists and software testing engineers from being left behind as the DevOps train rolls forward. Originally, DevOps was all about developers and IT Ops teams, even though they are hardly the only groups required to produce a successful application.
The security folks, network admin people and other groups latched on to DevOps soon enough, and in the process, they coined their own *Ops terms, as noted above.
It took longer for QA and software testing to become a central part of the DevOps conversation. The introduction of the QAOps term helps to reinforce their role, and it emphasizes the importance of efficient, automated software testing and QA in delivering quality applications.
Chris Riley (@HoardingInfo) is a technologist who has spent 15 years helping organizations transition from traditional development practices to a modern set of culture, processes and tooling. In addition to being an industry analyst, he is a regular author, speaker, and evangelist
