# Running verification and reading results

> Once your tests are ready, it's time to run verification. Learn how to run it, how to read the pass and fail results, and how to get a fix report and hand it to your AI when something breaks.

Once your tests are ready, it's time to run **verification** — clicking through your app to confirm it really behaves the way the test says (what people usually call a test run). Below we walk through how to run a check, how to read the pass and fail results, and how to take a fix report and hand it to your AI when something breaks.

## Run a verification

There are two ways to start a verification. **When starting a new run group**, ask your AI "start a verification round for this workspace," and it puts together a plan review (a PRD) of what it will verify and by what rules. Approve it once and the tests are submitted and the first verification runs automatically. **To re-verify a test you've already made**, no approval is needed — go to the **Dashboard** on your workspace board, where your tests show up grouped by area, and press **Run test** on the one you want.

When you press it, a real browser opens and clicks through the steps one by one, just like a person would. "Open the signup page" really opens that page; "enter email" really types into the email field. While it runs, the screen shows **Verifying**.

A verification is billed a tiny amount of credit that adds up in proportion to how long it actually took. If you're short on credits, you can top up (add more credits) on [Credits and plans](/en/docs/billing-and-credits). (To start a verification, your balance needs to be at least 1 credit.)

If you have several tests to check, you can select them and run them all in one go. Every run is always saved as **one run group (a round)**. Even running a single test leaves a group of size one. So you can compare "which passed and which got stuck in this round" on one screen. Flows that need a fresh account every time, like sign up, run with new random details on each check, so repeating the same verification never collides.

To run a check, the **site address to test** (your test environment's frontend address) must be registered. If you haven't done that yet, see [Connect your code](/en/docs/connect-your-code) first.

## See your history — the Run tests tab

Verifications you've run stack up by round on the **Run tests** tab. Here you can scan past runs newest-first, seeing at a glance whether each round passed or failed and when it ran. You can also click a specific test to look at how just that one has trended over time (pass rate and history). It's handy for tracing "it worked yesterday but suddenly failed today."

## Read the results — pass and fail

When a verification finishes, the result shows up as a badge (a small status marker). It's one of two things.

- **Pass** — the app worked just as the test said. Every step finished without getting stuck.
- **Fail** — at some step, it didn't go the way the test expected. It also shows you which step it stopped at.

Next to the result is the **verification time** (when it ran). That keeps you from confusing "was this result just now, or from yesterday?" Pass is green and fail is red, so it reads at a glance even from afar.

> The result is either "pass" or "fail," just those two. There's no vague middle ground like "almost worked." That way you can tell, plainly, whether something works or not.

If the approved pass condition and the current test have diverged, the result carries a **"please re-approve"** note. It's a signal that what counts as success has changed, so take a look and re-approve. (What pass-condition approval means is covered in [How verification works](/en/docs/how-verification-works).)

## Replay the video and screenshots

Every time you run a verification, the path the browser clicked through is saved as a **video** and **screenshots**. On the result screen, press the video to watch it again from the start. You see with your own eyes which screen appeared at which step, and where it stopped.

You don't need to read code. Just watching the video, you can tell right away — "ah, it pressed the pay button but the next dialog never opened." A screenshot is also saved at each step, so you can quickly scan "which screen it stopped at" without watching the whole video. When you need to explain the situation to someone, that one screenshot is often enough.

Run the same test several times and the video updates to the newest one. If a test's result has been invalidated (for example, you reordered the steps so the old result can no longer be trusted), the remaining video gets a **Previous video** note. That marks that the video may differ from the current test.

## When it fails — the fix report

When a verification fails, you can get a **fix report**. Press the **View suggestions** button and AI analyzes the failed step and lays out things like this.

- **Which step got stuck** — e.g., "Cancel payment — button not responding"
- **Cause** — e.g., "The cancel confirmation dialog never opened, so the flow didn't continue"
- **Suggestion** — e.g., "Check the handler wired to the cancel button"

Let's be clear about one thing. **Specnote does not fix your code directly.** Instead, it produces a report that neatly organizes the failure cause, the expected result versus the actual result, any error shown on screen, and so on.

Here's what comes next. Copy the report and paste it into the AI coding tool you usually use (Cursor, Claude Code, and the like), and the actual fix begins there. In other words, **Specnote finds and organizes the cause, and your AI tool does the code fixing** — split between the two. After the fix, just run the verification again to see if it passes this time.

> Failures show up in two kinds. **App problem** (the app didn't meet the pass condition — fixing the code resolves it) and **Blocked** (not the app's fault — the test environment or an outside factor got in the way of verifying). Which kind it is changes what you need to touch.

## Get result notifications

You can't watch the screen every time a check finishes. So you can get results as notifications.

| Where it arrives           | When it's on                                                           |
| -------------------------- | ---------------------------------------------------------------------- |
| In-app notification center | Always on                                                              |
| Email                      | On only if you turn it on (opt-in)                                     |
| Slack                      | On once you register a webhook (the address notifications are sent to) |

Notifications come by category: screen walk-through, re-walk, verification, auto-recovery, and code sync. Of these, **code sync notifications are off for external delivery by default** — to keep them from arriving so often that they get in the way. You can turn them on in settings if you need them.

With notifications on, you can step away to other work while a long verification runs and just catch the result when it's done. You set which notification goes where, by category, in settings — so you might take only the important verification results by email or Slack and check the rest inside the app.

## Verify again

When you fix code, you have to verify again to confirm it's really fixed. The simplest way is to press **Run test** one more time on the same test. That gives you a new video and a new result. A re-verification like this runs without approving a new plan review, and it **re-runs in place at the original run group (round), refreshing that group's pass rate.** It doesn't spawn a new group — the result in the same spot just updates to the latest.

If you changed code in several places, running everything every time gets tedious. For that, use **Re-check changes** — it picks only the changed parts and re-checks just the affected screens. Unchanged spots are confirmed quickly with no AI cost, and only the screens that genuinely need another look get re-checked, so it saves money too.

When a re-check turns into a pass, the pass badge comes back on the test. Repeat this fix-and-recheck loop and your tests stay in sync with the app as it is now. Instead of confirming "it works as planned" once and being done, you can easily realign every time the code changes.

> Hooking verification to run on its own every time you push code (CI integration) is available now, too. If you'd rather have it verify automatically instead of pressing a button each time, see [Connect CI for automatic verification](/en/docs/connect-ci).

If you want to know more about how verification works under the hood, see [How verification works](/en/docs/how-verification-works); if you haven't connected your code yet, see [Connect your code](/en/docs/connect-your-code).

---

Source: https://specnote.io/en/docs/running-and-results