Execution and Debugging

Learn how to run your flows, interpret results, and diagnose failures.

Running a Flow

Full Execution

To execute the entire flow:

1. Make sure the flow is saved
2. Click the Run button (▶️) in the top bar
3. Wait for completion — nodes will display real-time status indicators

Image: Canvas showing nodes with status indicators during execution

Visual Web Flow Execution — Enterprise

When starting a full execution with the canvas Run button, disabling Headless on at least one Smart Web Flow, Web Flow, or Smart Locators node enables visual mode for that execution.

The behavior depends on where QANode is running:

Live View belongs to the execution started from the canvas, not to a single node. Therefore:

• the panel remains open until the execution succeeds, fails, is cancelled, or the user closes it;
• while the flow runs nodes that do not use a browser, such as HTTP Request, IF, database, or Wait, no new web image is produced and the last screen may remain visible;
• if another web node runs later, the same panel resumes following the browser without closing and opening a new window;
• keeping the panel open does not necessarily mean the previous browser is still running: the browser lifecycle still depends on the session strategy configured on the node.

This visual mode is enabled only for an interactive execution started by a user from the canvas. Suites, schedules, CI/CD, integration tokens, API, and other external processes do not automatically open a window or Live View.

When using Run in the properties panel, visualization remains limited to the selected node.

Execution Status

Cancelling Executions

Running executions can be cancelled by users with the run.cancel permission.

Where to cancel:

• Scenario editor: during execution, the run button changes to a stop button.
• Execution list: use the action menu for the running execution.
• Suite execution: cancelling the parent execution also cancels pending or running scenarios in that suite.

When cancelled, the final status is Cancelled. Evidence and logs already generated up to that point remain available for review.

Cancellation happens at safe execution points. Web, Smart Web, mobile, API, database, SSH, load, and custom JavaScript nodes check for cancellation while processing. For browser or mobile session nodes, QANode also tries to close opened resources to avoid stuck sessions.

A very long external action may finish its current segment before recognizing cancellation. In those cases, QANode cancels as soon as execution returns to a safe point.

Analyzing Results

After execution, click on any node to see its results in the properties panel:

Results Tab

Outputs

The outputs of each node are accessible to subsequent nodes via expressions. For example, after running an HTTP Request, the outputs will be:

{
  "status": 200,
  "body": {
    "id": 1,
    "name": "João",
    "email": "joao@exemplo.com"
  }
}

You can then access this data in subsequent nodes:

{{ steps["http-request"].outputs.body.name }}  →  "João"
{{ steps["http-request"].outputs.status }}     →  200

When an output is a file, the main value is a fileRef:

{{ steps["http-request"].outputs.fileRef }}
{{ steps["file-generate"].outputs.fileRef }}

In the variables panel, files show name, MIME type, and size in their details. Internal storage path fields are hidden from the main view.

Screenshots (Evidence)

For web nodes (Smart Web Flow, Web Flow, and Smart Locators), captured screenshots appear as clickable thumbnails. Click to view at full size.

Files

Files generated or captured during execution appear in the Files section of the execution detail. When downloading, the browser uses the real file name when available instead of an internal execution identifier.

Isolated test files created in the editor are temporary and can be cleaned up automatically when the user leaves the flow or by the cleanup routine.

Debugging Failures

Identifying the Problem Node

1. Look for nodes with a red border (🔴) on the canvas
2. Click on the failing node
3. Check the error message and the logs

Friendly Failure Hints

When a step fails with a known error, the run detail can show a Possible cause section with an objective suggestion. It appears only on failed steps, and QANode shows one hint at a time to avoid conflicting messages.

Hints cover common issues such as expired sessions, credentials, broken expressions, missing files, ambiguous targets, hidden, disabled, or read-only fields, blocked clicks, timeouts, assertion mismatches, and expected effects that did not appear after the action.

Use the hint as a starting point and confirm it with evidence, logs, and screenshots before changing the flow.

Common Error Messages

Web Flow / Smart Locators

HTTP Request

Database

SSH

Using Logs for Diagnosis

The logs of each node provide details about each executed step. For web nodes, logs show:

Navigated to: https://exemplo.com/login
Filled: "usuario@exemplo.com" on [getByLabel("E-mail")]
Clicked: [getByRole("button", { name: "Entrar" })]
Assert passed: textContains "Bem-vindo" — true

If a step failed, the log will show exactly which step and why:

Navigated to: https://exemplo.com/login
Filled: "usuario@exemplo.com" on [getByLabel("E-mail")]
ERROR: Click failed after 3 attempts: [getByRole("button", { name: "Login" })] — element not found

Debugging Tips

1. Disable Headless Mode

For web tests, disable headless mode on the node to see the browser in action:

• On the Smart Web Flow, Web Flow, or Smart Locators node, uncheck Headless
• When using Run in the properties panel, visualization shows only the selected node
• When running the full flow from the canvas on a server, Live View follows the complete web execution in the same panel
• Suites, schedules, CI/CD, and external calls continue running without opening interactive visualization

2. Add Wait Steps

If elements appear with a delay, add wait steps before interacting:

• wait with visible mode waits for the element to appear
• wait with networkIdle mode waits for all network requests to finish

3. Capture Screenshots for Diagnosis

Enable screenshots in before mode to see the page state before each action. This helps identify whether the page was in the expected state.

4. Check Expressions

If a node fails with an unexpected value, add a Log node before it to inspect the values:

Token value: {{ steps.login.outputs.body.token }}
Status: {{ steps["http-request"].outputs.status }}

5. Use the "Continue on Failure" Toggle

To diagnose multiple failures at once, enable Continue on Failure on verification nodes. This allows the flow to continue and you can see all failures in a single run.

Opening a Bug from a Failed Execution — Enterprise

When an execution ends with failure, the Open Bug button becomes available in the execution detail. Clicking it opens a modal to fill in the bug information — title, description, severity, priority, and other fields defined by the workflow.

The created bug is automatically linked to the execution, the scenario, and the step that caused the failure.

Permission required: bug.create

Related bugs

The execution detail also displays the Related Bugs section with the list of all bugs linked to that execution — bug key, title, status, and severity — with a direct link to each bug.

Execution Report

After each run, QANode provides a PDF report with:

• Execution summary (status, duration, date)
• Details of each step (status, logs, outputs, duration)
• Captured screenshots
• Errors encountered

The report is available in the project's execution list and can be downloaded or sent by email. Depending on the active template, the PDF can be generated automatically when the execution finishes or only when someone requests the download.

Next Steps

• Node Reference — Complete details of each node type
• Expressions — Master the dynamic data system