What Is QA Automation — And When Does Your Product Actually Need It?

When I started in software QA, automation was a specialization within a specialization. Today it is expected in almost every product team. But the conversations I have with clients — especially founders and product managers who are new to the QA space — suggest that 'automation' has become a buzzword that obscures more than it reveals. Let me try to be concrete about what it actually is, what it does well, and when you genuinely need it.

What QA Automation Actually Is

QA automation means writing code that simulates user behaviour and checks that your software responds correctly. Instead of a human tester clicking through a login flow to verify it works, a script does it — faster, repeatably, at any hour, without fatigue. The most widely used tool for web application automation right now is Playwright, which I use for most of my client work. It controls a real browser, fills forms, clicks buttons, navigates pages, and asserts that the result matches what you expect.

What It Does Not Do

Automation does not replace human judgement. It does not catch design problems, accessibility issues, confusing user flows, or business logic errors that your tests did not anticipate. Automated tests check what you told them to check — nothing more. A green test suite means your existing scenarios passed; it does not mean your product is good. This is why skilled QA engineers write tests alongside manual exploration, not instead of it.

When You Actually Need It

• You deploy frequently — if you are pushing code daily, manual regression testing becomes the bottleneck that slows your releases.
• You have a stable set of critical user journeys — login, checkout, onboarding, key form submissions — that must work on every release.
• Your product runs across multiple browsers or devices — automation can run the same tests on Chrome, Firefox, Safari, and mobile viewports simultaneously.
• You have a growing team — the larger the team, the more valuable a shared automated regression suite becomes as a safety net.

When You Probably Do Not Need It Yet

• Your product is still in early discovery — if the UI and flows change every week, automated tests become a maintenance burden that costs more than they save.
• You have a very small, stable product with infrequent releases — manual testing may be faster and cheaper.
• You do not yet have the development discipline to keep tests green — broken tests that nobody fixes are worse than no tests.

A Practical Starting Point

For most early-to-mid stage products, the right automation strategy is a small, focused suite covering five to ten critical paths — the things that, if broken, would stop users from doing anything meaningful. Login. Signup. Core action. Checkout if applicable. These run on every deployment and give you a reliable signal without becoming a maintenance project in themselves. From there, you grow the suite as the product stabilises.

The most expensive automation mistake I see is writing hundreds of tests for an unstable product. Start with ten tests that you will actually maintain, not a hundred that you will eventually ignore.