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

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

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
• Run the flow and observe the browser

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 automatically generates 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.

Next Steps

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