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

User Experience (UX) requirement analysis is a critical component of acceptance testing and product development. According to ISTQB Acceptance Testing syllabus and industry-aligned UX design methodologies (e.g., ISO 9241-210 and BABOK guidelines), UX requirement analysis is typically structured around the following pillars:

User Analysis – Understanding who the users are (roles, goals, experience levels)

Task Analysis – Understanding what users do (tasks, workflows, pain points)

Context Analysis – Understanding where and how users interact with the product (environmental and contextual factors)

Competitor Analysis – Understanding how similar problems are solved in the market

Option B best describes Task Analysis, one of the most practical and impactful pillars. In task analysis, business analysts and UX researchers observe how users interact with current or comparable systems to understand workflow patterns, user frustrations, needs, and required system functionality. This method helps uncover implicit needs that users may not articulate in interviews.

This approach is aligned with ISTQB’s emphasis on understanding real-world usage and business processes as a foundation for deriving acceptance criteria and tests. It supports the creation of realistic scenarios that reflect actual user behavior, which is essential for verifying system fitness for use.

The other options are inaccurate:

A refers to psychological disposition, which is more aligned with user profiling or persona development, not a core focus of user analysis in requirement engineering.

C incorrectly ties context analysis with deriving security requirements, which is not its purpose.

D describes an unrealistic or incorrect method for competitor analysis.

Therefore, Option B is the best description of a key pillar of UX requirement analysis per industry and ISTQB standards.

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

Gherkin is a structured language used in Behavior-Driven Development (BDD) to define test cases in a clear, business-readable format. It follows the GIVEN-WHEN-THEN structure:

GIVEN describes the precondition (system’s state before the action).

WHEN describes the action/event.

THEN describes the expected result or outcome.

Analyzing the phrases:

ii) “The elevator is on the Ground Floor” is a precondition — fits GIVEN.

i) “The total weight of passengers is greater than 200 kg” is an action or state change — fits WHEN.

vi) “A message ‘too many passengers’ is displayed on the screen” is the expected outcome — fits THEN.

Thus, Option A correctly maps these elements to form a well-structured Gherkin scenario.

Other options are incorrect because:

Option B misplaces an expected outcome as an action.

Option C misrepresents the order — “login” isn’t a precondition.

Option D introduces two THEN elements and violates the typical Gherkin structure.

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

“Gherkin test cases use GIVEN-WHEN-THEN structures to make the behavior of the system under test understandable by all stakeholders.”

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

Acceptance criteria must be concrete, testable, and focused on observable system behavior. They define what the system must do to satisfy a requirement and help determine whether the requirement has been successfully implemented.

REQ 3.28 states: “The automated system records critical credit application data (CCAD) needed to support application screening.” From this, we infer that the system must persistently store this data after data entry.

Option A is the best match because it provides a specific, observable behavior (CCAD being stored in a MySQL database after a successful entry) that can be verified through acceptance testing. It’s a measurable outcome, aligned with the requirement's objective.

Other options are less suitable:

Option B introduces new behavior (displaying a message) not directly tied to the original requirement.

Option C is vague ("quick and reversible") and lacks measurable criteria.

Option D refers to usability guidelines, which is not directly relevant to the storage functionality stated in the requirement.

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

“Well-written acceptance criteria are unambiguous, testable, and focused on observable results.”

Comprehensive Detailed Explanation (Approx. 200–220 words):

In the first BPMN diagram (Loan Request Process), the process starts with the receipt of a loan application. Then, parallel gateways (indicated by the “+” symbols) are used to trigger three separate evaluations: verifying employment, requesting and reviewing a credit record, and performing and reviewing a title search. These are executed concurrently, not sequentially.

After all checks are completed, the loan application is reviewed. A decision gateway (diamond with an “X”) checks whether the loan is approved. Depending on the decision:

If approved: a loan approval letter is sent, and a sub-process is triggered (represented by the rectangle with a "+" symbol inside), which is the creation of the loan contract. This is what identifies it as a BPMN “sub-process.”

If rejected: a rejection letter is sent.

In both cases, the process ends after customer notification.

Evaluation of answer options:

A: Incorrect — the verification steps occur before the loan status is determined.

B: Correct — the “Create the loan contract” activity has a “+” symbol, indicating a sub-process.

C: Incorrect — the parallel gateway means these tasks are executed concurrently, not sequentially.

D: Incorrect — all review activities are mandatory prior to application review.

Therefore, B is the correct answer.

Comprehensive Detailed Explanation:

According to the scenario described in the question, the business process for expense reimbursement includes two key timing constraints:

If the request is not processed within 7 days, an "ongoing" email is sent to the employee.

If the request is not completed within 30 days, the process is canceled and the employee is asked to resubmit the request.

