The Session Nobody Wrote Down

The write-up is where the value leaks.

Every QA engineer knows this afternoon. You spend ninety minutes exploring a new release: following a hunch, switching roles, breaking the happy path on purpose. You find three defects and a workflow that only fails when the steps run in an unexpected order. Then the session ends, and the real work begins: writing it all up from memory.

Steps get compressed. The hunch that led to the bug gets dropped because it doesn’t fit a template. The environment details, the exact data, the order of clicks: half of it is gone by Friday. Testers know it, and many quietly skip the documentation because the alternative is spending as long writing about the session as running it.

ATTEST started as a QA engineer’s answer to that problem. If the session itself could be the source of the documentation, the tester could stay focused on testing.

ATTEST, short for Automated Timestamped Test Evidence Synthesis and Traceability, has since grown beyond software testing, as section 06 describes.

Record the session. Get structured QA artifacts.

The idea is close to “Loom meets QA automation.” The tester records the session, narrating as they go, and ATTEST turns the recording into four kinds of output.

Capture, analyze, draft, review.

A recording is uploaded and queued for background processing. Large language models work over the session’s audio and visual context, and the results are stored as structured records so they can be searched, revised, and reused.

Under the hood it is deliberately ordinary. We wanted the AI to be the interesting part, not the plumbing.

One design choice matters more than the stack. ATTEST separates a deterministic layer, which captures and time-aligns the evidence, from an AI layer, which drafts from it. The timeline doesn’t depend on a model’s interpretation, and that is what lets a reviewer check a draft against the moment it cites. The models are also swappable, so a deployment can follow a customer’s approved-model list rather than one vendor’s roadmap.

The subject matter expert owns the judgment.

An AI that writes test cases invites an obvious worry: plausible-looking documentation that is subtly wrong. Our answer is the same one we give on every mission-critical engagement.

ATTEST treats every generated artifact as a draft with a review status. A reviewer approves, edits, or rejects it, and the record keeps who reviewed it, when, and their notes. Nothing becomes an official test record until that step is complete.

That design also makes disagreement useful. When a reviewer corrects a draft, the correction is a signal about where the model misread the session, and it is visible rather than silently overwritten.

Recording people at work is a sensitive thing to ask of a team, and we treat it that way. The tester decides when recording starts and stops, recordings belong to the program that made them, and what is kept, and for how long, follows the customer’s rules rather than ours.

Feed the systems teams already use.

QA teams already have homes for their output: a test management tool, an issue tracker, a CI pipeline. ATTEST is meant to feed those systems, not replace them, with drafts structured so they can move into tools such as Jira and TestRail once approved.

On defense programs, test evidence is often a contractual deliverable in its own right, so approved records are structured to trace back to the requirements they verify.

The next step we find most interesting is closing the loop with automation: using approved session records to flag which exploratory findings deserve a permanent automated test. That is an opportunity we are exploring, not something measured today.

From the browser to the test floor.

The same problem looks different in a hardware test control room, but it is the same problem. When a test article behaves unexpectedly, the evidence needed to explain it is scattered across what the operator did at the console, what was said on the comm loop and by whom, what the telemetry and command record show, and how the article, facility, and instrumentation were configured at that moment. Each lives in a different system on a different clock, and reconstructing an anomaly can mean days of forensic work across records that were never designed to line up.

The test-floor variant of ATTEST applies the session-capture idea to that environment. It is being built to record the console and the loop, attribute each call to its speaker, and align both with telemetry, commands, and declared configuration on a single timebase. The goal is configuration-resolved data provenance, where every dataset carries the action and the configuration that produced it.

This work is at TRL 4. The capture-to-review pipeline runs end to end in the software variant; console capture, loop attribution, and time alignment for the test floor are what we are building now. The review model in section 04 carries over unchanged, so an engineer adjudicates every draft before it becomes part of the test record.

What ATTEST does not do.

ATTEST does not replace exploratory testing, and it does not remove the need for a skilled tester. A recording cannot capture what the tester was thinking but never said aloud, and a draft is only as good as the narration behind it. What it removes is the hour of reconstruction afterward, and the knowledge that used to evaporate in that hour.