Core concepts

TestLookup keeps several kinds of records apart: what your tests did, the test cases your team writes, the analysis of failures, and release decisions. They are related, but each has its own meaning. Knowing which record you are looking at helps you read the web app and the API correctly.

Projects, runs and test results

A project holds its own runs, tests and history, and decides who can see them. Three things affect your access: your project membership, your role, and the projects and actions an API key is allowed to reach.

A test run is one time your tests ran and sent results, either as an imported report or live while the tests ran. Inside a run, each test result is one execution of one test.

Written test cases versus test results

An authored test case is one your team writes and reviews in test management. A test result is one execution recorded in a run. One does not imply the other: a run can contain results for tests that have no written test case.

How the main records relate

Open the diagram full size

Relationships in this diagram, as text

1. PROJECT grants PROJECT_MEMBER (zero or more)
2. USER joins PROJECT_MEMBER (zero or more)
3. PROJECT contains TEST_RUN (zero or more)
4. TEST_RUN records TEST_CASE (zero or more)
5. TEST_CASE analyzed AI_ANALYSIS (zero or more)
6. PROJECT organizes TEST_SUITE (zero or more)
7. TEST_SUITE identifies CANONICAL_TEST_CASE (zero or more)
8. CANONICAL_TEST_CASE links TEST_CASE (zero or more)
9. PROJECT authors MANAGED_TEST_CASE (zero or more)
10. TEST_RUN investigated AGENT_PIPELINE_RUN (zero or more)
11. AGENT_PIPELINE_RUN records AGENT_STAGE_RESULT (zero or more)
12. PROJECT plans RELEASE (zero or more)
13. RELEASE evaluates RELEASE_GATE_DECISION (zero or more)

The diagram shows the main records only. The data dictionary lists every column, optional link and delete rule.

The diagram uses the database names. TEST_CASE is one test result in one run. CANONICAL_TEST_CASE is the lasting record that links the same test across all its runs. MANAGED_TEST_CASE is a test case your team writes, which moves through stages from draft to archived. TestLookup keeps these three apart in its counts and screens. A run can carry suite, CI, release and environment details even when none of its tests has a written test case.

TestLookup works out an ID from each test’s class and test name, called the test’s fingerprint. With it, TestLookup recognises the same test in every run. The code is in the import helpers and the import pipeline.

How TestLookup recognizes the same test

TestLookup keeps a lasting record for each suite and each test, so it can link the same test across runs.

A run’s identity also uses the CI details it arrives with, such as the CI run URL, the CI provider, the repository and the build. So two separate CI jobs that reuse the same build label do not merge into one run.

A JSON batch sent twice ends up in the same run, while every file upload creates a new run. The guide to sending results explains the difference.

Evidence, reports and review

Evidence is the results, logs and history behind a finding. Evidence and analysis feed reports, and a person’s review of a report is a separate decision. A finished analysis does not mean that anyone accepted the report.

Whether review is enforced is an installation setting, and it is off by default. The review policy explains the modes.

What TestLookup does

Collecting results. You can upload report files, post batches of results, let TestLookup pick up reports from file storage, or stream results live from a reporter library. Reading files, saving results and AI analysis all happen in the background. Lasting suite and test records link the same test across runs. CI details, the environment and the time each test ran make runs easier to compare and to link to a release.

Failure analysis. Rules, trained classifiers and configured AI language models all produce the same kind of analysis result. The standard analysis finds unusual results, sorts failures by kind and writes a summary. The deep investigation adds groups of related failures, follow-up investigations, specialist evidence, a risk assessment and a decision report. Each finding shows where it came from, how sure the analysis is and what evidence is missing. A finding is a likely cause, not a proven one.

People stay in charge. Each project’s agent settings and versioned workflow definitions limit what automated helpers may do. A person reviews AI reports, and separate rules control what leaves TestLookup. Release decisions, overrides, assignments, quarantined flaky tests and proposed actions all keep a record of who did what. Each installation chooses whether review is enforced, and it is off by default. In the default mode TestLookup only records what it would have held back, so a report that was sent out is not necessarily an approved one.

Test management. The test cases, plans and strategies your team writes are separate from the results your runs record. TestLookup can look up your own documents and draft test content from them, with on/off settings, a link to each source and a person’s review. The newer test-case lifecycle is controlled by the test_case_lifecycle_v2 flag, which ships on. The web app and the API offer only the status changes each case allows.

Sharing and access. People and tools reach TestLookup data in different ways: screens in the app, downloads, share links, notification subscriptions, Jira, GitHub, GitLab and MCP for AI assistants. Each integration must be set up and allowed by policy before it works. Single sign-on (SSO), automatic user setup from your company directory (SCIM) and project API keys are all available.

Run and release decisions

TestLookup makes decisions at two levels, and each one is separate from a run’s status, an analysis result and a report review:

• A single run gets GO, Conditional GO or NO-GO. The decision weighs the run’s results and pass rate, the project’s policy (or the defaults), and failure groups and flaky tests. The strictest signal wins. A QA lead or administrator can override a run’s decision with a written reason, and TestLookup keeps the record.
• A whole release gets GO, NO-GO or Not evaluated. The decision looks at the latest result of each test in the runs linked to the release, and at the release’s open defects and their severity. A release is Not evaluated when fewer than 5 tests have results, when a linked run rejected some of its results, or when open defects have no severity. At this version a release-level decision is never Conditional GO.

Steps that finish at different times

Several steps happen one after another, and each can finish at a different time: accepting an upload, reading the file, storing the run, finalizing it, analysing it and reviewing it. An accepted request (HTTP 202) only starts this work. It is not the final result of the import, the analysis or the release decision.

Continue with user workflows to see how these records move through a complete task.