Getting the best out of QA when you don’t have a dedicated QA team

Over the years I’ve worked with a wide range of software teams, different industries, different time zones, different levels of experience. Each one had its own techniques and its own approach, shaped by its context and its goals. But one thing showed up everywhere: the need for quality assurance of some kind is non-negotiable. And it almost always comes with a catch.

Plenty of organisations don’t have a dedicated QA department. The people who would do the testing are already stretched thin, the same person is running the project, writing the code, answering support tickets, and somehow also expected to make sure nothing’s broken before it ships. If that sounds familiar, this article is for you. Here are the techniques I’ve seen work for getting genuinely good QA out of a small, busy team, without pretending you have resources you don’t.

The trick isn’t to test everything. It’s to test the right things, with the right people, at the right moment. Let’s start with the first one.

1. Decide what’s actually worth testing

The most common QA mistake on a stretched team isn’t testing too little. It’s testing everything a little, badly. When time is scarce, the first job isn’t to test, it’s to triage.

Be deliberate about scope. For each feature, ask one blunt question: what is the cost if this fails? That cost comes in three flavours; human, financial, and technical and they’re not equal.

• Financial impact. Does this feature touch money? Pricing, calculations, the payment page, the checkout flow, anything that affects what a customer is charged. That gets tested first, every time, no debate. A display bug on an FAQ page is embarrassing. A rounding error in a price is a refund queue, a chargeback, and a trust problem.
• Safety and regulatory impact. If you’re in healthcare, finance, or any safety-critical domain, the bar is higher and the testing is more frequent. The question stops being “can we afford to test this?” and becomes “can we afford notto?”
• Visibility and business logic. Is it on the homepage? Is it core pricing information? Is it the bit of business logic everything else depends on? High blast radius means high priority.

There’s a paradox lurking here that’s worth naming. The instinct on a small team is to test less because you have less capacity. But the features where failure is expensive are exactly the ones where you can’t afford to cut corners. So the honest answer to “how much should we test?” is: test less overall, but test the high-cost-of-failure things more. Spread thin across everything and you protect nothing.

Two more things shift the dial on how much testing is enough. First, audit and compliance. If you’ll need to prove you tested something later, that’s a floor you can’t go below regardless of capacity. Second, your failure philosophy: a “fail fast and iterate” product can tolerate more rough edges than one where a single bad release damages the brand. Know which one you are before you decide what “good enough” looks like.

2. Get your foundations right: you can’t test what you can’t measure

Here’s the uncomfortable truth that no amount of testing effort fixes: bad requirements produce bad QA. If a story doesn’t have clear acceptance criteria, your tester is just guessing at what “working” means — and two people will guess differently.

So before you worry about who tests, make sure every story has measurable acceptance criteria. Not “the login should work”, that’s an opinion, not a test. Something you can actually pass or fail against. The good news is that solid acceptance criteria do double duty: they are your test scripts, near enough. Write them well once and you’ve done a chunk of the QA work before anyone’s opened the app.

This raises a question worth asking honestly: how trained is your team at writing good requirements? It’s an underrated skill, and it’s usually the cheapest, highest-leverage place to invest. A team that writes crisp, testable acceptance criteria needs dramatically less heroic testing later. If your stories are routinely vague, fix that before you buy any tools or hire anyone, it’s the root cause hiding behind most QA pain.

3. Crowdsource the testing

This is the big one, and it’s where most small teams leave value on the table. You almost certainly have more QA capacity than you think, it’s just not labelled “QA.”

Spread the load across the people you already have: project managers, product owners, business analysts, support staff. They each bring something a dedicated tester might not. Support people know exactly how real users break things. Business analysts know what the feature is supposed to do better than anyone. Product owners own the outcome, so the question is fair: are they up to speed enough to test? Often they are, and often they want to be, because nobody wants their feature shipping broken.

Don’t overlook your junior team members either. Getting them involved in writing test plans and scripts, and running them with the team, is one of the best ways to bring them up to speed, they learn the product deeply, and you get extra hands. It’s training and QA in the same activity.

And it doesn’t have to stop at your immediate team. I’ve had real success simply asking other departments for help, a short email explaining the feature, what you need eyes on, and how long it’ll take. People are generally happy to spend twenty minutes clicking through something if you make it easy and tell them why it matters.

