Running QA in a Team That Has No QA Department

Most software is built by teams with no QA function. Four developers, a designer, someone who is half a project manager, and a shared belief that everyone tests their own work. It usually holds until the first release where a customer finds something embarrassing.

I run a small development studio alongside a full-time QA role, so I have had to answer this from both directions: what is the minimum that meaningfully improves quality when there is no tester, no budget for tooling, and no appetite for process?

The answer is smaller than most process documentation suggests. Four or five things, in order, and none of them require hiring anyone.

The situation, honestly

In a team with no QA function, quality is everyone's responsibility, which in practice means it is nobody's. Not through negligence — because developers test their own work against the case they had in mind while building it, and that is the one case guaranteed to work.

This is not a discipline failure, it is a perspective limitation. The person who wrote the code cannot easily imagine the input they did not anticipate. Someone else can, and they do not need to be a specialist to do it.

So the first move is not a test plan. It is deciding that nobody merges their own work unchecked.

Start with a definition of done, not a test plan

Before any tooling, agree what "finished" means. Written down, in one place, six to eight lines. Something like:

• The feature works on the happy path and on the two obvious failure paths
• Someone other than the author has used it
• Required fields validate, and the error messages say what is wrong
• It works on a phone-sized screen
• Nothing in the browser console, and no unhandled server error
• The data it writes has been looked at directly, not just the success message

That list is worth more than a test plan in a team this size, because it is short enough to be remembered and it is applied by the person building the thing. Most of what a tester would catch on a small product is on that list.

The line that changes the most is the second one. Ten minutes of someone else using a feature before it merges catches a remarkable proportion of what would otherwise reach a customer.

One checklist beats a test management tool

Do not buy test management software for a team of five. Write a release checklist in a document in the repository.

It should contain the flows that must never break — sign up, log in, the core action the product exists for, checkout or whatever moves money — with the steps to walk each one and what to expect. Twenty to forty items, not four hundred.

Someone runs it before each release and notes the date, the build, and anything that failed. That is a regression suite. It is unglamorous, it takes an hour, and it will catch the majority of what escapes a small team — the thing broken as a side effect of an unrelated change.

When something does escape to a customer, it earns a permanent line on the checklist. Over a year that list becomes the most valuable quality document the team owns, because it is built from what actually broke in this product rather than from what someone imagined might. The same principle scales up: a defect-driven suite is the core of any regression strategy.

Make the tracker the only channel

Defects reported in chat do not get fixed. They scroll away, get half-remembered, and reappear as a customer complaint.

One tracker, and if it is not in there it does not exist. Whatever the team already uses is fine — the tool matters far less than the rule.

Then hold a minimum standard for what a report contains: steps, expected, actual, environment. It takes two extra minutes to write and saves a developer twenty minutes of guessing, and in a small team the person who benefits is sitting next to you. The full structure is here, but steps, expected, and actual carry most of the value.

Automate the cheapest layer first

The instinct is to reach for browser automation. In a small team that is usually the wrong first investment: it is the most expensive to write, the most brittle, and the first thing abandoned when a deadline arrives.

Cheaper layers with better returns:

• A Postman collection asserting status codes and response shapes for your main endpoints. An hour to build, runs in seconds, catches contract breakages the same day they appear.
• A handful of SQL queries that check data consistency — orders whose total disagrees with their line items, records in impossible states. Run them against staging before a release.
• Whatever unit tests the developers will actually maintain around the logic that calculates money.

If browser automation is worth adding later, add it for the two or three flows that must never break, and build it so it does not rot. Ten stable tests that run on every pull request are worth more than a hundred nobody trusts.

Test the money paths, ignore the rest at first

With limited time, the prioritisation is not subtle. Anything that calculates an amount, takes a payment, changes stock, or writes a financial record gets tested every release without exception. Anything that affects who can see what gets tested every release too.

Layout, sorting, filter behaviour, and copy can rotate — a different area each release. When time runs out, that is what gets cut, and deciding it in advance is much better than deciding it under pressure at the end.

The point of the tiering is not thoroughness. It is that the failures which cost money or expose data never end up in the pile that got skipped.

Give the team a release ritual

The last piece is a small, fixed sequence before every release. It does not need a document:

1. Run the checklist on the release build, not on the branch
2. Re-verify every defect marked fixed in this release, on that build
3. Run the consistency queries against staging
4. Write three lines in the release notes: what was tested, what was not, and what is known broken
5. Ship, then check the core flow once in production

Step four is the one people skip and the one that changes the team's culture fastest. "Export formatting was not re-tested this cycle" is a professional statement of scope, and it gives everyone else a chance to object before it matters rather than after.

What good enough looks like

Three months in, a team that has done the above has no QA department and no tooling budget, and has: a definition of done people apply, a release checklist that grows from real failures, one tracker with reports developers can act on, a small set of API and data checks that run fast, and a habit of writing down what was not tested.

That is not a QA function. It is most of the value of one, and it costs a few hours a month. The remaining gap — the deliberate, adversarial thinking about how a system fails, and the willingness to own a release decision — is where bringing in someone who does this for a living starts to pay for itself. That is a large part of what I do, and it is also the honest answer to when you actually need it: later than most process advice implies, and earlier than most teams admit.