Free Practice Questions for iSQI CTFL-AcT Exam

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.

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.

In ISTQB Acceptance Testing context, the process of refining requirements or user stories into acceptance criteria plays a crucial role in defining clear, testable conditions. These acceptance criteria act as the basis for deriving test conditions, which are in turn used to design acceptance test cases.

According to the ISTQB Foundation Level Acceptance Testing syllabus:

“Acceptance criteria are refined expressions of business requirements, and they help to determine the scope and intent of acceptance tests. These criteria are used to derive test conditions and guide the development of test cases.”

This alignment ensures that the delivered software meets the expectations set out in the requirements and satisfies the user needs. Acceptance tests are typically written from the user’s perspective and are focused on verifying that the system behaves correctly in realistic business scenarios.

Option B is correct because it explicitly describes this logical and procedural relationship between user stories, acceptance criteria, and acceptance tests.

Other options are incorrect or misleading:

A is incorrect: reviewing requirements does not eliminate the need for dynamic testing.

C is incorrect: code coverage is more relevant for unit or system-level testing, not acceptance testing.

D is incorrect: exploratory testing is a valuable supplement but does not replace the need to verify acceptance criteria.

Security testing ensures the system protects data and maintains intended behavior under potential attacks. Different techniques address specific security goals.

Option A is correct: Static vulnerability analysis inspects code or architecture without executing it, identifying weaknesses in mechanisms such as authentication (e.g., login controls) and authorization (e.g., access permissions). These mechanisms are foundational security requirements.

Other options:

B is misleading — penetration testing simulates attacks, but input validation is more often verified with fuzzing or code review.

C is incorrect — fuzzing tests input handling, not the performance of cryptographic algorithms.

D is incorrect — threat modeling is a design-time activity to identify risks; it’s not used to test policies directly.

Answer: A. Static vulnerability analysis to test authentication and authorization mechanisms

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

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

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

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.

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