If you cannot afford a QA team, do not try to test everything a little. Test a few things properly. A good software testing strategy on a small budget spends effort where a failure would cost you the most, and deliberately spends less everywhere else.
Start your software testing strategy with a risk list
Testing time is limited, so treat it like any other budget: rank the options and fund the top of the list. For each feature or flow in your product, give two scores from 1 to 5:
- Impact: what happens if this breaks? A 1 is a cosmetic glitch. A 5 is lost money, lost data, a legal problem or customers locked out.
- Likelihood: how likely is it to break? Code that changes often, has complex rules or depends on outside services scores high. Pages nobody has touched in a year score low.
Multiply the two. Anything scoring 15 or more gets tested on every release. Anything under 6 gets a quick look now and then. Everything in between gets tested when it changes.
The value is not in the arithmetic. It is in having the conversation once, writing down the answer, and then not arguing about it every release.
A worked example: a store with 400 products
Imagine an online store selling 400 home decor products, with discount codes, cash on delivery and card payments, order emails and an admin panel for stock. A first pass at the risk list might look like this:
- Checkout and payment: impact 5, likelihood 4 (payment gateway updates, tax rules) = 20
- Discount codes: impact 4, likelihood 4 (marketing changes them weekly) = 16
- Stock updates from the admin panel: impact 4, likelihood 3 = 12
- Order confirmation emails: impact 4, likelihood 2 = 8
- Product search and filters: impact 3, likelihood 2 = 6
- About and contact pages: impact 1, likelihood 1 = 1
Now say the store can afford about 40 hours of testing a month, from a part-time tester or from developers' time. A sensible split:
- 12 hours running a written regression checklist for checkout, payments and discount codes before each release
- 10 hours writing and maintaining a small set of automated tests for the same high-risk flows
- 8 hours of exploratory testing on whatever changed that month
- 6 hours on real devices and browsers, chosen from the store's own analytics
- 4 hours triaging bug reports and confirming fixes
The About page gets no scheduled time at all, and that is fine.
Five areas almost every product should test first
Whatever your product does, these usually land at the top of the list.
1. The money path
Anything that takes payment, creates an invoice or calculates a price. Test the happy path, a failed card, a slow network during payment, and a customer pressing the back button after paying.
2. Getting in
Sign-up, login, password reset and email verification. If people cannot get in, nothing else you tested matters.
3. Data you cannot get back
Deletes, imports, bulk edits and database migrations. A bug that shows the wrong color on a button can be fixed tomorrow. A migration that corrupts order history may not be fixable at all, so test these on a copy of real data and check your backups actually restore.
4. Who can see what
Log in as customer A and try to open customer B's order by changing the number in the URL. This is a five-minute check, and it catches one of the most serious bug types a web app can have.
5. The edges where you meet other systems
Payment webhooks, SMS and email providers, shipping APIs. Test how your app behaves when they are slow, fail or send something unexpected. You do not need to test the provider itself. The Playwright best practices guide puts it well: only test what you control, and mock the responses of third-party services instead of calling them in tests.
Where automation pays off, and where it does not
Automated tests cost time to write and time to maintain. They pay off when the thing they check is important, stable and checked often.
- Automate first: business rules with clear inputs and outputs, such as price, tax, discount and delivery date calculations. These unit tests are cheap, run in seconds and rarely break for the wrong reasons.
- Automate next: a handful of end-to-end tests of the flows at the top of your risk list, such as "guest buys one product with a discount code." Five good end-to-end tests are worth more than fifty fragile ones.
- Keep manual: screens that are still being redesigned, one-off campaigns, and anything where a human judges whether it "looks right." Automating a screen that changes every week means rewriting the test every week.
Write tests the way a user sees the product. Playwright's guide recommends testing user-visible behavior rather than implementation details, and keeping each test isolated with its own data, which is also what keeps a small test suite from becoming a maintenance burden. Once you have tests, run them automatically on every pull request, as described in our guide to a simple CI/CD pipeline, so nobody has to remember.
One rule costs almost nothing and compounds: every time you fix a bug, add a test that would have caught it.
Devices, browsers and free help
You do not need to test on every phone. Open your analytics, list the browsers and devices that cover most of your visitors, and test on those. For a mobile app, depending on your audience, a couple of mid-range Android phones and a recent iPhone may cover more real users than a set of flagship devices.
If you publish on Google Play, use the pre-launch report. When you upload an app bundle, Google installs the app on devices in its test lab, crawls it for several minutes and reports stability, compatibility, performance and accessibility issues, usually within an hour. If your app has a sign-in screen, give it test credentials so it can get past the login. Our app launch checklist covers the other store-side checks worth doing before release.
Production is part of your test plan
No budget catches every bug before release, so make sure you find the rest quickly. Three inexpensive things do most of the work:
- Error tracking that alerts a developer when a new error appears, with the stack trace attached.
- An uptime or health check that tests a real page or API endpoint every few minutes, not just whether the server answers.
- An easy way for users to report problems, with the app version and device captured automatically.
Pair these with small, frequent releases. A release with three changes is easy to test and easy to roll back. A release with forty changes is neither.
What to skip until later
On a small budget, a software testing strategy has to say what waits, not just what gets tested. For now, skip:
- Chasing a coverage percentage. 90% coverage of the wrong code protects less than a few tests on checkout.
- Load testing before you have load, unless you are planning a launch event, a sale or an advertising burst. Then it moves to the top of the list.
- Automated tests for screens still being designed.
- Testing third-party services themselves. Test how you handle them, not whether they work.
And when is a dedicated tester worth paying for? When the same bugs keep coming back, when releases regularly break something unrelated, when you are about to launch publicly, or when you work in payments, health or other areas where a mistake has consequences beyond an unhappy customer. Developers testing their own work miss things for the same reason writers miss their own typos.
A good next step is an hour with your team: list your flows, score them, and agree on the top five. If you would like an outside view, our QA and testing team can build the risk list with you, write the regression checklist and set up the first automated tests, then hand it all over so your developers can keep it going. For a store like the one in the example, our e-commerce developers can also point out where checkout code tends to be fragile.
