CTAL-TAE · Question #119
Consider A TAS for testing a desktop application via its GUI. All the test cases of the automated test suite contain the same identical sequences of steps at the beginning (to create the necessary…
The correct answer is A. Implementing keywords with higher level of granularity. Option A is correct because the scenario describes identical sequences repeated across all test cases - both setup and teardown - which is precisely the problem that high-granularity keywords solve. In a keyword-driven TAS, these repeated sequences should be encapsulated into…
Question
Consider A TAS for testing a desktop application via its GUI. All the test cases of the automated test suite contain the same identical sequences of steps at the beginning (to create the necessary objects when doing a preliminary configuration of the test environment and at the end (to remove everything created 璼pecifically for the test itself during the preliminary configuration of the test environment). All automated test cases use the same set of assertion functions from a shared library, for verifying the values in the GUI fields ( e.g text boxes). What is the BEST recommendation for improving the TAS?
Options
- AImplementing keywords with higher level of granularity
- BImproving the architecture of the application in order to improve its testability
- CAdopting a set of standard verification methods for use by all automated tests
- DImplementing standard setup and teardown functions at test case level
How the community answered
(24 responses)- A63% (15)
- B4% (1)
- C21% (5)
- D13% (3)
Explanation
Option A is correct because the scenario describes identical sequences repeated across all test cases - both setup and teardown - which is precisely the problem that high-granularity keywords solve. In a keyword-driven TAS, these repeated sequences should be encapsulated into composite, reusable keywords (e.g., InitializeEnvironment, CleanupEnvironment) that abstract away the low-level steps, making tests shorter, more readable, and centrally maintainable.
Why the distractors are wrong:
- C is already implemented - the scenario explicitly states all tests share assertion functions from a shared library, so this is not a new recommendation.
- D is too narrow: setup/teardown functions at test case level address only the begin/end sequences, whereas high-level keywords (A) provide broader reusability across the whole TAS, not just lifecycle hooks.
- B is out of scope - the question asks how to improve the TAS (the test automation infrastructure), not the application under test; changing the application's architecture is irrelevant here.
Memory tip: When you see "identical steps repeated in every test case," think keyword abstraction - bundle repeated sequences into named, reusable keywords at a higher level of granularity. If the shared library already exists (like the assertion functions here), don't pick "add a shared library" again.
Topics
Community Discussion
No community discussion yet for this question.