Service file · QA Testing VA · Updated November 2026
Outsourcing software testing: hiring a QA testing virtual assistant
A buyer's file for moving the testing work your developers squeeze in before a release (test cases, manual and regression runs, exploratory sessions, bug reports, fix checks, test data and the upkeep of automated tests you already have) to a dedicated remote tester: what to put in scope, which level to buy, who keeps the release decision, what it costs against an in-house hire and which numbers to put in writing.
- Rate
- $8.50–$16/hr
- Full-time / month
- $1,360–$2,560
- First candidates
- About 2 business days
- Setup / recruitment fee
- None
File summary
per hour for a dedicated QA testing VA through our recruiting partner, set by skill level
recruitment or setup fee; nothing is paid before you choose a candidate
business days to the first candidates, usually (never a binding promise)
no release sign-off, no security testing, no compliance certification
trial window in which you can end the engagement immediately
the tester works only for you, inside your own tracker, test tools and environments
In this file
- Work packages by testing activity
- Who decides what
- Buying the right level
- A statement of work you can copy
- Engagement models compared
- Total cost of ownership
- Sizing the seat from a sprint tally
- Environments, accounts and test data
- The bug report standard
- Service levels and KPIs
- Vendor questionnaire
- Scope by product type
- Tools the seat works in
- Acceptance test before you choose
- Onboarding plan: 30, 60, 90 days
- Risk register
- Exit and handover
- Requesting candidates
- FAQ
Work packages by testing activity
A QA testing virtual assistant is a dedicated remote tester who checks your software before your users do. You buy a seat, measured in hours, inside your own bug tracker, test management tool, staging environment and team chat. Today this work usually sits with the developers who wrote the code, or with nobody when the deadline is close.
Buy the seat by activity. Each row names what the tester does and what stays with your team. A common starting point is regression runs and bug reports on the main product, then add test-case writing and exploratory sessions once the tester knows the flows.
| Package | Tester's tasks | Stays with your team |
|---|---|---|
| Test cases | Write test cases from user stories, acceptance criteria and specs: happy paths, invalid inputs, boundary values, permissions; keep them current when features change | The acceptance criteria themselves; what a feature should do |
| Manual functional testing | Run the cases on each build in staging; record pass, fail or blocked with evidence | Which builds go to test and when |
| Regression testing | Re-run the regression set before each release; keep the set trimmed and ordered by risk you agree | Which areas count as critical |
| Exploratory testing | Time-boxed sessions on new or changed features from a written charter; notes of what was tried and what was found | Charter topics and priorities |
| Browsers and devices | Check agreed flows on the browser and device list you set, on real devices or a device cloud you pay for | The supported browser and device list |
| Bug reports | File reports to your standard with steps, expected and actual results, environment, screenshots, a recording and logs; link them to the story | Severity rules, priority and who fixes |
| Fix verification | Re-test fixed bugs on the next build, close or reopen with evidence, check the area around the fix | Decisions to defer or accept a known bug |
| Test data | Create test accounts, sample records and files in test environments from your rules; reset data between runs | Test accounts, masking rules and any production access |
| Release checklist | Run your pre-release and post-deploy checklists; write the test summary: run, passed, failed, not tested, open bugs | The go or no-go decision |
| API checks | Run and extend Postman collections or similar against documented endpoints; compare responses with the spec | The API design and contracts |
| Automated test upkeep | Run the existing suite, triage failures, fix broken selectors and data, add cases in the pattern your engineers set | Framework choice, architecture and the CI pipeline |
| User acceptance support | Write UAT scripts for your customers or stakeholders, collect their results, turn feedback into tickets | Sign-off by the stakeholder |
| Release sign-off, security testing, compliance certification | Anything that approves a release, attacks the system or certifies conformance | Always; never in scope |
Who decides what
A tester produces evidence; your people make the calls. Writing that down early stops two common failures: a green test run read as a release approval, and a tester who argues severity with developers instead of escalating. Put this split into the onboarding pack and the statement of work.
The tester may
- Mark a test passed, failed or blocked, with evidence
- Propose a severity from your written scale
- Reopen a bug when the fix doesn't hold
- Flag a release risk in the test summary, in plain words
- Ask for a clearer acceptance criterion before testing
- Stop a test run that would touch data outside the agreed environment
The tester never
- Approves or blocks a release on its own; your engineering lead decides go or no-go
- Tests against production data or real customer accounts without your written rules
- Runs security scans, penetration tests or load tests against your systems
- States that the product meets SOC 2, PCI DSS, an accessibility standard or any other certification
- Changes code outside the test suite, or merges to your main branch
- Closes a bug as "won't fix"; that is a product decision
Buying the right level
The rate range is wide because the role is three different seats. Buy the level of the work you will hand over in the first 60 days, not the level of the title on a CV.
| Level | Rate | 80 h / month | 160 h / month | Typical work |
|---|---|---|---|---|
| Manual tester | $8.50–$11/hr | $680–$880 | $1,360–$1,760 | Runs existing cases and checklists, regression, browser and device checks, bug reports, fix verification |
| Test-plan and test-case writer | $11–$14/hr | $880–$1,120 | $1,760–$2,240 | All of the above, plus test plans, cases from stories, exploratory charters, UAT scripts, test summaries |
| Automation and API tester | $14–$16/hr | $1,120–$1,280 | $2,240–$2,560 | All of the above, plus upkeep of an existing automated suite and API collections |
Three questions place you. No written test cases yet? Start at the middle level, because the first job is writing them. An automated suite that fails and nobody fixes? The top level, if you name the framework. Nobody has time to click through before release? A manual tester with your checklist.
What none of these levels is: a QA lead who sets your quality strategy, picks your tools and designs an automation framework. If you need that, hire it as a separate engineering seat; the tester then works to that person's plan. See dedicated development team companies for providers that place engineers.
A statement of work you can copy
Fill in the brackets and attach it to the request and the agreement.
Role: QA tester (remote), level [manual / test-plan writer / automation and API], for [company name], testing [web app / mobile app / store / client sites / internal tools], release cadence [weekly / every two weeks / monthly].
Hours: [80 / 160] hours a month, [days and hours], [time zone], with at least [N] hours of overlap with the development team's working day.
Systems: [bug tracker], [test management tool or sheet], [staging URLs and build source], [device cloud], [API tool], [automation repository, read and branch access], [team chat].
Work packages in scope: [test cases, manual functional testing, regression, exploratory sessions, browsers and devices, bug reports, fix verification, test data, release checklist and test summary, API checks, automated test upkeep, UAT scripts].
Out of scope: release approval, production testing outside the written list, security or penetration testing, load testing, compliance or accessibility certification, framework design, changes to product code, merging to the main branch.
Environments and data: testing only in [environments] with test accounts we create; no real customer data unless masked by our rules; payments only in the provider's test mode.
Deliverables: bug reports to our template; a test summary for every release; an end-of-day note (what was tested, what is blocked, what needs an answer); a weekly report on the service levels.
Commercials: hourly rate, monthly billing in arrears for hours worked, 30-day trial, notice period, replacement terms.
Engagement models compared
| Criterion | In-house QA tester | Developers test their own work | Crowdtesting or project-based QA firm | Dedicated QA VA |
|---|---|---|---|---|
| Cost model | Salary plus payroll costs and benefits | No invoice; paid in development hours | Per test cycle, per bug or per project, set by each provider | Flat $8.50–$16/hr by level |
| Knows your product over time | Yes | Yes, but tests what they expect to work | Varies; testers often change between cycles | Yes, one person on your product |
| Available every sprint | Yes | When time allows | When booked | Yes, on agreed hours |
| Writes and keeps test cases | Yes | Rarely | Sometimes, for the project | Yes, at the middle and top level |
| If it isn't a fit | Recruit again | - | Change provider | Replaced at no extra cost |
| Best for | Large teams with a QA lead | Very early products | One-off launches and device coverage | Steady releases that need the same checks every time |
The models combine: a dedicated tester for every sprint, a crowdtesting cycle for a big launch. For the wider choice between one dedicated person and a managed team, see dedicated team vs staff augmentation; if you are weighing a full IT provider, the IT outsourcing companies drawer compares them.
Total cost of ownership: in-house tester vs QA VA
| Line item (per year, full-time) | US software QA analyst or tester | Dedicated QA VA |
|---|---|---|
| Pay or hourly fees | $104,300 median (about $50 an hour) | $16,320–$30,720 (160 hours × 12 months at $8.50–$16) |
| Employer payroll taxes | About $7,979 (7.65% FICA), plus state and federal unemployment | None for you |
| Pay plus FICA | About $112,279 before benefits | $16,320–$30,720 |
| Benefits | Commonly about 30% of total compensation in US private industry | None for you |
| Computer and test devices | You provide | The VA's own computer; budget a device cloud seat if you need many devices |
| Recruiting | Job ads and interview hours | No recruitment fee |
| Bug tracker, test tool and device cloud licences | The same either way, paid to those vendors | |
Read the comparison fairly. The BLS group includes QA analysts who plan strategy and build automation, so the median is not the price of a manual tester. For many teams the real comparison is the developer hours spent clicking through flows before each release. A part-time seat (80 hours a month) costs $680–$1,280 a month, or $8,160–$15,360 a year, and moves that checking off your engineers' calendar.
Sizing the seat from a sprint tally
Don't guess the hours. For two normal sprints, note every testing task from the work packages and the minutes it takes, or would take if done properly. The example below shows the arithmetic for a team shipping one web app every two weeks with a companion mobile app; the inputs are illustrations, not benchmarks.
| Item (example inputs) | Per month | Minutes each | Hours a month |
|---|---|---|---|
| New stories needing test cases | 16 | 60 | 16 |
| Stories tested on a build | 16 | 45 | 12 |
| Regression runs (web, before each release) | 2 | 480 | 16 |
| Regression runs (mobile, two platforms) | 2 | 360 | 12 |
| Exploratory sessions | 8 | 90 | 12 |
| Bug reports filed | 40 | 15 | 10 |
| Fixes re-tested | 35 | 10 | About 6 |
| Test data set-up and resets | 8 | 45 | 6 |
| Post-deploy checks and test summaries | 2 | 120 | 4 |
| Stand-ups, sprint meetings and the end-of-day note | 21 days | 30 | About 11 |
| Seat to buy | About 105 hours plus a margin you set for hotfixes and release weeks: start at 80 hours if regression is the main job, 160 if you want case writing and exploratory work too | ||
As a starting point: a team releasing monthly with one product often begins at 80 hours. Teams releasing every week or supporting web and mobile usually fill a full-time seat.
Environments, accounts and test data
A tester needs room to break things. The single most useful thing you can prepare is a staging or test environment that looks like production, with test accounts you create for each role in your app. Agree these controls before access starts.
Require
- A named login in every tool, with the lowest permissions the packages need
- Test accounts for each user role, created and owned by your team
- Masked or made-up data in test environments; real customer records only under your written masking rules
- Payments only in your payment provider's test mode, with its test cards
- A written list of any checks that must run in production, the accounts to use, and who approves
- A signed confidentiality agreement covering code, builds, data and roadmaps
- Access removed the same day the engagement ends
Refuse
- Shared admin logins or a developer's personal account
- Testing in production because staging isn't ready
- Customer exports copied into spreadsheets for "test data"
- Builds, logs or screenshots with customer data in personal email, chat apps or drives
- Write access to the main branch or deployment pipeline
- Providers who say their testers "handle security" or "certify compliance" for you
At the top level, repository access is a branch and pull requests your engineers review, with no merge rights.
The bug report standard
A bug report is the tester's main deliverable, so define it before day one and make it the acceptance criterion for the work. A report your developers can't reproduce costs them time instead of saving it. Put these fields into your tracker's template:
| Field | What good looks like |
|---|---|
| Title | Where and what: "Checkout: discount code accepted twice on the same order" |
| Environment | Build or version, environment URL, browser or device and OS, test account used |
| Steps | Numbered, from a stated starting point, short enough to follow without asking |
| Expected and actual | What the story or spec says should happen, and what happened |
| Evidence | Screenshot, a short recording, console or network log where relevant |
| Severity (proposed) | From your written scale; your team sets the final priority |
| Frequency | Every time, sometimes (with the count tried), or once |
| Links | The story, the test case and any related bug |
Write the severity scale in four lines (for example: blocks a core flow; breaks a feature with a workaround; cosmetic; question) with one example of each from your own tracker.
Service levels and KPIs to put in writing
Measure for 30 days, then set targets from your own numbers, using the tracker and tools you already have.
| Area | Measure | Data source | Review |
|---|---|---|---|
| Regression | Regression run finished within the agreed time after a release candidate arrives | Test management tool | Each release |
| Bug report quality | Share of reports developers reproduce on the first try, from a monthly sample | Tracker comments, spot checks | Monthly |
| Fix verification | Fixed bugs re-tested within the agreed time of reaching a test build | Tracker | Weekly |
| Coverage of new work | New stories with test cases before the sprint review | Test management tool | Each sprint |
| Release summary | A test summary for every release: run, passed, failed, not tested, open bugs | Wiki or tracker | Each release |
| Escaped bugs | Every bug reported by users reviewed: was there a case for it, and should there be? | Tracker | Monthly |
| Automated suite | Failing tests triaged within the agreed time; flaky tests listed with a fix plan | CI results | Weekly |
Avoid two targets that work badly. A bug-count target rewards splitting one problem into five tickets. "Zero bugs in production" makes the tester answerable for code and release decisions they don't control. Review escaped bugs one by one instead.
Vendor questionnaire: fourteen questions
People
- Does the tester work only for my company?
- What software testing experience will candidates have: products, platforms, tracker and test tools?
- Are candidates tested on testing tasks (a bug report on a live app, test cases from a spec, triage) before I meet them?
- Do I interview and choose?
Price and terms
- Which level is this candidate priced at, and what moves the rate within $8.50–$16?
- Are there recruitment or setup fees? Is there an advance payment, and is it refundable?
- What is the trial period, the notice period and the replacement policy?
- Can hours go up in release weeks, and how much notice do you need?
Access and boundaries
- Will the tester work only in my tools and environments, under a named login?
- What does the provider put in writing about confidentiality of code, builds and data?
- Does the provider confirm in writing that the tester approves no releases and makes no security or compliance claims?
Continuity
- What is the backup for internet and power outages during my release windows?
- How is cover arranged during the tester's leave and public holidays, when a release is due?
- If the tester leaves, how fast is a replacement shortlisted, and who hands over the test cases and notes?
Our outsourcing contract checklist covers the clauses behind these answers.
Scope by product type
The same title covers different seats. Place your product in one of these boxes before you request candidates: it decides which packages come first and which tools the tester must know.
Sprints and regression
Test cases from stories, regression before each release, roles and permissions, browser checks, API checks at the upper level. The most common seat, usually tied to a two-week sprint.
Builds and devices
Beta builds on iOS and Android, a device list you set, install and upgrade paths, offline and notification behaviour, store-release checklists. A device cloud subscription usually pays for itself here.
Checkout and catalog
Checkout in test mode, discount and shipping rules, product pages after theme or app updates, email and order flows. Overlaps with the e-commerce outsourcing drawer for wider store operations.
Your procedures, your auditors
Health, finance or payments products can use the same seat to execute test scripts and keep evidence under your quality procedures. Conformance and certification stay with your quality lead and auditor.
Tools the seat works in
Candidates can be matched to the tools you run. Name them in the request; the provider can put a task in your own tool or a sandbox into the test.
| Tool type | Examples | What the tester does there |
|---|---|---|
| Bug and work tracking | Jira, Linear, ClickUp, Azure DevOps, Asana | Bug reports, links to stories, status updates, fix verification |
| Test management | TestRail, Zephyr Scale, Xray, Qase, or a shared sheet | Test cases, runs, results and release summaries |
| Browsers and devices | BrowserStack, LambdaTest, Chrome DevTools, Xcode Simulator, Android Studio emulators, TestFlight | Checks on your browser and device list; beta builds |
| API testing | Postman, Insomnia, Swagger or OpenAPI docs | Runs and extends collections against documented endpoints |
| Test automation | Selenium, Cypress, Playwright, Appium | Runs, triages and maintains the existing suite on a branch |
Acceptance test before you choose
Many CVs say "testing" for someone who once clicked through their own project. Ask each shortlisted candidate for a short work sample on your staging app or a public demo app:
- Bug hunt: 30 minutes on one flow, then two bug reports in your template, with a recording.
- Test cases: from a short story with acceptance criteria, write cases that cover the happy path, invalid inputs and limits.
- Triage: given ten vague bug reports, propose a severity for each and list what information is missing.
- The line: answer a product manager who asks "are we good to release?" The right answer gives the test summary and leaves the decision with the lead.
- Tool check (top level): run a Postman collection or fix one failing test in a small sample suite, and explain the change.
Score clarity, coverage and accuracy.
Onboarding plan: 30, 60, 90 days
- Week 1, access and the product tour: named logins, test accounts per role, staging access; the bug template, severity scale and boundary list read and signed; a recorded walkthrough of the core flows by your product owner or a developer.
- Weeks 2–4, regression and bug reports: the tester runs your existing checklist or writes a first regression set for the main flows; a developer reviews every bug report for the first two weeks, then samples.
- Day 30 review: baseline numbers for the service levels; the seat size checked against the sprint tally; decide which package comes next.
- Days 31–60, new work: test cases written for each new story; exploratory sessions on changed features; the test summary for every release.
- Days 61–90, full scope: API checks and automated test upkeep where bought; browser and device matrix; targets written into the agreement from the baseline.
Risk register
| Risk | Control | Owner |
|---|---|---|
| A test run is read as release approval | Test summary lists "not tested" items; go or no-go recorded by the lead | Engineering lead |
| Customer data ends up in a test environment or a bug report | Masking rules; test accounts only; evidence screenshots checked for personal data | Engineering lead |
| A test touches production by mistake | Separate URLs and accounts; production checks only from the written list | Engineering lead |
| Regression set grows until it can't finish | Set ordered by risk; quarterly trim agreed with the product owner | Product owner |
| Automated suite drifts and gets ignored | Failures triaged on a schedule; flaky tests listed and fixed or removed | Engineering lead |
Exit and handover
All work stays in your tracker, test tool, repository and wiki, so nothing has to be handed back. At the end of an engagement, ask for a final handover note (open bugs waiting for verification, the state of the regression set, known flaky tests, test accounts and data in use), remove access the same day and rotate any shared test credentials.
Requesting candidates
Requests sent through this site go to our recruiting partner, a managed VA agency:
- Send the scope: product type, stack, release cadence, tools, level and hours, using the statement of work above if it helps.
- Review the shortlist: candidates with software testing experience, screened and tested, usually in about 2 business days.
- Interview and choose: nothing is paid before you choose; billing is monthly in arrears for hours worked; a tester who isn't a fit is replaced at no extra cost.
The trade-offs: an agency costs more per hour than a freelancer you recruit yourself, in exchange for screening and replacement; the first month needs a developer's review time and a working staging environment; after the 30-day trial a notice period applies. If what you need is engineers rather than testing, the dedicated development team drawer lists providers scored on published prices and terms.
FAQ
What does a QA testing virtual assistant do?
Day-to-day software testing inside your own tools: writing test cases from user stories, running manual functional and regression tests on each build, exploratory sessions on new features, cross-browser and device checks, bug reports with steps, screenshots and recordings, re-testing fixes, preparing test data, running the release checklist and, at the upper level, API checks and upkeep of the automated tests you already have. Your engineering lead keeps the release decision.
How much does a QA testing VA cost?
Through our recruiting partner, $8.50–$16 an hour by level: manual testers $8.50–$11, testers who write test plans and cases $11–$14, automation and API testers $14–$16. That is $680–$1,280 a month for 80 hours or $1,360–$2,560 full-time (160 hours), billed monthly in arrears for hours worked, with no recruitment or setup fee.
Is a QA VA cheaper than an in-house QA tester?
Per year, yes, though the roles differ. The US Bureau of Labor Statistics put the median pay of software quality assurance analysts and testers at $104,300 a year in May 2025 (about $50 an hour), before payroll taxes and benefits. A full-time remote tester costs $16,320–$30,720 a year at $8.50–$16 an hour. A QA lead who designs your strategy is a different, more senior seat.
Which level of QA tester should I buy?
Buy the level of the work, not of the title. If you have test cases or can describe the flows, a manual tester runs them. If nobody writes test cases today, buy a tester who writes plans and cases. Buy the automation and API level only if you already have an automated suite or API collections that need upkeep, and say which framework.
Can a QA VA sign off a release?
No. The tester reports what was run, what passed, what failed and what was not tested, against your release checklist. Your engineering lead or product owner decides go or no-go. Put this in the statement of work so nobody reads a green test run as approval.
Can a QA VA build a test automation framework?
Treat that as a separate engineering hire. At the top of the range, testers maintain and extend existing suites in tools such as Selenium, Cypress or Playwright, fix broken selectors, add cases to the pattern your engineers set and run API collections in Postman. Choosing and building a framework stays with your engineers.
Can the tester use production data or real customer accounts?
Only under written rules you set. By default the tester works in staging or a test environment, with test accounts you create, masked or made-up data, and your payment provider's test mode instead of real cards. If some checks must run in production, list them, name the accounts and say who approves.
Does a QA VA do security or penetration testing?
No. Security testing, penetration testing and vulnerability scanning belong to qualified security specialists you hire for that. The tester reports anything that looks wrong, such as a page showing another user's data, as a bug for your engineers, and makes no security claims.
Can a QA VA confirm we meet SOC 2, PCI or accessibility standards?
No. The tester can run checklists you provide, for example keyboard navigation or form labels, and log what fails. Whether a product meets SOC 2, PCI DSS or an accessibility standard is decided by your auditor or assessor, not by the tester or the provider.
How do I measure an outsourced QA tester?
On things the tester controls: regression runs finished within the agreed time after a build arrives, bug reports your developers can reproduce on the first try, fixes re-tested within the agreed time, new stories covered by test cases before the sprint ends and a written test summary for every release. Count bugs that reached users and review each one, without a target on bug counts.
How long does it take to get a QA VA working?
First candidates usually arrive in about 2 business days. Plan about 30 days to regression and bug reports on your main product under review, 60 days to test-case writing and exploratory sessions on new features, and 90 days to full scope. With our recruiting partner you can end the engagement immediately during the first 30 days; after that a notice period applies, and a tester who isn't a fit is replaced at no extra cost.