I’ve been writing a bit the last several weeks on a few topics related to QA. Usually when I have a conversation on the topic, the question eventually pops up: “So how would you organize QA within an organization?”

Today I want to answer that question briefly.

First, though, I want to outline a common problem I see, which I see as a close parallel to the problem that DevOps is meant to solve:

• In many organizations, QA is set up as a quality gatekeeper. This puts QA and Development at odds with each other; QA playing defense, and developers playing offense. In the worst cases, this leads to inter-personal rivalries, hurt feelings, and resignations. But even on the most mature teams, with great inter-personal skills, this is not an ideal scenario from a productivity standpoint.

Compare this to the problem observed between developers and operations which lead to the idea of DevOps:

• In many organizations, operations is tasked with keeping the system stable, while development is tasked with changing the system as quickly as possible. This puts Ops and Development at odds with each other; Ops playing defense and developers playing offense.

Hmm. Seems a bit familiar.

The solution for Dev & Ops has been to align the goals of the two groups. Can we do the same with QA?

I believe we can.

If it’s true that…

[It is not] operation’s job is to keep the site stable and fast. Operation’s job is to enable the business.

I think it’s equally true that

It is not QA’s job to prevent bugs or other quality defects from getting into production. It is QA’s job to enable the business.

Of course there’s a ton of room for interpretation there. And I still haven’t answered the question of how QA fits within DevOps. In part, that’s becuase there is a fair amount of room for interpretation.

But let me finally make a concrete recommendation, based on my experience that has worked well in several organizations:

QA, like Ops, should work in a supporting role analogous to the operations-as-a-service team that is popular for operations. In this capacity, QA should:

• Ensure that the development team has the tools and infrastructure necessary to do testing (both automated and manual)
• Support the development team with mentoring, training, and virtual hand-holding when necessary.
• Conduct exploratory testing outside of the software delivery life cycle. The key here is that the QA team should not be a goalee or gatekeeper for code getting into production. In practice, this probably means that exploratory testing is happening on production systems; possibly on systems otherwise hidden behind feature flags.

Questions? Disagreement? I’d love to hear what you think!