Where to Start on uatgpt.com: Brief, Paths, Coverage, Evidence, Defects or Release

Updated

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

Starting point Use it when you have… What you produce
Brief A product request, but no clear acceptance condition A criterion with actor, starting state, action and visible outcome
Paths A condition, but no scenario steps Scenario paths with observable outcomes
Coverage Criteria and tests, but uncertainty about gaps Trace links between criteria and tests
Evidence An observed result to record Observation notes kept beside the expectation
Defects A failed path that needs to be reproducible Reproduction steps
Release Evidence gathered, decision pending Decision gates for a release conversation

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.