- CT-AcT (Acceptance Testing) is the ISTQB specialist certification in acceptance testing: acceptance criteria, ATDD and BDD with Gherkin, business process (BPMN) and business rule (DMN) models, acceptance of non-functional requirements and collaboration between testers, business analysts and product owners.
- Current version: syllabus v2019 (released June 21, 2019).
- Prerequisite: the ISTQB Foundation Level (CTFL) certificate.
- Exam: 40 questions, pass mark 26 (65%), 60 minutes (75 if it isn't in your native language).
- 5 chapters and 600 minutes (10 hours) of minimum training.
- It's designed for three roles at once: testers, business analysts and product owners.
- The exam isn't included in any course: buy it from iSQI (20% coupon for Cool Testers students) or through us if you need an invoice.
"It works, but it's not what we asked for." If you've ever heard that in a demo or during UAT, you already know the problem this certification solves. Most acceptance rejections don't come from coding errors but from ambiguous acceptance criteria and from analysts and testers working in silos. ISTQB CT-AcT focuses on exactly that. This guide explains what the syllabus covers, what the exam looks like and how to prepare.
For the full certification map and costs, see our main ISTQB certification guide.
What CT-AcT is and where it sits in the ISTQB portfolio
CT-AcT is an ISTQB specialist certification. According to its syllabus, the key objective is to support collaboration between product owners, business analysts and testers in acceptance testing, avoiding the silo effect, whether the lifecycle is agile or traditional.
The syllabus starts from a simple idea: acceptance criteria are obtained by breaking requirements down into a more atomic, testable form, and test cases are then designed from those criteria. If that chain breaks, acceptance fails.
Which forms of acceptance testing it covers (and which it doesn't)
Of the forms of acceptance testing defined in the Foundation Level, the syllabus covers:
- User acceptance testing (UAT).
- Contractual and regulatory acceptance testing.
- Alpha and beta testing.
It deliberately leaves out operational acceptance testing (OAT), because it's usually performed by the teams that will operate the system rather than by testers and business analysts.
Current version
The current version is v2019, released on June 21, 2019. On the ISTQB page it appears as "CT-AcT Syllabus v1.0 2019": it's the same version and, at the time of writing, there's no newer one.
Where it fits
You take it after ISTQB Foundation Level (CTFL 4.0), and it draws heavily on concepts from Agile Tester (CTFL-AT) (user stories, INVEST, ATDD), Model-Based Testing (CT-MBT) (coverage on models) and the IQBBA Foundation Level in business analysis, which the syllabus uses as its reference for analyst activities.
Who it's for and prerequisites
The syllabus says the certification is aimed at anyone involved in acceptance testing: product owners, business analysts, testers, test analysts, test engineers, consultants, test managers, user acceptance testers and developers.
It's especially useful if:
- You're a functional tester taking part in refinement or UAT with business users.
- You're a business analyst or product owner who wants to write acceptance criteria that can actually be tested.
- You work with BDD/Gherkin or want to introduce it to your team.
- You work on projects with contractual or regulatory acceptance (government, banking, healthcare, external vendors).
Exam entry requirements
The syllabus states that you must hold the ISTQB Foundation Level certificate before taking the Acceptance Testing exam.
What you'll be able to do: business outcomes
Because the certification covers three roles, the syllabus expresses its Business Outcomes by role:
| Role | Code | Business outcome |
|---|---|---|
| Business analysts and product owners | AcT-1 | Contribute by taking part in acceptance test design and help align the product with business requirements. |
| AcT-2 | Contribute to organizing acceptance testing (process, artifacts, communication, reporting, monitoring and management) and collaborate with testers and stakeholders. | |
| AcT-3 | Contribute to the quality of the acceptance testing process, including validation and verification of artifacts. | |
| Testers | AcT-4 | Contribute to defining acceptance criteria during requirements definition. |
| AcT-5 | Collaborate efficiently with business analysts and stakeholders throughout acceptance testing. | |
| AcT-6 | Understand business objectives, communicate with business units and share common objectives for acceptance testing. |
Syllabus content chapter by chapter
The syllabus has five chapters, each with a minimum training time. Learning objectives range from K1 (remember) to K3 (apply), and all content is examinable at least at K1.
| Chapter | Minimum time | Key topics |
|---|---|---|
| 1. Introduction and Foundations | 80 min | Business goals, needs and requirements; requirements, acceptance criteria and acceptance tests; requirements quality; business analysis and testing; ATDD and BDD |
| 2. Acceptance Criteria, Acceptance Tests and Experience-Based Practices | 165 min | Writing acceptance criteria, test techniques and approaches, Gherkin, exploratory testing, beta testing |
| 3. Business Process and Business Rules Modeling | 150 min | BPMN and DMN models, deriving tests with coverage criteria, good practices, modeling for ATDD |
| 4. Acceptance Testing for Non-Functional Requirements | 95 min | ISO 25010 and quality in use, usability and UX, performance, security |
| 5. Collaborative Acceptance Testing | 110 min | Social and communication skills, defect analysis, reporting, QA of artifacts, tools |
Chapter 1. Introduction and foundations (80 min)
This chapter builds the full chain: business goals → business needs → requirements → acceptance criteria → acceptance tests. Key points:
- Acceptance criteria are measurable statements that can be either true or false, tied to a specific requirement or story. They define "what" to test, not "how".
- Acceptance test cases are derived from those criteria.
- If requirements or criteria are vague, testers make assumptions and tests may be invalid. That's why the INVEST criteria for user stories and ISO/IEC/IEEE 29148 for requirements matter.
- How business analysis activities (strategy, process management, requirements engineering, solution evaluation) relate to test process activities (planning, analysis, design, implementation, execution, completion).
- ATDD (acceptance tests are created collaboratively during requirements analysis) and BDD (Gherkin's Given-When-Then format, where specifications become tests and a basis for automation).
Example: the business goal is "cut call center calls by 30%". A need is "customers can reschedule delivery without calling". The story is "as a customer I want to change my delivery date in the app". An acceptance criterion is "the new date can only be chosen from the next 10 available business days". That criterion is already testable.
Chapter 2. Acceptance criteria, acceptance tests and experience-based practices (165 min)
The longest chapter and the one with the most exam questions. It has two key K3 objectives:
- Write acceptance criteria following good practices for a given requirement or story: precise, measurable and concise; free of technical solution details (the "what", not the "how"); covering non-functional requirements too; and reviewed through walkthroughs, technical reviews or iteration planning.
- Apply Gherkin to design acceptance tests for a given story. Gherkin scenarios don't refer to UI elements but to user actions on the system.
You'll also cover techniques for acceptance testing: black-box (equivalence partitioning, boundary values), business process-based testing with decision tables, experience-based, risk-based and model-based testing; exploratory testing with test charters, in pairs or as a team; and beta testing, useful for COTS or SaaS products but neither systematic nor measurable and late in the cycle, so it shouldn't be the only form of acceptance.
Gherkin example:
Scenario: reschedule delivery to a valid date
Given I have an order scheduled for delivery on Monday
When I choose Thursday as the new date
Then the order shows delivery scheduled for Thursday
And I receive an email confirmation.
Notice it doesn't say "I click the blue button": it describes behavior, not the interface.
Chapter 3. Business process and business rules modeling (150 min)
This chapter brings in "business process assurance": organizations need confidence that critical processes (order-to-cash, employee onboarding, production planning) run without disruption. It uses two OMG standards:
- BPMN (Business Process Model and Notation) for workflows.
- DMN (Decision Model and Notation) for decisions and business rules expressed as decision tables.
The K3 objectives are to build a simple process or rule model (fewer than 20 elements, using a BPMN and DMN subset defined in the appendix) and to derive acceptance tests that meet a given coverage criterion. Typical coverage items are: stories, requirements and risks annotated on the model; decisions in rule tables; user scenarios (paths through the process); and all loop-free paths.
You'll also see good practices: model only what will be tested, use sub-processes to keep diagrams simple, have analysts and testers model together, and annotate diagrams with stories, risks and priorities. And how these models serve ATDD as living documentation, which is the main difference from BDD's Gherkin: here the specification is visual.
Example: a loan approval process with a gateway "amount over 50,000?" and a DMN risk table with four rules. If the agreed criterion is "all paths of the main scenario and each rule once", you get a bounded test set you can justify to the business.
Chapter 4. Acceptance testing for non-functional requirements (95 min)
Acceptance isn't only functional. This chapter uses the ISO 25010 model:
- Examples of non-functional sub-characteristics to include in acceptance tests, and the five quality in use characteristics: effectiveness, efficiency, satisfaction, freedom from risk and context coverage.
- Usability and UX: the four pillars of UX requirements analysis (user, task, context and competition analysis) and usability testing methods such as checklist-based evaluations, expert reviews, walkthroughs and think-aloud, biometrics-based evaluations and log file analysis.
- Performance: high-level performance tests (load, stress, endurance) and acceptance criteria from three perspectives: user (perceived response time), business (concurrent users, transactions and expected times) and technical (resources and architecture).
- Security: why measurable security acceptance criteria (authentication, authorization, input sanitization, cryptography, privacy) and high-level security tests are needed, some run by the acceptance tester and others by specialists.
Example of a performance criterion covering all three perspectives: "with 500 concurrent users at peak hour (business), payment confirmation appears in under 3 seconds for 95% of transactions (user), with server CPU below 70% (technical)". To go deeper, read our guides to Performance Testing (CT-PT) and Usability Testing (CT-UT).
Chapter 5. Collaborative acceptance testing (110 min)
The last chapter covers the human and management side:
- Collaboration (K3): applying social and communication skills in a given situation. The syllabus mentions serious games, role playing, workshops and principled negotiation to get to know each other, communicate in an environment of trust, envision common objectives and defuse conflict.
- Defect analysis at the business level: the tester identifies which criterion isn't met and the business analyst assesses the impact on business processes, walking through the affected model paths and rules.
- Reporting for a business audience and the possible decisions: release as is, release with reservations (with workarounds or excluding a feature), or reject until fixed.
- QA of acceptance artifacts: review of criteria, review of test cases, traceability, coverage analysis and review of reports.
- Tools from business analysis and testing that support acceptance.
Example: during UAT a defect appears in a discount calculation. The tester identifies the failing criterion; the analyst checks the model and finds it only affects corporate customers on deferred payment, 2% of orders. Together they recommend releasing with reservations and communicating the workaround to support.
Download the official syllabus
The CT-AcT syllabus is in English. Download it and check the ISTQB page for the sample exam:
The CT-AcT exam
Verified structure
| Item | Value |
|---|---|
| Questions | 40, multiple choice |
| Total points | 40 |
| Pass mark | 26 points (65%) |
| Duration | 60 minutes; 75 minutes if it isn't in your native language (+25%) |
| Prerequisite | ISTQB Foundation Level |
Source: the official CT-AcT page at ISTQB and the ISTQB Exam Structure and Rules Tables v1.18 (May 2026). According to the distribution published by ISTQB, chapter 2 contributes 10 questions, chapters 3, 4 and 5 contribute 8 each, and chapter 1 contributes 6.
Exam formats
- Online with remote proctoring (iSQI FLEX), 24/7: book at least 2 hours ahead. You need a webcam, a microphone, a second camera (your phone) and a government-issued ID.
- Pearson VUE: at a test center or online with OnVUE.
- On-site at your company for groups of 6 or more: Cool Testers brings a proctor.
Paper-based exams are no longer offered. If the exam isn't in your native language you get 25% extra time; check the available languages on iSQI when booking. The certification has the same value in any language.
Where to buy it
- Directly at iSQI.org, our partner and official exam provider, with a 20% coupon off the price on their site for the first attempt for Cool Testers students. Recommended if you're paying yourself.
- Through Cool Testers (certification exam, 1 or 2 attempts) if your company pays or you need an invoice. You have 1 year to take it. Contact us to confirm availability.
Costs in your currency: main ISTQB certification guide.
How to prepare for CT-AcT
- Review Foundation Level, especially test levels, black-box techniques and decision tables.
- Write acceptance criteria every day. Take real stories from your backlog and rewrite their criteria so they're measurable, free of technical details and include at least one non-functional aspect.
- Practice Gherkin. Write scenarios for 5 different stories and check that none mention UI elements.
- Learn the BPMN and DMN subset in the appendix. Draw two processes from your work with fewer than 20 elements and derive tests using different coverage criteria.
- Memorize the ISO 25010 lists the syllabus uses: non-functional sub-characteristics and the five quality-in-use characteristics.
- Practice the three performance perspectives (user, business, technical) with your own example.
- Take the official sample exam and study each rationale.
Benefits and career paths
- Less rework and fewer "that's not what we asked for" moments. Clear criteria from refinement onward reduce rejections in demos and UAT.
- You become a business counterpart. Talking about processes, rules and business risk brings you closer to product owners and managers.
- A solid base for BDD. If your team automates with Gherkin, writing good scenarios is half the job.
- Useful beyond the tester role. Business analysts and product owners can also get certified and show they know how to define acceptance.
- Roles where it adds value: functional QA, UAT lead, business analyst, product owner, quality consultant on enterprise software implementations.
We don't quote salary figures because they vary a lot by country and company.
Related certifications and next steps
| Certification | Relationship to CT-AcT |
|---|---|
| CTFL 4.0 | Entry requirement |
| CTFL-AT Agile Tester | User stories, INVEST and ATDD; highly complementary |
| CT-MBT Model-Based Testing | Goes deeper into generating tests from models and coverage criteria |
| CT-UT Usability Testing | Goes deeper into usability and UX |
| CT-PT Performance Testing | Goes deeper into performance |
| Security Tester | Goes deeper into security |
| CTAL-TA Test Analyst | Next step in business-oriented test techniques |
Frequently asked questions
What is the ISTQB CT-AcT certification?
It's ISTQB's specialist certification in acceptance testing. It focuses on collaboration between testers, business analysts and product owners to define acceptance criteria, design tests (including Gherkin and BPMN/DMN models) and accept functional and non-functional requirements.
How many questions are on the CT-AcT exam?
40 multiple-choice questions, one point each. You pass with 26 (65%). It lasts 60 minutes, or 75 if it isn't in your native language.
Do I need Foundation Level to take CT-AcT?
Yes. The syllabus states that you must hold the ISTQB Foundation Level certificate before taking the exam.
Can a business analyst or product owner take CT-AcT?
Yes. The syllabus is explicitly designed for three roles: business analysts, product owners and testers, with business outcomes for each. You just need to meet the Foundation Level requirement.
Does CT-AcT cover operational acceptance testing (OAT)?
No. It covers UAT, contractual and regulatory acceptance, and alpha and beta testing. It leaves out OAT because it's usually performed by operations teams.
Do I need to know BPMN and Gherkin before studying?
No. The syllabus appendix includes the BPMN and DMN subset you need, and it explains Gherkin's Given-When-Then pattern. What matters is practicing them.
Is the exam included in any Cool Testers course?
No. It's purchased separately: directly from iSQI with a 20% coupon for our students, or through Cool Testers if you need an invoice or your company is paying.