Writing tests for autonomous runs

When authoring manual tests for autonomous execution with Autonomous Tester, follow these best practices.

Core principles

Follow these guidelines to create manual tests 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.

Instead of:

Navigate to Dashboard.

Use:

Click the "Dashboard" button in the top navigation bar.
Ensure every important action has a validation step to confirm its success.

For example:

Click the "Save" button.

Validate that the message "Saved successfully" is displayed.
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 manual tests

Apply these best practices when writing manual 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.

Click the "Delete" button in the first row of the table.
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.

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 manual tests 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.