Create your first regression test with FlowQA
This is the first session with FlowQA: an account, a project pointed at your site, one test that is recorded or generated, a look at its assertions, and a second run to see it hold. It also says plainly which steps need the desktop app and which work in the browser.
What runs where
| FlowQA on the web | FlowQA Desktop (Mac, Windows) | |
|---|---|---|
| Sign in, open projects, see results | Yes | Yes |
| Run tests on cloud browsers | Yes | Yes |
| Run tests on your own machine, free, including sites behind a VPN or on localhost | No | Yes |
| Record a test by clicking through your site | No | Yes |
| Let the exploring agent map the site and generate tests | Yes, on a cloud browser | Yes, on a cloud browser or on your machine |
| Repairs, schedules, CI triggers, GitHub hooks, site notes | Yes | Yes |
The web workbench is enough to generate, run and maintain tests. Recording by hand needs the desktop app because it drives a real browser on your machine.
1. Sign in
Open FlowQA on the web, or install FlowQA Desktop from the downloads page and open it. Sign in with your work email and the six-digit code from the email you receive. A TestFinch account works for both products; if your team already uses Snag, the same email and workspace apply.
2. Create a project
Choose New project. Give it a name, the site's base URL (the one tests start from), and the hosts a test may visit; one environment is created from those, and you can add staging or preview environments later in the project's Settings. If the site sits behind a preview password or a sign-in, record the steps that pass it as a shared opening once; the explorer and every test can run it first.
3. Get a first test
Two ways.
Generate it. Choose Explore site. FlowQA maps the site on a cloud browser, proposes test journeys with a goal and a success condition each, and waits. Keep, rename or drop the journeys, then generate. Each kept journey is explored, recorded as steps, given assertions, replayed twice on fresh sessions, and checked against a deliberately broken page; only a test that passes clean and fails when it should is accepted. Accepted tests appear in the project.
Record it (desktop only). Choose Record a test, click through the flow in the browser that opens, and stop. The steps appear in the editor. Add an assertion for what the page should show at the end, so the test fails when the flow breaks rather than only when it crashes.
4. Read the test
Open the test. Each step shows what it does and the element it acts on; assertion steps show what they check. The site notes, under the project's Settings, hold what the explorer learned about each page; correct anything that is wrong and the next run reads it.
5. Run it again
Choose Run. On the web the run happens on a cloud browser; on the desktop you can pick your own machine. The result lists every step with its status, and a failing step shows the error, the screenshot and what the page looked like. Run history is kept per test, so the next run compares against this one.
6. Keep it running
- On a schedule: the project's Settings, then Schedules and CI, runs the tests nightly or hourly and emails or Slacks the people named when a run fails.
- From your pipeline or on every deployment: the same page gives a CI trigger token, and the GitHub deploy hooks run the regression after every successful deployment with a check on the commit.
- When a page changes on purpose and a test fails, FlowQA proposes a repair, proves it twice, and waits for your approval.
- With Snag in the workspace, a failing run files a bug with the evidence, and a bug can be reproduced as a test from its trail.