If DevOps is being practiced, but the QAs and testers are still relegated to checking things in the corner, and are not explicitly and proactively involved in providing input into both applications and infrastructure code, are we perhaps doing the very opposite of what DevOps and quality assurance were meant to be?
Most of us know the tale of how DevOps was conceived, and I trust most of us have read Gene Kim's landmark The Phoenix Project as one of our first DevOps books.
Therein we learned that DevOps is meant to be a collaborative and efficient partnership to achieve a common goal. This means working software in a production system and reorienting your process to the customer.
But when apparent DevOps teams exclude other members, like security or quality assurance (QA), we have missed the point. DevOps is more than developers and operations engineers working together. It's intended for teams -- both operations and development. QA -- specifically Lean QA -- is, therefore, intrinsically a member of DevOps.
Where we find QAs with no input into operations and continuous delivery conversations -- because "they are not developers" -- we are in fact practicing a cargo cult. We're not doing DevOps, but an imitation and approximation of the real thing, because the real reasons of why have not been fully grasped.
If we are going to do DevOps and QA, it behooves us to know why we do it, and not only how.
The reduction of waste, such as rework, defects and friction, by holistically testing the whole system early, continuously and into production -- including measuring what really matters and incrementally improving thereupon -- and using your humans intelligently in doing so, is what we call Lean QA.
And it's what I consider essential to DevOps.
DevOps and QA: Trim the waste
DevOps and QA fundamentally assist with reducing the following waste:
- Project churn
- Slow response
- Unreliable and unstable systems
- Needless expenses
- Lengthy handovers
- Time delays
- Failed projects
- Manual overheads
- Double-handling and many similar issues
Every time a feature is double-handled -- such as the churn when a bug is discovered later -- we have incurred waste.
Can QA and the business side work together?
QA exists to improve the customer experience, and that surely has business value. But this still often leaves the business side wondering -- especially with more and more viable automated artificial intelligence testing -- if there are opportunities for QA to expand in the present software development model.
QA is feedback, and feedback kills waste
QA testers do not provide assurance; they help provide analysis and feedback. To minimize and reduce waste, you want to receive that feedback as early as possible and ensure the feedback occurs in meaningful levels and depths in your system.
Monitoring is a form of feedback on the system's behavior. Just like monitoring is feedback, so too is testing. Whether the testing is manual exploratory testing or automated tests, it's feedback. Testing tells you about components and relationships; monitoring tells you about the system.
QA -- testing and monitoring -- should be done early and continuously. Again, receiving early feedback enables one to act on that information and improve or course-correct as early as possible.
Your QA testers can and should be involved in these conversations. And if they cannot be involved, as their manager or peer, the onus is on you to empower them to become involved.
The days of QA telling you if you're OK to go live are numbered. The whole team should know that based on the continuous feedback they have been receiving.