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

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.

According to ISTQB and the Business Analysis Body of Knowledge (BABOK) standards, the terms business goals, business needs, and requirements are related but represent different levels of abstraction in defining what an organization aims to achieve.

Business Goals represent the high-level strategic objectives an organization wants to accomplish. These are broad statements of intent and typically reflect long-term ambitions.

Business Needs specify what the business must address to meet its goals; these are more focused descriptions of the problems or opportunities that justify the business change. They provide a rationale for why a project or initiative is undertaken.

Requirements are detailed specifications that describe the features, functions, or qualities the solution must have to fulfill the business needs.

The relationship is hierarchical and increasingly specific: business goals set the overarching purpose, business needs interpret these goals into actionable problem statements or opportunities, and requirements specify the solution details.

ISTQB glossary and syllabus excerpts confirm this layered approach, clarifying that these terms are not synonymous but instead describe the same concept at varying levels of detail and abstraction. Therefore, option B best captures this nuanced relationship.

Exact Extract from ISTQB Foundation Level Syllabus (Business Analysis Section):

"Business goals, business needs, and requirements describe, at different levels of abstraction, what shall be achieved by the business change. Business goals are high-level statements; business needs are statements of problems or opportunities to be addressed, and requirements define the detailed attributes of the solution to meet those needs."

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.

In ATDD (Acceptance Test-Driven Development), business process modeling (e.g., using BPMN) is a powerful way to visualize workflows and system behavior from the user's perspective. Testers can use these models to derive acceptance test cases by covering different business paths, including normal flows, alternate flows, and exception conditions.

Option A is correct because it reflects this practical usage: testers analyze the business process model and create test cases to ensure coverage of the different paths the system might take. This aligns acceptance testing directly with business logic and enhances traceability.

Other options:

B is partially valid but less direct; business analysts help define rules, but test case creation is a tester's role.

C reverses the correct flow; BPMN models are often created first and used to define or validate acceptance criteria, not the other way around.

D is incorrect — requirements/user stories are usually defined through stakeholder collaboration, not auto-generated from BPMN diagrams.

Answer: A. Testers use business process models to write test cases that cover the different paths.

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

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.

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

Bi-directional traceability is a fundamental concept in requirements engineering and test management. It refers to the ability to trace:

Forward: From requirements/user stories to corresponding test cases (to ensure all requirements are covered).

Backward: From test cases to the requirements they validate (to ensure every test aligns with a requirement).

According to the ISTQB Certified Tester Foundation Level and Acceptance Testing syllabi, bi-directional traceability is essential to manage test coverage and ensure completeness. It allows project managers and product owners to assess whether all specified requirements/user stories have been covered by appropriate test cases, helping to identify any untested functionality.

This also supports impact analysis during change management — knowing which test cases will be affected by a change in a requirement.

Option B is correct because it precisely captures this benefit. While Option C refers to reviewing test cases against acceptance criteria (a valid review activity), the bi-directional traceability's key benefit from a management and quality assurance perspective is traceability for coverage.

Exploratory testing is an unscripted, experience-based testing technique where the tester learns about the system, designs tests, and executes them simultaneously. It is especially effective in Agile environments, where rapid feedback and creative exploration are valuable.

Option D is the least likely action because scripting automated test scripts is a structured activity that typically occurs after exploratory sessions or during more formal test phases. Exploratory testing emphasizes manual exploration, not automation scripting.

Other options:

A is part of the core purpose of exploratory testing — discovering the product.

B is relevant — defining a charter and discussing it with stakeholders (like the Product Owner) helps guide the exploratory session.

C is also relevant — results of exploratory tests should be documented and communicated.

Answer: D. Scripting of the automated test scripts

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

UX (User Experience) requirement analysis involves studying the context in which users will interact with a system. This includes analyzing:

Who the users are (personas/user profiles)

What tasks they perform (task analysis)

Where and how they perform them (environmental conditions)

Option D is correct because task analysis in UX encompasses understanding the user’s physical and digital environment. Environmental conditions (e.g., lighting, noise, interruptions) are important for designing accessible and effective interfaces.

Let’s review other options:

A is partially correct but not fully aligned — personas describe user archetypes, not primarily competitor analysis.

B refers to user profiling but interprets it narrowly. Business knowledge is only one part of profiling.

C confuses security with UX. Security requirements often come from risk analysis, not usage scenarios.

Answer: D. Environmental conditions such as light conditions are obtained from a task analysis.

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

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.

