Consider a TAS that uses a keyword-driven framework. The SUT is a web application and there is a large set of keywords available for writing the automated tests that relate to highly specific user…

Question

Options

• AChanging the scripting approach to data-driven scripting
• BImplementing keywords with a higher level of granularity
• CChanging the wait mechanism to explicit hard-coded waits
• DEstablishing an error recovery process for TAS and SUT

• A
  12% (8)
• B
  59% (39)
• C
  6% (4)
• D
  23% (15)

Explanation

Option B is correct because the static analysis tool is flagging repeated sequences of identical keywords - a direct symptom of keywords being too fine-grained (e.g., individual GUI clicks and field inputs). Raising the level of granularity means combining these low-level actions into composite, higher-level keywords (like Login_As_User instead of three separate click/type keywords), which eliminates redundant sequences, improves test readability, and decouples tests from GUI implementation details.

Why the distractors are wrong:

• A (Data-driven): Addresses test data variation, not structural keyword repetition - solving a different problem entirely.
• C (Hard-coded waits): This would be a regression; the current synchronous sampling with timeout is already a more robust approach than hard-coded sleeps, which are brittle and waste time.
• D (Error recovery): Handles test execution failures gracefully, but doesn't address the root cause of low-level keyword duplication identified by static analysis.

Memory tip: Think of keyword granularity like refactoring code - if your static analyzer keeps flagging copy-pasted blocks, you don't switch languages (A) or add try/catch (D); you extract them into a reusable function. Higher-level keywords are that extraction.

No community discussion yet for this question.