Running tests
Trigger and analyze tests regularly to catch regressions before customers do — at minimal cost and negligible time investment.
How runs work?
Section titled “How runs work?”Each run executes an AI-generated test script in a fresh, isolated environment. Runs can be scheduled, triggered on demand, or fired from CI/CD. There is no cap on concurrency — for example 10 scripts across multiple test suites can all run simultaneously without interfering with each other.
The same test script can also run in parallel across different configurations (browsers, viewports, devices), exactly like having multiple QA engineers performing the same test case at once, on different devices — except AI does it all instantly.
The time savings
Section titled “The time savings”| Approach | 10 tests | Notes |
|---|---|---|
| Manual testing | ~100 min | 10 min per test, sequential |
| Traditional automation | 10s of minutes to hours | Tedious scheduling & sequencing |
| This platform | 2–3 min | All tests run in parallel |
Once a verified test script is ready, every test executes in parallel. What could take ~100 minutes now takes 2–3.
Every run produces detailed logs and analytics covering outcomes, steps executed, and any issues or errors detected.
Triggering tests
Section titled “Triggering tests”Runs can be triggered in three ways:
- Manually from the UI — as an individual test or as part of a test suite
- Via CI/CD — For example, by using a GitHub Action, for individual tests or full suites
- On a schedule — fixed cadence with no manual intervention needed
It’s also possible to override run parameters such as URL, secrets, and browser engine at trigger time.
Running an individual test
Section titled “Running an individual test”- Navigate to the tests section
- Open the test you want to run
- Click the Run button