Test Automation
Test automation is the practice of using software to run tests against an application automatically instead of a person clicking through it by hand. It lets teams re-check existing behavior quickly and repeatedly every time code changes, catching regressions that manual testing would be too slow to find every time.
itSoftware engineering | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Intro
Test Automation
Software changes constantly. Every change can break something that used to work. Checking that by hand, every time, does not scale past a small codebase. Test automation is the practice of encoding those checks as code, so a machine re-runs them on every change instead of a person re-clicking through the application.
Automation does not replace testing as a discipline. It replaces the repetitive execution of tests that already have a known, checkable outcome. Exploratory testing, usability judgment, and deciding what to test in the first place stay human work. Test automation is how you make the checks you already know you want cheap enough to run constantly.
Why automate
A regression test re-run by a person costs the same effort the tenth time as the first. An automated test costs effort once, to write, and then runs at near-zero marginal cost. That shift changes what becomes economically possible: running the full check suite on every commit, not once before a release.
The Certified Tester Advanced Level Test Automation Engineering syllabus frames the case directly: automation buys speed, repeatability, and coverage that scales with the size of a test suite, at the cost of an upfront investment to build and an ongoing cost to maintain the automation itself. Automation is not free. Scripts rot as the application changes; a suite nobody maintains becomes a suite nobody trusts. The decision to automate a given check is a cost trade-off, not a default.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://www.gasq.org/files/content/iqbohs/images/logo/ISTQB_CTAL-TAE_Syllabus_v2.0.pdf
Supports
- Definition of test automation and its role relative to manual testing
- Cost/benefit trade-off of automation (upfront and ongoing maintenance cost)
- Kinds of testing that resist automation (usability, exploratory)
- Generic test automation architecture layers (definition, execution, adaptation, data/configuration, reporting)
- https://martinfowler.com/bliki/TestPyramid.html
Supports
- The test pyramid shape (many unit tests, fewer service tests, very few UI/end-to-end tests)
- Trade-off of speed/reliability versus realism across layers
- The ice-cream cone anti-pattern
- https://martinfowler.com/articles/practical-test-pyramid.html
Supports
- Practical application of pyramid layering
- Guidance on test doubles versus real collaborators
- Sequencing a suite for fast feedback in a pipeline
- https://testing.googleblog.com/2010/12/test-sizes.html
Supports
- Definition of small tests (one thread, one process, one machine, no sleep/network/disk)
- Sizing tests by measurable execution scope rather than unit/integration/system labels
- https://abseil.io/resources/swe-book/html/ch14.html
Supports
- Small test constraints (one thread, one process, one machine)
- Large tests' default timeout of 15 minutes to 1 hour, with some running longer
- Preference for the majority of tests being unit-level (pyramid shape) at scale
- https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/
Supports
- Definition of a page object as an interface to a page or component of the application under test
- Rule that tests, not page objects, make assertions (except verifying the correct page loaded)
- Rule that methods return page objects to model user journeys
- Maintenance benefit of a single place to update when the UI changes
- https://playwright.dev/docs/best-practices
Supports
- Preference for role/label/text locators over CSS selectors or DOM structure
- Per-test isolation (own cookies, storage, session)
- Use of web-first, retrying assertions instead of fixed waits/timeouts
- Use of trace-on-first-retry for CI debugging
- https://testing.googleblog.com/2016/05/flaky-tests-at-google-and-how-we.html
Supports
- Definition of a flaky test (passes/fails without a code change)
- Causes of flakiness (shared state, timing, external dependencies)
- Mitigations: quarantining chronically flaky tests, rerunning suspected-flaky tests, tracking flakiness over time
- https://martinfowler.com/articles/continuousIntegration.html
Supports
- Definition of a self-testing build
- Rule that any failing test fails the build, not just a majority
- Fixing a broken build as the immediate priority
- Two-stage pipeline pattern (fast commit build with test doubles, slower broader stage)
- https://github.com/atinfo/awesome-test-automation/blob/master/javascript-test-automation.md
Supports
- Curated selection of browser/E2E automation frameworks for 09-awesome-links.yaml (Selenium, Playwright, Cypress, WebdriverIO, Puppeteer)
- https://github.com/atinfo/awesome-test-automation/blob/master/general-purpose-test-automation-tools.md
Supports
- Curated selection of general-purpose automation tools for 09-awesome-links.yaml (Robot Framework, Postman, Apache JMeter, Swagger, SoapUI)
