ISTQB Acceptance Testing (CT-AcT): Syllabus, Exam Format and Who It Is For

Plenty of people picture acceptance testing as a few business users clicking through the finished system in the last week before release, which makes a certificate in it look like a tester's badge. The ISTQB Certified Tester Acceptance Testing (CT-AcT) syllabus treats it differently: acceptance criteria are written while requirements are still being shaped, and product owners and business analysts sit the paper alongside testers. It is 40 questions in 60 minutes, with 26 needed to pass.

Is acceptance testing really a last-week activity, and who is this certificate for?

The myth has a grain of truth. Acceptance testing is the level at which a customer or user decides whether a system is ready to be released, and in a strictly sequential project that decision does arrive late. What the syllabus adds is that almost everything which makes the decision sound happens much earlier. Someone has to turn a business need into a requirement, the requirement into measurable acceptance criteria, the criteria into tests, and all of it has to be understood by people who will never read a test script. If that early work is vague, the late test is a formality and the surprises arrive after go-live.

That is why ISTQB aimed the qualification at three roles instead of one. Its own wording lists business analysts, product owners and testers, and the target audience stretches to test analysts, test engineers, test consultants, test managers, user acceptance testers and developers. The stated purpose is to stop a silo forming between the people who define what the business wants and the people who check that it was delivered. In practice that makes CT-AcT a better fit than most ISTQB papers for someone whose job title does not contain the word tester.

What do the three roles take away?

The syllabus states six business outcomes, split by role. For business analysts and product owners the outcomes are about taking part in acceptance test design, helping organise the acceptance activities and contributing to the quality of the process, including verification of the artifacts it produces. For testers the outcomes are about shaping acceptance criteria during requirements work, collaborating with analysts through every activity, and understanding business objectives well enough to talk to the business units directly. Read those six lines once before you study; every chapter is written to serve one of them.

What must you hold before booking?

ISTQB's certification page and the syllabus agree on one entry condition: you need the Certified Tester Foundation Level certificate first. There is no experience requirement stated on either document. The syllabus assumes you already know the Foundation Level vocabulary, so terms such as equivalence partitioning, test levels and exploratory testing are used without being taught again. If your Foundation Level knowledge is a few years old, refresh the technique chapter before you open the CT-AcT syllabus.

You will also meet the qualification under other names. Searchers abbreviate it CTFL-AcT, the syllabus PDF is titled Certified Tester Foundation Level Syllabus - Acceptance Testing, and ISTQB's certification page lists it as Certified Tester Acceptance Testing (CT-AcT). All three are the same exam.

How is the CT-AcT paper built, and is the syllabus still current?

The paper is short by ISTQB standards: 40 questions, 60 minutes, 40 points in total, and a pass at 26. ISTQB's page also lists 25 percent extra time for candidates who sit in a language other than their native one, which turns 60 minutes into 75; ask your exam provider how that is requested. Every question is worth a point, so an unanswered question can only cost you.

Item	Detail
Exam code	CT-AcT
Full name	ISTQB Certified Tester Acceptance Testing
Vendor	ISTQB
Category	Specialist
Syllabus version	CT-AcT Version 2019
Price	USD $199
Duration	60 minutes
Questions	40
Passing score	26 / 40
Prerequisite	Certified Tester Foundation Level

Version check. When we read ISTQB's own certification page in October 2026 it still presented CT-AcT as a current certification, linked syllabus v1.0 dated 2019, and carried no retirement or replacement notice. The syllabus itself is dated 21 June 2019 and runs to 40 pages. You can read the whole document in ISTQB's CT-AcT syllabus PDF, and the ISTQB CT-AcT certification page is the place to confirm the version again before you book.

Price. USD $199 is the figure we list. ISTQB's own page says exam fees are set by the local exam providers and member boards rather than as one global price, so treat 199 as a guide and read the fee your provider shows at checkout. The same goes for the language, location and proctoring options; they belong to the provider.

Nothing in the syllabus splits the 40 questions by chapter. What it does publish is a minimum training time and a cognitive level for every learning objective, and those two numbers are the honest guide to where the marks are. The next section lays them out.

Where do the 600 syllabus minutes go, and what does that say about the marks?

Accredited courses must spend at least 600 minutes on the five chapters. Teaching time is not the same as exam weight, but it measures how much material each chapter holds, and the number of objectives at K3 (apply) shows where you will be asked to do something rather than recall it.

