Skip to main content
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

1

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.
2

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.
3

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.
4

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.

​
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.
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.