Test Automation
Test Automation assesses whether you can design and sustain automation that pays for itself. The exam tests strategy, the test automation pyramid, TDD/ATDD, framework design and continuous integration, not tool-specific commands.
Core rules and concepts
- Automation is a development activity with a total cost of ownership: build, maintenance, infrastructure and analysis time.
- The test automation pyramid recommends many unit-level checks, fewer service/API checks and very few UI checks, because speed and stability fall as you move up.
- TDD follows red-green-refactor: write a failing test, make it pass minimally, then refactor. ATDD adds an outer acceptance loop.
- Common framework designs include data-driven, keyword-driven, hybrid and page-object or screenplay. Each trades initial cost for maintainability.
- Continuous integration runs the build and fast checks on every commit; slower checks run later in the pipeline.
- Choose automation candidates by frequency, risk, stability and data availability; keep test data and environments under configuration control.
Worked example
A login check runs 200 times per release and takes 10 minutes manually. Building an automated check costs three days; maintenance is about two hours per release. Reasoning: high frequency, deterministic behaviour and stable data make it a strong candidate, and payback arrives within a few releases. A one-off regulatory report with changing formats is a poor candidate and stays manual.
Traps
- Automating everything regardless of return on investment.
- Relying on record-and-playback for large suites.
- Ignoring maintenance and flaky tests.
- Reporting automation progress by test count rather than by risk covered.