Module 04

Automation testing — let machines do the repetition

Automation testing uses code and tools to run checks a human would otherwise repeat by hand — faster, at scale, on every single build. It doesn't replace manual testing; it frees it.

What is automation testing?

Automation testing means writing scripts (or configuring tools) that execute test steps, compare actual results to expected ones, and report pass/fail — with no human at the keyboard. Once written, a suite can run on every commit, overnight, or across a hundred browser/device combinations at once.

Example A Selenium script logs in with 50 different account
types, verifies each dashboard loads, and finishes in
4 minutes. Manually, that's half a day — every release.

What to automate (and what not to)

  • Automate: repetitive regression suites, data-driven checks, API contracts, performance/load, anything run on every build.
  • Keep manual: exploratory testing, visual/usability judgement, one-off checks, features still changing daily.

Popular tools you'll hear about: Selenium and Playwright (web UI), Appium (mobile), Postman (API), JUnit/PyTest (unit), JMeter (performance).

Illustration of a robot arm running test scripts across multiple screens with green check marks

Types of automation testing — with examples

Unit testing

Automated checks of the smallest code pieces — single functions or classes — written by developers and run in seconds.

Exampleassert calculateDiscount(100, "SAVE10") === 90 — a JUnit test verifying one pricing function.

API testing

Testing the service layer directly — requests in, responses out — without touching the UI. Fast and very stable.

ExamplePostman suite: POST /orders with an invalid card → expect HTTP 402 and error code "card_declined".

UI / functional testing

Scripts that drive the real interface — clicking, typing, asserting what appears — across browsers and devices.

ExamplePlaywright: fill the signup form, submit, assert the welcome banner shows the new username in Chrome, Firefox and Safari.

Automated regression

The whole existing suite re-run on every build in CI/CD, catching anything a change silently broke.

ExampleEvery merge triggers 800 tests in the pipeline; a failed checkout test blocks the deploy automatically.

Performance / load testing

Simulating hundreds or thousands of users to measure speed, stability and breaking points — impossible manually.

ExampleJMeter ramps 5,000 virtual users onto checkout; response time passes 2s at 3,200 users — that's the number the team fixes.

Automated smoke suite

A small, fast script pack that gates every new build: core flows must pass before deeper testing starts.

ExampleTen tests — login, search, add-to-cart, pay — run in 3 minutes after every deploy to staging.

Manual vs automation — teammates, not rivals

AspectManual testingAutomation testing
Best atJudgement, exploration, usabilityRepetition, scale, speed
Upfront costLow — start immediatelyHigh — scripts and frameworks take time
Cost over timeGrows with every repeated cycleDrops — the suite pays for itself
ReliabilityHuman error possibleConsistent, but only as good as the script
Typical useNew features, UX review, UATRegression, APIs, performance, CI/CD gates

Real teams use both: automation guards everything that already works, so humans are free to explore what's new. Next, learn the three perspectives every test is designed from — black, white and grey box.

Back: Manual Testing Next: Black, White & Grey Box