You have been asked to automate a set of functional tests at system Test level via the CLI of the SUT for the first release of a software system. The automated tests will be delivered to the learn…

Question

Options

• AData-driven scripting
• BKeyword-driven scripting
• CLinear scripting
• DStructure scripting

• A
  7% (3)
• B
  2% (1)
• C
  11% (5)
• D
  80% (37)

Explanation

Structured scripting is correct because it organizes tests around reusable function/procedure libraries - existing library functions can be called by many tests, so maintenance fixes in one place propagate everywhere (requirement 1), adding new tests is cheap since they reuse existing building blocks (requirement 2), and the library abstraction decouples tests from the specific tool's implementation details (requirement 3).

Linear scripting (C) fails all three requirements: tests are monolithic record-and-playback scripts with no reuse, so every change requires updating each script individually and the scripts are tightly coupled to the tool's recorded actions.

Data-driven scripting (A) helps with adding test cases via external data files but doesn't address tool independence - the scripts themselves remain tool-specific procedural code.

Keyword-driven scripting (B) actually scores best on all three requirements in theory, but it requires significant upfront investment to build and maintain the keyword engine and action word library - making it impractical for a first release hand-off to a maintenance team.

Memory tip: Think "Structured = Shared libraries = Savings" - the shared function library is what buys you cheap maintenance, cheap new tests, and tool independence all at once. Keyword-driven is the "gold standard" but costs gold to build; structured scripting is the pragmatic sweet spot.

No community discussion yet for this question.