CTFL-AcT ISTQB Certified Tester - Acceptance Testing (CT-AcT) Questions and Answers

Acceptance criteria should define how the system behaves for a given user story or requirement. They must be precise, testable, and directly traceable to the requirement being verified.

REQ 3-12 describes access control for three user types. Option B is a concrete, scenario-based acceptance criterion that tests the enforcement of access rights — making it an ideal match.

Other options:

A is irrelevant — database technology (MongoDB) is an implementation detail, not a functional criterion.

C is too vague — stating that security tests must be performed doesn’t specify expected behavior or outcome.

D is plausible, but option B more directly demonstrates how an actual system behavior validates the requirement.

Answer: B. Since I am logged in as a department manager, when I try to access the file of an employee who is not in my department then a message telling me that I do not have access rights is displayed

Acceptance Test-Driven Development (ATDD) is a collaborative approach in which acceptance criteria are defined early, often before implementation starts. Business process models (e.g., BPMN) and business rule models (e.g., DMN) are essential tools to formalize how the system should behave under various conditions.

In ATDD, these models provide a structured representation of system workflows and decision logic, which can then be used by testers and stakeholders to derive or generate acceptance tests. This ensures that testing is aligned with actual business processes and requirements.

Option C is correct because it aligns with the purpose of ATDD: to use business models as a foundation for deriving acceptance tests in collaboration with business analysts, testers, and developers.

Other options:

A is incorrect — models are created as part of the project, not necessarily before it starts.

B is incorrect — models support and clarify acceptance criteria; they do not replace them.

D is incorrect — models are maintained as living documentation, especially in agile and iterative approaches.

Answer: C. In an ATDD approach, testers use business process and business rule models to generate acceptance tests.

According to ISO/IEC 25010:2011, the “Quality in Use” model includes characteristics that measure the system’s impact on stakeholders during actual usage in a specific context.

The four main characteristics of Quality in Use are:

Effectiveness

Efficiency

Satisfaction

Freedom from Risk

Option C is correct because “Satisfaction” is one of the core quality-in-use characteristics and refers to the degree to which user needs are fulfilled in context.

Other options:

A (User experience) is a broader term not formally defined as a Quality in Use characteristic in ISO 25010.

B (Security) is part of the product quality model, not quality in use.

D (Freedom of interference) is not a defined term in ISO 25010; it may be a misstatement of "freedom from risk."

Answer: C. Satisfaction

The medical scanner must be able to examine at least 50 patients per day. This requirement directly impacts hospital operations and service efficiency. If the scanner fails to meet performance requirements, such as processing speed or availability, it will affect the hospital’s ability to deliver services to patients — impacting schedules, patient flow, and ultimately the business goals of the hospital.

Option C is correct because it reflects the consequences of performance shortfalls from a business outcome perspective: failure to meet this requirement may result in financial loss, compliance issues, or customer dissatisfaction.

Other options:

A (User perspective) is involved, but the impact here is primarily operational/business.

B (Functional perspective) refers to whether the scanner has the correct features, not performance.

D (Technical perspective) is also relevant, but the business impact (e.g., service delivery) takes precedence in this case.

Answer: C. Business perspective

Clear, complete, and testable requirements or user stories are critical for effective acceptance testing. Ambiguities or vague statements lead to differing interpretations by stakeholders, developers, and testers. This often results in software that doesn’t meet user expectations or in tests that fail to verify business needs correctly.

Option B is correct because it highlights the importance of precise requirements in both implementation and testing phases. Ambiguities can result in incorrect behavior, untestable features, or test cases that don’t align with business goals.

Other options:

A is risky — while testers may explore assumptions during exploratory testing, relying on assumptions rather than clarification increases risk.

C is incorrect — the INVEST mnemonic helps write better user stories, but it doesn’t replace review or validation processes.

D is false — Agile still values requirements engineering; it’s more collaborative and incremental, with the product owner playing a key role, not diminishing its importance.

Answer: B. Vague or ambiguous requirements may lead to misunderstandings both during implementation and testing

In situations where a team is demotivated or struggling with vision and direction, it's effective to use visualization workshops that help the team reflect on progress and visualize a path forward.

Option B describes a metaphorical workshop using a staircase to represent the project's journey — this is known as the "Stairway Retrospective" or "Timeline Workshop". It provides a shared mental model, identifies milestones, and encourages discussion around past progress and future steps. It's ideal for reigniting motivation and clarifying direction — which aligns with the issue described in the question.

