Test Automation Introduction

What is test automation?#

Test automation uses code to execute tests, compare actual results with expected results, and report pass or fail — without a person clicking through the application. Automated tests can run on every commit, overnight, or on dozens of browsers at once.

Automation doesn't replace testers. It replaces the repetitive part of testing, so people can spend their time on exploratory testing, new features and risk analysis.

What to automate — and what not to#

A useful rule: automate what you'll run often and what must never break.

The automation pyramid#

Automate at the lowest level that can catch the bug:

            /\          UI / end-to-end (Selenium, Cypress, Playwright)
           /  \         — few: slow, more fragile, test whole journeys
          /----\
         /      \       API / integration (Postman, REST clients, Playwright request)
        /--------\      — more: fast, stable, test business rules
       /          \
      /------------\    Unit (pytest, JUnit, Jest)
                        — most: milliseconds each, written with the code

Checking that a discount is calculated correctly is an API or unit test — not a UI test that clicks through checkout ten times with different codes. Use the UI layer for the handful of journeys that prove the whole system works together.

Choosing a UI automation tool#

For APIs, Postman (with Newman) or the same language's HTTP client works well.

Pick the tool your team can maintain: matching the developers' language means they can help fix and extend tests.

Anatomy of an automation framework#

A maintainable framework usually has:

• Test runner — pytest, JUnit, Jest, Playwright Test.
• Page objects / helpers — one place for selectors and page actions (Page Object Model).
• Test data management — fixtures, factories, CSV/JSON data, API calls to set up state.
• Configuration — base URL, credentials and browser per environment.
• Reporting — HTML or Allure reports, screenshots and videos on failure.
• CI integration — tests run automatically on every pull request (CI Integration & Flaky Tests).

Calculating automation ROI#

Automation has an upfront cost and pays back every time the tests run.

# automation_roi.py — run with: python automation_roi.py
manual_minutes_per_run = 6 * 60     # 6 hours of manual regression
automate_hours = 80                 # build the suite
maintain_hours_per_month = 6
runs_per_month = 8                  # twice a week

saved_per_month = runs_per_month * manual_minutes_per_run / 60 - maintain_hours_per_month
print(f"Hours saved per month: {saved_per_month:.0f}")
print(f"Break-even after:      {automate_hours / saved_per_month:.1f} months")

Hours saved per month: 42
Break-even after:      1.9 months

The real gains are bigger than hours: faster feedback, releases whenever you want, and no human fatigue on run number fifty.

Common automation mistakes#

• Automating everything through the UI (an inverted pyramid).
• Copy-pasting selectors into every test instead of using page objects.
• Fixed sleeps (time.sleep(5)) instead of proper waits — slow and flaky.
• Tests that depend on each other's data or order.
• Ignoring flaky tests until nobody trusts the suite.

The next lessons show how to avoid each one, starting with Selenium WebDriver basics.