Faster, more frequent releases at a higher quality. That is all DevOps is. That’s not hard to understand. What is hard to accept, however, is how much organizations are neglecting the latter part of this equation. Not only does a lack of focus on quality slow down releases in the long term, it does not fit with the overall goal of DevOps.
DevOps for existing development organizations is hard to implement. Entrenched development shops not only do not have the option to stop everything and start over, they are also slipstreaming new processes and technologies into an existing process, and an already-established delivery pipeline. I have seen many organizations for which the transition has worked out great, and other times where it has fallen flat. But I’ve very rarely seen an environment where QA drives change.
Because QA has a holistic view of the entire environment, they are uniquely positioned to look at the performance of not just the application’s code, but the delivery processes. They can see where the bottlenecks are, quantify technical debt, and easily point to areas where improvements can be made. The quality assurance department is a hub, connected to all the developers, processes, and all application features, versus the developers who have to maintain extreme focus in order to execute on their specific branch of code.
So, in my opinion, QA teams can lead the organization’s move to DevOps. The problem is that most QA teams are not empowered, and often don’t know what—and how much—they know. This is what needs to happen for QA to be the pivot point on the organization’s journey to DevOps:
Empower QA to recommend or dictate tools.
Transition QA to more test strategy.
Give QA greater exposure to the roadmap.
Change QA focus from reactive to proactive.
Allow QA to evangelize and educate on DevOps.
When the visibility of the QA team is leverage to influence processes and tools, the organization has already started to move into the DevOps framework, and done so without major organizational changes, special hires, or reliance on a tool to dictate it all.
And not only does QA have the big picture of all the tools, people, and processes that comprise an application, but they also have tooling that makes DevOps principles of Continuous Integration and Continuous Delivery.
Automated Functional Testing tools take QA a step further to better CI-CD: they allow applications to be tested quickly before a release, and even after releases to spot bugs faster than ever before—especially due to acceleration of manual testing and monitoring processes.
And because they are testing applications from the customer’s point of view, the connection from what the users are seeing on the screen to what support and development teams see is fully transparent.
Besides the lack of focus in many organizations, there are a few challenges. First, QA teams tend to be their own enemy. They often are not vocal enough, or don’t care enough about their impact on the delivery change. This is not something you can force teams to address. Second is the fact that many existing QA teams are not technical. And when they are not technical, they also do not tend to be strategic. Modern QA teams need to be technical, and they need to own the strategy for testing, not just execution.
If you are an existing development shop, making the move to DevOps won’t be easy. And sometimes it’s a bit of analysis paralysis trying to figure out how. However, there is a trick in your back pocket, and that is your QA team. They have a holistic overview of the development environment, and automation that can help simplify and accelerate the move to DevOps.
Chris Riley (@HoardingInfo) is a technologist who has spent 12 years helping organizations transition from traditional development practices to a modern set of culture, processes and tooling. In addition to being a research analyst, he is an O’Reilly author, regular speaker, and subject matter expert in the areas of DevOps strategy and culture. Chris believes the biggest challenges facing in the tech market are not tools, but rather people and planning.
