Running a test

Running a test means replaying every recorded step against your real, live site. It is the moment you find out whether the journey you care about still works. A run is a single, fully recorded execution of the test, and every run is preserved so you can compare today's behaviour to last week's, last month's, or last release's.

123

1. 1Run the test now. A fresh browser session opens and walks every step.
2. 2Run history and pass rate, so you can see whether this is normally green.
3. 3When it last ran.

Starting a run

Open any test and click "Run Test". Testsnag spins up a fresh browser session, loads your target URL, and walks through each step in order, clicking, typing, navigating, and checking assertions exactly as recorded. You can watch it happen live in the panel as it runs. A status indicator shows the current step, a timer counts up, and the result of each step appears the moment it completes, which means you usually know whether something is broken before the run has even finished.

Choosing an environment

If the test has environments enabled, the Run button opens a menu: No environment, one entry per enabled environment, and All enabled when there is more than one. All enabled starts one run per environment, and each run uses one run from your monthly allowance. If there are not enough runs left for all of them, none start.

Reading the outcome

When the run finishes, you will see a clear pass or fail with timings and screenshots for every step. A pass means every step ran and every assertion held. A fail means at least one step or assertion did not behave as expected, and the failing step is highlighted with its error message and the screenshot that was captured at the moment things went wrong. Most failures can be diagnosed without leaving the run page.

Run history

Runs build a useful history for as long as the test exists, which is essential when investigating regressions days or weeks after the fact. If you delete the test itself, its runs are deleted with it, so keep that in mind before removing something you may still need for audit or debugging. Runs can be triggered manually from the test page, on a schedule, by a webhook, or through an integration such as a GitHub deployment, each of which has its own guide. You can mix triggers freely on the same test, and every run is tagged with how it was started so the source is always clear at a glance.