CTAL-TAE · Question #115
Consider a TAS that exclusively uses the APIs of a SUT. To make this work, significant changes have been required to the SUT by adding a set of dedicated test interfaces to the APIs. All the…
The correct answer is A. The connectivity from the TAS to the dedicated test interfaces will not work. Option A is correct because the scenario's defining characteristic is that the TAS communicates with the SUT exclusively through newly added, dedicated test interfaces. When verifying the test environment setup, the most specific risk is whether the TAS can actually establish…
Question
Consider a TAS that exclusively uses the APIs of a SUT. To make this work, significant changes have been required to the SUT by adding a set of dedicated test interfaces to the APIs. All the automated tests will use these test interfaces when interacting with the SUT. Assume that you are currently verifying the correctness of the automated test environment and test tool setup. Which of the following would you expect to be the MOST specific risk associated with this scenario?
Options
- AThe connectivity from the TAS to the dedicated test interfaces will not work
- BThe process of configuring the TAS will be error-phone due to manual intervention
- CThe automated test cases will not contain the expected result
- DFalse alarms, that are unlikely to occur in the real world, will be observed during testing
How the community answered
(46 responses)- A85% (39)
- B4% (2)
- C9% (4)
- D2% (1)
Explanation
Option A is correct because the scenario's defining characteristic is that the TAS communicates with the SUT exclusively through newly added, dedicated test interfaces. When verifying the test environment setup, the most specific risk is whether the TAS can actually establish connectivity to these purpose-built interfaces - if that link doesn't work, no automated testing can proceed at all. The interfaces are novel additions to the SUT's APIs, making connectivity the primary and most scenario-specific thing to validate.
Why the distractors are wrong:
- B (error-prone manual configuration) is a general TAS setup risk applicable to virtually any automation project, not specific to the dedicated test interface architecture described here.
- C (test cases lacking expected results) is a test design concern, not a test environment verification concern - expected results should have been defined long before environment setup.
- D (false alarms unlikely in real world) is a valid long-term risk of dedicated test interfaces (they can expose non-production code paths), but it applies during test execution, not during the setup verification phase the question specifies.
Memory tip: "New pipes, new leaks." Dedicated test interfaces are brand-new additions to the SUT - when verifying setup, your first and most specific worry is always whether the TAS can reach them at all. Everything else is secondary.
Topics
Community Discussion
No community discussion yet for this question.