Chapter	Minimum teaching time	Objectives	Levels
1. Introduction and Foundations	80 minutes	6	1 at K1, 5 at K2
2. Acceptance Criteria, Acceptance Tests and Experience-Based Practices	165 minutes	5	3 at K2, 2 at K3
3. Business Process and Business Rules Modeling	150 minutes	4	2 at K2, 2 at K3
4. Acceptance Testing for Non-Functional Requirements	95 minutes	7	1 at K1, 6 at K2
5. Collaborative Acceptance Testing	110 minutes	5	1 at K1, 3 at K2, 1 at K3
Total	600 minutes	27	3 at K1, 19 at K2, 5 at K3

Three readings follow from the table. First, all five K3 objectives live in chapters 2, 3 and 5, and chapters 2 and 3 together take 315 of the 600 minutes. Those are the chapters where the paper asks you to write acceptance criteria, phrase a Gherkin scenario, build a small process model or derive tests from one, so they repay practice rather than rereading. Second, chapter 4 has the most objectives (seven) in the second-shortest time, so it rewards a tidy list of names and what each one is for. Third, chapter 1 is only 80 minutes but its vocabulary is used by every later chapter, so a shaky chapter 1 costs you in places you would not expect.

For the K levels themselves, ISTQB's definitions are plain: K1 means remember a term or concept, K2 means select the explanation that fits a statement, and K3 means select the correct application of a technique to a given context. All of the syllabus is examinable at K1, so even the sections without a learning objective can supply a recall question. If you want the same chapters laid out beside our topic pages, our chapter breakdown of the CT-AcT syllabus follows the same five-chapter structure.

How do you turn a user story into acceptance criteria and Gherkin tests?

Chapters 1 and 2 are the heart of the exam and the best place to see why acceptance testing cannot wait until the end. Take a story from an online shop: as a shopper, I want to return an item within 30 days so that I get my money back.

From story to criteria

The syllabus separates three things that beginners blur. The requirement or user story says what the business wants. Acceptance criteria are measurable true-or-false statements that say when the story counts as done. Acceptance tests then say how each criterion is checked. Criteria are the test conditions, the "what"; the tests are the "how".

Good criteria, in the syllabus's terms, are precise, measurable and concise, they leave out technical solution details, and they cover non-functional needs as well as functional ones. For the returns story, three sound criteria would be:

• A return requested up to 30 days after delivery is accepted and the refund goes to the original payment method.
• An item marked final sale is refused and the shopper is told the reason on the same screen.
• The refund confirmation appears within 5 seconds of the shopper submitting the request.

Compare that with a weak version: "returns should work quickly using the new refund service." Nobody can mark it true or false, and it names a solution instead of an outcome. Expect the exam to hand you a requirement or story with a defective criterion and ask which statement is the better one, or to give you a story and ask which set of criteria meets good practice. The last criterion above also shows the syllabus point that non-functional requirements deserve criteria too.

From criteria to Gherkin

Gherkin is the Given, When, Then pattern. Given describes the state the system is in before the action, When names a user action on the system, and Then states what can be observed afterwards. The syllabus stresses that Gherkin test cases talk about user actions, not user interface elements, so "When the shopper submits a return request" is right and "When the shopper clicks the blue Return button" is not.

Keyword	Returns example
Given	an order delivered 12 days ago that contains one item not marked final sale
When	the shopper submits a return request for that item
Then	the request is accepted and the refund is shown as going to the original payment method

The same structure can be read by a business analyst, discussed with developers and, because it can be parsed, turned into automated scripts through keyword-driven testing. That double life is why the syllabus links Gherkin to both approaches in section 1.2.3: Behavior-Driven Development, which uses Gherkin for the requirements themselves, and Acceptance Test-Driven Development, where acceptance tests are produced together during requirements analysis by analysts, product owners, testers and developers, in text or in diagrams. The two terms are often used interchangeably, but the syllabus keeps a distinction a question can exploit: BDD is tied to Gherkin, while ATDD allows other forms, including the graphical, visual ATDD that chapter 3 builds on.

Which techniques sit behind the tests?

When tests are derived from acceptance criteria, the usual black-box techniques apply, such as equivalence partitioning and boundary value analysis from the Foundation Level syllabus. The syllabus then lists what can augment them: business process-based testing, possibly with decision tables; experience-based testing; risk-based testing, where prioritisation follows risk type and level; and model-based testing. It also says that criteria should be verified by tests and that traceability between requirement or story and test case should be managed, a point chapter 5 returns to.

