Free Practice Questions for iSQI CTFL-AcT Exam

To describe business processes and business rules in a structured, visual, and analyzable way, a process modeling tool is the most appropriate. These tools often support standards like BPMN (Business Process Model and Notation) for process workflows and DMN (Decision Model and Notation) for business rules.

Option D is correct because process modeling tools enable business analysts and stakeholders to capture, analyze, and communicate business operations and decision logic, which are foundational for acceptance test case generation in ATDD.

Other options:

A (Project management tools) manage schedules, resources, and scope, not business rules.

B (Test management tools) handle test cases and execution, not business modeling.

C (Defect tracking tools) track bugs but are not used for describing processes or rules.

Answer: D. Process modelling tool

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 Acceptance Test-Driven Development (ATDD), test cases are derived early and are based on business understanding. Application workflows modeled using BPMN or similar notations provide a clear, visual representation of how a user interacts with a system and which business rules are applied.

Option D is correct because these workflow models help define acceptance test cases by outlining the process paths, user interactions, and decision points. These visual models bridge the gap between business needs and testing.

Other options:

A is incorrect — business rule and process models are created based on need; one doesn't necessarily precede the other.

B is misleading — writing business rule models doesn't imply stakeholder commitment to ATDD.

C is incorrect — Gherkin is used for writing scenarios in BDD/ATDD, but business rules are typically modeled using DMN, not Gherkin.

Answer: D. Application workflow models facilitate the generation of ATDD acceptance test cases

The relationship between testing and requirements engineering is iterative and collaborative. According to ISTQB CTFL and IQBBA FL syllabi, test activities such as test analysis and test design involve reviewing and interpreting acceptance criteria to derive test conditions and test cases. During this process, testers may identify ambiguities, conflicts, or missing acceptance conditions. These insights often result in feedback to business analysts or stakeholders, leading to refinement or changes in the acceptance criteria to ensure clarity, completeness, and testability.

This iterative feedback loop is essential in both Agile and traditional lifecycles. Therefore, option D is correct. It reflects the dynamic interaction between requirements and test design, where improving one often improves the other.

Other options are incorrect:

Option A falsely assumes business analysts don’t engage in test design, while in practice, they collaborate closely with testers.

Option B incorrectly suggests that IQBBA and ISTQB lifecycles are mutually exclusive. In fact, they complement each other.

Option C is incorrect in sequencing. In reality, solution evaluation (IQBBA) follows test execution, not precedes it.

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

“During test analysis, inconsistencies or missing information in the acceptance criteria can be identified and addressed through collaboration with business analysts.”

==================

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

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 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

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.