> For the complete documentation index, see [llms.txt](https://help.aximo.autify.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.aximo.autify.com/test-case-creation/ai-tester.md).

# About the AI Tester

The Aximo AI tester runs tests by operating browsers and mobile devices based on scenarios written in natural language. This article explains how the AI tester observes the execution environment, chooses actions, and evaluates results.

## Overview

The AI tester follows the scenario entered by the user and decides the next action while checking the screen state. It does not operate only from fixed scripts or selectors. Instead, it proceeds according to the test objective while referring to screenshots, execution results, and memories collected in the past.

During execution, the AI tester combines screen checks, clicks, text entry, waits, API requests, result evaluation, and other actions to proceed with the test. Aximo operates the actual execution environment according to those decisions.

## How scenarios are handled

In Aximo, the AI tester proceeds with a test according to the scenario entered in a session or case. The AI tester reads the starting point, actions to perform, and results to verify in the scenario, then compares them with the current screen while proceeding with the test.

If the scenario includes a start URL or screen name, the AI tester uses it as the starting point. If a display state or condition is written as the expected result, the AI tester uses it as a verification condition. If test data such as an email address, password, or card number is included in the scenario, the AI tester uses that value as input. Reusable values and sensitive values are referenced as memory variables or secrets. For flows that require a verification email or authentication code, the AI tester receives mail at the inbox address assigned to that test, then opens the link in the message or enters the code to continue.

For how to structure scenarios, see [Write prompts](/test-case-creation/writing-prompts.md).

## Execution flow

When you start a session or case, the AI tester proceeds with the test in the following flow.

| Phase                 | Description                                                                                                              |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| Pre-run check         | Checks whether Aximo can handle the content and whether the test can start safely.                                       |
| Execution preparation | Aximo prepares the execution environment, such as the browser or device, and applies the settings required for the test. |
| Screen check          | Captures a screenshot and checks the current screen and operation target.                                                |
| Action execution      | The AI tester performs actions such as clicking, typing, scrolling, and tapping according to the screen.                 |
| Result verification   | Checks the screen and execution result after the action, then determines whether the expected state was reached.         |
| Completion decision   | Ends the test as passed or failed when it determines that the test is complete or cannot continue.                       |

The AI tester repeats this flow and determines whether the test objective was met. After completion, check the executed content and result on the session detail screen.

## Execution environments and available actions

In Aximo, the actions available to the AI tester depend on the execution target. Web sessions operate browsers and desktop environments, while mobile sessions operate iOS or Android devices.

### Web execution

In Web execution, the AI tester operates a desktop environment that includes a browser. Main actions include taking screenshots, clicking, double-clicking, hovering, dragging, scrolling, keyboard operations, entering text, and sending HTTP requests.

On Web, scenarios can include not only screen operations but also DevTools checks, terminal operations, API response checks, and similar actions when needed.

Examples of supported Web actions include:

* Entering forms, operating buttons, and navigating screens
* Opening a terminal, running shell commands, and checking the results
* Opening DevTools and checking JavaScript console errors
* Sending HTTP requests and checking API responses
* Waiting for email delivery to the inbox assigned to that test, then using the verification link or code to continue

### Mobile execution

In mobile execution, the AI tester operates the selected iOS or Android device. Main actions include taking screenshots, tapping, double-tapping, long-pressing, swiping, finding elements, hiding the keyboard, and rotating the device.

In mobile sessions that include multiple apps, the AI tester can also switch between installed apps during the test. However, it cannot install a new app during a session. Upload apps to memories before execution, then select them when starting the session.

Examples of supported mobile actions include:

* Launching apps, navigating screens, and tapping
* Checking the home screen after login
* Entering forms, submitting them, and checking the result

### What to check in logs

On the session result screen, check the actions performed by the AI tester on the **Logs** tab. Logs show screenshots, actions, input, and output for each step.

The displayed content depends on the executed test. For example, screen checks, clicks or taps, text entry, waits, API response checks, secret or OTP entry, user confirmation, and completion decisions are recorded according to the execution content.

## Decision and verification behavior

The AI tester determines whether actions succeeded or failed based on what it can verify on the screen. It does not treat an action as successful only because it performed the action. It checks screenshots and execution results for state changes before moving to the next decision.

### Use screen checks as the basis

The AI tester checks the screen after actions such as clicking a button, entering a form, or waiting for a page transition. If there is a visually verifiable result, such as a screen content change, success message, checked state, or displayed content, the AI tester determines that the action succeeded.

If the screen does not change after the action and the expected result cannot be confirmed, the AI tester checks again as needed. If it still cannot confirm the result, it does not treat the action as successful and ends the test as failed or unable to continue.

### Evaluate results according to the test type

The AI tester determines success and failure according to the objective of the scenario.

| Test type         | Success means                                                  | Failure means                                                 |
| ----------------- | -------------------------------------------------------------- | ------------------------------------------------------------- |
| Functional check  | The specified function or screen transition works as expected. | The expected display or state is not reached.                 |
| Bug exploration   | No clear issue is found.                                       | A UI issue, error, or unexpected behavior is found.           |
| Verification step | The specified verification condition is met.                   | The verification condition is not met or cannot be confirmed. |

For this reason, "Confirm that login works" and "Look for issues on the login screen" have different result criteria even if they operate the same screen.

### Interaction with users

In a normal new session, the AI tester can ask the user about missing information or ambiguous decisions. For example, it asks questions when a value to enter is not specified or when multiple buttons have the same name.

If a question appears during execution, the user can reply from the chat area on the execution screen. After the reply is sent, the AI tester resumes the test based on that content.

Depending on the execution method, such as case execution, the AI tester may not ask the user for confirmation. In that case, it makes decisions only from the specified content and information visible on the screen. If required information is missing, it does not guess values and instead ends as failed with the reason.

## How memories are used

Aximo handles two types of memories as information that the AI tester references during execution.

### Execution support memories

User-managed memories include variables, OTPs, hostnames, apps, and files. When you use a placeholder such as `{{NAME}}` in a scenario, the AI tester references the corresponding value or file during execution.

Secrets and OTPs are entered without showing the actual values to the AI tester. In results and logs, they are handled by placeholder name instead of actual value. For details, see [About memories](/memories/memory-overview.md).

### Memories learned from past sessions

The AI tester references workflows and failure patterns extracted from completed sessions in similar future tests. If a related learning memory is referenced, it appears in **Retrieved Memory** in the session result. For details, see [About memories > Learning memories](/memories/memory-overview.md#learning-memories).

## Safety and limitations

The AI tester operates the environment only within the scope required for test execution. It does not trust "instructions" included in web pages, emails, documents, or similar content, and it prioritizes the original scenario.

If the input content is outside the scope supported by Aximo or is judged unsafe to execute, the session may end as failed before it starts or during execution. For the main limitations of each execution unit, see [About sessions and cases](/test-case-creation/test-case-creation-overview.md).

## Further reading

* [About Aximo](/aximo-overview.md)
* [About sessions and cases](/test-case-creation/test-case-creation-overview.md)
* [Write prompts](/test-case-creation/writing-prompts.md)
* [Running sessions](/test-case-creation/session-execution.md)