What do exploratory and beta testing add?

Exploratory testing in this syllabus is run by people who are domain experts but not necessarily familiar with the product. In one uninterrupted session they learn the product, design tests, run them and interpret results. A test charter, prepared before the session and possibly written jointly by analyst and tester, gives purpose, scope, set-up, duration and tactics, and time-boxed sessions, ideally in pairs, keep the effort bounded. It complements formal techniques and gives rapid early feedback.

Beta testing is the other half of section 2.3. It is common for off-the-shelf software and software as a service, and it is carried out by potential or existing users at their own location, with no predefined procedures and no charter. It finds defects that escaped earlier levels, but the syllabus is blunt about its limits: it is not systematic or measurable, nothing guarantees every requirement is covered, and it happens late, whereas criteria-based tests support the Early Testing principle. A typical wrong option on the paper says beta testing is enough on its own.

What does a business process model have to do with test cases?

Chapter 3 is the one candidates fear, and it is the one that rewards a pencil. It is 150 minutes long and holds two K3 objectives: construct a simple model using BPMN or DMN, and derive acceptance tests from one for a given coverage criterion. BPMN, maintained by the Object Management Group, draws workflows as flow diagrams; DMN, also an OMG standard, captures business rules as decision tables, and the syllabus uses a defined subset of each, listed in its appendix. A "simple" model means fewer than 20 modelling elements drawn only from that subset.

A worked decision table

Suppose the returns policy has two conditions: is the request inside the 30-day window, and is the item marked final sale? Two yes-or-no conditions give four rules.

Rule	Inside 30 days	Final sale	Outcome
R1	Yes	No	Full refund
R2	Yes	Yes	Refuse, give reason
R3	No	No	Pass to a manager for a goodwill decision
R4	No	Yes	Refuse, give reason

One of the coverage items the syllabus names is the decisions in the decision tables, and full coverage means each occurrence of the coverage item is exercised at least once. Here that is four tests, one per rule. If the exam shows a table with five rules and offers four test sets, the right answer is the set that touches all five.

A worked process path

Now model the same flow in BPMN with two exclusive gateways. The first asks whether the request is inside the window; if not, the process ends with a refusal. If it is, the second gateway asks whether the item passes inspection; yes ends in a refund, no ends in a refusal that states why. That diagram has three paths from start to end. The syllabus lists several coverage items for such a model: the user stories, requirements and risks annotated on it, the decisions in its tables, user scenarios defined by different paths, and all paths, normally without loops. Covering all paths here needs three tests. Covering only the main scenario plus one path for the alternative needs two. Agreeing which coverage item is enough is a conversation between analyst and tester, which is exactly the collaboration the syllabus wants.

Modelling good practice and ATDD

Section 3.3 reads like a checklist of habits, and each one is fair game for a K2 question. Model only what is to be tested; a workflow that covers part of the system's behaviour is acceptable if it shows what you will check. Use decision tables for rule-heavy processes because they keep dependencies manageable. Keep diagrams as simple as possible and split them into sub-processes. Finally, the models support ATDD: analysts, testers and developers can read the diagram together, agree the scenarios, and use it as the shared picture from which tests are derived.

How are usability, performance and security accepted, and who is in the room?

Chapter 4 is the longest list of named things in the syllabus, but each name has a job. The syllabus's argument is that non-functional requirements matter more to acceptance as software spreads into everyday life and into systems of systems, and that missing them can mean customer dissatisfaction, lost sales, rejection of the solution, liability and public exposure.

Which ISO 25010 names do you need?

The syllabus draws on ISO 25010, whose product quality model has seven non-functional characteristics: performance efficiency, compatibility, usability, reliability, security, maintainability and portability. Each has sub-characteristics; usability, for example, includes learnability, operability, user error protection, user interface aesthetics and accessibility, and security includes confidentiality, integrity, non-repudiation, accountability and authenticity. You are asked to give examples of sub-characteristics worth considering in acceptance tests, so be able to match a sub-characteristic to its parent and to a plausible criterion. An acceptance testing strategy, the syllabus says, selects and prioritises among them for the context.

The same standard defines a quality in use model with five characteristics about the outcome of a person using the system: effectiveness, efficiency, satisfaction, freedom from risk and context coverage. This is a K1 objective, so it is a recall question, and it is useful for acceptance because it speaks about the user's experience of the system.