Other options:

A can spark debate but may not be constructive or motivating in a stagnation scenario.

C may foster team bonding but doesn’t directly address project direction or vision.

D focuses only on future milestones and lacks the reflective component essential when a team feels stuck.

Acceptance testing primarily focuses on verifying whether a system meets agreed-upon requirements and satisfies the business and user needs. Quality attributes (also known as non-functional requirements) play a vital role in defining the completeness of the acceptance testing process.

Let’s analyze the options:

ii. Functional suitability — directly relates to whether the system provides the correct functions as per business needs. Essential in acceptance testing.

v. Security — ensures that the system is protected against unauthorized access or data breaches. Often critical for business stakeholders.

vii. Maintainability — reflects how easily the system can be modified. Relevant in acceptance if maintainability requirements are part of contractual criteria.

Thus, Option B (ii, v, vii) contains three attributes that are very relevant for acceptance testing.

Other options:

A includes vi (cognitive ability), which is not a standard ISO 25010 quality attribute.

C includes i (commercializability) — not a system quality attribute defined in ISO 25010.

D includes iii (viability) — more of a business or market consideration, not system testability.

Answer: B. ii, v and vii

Beta testing is a form of external user acceptance testing where real users test the product in their environment before the official release. It helps identify issues that may not have been caught in internal testing and gather user feedback on functionality, usability, and performance in real-world conditions.

Option C is correct — the core goal of beta testing is to obtain user feedback in their actual usage context, providing insight into how the system performs outside of controlled environments.

Other options:

A: Test charters are used in exploratory testing, not typically in beta testing.

B: Incorrect — beta testing is not tied to the timing of user story development in Agile.

D: Incorrect — beta testing is performed by end users, not by internal team members like developers or business analysts.

Answer: C. Beta testing aims to obtain feedback from users in their context of use

Effective test reporting should be tailored to the audience’s role and needs. Project managers are typically concerned with high-level progress, schedules, risks, and milestones. Progress trend charts (e.g., test execution over time, defect trends) provide insights into how the project is advancing and help identify delays or bottlenecks.

Option B is correct as it fits the informational needs of a project manager.

Other options:

A: Defect reports are too detailed for steering groups, which prefer strategic summaries or risk reports.

C: Pie charts may provide high-level summaries, but development teams usually need detailed defect or test result data.

D: System users (e.g., customers) are not responsible for project risks and would not benefit from test risk rankings.

Answer: B. Progress trend charts for the project manager

Beta testing is a type of acceptance testing performed by end users in a real-world or production-like environment. It is especially relevant for cloud-based and SaaS platforms where widespread feedback is required before release.

Option B is correct because SaaS platforms often release features to a subset of users (beta users) to test the software under actual operating conditions, get feedback, and fix any defects that were not found during internal testing. This allows vendors to validate functionality, performance, and usability in diverse environments.

Other options:

A: Beta testing is not limited to Commercial Off-the-Shelf (COTS) software.

C: Incorrect — beta testing is a form of acceptance testing, not a separate unrelated technique.

D: Incorrect — beta testing and acceptance testing overlap, but they are not synonyms; the terminology does not change based on the development approach (Agile or not).

Answer: B. Beta testing is often used for acceptance testing of Software as a Service (SaaS) platforms

Decision Model and Notation (DMN) is a standardized approach used to model decision logic, often represented in decision tables that evaluate inputs and determine outputs. In this scenario, the entitlements granted to a candidate are based on the total score from two exams, where:

Each exam can be graded as either 0 or 1.

The combined score can be 0, 1, or 2.

The entitlements depend on the combined result:

0 → No entitlements

1 → Partial entitlements

2 → Full entitlements

Among the given diagrams:

Option A simply lists test cases but lacks explicit logic modeling.

Option B shows a mapping from total score to entitlements but doesn't model how the total is derived from the two exams.

Option C redundantly splits outputs into multiple Boolean fields and doesn't reflect how the decision is made from exam inputs.

Option D is the correct representation.

Option D uses:

e1 and e2 as inputs for Exam #1 and Exam #2.

Result as the sum of e1 + e2.

A final Output mapped based on the Result:

0 → No

1 → Partial

2 → Full

This structure accurately follows the DMN standard by expressing inputs, a derived result, and the corresponding decision output, making Option D the correct and most complete decision model.

Exact Reference – ISTQB CTFL Acceptance Testing Syllabus (Section 2.3):

