Originally published on 2015-05-09; fully revised and updated.
Continuous Delivery changes who owns quality, not just which tools run tests. This article is for engineering managers, developers, QA engineers, and DevOps practitioners who want to reduce release friction while keeping quality high. You will learn how QA responsibilities typically evolve from manual gatekeeping to scenario-driven sign-off and shared engineering accountability.

From QA gatekeeping to shared quality ownership
The original model describes a common path: teams begin with manual builds and late QA checks, then progressively automate builds and tests, and eventually shift to a model where developers own test implementation while QA focuses on acceptance intent, risk, and business-facing validation. The core idea is simple: quality improves when testing is built into delivery, not bolted on at the end.
QA maturity levels in a Continuous Delivery model
These five levels are best treated as a practical heuristic, not a formal industry standard. Teams may sit between levels depending on legacy systems, compliance requirements, and staffing.
| Level | Build and test setup | Primary QA role | Typical bottleneck | CD readiness |
|---|---|---|---|---|
| 0 | Manual compilation, little or no unit testing | Manual functional testing after development | Long feedback cycles and high defect escape risk | Very low |
| 1 | Automated build, some developer unit tests | Mostly manual QA validation | QA still becomes a release gate | Low |
| 2 | Automated build, strong unit tests, QA begins automation | Automated regression plus story sign-off | Dev and QA branch drift, rework loops | Medium but fragile |
| 3 | Developer unit + integration tests, better QA tooling | Broader automated validation and test reuse | “Dev complete” handoff queues | Medium to high, often costly |
| 4 | Developers implement app and test code; acceptance criteria drive automation | QA acts as domain expert, scenario author, and sign-off authority | Coordination quality and scenario clarity | High when discipline is strong |
Delivery workflow at a mature level-4 setup
At higher maturity, quality work moves earlier: acceptance scenarios are clarified before coding, automated checks run in CI, and QA sign-off focuses on intent, risk, and coverage rather than manual retesting of every change.
flowchart LR
A[Story with acceptance scenarios] --> B[Developer writes feature and tests]
B --> C[CI runs unit and integration tests]
C --> D{Pipeline green}
D -- no --> E[Fix code or tests]
E --> C
D -- yes --> F[QA reviews scenario coverage and risk]
F --> G[Deploy with feature flag]
G --> H[Demo, monitor, and release broadly]
Implementation patterns you can adopt now
Write acceptance scenarios before coding starts
Scenario-first planning makes QA intent executable and gives developers a precise target for automated tests.
Feature: Money transfer
Scenario: Successful transfer between active accounts
Given an active source account with balance 500
And an active destination account with balance 200
When the user transfers 100
Then the source balance should be 400
And the destination balance should be 300
And the transfer should be recorded in audit historyCode language: JavaScript (javascript)
Enforce automated quality gates in CI
Use CI stages to block promotion when any critical test layer fails. The exact tooling can vary, but the gating principle is consistent.
stages:
- build
- unit_test
- integration_test
- acceptance_test
- deploy
build:
stage: build
script:
- ./scripts/build.sh
unit_test:
stage: unit_test
script:
- ./scripts/test-unit.sh
integration_test:
stage: integration_test
script:
- ./scripts/test-integration.sh
acceptance_test:
stage: acceptance_test
script:
- ./scripts/test-acceptance.sh
deploy:
stage: deploy
script:
- ./scripts/deploy.sh
when: on_success
Use feature flags for safer production rollout
- Deploy code paths disabled by default for external users.
- Enable internally first for controlled validation and feedback.
- Roll out gradually while monitoring errors and user behavior.
Role split in a high-automation team
| Activity | Developers | QA or QABA | Business stakeholders |
|---|---|---|---|
| Acceptance definition | Contribute feasibility and edge cases | Lead scenario clarity and test intent | Confirm expected business outcomes |
| Test automation code | Own implementation and maintenance | Review for intent and coverage gaps | Usually not involved |
| Exploratory and risk-based testing | Support debugging and fixes | Lead focused exploratory passes | Participate in milestone reviews when needed |
| Release decision | Own technical readiness | Provide quality sign-off input | Approve for business-critical changes |
Common pitfalls
- Treating QA automation as a separate codebase detached from product development.
- Keeping a hard “dev complete” handoff that recreates waterfall queues.
- Automating test scripts without improving acceptance criteria quality.
- Assuming tools alone fix quality problems without role and process changes.
- Using feature flags without ownership, expiry, and cleanup discipline.
Bottom line: the strongest Continuous Delivery teams make quality a shared engineering responsibility, while QA provides domain-driven challenge, acceptance clarity, and sign-off confidence.
I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.
I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.
Find Trusted Cardiac Hospitals
Compare heart hospitals by city and services — all in one place.
Explore Hospitals