How is usability examined?

Usability is described in ISO 25010 terms as effectiveness, efficiency and satisfaction for specified users in a specified context. User experience widens it to aesthetic and emotional factors, and context matters: a user at a desk, driving or hiking will experience the same product differently. The syllabus structures UX requirements analysis on four pillars, and the objective asks you to relate usage scenarios to them:

• User analysis categorises users by characteristics such as skills, business knowledge and background, sometimes using personas.
• Task analysis formalises functionality through use cases and scenarios and studies user behaviour and expectations.
• Context analysis looks at external, physical and psychological conditions and at devices and form factors.
• Competition analysis studies how competitors solved the same problem, unless a disruptive design is the aim.

Accessibility sits in the same section: analysts and testers should assess whether products are usable by people facing perceptual or cognitive limitations when they design criteria and tests.

What does a performance acceptance test look like?

Performance tests have to be considered at every level, but during acceptance they are particularly addressed in operational acceptance testing, usually by the operating teams. Analysts and testers still take part when criteria and test cases are written. The syllabus insists that criteria for performance efficiency give objective measures, so that nobody argues about whether the system felt slow. A high-level performance test simulates concurrent users or transactions with tools, measures response times of key elements such as web server, application server and database, and compares them with the predefined requirements; the cycle of test, analysis and improvement repeats until the target is met. The second objective asks you to recognise how different perspectives change the criteria, since a user, an operator and a business sponsor will each define acceptable performance differently.

Why is security part of an acceptance syllabus?

The syllabus ties security to an organisation's overall security policy and treats it as a requirement to be considered at every stage of business analysis and acceptance. Information security belongs in risk management and non-functional requirements analysis; the value of the information is assessed and risks prioritised; criteria must be measurable and may cover authentication, authorisation, accounting procedures, sanitisation of input data, cryptography and data privacy; and high-level security test cases set out context, main steps and expected results. Some of these tests can be run by the acceptance tester and others by specialist security testers, depending on how technical they are. The single objective is K2: explain why such criteria and tests are required for a given security requirement.

Why is operational acceptance testing missing?

The syllabus names the forms of acceptance testing it covers: user acceptance testing, contractual and regulatory acceptance testing, and alpha and beta testing. It deliberately leaves out operational acceptance testing, because that is generally done by the teams who will run the system rather than by testers and analysts. It still appears in passing in the performance section, which is why a question may mention it without it being a topic you must master.

How do analysts and testers report and agree on what "done" means?

Chapter 5 is short on technique and heavy on judgement. It carries one K3 objective: for a given situation, apply social and communication skills relevant to collaborative acceptance testing. The text explains why: the people involved range from business analysts and sponsors to automation specialists, with different aims and skills, so social skills are of utmost importance. Tools it names for building trust include serious games, role playing and workshops, and the goals are that team members get to know each other, communicate openly in an environment of trust, envision common objectives, and defuse major problems with humour, positive communication or negotiation techniques such as principled negotiation.

The K3 question tends to describe a tense situation, say a business sponsor who rejects a defect as unimportant while the tester insists it blocks release, and offers four responses. The correct one is rarely the most assertive; it is the one that restores shared objectives and uses the criteria as the neutral reference.

How is a defect analysed at the business level?

The tester reports the discrepancy between actual and expected outcome and identifies which acceptance criteria were not satisfied. The analyst then helps judge business impact, often by exploring the paths in the process model where the defect occurred and the business rules that were not implemented correctly, and sets a priority such as low, medium, high or critical according to potential impact on usage. The impact analysis and the decision are recorded in the defect report.

What does a good acceptance report tell decision makers?

Reports go to business managers, product managers or domain experts, who know the domain but not the implementation, so progress, results and defects are presented without technical details and in their language, with metrics. The test summary report adds the impact analysis of open defects and states whether the targeted quality criteria were reached. The syllabus lists three possible release outcomes, and the exam expects you to match a situation to one:

• Release as is, with no restrictions on roll-out.
• Release with reservations: known errors with a workaround are communicated to users and the support team, and a feature or sub-system with an important risk may be excluded from roll-out.
• Reject until critical defects are fixed and re-tested, with roll-out postponed or replaced by alternative solutions.

Which quality assurance activities protect the tests themselves?

