Teams often argue about testing as if it were a choice: automate everything, or test by hand. In practice the question is narrower and more useful. Which checks are the same every time, and which need someone to look and think?
Automate what must never break
Some things have to work on every release: signing in, paying, submitting the main form, loading the pages that bring in most of the traffic. These journeys change rarely and matter enormously, which makes them ideal for automation.
Browser automation tools such as Playwright or Cypress can walk these journeys in a few minutes on every change, in several browsers at once. When a developer fixes one thing and quietly breaks another, the test fails before the change reaches anyone.
Keep the suite small enough to trust
A test suite that takes an hour to run gets skipped. One that fails at random gets ignored. Both end in the same place: tests that exist but no longer protect anything.
We would rather have twenty reliable tests covering the critical paths than five hundred brittle ones covering everything. A flaky test gets fixed or removed the week it appears. Leaving it in trains the team to ignore red.
Let screenshots catch what assertions miss
A button can exist, be clickable and pass every functional test while sitting on top of the headline. Visual regression testing takes screenshots of key pages on each change and highlights the pixels that moved.
It is noisy at first and needs sensible thresholds, but for design-heavy sites it catches the class of bug that code checks cannot see: a font that failed to load, a spacing change that rippled across forty pages.
Keep people for the things that need taste
No script can tell you that a new flow is confusing, that an error message sounds rude, or that the page technically loads but feels slow. Exploratory testing, where a person uses the product with no script and tries to make sense of it, still finds the most important problems.
The best moment for it is when something is new. Once a feature settles, its core path can move into the automated suite and human attention can move on.
Run the tests where the work happens
Tests that live on one developer’s machine protect one developer. Wired into the build pipeline, they run on every change and block a release that fails them. That is when automation starts to pay back what it cost to write.
Know when not to automate
For a five-page marketing site that changes twice a year, a careful manual checklist is often the better investment. Automation earns its keep where there is repetition: frequent releases, many contributors, long-lived products. Matching the testing to the product is part of the job.
