About the sample data
Everything in the walkthroughs is made up: projects, runs, failures, evidence, people and times. A notice on each walkthrough says so. Nothing you see is a customer record, a benchmark, a measured AI result or a statement about a real installation.
First useful run
The first-run walkthrough follows a pretend upload of a test report. It starts when TestLookup accepts the file, goes on while TestLookup reads it, and ends with a finished test run. Two side paths show an invalid file and a run where every test was skipped.
The walkthrough keeps the upload task and the test run apart. You’ll see that TestLookup can accept a report before its results are saved.
Failure triage
Triage means looking at a failure and deciding what to do with it. The failure-triage walkthrough looks at one failed test and shows:
- the test’s output, with sensitive details removed;
- a comparison with an earlier run;
- a rule-based classification, with where it came from and how sure it is;
- what happens when some evidence is missing;
- a person correcting the result.
Spotting a likely bug is a separate step from opening an issue in another tool. In TestLookup itself, a test’s evidence and the Correct button are on the test result page, not on the run’s Evidence tab. A correction takes effect the next time TestLookup analyzes the same test.
Review and release states
The review and release walkthrough starts with an AI-written report that is waiting for review. You see it with the review gate on Audit only and on Enforced. Then you see an accepted report and a rejected one.
It also shows two decisions: a release that is Not evaluated, and a single test run that gets a Conditional GO. Accepting a report never decides a release by itself.
At this version, a whole release gets one of three decisions: GO, NO-GO or Not evaluated. Only the decision on a single test run can be Conditional GO.
Pending review is 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.
Review becomes enforced when the server’s enforcement setting is on, or once an enforcement date chosen by an administrator has passed. By default, review isn’t enforced. Nothing is held back, TestLookup only records what it would have refused, and the Review gate settings page reads Audit only.
Separately, a release stays Not evaluated until at least 5 different tests in it have results. That minimum is fixed, and the release rules can’t change it.
Details: the server setting is REVIEW_GATE_ENFORCED=true. In the API, the decisions are GO, NO_GO, NOT_EVALUATED and CONDITIONAL_GO, and the label is PENDING_REVIEW.
Without JavaScript
Every walkthrough also works as plain step-by-step text, so you can read the whole example with JavaScript turned off. The controls are ordinary buttons, links and a drop-down list. Any chart or animation only repeats what the text already says.
Install it next
When you’ve finished, try TestLookup itself. Follow the Quick start on a spare machine that you can wipe afterwards. Before you use real data, check that:
- you can open your project;
- the background workers, which process uploads and analysis, are running;
- one report goes all the way from upload to a finished run.
If you work from a copy of the code, the quick-start command loads demo projects and sample results into your own local TestLookup. Its quick login needs no password, and it works only in development mode.
make quickstartFor more detail, read the workflow guide, the test run guide and the reporting guide on GitHub.