What your QA vendor should leave behind: how to avoid lock-in
Buyers of outsourced testing are asking a new question before they sign, and it is a good one. Not "how good are you", but "what do I keep when we stop working together?" The answer they want is simple: nothing should be sticky. The test cases, the automation, the bug history and the reports should already sit in your repository, your Jira and your tools, in formats you can open without the vendor in the room.
This guide is for the CTO, product owner or founder about to hire a QA team. It covers what should stay with you, how to check each item before you sign, the contract clauses worth asking for, and the red flags that tell you an exit will be expensive.
Why lock-in matters more in QA than people expect
Testing builds up an asset quietly. Every month a QA team writes test cases, automates the important journeys, files bugs with steps and evidence, and learns where your product breaks. After a year, that body of work is a large part of what you paid for. The people matter, but the people can change. The asset should not walk out with them.
Lock-in rarely comes from bad intent. It usually comes from convenience. A vendor uses its own platform because it is faster for its team, the tests get written in a format only that platform runs, the bug history lives in the vendor's tracker, and nobody notices until the contract is up for renewal. At that point leaving means starting from zero, and staying is the cheaper choice even if you are not happy. That is exactly the position you want to avoid being in.
So the useful test is not whether a vendor has good tools. It is whether you could stop working with them on a Friday and have your own team, or another vendor, run everything on Monday.
Can you run the automated tests without the vendor?
This is the item with the most money behind it, and the easiest one to check. Automated tests should be written in, or exported to, a standard open framework such as Playwright or Cypress. They should live in your repository, next to your code, and run in your own CI pipeline. If a test only runs when the vendor presses a button on its own platform, you do not own a test suite. You own access to one.
Before you sign, ask the vendor to show you an exported test from a demo project and run it yourself, outside their environment. The Playwright documentation on running tests in CI is a good reference for what a normal setup looks like. A developer on your team should be able to read the exported code, understand what it checks and change it without training on a proprietary tool.
A few details worth asking about:
- Test data and fixtures. Are they in the repository too, or do they live on the vendor's side?
- Secrets. Credentials should come from your own secret store, not one the vendor controls.
- Maintenance features. If the vendor's tooling repairs tests when the interface changes, ask what the exported code looks like afterwards. The repair should land in plain code you keep, not in a layer you lose when you leave.
Our test automation service page describes how we set this up from the start.
Where should test cases, bugs and reports live?
In your tools, from day one. Test cases and bug reports belong in the tracker your developers already use, whether that is Jira or Azure DevOps. If a vendor works in its own system, that is fine as long as everything is pushed into yours as it happens, not handed over in a zip file at the end.
The bug history is worth more than it looks. It tells the next team which areas break often, which fixes came back, and which defects were closed as intended behaviour and why. Lose it and the next team relearns those lessons the expensive way, from your users.
Where something does live in the vendor's tool, there should be an export in a standard format such as CSV, and you should test that export before you sign rather than discover its gaps at the end. Then the paperwork. Test plans, test strategy, environment notes, the list of accounts and roles used for testing, and any risk analysis should be documents you hold, in a shared space you control. A useful check: ask who could rebuild the regression suite from the documents alone. If the honest answer is "only the vendor", the knowledge is sitting in the wrong place.
What happens to your data and to generated work?
Many QA vendors now use tools that generate test cases or draft bug reports from screenshots, recordings and requirements. That can save time. It also raises two questions buyers should ask directly.
The first is whether your data is used to train anything. Your requirements, screenshots and bug reports describe your product, often before it is public. They should not end up improving a model that serves other customers. Ask for this in writing, not as a sales answer.
The second is whether a human approves what gets generated. A generated test case that nobody reviewed is a guess with good formatting. Ask who signs off on generated work before it counts, and whether generated and reviewed items are marked differently. When you take the suite over, you want to know which parts a person has actually checked.
When the engagement ends, ask what is deleted on the vendor's side, by when, and how you will be told it is done.
Which contract clauses should you ask for?
Most of this can be settled in a few lines of the contract. These are the clauses we would want if we were the buyer:
- Ownership. Everything produced for you, including test code, test cases, bug reports and documentation, belongs to you.
- Location. Work is kept in your repository and your tracker as it is produced, not only at the end.
- Export. Anything held in vendor tools can be exported in standard formats at any time, at no extra cost.
- Notice period. A clear, reasonable notice period, with the team still working through it.
- Handover. A defined handover at the end: a walkthrough of the suite, open risks, and a session with whoever takes over.
- No trailing licences. Nothing you have to keep paying for after you leave in order to run your own tests.
And the red flags. Be careful if tests only run on the vendor's platform, if the export is described as "available on request", if the bug history sits only in the vendor's tracker, or if the commercial model includes a tool licence that outlives the service. None of these is proof of bad faith. All of them make leaving harder, and you will pay for that later. If you want to see how a vendor handles these questions in practice, a short trial is the place to test it. Our guide on what a QA trial should prove covers what else to check in those weeks.
How BetterQA handles ownership
We work in your tools: your Jira, your repository, your CI. What we build for you belongs to you. We built our own QA tools because they make our engineers faster, and they come with every engagement at no extra licence cost, but none of them is a place your work gets stuck.
Flows records browser actions and turns them into test scripts that repair themselves when the interface changes. It exports to Playwright or Cypress, so the suite runs in your own pipeline without us. BugBoard turns screenshots, recordings and requirements into bug reports and test cases, pushes them to Jira or Azure DevOps, and exports CSV. Every generated test case and bug report goes through a human before it counts, and no AI training happens on our platforms, on anyone's data.
Whether we run the whole testing function as managed testing or work inside your team, the aim is the same: if you stop working with us, you keep everything and lose nothing but us.
Frequently asked questions
Ask us the hard questions first
Bring your list of ownership and exit questions to the first call. We will show you where the work lives and how you would take it with you.
Book a call See our servicesNeed 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.
