HomeCTAL-AT v2.0Practice questionsTest Automation and Test Tools
CTAL-AT v2.0 · ISTQB · Test Automation and Test Tools · Bank updated 2026-07-03

CTAL-AT v2.0 practice questions: Test Automation and Test Tools

5 free questions from 13 on this area · answer and explanation for each · no sign-up

These 5 questions come from the Test Automation and Test Tools section of our CTAL-AT v2.0 bank (13 questions on this area, which carries 5% of the real exam). Every question is original, with the correct answer explained and linked to the source it is drawn from.

Start 6 free in study mode → All CTAL-AT v2.0 sample questions
1/5 · Test Automation and Test Tools
A team practicing Behaviour-Driven Development (BDD) writes scenarios in Given-When-Then format that are automated and executed on every commit. A developer argues these scenarios are 'just automated tests' and could instead be written directly as plain unit-test code, skipping the Given-When-Then structure. What is the MOST important benefit of the Given-When-Then format that the developer is overlooking?
AIt guarantees that the automated scenarios execute faster than equivalent tests written directly as unit-test code.
BIt removes the need for any exploratory testing once the BDD scenarios pass, since the scenarios are considered complete coverage.
CIt automatically ensures 100% code coverage of all acceptance criteria without any additional analysis.
DIt provides a shared, business-readable specification that the whole team can discuss, review, and validate both before and after automation, supporting collaboration and a common understanding of behavior.
Show answer & explanation
D is correct. The purpose of the Given-When-Then structure in BDD is to keep acceptance criteria in a natural-language, business-readable form so they function as a shared specification and living documentation for the whole team, not just as syntax for automation. This supports collaboration and shared understanding, distinct from claims about speed, coverage, or replacing exploratory testing.
↗ the ISTQB Advanced Level Agile Tester Syllabus v2.0 (GA 2026-04-17) + ISTQB CTFL v4.0 as base knowledge — Test Automation and Test Tools
2/5 · Test Automation and Test Tools
A team relies on an automated regression suite that runs in the CI/CD pipeline on every merge to the main branch. Over several sprints, testers notice a growing number of intermittently failing ('flaky') tests, and developers have started merging changes even when the pipeline reports failures. What is the MOST significant risk this creates for the team's use of automated regression as a safety net?
AFlaky tests are automatically quarantined by the CI/CD tool, so no team action or investigation is required.
BThe test management tool will stop recording results for automated tests once flakiness is detected.
CThe CI/CD pipeline will take longer to execute overall because of the flaky tests.
DThe team loses confidence in and trust of the regression suite, so genuine regressions may go unnoticed and be released to production.
Show answer & explanation
D is correct. Automated regression suites act as a safety net only if the team trusts and acts on their results. Persistent flaky failures that are ignored lead to 'alarm fatigue,' eroding confidence in the pipeline and allowing genuine regressions to reach production undetected, which is a far more significant risk than slower execution or assumptions about automatic tooling behavior.
↗ the ISTQB Advanced Level Agile Tester Syllabus v2.0 (GA 2026-04-17) + ISTQB CTFL v4.0 as base knowledge — Test Automation and Test Tools
3/5 · Test Automation and Test Tools · easy
The test automation pyramid is a widely used model for planning the balance of automated checks across test levels in an agile project. According to this model, how should the number of automated tests typically be distributed across the unit, service/API and GUI levels?
AAutomated tests should be concentrated almost entirely at the service/API level, since this level alone provides sufficient confidence and both unit and GUI automation are considered redundant effort.
BThe largest number of automated tests should sit at the unit level, a smaller number at the service/API level, and the fewest at the GUI level, because lower-level tests execute faster, are more stable and pinpoint defects more precisely.
CThe largest number of automated tests should sit at the GUI level, since only tests that exercise the full application through its user interface can confirm that the system behaves correctly for real end users.
DAutomated tests should be split roughly evenly between the unit, service/API and GUI levels so that no single test level is under-represented in the regression suite.
Show answer & explanation
B is correct. The test automation pyramid guides teams to invest most heavily in fast, stable, cheap-to-maintain unit-level checks, fewer at the service/API level, and the fewest at the slow, brittle GUI level. This shape optimizes feedback speed and defect localization while still retaining some end-to-end confidence. Inverting or flattening this distribution undermines the fast-feedback goal that automation is meant to serve in agile delivery.
↗ the ISTQB Advanced Level Agile Tester (CTAL-AT) Syllabus v2.0 — Test Automation and Test Tools
4/5 · Test Automation and Test Tools
A team's service under test integrates with a third-party payment provider whose test environment is frequently unavailable, enforces strict rate limits, and charges per call. This instability is causing the automated regression suite to fail intermittently for reasons unrelated to the code under test. Which type of tool would BEST address this specific problem?
AA test management tool that records and tracks manual exploratory testing charters, since the issue concerns coordinating test coverage rather than the reliability of automated execution.
BA service virtualization/stubbing tool that simulates the third-party payment provider's responses, allowing the automated suite to run reliably and independently of the external environment's availability and limits.
CA production monitoring and log-analytics tool that detects anomalies after release, since the priority should be observing real payment transactions in production rather than stabilizing pre-release automated tests.
DA static code analysis tool that scans the codebase for coding standard violations, since intermittent failures are most often caused by undetected code quality defects rather than environment instability.
Show answer & explanation
B is correct. When automated tests depend on an unreliable, rate-limited or costly external system, service virtualization/stubbing tools simulate that dependency's behavior so the suite can execute quickly, deterministically and independently. This is a standard category of tool support for agile testing precisely because real third-party test environments are often unsuitable for frequent CI/CD execution.
↗ the ISTQB Advanced Level Agile Tester (CTAL-AT) Syllabus v2.0 — Test Automation and Test Tools
5/5 · Test Automation and Test Tools
A team new to test automation adopts a capture/replay (record-and-playback) tool so that non-technical testers can generate automated GUI regression scripts simply by performing actions manually once. After a few sprints, the suite has grown large but a small UI change (such as renaming a button) breaks dozens of scripts simultaneously. What does this outcome MOST clearly illustrate about capture/replay tools?
AThis is expected and acceptable overhead, since the syllabus recommends capture/replay as the standard approach for building a long-term, low-maintenance automated regression suite in agile projects.
BThis confirms that capture/replay tools are best suited to unit-level automation, and the team's mistake was applying a capture/replay tool to GUI testing instead of its intended purpose at the unit level.
CThe failures indicate the tool itself is defective, since a properly functioning capture/replay tool should automatically update all recorded scripts whenever the underlying UI element names change.
DCapture/replay scripts typically hard-code UI element references and exact interaction sequences without an abstraction layer, so they are quick to create but brittle and expensive to maintain as the application evolves.
Show answer & explanation
D is correct. Capture/replay tools let anyone quickly generate scripts by recording UI actions, but without an abstraction layer such as a page-object model, the resulting scripts embed literal UI references throughout. A single UI change can then ripple across the suite and break many scripts at once, illustrating why capture/replay alone is a common misconception as a shortcut to maintainable, scalable automation.
↗ the ISTQB Advanced Level Agile Tester (CTAL-AT) Syllabus v2.0 — Test Automation and Test Tools
Practise all 13 Test Automation and Test Tools questions - start free → See the whole CTAL-AT v2.0 bank

Other CTAL-AT v2.0 areas

The same kind of free sample for every other section of the CTAL-AT v2.0 bank:

Test Strategy and Test Approach Challenges17 qPeople and Teams21 qTest Management and Test Process Improvement27 qShift Left26 qAgile Approaches and Test Techniques37 q

Study Test Automation and Test Tools with instant feedback

6 free questions · filter study mode by area and difficulty · error log with spaced repetition · no card, no dumps, no ads.

Create your free account →
Read next
CTFL (ISTQB) Study Plan: 4 Weeks to Pass Without a Bootcamp ISTQB CTFL: 40 questions, 60 minutes, 26 to pass, no course required. A four-week self-study plan sized to the syllabus hours. Verified 14 Sep 2026.
ExamDeck is an independent study tool, not affiliated with, endorsed by, or sponsored by ISTQB. CTAL-AT v2.0 and related marks are trademarks of their respective owners, used for identification only. Exam facts checked against official ISTQB materials (as of August 2026); always confirm current details with the vendor before booking.