However, in the BPMN model presented in the image, the second timing event (clock icon near "Approval in Progress") incorrectly shows 23 days instead of 30 days. This discrepancy misrepresents the actual business rule and violates the accuracy required in process modeling.

ISTQB Foundation Level Extension – Acceptance Testing syllabus and the Certified Tester Foundation Level Business Process Testing (CTFL-BAT) emphasize that a process model should correctly reflect the specified behavior, rules, and constraints of the business scenario. An incorrect timer can lead to miscommunication between stakeholders and incorrect automation or implementation logic.

Therefore, Option A is the most likely review comment since it directly points to this inconsistency in the model.

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.

=======

An exploratory test charter is a high-level plan or mission statement for a time-boxed exploratory testing session. It guides what the tester should focus on during the session and may include the goal of the test, specific areas of the system under test, the risk or feature to explore, the type of persona to simulate (e.g., novice or expert user), and possibly known issues to watch out for.

Option A is correct because specifying a user persona (such as a novice user) helps the tester approach the system from that perspective. This supports the goal of exploratory testing: to simulate realistic usage and uncover issues that scripted tests might miss.

Option B is incorrect — although exploratory testing is adaptive, the charter is defined before the session starts, not elaborated during execution.

Option C is misleading — charters may refer to areas of interest, but not necessarily to a predefined list of activities.

Option D is incorrect — a test oracle (i.e., the mechanism for determining whether a result is correct) is not defined by the charter. It may exist already or be inferred from requirements, heuristics, or user expectations.

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

“Charters define the focus of exploratory testing sessions and may specify the tester’s role or perspective (e.g., novice user).”

Non-functional quality attributes (also called quality characteristics) such as usability, reliability, operability, performance, and maintainability are often validated during acceptance testing to ensure the system behaves as expected under real-world conditions.

Option C is correct because operability — a subcharacteristic of usability per ISO 25010 — refers to the degree to which users can operate and control the system effectively. Acceptance testing often involves running the system in realistic settings to validate these aspects.

Other options:

A (Modularity and reusability) are more relevant to system architecture and design, not acceptance testing.

B is incorrect — time behavior (performance) can and should be tested at multiple levels, including system and integration testing before acceptance.

D is misleading — testing basic functionality is necessary, but it does not address non-functional quality attributes.

Answer: C. During acceptance testing, the operability of the product is checked in a realistic environment

ATDD and BDD are agile development approaches that emphasize collaboration among stakeholders (such as business analysts, developers, testers, and customers) to define clear and testable acceptance criteria before or as requirements are being finalized. Both techniques promote using concrete examples to drive development and validate understanding.

In ATDD, acceptance test cases are derived directly from user stories or requirements and written before the actual implementation starts. In BDD, scenarios are expressed in natural language (often using Gherkin syntax) to describe behaviors the system should exhibit under specific conditions. In both cases, these tests serve not only as validation tools but also as executable specifications — i.e., shared understanding expressed through concrete examples.

Option B is correct because both methodologies use examples (scenarios/test cases) to describe how a system should behave — serving as acceptance criteria.

Incorrect options:

Option A wrongly suggests BDD defers testing until after requirements are finalized — it actually promotes early collaboration.

Option C is false — in ATDD, test cases are based on predefined acceptance criteria, not written beforehand.

Option D is inaccurate — acceptance tests in ATDD and BDD may be automated but are collaboratively written first, not by test automation engineers alone.

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

“Both ATDD and BDD involve the collaborative definition of test cases before implementation to clarify requirements and serve as product usage examples.”

This user story is about a logged-in user measuring their blood sugar using a connected glucose meter and seeing the result quickly. The acceptance criterion specifies that the result should be displayed in less than four seconds.

Option B is correct because:

It starts with a valid GIVEN precondition (“I am logged in”).

The WHEN step matches the functionality described in the user story (blood sugar measurement using a connected device).

The THEN step explicitly includes the performance expectation (“less than 4 seconds”), aligning directly with the acceptance criterion.

Other options:

A is incorrect — while it mentions the correct functionality, “I am diabetic” is not a necessary system precondition.

C refers to blood pressure instead of blood sugar — mismatched with the user story.

D introduces additional functionality (alerts for hypo-/hyperglycemia), which is not part of the specified acceptance criteria.

Answer: B. GIVEN I am logged in on the system … THEN I can see the result … in less than 4 second

The ISTQB CTFL Acceptance Testing Syllabus emphasizes the importance of collaboration between business analysts and testers throughout the testing lifecycle, especially during test planning and risk identification. Business analysts contribute domain knowledge and business context, which is crucial in identifying business-critical areas, defining priorities, and ensuring that acceptance tests align with business goals.

