uatgpt.com

uatgpt.com keeps evidence and defects tied to the expectation by treating a drafted test, an observed result, and a release decision as three separate events, each anchored to the product actually checked. You record what should have happened next to what did happen, and you make a failed path reproducible by naming the path and build that were checked. This applies when you are preparing acceptance evidence and a release conversation; the site frames criteria and organizes notes, but it does not decide whether a product meets them.

The separation that makes evidence trustworthy

The site's own framing is explicit: "A drafted test, an observed result and a release decision are different events. Keep each one tied to the product you actually checked." That sentence is the mechanism behind everything else on the page.

• Drafted test — the criterion you wrote before running anything. It states the actor, starting condition, action, and visible outcome.
• Observed result — what you actually saw when you checked that criterion on a specific path and build.
• Release decision — the judgment you make after reviewing evidence, not a substitute for it.

Keeping these apart prevents the most common failure in acceptance work: letting a well-written test stand in for a result, or letting a release decision quietly rewrite what was observed.

Keeping observed results beside the expectation

The Evidence stage uses observation notes to hold the expected outcome and the observed outcome in the same place. The page's criterion frame defines what belongs in the expectation:

The frame also includes the starting state, so the full criterion reads as actor, starting condition, action, and visible outcome. The site notes that this frame "exposes missing parts; it does not decide whether a product meets them" — which is exactly why the observation note has to sit beside it rather than replace it.

The page makes the point concretely: "Intuitive" cannot be observed in the same way as a named message or changed state. If your expectation is a named message or a changed state, your observation note can record whether that message appeared or that state changed. If your expectation is a feeling, there is nothing to record against.

Making a failed path reproducible

The Defects stage uses reproduction steps and asks: which path and build were checked? A failure is only useful to a release conversation if someone else can retrace it. That means the defect record should carry:

• The path that was exercised
• The build that was checked
• The expectation it failed against (traceable back to the criterion)
• The observed result, kept as observed

The Coverage stage supports this with trace links that find gaps between criteria and tests, so a defect can point to the specific acceptance statement it contradicts rather than to a general impression.

Why the tie to the actual product matters

Every stage on the site carries the same constraint. The Brief stage turns a product request into acceptance conditions; the Paths stage writes scenarios with observable outcomes; Coverage maps criteria to tests; Evidence keeps results beside expectations; Defects makes failures reproducible; Release reviews evidence before a decision. Each stage is a local draft, and the page states plainly that drafts stay on the page.

The practical consequence: when you move from a drafted test to an observed result, you are recording something about a named path and build — not about the criterion in the abstract. A release decision built on that record can be defended; one built on a well-worded test cannot.

A worked example

Suppose a request says users should get clear feedback after submitting a form.

1. Brief — Draft the criterion: a signed-in user (person), on a completed form (starting state), submits it (action), and sees a named confirmation message (visible outcome).
2. Paths — Write the scenario with that observable outcome rather than "feels responsive."
3. Coverage — Link the criterion to the test so gaps are visible.
4. Evidence — Run it on a specific build and path; note beside the expectation whether the named message appeared.
5. Defects — If it did not, record the path, the build, and the observed result so the failure can be retraced.
6. Release — Review the evidence as recorded, and make the decision as a separate step.

At every point, the record stays attached to the product you actually checked. That is the whole method: the expectation is written so it can be observed, the observation is kept next to it, and the failure names where and on what build it happened.

uatgpt.com is a working page for turning a product request into a written acceptance criterion, then keeping the expected and observed results side by side. It is a drafting and evidence aid, not a test runner: the site itself says the criterion frame "exposes missing parts; it does not decide whether a product meets them." Use it if you need to prepare acceptance evidence and a release conversation; it will not execute tests or produce a pass/fail on its own.

What the page actually does

The core action is a five-part frame. You write down:

1. Person — whose task is this?
2. Action — what changes?
3. Result — what can be observed?
4. Starting state — what is true before the action?
5. Coverage — which acceptance statement is being checked?

The page's own summary of the frame: "Write the actor, starting condition, action and visible outcome." A feature request becomes a useful criterion only when these pieces connect. The frame's value is that a missing piece becomes visible — for example, an outcome nobody can observe.

The site also draws a line that matters for how you use it: "A drafted test, an observed result and a release decision are different events. Keep each one tied to the product you actually checked." So the tool holds the draft and the observation notes; it does not invent a test outcome for you.

The stages it covers

The page organizes work into six stages, each with a "use the check" action and a local draft:

Two things to note. First, drafts stay on the page — the site labels them "Local draft" and "Private draft," so this is not a shared team workspace by default. Second, the stage names describe the artifact you produce, not an automated check; "Coverage" means trace links you record, not a coverage report generated from a test run.

Why "visible" is the recurring theme

The page argues that "a visible result is stronger" — "intuitive" cannot be observed the same way as a named message or a changed state. That is the practical test for whether a criterion is ready: can someone else see the outcome without asking you what you meant? If the answer is no, the frame is incomplete.

