CTAL-TAE · Question #100
Consider a TAS that is going to be deployed for the first time. The TAS requires share resources and run it its own test environment. The infrastructure for the TAS has been created along with…
The correct answer is B. Testing the TAS for its ability to be implemented in other target test environments. Option B is correct because portability testing - validating the TAS's ability to run in other target environments - is the most effective way to uncover hidden dependencies on shared resources before the risky deployment occurs. By exercising the TAS in alternative…
Question
Consider a TAS that is going to be deployed for the first time. The TAS requires share resources and run it its own test environment. The infrastructure for the TAS has been created along with maintenance procedures. It is very unlikely the TAS will be required to work in other target Environments. There is a high-risk that when the TAS is deployed in its own test environment, a number of existing application will no longer work because of conflicts with the existing shared resources. Which of the following activities would you expect to be MOST effective at mitigating the risk associated with the first deployment of the TAS?
Options
- ATesting the TAS for application compatibility issues in the target environment
- BTesting the TAS for its ability to be implemented in other target test environments.
- CTesting the TAS for regressions due to optimization that fix non-functional issues.
- DTesting the TAS for ITS ability to run a shared test environment
How the community answered
(39 responses)- A5% (2)
- B64% (25)
- C10% (4)
- D21% (8)
Explanation
Option B is correct because portability testing - validating the TAS's ability to run in other target environments - is the most effective way to uncover hidden dependencies on shared resources before the risky deployment occurs. By exercising the TAS in alternative environments, testers can identify which shared resources it relies on and anticipate conflicts, without triggering those conflicts in the actual target environment where live applications could break.
Why the distractors are wrong:
- A tests compatibility in the target environment itself - this doesn't mitigate the risk, it executes it. You'd be deploying to the exact environment where breakage is expected.
- C tests for regressions from non-functional optimizations, which is unrelated to the specific risk of shared-resource conflicts during first deployment.
- D tests whether the TAS can run in a shared environment - but this evaluates the TAS's own functionality, not whether it will conflict with other existing applications sharing those resources.
Memory tip: The phrase "very unlikely to work in other environments" is a deliberate distractor. The key insight is test elsewhere first - portability testing in safer environments is a proactive risk-reduction strategy, not a portability goal. When a deployment is high-risk, find the landmine in a field that doesn't matter before walking through the one that does.
Topics
Community Discussion
No community discussion yet for this question.