- CT-QDO (Certified Tester Quality in DevOps) is the ISTQB certification on how to assure quality and test in teams that work with DevOps.
- It is a new Specialist module: syllabus version 1.0 was released in April 2026.
- Prerequisite: the ISTQB Foundation Level (CTFL) certificate; some development or testing experience is recommended.
- It has 4 chapters and requires at least 20.2 hours of accredited training over at least three days; the longest chapter covers automated and manual tasks in DevOps.
- The exam has 40 multiple-choice questions, lasts 60 minutes (75 in a non-native language) and you pass with about 65% of the points.
- It covers DORA metrics, CALMS, the three ways of DevOps, SRE, continuous testing, pull requests, CI/CD, API and contract testing, crowd testing, quality hunting, feature toggles, chaos engineering, observability, SBOM and containers.
- It is for testers, but also for developers, DevOps and SRE engineers, scrum masters and product owners.
On many teams, testers still feel DevOps "ran them over": the pipeline deploys several times a day, manual testing no longer fits the cycle and nobody is quite sure where QA belongs. The ISTQB CT-QDO certification answers exactly that: how quality is built into every stage of the DevOps value stream and what role testing, automated and manual, plays.
In this guide I explain what CT-QDO is, who it is for, its business outcomes, what the syllabus covers chapter by chapter, what the exam looks like and how to prepare.
What CT-QDO is and where it sits in the ISTQB portfolio
CT-QDO is an ISTQB Specialist module. The current version is v1.0, generally released on April 17, 2026. According to the syllabus, it exists because DevOps has become the mainstream way of building software in many domains and ISTQB wanted an international certification specifically for quality in that context.
The syllabus builds on Foundation (CTFL 4.0) and leans on the ISTQB Agile and test automation syllabi. As it explains, the Agile syllabi teach how testing works in an Agile team and the automation syllabi teach how automation is built and used; CT-QDO extends that into the DevOps culture. See the full map and prices in your currency in our ISTQB certification guide.
Who it is for and prerequisites
The syllabus targets quality and testing professionals in a DevOps environment, and ISTQB explicitly opens it to developers, DevOps and SRE engineers, scrum masters and product owners, because in DevOps quality is everyone's responsibility.
- Formal prerequisite: the ISTQB Foundation Level certificate (CTFL v4.0 or earlier) and an interest in testing and DevOps. If you do not have Foundation yet, start with our ISTQB Foundation Level 4.0 course.
- Strongly recommended: at least a minimal background in development or testing, such as six months as a system or acceptance tester or as a developer, and an accredited course.
- Useful but optional: knowing the Agile (Agile Tester) and automation (TAE or TAS) syllabi, and having seen a working CI/CD pipeline.
What you will be able to do: business outcomes
The syllabus defines nine business outcomes. A CT-QDO certified person can:
| Code | Business outcome |
|---|---|
| QDO-BO1 | Explain how quality assurance is supported by and contributes to DevOps concepts |
| QDO-BO2 | Understand the concepts of implementing DevOps in an organization |
| QDO-BO3 | Contribute to all value stream stages to assist in quality engineering |
| QDO-BO4 | Contribute to the DevOps loop implementation |
| QDO-BO5 | Describe how automation supports quality assurance in DevOps |
| QDO-BO6 | Implement test automation in DevOps teams |
| QDO-BO7 | Implement manual testing in DevOps teams |
| QDO-BO8 | Select tools supporting DevOps within the organization |
| QDO-BO9 | Understand technologies and practices that support quality in DevOps |
Learning objectives range from K1 to K3. Each chapter's keywords are examined at K2 (you must understand them, not just recall them). Hands-on objectives range from H0 to H2; almost all are H2, exercises with hints based on a realistic case.
Syllabus content chapter by chapter
| Chapter | Minimum time | Key topics |
|---|---|---|
| 1. Fundamentals of DevOps | 140 min | Key concepts, wall of confusion, DORA metrics, CALMS, the three ways, benefits and risks, roles, SRE, team topologies and anti-patterns |
| 2. Quality Assurance and Testing in DevOps | 360 min | QA across the value stream, test objectives by lifecycle model, continuous testing, pull requests, QA in discovery, CI, continuous delivery and deployment, release on demand, building a pipeline |
| 3. Automated and Manual Tasks in DevOps | 510 min | Single source of truth for testware, traceability, quality reporting, test data and environments, regression in the pipeline, API and contract testing, exploratory testing, crowd testing, quality hunting |
| 4. Tools and Practices in DevOps | 200 min | Tool capabilities, non-testing pipeline activities, release strategies, infrastructure as code, feature toggles, branching, chaos engineering, telemetry and observability, SBOM, containers |
Chapter 1. Fundamentals of DevOps
The chapter opens with DevOps key concepts and a metaphor every tester has lived through: the wall of confusion. Development wants to change fast; operations wants stability. The result is silos, manual processes and inconsistent environments. DevOps tears that wall down, and the syllabus stresses that QA and testing are key to doing so because they span both sides.
It then explains the DORA metrics used to measure delivery performance:
- Throughput: change lead time (commit to production) and deployment frequency.
- Stability: change fail percentage and failed deployment recovery time.
DORA added reliability (availability, latency, performance, scalability) as an operational performance indicator, and the syllabus shows how QA improves it through test-first approaches, non-functional testing, chaos engineering and quality hunting.
Next come CALMS (culture, automation, lean, measurement and sharing) seen through a QA lens, and the three ways of DevOps from The Phoenix Project: flow, feedback and continuous learning. For example, QA supports flow with test-first approaches, feedback with continuous automation and monitoring, and learning with quality events and strong regression suites.
The second half covers implementation in an organization: roles in a DevOps team, Site Reliability Engineering (SRE) with SLAs, SLOs and SLIs (for example, an SLO of "99.9% monthly availability" measured by an SLI of successful requests), and team topologies: Dev and Ops collaboration, fully shared ops responsibilities, or an SRE team. It also covers anti-patterns: Dev and Ops silos, "Dev doesn't need Ops" and the infamous "DevOps team" that only runs tooling.
Chapter 2. Quality Assurance and Testing in DevOps
Six hours on where and how QA adds value. First, across the value stream: quality of products, processes and people. Then it compares test objectives in DevOps with sequential and Agile models.
A central topic is continuous testing: testing from concept to production and beyond. Its principles: test early and often, cross-functional collaboration (quality belongs to everyone), integrated automation, monitoring and observability in production, and adaptive improvement. As an example framework it cites Janet Gregory and Lisa Crispin's holistic testing.
It also explains why pull requests are a quality tool: they encourage review and knowledge sharing, trigger automated tests, enforce standards with static analysis, improve traceability, favor small changes and act as a quality gate.
Then it walks through the DevOps loop stage by stage and QA's role in each: continuous discovery, continuous integration (CI), continuous delivery (CD), continuous deployment (with strategies such as canary, blue-green or dark launching) and release on demand. It closes with a K3 objective: implementing a CI/CD pipeline in six steps: model the value stream from commit to release with a walking skeleton, automate build and deployment, automate the commit stage, automate the acceptance stage, automate the release and evolve the pipeline.
Chapter 3. Automated and Manual Tasks in DevOps
The longest chapter, at more than eight hours, in three blocks.
How automation supports QA: a single source of truth for testware (test cases, scripts and data versioned alongside the code), automated traceability between the test basis and testware, uniform quality reporting in the pipeline that combines automated and manual results (a K3 objective), automated test data management, statistical analysis of test results over time (for example, to spot flaky tests) and standardized, controlled, automated test environments.
Automation in DevOps teams: how regression fits each pipeline stage, preparing API tests (K3), including contract testing between services, and a comparison of automation levels in DevOps versus Agile and sequential models. To practice API testing, our API Automation with Postman course is a good complement.
Manual testing in DevOps: yes, it still exists. The syllabus gives examples of valuable manual testing, explains how exploratory testing works with a CI/CD pipeline, how crowd testing supports a feedback culture and introduces quality hunting events (K3): small teams compete for a limited time to give the most valuable assessment of the product's quality level. Unlike bug hunting, the goal is not to catch the most defects but to build a shared view of quality and risk.
Chapter 4. Tools and Practices in DevOps
The last chapter is a broad tour, mostly K1 and K2. First, tool capabilities in DevOps and the tools that support QA and testing, so you can select them. Then the non-testing activities within the pipeline (such as security scanning or packaging) and release strategies: canary, blue-green, rolling, phased rollout, progressive delivery, hotfix and dark launching.
Then a review of practices every tester in DevOps should recognize:
- Infrastructure as code (IaC): environments are defined in versioned files, so they are reviewed and tested too.
- Feature toggles: they separate deployment from release; the code is in production but the feature is switched on when the business decides. Both paths need testing.
- Branching strategies.
- Chaos engineering: injecting controlled failures to verify resilience.
- Telemetry and observability: extending testing into production with real usage data.
- SBOM (Software Bill of Materials): the inventory of software components, key for configuration management and supply chain security.
- Containerization.
Download the official syllabus
The CT-QDO syllabus is available in English. Everything is examinable except the introduction, hands-on objectives and appendices.
The CT-QDO exam
Verified structure
| Item | Value |
|---|---|
| Questions | 40, multiple choice |
| Passing score | 65% of the points |
| Duration | 60 minutes; 75 in a non-native language |
| Prerequisite | ISTQB Foundation Level certificate |
| Cognitive levels | K1, K2 and K3 |
Source: istqb.org and the official exam structure tables. One detail: the official ISTQB table (v1.18) lists 44 total points with 29 to pass, while the certification page mentions 45 and 30; either way the cut-off is about 65%. Confirm when you book.
Exam options
- Online with remote proctoring (iSQI FLEX): 24/7, with a webcam, microphone, your phone as a second camera and a government-issued ID.
- Pearson VUE: test center or OnVUE.
- On site at your company: groups of 6 or more, with a proctor provided by Cool Testers.
Paper exams are no longer offered. Since CT-QDO is very new, check languages and availability with the provider before booking.
Where to buy it
You can buy it directly from an official exam provider such as iSQI, our partner, or through Cool Testers with our certification exam if your employer pays or you need an invoice (you have 1 year to take it). Not sure which option suits you? Message us on WhatsApp.
How to prepare
- Keep your CTFL fresh. It is required, and CT-QDO uses its vocabulary a lot (whole-team approach, test pyramid, shift left).
- Read the full syllabus twice. Keywords are examined at K2: memorizing is not enough; you must tell similar concepts apart (continuous delivery vs. continuous deployment; canary vs. blue-green; SLA vs. SLO vs. SLI).
- Build a practice pipeline. With GitHub Actions, GitLab CI or Azure DevOps, set up a simple pipeline with a build, unit tests, API tests and a deployment to a test environment. The chapter 2 K3 objectives make much more sense afterwards.
- Practice API and contract testing. They are K3 in chapter 3.
- Make flashcards for the syllabus lists: DORA metrics, CALMS elements, the three ways, topologies and anti-patterns, release strategies.
- Work through the official sample exam on istqb.org.
- Strengthen your automation skills. If you come from manual testing, courses like Playwright or Build a Test Automation Practice give you the hands-on base this syllabus assumes.
Benefits and career paths
- Immediate relevance: most software companies already work with CI/CD pipelines; a tester who speaks DevOps fits in better and contributes more.
- Hybrid profile: it opens doors to roles such as quality engineer, SDET, QA on platform teams or working alongside SRE.
- Business view: you learn to connect quality with metrics leadership understands, such as DORA.
- For developers and DevOps: it is one of the few ISTQB certifications explicitly designed for them too, useful for building a quality culture across the team.
- For companies: a shared quality language between Dev, QA and Ops. To train your team in testing and automation, request a quote.
Related certifications and next steps
- Before: CTFL 4.0 (mandatory). Recommended: Agile Tester (CTFL-AT).
- Automation: CT-TAS for strategy and CTAL-TAE for automation engineering.
- Advanced Agile: CTAL-AT and, while still available, CTAL-ATT. At scale: CT-ATLaS.
- Specialties that fit DevOps: Performance Testing and Security Test Engineer.
- AI in the pipeline: CT-GenAI.
Frequently asked questions
What is the ISTQB CT-QDO certification?
It is the ISTQB Specialist certification on quality assurance and testing in DevOps teams. Syllabus v1.0 was released in April 2026.
What is the prerequisite for CT-QDO?
The ISTQB Foundation Level (CTFL) certificate. ISTQB also recommends some development or testing experience and an accredited course.
What does the CT-QDO exam look like?
40 multiple-choice questions in 60 minutes (75 in a non-native language). You pass with about 65% of the points.
Is CT-QDO only for testers?
No. It is also aimed at developers, DevOps and SRE engineers, scrum masters and product owners, because in DevOps quality is the whole team's responsibility.
Do I need to know how to code?
It is not a formal requirement, but you should understand how a CI/CD pipeline works and have basic knowledge of automation and API testing.
How much study time does it take?
An accredited course must last at least 20.2 hours over at least three days. If you self-study, plan for similar time plus practice.
What is the difference between CT-QDO and CT-TAS?
CT-TAS focuses on the organization's test automation strategy. CT-QDO covers quality across DevOps as a whole: culture, value stream, CI/CD, automated and manual testing, and operational practices.