Who owns the test automation code a vendor writes

Why ownership of test code matters

A test automation suite is one of the few lasting assets an outsourced QA engagement produces. It encodes what your product is supposed to do, how to set up data for it, and which behaviour has broken before. If the vendor owns it, or you cannot run it without them, the suite becomes a switching cost. That is lock-in, and it is paid for with your money.

The UK government technology guidance used as a source for this framework makes the same point from the public sector side: avoid being locked into one supplier, prefer open standards, and make sure you can maintain what you buy. The questions below apply the same thinking to test code.

Foreground and background IP

Contracts usually separate two kinds of intellectual property.

Type	What it is in a QA engagement	What you should get
Foreground IP	Test code, page objects, fixtures, test cases, test data sets, test plans and reports written for you	Assignment to you on creation
Background IP	Libraries, frameworks, utilities and templates the vendor had before and reuses across clients	A perpetual, irrevocable, royalty-free licence to use, copy and modify as part of your suite, transferable to a replacement supplier

The weak point is usually the boundary. A vendor may describe a large part of the suite as its "accelerator" or "framework", which would put it in background IP. Ask for a list of background components before signature, and make the contract say that anything not on the list is foreground.

Why the assignment has to be in writing

US copyright rules explain that a work made for hire belongs to the commissioning party only in specific cases. Software written by an independent company generally falls outside those cases, so ownership moves to you through a written assignment. Other jurisdictions have their own rules, but the practical answer is the same: do not rely on payment or on an implied understanding. The framework's clause library includes wording along these lines:

All test code, automation frameworks built for [Customer], test cases, test data, test plans, reports and related documentation created under this Agreement ("Test Assets") are assigned to [Customer] on creation.

The contract clause builder generates this clause with its rationale, together with the background licence and the repository clause below.

Repository access from day one

Ownership on paper is not enough if the only copy of the code sits in the vendor's systems. The framework's repository clause asks that all test assets live in source control, test management and CI accounts owned and administered by you, and that the vendor never keeps the only copy of anything.

In practice:

• Create the repository in your organisation's account before kickoff.
• Give vendor engineers named accounts with access you can revoke.
• Run the suite in your pipeline, with secrets held in your secret store.
• Keep test management and defect data in your own tools, or confirm they can be exported in an open format at any time.

This also makes the code visible while it is written, so your engineers can review it early instead of discovering problems at exit.

Licences for anything left in your code

Check the dependency list. Any of these can stop you running the suite after the vendor leaves:

• A private package that installs only from the vendor's registry.
• A licence key or subscription billed through the vendor.
• A proprietary test runner or reporting service.
• Helper services hosted by the vendor, such as a data generator or device lab account.

For each one, the contract should either give you a licence that survives exit or require the vendor to replace it with something you control before handover. Open-source frameworks such as Playwright, Selenium, Cypress or Appium avoid most of this, which is one reason the framework scores open framework choice as a separate criterion.

Proving you can maintain it

The last test is practical. Ask one of your engineers, with no vendor help, to clone the repository, run the suite, and change one test. If that takes more than a short session, the gap is documentation or hidden dependencies, and it is cheaper to fix now than at exit. The framework's acceptance clause lets you make "runs in the customer's CI pipeline on a clean environment" a condition of accepting the automation deliverable.

For related contract terms see avoiding lock-in with vendor test automation and exit planning. Add the ownership questions to your questionnaire so every vendor answers them before you score.