> ## Documentation Index
> Fetch the complete documentation index at: https://docs.simpleuat.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Retesting

> Retest after a fail, a finding in retest status, or a client request. Use the Retest requests queue.

Retest is not a new methodology. It's "they said they fixed it; you click the same path again." SimpleUAT tracks that so you don't keep a side tab for fix verification.

## Three doors into retest

1. **You failed a case/step:** next run (or the same cycle, new run) you execute again.
2. **Finding status `retest`:** the issue is waiting for you to verify.
3. **Client review action `retest_requested`:** they sent work back. You see it on **Retest requests** (`/retests`).

[Full retest article](/findings/retest).

## How to execute without losing the thread

Use the same cases. New **run** (don't rewrite history on the old run). Attach new evidence. Update the finding: `resolved` / `closed` if it holds, or keep `open` and comment if it still fails.

The delivery snapshot from last week stays immutable. A new snapshot is how you show the retest round. [Snapshots](/concepts/snapshots).

<Columns cols={2}>
  <Card title="Client review actions" icon="inbox" href="/delivery/what-client-sees">
    Accept, known issues, not ready, request retest.
  </Card>

  <Card title="Keep them updated" icon="bell" href="/playbook/keeping-client-updated">
    Comments and notifications while you verify.
  </Card>
</Columns>