Which characteristic is essential for well-formed acceptance criteria?

Brevity — the criteria are as short as possible, even if they omit important details

Complexity — the criteria are written in technical jargon to be precise

Ambiguity — the criteria can be interpreted in multiple ways to allow flexibility

Testability — the criteria can be verified through a defined test or observation

During a review, a team finds two conflicting acceptance criteria for a payment feature: 'The system must process payments within 2 seconds' and 'The system must verify payments with a third-party service that takes up to 5 seconds.' What is the best way to resolve this conflict?

Refine the performance criterion to: 'The system must display a processing message within 2 seconds and complete the payment within 5 seconds.'

Change the 2-second criterion to 5 seconds to match the third-party service.

Remove the 2-second criterion, as the third-party service is the bottleneck.

Keep both criteria and let the development team figure out how to meet them.

A team reviews this acceptance criterion: 'The system must send a notification to the user when their order is shipped.' Which question is most important to ask during the review to improve this criterion?

Why does the system need to send a notification?

Who is the user that receives the notification?

When should the notification be sent?

What channel is used for the notification (e.g., email, SMS, push)?

What is the primary relationship between acceptance criteria and acceptance tests?

Acceptance criteria and acceptance tests are two names for the same artifact

Acceptance tests define the conditions, and acceptance criteria are the results of those tests

Acceptance criteria define the conditions, and acceptance tests are designed to verify those conditions

Acceptance criteria are used only for manual testing, while acceptance tests are always automated

When deriving acceptance criteria from a user story, what should be included to ensure completeness?

Only the functional requirements that are explicitly stated in the user story

Only the business value that the feature is expected to deliver

Both functional and non-functional aspects, such as performance and usability

Only the technical implementation details that the development team decides to use

Certified Tester Acceptance Testing

Domain 2Objective 1

Objective: Writing Acceptance Criteria CT-ACT Practice Questions (Page 1)

Part of the Domain 2: Acceptance Criteria, Acceptance Tests and Experience-Based Practices domain, which makes up ~23% of our current practice bank. ISTQB does not publish an official question count, but from its 60-minute exam (~25–40 total, ~6–9 in this domain), expect 2–3 from this objective — we provide 23 practice questions to prepare you well beyond it. (estimate)

23questions here

5free pages

7concepts

Questions 1–5

1foundation · easy
Which characteristic is essential for well-formed acceptance criteria?
Select an answer first
2expert · hard
During a review, a team finds two conflicting acceptance criteria for a payment feature: 'The system must process payments within 2 seconds' and 'The system must verify payments with a third-party service that takes up to 5 seconds.' What is the best way to resolve this conflict?
Select an answer first
3application · medium
A team reviews this acceptance criterion: 'The system must send a notification to the user when their order is shipped.' Which question is most important to ask during the review to improve this criterion?
Select an answer first
4foundation · easy
What is the primary relationship between acceptance criteria and acceptance tests?
Select an answer first
5foundation · easy
When deriving acceptance criteria from a user story, what should be included to ensure completeness?
Select an answer first

Finished these 5 questions?

Review the revealed explanations, or continue through the curriculum.

Next 5 questions →Back to CT-ACT

Free Basic Practice is a study aid with revealable answers — not a scored exam. Examers.io is independent and not affiliated with or endorsed by ISTQB. “CT-ACT” is a trademark of its owner, used for identification only.