In this guide 6 sections
Hire a staff tester when you release weekly and need someone who knows the product deeply. Use a freelancer for a bounded project with a clear scope. Use a QA service when you need independence, many devices and continuity. Whichever you pick, own the test cases in your own repository.
What you are really buying
A tester is not a button clicker. The real work is writing test cases from requirements, running them on real phones and browsers, logging defects with steps to reproduce, and retesting fixes before release.
The three options differ in who carries that work when things change. A salaried tester carries it daily. A freelancer carries it for the contract. A service carries it through a team, with a lead who reviews the output.
Name the gap first. A product with no test cases at all needs a different person from one with a suite that nobody runs.
Independence and device coverage
Developers miss their own mistakes. A staff tester sitting beside the team learns the shortcuts and slowly starts to test what the developers expect. An outside freelancer or service keeps a fresh eye, and that matters most before a major release.
Coverage is the other test. One person owns a phone or two. Real customers use older Android handsets, small iPhones, tablets and three browsers. A service usually keeps a device shelf and a cloud account. A freelancer brings whatever sits on their desk.
Ask each candidate which devices and browsers they would cover. Ask what they would skip. Listen for specifics.
- Who reports defects: the person who wrote the feature or someone separate
- Real device list, not emulators alone
- Browsers and screen sizes covered
- Access to a staging copy, never live data
Continuity when one person leaves
This is where the single hire is weakest. When your only tester resigns, the knowledge of which screens break, which accounts to use and how the release checklist works leaves with them. A fortnight later, a bug reaches customers.
A freelancer carries the same risk, with less notice. A service has a second person who can step in, plus a lead who has seen the notes. That cover is part of what the fee pays for.
Reduce the risk in any case. Keep a written smoke list, a shared test account sheet and a release checklist where a replacement can find them on day one.
Who owns the test cases and scripts
Ownership is the clause people forget. Read it twice. Then read it again. Test cases in a spreadsheet on a freelancer’s laptop, or automation scripts in a service’s private repository, are not yours. If the relationship ends, you restart from zero.
Insist that cases live in your tracker or repository, whether that is Jira, TestRail, a shared sheet or Git. Automation code should be pushed to a repository you control, with a read me that explains how to run it.
Write it into the agreement: all cases, scripts, test data and defect history belong to you and are handed over on request.
- Test cases stored in your tool
- Automation code in your Git repository
- Credentials and test accounts held by you
- Handover notes written before the contract ends
A simple way to choose
Weekly releases and a deep product point to a staff tester, paired with a service for peak periods. A one off launch or a migration points to a freelancer with a tight brief. A product with many devices, strict customers or no spare tester points to a service.
Many small teams mix them: one internal owner of quality, plus outside help for regression and release weeks.
Start with a pilot. Run four weeks on one real release. Compare the defects found, the clarity of the reports and how fast the retests came back.
QA options comparison sheet
Table on a single page, three columns wide: staff tester, freelancer and QA service. Rows cover independence, devices, cover for absence, ownership of cases and scripts, notice period and handover. A box below logs the pilot release. It records defects found, report clarity and retest turnaround in days.
Open a blank worksheet to printQuestions owners ask
Is a freelancer cheaper than a QA service?
Often for a small scope, yes. Compare the full cost, including your time spent briefing, reviewing reports and finding cover when the freelancer is unavailable.
Can developers test their own work?
They should test while building, but not alone. A second person tests against the requirement rather than the intention, and finds different defects.
Who should own the automation scripts?
You should. Keep them in your Git repository with run instructions, so any future tester or service can pick them up.
When do we need more than one tester?
When releases slip because testing queues behind one person, or when the product must run on many devices. Add a service for the peaks rather than a second hire.