Test Automation
Automation is not "record clicks and replay them". It is an engineering discipline: you write code that checks other code, and that code must also stay fast, stable, and readable. A bad autotest costs more than a manual check — it fails intermittently, needs edits on every UI refactor, and eventually gets disabled. A good autotest catches regressions silently for years.
The topic runs from the base of the pyramid (unit tests) to its top (e2e) and on to the infrastructure that keeps a suite fast and repeatable: mocks and fixtures for isolation, Page Object and locators for UI automation, tactics against flaky tests, a measure of the tests' own quality (mutation testing), performance test kinds, and finally CI/CD and Git as the pipeline from commit to production. The key traps are named in each layer. The full map is below.
Topic map
- Unit test — the smallest isolated check of one function with its dependencies mocked, and its place at the base of the pyramid.
- End-to-end test — driving the whole system through the UI like a real user — the highest confidence at the cost of speed and brittleness.
- Good autotest — the FIRST principles: independence, determinism, readability, and a clear failure message.
- Assertions — the checks that fail a test, their kinds, and the soft-versus-hard distinction.
- JUnit setup hooks — the difference between per-test setup and once-per-class setup.
- Mocking — replacing a real dependency with a controlled stand-in for isolation and determinism.
- Locators — ways to find an element (id, CSS, XPath) and the stability-versus-flexibility trade-off.
- Page Object pattern — a page as a class of methods, centralizing locators and removing duplication.
- Appium versus native instruments — one cross-platform codebase versus fast native Espresso and XCUITest.
- Flaky tests — non-deterministic tests, their causes, and the cure through explicit waits and isolation.
- Automation anti-patterns — sleep waits, interdependent tests, and the ice-cream-cone pyramid.
- Mutation testing — deliberate faults in the code that measure the quality of the tests themselves.
- Linter — a static analyzer that catches style and a class of errors before the code runs.
- Parallel and distributed execution — how to speed up a suite and how sharding differs from concurrency.
- Load testing — system behavior under expected and peak load, and its tools.
- Load, stress, and synthetic monitoring — three kinds of performance check with different goals.
- CI/CD — automated build, tests, and delivery of every change from commit to production.
- Git and Git Flow — Git basics and a branching model for a structured path to release.
Common traps
| Mistake | Consequence |
|---|---|
Replacing an explicit wait with Thread.sleep | Timing races, flaky tests, and a slow suite |
| Keeping a flaky test in the suite instead of quarantining it | Trust in the whole run drops; real bugs drown in the noise |
| Building an ice-cream-cone pyramid (too many UI tests) | A slow, brittle, expensive-to-maintain suite |
| Putting raw locators directly in tests | A UI change breaks dozens of tests instead of one page class |
Reaching for XPath where an id or CSS would do | Brittle and slow selectors |
| Sharing mutable state in a per-class hook | Tests depend on each other — isolation breaks |
| Treating a surviving mutant as a sign of good tests | The opposite — it exposes a gap in the checks |
| Confusing load testing with stress testing | Wrong goals and metrics, missed bottlenecks |
| Relying on line coverage as a quality measure | A line executed is not a bug caught in it |
Interview relevance
Automation is asked not for the syntax of a particular framework but to test engineering judgment. A candidate who explains why the pyramid has its shape, how a mock differs from a real dependency, and why a flaky test is sometimes worse than no test immediately gets ahead of someone who can only record a scenario.
Typical checks:
- The test pyramid: why unit tests are many, e2e few, and what the ice-cream-cone anti-pattern is.
- What makes a good autotest — independence, determinism, isolation via mocks and fixtures.
- UI automation: locators, their stability, and the Page Object pattern.
- Handling flaky tests, the difference between load and stress testing, the role of CI/CD.
Common wrong answer: "more UI tests means more reliable" or "a flaky test just needs a rerun". In fact a heavy UI layer makes the suite slow and brittle, and rerunning a flaky test masks the cause and erodes trust in the whole run — such a test must be stabilized or deleted.