Bundle, schedule, run, drill in. Test automation that holds up at scale.

Plan details

Name the plan. Set a schedule (cron-style or off). Add email recipients and pick when they fire (on failure, on success, always). Choose setting profiles, browsers, parallel execution, retries, and reporting (video, step details).

Select tests

Pick tests from your project tree. Search by name, filter by tag, or import a selection from another project. The side panel keeps a running count as you build the plan.

Order tests

Set the run order. Some tests need to run after others (login first, then authenticated flows). Drag to reorder.

Data source

Bind a data source to the plan. CSV, API fixture, or a saved HTTP Request. The plan runs once per row, so coverage scales with your data set.

Two units of organization. That's all you need.

Directories group related plans under a single name. Useful when one product surface has several plans (smoke, regression, full suite) and you want them grouped without flattening into a single bucket.

Plans are the runnable unit. A plan owns its own schedule, browser matrix, recipient list, and data source binding. One plan, one run, one result.

The overview keeps both visible at the same level so you can see the whole tree without clicking through layers.

Every plan run, drillable to the failing step.

Every plan execution is captured. The Plan Results view shows the last 30 days at a glance: pass rate trend, total runs, success and failure counts, and a per-run table with executor, browser, test count, and pass/fail split.

Click any plan run and the side drawer opens with:

The same drawer surfaces from the Testpit analytics page, so wherever you spot a regression you can drill into the run that caused it.

Run now

Hit the Run button. The plan executes against the browser matrix you configured. Most teams start here, then layer in scheduling once the suite is stable.

Schedule

Runs the plan at a defined cron. Hourly, daily, before every release. Catches regressions between deploys, not just during them.

Parallel execution

Spreads tests across workers so a long suite finishes fast. Same plan, more workers, same result.

CI/CD integrations

Trigger plans from GitHub Actions, GitLab CI, CircleCI, Jenkins, and Bitbucket Pipelines. JUnit XML output means PR gates and status checks work out of the box.

A failed test should tell you what to fix.

When a step inside a plan fails, the result row carries the error inline. TimeoutError with the step that timed out. AssertionError with the variable that was missing. Network errors with the request that returned the wrong status.

Click into the test and you get the full step-by-step replay, the screenshots captured at each step, and the video of the run if you enabled it in Reporting settings.