CTAL-TAE · Question #101
Consider a TAS deployed into production. The SUT is a web application and the test suite consists of a set of automated regression tests developed via GUI. A keyword-driven framework has been…
The correct answer is A. The keyword-driven framework is not suitable, it would be better to adopt a structured-scripting. Option A is correct because keyword-driven frameworks deliver their reusability and low-maintenance benefits only when built on stable, meaningful identifiers - but this TAS uses fragile low-level locators (coordinates, tab indexes, class indexes) that will almost certainly…
Question
Consider a TAS deployed into production. The SUT is a web application and the test suite consists of a set of automated regression tests developed via GUI. A keyword-driven framework has been adopted for automating the regression tests. The tests are based on identification at low-levels of the web page components (e.g class indexes, tab sequence indexes and coordinates) in the next planned release the SUT will be subject to significant corrective maintenance (bug-fixes) and evolution (new features) Maintenance costs to update the test scripts should be as low as possible and the scripts must be highly reusable. Which of the following statements is most likely to be TRUE?
Options
- AThe keyword-driven framework is not suitable, it would be better to adopt a structured-scripting
- BFalse positive errors are likely to occur when running the automated tests on the new releases
- CThe total execution time of the automated regression test suite will decrease for each planned
- DThe keyword-driven framework introduces a level abstraction that is too high and makes it difficult
How the community answered
(28 responses)- A64% (18)
- B4% (1)
- C21% (6)
- D11% (3)
Explanation
Option A is correct because keyword-driven frameworks deliver their reusability and low-maintenance benefits only when built on stable, meaningful identifiers - but this TAS uses fragile low-level locators (coordinates, tab indexes, class indexes) that will almost certainly break during significant UI changes from bug-fixes and new features. The keyword abstraction layer provides no protective value when its underlying component identification is this brittle, making the framework complexity unjustified; structured scripting with modular functions would offer equivalent reuse without the overhead of a keyword infrastructure that cannot fulfill its promise.
Why the distractors are wrong:
- B - While test failures will occur due to broken locators, those are "false positives" (test fails but app is fine) not a distinguishing feature of framework choice; A addresses the root cause more precisely.
- C - Execution time does not decrease as the SUT grows; adding features typically means more tests and longer suite runs, not fewer.
- D - The abstraction is not "too high" - the keyword-driven level of abstraction is generally appropriate; the real flaw is that the locator strategy is too low-level, which is a separate concern.
Memory tip: Think "Keywords need Anchors" - a keyword-driven framework is only as stable as the identifiers beneath it. If those identifiers are positional or index-based (coordinates, tab order), no amount of abstraction saves you from UI-change breakage.
Topics
Community Discussion
No community discussion yet for this question.