QA Flow gives you fine-grained control over how your Playwright tests are executed — from simple single-threaded runs to fully parallel multi-worker suites. Configure execution behavior once in the Project Settings modal and every subsequent run will respect those preferences, or override them on demand through the REST API.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/davidG97/qa-flow/llms.txt
Use this file to discover all available pages before exploring further.
Triggering a Test Run
There are two ways to start a test run: directly from the visual editor, or programmatically through the API.From the Editor
Click the ▶ Execute button in the top toolbar. The execution panel slides open on the right and immediately begins streaming live node-status updates and the browser screencast.
Via the REST API
POST /api/run accepts a JSON body with your flow definition and returns an executionId instantly. The run continues in the background and its status is queryable at any time.API Endpoints
| Method | Endpoint | Description |
|---|---|---|
POST | /api/run | Start a new test execution |
GET | /api/status/:executionId | Poll the status of a running or completed execution |
GET | /api/executions | List the 20 most recent executions |
POST /api/run request body must include the flow object (nodes + edges). Optionally pass an options object to override slowMo and timeout for that individual run.
pending → running → completed | failed.
Execution Modes
QA Flow maps directly onto Playwright’s test runner concepts. The execution mode is set in Project Settings → Execution Mode.- Default
- Serial
- Parallel
Playwright’s built-in default behavior. Tests run sequentially within a single worker unless Playwright itself decides otherwise. Best for small projects or when you want predictable, repeatable ordering without any configuration overhead.
Project Configuration Reference
All execution options come from theProjectConfig interface defined in src/types/nodes.ts. Open Project Settings (gear icon) in the editor to adjust these values with a GUI, or supply them directly in the API request body.
ProjectConfig
| Field | Type | Default | Description |
|---|---|---|---|
executionMode | 'default' | 'parallel' | 'serial' | 'default' | Controls how Playwright schedules tests |
workers | number (1–10) | 4 | Number of parallel worker processes; only active in parallel mode |
retries | number | 0 | Times to automatically retry a failed test before marking it as failed |
timeout | number (ms) | 30000 | Maximum time allowed for each individual action (e.g., a click or assertion) |
maxFailures | number | 0 | Stop the entire suite after this many failures; 0 means run to completion regardless |
cdpUrl | string (optional) | '' | Connect test execution to a specific remote Chrome instance via CDP |
Full configuration example
Node Status Indicators
While a run is in progress the editor canvas updates each node in real time to reflect its current state:| Indicator | Meaning |
|---|---|
| 🟡 Yellow pulse | Node is currently executing |
| 🟢 Green | Node completed successfully |
| 🔴 Red | Node failed (check the execution panel for the error message) |
Choosing the Right Settings
Start with Default mode
Unless you have a specific reason to use parallel or serial, start with
default. It requires no extra thought about test isolation and gives you a reliable baseline.Increase workers gradually for parallel runs
When switching to
parallel, start with workers: 2 and verify your tests pass consistently before increasing. Each worker spins up a full Chromium instance, so very high worker counts (8–10) require substantial RAM — plan for roughly 200–400 MB per worker.Tune timeout to your application's response time
The default
timeout of 30000 ms (30 seconds) is generous. For fast local apps you can lower it to 10000–15000 to make failures surface faster. For slower CI environments or apps with heavy network calls, leave it at 30 s or increase it.Use maxFailures in CI to fail fast
Setting
maxFailures: 1 or maxFailures: 5 prevents a suite with a systemic failure (e.g., wrong base URL) from running hundreds of tests before you see the problem. Set it to 0 for full coverage reporting in nightly runs.