There are two ways to check a program. The first is by hand: a person walks through the scenario themselves, clicks, looks, compares. The second is with automation: a programmer writes separate code (a test) that walks through the scenario for the person and reports on its own whether everything is fine.

Beginners are often scared that "manual is dying, everything's being automated". That's a myth. Manual and automated testing solve different tasks, and one doesn't replace the other. Let's figure out where each is strong and why it's worth starting exactly with manual.

Manual testing: a person checks it themselves

The tester opens the application and walks through a scenario like a live user: registers, adds an item to the cart, pays, looks at the result.

Strengths:

  • Flexibility. Noticed something odd — immediately turned aside and checked it. No need to program anything in advance.
  • A live eye. A person sees that the button has shifted unattractively, the text is cut off, the error color is unreadable. An automated test doesn't "feel" this.
  • A quick start. To check a new feature once, you don't need to write code — you open it and check.

Weaknesses: it's slow and tiring when the same thing has to be repeated many times. Running 500 checks by hand after every change is unrealistic. And a person gets tired, which means they make mistakes and miss things.

Automated testing: code checks for you

Here the scenario is described in code once, and then it can be run as many times as you like — after every change, or overnight.

Strengths:

  • Speed and repeatability. Thousands of checks in minutes, equally precisely every time.
  • Doesn't tire. The machine doesn't care whether it's the first run or the thousandth.
  • Good for regression. Ideal for checking that the old stuff still works after new changes.

Weaknesses: it's expensive to create and maintain. An automated test is also code that has to be written, fixed when the interface changes, and which itself can have bugs. An automated test checks exactly what was put into it, and won't notice that "this actually looks ugly". Writing an automated test for a one-off check is a waste of time.

What's checked with what in practice

A rough but working rule:

  • Automate what repeats often and rarely changes: regression of the main scenarios, API checks, calculations, processing many variants of data.
  • Check by hand the new, the complex, and the "by eye": a just-built feature, interface usability, rare scenarios, and also exploratory testing — when you roam around the product without a strict plan looking for the unexpected.

Exploratory testing is an important thing that automation can't do in principle. It's when the tester explores the product, inventing checks on the fly, drawing on experience and curiosity. That's exactly how the most interesting bugs are found.

Why it's worth starting with manual

Automation is, in essence, programming. To write good automated tests, you first need to understand testing itself: what to check, what kinds of scenarios exist, where bugs hide, how to assess a problem's importance. All of this comes from manual testing.

A person who rushed into automation without learning to test writes automated tests that check the wrong thing in the wrong place. That's why almost everyone enters the profession through manual testing, and moves to automation deliberately — once it's clear what exactly and why to automate. On this transition — see the article where to grow next.

Where this applies

On a real project these two approaches live together: some checks are automated and run on every change, while the tester checks the new by hand and explores the product. Understanding what to check with what helps you not waste effort — not running by hand what should have been automated long ago, and not automating one-off work.

Where beginners stumble:

  • They think automation will replace manual and that "manual testers aren't needed". In reality both are needed.
  • They rush to automate without learning to test. The result is automated tests that check nonsense.
  • They try to check by hand what should have been automated — for example, the same long regression after every build. This wears you out and leads to misses.

What to learn next. See how the development and testing lifecycle works, and then move on to the heart of manual work — test levels and types of testing.