Walkthrough with sample data
Accepting an AI report and deciding whether a release can ship are two different decisions. Step through both with made-up sample data, and see how each one keeps its own reasons and history.
Release managementTry it
State 1 of 6: Pending review — audit only
Nothing plays on its own, and nothing is uploaded or sent to TestLookup or any other service.
The report is waiting for review, and the review gate is on Audit only. Nothing is held back, and TestLookup only counts what it would have refused. The usual export and sharing permissions apply.
The buttons appear once the page has finished loading. All the steps are already written out below.
Step by step
Example with made-up data. Nothing on this page contacts a server.
Begin with a report that is waiting for review, while the review gate is on Audit only. Nothing is held back, and TestLookup hasn't worked out a release decision.
Switch the gate to Enforced. The release shows Pending review. A pending report could leave TestLookup only as a permitted draft, with a watermark and an entry in the audit log.
Accept the report. This settles the review and marks its AI analysis run as passed. It doesn't create a release decision.
Reject the report and give a reason. The AI analysis run is marked failed, and a rejected report can't be exported as a draft. The release decision stays separate.
Check a release with too few results: 2 tests have results, and TestLookup needs at least 5. The release is Not evaluated, which doesn't count as a success.
Check the release rules against the sample's test run. TestLookup records a Conditional GO for that run, with reasons, the rules version and what it covers. The history only grows.
Example with made-up data. Nothing on this page contacts a server.
Report review is a person’s decision about one AI-written report. A release decision is TestLookup’s verdict on a whole release, or on one phase of it. It’s based on the test results and other evidence in that release.
Accepting a report doesn’t make a release GO. A release decision doesn’t change the report’s review record. The reporting guide on GitHub describes both.
The walkthrough starts with a report that is waiting for review, while the review gate is on Audit only. Choose Accept report, then look at a decision as a separate step. Or choose Reject report to see that a rejected report can’t be exported as a draft.
Nothing is sent to TestLookup.
As in TestLookup, there are only two review decisions: accept and reject. There’s no “request revision”. The sample uses TestLookup’s review states: pending, accepted and rejected.
A fourth state, superseded, marks a review that a newer review request replaced. That happens, for example, after a new run or a changed report.
Accepting settles the review and marks the report’s AI analysis run as passed. It doesn’t create a release decision. In TestLookup, an accepted review also appears in the project’s activity feed.
A run’s code change may already have a TestLookup comment on GitHub or GitLab, on its pull request or merge request. When a person accepts the report, TestLookup edits that comment to say a person reviewed it.
In this path, 2 made-up tests have results, but the release needs 5. The result is Not evaluated, which doesn’t count as a success.
In TestLookup, this minimum counts different tests with results across the whole release. It’s fixed at 5, and the release rules can’t change it.
The reason reads “only N of M tests carry evidence; 5 required before a verdict means anything”. The release’s gate panel shows Evidence as the number of tests with results.
At this version, a whole release gets one of three decisions: GO, NO-GO or Not evaluated. The walkthrough’s separate Conditional GO example is the decision on a single test run. It comes with a reason and the version of the release rules it used.
Details: in the API, these decisions are GO, NO_GO, NOT_EVALUATED and CONDITIONAL_GO.
TestLookup’s review gate has two states, Audit only and Enforced. On Audit only, nothing is held back, and TestLookup only counts what it would have refused. So the audit-only step records the review state and claims no refusal.
The gate is Enforced in either of two cases:
A date in the future still means Audit only.
In the enforced step, the release shows Pending review. That’s a label, not a stored decision. While review is enforced, an AI-made decision that nobody has reviewed shows as Pending review instead of its result.
Someone with permission can still export a pending report as a draft. The draft gets a watermark, and TestLookup adds the export to its audit log, the record of who did what.
A rejected or superseded report can’t be exported this way. The walkthrough only switches a label and changes no setting.
Details: the server setting is REVIEW_GATE_ENFORCED=true. In the API, the label is PENDING_REVIEW.
The Conditional GO example is a recorded decision on one test run. It records what it covers, the version of the release rules, how much evidence it used, the reason, and whether anyone overrode it.
The history only grows. Back changes what this page shows and never claims to undo a recorded event.
In TestLookup, a QA lead can also record Hold, Approve with conditions or Override to GO from a run’s Analysis tab. TestLookup records each override in the audit log.
Why this score? shows the weights in the project’s release rules. The walkthrough’s Conditional GO comes from checking the rules, with no override.
Reset walkthrough goes back to the pending report, with the gate on Audit only.
The step-by-step text at the end of this page covers both pending states and the accepted and rejected reports. It also covers the Not evaluated release and the separate Conditional GO decision for a test run. It’s complete even with JavaScript turned off.
