CTAL-TAE · Question #89
You are currently designing the TAA of a TAS. You have been asked to adopt an approach for automatically generating and executing test cases from a model that defines the SUT. The SUT is a…
The correct answer is C. Looking for tools that allow performing setup and teardown of the test suites and the SUT. Option C is correct because the SUT relies on unreliable hardware and communication links, making it essential that the Test Automation Architecture (TAA) can reliably initialize the SUT to a known state before each test (setup) and clean up resources afterward (teardown)…
Question
You are currently designing the TAA of a TAS. You have been asked to adopt an approach for automatically generating and executing test cases from a model that defines the SUT. The SUT is a state-based and event-driven that is described by a finite-state machine and exposes its functionality via an API. The behavior of the SUT depends on hardware and communication links that can be unreliable. Which of the following aspects is MOST important when designing the TAA in this scenario?
Options
- ALooking for tools that allows direct denoting of exceptions and actions depending on the SUT
- BAdopting a test definition strategy based on classification tree coverage for the test definition
- CLooking for tools that allow performing setup and teardown of the test suites and the SUT.
- DAdopting a test definition strategy based on use case/exception case coverage for the definition
How the community answered
(61 responses)- A13% (8)
- B5% (3)
- C54% (33)
- D28% (17)
Explanation
Option C is correct because the SUT relies on unreliable hardware and communication links, making it essential that the Test Automation Architecture (TAA) can reliably initialize the SUT to a known state before each test (setup) and clean up resources afterward (teardown). Without this, a failed or incomplete prior test-especially on flaky hardware-could corrupt the SUT's state, causing cascading false failures across the entire test suite.
Why the distractors are wrong:
- A (exception/action denoting tools) addresses error handling within tests, but is not the primary architectural concern when the core problem is environmental unreliability between tests.
- B (classification tree coverage) is a black-box input partitioning technique suited for data-driven testing, not for state/transition coverage of FSM-based, event-driven systems-making it a poor fit for this SUT.
- D (use case/exception case coverage) is a behavioral strategy relevant to requirements-based testing, but the scenario already specifies that test cases are automatically generated from the FSM model, so the test definition strategy is effectively handled by the model itself.
Memory tip: Map the scenario's biggest risk to the answer. The key word is unreliable - unreliable environments destroy test repeatability, and repeatability is owned by setup and teardown. When you see "flaky hardware/links," think "C for Cleanup and Configuration."
Topics
Community Discussion
No community discussion yet for this question.