To make crowdsourced testing work, two artefacts do the heavy lifting.

A solid test plan. This is your map of what gets checked across the product. It doesn’t need to be elaborate, it needs to cover the things that matter. For a typical product, the core list looks something like:

1. Login
2. Password reset
3. Forgotten password
4. Payment page
5. Checkout

Notice these map straight back to the cost-of-failure thinking from earlier — they’re the load-bearing, money-adjacent journeys.

Clear test scripts. Each script walks through the important scenarios for the feature, step by step, so that anyone, regardless of how technical they are, can run it and know whether it passed. Here’s what one looks like for a membership login:

1. A field to enter the membership number is presented to the user.
2. The user enters their membership number.
3. The user clicks Login.
4. If the membership number is invalid, a message is displayed stating “invalid membership number.”
5. If the membership number is valid, the user is taken through to the dashboard screen.

That’s it. No jargon, no assumptions. A product owner, a support agent, or a brand-new graduate can pick that up and execute it identically. And, you guessed it, most of those steps were sitting in the acceptance criteria already.

4. Bring product owners in early

A lot of QA pain is really timing pain. Bugs found a week before go-live are expensive and stressful; the same issues caught as a conversation at refinement are cheap and calm.

Get your product owners involved early, not at the end. The simplest mechanism I’ve seen for this is the “three amigos” meeting; business analysis, QA, and project management (or development) in the same room before a story is built. The three perspectives catch different things: the BA spots a missing requirement, the tester spots an edge case nobody considered, the PM spots a scope or dependency problem. Half an hour up front routinely saves days of rework later.

The honest diagnostic question to keep asking is: how involved are your product owners, really? If they’re only showing up at the demo to react, you’re finding problems at the most expensive possible moment. Pull them forward.

5. Automate the repetitive stuff

Humans are brilliant at exploratory testing and terrible at doing the same regression check for the four-hundredth time without their eyes glazing over. That’s exactly backwards from what a stretched team needs, which is where automation earns its keep.

You don’t need to automate everything. Start with the stable, high-value, repetitive journeys (those core flows again: login, checkout, payment). Tools like Selenium let you script those checks so they run themselves on every change, freeing your humans for the judgement-heavy work. And for the perennial headache of “does it work on that device?”, BrowserStack is invaluable. It lets you test across a wide range of real mobile devices and browsers without maintaining a drawer full of handsets.

A word of caution, though: automation is an investment, not a freebie. Automated tests need writing and maintaining, and a suite of flaky, out-of-date tests is worse than none because people stop trusting it. Automate the things that are stable and that you’ll run again and again. Leave the fast-changing, exploratory stuff to people.

6. Match your effort to the stage of the project

How much and what kind of QA you need changes depending on where you are. Early in development, you’re testing to learn; rough, fast, exploratory. As you approach go-live, the stakes rise and the testing tightens: the core journeys get hammered, the regression checks run, the cost-of-failure features get extra scrutiny.

And don’t forget that testing doesn’t end at launch. Post-go-live testing, smoke-testing the critical paths in production, watching how real users behave, catching the issues that only show up with real data and real load is part of the job, not an afterthought. The work changes shape after release; it doesn’t stop.

7. Know when to stop improvising and hire

Everything above is about getting more out of the team you have. But it’s worth being honest about the limit. If you genuinely don’t have a dedicated QA person and quality keeps slipping through the cracks. If releases are routinely painful, if the same kinds of bugs keep reaching customers, if your stretched team is burning out trying to cover testing on top of everything else, then the answer might simply be that it’s time to invest in a dedicated QA.

Crowdsourcing, good acceptance criteria, and automation will take a small team a remarkably long way. But there’s a point where the cost of not having someone who owns quality outweighs the salary of someone who does. Knowing where that line is for your product, your risk profile, and your team’s capacity is itself a quality decision.

The throughline

If there’s one idea connecting all of this, it’s that QA on a small team is a series of deliberate choices, not a department you either have or don’t. Decide what failure would actually cost. Write requirements clear enough to test against. Share the load with the capable people already around you. Let machines do the boring, repeatable checks. Tighten up as you near release, and keep watching after it. And when you’ve genuinely outgrown the improvised approach, recognise it and resource it properly.

You don’t need a big QA team to ship with confidence. You need to be intentional about the one you’ve got.