Test Automation Fundamentals
Test automation is the trigger, instructions, check and report-back shape from Automation in General, pointed at software. In practice, it is a manual test case written in a form a machine can follow.
You already know how to test: set things up, do the steps, check the result, write down pass or fail. An automated test does exactly the same four things. The tester decides what to check; the machine does the repeating. Automation does not replace thinking. It replaces the tenth, twentieth and hundredth time you click through the same flow before a release.
A test case and an automated test have the same parts
Take one manual test case for ordering a pizza and line it up with its automated version. Every part maps across.
| Part | In the manual test case | In the automated test |
|---|---|---|
| Precondition | "Log in as a normal customer. Cart is empty." | Setup: the script logs in with a test account and clears the cart before it starts |
| Test data | "Use customer ali@test.com, pizza Margherita, size Large" | Data: the same values, kept in a file or table outside the steps so they are easy to change |
| Steps | "Click Menu, choose Margherita, pick Large, click Order" | Actions: the script finds each button and clicks it, the same way you do |
| Expected result | "Confirmation page shows an order number" | Assertion: a check that the order number is on the page. If not, the test fails |
| Actual result | You write Pass or Fail and take a screenshot | Report: the tool records pass or fail, with screenshots and a step-by-step record when it fails |
| Clean up | "Cancel the order afterwards" | Teardown: the script removes what it created, so the next run starts clean |
If you can write a clear manual test case, you already understand most of automation. The rest is teaching the machine how to find things on the screen and how long to wait for them.
The moving parts
Every test automation tool, whatever its name, has the same few parts.
| Part | Plain meaning | Manual-testing equivalent |
|---|---|---|
| Test script | The steps and checks, written as code | The test case document |
| Test runner | Picks which tests to run, runs them, collects results | The execution plan for today |
| Driver | Controls the browser, phone or API on the script's behalf | Your hands on the mouse and keyboard |
| Locator | How the script finds an element: "the button labelled Order" | Your eyes looking for the button |
| Assertion | A yes/no check of what is on screen or in the response | Comparing actual to expected |
| Report | The run's results, screenshots and step record | The test execution log you fill in |
Tools differ in the language they use and how good their driver is, but the parts are the same. Learn the parts once and every tool (Playwright, Selenium, Cypress, Postman, SoapUI) becomes easier to pick up.
Where the tests run
Automated tests pay off when nobody has to remember to start them. Each time a developer changes the code, a pipeline builds the app, deploys it to a test environment and runs the tests on its own. The team gets a green or red answer within minutes, while the change is still fresh in the developer's head.
What test automation cannot do
- It only checks what you told it to check. If a test does not assert that the price is correct, a wrong price passes.
- It does not notice odd things. A human sees a misaligned button or a confusing message. A script only sees what its assertions look at.
- It does not decide what matters. Choosing which flows to automate and what "correct" means is still the tester's job.
- It needs upkeep. When the screen changes, the script must change too, the same way a manual test case goes out of date.
Where test automation fits
Manual and exploratory testing find the things nobody has written down yet. Automation checks the things we already know the answer to. A good team needs both. Automation frees the tester from repeating the same regression clicks every release, so there is time for the exploratory work a script cannot do.
| Manual / exploratory | Automated | |
|---|---|---|
| Good at | New features, usability, odd edge cases, "does this feel right" | Known flows that must keep working, run again and again |
| Cost | Same effort every run | High effort once, low per run, plus upkeep when the screen changes |
| Speed | Minutes to hours per flow | Seconds per flow, can run in parallel |
| Finds | New bugs | Regressions (something that used to work and now does not) |
A flow is worth automating when it is run often, stable (the screen has settled), critical to the business, and has a clear pass condition. These are the same rules as when automation is worth it, applied to test cases.
Test levels
Automated tests live at three levels. The lower the level, the cheaper and faster the test. Push each check as low as it can go, and keep UI tests for what only a real browser can prove.
| Level | What it checks | Speed | Who usually writes it | Example tools | Example check |
|---|---|---|---|---|---|
| UI / end-to-end (fewest) | The whole stack through a real browser | Seconds per test | Tester | Playwright, Selenium | A user logs in, orders a pizza and sees the order number |
| API / integration | One endpoint or service | Milliseconds to seconds | Developer or tester | Postman, SoapUI, Playwright request | POST /orders rejects an empty cart with 400 |
| Unit (most) | One function or component | Milliseconds | Developer | JUnit, Jest, pytest | Discount calculation returns 10% for gold members |
This shape is often drawn as a pyramid: many unit tests at the base, fewer API tests in the middle, a small number of UI tests at the top. The API level is often the cheapest win for a tester: business rules checked without a browser.
Suite types at a glance
The same tests are grouped into suites by when they run and what question they answer. A suite is a tag or folder, not a separate project.
| Suite | Question it answers | Size | When it runs |
|---|---|---|---|
| Smoke | Is the build alive enough to test at all? | 5 to 10 tests, under 5 minutes | After every deploy |
| Sanity | Does the area that just changed work? | A handful around the change | After a fix or small change |
| Regression | Did anything that used to work break? | The full trusted suite | On every merge request or nightly |
| End-to-end | Does a full business journey work across systems? | Few, long | Nightly or before release |
| Data-driven | Does one flow work for many inputs? | One test × N data rows | With regression |
| Cross-browser | Does it work on Chrome, Firefox and Safari? | Regression × browsers | Nightly or before release |
| Visual | Does the screen still look the same? | Screenshot comparisons | Optional, once layouts settle |
Commonly confused pairs
| Pair | The difference |
|---|---|
| Smoke vs sanity | Smoke is wide and shallow over the whole build. Sanity is narrow and a little deeper, only around what changed. |
| Regression vs retest | Retest checks that one fixed defect is really fixed. Regression checks the fix did not break anything else. |
| UI test vs end-to-end | A UI test drives the browser, but may stub the backend. End-to-end goes through every real system in the chain. |
| Failing vs flaky | A failing test fails every time, so something is wrong. A flaky test passes and fails on the same code, so the test or environment is wrong. |
| Recording vs script | A recording is a first draft. It becomes a script after you fix locators, add assertions and pull out test data. |
| Test case vs automated test | The manual test case says what to check. The automated test is code that checks it. Keep the link (case ID in the test name) so coverage is traceable. |
Tips
- Write the manual test case first. If you cannot write the steps and the expected result clearly in plain words, the script will not be clear either.
- One flow, one test, one pass condition. A long test that chains login, search, edit and delete tells you nothing about which part broke.
- Learn the parts, not the tool. When you move from Playwright to SoapUI or Selenium, ask "where is the runner, the locator, the assertion, the report?" and you are halfway there.