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

# Acceptance Tests: Confirm That Features Are Delivered

> Convert business requirements into repeatable acceptance flows to independently verify that a development team delivered working software.

An acceptance test is a flow tied directly to a specific business requirement or user story. Its purpose is to give you — the CTO, founder, or product owner — an independent, repeatable way to verify that a feature was actually delivered and works correctly in production, without relying on the development team's own testing or a manual walkthrough. If the acceptance test passes, the requirement is met. If it fails, the feature is not yet accepted.

## How Acceptance Tests Differ from Monitors

Acceptance tests and monitors both use flows, but they serve different purposes:

* **Monitors** run automatically on a schedule to catch regressions and uptime failures in features that are already in production. They answer the question: *is this still working?*
* **Acceptance tests** are run on demand at delivery time to verify that a specific requirement was fulfilled. They answer the question: *was this ever built correctly?*

You run an acceptance test once (or a handful of times) to formally accept a deliverable. Once accepted and live in production, you can promote that same flow to a monitor to keep watching it going forward.

## Writing an Acceptance Test

<Steps>
  <Step title="Write the requirement as plain English">
    Start with the original requirement or user story exactly as it was defined. For example: *"Users can sign up with an email address and password and are redirected to the onboarding page on success."* This plain-English statement becomes the acceptance criterion your test must prove.
  </Step>

  <Step title="Translate to flow steps">
    Break the requirement into discrete, testable actions and assertions. Map each part of the requirement to a specific flow step — navigation, input, click, and assertion steps that mirror what a real user would do.
  </Step>

  <Step title="Run against the delivered feature">
    Point the flow at the environment where the feature was delivered — staging, a preview URL, or production — and execute the test. TYAN runs every step and records the result, duration, and a screenshot at the point of any failure.
  </Step>

  <Step title="Pass means accepted">
    A fully passing run is your formal acceptance signal. Every step completed as the requirement described. A failing run identifies exactly which step did not meet the requirement, giving you a precise, reproducible bug report to return to the development team.
  </Step>
</Steps>

## Example: Email and Password Signup

**Requirement:** Users can sign up with email and password.

The translated flow steps for this acceptance test are:

1. Navigate to `https://yourapp.com/signup`
2. Fill the **Email** field with `acceptancetest@example.com`
3. Fill the **Password** field with a test password
4. Fill the **Confirm Password** field with the same test password
5. Click the **Create Account** button
6. Assert text **"Welcome"** is visible on the page
7. Assert URL matches `https://yourapp.com/onboarding`

When all seven steps pass, the requirement is accepted. If step 5 fails because the button is disabled or the form returns an error, the test fails and you have a concrete, reproducible report.

## Sharing Acceptance Tests

Acceptance tests are designed to be shared with anyone who needs to see the proof of delivery:

* **Shareable link** — Generate a read-only link to a test run and send it to stakeholders, clients, or managers. They can see every step, the pass/fail result, and screenshots without needing a TYAN account.
* **Exported report** — Export the full run as a PDF or structured report to attach to a ticket, a project management tool, or a client sign-off document.

<Note>
  Once a feature is live in production and accepted, you can promote the acceptance test to a monitor with a single click. The same flow that proved the feature was delivered will then run on a schedule to alert you if it ever regresses.
</Note>