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.
- 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.
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.
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 for categories and the workflow map for connections. An initial Origin conversation can start with those broad descriptions and your open questions.
Common questions
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.