What a new QA team needs from you in week one
Short answer
An outside QA team can start finding real bugs within days if it has five things: signed paperwork, access to a test environment, one test account per user role, a way to reset test data, and a clear first priority. Repository access, app builds and your existing test cases and bug history speed things up further. What slows a start is never the testing; it is waiting for access.
This is the checklist we send after a kickoff call, written for the product lead or CTO on the client side. It is based on the first weeks of real engagements, including ones that started against a release deadline only a few days away.
Paperwork first, in the right order
Three documents, usually in this order. The NDA comes first because it unlocks everything else: once it is signed, the testing team can see your environments, requirements and bug history while the commercial documents are still being agreed.
- NDA. Lets you share access and documentation safely. Sign it before the second call if you can.
- Master services agreement (MSA). The general terms: confidentiality, ownership of the work, liability, how the engagement ends.
- Statement of work (SOW). What this engagement covers: scope, team, timeline, deliverables and cost.
Agree in the MSA that test cases, automated tests and bug reports belong to you and live in your tools. It costs nothing to agree on day one and is hard to negotiate later. Our guide to what your QA vendor should leave behind covers the clauses worth asking for.
Access: the checklist
| What | Why it matters | Common snag |
|---|---|---|
| A staging or test environment | Testing in production risks real data and real customers | Staging is behind production, so bugs found there are already fixed, or missing |
| One test account per user role | Most serious bugs sit in what one role can see or do that another cannot | Only an admin account is provided, so every permission bug is invisible |
| A way to reset test data | Many flows can only be walked once per account: onboarding, a first purchase, a free trial | No reset exists, so testers run out of fresh accounts on day two |
| Builds for mobile apps | Testers need to install the app on many screen sizes | Only store builds exist; simulator and emulator builds (IPA and APK) were never set up |
| Bug tracker access | Bugs land where your developers already work | Testers get read access and cannot file tickets |
| Requirements and docs | Testers check behaviour against what was intended | Nothing is written down, which is common and fine if someone can answer questions |
| Repository access, after the NDA | Enables static code analysis and dependency scanning, and local builds | Only needed for security work and builds; plan it rather than block on it |
Two tricks that save days. If a flow includes a purchase, a 100% discount code lets testers buy as many times as they need without real payments. And most email systems accept plus addressing, so [email protected], [email protected] and so on all reach one inbox while counting as separate accounts. Together they turn "we cannot reset that account" into "we create a fresh customer in a minute".
Agree how you will talk
It sounds trivial and causes real delays. If you use Microsoft Teams and the testing team uses Slack, someone has to be a guest in the other's workspace, and guest accounts often need IT approval. Decide in the kickoff call:
- Which chat tool, and who creates the accounts.
- One named contact on your side who can answer "is this a bug or intended?" within the day.
- Where bugs go first. A common pattern is that the testing team files into its own system for the first days, you see how the reports look, then they flow straight into your Jira or Azure DevOps.
- A short daily or twice-weekly check-in for the first two weeks.
Give the first week one priority
The most useful thing you can tell a new QA team is what must be true by a date. "Audit everything" in week one produces a long list in no particular order. "Checkout must be safe to release on Friday" produces a focused test plan and an answer you can take to your board.
A good first priority is usually the flow behind the current deadline, or the flow that customers complain about. Send whatever already exists for it: test cases, recent bug reports, support tickets. The testing team extends them, finds the gaps, and agrees with you which findings must be fixed before release and which go to the backlog.
If you are not sure how much testing you need overall, our guide on how much QA you need helps size it.
What to expect in the first week
With tooling in the mix, findings arrive in two waves, and it helps to know that in advance.
The first wave is wide. Automated checks for functionality, accessibility and security run early and produce a batch of tickets with clear reproduction steps. It can feel like a lot. Most teams are better off seeing it now than hearing about it from a customer.
The second wave is deep, and it comes from people. Tools only check what is there. A registration form missing its "confirm password" field passes every automated check, because nothing tells a tool that the field should exist. A tester who has registered on a hundred products notices at once. These findings grow as the testers learn your product, which is why the same people should stay on it.
By the end of week one you should have: the priority flow tested, a list of findings ranked with you, and a plan for weeks two to four. If the engagement started as a trial, our guide on what a QA trial should prove covers how to judge it.
Frequently asked questions
Starting with an outside QA team?
Send us your deadline and the flow that worries you most. We will tell you what we need and start within days of the NDA.
Book a call QA outsourcingNeed 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.
