QAOps: What It Is and How to Start

Most engineering teams already run on DevOps: a CI/CD pipeline, infrastructure as code, a deploy triggered the moment a pull request merges. What frequently sits outside that pipeline, bolted on as a separate process with its own calendar, is quality assurance. QAOps is the name for closing that gap, treating testing as a first-class part of the same pipeline that already builds, deploys, and monitors the product, instead of a manual checkpoint that happens beside it.

The term is newer than the practice. Teams that already run automated suites inside their pipeline and treat a failing test as a blocked deploy are doing QAOps whether or not anyone on the team uses the word. What follows is what the practice actually looks like, how it differs from the QA process most startups start with, and a real way to tell whether a team is ready to adopt it.

What is QAOps?

QAOps is the practice of embedding quality assurance directly into a team's DevOps pipeline, so testing runs continuously alongside development and deployment instead of as a separate phase after code is written. It extends DevOps' own principles, shared ownership, automation, and continuous feedback, to quality specifically, making a passing test suite a required, automated part of shipping rather than a manual sign-off that happens beside it.

In practice, that means test code lives in the same repository as application code, a failing test blocks a merge the same way a failing build does, and the person writing tests has enough pipeline access to change what gets blocked and why. None of that requires new tooling most teams do not already have. It requires treating quality as an operational responsibility with the same automation and accountability already applied to deployment.

How QAOps differs from the QA process most startups start with

A team's first QA process is usually a person, not a pipeline. Someone tests a build before release, files bugs in a tracker, and gives a verbal or written go-ahead to ship. That model works at small scale, but it puts quality behind a manual gate that only runs when someone remembers to run it, and it puts the tester outside the same tools and cadence the engineering team already lives in.

QAOps replaces the manual gate with an automated one and moves the tester inside the pipeline rather than beside it. The shift-left principle already covers part of this, catching defects earlier in development rather than after. QAOps extends that same idea past testing timing into testing ownership: QA does not just test earlier, QA becomes a contributor to the pipeline itself, with commit access to the CI configuration, not just to a test suite that configuration happens to run.

The core practices behind a QAOps model

Three practices show up consistently in teams that have actually made this shift, not just adopted the name for it.

Test code lives in the same repository as application code

When tests live in a separate repository, or worse, in a separate tool entirely, they drift out of sync with the code they are supposed to verify. A QAOps model keeps test code versioned alongside application code, reviewed in the same pull request, and run against the same commit, the same discipline Playwright's CI/CD integration already assumes by design.

Quality gates block automatically, not on request

A gate that someone has to remember to check is not a gate, it is a suggestion. CI/CD quality gates that actually block a merge or a deploy when a required check fails are what make QAOps enforceable rather than aspirational. The gate does not need to cover everything on day one. It needs to actually block something before anyone should call it a gate.

QA participates in the on-call and incident response rotation

This is the practice most teams skip, and it is also the one that closes the loop DevOps was built around in the first place. When a QA engineer is present for an incident, the defect that escaped gets fed back into test coverage by the same person who will next decide what to automate, rather than passed along secondhand in a retro months later.

Three signs a team is ready for QAOps, and one sign it is not

Adopting QAOps before a team has the underlying pieces in place tends to produce a pipeline full of gates nobody trusts. Across the embedded engagements we have run, readiness tends to show up as the same few signals.

A team is likely ready when a CI/CD pipeline already exists and deploys run through it consistently, when there is already some automated test coverage even if it does not run on every commit yet, and when engineering leadership is willing to let a failing test actually block a deploy rather than requesting an override every time it happens. That last point matters more than the first two. A gate that gets overridden the first time it is inconvenient is not a gate, it is a warning label.

The sign a team is not ready is the inverse of that last point: a pipeline that exists on paper but gets bypassed under deadline pressure often enough that nobody trusts what it reports. Adding QAOps on top of an untrusted pipeline does not fix the trust problem, it just automates the ignoring of it. That gap is usually a QA maturity problem to resolve first, not a QAOps problem to solve around.

How to start adopting QAOps without a full rewrite

QAOps does not require replacing an existing QA process in one project. It requires moving pieces of an existing process into the pipeline one at a time, in an order that builds trust before it demands it.

Start with the highest-risk pipeline stage, not the easiest one. A team's instinct is often to automate whatever is simplest to script first, a smoke test on a staging deploy, for example. That builds confidence in the tooling but does little for actual risk. Start instead with whatever regression testing already catches the most defects manually, and automate that first, even if it takes longer to script.

Automate one quality gate before automating five. A single gate that reliably blocks a real category of defect earns more trust across a team than five gates added at once, several of which turn out to be noisy. Noisy gates get muted or overridden, and an overridden gate erodes trust in every other gate next to it, including the ones working correctly. A pipeline riddled with flaky tests before the gate work even starts will sink this step before it gets going, so resolve flakiness first if it already exists.

Give QA engineers real pipeline access, not just visibility into it. A QA engineer who can see the pipeline but cannot change the CI configuration cannot actually practice QAOps, they can only report on somebody else's pipeline. This is as much an org design decision as a technical one, and it is usually the part that determines whether QA process design work sticks past the first quarter or quietly reverts once the person who set it up moves to another project.

QAOps is not a new job title or a rebrand of an existing QA team. It is what a QA process looks like once it stops running beside the pipeline and starts running inside it, one gate, one repository, and one on-call rotation at a time.