Manual vs Automated Testing: What a Small Business Needs.
- Published
- Updated
A small business usually does not have to choose between manual and automated testing: it needs the right sequence. First, manual testing of new and unstable functionality; then automated tests for the few critical flows that repeat before every release: registration, cart, checkout, payment. That combination covers the main risks for moderate money.
Below we break down the difference, what each approach catches, what it costs in orders of magnitude and how to start without unnecessary spending. We work with both approaches, so we will not claim that "automated tests solve everything" or that "manual is enough".
The difference between manual and automated testing
Manual testing is when a person opens the site and walks through scenarios through the user's eyes: adds a product to the cart, places an order, checks on different devices, looks for unusual situations. The result is bugs found, with descriptions, screenshots or video.
Automated testing is when the same scenarios are written as code and a program runs them itself. For example, a Playwright script opens a browser, adds a product, goes through checkout and verifies that the order was created. It runs in a few minutes and can be repeated as many times as you like.
| Criterion | Manual | Automated |
|---|---|---|
| Start | Fast, no preparation | Needs time to write and set up |
| Cost of one run | Hours are paid for every time | Almost zero once created |
| Finding new, unexpected problems | Strong side: a person notices the odd | Weak: it checks only what was built in |
| Repeated scenarios (regression) | Boring and expensive, people make mistakes | Strong side: stable and fast |
| Assessing usability, design, content | Yes | No |
| Cross-browser and devices | Real devices, but slow | Fast in several browsers, but emulation only |
| Maintenance | Not needed | Tests break when the interface changes |
Hence the simple logic: a person looks for the new and odd, a machine protects against the repetition of the old.
What exactly manual testing catches
A person can see what nobody foresaw in the requirements. In practice manual testing reveals:
- Logic errors: a discount applied twice, delivery calculated incorrectly for a particular city.
- Usability problems: a button under the keyboard on mobile, an unclear error message, a form that clears after failed validation.
- Visual defects: overlapping text, stretched images, the wrong font.
- Unusual paths: going "back" after payment, opening the cart in two tabs, changing the quantity to zero.
- Real devices: an old Android phone, Safari on iPhone, a slow network.
A typical manual check is a checklist of dozens of items. We showed what it looks like for a store in the ecommerce testing checklist for pre-launch QA. If you do not know where to start, the best first step is to run a full manual test once and record the result as test cases. They can be automated later.
Manual testing is needed before launching a new site, after big changes, and when adding complex functionality (payment, delivery integration, a customer account). We offer this as website testing from $20 per hour; for a store there is a separate QA audit from UAH 6,000.
What exactly automated testing catches
Automated tests work best where a scenario is stable and repeats often. This is classic regression: after every code change you need to be sure that the old things did not break.
Candidates for automation in a store:
- User registration and login.
- Adding a product to the cart, changing the quantity, removing it.
- Checkout as a guest and as a registered customer.
- Applying a promo code.
- Payment in the payment provider's test mode.
- Catalog search and filters (basic cases).
- Lead and contact forms.
An example of a simple Playwright test:
import { test, expect } from '@playwright/test'
test('a guest can place an order', async ({ page }) => {
await page.goto('/catalog/running-sneakers')
await page.getByRole('button', { name: 'Add to cart' }).click()
await page.goto('/cart')
await page.getByRole('link', { name: 'Checkout' }).click()
await page.getByLabel('Phone').fill('+380501234567')
await page.getByLabel('Name').fill('Test Tester')
await page.getByRole('button', { name: 'Confirm' }).click()
await expect(page.getByText('Thank you for your order')).toBeVisible()
})
Such a test runs in a few seconds and starts automatically on every code update. If someone breaks the "Confirm" button, you find out before the release, not from a buyer's complaint. We have a separate test automation service: Playwright scenarios for key paths and a CI run, priced after an audit.
What automated tests do not do: they do not evaluate design, they do not "feel" usability, and they do not find problems nobody thought of. A test checks only what is built into it.
What it costs: a comparison by order of magnitude
Exact sums depend on the project, so here are benchmarks from our price list and the logic of the costs.
- Manual testing is paid hourly: a QA engineer's rate is $20–25 per hour. The cost repeats with every release but scales flexibly: nothing needs to be built in advance. For a store, a one-off QA audit with a checklist of 150+ items starts from UAH 6,000.
- Automation is a one-time investment in writing and setting up, plus a small amount of maintenance. The first scenarios are ready in about 1–2 weeks. After that, every run is almost free.
The payback rule for a small business looks like this: if you release updates rarely (once every few months), it is cheaper to test manually. If updates come weekly and each requires full regression, automated tests pay off quickly, because they save hours of manual work every time. Do not estimate the break-even point by eye: count how many hours your manual regression takes and multiply by the number of releases per year.
Not sure where to start? We will run a free express check of your site within 48 hours and tell you where manual checking is enough and where it is time for automated tests. Details are on the website testing page.
How to decide what you need
Instead of abstract advice, use a simple decision scheme by situation.
You are launching a new site or store
You need manual testing before launch. This stage has the most new code and the most surprises. Check the full checkout, the mobile version, forms, emails, integrations. Automated tests are premature at this stage: the interface is still changing and the tests would have to be rewritten.
The site works and updates are infrequent
Manual regression before every release against a ready checklist. Pick the 20–30 most important items (checkout, payment, forms) and run them after changes. It is cheap and reliable.
Updates are frequent and checkout errors have already cost orders
Time for automated tests of the critical paths. Start with three to five scenarios that directly bring in money: cart, checkout, payment. We covered the typical bugs in these places in Why Orders Get Lost at Checkout.
Development is continuous and there is a team
Combine both approaches: automated tests in CI on every pull request, manual testing of new features before release. A dedicated QA on the team (part-time or full-time) covers this without hiring a staff employee; details are in the dedicated developer format.
Where to start: a one-month plan
A realistic scenario for a small store with no testing at all:
- Week 1. A manual QA audit: we go through the whole site against the checklist and record bugs with video and priorities. The output is a list of problems and a set of test cases.
- Week 2. Fixing critical and serious bugs. Re-checking the fixes.
- Week 3. We pick the 3–5 most important test cases to automate: the ones that touch money. We write the Playwright scenarios.
- Week 4. We connect the automated test run to the deployment process (CI). We agree on a rule: a release does not go out if the automated tests are red.
After that, manual testing handles new functionality and odd cases, and automated tests guard what has been verified. Monthly regression can be handed to website support from UAH 8,000 per month, where regression before releases is part of the plan.
What it takes for automated tests to really work
Automated tests are not "install and forget". They need three things, without which they quickly turn into a source of noise.
A stable test environment
Tests must run on a separate staging environment with test data, not on the live store. For payment the provider's test mode is used, for Nova Poshta a test key or a stub. This lets you create orders safely and not confuse them with real ones. The database is reset to a known state before a run: otherwise a test that passed yesterday fails today because of someone else's data.
Resilient selectors and scenarios
A test tied to the markup ("the third div in the second block") breaks with any design tweak. It is more reliable to find elements by role and label (the "Confirm" button, the "Phone" field), as in the example above, or by dedicated test attributes. Then you can change a color or spacing without repairing tests.
A CI run and a reaction rule
An automated test only makes sense when it runs automatically and someone reacts to a red result. A typical setup: tests start on every pull request and before a release, and a report with video and a failure trace is available to the whole team. Agree on a simple rule: if the tests are red, the release does not go out until the cause is found. A failure can be a real bug or an outdated test, but it cannot be ignored.
An example payback calculation
Take a hypothetical example to show the logic, not concrete figures for your business. Suppose a full manual regression of key scenarios takes 3 hours, and updates go out once a week. Over a year that is about 50 runs of 3 hours, or 150 hours. At a QA engineer's rate of $20–25 per hour, that is thousands of dollars a year spent only on repeating the same check.
Automating the same scenarios is a one-time cost of 1–2 weeks of work and a small annual maintenance of the tests. An automated run takes minutes, and a person is needed only to analyze failures. In such an example automation pays off within the first or second quarter. If, however, releases are quarterly, four runs a year will not be enough to justify the cost, and it is cheaper to keep manual regression.
An important caveat: this is an approximate model. Real figures depend on the complexity of scenarios, the stability of the interface and the number of integrations. That is why we always start with an estimate on the specific project, not with universal promises.
Typical mistakes of small businesses
- Automating everything at once. A big set of brittle tests is a burden: they fail over trifles and people stop listening to them. Better few but stable.
- Automating an unstable interface. If the design changes weekly, the tests constantly break.
- Relying only on the developer. The code's author tests the way they designed it, not the way a buyer will behave.
- Not recording results. Without a report you cannot compare a release with the previous one or prove that what was fixed is really fixed.
- Thinking testing is an expense, not insurance. One missed bug in payment usually costs more than a month of regular regression. Calculate the exact sum for your store from the number of orders per day and the share that would complete checkout.
If you already see that the problems lie in the code itself, not in the scenarios, you may need a code audit rather than new tests: automated tests do not cure bad architecture, they only expose it faster.
Summary
Manual testing finds the new, the odd and the inconvenient; automated testing protects against the repetition of old mistakes. A small business is usually fine starting with manual testing and a checklist, then automating a few critical scenarios as releases become frequent. The main point is not to choose between the approaches but to split the roles: a person explores, a machine stands guard.
Need a release without nasty surprises? Describe your project in the brief and we will propose a testing scheme: what to check manually, what to automate and what it will cost.
Which is cheaper: manual or automated testing?
Manual is cheaper at the start: you can order it as a one-off and by the hour, and our QA engineer rate is $20–25 per hour. Automated tests require investment in writing and maintenance, but pay off on repeated scenarios. A small business should usually start manual and automate only the stable core.
When does a small business need automated tests?
When the same checks are repeated after every release and manual regression takes too much time. A typical candidate is the purchase path in a store. If the product changes often, automated tests will keep breaking, so automate only stable scenarios. Otherwise you spend money on fixing the tests themselves rather than on business value.
Where should I start testing a site that has never been tested?
With a manual QA audit of critical scenarios: ordering, payment, forms and the mobile version. For a store it takes 3–5 days and starts from UAH 6,000. The audit shows which checks are worth automating and which to leave to a person. It gives you a base to build on.
Can automated tests fully replace a manual tester?
No. Automated tests catch regressions in known scenarios well, but they do not judge usability and do not find unexpected problems in new functionality. Manual and automated testing complement each other, and the right mix depends on the product and the budget.