What a QA tester does
A QA tester deliberately tries to break your software before your customers do. They work through it methodically — following requirements, poking edge cases, testing across devices and browsers — and file clear, reproducible bug reports your developer can act on. The deliverable isn’t fixed code; it’s a reliable account of what’s broken, how to trigger it, and how serious it is.
That distinction matters. A tester finds and documents problems; the developer fixes them. The value of a good tester is in the quality of their reports — a bug someone can reproduce in three steps gets fixed fast, while “it doesn’t work” burns a day in back-and-forth. Testing comes in two flavors: manual (a person using the product like a user) and automated (scripts that re-check things on every change). Most small projects start with manual and add automation as they grow.
What it costs
Independent QA testers typically charge $35–$90 per hour. Manual testing against clear instructions sits near the bottom; test automation and specialized work like performance or security testing sit at the top. Three things move the rate:
- Manual versus automated — writing and maintaining automated test suites is a coding skill that bills higher than manual testing.
- Domain — testing anything involving payments, security, or regulated data demands experience and more care.
- Coverage breadth — testing across many devices, browsers, and scenarios takes more hours than a single target.
See the full breakdown in our QA tester cost guide.
How to evaluate one
Ask to see a sample bug report. It’s the whole job, and a good one has clear steps to reproduce, expected versus actual behavior, severity, and the environment it happened in — everything a developer needs to fix it without a meeting. Then ask how they think about edge cases: what happens with an empty form, a huge upload, a double-click, a dropped connection. Testers who only walk the happy path miss exactly the bugs that embarrass you in front of customers.
Confirm what they’ll actually test on — real devices, browsers, and screen sizes, not just the one setup where everything happens to work. Define whether they’re writing test cases from your requirements, exploring freely, or both, and put the scope, target environments, and reporting format in a short statement of work so “test my app” has an actual shape. Agreeing on acceptance criteria up front gives testing a clear finish line.
When you need one
You don’t always need a dedicated tester. For a tiny site or a solo project, the developer testing their own work plus a friend clicking around may be enough. Hire a QA tester when the cost of a bug is real — anything handling payments, bookings, or customer data — because an independent set of eyes catches what the person who wrote the code can’t see.
The best time to bring one in is before launch, not after complaints start. A focused testing pass on a finished build is cheap insurance against the public bug that costs you a customer’s trust. If you’re launching something that has to work on day one, budget the hours for it deliberately.
Questions to ask before you hire
- Do you do manual testing, automated testing, or both, and which does my project need?
- How do you report bugs so my developer can reproduce and fix them without back-and-forth?
- Which devices, browsers, and screen sizes will you actually test on?
- Will you write test cases from my requirements, or explore the product freely, or both?
- Have you tested something like mine, and what kinds of bugs do you tend to catch?
Red flags
- Bug reports that just say "it's broken" with no steps to reproduce. That's not testing, that's complaining.
- Only tests the happy path — the way things are supposed to work — and never the edges.
- No coverage of real devices and browsers, just one setup that happens to work.
- Confuses finding bugs with fixing them; a tester reports, they don't rewrite your code.