Help — the 5-minute guide
Try it on the demo site first
Acme Freight is a make-believe shipping company served by this hub, made to be tested: tracking, quotes, a staff portal and slow jobs you can watch. Its guided tour walks you through running the Freight regression group, "deploying" newer releases of the site in its Release console, and watching the hub catch what each one broke.
Run tests
Tests page → the Run button next to any test, or tick several and Run selected. Groups run a whole set with one click. The Dashboard shows everything currently running, how long it has been going, the estimated time left (shown as null until that test has some history), and a Kill button if you need to stop one.
Record a new test — no code needed
- Tests → 🎥 Record new test. A live picture of the app opens.
- Click and type on the picture exactly as you would use the app. Every action is captured on the right.
- Right-click anything to add a CHECK or a WAIT — the element lights up and a panel opens: Check it says…, Check its value, Check it's visible, Check text/background color (already filled in from the real element), or Wait until it appears / is gone / says… with a how-long picker (5 s to 1 hour — use a long one for slow back-end steps).
- Stop recording → Create a new test. Give it a short ID (suggested automatically from the name) and press Create. Done — run it from the Tests page like any other.
Tip: add at least one CHECK at the end — that is what makes the test able to fail when the app breaks. A recording with no checks only proves the clicks still click.
When a test goes red
- Open the run (click the red badge anywhere).
- Read “What went wrong” — it says which check failed and what the page actually showed, next to a screenshot of that exact moment.
- Watch the Activity replay to see everything that happened (long waits are skipped automatically).
- Press Download report and attach that single file to your email/ticket — it contains the outcome, the error in plain words, the step timings and the screenshots. Developers can take it from there.
A red test is the system working: it caught something. Only re-record or edit the test if the app intentionally changed.
What the words mean
| passed | every step and check succeeded |
| failed | a check didn't hold, or a step couldn't run — the app (or the test) has a problem |
| error | the test could not run at all (e.g. browser could not start) — usually a setup issue, not the app |
| timeout | ran longer than the test's time limit |
| killed | someone pressed Kill — not a verdict about the app |
| aborted | the hub restarted while this was running — just run it again |
| estimate “null” | this test hasn't run enough times to predict its duration yet |
| flakiness | how often the same test flips between pass and fail — 0 is steady, near 1 means unreliable (tell a developer) |
| activity replay | pictures captured only while the screen was changing — long waits are skipped with a “skipped idle” note |
| step timings | how long every click/wait took, compared across runs on the test's page |
Good habits
- One test = one story (log in, submit one form, check one result).
- Prefer Wait until… over hoping the page is fast today.
- Name tests after what they prove: “Order form saves”, not “test 7”.
- Before a release, run the group and skim the Metrics page — Failing now and Step timing trends tell the story fast.