How much QA do you need when you have none? One engineer, part time or a team
Companies that have never had a QA function rarely know what to ask for. One person full time? Someone part time? Maybe more than one, because there is clearly a lot to test? That uncertainty is normal, and it is not a sign that you have done your homework badly. It is hard to size work you have never seen done.
This article gives you a way to reason about it. It covers the four questions that decide the size, the engagement shapes that fit each answer, when part-time testing works and when it does not, and how to start small without boxing yourself in.
Four questions that decide how much testing you need
Rules of thumb such as a fixed number of testers per developer get quoted a lot, and they break down fast because they ignore how your product is actually built and released. These four questions get you much closer.
How often do you release?
This is the biggest single factor. A team that ships every day needs testing running every day, because every release needs checking before it goes out. A team that releases once a month can concentrate effort in the days before each release. Frequent releases also make test automation worth building earlier, because the same checks repeat so often.
How settled are your requirements?
If features are still being defined, testing starts before the code does: reviewing requirements, asking what should happen in the awkward cases, writing acceptance criteria. That is senior work and it does not need many hours a week, but it needs the right person. If requirements are stable, the work shifts to running and maintaining tests, which scales with the size of the product.
How many surfaces do you ship?
A single web application is one thing to test. A web application plus a mobile app on two operating systems plus a public API is several, each with its own devices, browsers and failure modes. Each surface adds work, and the places where they connect add more.
Who will manage the tester?
An engineer added to your team needs someone on your side to set priorities and read their reports. If nobody has the time or the testing background to do that, you need a shape where the vendor runs the function and you get the result.
The shapes QA engagements usually take
Your answers to those four questions point to one of a small number of shapes. They are not fixed categories, and most engagements move between them over time.
| Shape | Fits when | Needs from you |
|---|---|---|
| A specialist for a fixed piece of work | You need performance, security, accessibility or API testing for a few weeks, not all year | A clear scope and an environment to test |
| One engineer, part time | Releases are infrequent, the product is small, or you need a senior to set things up before daily testing starts | Someone who can answer questions the same day, on the days they work |
| One or more engineers in your team | You release often and have someone who can direct testing day to day | A person on your side who sets priorities |
| A managed testing function | You release regularly and do not want to build or run a QA department | Agreement on what "done" means; the vendor owns the plan, the work and the reporting |
The difference between the last two rows matters more than it looks. With engineers in your team, their output is your management problem. It is cheaper per hour and more expensive in your own time. With managed testing, the vendor owns the plan, the work, the reporting and the staffing, and answers for the result. If you want people in your team rather than a function run for you, QA staffing is that shape.
When part-time QA works, and when it does not
Part-time testing is a reasonable choice more often than vendors admit, and we take part-time engagements. It works well in three situations. The first is early on, when you need an experienced tester for a few days a week to review requirements, set up the bug process and decide what to automate first. The second is a small, stable product that releases on a predictable schedule, where testing can be planned around release dates. The third is a specialist need, such as a security or performance review, alongside your own developers' testing.
It works badly when you release continuously, because a bug found on Thursday by someone who is not back until Monday has already shipped. It also works badly when the part-time person is the only tester on a fast-moving product and nobody else knows the test suite. In those cases, a full-time engineer, or a managed function with cover built in, costs more per month and less per bug that reaches your users.
A useful middle ground for a company starting from zero is a senior engineer part time combined with a mid-level engineer doing the daily testing. The senior sets the process and makes the judgement calls. The mid-level engineer does the volume. If you are unsure what each level brings, our article on junior, mid and senior QA covers it.
Start smaller than you think, and keep the contract flexible
When a company first sees how much there is to test, the instinct is to staff for all of it at once. We usually advise the opposite. Start with the smallest shape that covers your riskiest area, learn what the real volume is from a few weeks of actual testing, and grow from there. You will make a better decision about the second and third person once you have seen what the first one finds.
That only works if the contract can flex. Ask any vendor how fast you can add or remove people, what notice they need, and whether the engineers you start with stay on as the team grows. Most of our engagements start as one shape and turn into another, and the contract is written to allow that. Our guide to scaling QA covers how capacity is added without losing what the first engineers learned about your product.
On cost, our rates sit between $25 and $45 an hour, depending on seniority, how long you commit for, and the mix of manual, automation and specialist work. A team can usually be working on your product in about two weeks. The trial is the same whatever the size: two weeks, free if you are not happy with what we deliver. We invoice from week three.
If you have answered the four questions above and still are not sure whether you need one person or three, full time or part time, that is the normal position. It is a short conversation, not a research project. More on how we route these decisions is on our software testing services page, and the general reasons companies outsource testing at all are on the QA outsourcing page. For background on the discipline itself, Wikipedia's overview of software testing is a fair neutral starting point.
Frequently asked questions
One person or three? Ask us
Tell us how you build and how often you release. We will tell you what we would staff, and say so when the answer is smaller than you expected.
Talk to our teamNeed help with software testing?
BetterQA provides independent QA services across manual testing, automation, security audits, and performance testing. ISO 27001, 9001, 14001 and 13485 certified.
