Onboarding a QA vendor: the first 30 days

Updated 2026-09-24

Onboard an outsourced QA team in four stages over roughly a month: access and tools in week one, product context and a test strategy draft in week two, a first test cycle the vendor owns in week three, and a first report and review in week four. Agree the plan and its checkpoints before the start date, and judge progress on outputs you can see, such as tests running in your pipeline and defects written to your standard.

What to check

  1. Ask for the vendor's 30-day onboarding plan before signature and attach it to the statement of work.
  2. Prepare accounts, repository access and environments before day one so the team is not idle.
  3. Name one person on your side who owns the onboarding and answers product questions.
  4. Check that the people who start are the people named in the proposal.
  5. Review the first ten defect reports yourself for clarity, reproducibility and severity.
  6. Hold a review at the end of week four against the agreed checkpoints, and record what changes.

Ask the vendor

  • In your first 30 days on our account, what will you produce and how will we know onboarding has worked?
  • What test environments and access do you need from us, and by when?
  • Who is the single accountable lead on your side, and how much of their time is allocated to us?
  • How will your testers work inside our team day to day: which meetings do they attend and whose backlog do they work from?

Why the first month decides a lot

The first month of an outsourced QA engagement sets habits that are hard to change later: where the team takes its questions, how defects are written, which meetings they attend, and whether they work in your tools or their own. It is also the point at which you find out whether the team you evaluated is the team you got.

The framework scores onboarding as a criterion in its own right. A strong vendor can tell you before signature what it will produce in the first 30 days. Ask for that plan, attach it to the statement of work, and use it as the checklist below.

Before day one

Most slow starts are caused on the buyer side: accounts not created, environments not ready, nobody available to answer questions. Prepare:

  • named accounts in your source control, issue tracker, test management and chat tools;
  • access to at least one stable test environment and a way to reset its data;
  • product documentation, recent release notes and a list of known risk areas;
  • one internal owner for the onboarding who can answer product questions or route them quickly.

If testers need personal data to work, settle the data processing terms first. Test data and GDPR covers what that involves.

Week one: access and tools

The goal of week one is that every team member can do the basic mechanics of the job in your environment. By the end of the week, each tester should be able to log in, run the product, file a defect in your tracker in your format, and run any existing automated tests in your pipeline.

Check who actually started. Compare names against the proposal and the key personnel list.

Week two: product context and strategy

Week two is about understanding what matters. Run walkthroughs of the main user journeys, share the release plan, and explain where defects have hurt you before. Ask the vendor for a draft test strategy: what they would test first, what they would leave out, and how they will report. ISO/IEC/IEEE 29119-3 describes what test plans and strategies typically contain; use it as a reference for what to look for, not a template to impose.

A good sign in week two is questions. A team that asks about your customers, your release process and your past incidents is building a risk picture. A team that asks only for test cases to execute is not.

Week three: first owned test cycle

Give the vendor one release or feature to test end to end. It plans the testing, runs it, writes defects and decides what it would sign off. You watch, answer questions, and review the output.

Review the first defect reports yourself. Each should say what happened, what was expected, how to reproduce it, and on what build and environment. Severity should match your definitions, not the vendor's defaults.

Week four: first report and review

The vendor delivers its first test report in the format you agreed. A useful report shows what was tested, what was not, what failed, and what risk remains, not only counts of test cases run. Then hold an onboarding review with the vendor lead.

Checkpoint On track Needs attention
Team Named people started and are allocated as agreed Substitutions or part-time allocation not agreed
Access All tools and environments in use Team still waiting on access or working in its own tools
Strategy Draft reviewed, risk areas agreed No written strategy yet
First cycle Completed, defects clear and reproducible Cycle incomplete, defects need rewriting
Report Shows coverage, gaps and risk Lists activity counts only
Communication Questions come early and to the right person Blockers surface only in the weekly call

Record what changes after the review, with owners and dates. If several rows need attention, say so plainly and agree a short recovery plan. A month is enough to see a pattern.

After the first month

From here, the engagement moves into steady running. Managing an outsourced QA team covers the rituals and roles that keep it aligned, and KPIs for an outsourced QA vendor covers what to measure. Where onboarding sits in the whole process is shown on the selection path. If you are still selecting, score onboarding plans side by side on the scorecard.

Tools for this

Questions buyers ask

How long should a QA vendor take to become productive?
It depends on product complexity and how ready your environments are. A reasonable expectation is a first owned test cycle within the first month. If the vendor cannot say what it will deliver by then, treat that as a planning gap.
Should we pay for onboarding time?
Usually yes, since the team is working. What you should avoid is open-ended onboarding. Tie the onboarding period to the checkpoints in this guide and agree what happens if they slip.
What if the people who start are not the people in the proposal?
Raise it on day one. If the contract lists key personnel, a substitution needs your approval. If it does not, ask for CVs of the new people and decide whether to continue.

Sources

  1. Digital Services Playbook, US Digital Service
  2. The Sourcing and Consultancy Playbooks, UK Cabinet Office
  3. ISO/IEC/IEEE 29119-3:2021 Software testing, Part 3: Test documentation, ISO/IEC/IEEE
  4. Model Services Contract, UK Cabinet Office