Browser Execution vs Cloud Execution
When you click Run on a test case, QAlity asks you to choose between two ways to run it. This choice matters more than it might seem - the right option depends on what stage of testing you're in, how many tests you're running, and what your environment looks like. Both options capture screenshots at every step and give you a stop button, but under the hood they behave very differently.
How they work
Browser Execution runs the test directly inside your local browser, on your own machine. You can watch every click, scroll, and input happen in real time, exactly as a user would experience it. Because it runs locally, it has access to your network, your VPN, and even your existing browser session - including saved cookies and login state. This makes it uniquely useful for testing apps that live behind a firewall or require authenticated sessions that are hard to replicate elsewhere.
Cloud Execution runs your tests on QAlity's own cloud machines, completely in the background. There's no visual playback - the browser runs headlessly, meaning it operates without rendering a visible interface. This keeps runs fast and off your local machine. Every run starts from a clean, isolated browser session with no leftover cookies or state, which helps ensure your results are consistent and reproducible across runs.
Comparison at a glance
| Browser Execution | Cloud Execution | |
|---|---|---|
| Runs in | Your local browser | QAlity's cloud machines |
| Visual playback | Yes - live, real-time | No - headless background |
| Scheduled plans | Manual runs only | Automated on a schedule |
| Screenshots | Yes, every step | Yes, every step |
| Stop button | Yes | Yes |
| Speed | Slower (renders visually) | Faster (no rendering) |
| Browser session | Uses your existing state | Fresh, clean session every run |
| Network access | Your local network and VPN | Public internet only |
| Resource usage | Your machine's CPU and RAM | QAlity's infrastructure |
| CI/CD integration | Manual trigger only | Can be triggered via pipeline |
| Failure evidence | Live view and screenshots | Screenshots and logs |
| Agent type in history | WEB_AGENT | QAlity |
When to use Browser Execution
- Debugging a failing test - watching the browser in real time makes it easy to spot exactly where and why something breaks
- Verifying a new test case - before you trust a test to run unattended, watch it run once to confirm it behaves as expected
- Testing behind a VPN or firewall - since it runs on your machine, it can reach internal URLs and authenticated environments that QAlity's servers cannot
- Running a single test quickly - no setup or queue, just click and watch
- Checking for visual or layout issues - live rendering lets you catch UI problems that screenshots alone might miss
When to use Cloud Execution
- Regression testing - run a large batch of tests after a release or code change without sitting and watching each one
- Scheduled suites - trigger plans on a cadence so regression runs without manual starts
- CI/CD pipelines - Cloud Execution can be triggered automatically as part of your build or deployment workflow
- Keeping results consistent - clean browser sessions eliminate flakiness caused by leftover state, cached data, or previous test interference
- Saving local machine resources - tests run on QAlity's infrastructure, so your machine stays free while tests execute in the background
- Getting results faster - headless execution skips visual rendering entirely, making each test run noticeably quicker