# Could your software test history be licensed for AI?

> Map software test cases, bug investigations, expected results, and regression history before exploring data licensing. Keep test fixtures and customer data separate.

Canonical: https://origindatapartners.com/blog/license-software-test-history
By: Origin Data Partners
Status: Published
Published: 2026-09-15
Updated: 2026-09-15
Sources checked: 2026-09-15

## Quick answer

A software company can explore whether its retained test cases, bug investigations, and regression history are relevant to an AI-data licensing discussion. Describe how those records connect and what context remains. Test counts, pass rates, and owning the product do not establish permission, a licensing offer, or a price.

## Key points

- A written test case, its execution result, and the data used to run it are different records.
- Version and outcome context help explain what a test actually checked.
- Keep source code, production extracts and security-sensitive cases outside an initial company overview.

## What does a test history contain?

A list of test names says little about why a test exists. A more useful description identifies the requirement, the expected behavior, the product version, what happened in a run, and the follow-up. Your team may retain only some of that chain.

Microsoft distinguishes plans, suites, cases, shared steps and parameters in its test documentation. Its traceability guidance explains links among work items, changes, builds and releases. Those distinctions help describe existing records; they do not establish licensing eligibility.

Source: [Microsoft Learn: test objects and terms](https://learn.microsoft.com/en-us/azure/devops/test/test-objects-overview?view=azure-devops)

## A fictional regression, from question to retest

A fictional scheduling-software company changes how an overnight job is displayed across time zones. A test expects the job to retain its original local date. One release fails that case, an investigation identifies the conversion rule, and a later build passes the retest.

This invented example illustrates a record chain, not a licensed dataset or client result. A company could describe the chain without sharing the schedule, the test script, an employee name, or a screenshot.

| Record | What it explains | Question for the team |
| --- | --- | --- |
| Requirement or decision | The intended behavior | Does the original version remain? |
| Test case | The steps and expected result | Is this a reusable case or a customer-specific scenario? |
| Execution result | What happened on a particular build | Can the build and environment be identified internally? |
| Bug and resolution note | Why behavior changed | Are the issue and fix still linked? |
| Retest | Whether the chosen check later passed | Is the result recorded or merely remembered? |


## Keep test fixtures separate from the test description

A test fixture is the input used for a check. It might be invented, supplied by a vendor, created from production records, or assembled from several sources. Calling it “test data” does not answer where it came from or what uses are permitted.

Inventory fixture provenance as a question. Do not copy customer records, credentials, private endpoints or vulnerability details into a worksheet. A summary of expected behavior can be discussed before deciding whether any executable test, input file or screenshot belongs in a proposed scope.


## Include the inconvenient parts of the history

Identify deleted attachments, missing release identifiers, reruns, skipped cases, flaky tests, and changes in the test process. A passing result after a changed test is not necessarily the same observation as a passing result under the original check.

Start with one release or feature area. Ask your QA lead how many categories can be described reliably and which connections are uncertain. Do not turn an approximate record count into a completeness claim. Traceability is something to verify in your retained history.

Source: [Microsoft Learn: end-to-end traceability](https://learn.microsoft.com/en-us/azure/devops/cross-service/end-to-end-traceability?view=azure-devops)

## Questions before any record sharing

Who authored the cases and scripts? Which scenarios came from customers? Do contractor or vendor materials appear? Who can review the proposed purpose, recipient and handling? These questions belong in the company review before a request for files is accepted.

Use the [blank inventory](https://origindatapartners.com/blog/company-data-inventory-template) for categories and the [workflow map](https://origindatapartners.com/blog/map-company-workflows-without-exporting-records) for connections. An initial Origin conversation can start with those broad descriptions and your open questions.


## Questions and answers

### Do we have to include our source code?

You can describe test and resolution history separately from source code. A proposed recipient would still need to assess the usefulness of that narrower scope; excluding code does not establish permission to share the remaining material.

### Are generated tests automatically suitable for licensing?

No. Record how they were created, which inputs and tools were involved, whether they were reviewed, and what execution history exists. Generation alone does not establish usefulness or rights.

### Do more test cases mean a higher licensing value?

No standard value follows from the count. Context, duplication, retained outcomes, permitted use, preparation work and the terms of any actual proposal would need review.

## Sources

- [Microsoft Learn: test objects and terms](https://learn.microsoft.com/en-us/azure/devops/test/test-objects-overview?view=azure-devops)
- [Microsoft Learn: end-to-end traceability](https://learn.microsoft.com/en-us/azure/devops/cross-service/end-to-end-traceability?view=azure-devops)
- [U.S. Copyright Office: what copyright protects](https://www.copyright.gov/help/faq/faq-protect.html)

## Related reading

- [/blog/license-software-implementation-history](https://origindatapartners.com/blog/license-software-implementation-history)
- [/blog/license-support-tickets-for-ai](https://origindatapartners.com/blog/license-support-tickets-for-ai)
- [/blog/license-software-incident-reviews](https://origindatapartners.com/blog/license-software-incident-reviews)
- [How much is your company data worth?](https://origindatapartners.com/guides/company-data-value)