What is Quality Assurance?
Well in time honoured fashion I shall quote directly from Wikipedia:
Quality assurance (QA) refers to the engineering activities implemented in a quality system so that requirements for a product or service will be fulfilled.
What does this mean for DevOps though? Well the end product is the software or application being provided so most people focus on its requirements when talking QA and DevOps.
Software development based on TDD/BDD and strict Continuous Integration practices are brought up frequently.
Do These Things (TDD/BDD) Typically Involve Both Development and Operations Staff Though?
OK. That sounds reasonable. They are certainly things you'd expect to be taking place within an IT team professing to practice DevOps. Do these things typically involve both development and operations staff though? No, they don't. Were they practiced within development teams before DevOps went mainstream? Yes, they often were (perhaps not often enough though).
While these development practices are part of the DevOps puzzle making them your only focus when it comes to QA and DevOps is a massive oversight. As mentioned in the above definition QA is about making sure that requirements (functional and non-functional) for your product or service are met. In the case of testing of code, or the end application, it refers to the requirements of the customer. Crucial, but not the full story.
What Does DevOps Deal With Fundamentally?
The relationship between development and operations staff. With this in mind let's consider development to be customers of operations for a moment. The product they require is a stable, efficient infrastructure upon which to build and host their applications. QA in this instance then needs to make sure that the requirements of the developers (and their applications) are being fulfilled.
This is an important thing to understand, and appreciation of it by operations will go a long way to solving the tension between the two teams that the DevOps movement was born to address. You don't need to dig much into the history of a typical IT department to find examples of quality infrastructure (in the eyes of the ops team) not meeting the requirements of the developers and their application. Of course there are frequently good reasons for this (eg: security) but the bottom line is that the degree to which the infrastructure is fit for purpose for the developers and their application directly affects the degree to which the application is fit for purpose for the customer.
...we can automate. That doesn’t ensure quality though, it only ensures consistency.
So How Can We Ensure Quality in Infrastructure and Configuration?
Well we can automate. That doesn't ensure quality though, it only ensures consistency. In the development space BDD is such a powerful thing because it tests based on the requirements of the end user. Saying "I don't need to test my infrastructure or config because it's automated" is like a developer saying they don't need to test their code because it does what it's written to do. The point is that you need outside validation.
QA for DevOps is, and probably always will be, a broad term. If you can't independently and automatically validate your infrastructure and application configuration though then there's a massive gap in your approach.
