{"id":415,"date":"2026-10-14T05:31:02","date_gmt":"2026-10-14T05:31:02","guid":{"rendered":"http:\/\/www.scmgalaxy.com\/tutorials\/2015\/05\/09\/qa-roles-and-levels-in-continous-delivery-model\/"},"modified":"2026-10-14T05:31:03","modified_gmt":"2026-10-14T05:31:03","slug":"qa-roles-and-levels-in-continous-delivery-model","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/qa-roles-and-levels-in-continous-delivery-model\/","title":{"rendered":"QA Roles in Continuous Delivery: A Practical Maturity Model from Manual Testing to Shared Ownership"},"content":{"rendered":"\n

Originally published on 2015-05-09; fully revised and updated.<\/em><\/p>\n\n\n\n

Continuous Delivery changes who owns quality<\/strong>, 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.<\/p>\n\n\n\n

\"QA<\/p>\n\n\n\n

From QA gatekeeping to shared quality ownership<\/h2>\n\n\n\n

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<\/strong>.<\/p>\n\n\n\n

QA maturity levels in a Continuous Delivery model<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

Level<\/th>Build and test setup<\/th>Primary QA role<\/th>Typical bottleneck<\/th>CD readiness<\/th><\/tr><\/thead>
0<\/td>Manual compilation, little or no unit testing<\/td>Manual functional testing after development<\/td>Long feedback cycles and high defect escape risk<\/td>Very low<\/td><\/tr>
1<\/td>Automated build, some developer unit tests<\/td>Mostly manual QA validation<\/td>QA still becomes a release gate<\/td>Low<\/td><\/tr>
2<\/td>Automated build, strong unit tests, QA begins automation<\/td>Automated regression plus story sign-off<\/td>Dev and QA branch drift, rework loops<\/td>Medium but fragile<\/td><\/tr>
3<\/td>Developer unit + integration tests, better QA tooling<\/td>Broader automated validation and test reuse<\/td>“Dev complete” handoff queues<\/td>Medium to high, often costly<\/td><\/tr>
4<\/td>Developers implement app and test code; acceptance criteria drive automation<\/td>QA acts as domain expert, scenario author, and sign-off authority<\/td>Coordination quality and scenario clarity<\/td>High when discipline is strong<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Delivery workflow at a mature level-4 setup<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

\nflowchart LR\n    A[Story with acceptance scenarios] --> B[Developer writes feature and tests]\n    B --> C[CI runs unit and integration tests]\n    C --> D{Pipeline green}\n    D -- no --> E[Fix code or tests]\n    E --> C\n    D -- yes --> F[QA reviews scenario coverage and risk]\n    F --> G[Deploy with feature flag]\n    G --> H[Demo, monitor, and release broadly]\n<\/pre>\n\n\n\n
Implementation patterns you can adopt now<\/h2>\n\n\n\n
Write acceptance scenarios before coding starts<\/h3>\n\n\n\n
Scenario-first planning makes QA intent executable and gives developers a precise target for automated tests.<\/p>\n\n\n
Feature: Money transfer\n  Scenario<\/span>: Successful transfer between active accounts\n    Given an active source account with<\/span> balance 500<\/span>\n    And an active destination account with<\/span> balance 200<\/span>\n    When the user transfers 100<\/span>\n    Then the source balance should be 400<\/span>\n    And the destination balance should be 300<\/span>\n    And the transfer should be recorded in<\/span> audit history<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Enforce automated quality gates in CI<\/h3>\n\n\n\n
Use CI stages to block promotion when any critical test layer fails. The exact tooling can vary, but the gating principle is consistent.<\/p>\n\n\n
stages:\n  - build\n  - unit_test\n  - integration_test\n  - acceptance_test\n  - deploy\n\nbuild:\n  stage: build\n  script:\n    - .\/scripts\/build.sh\n\nunit_test:\n  stage: unit_test\n  script:\n    - .\/scripts\/test-unit.sh\n\nintegration_test:\n  stage: integration_test\n  script:\n    - .\/scripts\/test-integration.sh\n\nacceptance_test:\n  stage: acceptance_test\n  script:\n    - .\/scripts\/test-acceptance.sh\n\ndeploy:\n  stage: deploy\n  script:\n    - .\/scripts\/deploy.sh\n  when: on_success<\/code><\/span><\/pre>\n\n\n
Use feature flags for safer production rollout<\/h3>\n\n\n\n
  • Deploy code paths disabled by default for external users.<\/li>
  • Enable internally first for controlled validation and feedback.<\/li>
  • Roll out gradually while monitoring errors and user behavior.<\/li><\/ul>\n\n\n\n
    Role split in a high-automation team<\/h2>\n\n\n\n
    Activity<\/th>Developers<\/th>QA or QABA<\/th>Business stakeholders<\/th><\/tr><\/thead>
    Acceptance definition<\/td>Contribute feasibility and edge cases<\/td>Lead scenario clarity and test intent<\/td>Confirm expected business outcomes<\/td><\/tr>
    Test automation code<\/td>Own implementation and maintenance<\/td>Review for intent and coverage gaps<\/td>Usually not involved<\/td><\/tr>
    Exploratory and risk-based testing<\/td>Support debugging and fixes<\/td>Lead focused exploratory passes<\/td>Participate in milestone reviews when needed<\/td><\/tr>
    Release decision<\/td>Own technical readiness<\/td>Provide quality sign-off input<\/td>Approve for business-critical changes<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Common pitfalls<\/h2>\n\n\n\n
    • Treating QA automation as a separate codebase detached from product development.<\/li>
    • Keeping a hard \u201cdev complete\u201d handoff that recreates waterfall queues.<\/li>
    • Automating test scripts without improving acceptance criteria quality.<\/li>
    • Assuming tools alone fix quality problems without role and process changes.<\/li>
    • Using feature flags without ownership, expiry, and cleanup discipline.<\/li><\/ul>\n\n\n\n
      Bottom line:<\/strong> the strongest Continuous Delivery teams make quality a shared engineering responsibility, while QA provides domain-driven challenge, acceptance clarity, and sign-off confidence.<\/p>\n","protected":false},"excerpt":{"rendered":"
      This guide reframes QA roles across five delivery maturity levels, from manual testing bottlenecks to team-wide quality ownership. You\u2019ll get a clear progression model, a delivery workflow diagram, and practical CI and acceptance-testing examples.<\/p>\n","protected":false},"author":1,"featured_media":3464,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[2],"tags":[1691,1690,1689,1692,1687,1688,1694,1693,1697,1696,1695,779],"class_list":["post-415","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorised","tag-cd","tag-continuous-delivery","tag-levels","tag-model","tag-qa","tag-qa-roles","tag-qa-teams","tag-quality-management","tag-role-of-testing","tag-software-testing","tag-testers","tag-testing"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/415","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=415"}],"version-history":[{"count":3,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/415\/revisions"}],"predecessor-version":[{"id":79285,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/415\/revisions\/79285"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media\/3464"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=415"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=415"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=415"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}