A concrete example of the gap: a request says the checkout should "feel fast." Under the frame, that fails the Result step until you name something observable — a specific state change or message a tester can record. The page does not tell you which threshold to pick; it only forces you to state one.

What it references and what it isn't

The page points to ISTQB acceptance testing, Cucumber Gherkin, and Playwright as its reference points, and notes that Playwright is about visible behaviour. Those are pointers for how to phrase scenarios and where observable outcomes come from — the page does not claim to run Gherkin or Playwright.

It also does not publish pricing or account details. Nothing on the page indicates whether drafts persist beyond the session or require a login, so treat "local draft" as exactly that until you confirm otherwise.

When it fits your workflow

• Good fit: you have a requirement in prose and need to convert it into an acceptance criterion with a checkable outcome; you want a lightweight place to record what you expected versus what you saw before a release conversation.
• Poor fit: you need automated test execution, shared team dashboards, or a system of record for test results across builds. The page is explicit that a visible result is stronger than a vague one, but it leaves running and storing results to your existing tools.

The fastest way to judge it is to take one real requirement and try to fill all five parts. If you get stuck on "Result," that is the frame doing its job — and a sign the tool suits the problem you have.

Start with the stage that matches what you already have in hand. If you have a product request but no testable condition, begin at Brief. If you have a condition but no steps, go to Paths. If you have criteria and tests but don't know what's missing, use Coverage. If you have a result to record, use Evidence. If something failed, use Defects. If you're deciding whether to ship, use Release. The site frames these as six connected stages, each with a "Use the check" action and a local draft — it is a drafting aid, not a full test management system.

The six starting points and what each is for

The page describes the stages in this order: Brief → Paths → Coverage → Evidence → Defects → Release. You don't have to move through them linearly, but each stage assumes the output of the earlier ones exists in some form.

Choosing by what you actually have

The simplest rule is to ask what artifact is missing:

• No testable statement yet? Go to Brief. The criterion frame asks for the person or role, the task they need to finish, the starting state, the action or event, and the visible outcome. The site is explicit that this frame "exposes missing parts; it does not decide whether a product meets them."
• A statement but no walkthrough? Go to Paths and write scenario paths with observable outcomes.
• Both, but unsure of completeness? Go to Coverage and map which acceptance statements are actually checked.
• A run has happened? Go to Evidence and keep the observed result next to the expectation.
• A path failed? Go to Defects and make the failure reproducible with steps tied to the path and build checked.
• Everything is gathered and a decision is due? Go to Release and review evidence against decision gates.

What the site will and won't do for you

Each stage offers a "Use the check" action and produces a local draft — the page states "Drafts stay on this page." That means your work is a working draft for a conversation, not a stored record in a test management system. Plan to move finalized criteria, evidence and defect notes into whatever system your team uses for tracking.

The site also draws a line between three events: "A drafted test, an observed result and a release decision are different events. Keep each one tied to the product you actually checked." This matters most at Evidence and Release, where it's tempting to let a draft stand in for a result. The page's own guidance is that a visible result — a named message or changed state — is stronger than a subjective claim like "intuitive," because it can be observed the same way by someone else.

A practical example

Suppose a request says the password reset email should arrive quickly. At Brief, you'd write: a registered user, starting from the login page after requesting a reset, receives a reset email with a working link within a stated time. At Paths, you'd write the steps and the observable outcome (email received, link opens the reset form). At Coverage, you'd check whether expired-link and wrong-address cases are covered. After a test run, Evidence holds what you actually saw; if the link failed, Defects holds the reproduction steps and the build checked. Release is where you weigh that evidence before deciding.

Common sticking points

• Skipping Brief. Writing scenarios before the criterion is clear tends to produce paths that test the wrong thing. The frame is quick; use it first.
• Treating a draft as evidence. A drafted test is not an observed result. Record what happened separately at Evidence.
• Expecting persistence. Local drafts are for the current page and conversation; export or copy them into your team's tools.
• Confusing coverage with passing. Coverage shows which criteria are checked, not whether they pass — that's what Evidence and Defects are for.

The page links out to ISTQB acceptance testing, Cucumber Gherkin and Playwright as reference material for the underlying methods, so if you need formal definitions of acceptance testing or scenario syntax, those are the places to look rather than the stage pages themselves.

uatgpt.com organizes acceptance testing into six stages: Brief, Paths, Coverage, Evidence, Defects, and Release. Each stage asks one question and produces one local draft — a criterion, a scenario path, a trace link, an observation note, a reproduction step, or a decision gate. The stages are meant to be worked in order, so that a requirement becomes a testable criterion, a failure becomes a reproducible path, and a release decision rests on observed results rather than assumptions. The site frames this as "State the test. See the outcome." and keeps drafts on the page rather than publishing them.

The six stages and what each one asks

The site's own navigation labels these as "Use the check" / "Local draft" for each stage, and lists reference material alongside them: ISTQB acceptance testing, Cucumber Gherkin, and Playwright for visible behaviour.

How the stages connect

Brief: from request to criterion