Option A correctly identifies this collaboration. During test planning, business analysts help define acceptance criteria, identify risks from a business perspective, and support test prioritization to focus on high-value features. Their early involvement ensures that acceptance tests are meaningful and support stakeholder expectations.

Option B is incorrect as business analysts actively review acceptance tests to confirm alignment with business rules, regardless of technical complexity.

Option C is inaccurate because although testers seek to understand business needs, the responsibility for identifying those needs lies with business analysts.

Option D is incorrect; business analysts remain engaged throughout the project lifecycle, including test support and defect triage.

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

“Testers and business analysts collaborate during test planning and analysis activities to ensure the tests meet business needs and risk areas are adequately covered.”

Therefore, A provides the most accurate and comprehensive description.

Comprehensive Detailed Explanation (Approx. 200–220 words):

This question focuses on the coverage criterion “execute all possible process tasks” from the BPMN model of a $100 withdrawal.

Let’s analyze the process:

The process starts when the user selects “Withdraw $100.”

A decision gateway checks if the balance is ≥ $100.

If NO: the card is removed and withdrawal is rejected.

If YES: the user is prompted to select whether they want a receipt.

Depending on the user’s choice:

If YES: the receipt is printed → then $100 is withdrawn → card is removed.

If NO: $100 is withdrawn → card is removed (no receipt printed).

To meet the criterion “execute all possible process tasks,” we must cover:

Rejected withdrawal path (balance < 100)

Withdrawal without receipt

Withdrawal with receipt

Receipt printing

Card removal in both success and failure

Test case coverage:

Test 1 (balance = $100, receipt = YES): covers successful withdrawal + receipt printed.

Test 3 (balance = $85): covers withdrawal rejected + card removed.

Together, these two tests execute all possible process tasks:

Withdraw with receipt

Reject due to insufficient balance

Receipt printed

Withdraw funds

Remove card

Other test combinations are redundant or do not add new path coverage.

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.

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.

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.

Model-Based Testing (MBT) is a test design technique in which test cases are derived from a model that describes some aspects of the system’s behavior. In the context of acceptance testing, MBT can be used to generate high-level acceptance test cases automatically from business process models, use case diagrams, state models, or decision tables.

Option A is correct because MBT supports the systematic generation of acceptance test cases from these models, enabling better coverage of business rules and workflows while maintaining traceability to the requirements.

Other options:

B is close but slightly off: prioritization of acceptance tests in a priority-based approach depends on business value or stakeholder-defined priorities, not strictly on product risks.

C is incorrect. Risk-based testing relies on structured risk assessment, not just intuition or experience.

D is false. Black-box testing focuses on inputs and outputs without referencing the internal structure (such as function calls), which is characteristic of white-box testing.

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

“Model-based testing can be used to generate acceptance test cases systematically based on models representing business processes or system behavior.”

Performance testing assesses how a system behaves under specific conditions, typically focusing on responsiveness, stability, and resource usage. The type of performance test depends on the workload model:

Load testing evaluates performance under expected peak usage.

Stress testing pushes the system beyond its capacity to assess limits.

Endurance/stability testing checks for performance degradation over extended periods.

Option A correctly describes that performance test types are determined by the workload simulation strategy.

Other options:

B confuses performance with security testing — malicious attack robustness is a security focus, not performance.

C is partly correct but less comprehensive than A. While testing should simulate realistic conditions, categorization into stress/load/endurance is better aligned with workload modeling.

D is misleading — performance tests validate systems against performance requirements; they are not primarily used to define them.

Answer: A. Depending on the model used to simulate the workload, performance tests are called load, stress or endurance / stability tests.

Comprehensive Detailed Explanation (Approx. 200 words):

Acceptance criteria should focus on business-relevant outcomes that are specific, testable, and observable. In this user story, the goal is to validate that the registration functionality is available and behaves as expected.

Let's analyze each proposition:

i) “A registration form is displayed on the screen.”

→ Valid. It is observable, specific, and directly aligned with the user story.

ii) “The form is written in the Groovy language; the cursor is initially set on the ‘login’ field...”

→ Invalid as acceptance criteria. It contains implementation details (e.g., “Groovy language”) irrelevant to business stakeholders. Also, low-level UI behavior like cursor position is overly technical and not a business-driven criterion.

iii) “I cannot register myself if the login I choose is used by another player.”

→ Valid. It defines system behavior based on a business rule (unique login) and is testable.

iv) “After successful registration process I am informed about it by an e-mail.”

→ Valid. It describes a user-visible outcome after registration, which is observable and testable.

Correct answer: D. only i), iii), and iv) are well-written acceptance criteria.

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

“Acceptance criteria must describe the externally visible and verifiable system behavior, excluding implementation details.”

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