Five activities are listed: review of acceptance criteria for clarity, consistency and completeness; review of acceptance test cases against criteria, business processes, rules and risks; traceability between requirements or stories, criteria, test cases and defects; coverage analysis that becomes possible once traceability runs in both directions; and review of test reports so they support release decisions. The tool objective (K1) is a recall item: tools for acceptance testing come from both the business analysis and the testing worlds, including requirements management tools, Agile project management tools, business process management tools and test management and automation tools.

In what order should you study, and when are you ready to book?

There is no need to read the syllabus in print order. Because the K3 objectives are in chapters 2, 3 and 5 and chapter 1 supplies the vocabulary, the order below spends your effort where the paper asks for application. Adjust the lengths to your own diary; the sequence matters more than the calendar.

Stage	What to do	You are ready to move on when
1. Vocabulary	Read chapter 1 and rewrite the chain from business goal to acceptance test in your own words, including how ATDD and BDD differ.	You can say, without notes, what separates a requirement, a criterion and a test.
2. Writing	Take five stories from your own work. Write criteria for each, then one Gherkin scenario per criterion.	A colleague cannot find a criterion that is unmeasurable or names a solution.
3. Modelling	Draw a BPMN process with fewer than 20 elements and a DMN-style decision table, then derive tests for two coverage items.	You get the same test count twice, on different days.
4. Non-functional	Build flash cards for the seven ISO 25010 characteristics, five quality-in-use ones and four UX pillars.	You can match any sub-characteristic to its parent in a few seconds.
5. Collaboration	Study defect analysis, the three release outcomes and the five QA activities; rehearse two tense scenarios.	You can justify a release outcome using the criteria alone.
6. Rehearsal	Work through the sample paper ISTQB publishes, then timed mixed sets.	You finish with minutes to spare and can explain every wrong option.

ISTQB publishes a sample paper and its answers; start with the ISTQB sample exam questions for CT-AcT and mark yourself strictly. Timed sets are where the Gherkin and decision-table questions stop feeling easy, so sit a CT-AcT practice test against the clock after each of the K3 chapters and note which objectives still need another pass.

What do wrong answers usually have in common?

Across the syllabus the distractors follow a few patterns, all of which the text itself rules out. A criterion that names a technical solution. A Gherkin step that mentions a button instead of a user action. A claim that beta testing is sufficient. A performance criterion phrased as a feeling. A model with every detail of the system instead of what is to be tested. A report padded with implementation detail for a business audience. When you review a wrong answer, name the sentence of the syllabus that it contradicts; that habit sticks better than a score.

What does the certificate say about you?

CT-AcT sits in ISTQB's Specialist category and requires Foundation Level first, so it adds a role-specific signal rather than a step up in seniority. Its value is in being able to show that you can write criteria a business will sign, derive tests from a process model and report in language decision makers use. For an analyst or product owner it is evidence that you understand how your requirements will be tested; for a tester it shows you can work upstream. We make no salary claims here: ISTQB does not publish any, and a pay figure without a survey behind it would be a guess.

Frequently Asked Questions

How many questions are on the CT-AcT exam and what is the pass mark?

The CT-AcT exam has 40 questions in 60 minutes, worth 40 points in total, and the passing score is 26 of 40. ISTQB lists 25 percent additional time for candidates sitting in a non-native language; ask your exam provider how to request it.

Do I need the Foundation Level certificate before taking CT-AcT?

Yes. ISTQB states that candidates must hold the Certified Tester Foundation Level certificate to gain the Acceptance Testing certification, and the syllabus repeats this entry requirement. Neither document states a minimum amount of work experience.

Is the CT-AcT exam only for testers?

No. The syllabus covers three roles, business analysts, product owners and testers, and names test analysts, test engineers, test consultants, test managers, user acceptance testers and developers as the audience. Its aim is to improve collaboration between analysts and testers during acceptance testing.

How much does the CT-AcT exam cost?

We list the exam at USD $199. ISTQB says fees are set by local exam providers and member boards rather than as one global price, so the amount you pay, and any local taxes, depends on the provider you book through. Check the fee at checkout before you commit.

Which CT-AcT syllabus version is current and does it cover operational acceptance testing?

When we checked ISTQB's certification page in October 2026 it linked syllabus v1.0 from 2019 and showed no retirement notice. The syllabus covers user, contractual, regulatory, alpha and beta acceptance testing, and deliberately excludes operational acceptance testing, which operating teams usually run.

Select ratingPoorOkayGoodGreatAwesome

Rating: 5 / 5 (76 votes)