A passing CI job answers a specific question.
The project's workflow runs browser tests on pushes and pull requests to its main branches. It installs Chromium, executes the test:ci command, and retains a report and test results. Follow the chain before making a claim about release readiness.
Source changes trigger a reviewable CI run.
The command selects one configured browser project.
Results help diagnose a failure after the run.
Syllabus Study Guide
Four chapters aligned to CT-QDO v1.0, with applied notes on the linked CI workflow and test evidence.
Interactive Flashcards
Study delivery signals, continuous testing, exploratory charters and release evidence with focused prompts.
Practice Question Bank
Practise with 72 questions, including 12 new source-based quality and delivery scenarios.
Timed Practice Set
Use a timed 40-question learning set with flags and chapter feedback. The site gives each question equal weight.
Delivery Workbench
Calculate delivery signals and a sample availability budget; explore gate outcomes without implying a deployment.
Study Glossary
Search 45 independent study definitions across the four chapters.
Certification Standard
ISTQB® CT-QDO (Quality in DevOps)
Exam Question Count
40 questions / 45 points
Time Allocated
60 minutes (check accommodations with your provider)
Passing Score
30 of 45 weighted points
Cognitive Levels
K1 (Remember), K2 (Understand), K3 (Apply)
Official CT-QDO v1.0: 40 questions, 45 weighted points, 30 points to pass and 60 minutes. This site scores each question equally and uses a separate 70% practice target. Verify with ISTQB ↗
Syllabus Study Guide & Notes
Four syllabus chapters with source-backed examples and review prompts.
Flashcards (104 Cards)
Click the card (or press Spacebar) to flip. Use arrow keys to navigate.
Practice Question Bank with Explanations
72 independent practice questions with chapter filters and explanations.
CT-QDO Timed Practice
Choose a timed set to check your understanding. These independent practice questions use equal-weight scoring.
Selected Mode
40-question practice set
Question Count
40 Questions
Time Allocated
60 Minutes
Practice Target
70% correct (28/40 on full set)
Practice rules
- Each practice question has one correct answer out of four options.
- You can flag questions to review before final submission.
- Answer every question to make the chapter feedback useful.
- After submission, see your practice score and chapter breakdown. This is not an official exam result.
Official pass rule: 30 of 45 weighted points. This tool cannot award certification. See ISTQB details ↗
Delivery and Quality Workbench
Follow a real CI workflow, then use sample data to explore delivery signals, SLO allowance and gate decisions.
Read what ran. Record what it proves.
The playwright-automation-exercise project ↗ supplies a concrete CI example. Inspect the actual command and output before extending it with your own release gates.
Push or pull request
The workflow listens to main and master and supports manual dispatch. A test run is linked to a code change.
Open workflow ↗Chromium only in CI
The job installs Chromium and calls test:ci. Its package script selects the chromium Playwright project.
Open package scripts ↗Report and results
The workflow retains the HTML report and test-results directory even when tests fail, supporting later diagnosis.
Read artifact steps ↗No production release
There is no deployment, canary, SLO or production incident measurement in this workflow.
Compare configured browsers ↗npm ci
npx playwright install --with-deps chromium
npm run test:ci # playwright test --project=chromium --workers=2What happens after a failed browser test?
Use the test-results artifact and HTML report to inspect the case, then check the trace and screenshot settings. The workflow uploads artifacts whether the test step passes or fails.
Can a green run prove a production deployment?
No. The linked workflow runs tests only. A deployable build, environment, production rollout and release decision need separate evidence.
Which gate would you add first?
Start from a specific risk. Name the check, inputs, threshold, artifact and owner. For cross-browser risk, run the required engines explicitly; for a release risk, define a production signal and response.
Project boundary: The calculations below use illustrative input. They do not read the linked repository or trigger its CI, deployment or production systems.
Delivery signals
Five current DORA measures, calculated from your sample production records.
Use one application and one observation period. The initial values are illustrative; the linked test workflow has no production deployments. Read DORA’s current metric definitions ↗
Availability budget example
A downtime allowance for a defined time-based SLO.
This illustration treats each minute of downtime equally. A request-based SLI needs request data. The result does not enact a release freeze. Read Google’s SLO guide ↗
Policy belongs to the service’s stakeholders. An exceeded budget calls for the agreed response, which may differ between services.
Quality gate design exercise
Choose example results and see the outcome of each proposed check.
These are hypothetical gates and thresholds. The linked workflow runs Chromium browser tests and saves artifacts; it does not execute the unit, coverage, security or canary checks shown here.
Quality in DevOps Glossary
Independent study definitions for DevOps quality and delivery.