At first glance, QA teams may not appear to have much of a role to play in DevOps adoption. After all, DevOps (at least in the narrow, traditional sense) is about developers and IT Ops teams. So you might think that developers and IT Ops engineers need to be the ones to spearhead DevOps adoption.
But I’d disagree. Due especially to the cultural priorities that QA teams naturally embrace, QA engineers, too, can play a critical role in spurring the adoption of DevOps within an organization.
Let me explain…
What matters in QA culture
At the risk of being accused of spouting generalizations, I don’t think it’s too much of a stretch to say that most QA teams prioritize the following:
- Automation: Virtually every modern QA team embraces test automation. It’s the only way to test at scale across a wide range of environments.
- Holistic practices: The very nature of QA work demands a focus not just on individual elements of an application, but on how all of those elements interact. Sure, you might run tests against individual components of an app, but you also need to test how those components interact.
- Collaboration: QA work is also collaborative by nature. The job of QA engineers is not just to find problems, but to collaborate effectively with people who can help solve them.
Although there may be some variation out there among different QA teams, by and large, most embrace these three key cultural values.
QA culture and DevOps
Those three values happen to be key ingredients in DevOps too.
Automation is critical for building an efficient, reliable delivery chain. A focus on the delivery chain as a whole, rather than individual pieces of it, is part of what defines DevOps. And collaboration, or the breaking down of silos that separate different teams, is also part and parcel of what DevOps is all about.
It only makes sense, then, for QA teams to help lead the way toward DevOps for organizations that are working to adopt it.
How QA can encourage DevOps adoption
What might that look like in practice? Here are some specific ways in which QA engineers can steward DevOps adoption—or even become DevOps engineers themselves.
Your QA team might already be automating many of its tests. But it could work with developers and IT Ops to automate the handoffs that connect those tests to the rest of the delivery pipeline.
For example, the QA team could help configure build tools so that new releases are automatically built when they pass tests. Similarly, it could integrate tests with developers’ version-control systems in order to flag application components that fail tests.
By taking the automation expertise that QA teams already have and expanding it to other areas of the application delivery pipeline, your organization can move closer to having a fully automated, DevOps-friendly delivery chain.
Collaborating around testing
Your QA team probably already collaborates with developers to help fix problems that are identified during software testing. But the collaboration may not be happening in an efficient way. Here, QA teams have an opportunity to help erect the communication channels that fuel DevOps collaboration.
Those channels might vary depending on the specific tools you choose to use, but your QA engineers probably already have a sense (from previous collaborations with developers) of what works and what doesn’t. Maybe you choose to use Slack or similar messaging tools to facilitate communication. Maybe regular face-to-face meetings work best for your culture. Or maybe you’ll choose to create new roles that bridge both development and testing.
Whatever the approach, the QA team likely has vital, experience-based perspective to offer on how, exactly, to de-silo your organization.
Modeling shared ownership
At many organizations, the QA team is more likely than other technical teams to have collective ownership of tasks. It’s rare for a particular QA engineer to “own” a specific software test; instead, QA teams tend to write and run tests collectively.
For this reason, QA teams can serve as a model for other parts of the IT organization to adopt collective ownership. Developers who own individual pieces of code, or IT engineers who own certain servers or processes, can look to QA as a model of how to step away from individual ownership and replace it with a model of shared responsibility.
QA engineers need not be mere spectators as your organization adopts DevOps. On the contrary, the QA team can provide crucial guidance for other members of the IT organization as they work to embrace automation, shared ownership of IT assets and a holistic approach to application delivery.