Writing tests for autonomous runs

When authoring test steps for autonomous execution with Autonomous Tester, follow these best practices.

Core principles

Follow these guidelines to create test steps so that Autonomous Tester can run more effectively.

Separate actions and validations into distinct steps.

Do not combine actions with validations in a single instruction.

Instead of this combined step:

Click the "Create User" button and verify the dialog appears.

Use these steps:

Click the "Create User" button.

Validate that the "Create User" dialog appears.
Use explicit and unambiguous UI instructions.
- Provide detailed step instructions. For example:
  
  Instead of:
  
  Navigate to Dashboard.
  
  Use:
  
  Click the "Dashboard" button in the top navigation bar.
- When validating status values, explicitly specify which status field, where it appears, and which value is expected. For example:
  
  Validate that the "Run Status" field in the Execution Summary section shows "Passed".
  
  This helps the agent identify the correct status field, especially when multiple statuses exist on the same page.
- When scrolling, define the target element or section. For example:
  
  Scroll down until the "Save" button is visible.
  
  Or:
  
  Scroll to the "Advanced Settings" section.
Ensure every important action has a validation step to confirm its success.

For example:

After saving or creating new entities, validate both the success message and the actual result.

Click the "Save" button.

Validate that the message "Saved successfully" is displayed.

Validate that the created item appears in the table.
Prefer deterministic and repeatable steps.

Use consistent, predictable values. For example:

Enter "Auto_Test_20260324_112500" in the Name field.
Avoid unsupported browser-level operations.

Use UI controls in your test steps.

Instead of:

Refresh the browser.

Use:

Click the "Reload Data" button.

Best practices when writing test steps

Apply these best practices when writing test steps:

Always validate navigation results.

After navigating to a page, confirm that the expected page is displayed.

For example:

Navigate to https://example.com.

Validate that the Example Home page is displayed.
Do not use the phrase "Navigate Back".

To navigate to a previous state or page, click a specific button or link.

Instead of:

Navigate Back.

Use:

Click the "Dashboard" button in the top menu.
Use exact button, menu, and field labels.

In your test steps, use UI object names as they appear in the application. For example:

Click the "Add Defect" button.
Clarify which object to use when multiple objects exist.

When the same text, button, or label appears multiple times on the page, provide additional context information to enable unique identification. For example:

Click the "Functional Testing" button under the Test Types section.

Or:

Click the "Delete" button in the first row of the table.

Additional context can include: section name, panel name, area on the page, button type, or link type. This helps the agent identify the intended element more accurately.
Locate before interacting.

In some cases, it is helpful to add a separate step for locating the relevant object, record, or field, before the step that performs the action. For example:
```
Locate the recipient called "Digital recipient".
Click on the recipient ID/Name to open it.
```
In a table, you can also provide row-level context. For example:
```
Locate the row containing "Test_Project_145".
Click the Delete button in that row.
```
Base waits on visible UI conditions.

Instead of adding steps that wait a specific length of time, wait for something in the UI. For example:

Wait until the "Dashboard" header is visible.
Use keyboard navigation when appropriate.

Press Tab to move from the First Name field to the Last Name field.
Avoid instructions that require decision making.

Split compound instructions into separate steps.

Instead of this combined step:

Validate that the popup appears, then click the Close button.

Use these steps:

Validate that the popup appears.

Click the "Close" button.
Use objective observable validations.

Replace abstract or subjective validations with objective ones.

Instead of:

Check everything is correct.

Use:

Validate that the status is "Active".
Provide field details when filling forms.

Enter "John" in the First Name field.

Enter "Doe" in the Last Name field.

Negative and informational test scenarios

For tests that validate error conditions or informational scenarios:

Explicitly control execution flow for negative tests.

Validate that the error message "Invalid credentials" is displayed.
Never rely on assumptions.

Instead of:

Assume the warning dialog appears.

Use:

Validate that the warning dialog is displayed.

Specific scenarios and tips

Apply these tips for common scenarios when writing tests for the Autonomous Tester.

Working with multiple browser tabs.

You can switch to a newly opened browser tab that was opened from an existing tab. Specify the tab by name or number. The tab number corresponds to its position (from left to right) in the browser's tab bar.

Switching back to the previous tab is also supported. For example:

Switch back to the 1st browser tab.

Go to the 3rd tab.

Add a validation step after switching to verify that the new browser tab is active before continuing. This helps ensure that the agent continues execution in the correct browser context.
Working with drop-down lists.

When interacting with drop-down lists, split the action into two steps: open the drop-down, then select the value. For example:

Click the "Role" drop-down.

Select "Admin" from the drop-down list.
Checkbox interaction using label click.

In some applications, clicking directly on a checkbox may not always register due to UI implementation. In such cases, explicitly instruct the agent to click the label next to the checkbox. For example:

Click the text label next to the checkbox to register the action.
Expanding sections.

You can interact with expandable and collapsible sections. When a section must be expanded before interacting with its fields, state so explicitly. For example:

Expand the "Configuration" section.

Validate that the Configuration section is expanded.
Use "Open" for navigation actions instead of "Click".

When the goal is to navigate into an item, entity, or details page, use Open to make the navigation intent clearer. For example:

Open the defect "Bug_123".

Validate that the defect details page is displayed.

Acceptable Autonomous Tester behavior

The Autonomous Tester can perform certain implicit actions to achieve test objectives:

Minor implicit actions are acceptable. For example, the agent might scroll to locate an object that is not immediately visible.
Validations determine success. Make sure your test includes steps that validate the expected outcome of implicit steps. For example, if you expect the agent to scroll and find a UI object, add a step that validates that the object was found.

Check your tests before running

Before running your test steps with Autonomous Tester, ensure that:

Each step has one clear action.
Validations are objective and observable, checking visible text, dialogs, or UI state changes.
All UI object references use exact labels, as they appear in the application.
Navigation steps are followed by validation steps that confirm the expected page loaded.
Negative test scenarios explicitly validate the expected error or warning conditions.