← back to the section

You already know the difference between manual and automated testing. This article is the next step: how automation is built from the inside, when it pays off and when it brings nothing but costs, and what a manual tester can do for it right now without writing a single line of code.

two questions about a check — and it lands in its quadrant maintenance cost expensive to fix cheap to fix rarely often how often it runs payment regressionfirst autotest goes here order form in the UIstabilize it first quarterly reportthe gain is small one-off migrationcheck it by hand

Two axes: how often the check is run, and how much it costs to fix after every change. The answers to those two questions place the check in a quadrant, and the quadrant is the decision. Bottom right is what runs on every build and almost never gets reworked: there the test development pays for itself around the tenth-to-fifteenth run. Top left is one-off and fragile: by hand it is faster and cheaper.

Economics: automation is an investment

The main thing to grasp: automation is not a magic button but a project inside the project, with its own requirements, code, and plans. In manual testing most of the time goes into executing checks; in automated testing the picture flips: a long development-and-debugging phase — and then fast runs.

The payback logic is simple: developing and maintaining autotests is repaid by the savings on every run — so the benefit depends on three things:

  • How much time one run saves — the difference between manual and automated execution of the same checks.
  • How many times the checks will be repeated. The typical picture: automation pays for itself not on the first run but around the tenth-to-fifteenth build — and only after that starts bringing profit.
  • What maintenance costs. The most underestimated item: when requirements or the interface change noticeably, tests have to be reworked — sometimes from scratch.

That's why automation is strong where checks repeat often and change rarely: regression, smoke runs on every build, checks without a UI (APIs, console utilities), sweeping large data sets and configurations, load. And it's weak where thinking is required or where there will be no repetition: inventing checks, usability assessment, one-off checks, a product with unstable requirements. Two field aphorisms: "automating chaos gives you automated chaos" — if the manual process isn't in order, there's nothing to automate; and "better to test at least something by hand than nothing in an automated way" — under deadline pressure automation won't save you, at first it only consumes time.

The ladder of approaches

Automation technologies form a ladder — each rung solves the previous one's problem:

  • One-off solutions. A separate script for a separate task. Fast and simple, but "artisanal": nearly impossible to reuse, only the author understands it.
  • Record & Playback. A tool records the tester's actions and can replay them. Minutes to learn — which is why beginners often start here. But the recorded test is linear (no conditions, no loops), stuffed with concrete values, and fragile. A test skeleton — yes; a finished test — no.
  • Data-driven testing (DDT). The data moves out of the test code — into a table or file. One test runs against hundreds of input sets; adding a check = adding a row to the table.
  • Keyword-driven testing (KDT). Not only data but the actions themselves move outside: "open," "fill," "verify." Someone without programming skills can fill in such tables — the turning point at which non-technical specialists join automation.
  • Frameworks. Ready-made construction kits combining the best of the previous approaches: the xUnit family for unit tests, Selenium/Playwright for the web. Powerful and flexible, but requires programming and learning time.
  • Behaviour-driven development (BDD). Checks are written as business scenarios using the given — when — then formula: "Given the user is logged in; when they add an item to the cart; then the cart counter increases by one." Everyone can read and discuss such a record — customer, analyst, tester — and tools like Cucumber turn it into executable tests. The price: high-level scenarios skip low-level details, so they complement classic tests rather than replace them.

The rung with the data outside is easy to see: the rule "points cover no more than half of the total" is checked once, and there are as many input sets as rows in the table.

live example

cases = [(1000, 300, 300), (1000, 800, 500), (999, 400, 400), (500, 0, 0)]
for total, balance, expected in cases:
    paid = min(balance, total // 2)
    print(total, balance, paid, "OK" if paid == expected else "FAIL")
Run

Running examples is part of paid access. There the same code runs inside the article: editor, run and check next to the paragraph. Three free days →

Cases for automation: what you can do

What gets automated is most often ordinary, manually written test cases. And this is where the manual tester directly influences success:

  • A crystal-clear expected result. "The standard search page loads" is clear to a human, not to a machine. Needed: "title = 'Search page', the input field and the 'Go!' button are present." Correctness criteria must be concrete and checkable.
  • Waiting for a state, not for time. Not "wait 5 seconds and click" but "wait until the list becomes enabled." Timing-dependent tests fail on a perfectly working application — and erode trust in the whole automation effort.
  • Case independence — as in manual suites, only stricter: you cannot assume which tests run before and after yours.
  • No binding to a tool or platform. "Click and wait for the page to load," not a specific tool's commands inside the case steps.

And the most dangerous thing in automation is false-positive tests: the test is green while the application is broken. The classics — checking the wrong property (checkbox "enabled" instead of "checked") or accidentally changing a value instead of verifying it. Such a test is worse than no test: it hides defects while giving the team false confidence.

Where this applies

Even in a "manual" role you touch automation daily: you read run reports, triage failed tests (a bug, or an outdated test?), and write the cases that later get automated.

Where beginners stumble:

  • They measure automation by test count rather than by what the tests catch. A hundred false-positive tests is a minus, not a plus.
  • They believe Record & Playback is what automation is. It's the toddler stage: recordings must be turned into maintainable code.
  • They propose automating everything without asking "how many times will this repeat?" A one-off manual check is faster and cheaper.

In short

  • Automation is a project inside the project: the benefit arrives with repeated runs.
  • Three numbers decide it: saving per run, number of repetitions, cost of maintenance — the last is underestimated.
  • What is automated first repeats often and changes rarely: regression, smoke runs, API checks.
  • Each rung fixes the fragility of the previous one: script → recording → data outside → keywords → frameworks → given-when-then.
  • A case is fit for automation when the expected result is machine-checkable and the waiting is on a state, not on seconds.
  • A false-positive test is worse than no test: green on a broken application, it hides the defect.