“Decision tables are commonly used to express business rules that determine outputs based on combinations of inputs. DMN formalizes this structure to support automated reasoning.”

When stakeholders provide conflicting acceptance criteria, resolving the conflict effectively requires focusing on the underlying business goals rather than getting stuck in technical or solution-level disagreements.

Option D is correct because it aligns with the core role of a business analyst and an acceptance tester: to understand and validate business needs. By exploring the root business objectives, you can help stakeholders reframe the problem and reach a compromise based on what delivers the most value.

Other options:

A may lead to confrontation and unproductive discussion without proper facilitation.

B is risky — prioritizing stakeholders may escalate conflict or appear biased.

C assumes you can objectively resolve the conflict based only on pros and cons, but without understanding the business context, the decision may not meet stakeholder needs.

Answer: D. Instead of discussing conflicting technical solutions, you try to understand the underlying business needs

Acceptance criteria define the conditions under which a user story or requirement is considered complete and acceptable to stakeholders. They clarify the expected behavior, outcomes, or attributes of the system.

Option C is correct because it accurately reflects that acceptance criteria are used to specify what is expected from the system in relation to a given requirement or user story. This ensures a shared understanding among developers, testers, and business stakeholders.

Other options:

A is vague and misleading — acceptance criteria relate directly to specific stories or features, not generally to high-level goals.

B is partially correct but limited — while acceptance criteria help define test conditions, their purpose is broader than just test specification.

D is incorrect — acceptance criteria are not related to code coverage, which is a technical test metric.

Answer: C. For each requirement or user story, the acceptance criteria refine and specify what is expected

Usability testing involves evaluating a product by observing real users performing tasks. The “think-aloud” method is a cornerstone of qualitative usability testing. Test participants verbalize their thoughts while interacting with the system, revealing what they understand, find confusing, or expect. This method helps identify usability problems tied to user behavior and thought processes.

Option D is correct because it directly reflects this principle — walkthroughs and think-aloud sessions highlight pain points users face while performing tasks.

Other options:

A describes expert reviews but incorrectly attributes user insight, which is less direct.

B misunderstands biometrics — they measure physiological responses (e.g., stress, eye movement) but don’t explain behavior retrospectively.

C is incorrect — log files show user actions, but identifying "strong points" like visual attraction requires observation, not just logs.

Answer: D. Walkthrough and thinking aloud methods can indicate difficulties users experience with certain tasks.

=======

The relationship between business goals, business needs, and requirements is hierarchical and reflects increasing levels of specificity:

Business Goals: High-level strategic objectives.

Business Needs: Problems or opportunities that must be addressed to achieve those goals.

Requirements: Specific capabilities or conditions the system must satisfy to meet the needs.

Option B is correct because it accurately describes how these elements relate at different abstraction levels in the requirements hierarchy. This relationship is fundamental to business analysis and accepted by standards like BABOK and ISTQB.

Other options:

A is reversed — business goals usually precede and drive the elicitation of requirements.

C and D misrepresent the sequence — product requirements are derived from business goals and needs, not the other way around.

Answer: B. Business goals, business needs and requirements describe, at different levels of abstraction, what shall be achieved

Ensuring traceability between requirements (user stories) and test cases is a cornerstone of quality assurance in acceptance testing. It confirms that all business needs are covered by corresponding tests and helps assess the impact of changes. Traceability matrices or tools are used to track these links throughout the lifecycle.

Option B is correct because regularly verifying and updating traceability ensures that acceptance test coverage remains aligned with evolving requirements — a best practice in quality assurance.

Other options:

A (review of source code) is a white-box technique, more suitable for unit or integration testing.

C (checklist-based verification of requirements) is useful but focuses on requirement quality, not directly on testing activities.

D (eye tracking) is a usability evaluation technique and not standard for verifying test case feasibility.

Answer: B. Verification of the traceability between user stories and test cases to make sure it is up to date.

Poorly defined requirements are a leading cause of defects and project failure. According to the ISTQB CTFL Acceptance Testing Syllabus and IQBBA FL Syllabus, the quality of requirements plays a critical role in successful solution development and acceptance testing. Requirements must be clear, unambiguous, complete, and testable. When they are vague or ambiguous, stakeholders may interpret them differently, which can lead to incorrect implementations, inadequate testing, and ultimately rework or rejection during acceptance.

Option A is explicitly supported by the ISTQB Foundation Syllabus and IQBBA principles. In contrast:

Option B is incorrect because Agile lifecycles still place great emphasis on requirement engineering, even though requirements evolve iteratively.

Option C misrepresents INVEST: it is a guideline for writing good user stories but does not replace reviews or validation techniques.

Option D is risky and not endorsed by ISTQB. While testers may identify ambiguities, the correct approach is to clarify them with all relevant stakeholders, not make assumptions.

Exact Reference – ISTQB CTFL Acceptance Testing Syllabus (Section 1.3.1):

“Ambiguous, incomplete, or inconsistent requirements increase the risk of misunderstanding between stakeholders, leading to incorrect implementation and ineffective tests.”

In Gherkin syntax (Given-When-Then), the purpose is to describe system behavior in a way that’s understandable to all stakeholders. Test steps should focus on user intentions and observable results — not UI implementation details — to ensure maintainability and abstraction.

Line 3 ("click 'Buy Tickets' button") refers explicitly to a UI element, which should generally be avoided in acceptance tests. Instead, it could say "I request to buy tickets."

Line 7 ("I should provide my personal data") is describing an action the user must take, not an outcome or result. In a Gherkin “Then” step, we expect an observable system response, not further user interaction.

Option C identifies both of these review concerns correctly.

Other options:

A includes an incorrect comment about line 4 ("quantity should not be set") — setting a value is acceptable.

B is false — the test case has reviewable issues.

D might be valid in a different context (e.g., boundary tests), but that’s not a flaw in the existing scenario.

Answer: C. Line 3 refers to an element of the user interface, which is to be avoided and line 7 is an action and not a result

UX task analysis focuses on understanding how users perform their tasks in real-world contexts. It captures not only the sequence of actions but also the surrounding environment — including physical conditions (light, noise), devices used, interruptions, and constraints. These external or environmental conditions become vital inputs to UX design decisions, helping teams adapt interfaces and workflows to user realities.

Option C is correct because it emphasizes this key aspect of UX task analysis: capturing external conditions that influence usability and system interaction.

Other options:

A focuses on user profiling, not task analysis.

B refers to business process modeling, which is more strategic and less user-context specific.

D refers to benchmarking or inspiration analysis — useful for design ideation but not task analysis.

Answer: C. External conditions are considered as input for subsequent design steps.

Let’s analyze the DMN table shown in the image:

Rule 1: If weight ≤15, size ≤50, and distance ≤10 → use Normal bicycle

Rule 2: If weight is between 15 and 60 kg, size ≤150, and distance ≤25 → use Electric cargo bike

Rule 3: Otherwise → use Electric van

Now consider the options:

A: Incorrect — parcel size is not the only determining factor for using electric vans; it's about weight, size, and distance combined.

B: Incorrect — normal bicycles are used only when weight ≤15 kg, size ≤50 cm, and distance ≤10 km — so not just “short trips.”

C: Incorrect — electric cargo bikes are explicitly used for short trips (≤25 km), per Rule 2.

D: Correct — based on the rules, any weight above 15 kg (and up to 60 kg) results in the use of electric cargo bikes. So if weight >50 kg (but ≤60), cargo bike is still used under the conditions of Rule 2.

Therefore, the most consistent interpretation of the decision model is:

Answer: D. When the weight of the parcel exceeds 50kg then the electric cargo bike is necessarily used

Beta testing is a type of external user acceptance testing performed by potential or existing customers in a real-world environment. It typically occurs after internal validation and acceptance tests have been passed. The purpose is to validate the product in realistic contexts, identify usability issues, uncover defects that may have been missed in lab settings, and gather feedback for improvements.

Option C is correct because it best describes the intent and value of beta testing — to observe how the product performs in real-life configurations, which may include varying hardware, usage patterns, or business workflows.

Option A is incorrect — while some people use the terms loosely, beta testing is not a strict synonym for acceptance testing. Acceptance testing usually refers to more formal, criteria-driven testing (e.g., alpha or internal acceptance testing), while beta testing emphasizes broad, usage-based validation.

Option B is misleading — beta testers may follow scenarios, but beta testing is not typically based on predefined acceptance criteria alone. It emphasizes exploration in realistic use cases.

Option D is false — beta testing is not primarily about measuring test coverage. It is qualitative and feedback-driven rather than systematically structured.

Exact Reference – ISTQB CTFL Acceptance Testing Syllabus (Section 3.2):

“Beta testing is performed by users in their own environment and supports validation of the system in realistic operational conditions.”