Test reports summarize the results of test execution and are often used by stakeholders, including business owners and release managers, to make informed decisions about whether to release a product. If these reports are ambiguous, incomplete, or inaccurate, the decisions based on them could be flawed, leading to reputational damage, customer dissatisfaction, or regulatory issues.

Option A is correct because it highlights the risk of basing critical go/no-go decisions on poor-quality reporting.

Other options:

B describes a problem with test case implementation, not test reporting.

C mentions public perception, which might be influenced by report quality, but it is secondary to the internal decision-making purpose.

D refers to human error during test execution or design, not the purpose of reviewing test reports.

Answer: A. If the test reports are unclear or incomplete, the decision to release the product can be based on non-reliable information

In BDD (Behavior-Driven Development) and ATDD (Acceptance Test-Driven Development), “living documentation” refers to executable acceptance criteria that are kept up to date throughout development. These acceptance tests are written in natural, structured language (like Gherkin's Given-When-Then) and are linked directly to business requirements.

Option A is correct — “living documentation” bridges the gap between business and development by keeping requirements executable, relevant, and up to date.

Other options:

B is misleading — visual ATDD may use process models, but this is not a defining characteristic of BDD or ATDD.

C is true in part — BDD scenarios often use Given-When-Then, but this by itself is not the most defining statement when comparing options.

D is incorrect — ATDD and BDD support collaboration, but they do not expect business analysts to write code or automation scripts.

Answer: A. The concept of "living documentation" means that business requirements become executable

Usability testing aims to evaluate the ease of use, efficiency, and satisfaction with which users can achieve tasks. When checking the ergonomics (e.g., layout, visual clarity, interaction comfort), checklist-based evaluations are particularly useful.

Option A is correct because a checklist of ergonomic/usability heuristics (e.g., Nielsen’s heuristics, ISO 9241 standards) allows evaluators to systematically assess whether the interface meets established usability criteria.

Other options:

B (Biometrics-based evaluation) tracks physiological responses (e.g., stress or eye movement), which are useful but indirect and less targeted to ergonomic checks.

C (Walkthroughs) help assess usability by observing task flows, but they are less focused on layout and ergonomic design.

D (Log file analysis) captures behavior but not directly ergonomic issues like spacing, font size, or element alignment.

Answer: A. Checklist-based evaluation

In cross-functional, globally distributed teams, establishing collaboration, communication, and trust is key. A workshop (even virtual) is a proven method for initiating alignment, especially when a new team member joins, and project coordination is weak.

Option A promotes transparency and collective understanding, crucial for building team cohesion.

Option B is too passive and one-directional. Long emails rarely solve coordination problems in Agile or collaborative contexts.

Option C is about tool setup, not team integration or communication — tools are supportive but not substitutes for human connection.

Option D is not efficient; traveling to meet each team member is impractical and doesn’t guarantee a shared team vision.

✔ Answer: A. You organize a workshop with all team members to establish common understanding and to lay the foundation for fruitful trusting collaboration.

Collaboration between business analysts and testers is critical in Agile and acceptance testing environments. One of the most effective areas of cooperation is the joint development and review of acceptance criteria for user stories. This ensures that criteria are testable, clearly defined, and aligned with stakeholder expectations.

Option B is correct because creating acceptance criteria is where both business analysts (who understand the business needs) and testers (who ensure testability and clarity) contribute effectively.

Other options:

A (Business needs assessment) is typically a responsibility of business analysts, not a joint activity with testers.

C (Review of risk to prioritize acceptance tests) is a valuable activity but comes after criteria are defined. While it can be collaborative, it's more specific to test planning.

D (Definition of Beta Testing sessions) is less relevant to ongoing collaborative work between testers and BAs — this involves users and release planning.

Answer: B. Development of acceptance criteria for user stories

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.

In acceptance testing, close collaboration between testers and business analysts ensures that test results are properly interpreted and aligned with business expectations.

A. Testers verify the effectiveness of corrective actions and document their verdict in the defect report — Correct. When a defect is resolved, testers retest the system and record whether the issue is fixed. This is a common testing activity during acceptance test execution.

E. Business analysts compare the test execution result to the acceptance criteria of the requirement / user story — Correct. This ensures the functionality fulfills business needs and determines whether the criteria have been met for acceptance.

Incorrect options:

B: Testers do record actual results, but not necessarily "in a defect" unless a defect is found.

C: Priority is usually assigned by business analysts or stakeholders, not testers alone.

D: Business analysts do consider the impact of changes, but evaluating development risks is more a joint task with architects or developers.

Answer: A and E