The Brief stage uses a criterion frame with five parts: the person or role, the task they need to finish, the starting state, the action or event, and the visible outcome. A feature request becomes a useful criterion only when all five connect. The site is explicit about the limit of this frame: it "exposes missing parts; it does not decide whether a product meets them." So the Brief stage produces a well-formed question, not a verdict.

Paths: making the outcome observable

The Paths stage writes scenario paths with observable outcomes. The site's stated principle is that a visible result is stronger than a subjective one — "'Intuitive' cannot be observed in the same way as a named message or changed state." A path is only complete when the starting condition and the visible outcome are both named.

Coverage: tying criteria to tests

Coverage finds gaps between criteria and tests using trace links. This is where you check which acceptance statement a given test is actually checking, so that no criterion sits untested and no test floats free of a requirement.

Evidence: keeping observation beside expectation

Evidence keeps observed results next to the expectation in observation notes. The distinction the site draws is that "a drafted test, an observed result and a release decision are different events" — each must stay tied to the product you actually checked. This is the stage that prevents an invented test outcome from standing in for a real one.

Defects: making a failure reproducible

Defects records which path and build were checked and turns a failed path into reproduction steps. Because the path and build are named, someone else can re-run the same check rather than guess at it.

Release: reviewing evidence before deciding

Release sets decision gates: evidence is reviewed before a release decision is made. The gate depends on the earlier stages — you can only review observations that were recorded, against criteria that were defined, on paths that were specified.

A worked example of the chain

Suppose a request says users should get clear feedback when a form submission fails.

• Brief names the actor (a signed-in user), the starting state (a form with a missing required field), the action (submit), and the visible outcome (a named error message identifying the field). "Clear feedback" alone fails the frame.
• Paths writes the scenario: given the missing field, when submitted, then the named message appears.
• Coverage links this scenario to the acceptance statement it checks.
• Evidence records what was actually seen on the build tested, beside the expectation.
• Defects, if the message did not appear, captures the path and build plus steps to reproduce.
• Release reviews that evidence before the decision.

Each stage adds one artifact and one check; none of them substitutes for the others.

Where to start

The site offers a choice of starting point — Brief, Paths, Coverage, Evidence, Defects, or Release — so you can enter at the stage that matches your current gap. If a requirement is still vague, start at Brief. If tests exist but you cannot say which criterion they cover, start at Coverage. If a failure has been reported but not reproduced, start at Defects.

The criterion frame on uatgpt.com turns a product request into an acceptance condition by forcing it into a fixed structure: the actor, the starting condition, the action or event, and the visible outcome. The site describes the frame as a way to expose missing parts, not to decide whether a product meets them. In practice, that means the frame tells you whether a request is testable yet; it does not tell you whether the test passes.

What the frame asks for

The site presents the frame as a sequence of connected pieces. A feature request becomes a useful criterion only when these pieces connect:

• Person — whose task is it? A named person or role.
• Action — what changes? The task they need to finish.
• Result — what can be observed? The visible outcome.

The page also names a starting state and an action or event as part of the same structure, and its "Criterion frame" section summarizes it as: write the actor, starting condition, action and visible outcome.

The five parts in practice

The site's own example is a five-part sample marked "Clear" and "Editable," which shows the intended level of specificity: each part is filled in, not paraphrased.

Why the frame exposes gaps instead of judging results

The page is explicit that the frame "exposes missing parts; it does not decide whether a product meets them." That distinction matters because drafting a criterion and observing a result are different events. A request like "make onboarding intuitive" fails the frame at the outcome step: there is no named message, changed state, or other observable result to check. The frame surfaces that gap immediately, before anyone writes a test or claims a release is ready.

The site reinforces this with its note that "a visible result is stronger": "intuitive" cannot be observed in the same way as a named message or changed state. So the frame's value is diagnostic. It converts a vague request into a checklist of what is still unknown, and the unknowns become the next questions to ask the product owner.

Where the frame sits in the wider workflow

The page organizes its tools into stages, and the frame is the entry point rather than the whole process:

• Brief — turn a product request into acceptance conditions (the criterion frame).
• Paths — write scenario paths with observable outcomes.
• Coverage — find gaps between criteria and tests using trace links.
• Evidence — keep observed results beside the expectation using observation notes.
• Defects — make a failed path reproducible with reproduction steps.
• Release — review evidence before a release decision using decision gates.

Each stage has a "Use the check" action and a "Local draft" label. The page states that drafts stay on the page, so you can build criteria and notes without committing them anywhere. The site also references ISTQB acceptance testing, Cucumber Gherkin, and Playwright as sources in context, which signals the vocabulary the frame is meant to fit.

What to expect when you use it

Start with the Brief stage and fill in the person, starting state, action, and visible outcome. If any part cannot be written concretely, that is the finding: the request is not yet an acceptance condition, and the missing part tells you what to clarify. Once the frame is complete, move to Paths to write the scenario, then to Evidence to record what you actually observed. Keep the drafted criterion tied to the product and build you checked, since the page stresses that a drafted test, an observed result, and a release decision are separate events.

The frame will not tell you whether a feature is good, and it will not replace a test run. It gives you a consistent way to spot an untestable request early and to keep the acceptance conversation grounded in things someone can actually see.