A small team with no testers needs a light system, not a QA department: one named person who owns the 'ready to launch' decision; a written definition of 'done' that includes someone other than the builder trying the feature; a short list of the journeys the business earns from, rerun after every change; a staging copy to test on before publishing; and a single bug log. The team then moves the repeated reruns to an AI QA agent and keeps for people what needs judgement.
- QA for small teams
- how to test software without testers
- does a startup need a QA engineer
- QA process for a startup
- who tests the app in a small team
- how to do quality assurance without a QA team
Who owns quality when there is no tester?
On a team of five it goes like this: the developer finishes a feature and says 'I tried it, it works'. The product owner opens it once and says 'great'. It ships on Thursday. On Sunday a customer calls. Nobody was negligent, but nobody owned the question: is this actually ready? Quality on small teams does not collapse for lack of skill; it collapses for lack of an owner.
IllustrationThe answer is not hiring a tester tomorrow. It is naming one person who owns the launch decision. They do not test everything; they ask: was it tested? By whom? With what result? On most teams this is the product owner or founder, and the role can rotate monthly.
What everyone owns, no one owns. Put one name next to the word 'ready'.
What is the smallest quality system that actually works?
Five parts only. Any team can set them up in a week, and each addresses a common reason bugs reach customers:
- An owner
- One name decides ready or not ready
- Definition of done
- A short list no feature is finished without
- Journey list
- Three to five journeys rerun after every change
- Staging copy
- A place to test before customers see it
- One bug log
- One place, not scattered chats
Note what is absent: no QA department, no twenty-page test plan, no complicated tool. Those come later if the team grows. The staging copy is the most important part and the most neglected; see staging versus production.
What should 'done' mean?
Most arguments on small teams are about this word. The developer means 'I wrote the code'; the product owner hears 'a customer can use it'. Write the definition once and pin it up:
The first item assumes a written description exists. Two lines per feature are enough: what it must do and what it must refuse. Those are acceptance criteria, and without them there is nothing to test against. To write them in an organized way, read how to write a requirements document, or let Fanann's Product Owner Noura ask the questions and write them with you.
What do you test when you cannot test everything?
You will not test everything, and neither do large teams. The trick is to choose on purpose, not by accident. Ask two questions of each area: what do we lose if it breaks, and how often does it change?
| Category | Examples | How often to test |
|---|---|---|
| Touches money directly | Payment, cart, booking, prices, discounts | After every change, and daily by automation if you can |
| Touches trust | Sign-in, permissions, customer data, outgoing messages | After any change near it, and weekly |
| Changes often | Home page, offers, whatever you are building this month | On every change |
| Stable and low impact | About page, FAQ, footer | Before big releases only |
| Internal admin panel | Reports, staff settings | When it changes; staff will report quickly |
And write down what you decided not to test. A recorded, deliberate decision is very different from forgetting, and prevents surprises later.
What weekly rhythm keeps the system alive?
A system that runs on enthusiasm dies in month two. Tie it to fixed days. This example uses a Sunday-to-Thursday working week and takes one to two hours of team time:
- SundayWhat ships this week?
Ten minutes: the planned features, each with two lines on what it does and what it refuses.
- Mon–TueA second pair of eyes
Every finished feature is tried by another colleague on staging before it counts as done.
- WednesdayGroup bug hunt
Twenty minutes, each person on a different device, then a full rerun of the core journeys.
- Thursday morningLaunch decision
The owner reviews the log: no open critical or high bug? Publish. Otherwise, hold back only what is not ready.
- Thursday, after publishingSmoke test on live
Five minutes: a real order from a phone, to confirm what worked on staging works here.
Do not publish in the last hour before the weekend. If a bug appears nobody is there to fix it, and store and restaurant customers are at their busiest on days off.
How do you add testing capacity without hiring?
As the product grows, the weekly hour stops being enough. Before posting a job, there are four cheaper routes:
Pick the one that sounds like you to see the advice.
That is the work of an AI QA agent. It saves the cases and reruns them in a real browser after each change or on a schedule, and documents what broke. You only review the plan and the report.
A freelance tester for a few hours at each major release. Give them a goal and the feature description and let them explore freely. No standing contract needed.
Five real customers trying it in front of you, or a small beta group that gets the feature a week early. No tool replaces this.
Rotate the role: each week a different person is 'tester of the week' for two hours. Everyone learns the whole product, and the eye changes.
The agent-versus-person comparison, task by task, is in AI QA agent or a human tester. The rule: do not pay a person to repeat, and do not expect software to judge taste.
How does an AI QA agent fit into a small team?
It joins as a colleague carrying the heaviest part of the system: the journey list that gets rerun. Fanann's QA Engineer takes the address of your site or web app, built in Fanann or elsewhere, explores it and proposes test cases. It does not start until one of you approves the plan. Then it runs in a real browser and reports with screenshots and severity, includes a bug tracker with clear statuses, and re-tests after the fix. It is part of the paid plans.
| Part of the system | Before the agent | With the agent |
|---|---|---|
| Journey list | Rerun by hand, shortened when busy | Saved cases rerun in full every time |
| Bug log | A sheet updated when remembered | Each bug has a screenshot, steps and a status |
| The 'ready' decision | An impression | A verdict plus a list of what was not covered |
| Closing a bug | The developer says 'done' | A passing re-test |
| The owner | Still required | Still required |
We are a team of four with no tester. This is a sports pitch booking app. Test the three most important journeys at phone size: booking a pitch and paying the deposit up to the payment page without completing a real payment, canceling a booking before its time, and a pitch owner signing in to see today's bookings. Make sure the same pitch cannot be booked twice for the same hour, that a player cannot see other players' bookings, and that a pitch owner cannot see other owners' pitches. You are on the staging copy and may create test bookings. Save the cases so we can rerun them every week.
Try it in FanannWhich mistakes do small teams make?
- 'We will test when we are bigger': bugs do not wait, and habits not built with five people will not appear with twenty.
- The developer alone tests their own work: they know the right path and stay on it. A second pair of eyes, even for ten minutes.
- Testing straight on live: faster today, more expensive tomorrow.
- A huge testing push before each big release: exhausting, then abandoned. A small weekly rhythm beats it.
- Fixing without re-testing: the fix itself can break something nearby.
- Buying a tool with no owner: the tool produces reports, and a report without a reader changes nothing.
- Measuring quality by test count: measure what reached customers and how long it lived before discovery.
When do you hire a full-time tester? When steady human work fills their time: new features every week, devices and tills, or a complex product. Until then this system, plus an agent and a freelancer when needed, is enough. For the wider picture of a product team working with AI, read an AI product team in one place: plan, build and test.
Key takeaways
- 'Quality is everyone's job' means in practice nobody's; name one owner for the decision.
- Whoever built a feature should not be the last to test it; a second pair of eyes, even for ten minutes.
- Do not test everything; test what would cost money or trust if it broke, in that order.
- A fixed weekly rhythm of an hour or two beats a big testing push every three months.
- A QA agent adds testing capacity with no salary, but the team still names an owner and reads the report.
Frequently asked questions
Does a startup need a QA engineer from the start?
Who tests the app on a team with no testers?
How much time does testing need on a small team?
Should developers write automated tests themselves?
What is the difference between quality assurance and testing?
Does this system work for a solo founder?
Ask your AI assistant about this
Copy this prompt into the AI assistant you use, then add the details of your own case.
I am reading this guide: “Quality for small teams: how to test when you have no testers” https://fanann.com/en/blog/qa-for-small-teams-without-testers/ My question: QA for small teams Use that page as a source and explain the answer step by step for my situation, tell me what to check before I start, and cite the page link.