# What's New?

See the latest QApilot releases, including CoWork, PII exposure detection, and other recent product changes that affect testing workflows today.

### CoWork: Agentic Human-in-the-loop Test Authoring

CoWork is a new agentic test authoring mode on QApilot that converts natural language or BDD test cases into automated recordings - with the user remaining in control throughout.

Previously, automating a test case required either fully manual recording through the RPA module or utilising Crawler to generate tests autonomously. There was no middle path for teams that already had test cases written and wanted to automate them directly.

With CoWork, users can import or upload their existing test cases, review the auto-generated BDD steps, and trigger an AI planner that reads the screen at each step, takes the appropriate action, and automatically replans when it encounters unexpected UI states - without interrupting the user. Once the run completes, the user can accept the recorded steps or refine them in the RPA module before finalising!

CoWork covers 30–50% of test cases with an estimated 50% cost savings, and works alongside our Crawler and Record & Playback as the third mode of test authoring on QApilot.

***

### PII Exposure Detection In Network Logs

QApilot now automatically scans network logs during test execution to detect exposed PII data, flagging leakage across 8 sensitive data categories before it reaches production.

Previously, identifying personal data leaking through API calls or network requests required manual inspection of logs - a slow and error-prone process with no visibility during test runs.

With this capability, every test execution includes a scan of network traffic for 8 PII categories including email addresses, phone numbers, and financial identifiers. Any detected exposure is surfaced in the test report, giving teams a clear signal of data leakage risks without requiring additional configuration or tooling.

It is now possible to catch sensitive data exposure at the testing stage, before it reaches end users or auditors.


# Help and Support

Find built-in QApilot help resources, including demos, terms, local agent downloads, the status page, and links to product docs for quick support.

The QApilot application is equipped with a Help section that you can find on the bottom left of the screen.

<figure><img src="/files/2yoM141r2kP4p0Uu5hMX" alt=""><figcaption></figcaption></figure>

The help section has the following resources -

1. Demos
2. Terms & Conditions
3. Local Agent
4. Status Page
5. Documentation

### Demos

QApilot has interactive arcade demo videos embedded into the application. These demo videos cover all the basic important features that can help the user to get started with using the product.

<figure><img src="/files/yZNozgyKGGBXgWCQ0qMq" alt=""><figcaption></figcaption></figure>

The user can interact with the demos as shown in the above screenshot. The hotspots in the demos accompanied by the annotations give a comprehensive walkthrough of the product to the user. Furthermore, if the user wants to share these demo videos within the team, they can copy the video link and share it across. But note that these are accessible only after logging into QApilot.

### Terms and Conditions

The comprehensive terms and conditions of QApilot are listed here

### Local Agent

As discussed in this chapter - [Local Agent](broken://pages/w5bRQwuOaimZNA5tsTOM), this is for the set up of the QApilot Local Executor.

### Status Page

The status page redirects the user to <https://status.qapilot.io/> which shows the live status of QApilot's application at all times including any scheduled maintenances and production updates.

### Documentation

The documentation section redirects the user to the currrent documentation pages - <https://docs.qapilot.io/> that outlines the product features end to end.


# QApilot Getting Started

Start AI-native mobile testing with autonomous exploration, recording, natural-language authoring, cloud execution, and actionable reports.

Welcome to **QApilot**, the industry’s first **AI-native autonomous testing platform for mobile applications**.

QApilot enables you test your app’s critical flows from Day 0 with **zero-touch sanity testing**, and then scale to comprehensive coverage using record & playback, Appium scripts, or natural-language test creation, all in one unified system.

### Why QApilot?

Modern mobile apps evolve fast. Testing them shouldn’t slow you down.\
Traditional automation often breaks when the app changes, requires heavy setup, and delivers poor coverage vs. effort.

QApilot leapfrogs traditional mobile app automation by combining:

* **AI-Native Mobile App Crawler:** autonomously explores your app, maps screens, states, and user journeys.
* **Knowledge Graph Generation:** QApilot's crawler outputs a structured graph of your app, serving as a single source of truth.
* **Network of Intelligent Agents: A** team of specialized AI agents (for test creation, prioritization, data generation, auto-healing, bug reporting, accessibility, etc.) perform **zero-touch smoke testing**.
* **Extensible Platform:** Seamlessly integrate third-party tools or even your own custom agents.

With QApilot, you get **faster releases, higher coverage, and less maintenance overhead**.

### How It Works

1. **Upload Your App**\
   Upload your APK/IPA to QApilot.
2. **Crawler Generates a Knowledge Graph**\
   The crawler autonomously navigates your app, handling interruptions, indexing states, and building a knowledge graph of flows and screens.
3. **Zero-Touch Sanity Testing**\
   Our agent network uses the graph to automatically generate and execute smoke tests. No scripts or setup required.\
   You get instant feedback on app health.
4. **Scale Coverage**
   * Extend tests via **record & playback**
   * Create scenarios in **natural language (Copilot)**
   * Add **Appium/RPA scripts** where needed
5. **View Reports & Insights**\
   QApilot produces detailed reports with screenshots, logs, analytics, and regression comparisons. Failures can be auto-logged to Jira, Slack, Teams, or your CI/CD pipelines.

### Key Features

* **Zero-Touch Smoke Testing:** Critical flows validated without setup.
* **Record & Playback:** Simple, script-free test creation.
* **Copilot Mode:** Generate tests from natural-language prompts.
* **Extensible Agents:** Bring your own or use QApilot’s AI agents.
* **Seamless Integrations:** Jira, Slack, Teams, BrowserStack, SauceLabs, CI/CD pipelines.
* **Debug & Auto-Heal:** Local agent debugger, self-healing flows.
* **Comprehensive Reports:** Dashboards and report comparisons.


# Set Up QApilot

Set up QApilot access, sign in, and prepare local or cloud mobile testing.

To start using **QApilot**, you can request to be part of the Beta Program by visiting our website and following the instructions. Alternatively, you can contact our [support team](https://qapilot.io/) to express your interest in joining the Beta Program. Once you are shortlisted for our Beta Program, we will reach out to you with the next steps.

Upon successful enrollment in the Beta Program, users can gain access to **QApilot** and begin using its features for their quality assurance and mobile automation testing needs.

***

## Setting up QA pilot Account:

Since the tool is currently in closed beta, setting up an account will be via request from our website.

Once shortlisted, they would receive credentials to log in. Using this account, you can invite other users.

<figure><img src="/files/F26c6lkkVd8MwFjMUZsh" alt=""><figcaption></figcaption></figure>

In this case, users invited by the admin will need to wait to receive an invitation from the admin to create an account.

1. **Receive an Invite:** You will receive an email invite to join **QApilot**.
2. **Follow the Link:** Click on the link provided in the email invite to go to the **QApilot** sign-up landing page.
3. **Email Confirmation:** Once the account is set up successfully, you will receive an email confirmation regarding the successful account setup.
4. **Login:** Use your credentials to log in to **QApilot**.

**For the Existing User:**

You can log in with your GitHub account and also log in with your email ID linked to the account.

***

## How To Access the QApilot?

1. Enter the Login credentials (Email ID and password). Click Login.
2. It redirects to the Dashboard screen.
3. The Dashboard displays all the existing Projects along with their current status.
4. For Users, Users can only view projects that are assigned to them

<figure><img src="/files/3fSDYtPQCydo9ET1cJT5" alt=""><figcaption></figcaption></figure>

***

## Creating Projects, Tests, and Reports?

* To create and manage projects, refer to [projects](/ai-and-core-concepts/projects)
* To create and manage test cases, refer to manage [test cases](/test-creation/create-and-manage-mobile-test-cases).
* To add test steps, refer to [Create test steps](broken://pages/eR69n9Ipg3JT4Y7cbgAL).
* To run tests, refer to [test runs](/execution-and-reliability/run-mobile-test-plans).
* To view results and debug errors, refer to view [reports](/reports-security-and-release-readiness/mobile-test-execution-reports) & debug errors.


# System Requirements

Review the hardware, software, and OS requirements for cloud testing and local Android or iOS execution on Windows, macOS, and Linux devices.

To ensure a seamless experience using **QApilot**, here are some general hardware and software requirements that you need to consider:

## Cloud Device Testing

* **Hardware:** Windows or Mac laptop with a minimum of 8GB RAM.
* **Internet Connection:** A stable internet connection to access the cloud platform and execute tests.
* **Supported Browsers:** Latest versions of Chrome, Firefox, Safari, or Edge.

## Local Device Testing - For Windows

* **Operating System:** Windows 10 or later
* **Hardware:** Minimum of 8GB RAM, 2GHz dual-core processor.
* **Software:**
  * Install [**QApilot** executor](broken://pages/w5bRQwuOaimZNA5tsTOM)
* **Mobile Configuration:** Developer options on mobile must be enabled.

## Local Device Testing - For Mac (Android Local Execution):

* **Operating System:** MacOS 10.14 (Mojave) or later.
* **Hardware:** Minimum of 8GB RAM, 2GHz dual-core processor.
* **Software:**
  * Java JDK 8 or later
  * Node.js 12 or later
  * Android SDK (for Android app testing)
  * [**QApilot** Local Executor](broken://pages/w5bRQwuOaimZNA5tsTOM)
* **Mobile Configuration:** Developer options on mobile must be enabled.

## Local Device Testing - For Mac (iOS Apps Local Execution):

* **Operating System:** MacOS 10.14 (Mojave) or later.
* **Hardware:** Minimum of 8GB RAM, 2GHz dual-core processor.
* **Software:**
  * Java JDK 8 or later
  * Node.js 12 or later 3.Xcode
  * WebDriver
  * [**QApilot** Local Executor](broken://pages/w5bRQwuOaimZNA5tsTOM)
* **Mobile Configuration:** Developer options on mobile must be enabled.

## Local Device Testing - For Linux:

* **Operating System:** Linux.
* **Hardware:** Minimum of 8GB RAM, 2GHz dual-core processor.
* **Software:**
  * Java JDK 8 or later
  * Node.js 12 or later 3.Xcode
  * android studio
  * [**QApilot** Local Executor](broken://pages/w5bRQwuOaimZNA5tsTOM)
* **Mobile Configuration:** Developer options on mobile must be enabled.


# Local Recording and Execution

Set up local recording and execution on Windows, macOS, Linux, or iOS, including software installs, device connection, and launch steps for testers.

## QApilot Executor Local Agent

**QApilot** allows you to run tests on your local machines. To run the tests locally, you need a small QApilot Local Agent (Java) utility running on the machine for test orchestration, i.e., queueing tests, running the tests, fetching the test results, etc.

### Prerequisites

* You should have a QApilot Local agent on your machine.
* Enable Developer options on your mobile device.

### Updating QAPilot Local Agent - New Version

1. Navigate to **Local Agent** and click **Download Agent**.

<figure><img src="/files/YZkNOxYmsh9oxuTdgZN2" alt=""><figcaption></figcaption></figure>

2. It will redirect to the below window. Check the new and old versions of the local agent executor files for Windows, Max, and Linux devices.

<figure><img src="/files/2bh30AGDmbbu1mIwLAH4" alt=""><figcaption></figcaption></figure>

3. Also, you can refer to the document and video demo for installation instructions on the devices listed in the top right corner.

When using **QApilot** for test recording with local devices, the process typically involves setting up the devices on your local network → device/system, and configuring them to work with the **QApilot** platform.

* [x] Connect the device to your system. Ensure you have enabled developer options for local testing and the **QApilot** Local Executor (Local Agent) is installed and running.
* [x] The connected device will automatically be displayed on the Test Recording Screen.

## **Software Installation:**

### Install Required Software:

<figure><img src="/files/EnILuTPTkBu9L2W0LUrU" alt="Windows , Mac Android, Mac IOS, Linux"><figcaption><p><a href="#for-windows">Windows</a>, <a href="#for-mac-android">Mac Android</a>, <a href="#for-mac-ios">Mac IOS</a>, and <a href="#for-linux">Linux</a></p></figcaption></figure>

## How To Connect to the Local Device?

### Prerequisites

Ensure you create a [Project](/ai-and-core-concepts/projects). Logging into the QApilot UI is a prerequisite for accessing the Projects Menu. The Projects Home page is the first screen shown after the respective user's successful login. Click the Project card to make the changes or [Create a New Project](/ai-and-core-concepts/projects#how-to-create-a-new-project).

1. Click on the Project Card. Select the Recorder option from the Configurations list.\ <br>

   <figure><img src="/files/weOTBr1oixQ5phP41U2D" alt=""><figcaption></figcaption></figure>
2. The first step is to set the Connection type—selecting the kind of Environment, Cloud or Local.<br>

   <figure><img src="/files/JXu8PP2gc8cobBhmg2QE" alt=""><figcaption></figcaption></figure>
3. Select Local Devices → It will redirect to the below screen:

<figure><img src="/files/mIapURdXsMaqU4YjPcTp" alt=""><figcaption></figcaption></figure>

4. Depending on your choice, select a Desktop OS: Windows, Mac, or Linux. Connect your mobile device to your laptop or desktop.

Local Devices refer to physical devices on which the Test cases are run to check the respective app's functionality. Cloud devices refer to the devices present in the Cloud farm.

The Cloud Device setup will enable running the Test Cases on multiple mobile devices as they are integrated/configured to be part of the Automation testing environment. This arrangement will facilitate the Test Cases' check to understand the application's compatibility.

### For Windows:

#### Pre-requisites:

1. **Administrative Privileges:** The script requires administrative privileges to modify system environment variables and install applications.
2. **JDK and Android SDK Directories:** Ensure the JDK and SDK folders are located in the same directory as the script.
3. **install** [**local agent QApilot Local executor**](broken://pages/w5bRQwuOaimZNA5tsTOM).

#### Installation Steps to follow:

1. Uninstall any previous **QApilot** builds if any.
2. Run the install.bat file.
3. If all prerequisites are met, the Setup Wizard will automatically open.
4. Follow the basic instructions & wait for the installation to complete.
5. Restart the system.
6. Run the QApilot application from your installed directory.

### For Mac Android:

#### Install android SDK

To download the latest version of Android SDK, navigate to the link [Download Android SDK](https://developer.android.com/tools/releases/platform-tools?_gl=1*1yubow8*_up*MQ..\&gclid=Cj0KCQjwiOy1BhDCARIsADGvQnBWvkKppBLUL3KnC1pGWfZRm8He13ZcG6OXsoBd1rkDhZ01kGFgXp0aAkNNEALw_wcB\&gclsrc=aw.ds)

#### Install node.js

To download the latest version of Node.js, navigate to the link [Download Node.js](https://nodejs.org/en/download)

**Download and install** [**local agent QApilot Local executor**](broken://pages/w5bRQwuOaimZNA5tsTOM)

**Install Java and Set the Path**

1. Download the JDK from Oracle's website or use `Homebrew` to install it:

   ```
   brew install openjdk@11
   ```
2. Set up the JDK environment file:
3. echo 'export PATH="/usr/local/opt/openjdk\@11/bin:$PATH"' >> \~/.zshrc
4. echo 'export JAVA\_HOME=$(/usr/libexec/java\_home -v 11)' >> \~/.zshrc
5. source \~/.zshrc

#### Install Android Studio and Set the Path

1. Download Android Studio from the official website.
2. Run the installer and follow the setup wizard.
3. Open the downloaded file and drag Android Studio to the Applications folder.
4. Open Android Studio and follow the setup wizard.
5. Open a terminal and find the SDK path: open -e \~/.zshrc
6. Add the following lines (adjust the path as needed):
7. export ANDROID\_HOME=$HOME/Library/Android/sdk
8. export PATH=$PATH:$ANDROID\_HOME/emulator
9. export PATH=$PATH:$ANDROID\_HOME/tools
10. export PATH=$PATH:$ANDROID\_HOME/tools/bin
11. export PATH=$PATH:$ANDROID\_HOME/platform-tools
12. Save the file and reload the terminal: source \~/.zshrc

### For Linux:

#### Install android SDK

To download the latest version of Android SDK, navigate to the link [Download Android SDK](https://developer.android.com/tools/releases/platform-tools?_gl=1*1yubow8*_up*MQ..\&gclid=Cj0KCQjwiOy1BhDCARIsADGvQnBWvkKppBLUL3KnC1pGWfZRm8He13ZcG6OXsoBd1rkDhZ01kGFgXp0aAkNNEALw_wcB\&gclsrc=aw.ds)

#### Install node.js

To download the latest version of Node.js, navigate to the link [Download Node.js](https://nodejs.org/en/download)

**Download and install** [**local agent QApilot Local executor**](broken://pages/w5bRQwuOaimZNA5tsTOM)

#### Install Java & Set Path

1. Download the JDK from Oracle's website
2. Set up the JDK environment file:
3. echo 'export PATH="/usr/local/opt/openjdk\@11/bin:$PATH"' >> \~/.zshrc
4. echo 'export JAVA\_HOME=$(/usr/libexec/java\_home -v 11)' >> \~/.zshrc
5. source \~/.zshrc

#### Install Android Studio & Set the Path

1. Download Android Studio from the official website.
2. Run the installer and follow the setup wizard.
3. Open the downloaded file and drag Android Studio to the Applications folder.
4. Open Android Studio and follow the setup wizard.
5. Open a terminal and find the SDK path: open -e \~/.zshrc
6. Add the following lines (adjust the path as needed):
7. export ANDROID\_HOME=$HOME/Library/Android/sdk
8. export PATH=$PATH:$ANDROID\_HOME/emulator
9. export PATH=$PATH:$ANDROID\_HOME/tools
10. export PATH=$PATH:$ANDROID\_HOME/tools/bin
11. export PATH=$PATH:$ANDROID\_HOME/platform-tools
12. Save the file and reload the terminal: source \~/.zshrc

Once the installations are done for your choice of OS. Extract the Local Agent launcher file.

### For Mac IOS:

#### Install Java and Set Path:

1. Download the JDK from Oracle's website [Click Here](https://www.oracle.com/in/java/technologies/downloads/) or use `Homebrew` to install it:

   ```java
   brew install openjdk@11
   ```
2. Check how to set the path [Click Here](https://docs.oracle.com/en/java/javase/23/install/installation-jdk-macos.html#GUID-C5F0BF25-3487-4F33-9275-7000C8E1C58C)

#### Install Android Studio & Set the Path

1. Download Android Studio from the official website. [Click Here](https://shorturl.at/DhMxr)
2. Check how to set the path [Click Here](https://developer.android.com/tools/variables)

#### XCode installation

1. Log in with the Developer Account on the Apple website.
2. Go to the downloads page [(https://developer.apple.com/download/)](https://developer.apple.com/download/) and download the latest version of Xcode
3. After the download is completed, double-click on the dmg file of Xcode.
4. Drag the Xcode dmg file to the application folder.

#### Install node.js

To download the latest version of Node.js, navigate to the link [Download Node.js](https://nodejs.org/en/download)

**Download and install** [**local agent QApilot Local executor**](broken://pages/w5bRQwuOaimZNA5tsTOM)

#### Update WebDriverAgent

Download the source code of the latest version of WebDriverAgent from the below link <https://github.com/appium/WebDriverAgent/releases/latest>

### Extract Local Agent:

1. Extract the **Executor** zip file

<figure><img src="/files/8UYtc2LpTiHqznKGGByE" alt=""><figcaption></figcaption></figure>

2. Open **CMD** from the same file location

<figure><img src="/files/Y356908spQMGke170hDk" alt=""><figcaption></figcaption></figure>

3. Enter **npm i** for the first time, once the **installation** is done.

<figure><img src="/files/rrHalmKRXAvk3JQ7mYNQ" alt=""><figcaption></figcaption></figure>

4. Enter **npm start**, if the **Android SDK** **path** is set and corrected the respective screen is displayed.

<figure><img src="/files/69BSn7xU41qcd3AqZjgI" alt=""><figcaption></figcaption></figure>

5. The respective **Physical Device** will be displayed in the **Device** dropdown.
6. Enable **Developer Tools/Options** on the connected **Device/Mobile.**
7. Enable **USB Debugging**.

Applying the above two steps is mandatory to add the respective **Device** details to the QA pilot UI.

The **Mobile settings** of **Developer Tools** and **USB Debugging** for the QA pilot UI will fetch the device details. The user can use any search engine (Google/Bing) to understand how to enable the required mobile settings for the respective model (mobile company & model).

Unless the above two settings are enabled on the **Device** to be selected, the **Device** details are not shown under the **Device** dropdown to proceed to the next step.

<figure><img src="/files/7CmpoaNi7ga5J6lIZbOO" alt=""><figcaption></figcaption></figure>

8. Select the respective options from various fields(**App**, **Module, Testcase**, **Page, and VPN Required**) on **Select App & Testcase** as shown above.

The **user** can select the options from the dropdown or **click the button to create a new element for every field**.

**New element creation:**

* **Module**
* **Testcase**
* **Page**

<figure><img src="/files/w2V7BZsvlLUsr0WPCHgK" alt=""><figcaption></figcaption></figure>

9. Select App from the drop-down to test.
10. For Module:

Create Module

<figure><img src="/files/TYdLkwY63VHhZr4mZnHb" alt=""><figcaption></figcaption></figure>

11. Create a **test case** and click on the **Create** button.

<figure><img src="/files/Y0dlowGaqpdX0AnGxJ1S" alt=""><figcaption></figcaption></figure>

12. For **Page:**

Page Title

<figure><img src="/files/pF65KJlAPx5Lvkc7GUkC" alt=""><figcaption></figcaption></figure>

13. **VPN Required** is optional. If a **VPN** is required, then a **local executor** should be running.

<figure><img src="/files/A0yTQsQyJdiLNa64qQEW" alt=""><figcaption></figcaption></figure>

14. click on **Launch** to establish a connection to your local device.

<figure><img src="/files/x7RlrKlgROdtcMCvqSqE" alt=""><figcaption></figcaption></figure>

15. The **device** will be successfully **connected** and the below **Recording Screen** will be displayed.

<figure><img src="/files/3WO2dSxNbbGvI20upWJc" alt=""><figcaption></figcaption></figure>


# Cloud Device Recording and Execution

Record and run Android and iOS mobile tests on supported cloud devices by uploading APK or IPA builds and configuring a provider connection.

## Cloud Device Recording and Execution

QApilot lets you record and automate mobile tests on supported cloud-hosted devices. Upload an Android APK or iOS IPA, configure a cloud provider connection, and start a recording session.

Cloud recording creates reusable mobile test steps without manually writing test code. A provider connection supports one simultaneous test session by default.

By default, Cloud Device Provider allows users to run a single testing session simultaneously. If you need to run multiple testing sessions simultaneously across different devices, browsers, or operating systems, contact the team through the [QApilot website](https://qapilot.io/) to discuss your requirements and upgrade options.

### Software Required For Cloud Recording:

APK/IPA File is Required (according to the selected OS):

1. **An Android APK**: An APK file (Android Package Kit) is the file format used by the Android operating system to distribute and install apps. It contains all the elements necessary for an Android application to be installed and run on a device.
2. **IOS IPA**: An IPA file (iOS App Store Package) is the file format used by the iOS operating system to distribute and install applications on iPhone, iPad, and iPod touch devices. IPA files are specifically designed for Apple devices and can only be installed on devices running iOS, iPadOS, or macOS (with some modifications).

## How to Connect to the Cloud Device?

### Prerequisites

Ensure you create a [Project](/ai-and-core-concepts/projects). Logging into the QApilot UI is a prerequisite for accessing the Projects Menu. The Projects Home page is the first screen shown after the respective user's successful login. Click the Project card to make the changes or [Create a New Project](/ai-and-core-concepts/projects#how-to-create-a-new-project).

1. Click on the Project Card. Select the Recorder option from the Configurations list.\ <br>

   <figure><img src="/files/TSMBRVUUtPqNn1kqquQr" alt=""><figcaption></figcaption></figure>
2. The first step is to set the Connection type—selecting the kind of Environment, Cloud or Local.\ <br>

   <figure><img src="/files/TquvHJlJZcnInQpYK0VQ" alt=""><figcaption></figcaption></figure>
3. Select the kind of Environment, Cloud or Local. Please select Cloud Devices.

<figure><img src="/files/ZSG4Jh1qYGz0wt0y6qLm" alt=""><figcaption></figcaption></figure>

4. Choose Cloud Devices. The Operating System(OS) (Android/IOS) will appear as follows. Select your choice based on the Device to be tested.
5. Configure Cloud Device Provider Integration. Add New and it redirects to the below window:

<figure><img src="/files/nAeuUPjoA3jx8e5Ov1Nj" alt=""><figcaption></figcaption></figure>

6. As you can see, the **QApilot** supports integrations with several third-party tools, including Browser Stack, testrail, JIRA, Sauce Labs, Microsoft Teams, and Slack. Configure Cloud Device Integration. Enable Browser Stack for your integration. You can click on [Integrations](broken://spaces/f7DuCvkprTM62hS3tKQF/pages/k71vcGDL62El4vhKwFIW) to integrate with various other tools.

Browser Stack is a cloud-based cross-browser testing platform that allows admins/users to test their mobile applications across different browsers, operating systems, and devices. It provides a wide range of real, physical devices for testing, along with automated and live interactive testing capabilities. This helps developers and QA teams ensure their products are compatible and function properly across diverse environments.

<figure><img src="/files/u1bZXOhATqOm8wZ8FUxO" alt=""><figcaption></figcaption></figure>

7. Click on Yes to integrate for this cloud device.

<figure><img src="/files/BxmNnXWgvHpHesUMoBLg" alt=""><figcaption></figcaption></figure>

8. Select Appium Version as currently, the **QApilot** is running on the latest version v1.22.3.
9. Select your Device from the dropdown, and click Next.

In this Step, select App & Testcase and the Page where the Test Case is applied.

App name is the Application Name. The module is a scenario or functional need served by the App. Test Cases are the aspects to check the functional ability of the app for real-time scenarios. Page is the screen/location where the whole functionality is implemented within the app.

<figure><img src="/files/Y4KNh2CPTakNywDmZYoc" alt=""><figcaption></figcaption></figure>

Select the OS (Android or iOS) and the app you want to test. The app names will be displayed. Choose the Application Name for the app you wish to test.

It is a general configuration in any Application that, depending on the App Source, the Modules are synced and displayed in the Module dropdown. The Test Case dropdown displayed only those scenarios relevant to the opted Module. Pages are displayed only related to the App Source and Module. App Source, Module, Test Case, and Page are designed to be in sync concerning the functionality or the feature of the App.

10. Select App and Test Cases. When you click on APP, it will redirect to the below screen.

<figure><img src="/files/9vnIPqa1wQ4t0XN6Tk1x" alt=""><figcaption></figcaption></figure>

11. As you can see above, Enter the Title.
12. As the Test recording is for a cloud device, Select the location as a cloud.
13. Select service from the dropdown. Cloud Device Integration before the App upload
14. Here, We need to upload the APK/IPA file as we selected Cloud Devices. It is mandatory to note that, for Cloud Devices, an **APK/IPA file** should be provided.
15. As we have selected for Android, Once we upload the APK file\*\*,\*\* the Package Name and Version Name will automatically be fetched.
16. Click on the Launch button to initiate a session on the selected device.

<figure><img src="/files/vEVTE1pIE2Ww8V5ttfcG" alt=""><figcaption></figcaption></figure>

17. For Module:

Create Module

<figure><img src="/files/QCXGAyuyIv9ZTlmpJCrU" alt=""><figcaption></figcaption></figure>

18. Create a Test case and click on the Create button.

<figure><img src="/files/JKFp69lFKJZ2lJhWqZzz" alt=""><figcaption></figcaption></figure>

19. For Page:

Page Title

<figure><img src="/files/keBCiZXBKCM9wHx5whIC" alt=""><figcaption></figcaption></figure>

20. VPN Required is optional. If a VPN is required, then a local executor should be running.

<figure><img src="/files/aWVes1WH7bFaW9EtfwxV" alt=""><figcaption></figcaption></figure>

21. Click on Launch to establish a connection to your Cloud device.

<figure><img src="/files/pDHJ82D5PuhfwfiLHxlr" alt=""><figcaption></figcaption></figure>

22. The device will be successfully connected and the below Recording Screen will be displayed.

<figure><img src="/files/A4WFBIsGBviZF4dbP9gu" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/Vm0HzWyNgzJCoXPvHhtu" alt=""><figcaption></figcaption></figure>

### Record Flutter Apps with Flutter Driver

When starting a recording session, select **UIAutomator2** or **Flutter Driver** to initialize the session with the correct dependencies.

* The default recording mode remains UIAutomator2 (standard context) unless a specific type is selected.
* Selecting Flutter triggers the session with Flutter-specific dependencies, using the same initialisation logic as standard sessions.
* This option is available on the recording setup screen before a session begins.

<figure><img src="/files/sYxEoV8VHEw2KcZalX4H" alt=""><figcaption></figcaption></figure>

### LambdaTest Fingerprint Authentication Support

Fingerprint authentication can be bypassed during recording and execution on LambdaTest. This supports test flows that include a fingerprint-gated identity module without manual intervention.

#### How it works

* When a fingerprint authentication prompt is triggered during a test flow, a dummy screen is rendered in its place, allowing the user to proceed with testing.

**Supported authentication type:** Fingerprint

> **Note:** This capability is currently available on LambdaTest only.


# Android and iOS Mobile Testing Quickstart

Start recording and running mobile tests for Android or iOS apps with QApilot on local devices or supported cloud device providers.

## Android and iOS Mobile Testing Quickstart

Start with a project, connect a device, record a critical flow, then run it through a test plan. QApilot supports local and cloud workflows for Android and iOS apps.

### Before you begin

You need access to QApilot and an app build. Cloud workflows require an Android APK or iOS IPA. Local workflows require the supported device and local setup.

Review [System Requirements](/getting-started/set-up-qapilot/system-requirements) before configuring your environment.

### Quickstart

{% stepper %}
{% step %}

### Create a project

Create a [project](/ai-and-core-concepts/projects) for the app and test assets.
{% endstep %}

{% step %}

### Choose a device connection

Use [local recording and execution](/getting-started/set-up-qapilot/local-recording-and-execution) for a connected device. Use [cloud recording and execution](/getting-started/set-up-qapilot/cloud-device-recording-and-execution) for a supported cloud provider.
{% endstep %}

{% step %}

### Record one critical flow

Start with a high-value journey, such as sign-in or checkout. Capture it with the [test recorder](/test-creation/record-mobile-test-steps/create-test-steps-with-the-test-recorder). Review each recorded step before saving.
{% endstep %}

{% step %}

### Run a test plan

Create a [test suite](/test-creation/test-suite) if the flow has multiple cases. Configure a [test plan](/execution-and-reliability/run-mobile-test-plans), select the OS, device, app source, and test data.
{% endstep %}

{% step %}

### Review evidence

Open the resulting [report](/reports-security-and-release-readiness/mobile-test-execution-reports). Review step outcomes, screenshots, logs, and videos when enabled.
{% endstep %}
{% endstepper %}

### Android considerations

The Android crawler can explore and record flows on local or cloud devices. CoWork also currently supports Android on LambdaTest.

### iOS considerations

Use the standard recording and execution workflow for iOS. For shared Android and iOS cases, follow the [cross-platform execution guidance](/mobile-testing/cross-platform-execution-for-android-and-ios).

### What to do next

Create a small smoke suite first. Then add regression coverage around important business journeys.

* [Test Recording](/test-creation/record-mobile-test-steps)
* [Schedule Test Plans](/execution-and-reliability/schedule-test-plans)
* [AI-Native and Agentic Mobile Testing](/ai-and-core-concepts/ai-native-and-agentic-mobile-testing)


# QApilot Overview

Learn how QApilot provides AI-native mobile testing for Android, iOS, and Flutter apps through test creation, execution, and evidence-rich reporting.

## What is QApilot?

QApilot is an AI-native mobile testing platform for Android, iOS, and Flutter apps. Teams use it to explore, create, run, and review automated mobile tests on local or supported cloud devices.

QApilot supports recorded test steps, autonomous Android exploration, human-in-the-loop authoring, and evidence-rich execution reports. It also integrates with cloud device providers, CI/CD workflows, and collaboration tools.

Use QApilot to build repeatable coverage for critical mobile flows. Review reports, artifacts, and healed steps to investigate failures and maintain tests across releases.

***

Core concepts:

* [**Record Mobile Test Steps**](/test-creation/record-mobile-test-steps): Record reusable interactions, then organize them into [test suites](/test-creation/test-suite).
* [**Run Mobile Test Plans**](/execution-and-reliability/run-mobile-test-plans): Configure and execute coverage on local or supported cloud devices.
* [**Cloud Device Recording and Execution**](/getting-started/set-up-qapilot/cloud-device-recording-and-execution): Upload mobile builds, select a provider connection, and start cloud sessions.
* [**Mobile Test Execution Reports**](/reports-security-and-release-readiness/mobile-test-execution-reports): Investigate outcomes with step-level evidence and artifacts.
* [**API Test Automation**](/test-creation/api-test-automation): Configure and run API requests and collections alongside mobile testing workflows.

***

## Getting Started with Automation Testing

Start with a project, an app source, and a local or cloud device connection. QApilot supports two primary execution environments:

### [Local Device Testing](/getting-started/set-up-qapilot/local-recording-and-execution)

Local device testing is testing mobile applications directly on physical devices you can access. Unlike cloud-based testing platforms, where tests run on remotely hosted devices, local device testing requires testers to interact directly with the hardware. This method is beneficial for validating real-world interactions and device-specific behaviors.

### [Cloud Device Testing](/getting-started/set-up-qapilot/cloud-device-recording-and-execution)

Cloud Device Testing involves running automated test scripts on real devices and emulators hosted in the cloud device farm. Since these devices are hosted on cloud-based servers → cloud, they’re accessible online at all times. Such a testing infrastructure is called a real device cloud → device farm which facilitates effective cloud testing.

**QApilot** integrates with cloud device providers such as BrowserStack and Sauce Labs. For cloud-provider setup, see [Integrations](/integrations).

***

### Cloud Architecture:

This image shows a cloud-based architecture for an automation testing solution **QApilot**. Here’s a breakdown of the components and how they interact:

<figure><img src="/files/hQrixtRJ23WpVtDUHUAD" alt=""><figcaption></figcaption></figure>

1. **Client Apps**:
   * **App UI Interface**: The front-end interface users interact with.
   * QApilot supports local device execution. See [Local Recording and Execution](/getting-started/set-up-qapilot/local-recording-and-execution) for setup and connection steps.
2. **API Layer**:
   * **Core APIs**: Core functionality exposed as APIs for client apps to interact with the backend services.
   * **Webhooks**: Enable asynchronous communication and event-based updates between the system and external integrations.
3. **Microservices**:
   * **Authentication**: Manages user login and security protocols.
   * **Tenant Manager**: Manages multi-tenant environments, allowing multiple clients or users to operate in isolated segments.
   * **Device Management**: Handles devices used for testing.
   * **Application Data Manager**: Manages application data required for test cases and configurations.
   * **Visual and Text AI Modules**: AI-powered modules for image recognition and text analysis in testing.
   * **Reporting**: Generates reports on test execution and results.
   * **Executions Manager**: Manages test execution workflow.
   * **Network Tracer**: Monitors and logs network traffic for analysis during tests.
   * **Others**: Placeholder for additional microservices that support other functionalities.
4. **Infrastructure Layer:**
   * **Cloud Storage**: Stores large files or test data.
   * **Database**: Stores application data, configurations, test results, etc.
   * **Logs**: Maintains logs for monitoring and troubleshooting.
   * **Cache**: Used for caching frequently accessed data to improve performance.
5. **Integrations**:
   * **Device Farms**: External device farms (BrowserStack, Sauce Labs) for testing across different devices and configurations.
   * **CI/CD**: Continuous integration and deployment help automate the testing workflow.
   * **Test Management**: Teams manage test cases, suites, and plans in QApilot.
   * **Defect Management**: The [Jira integration](/integrations/jira) supports issue creation from test workflows.
   * **Social Apps**: Integration with communication platforms like Microsoft Teams for notifications and updates.

This architecture supports modularity, scalability, and integration with various testing and development tools, enabling efficient automation testing workflows and management across different devices and environments.


# QApilot Terminology

Learn QApilot terminology for test cases, suites, data, rules, recorders, pages, and modules so teams share a common testing language internally.

Here are some common terminologies related to **QApilot** that you may come across:

### Test Case

A test case is a list of steps or user actions that you list in a specific order to automate a test scenario. Test cases are conditions or steps designed to evaluate a particular feature or functionality of a software application. Users can create test cases using the **QApilot** Recorder or create steps manually.

***

### Test Suite

A test suite is a collection or grouping of individual test cases that are organized together to execute them as a single entity. **QApilot** organizes your test cases into test suites based on common functionalities or scenarios to manage and execute them effectively. Test suites will help you in executing and reporting the test plan status. You can add a test case to multiple test suites.

***

### Test Data

In **QApilot**, Test Data displays the details of the data sets utilized in different test scenarios. You can create and save data sets for various environments. The details of these data sets, such as the values used, are displayed in this tab.

***

### Test Rules

**QApilot** Test Rules feature facilitates the appending/associating of relevant Test Data to the Test Cases under the respective Test Suite. They provide structure to the automation testing process and help ensure that tests are executed consistently, producing reliable and accurate results.

***

### Test Recorder

Test Recorder lets you capture Elements and actions within **QApilot**. We recommend using the Test Step Recorder since it's quicker and easier and captures more locator details than manually creating elements.

***

### QApilot Executor as Local Agent

You can run the tests you create on **QApilot** on your local device. For running the tests locally, you need a Local Agent utility running on the machine for Test Orchestration (queueing Tests, running the Tests, fetching the Test Results, etc.).

***

### Page

Page in App Upload flow used in **QApilot** refers to a distinct screen or interface where specific functionality is implemented. It represents a logical section or module within the app. Each page in an app is designed to deliver a specific user experience, often related to a particular task or flow.

***

### Module

A module in an application used in **QApilot** represents a self-contained unit that provides a specific feature or fulfills a functional need within the app. Each module typically focuses on delivering a specific scenario or workflow that aligns with the user’s needs.


# Projects

Create, edit, filter, team-manage, and disable QApilot projects, then use each project as the starting point for recording and crawling workflows.

1. You must have a **QApilot** account: If you haven't already, You can contact our [support team](https://qapilot.io/) to express your interest in trying out QApilot. Our team will reach out to you with the next steps.
2. App Framework of the respective mobile application that you are testing. Click on the [App Frameworks](https://technostacks.com/blog/mobile-app-development-frameworks/) for more information.

***

#### How to Create a New Project? <a href="#how-to-create-a-new-project" id="how-to-create-a-new-project"></a>

1. On the Projects Home page, click the Add+ icon on the top-right corner beside the Filter icon as shown below.
2. A side window overlaps the Home page to Create Project as shown below.\
   ​

   <figure><img src="/files/Zb2DtDDxs7PzebJCHQql" alt=""><figcaption></figcaption></figure>
3. As you can see above, Enter all the required fields: Project Title, APP Framework, Description, Project Logo, and Select Team.
4. Upload the App Framework of the respective mobile application you are testing and provide the necessary details for the project.
5. An app framework, short for application framework, refers to a set of pre-built software components, libraries, and tools that provide a structured foundation for developing software applications.
6. These frameworks provide a structured environment and tools for designing, developing, and running automated tests, enabling testers and developers to efficiently verify the functionality, performance, and reliability of their applications. If you are not aware of the App Framework of the respective mobile application, Please contact your Application Development Team.
7. Enter Description
8. Upload Product Logo: The preferred image size should be a maximum of 2 MB (SVG, PNG, or JPG).
9. Enter the required details and click the Create button for a new Project creation. The below Success Message will be displayed: QApilot runs on the Appium model, which is used for Automating Native, mobile web, and hybrid applications on iOS and Android platforms. You can select whether you want to test for Android, iOS, or a combination of both.\
   ​

   <figure><img src="https://docs.qapilot.io/~gitbook/image?url=https%3A%2F%2F1727045651-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Ff7DuCvkprTM62hS3tKQF%252Fuploads%252FCpG6ulqBdX7cBHNX7qkS%252FCreate%2520New%2520Project%25203.png%3Falt%3Dmedia%26token%3D0eb5b0ac-420a-4cd2-9bf2-59d7cac427b7&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=e9ab357b&#x26;sv=2" alt=""><figcaption></figcaption></figure>
10. Once it is created, it appears as an info card on the Projects tab Screen.

<figure><img src="https://docs.qapilot.io/~gitbook/image?url=https%3A%2F%2F1727045651-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Ff7DuCvkprTM62hS3tKQF%252Fuploads%252FFhJUPQvh8vUvW9hM2ci0%252FCreate%2520New%2520Project%2520image%25204.png%3Falt%3Dmedia%26token%3D969013e2-ffc5-4f32-8457-e22266fdf7c8&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=7bf20f00&#x26;sv=2" alt=""><figcaption></figcaption></figure>

***

### How To Filter the Projects? <a href="#how-to-filter-the-projects" id="how-to-filter-the-projects"></a>

1. On the Projects Home page, click the Filter icon beside the Quick Search box.
2. It will display two filtering fields, App Framework and Status. The criteria are selected from the dropdowns.<br>

   <figure><img src="https://docs.qapilot.io/~gitbook/image?url=https%3A%2F%2F1727045651-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Ff7DuCvkprTM62hS3tKQF%252Fuploads%252FwQl95lzceSRfmVlUao5C%252FFilter%2520Project%2520image%25201.png%3Falt%3Dmedia%26token%3Dc0a4d41e-134d-47bd-8baf-9c14e318ce37&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=890e56ea&#x26;sv=2" alt=""><figcaption></figcaption></figure>
3. Click the Apply button to fix the criteria. The below output is shown as per the filter criteria.

<figure><img src="https://docs.qapilot.io/~gitbook/image?url=https%3A%2F%2F1727045651-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Ff7DuCvkprTM62hS3tKQF%252Fuploads%252Fb6i6EdmKrpEgLDDudhLA%252FFilter%2520Project%2520Image%25202.png%3Falt%3Dmedia%26token%3De9fd7bf4-2026-4ce2-b24f-0b3002064af5&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=2c4d8624&#x26;sv=2" alt=""><figcaption></figcaption></figure>

<figure><img src="https://docs.qapilot.io/~gitbook/image?url=https%3A%2F%2F1727045651-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Ff7DuCvkprTM62hS3tKQF%252Fuploads%252F7mrNgdY9J05LvB17qqyw%252FFilter%2520Project%2520Image%25203.png%3Falt%3Dmedia%26token%3Dd8603bed-d101-46ed-9439-05d1e16ef513&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=38d67b1d&#x26;sv=2" alt=""><figcaption></figcaption></figure>

***

### How to Edit the Project? <a href="#how-to-edit-the-project" id="how-to-edit-the-project"></a>

1. On the Projects Home page, click the three-dot menu.
2. A dropdown appears as shown below.<br>

   <figure><img src="https://docs.qapilot.io/~gitbook/image?url=https%3A%2F%2F1727045651-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Ff7DuCvkprTM62hS3tKQF%252Fuploads%252FZBfTNLYG3IUHttwL1A1g%252FEdit%2520Project%2520image%25201.png%3Falt%3Dmedia%26token%3Ddd03dd19-0e8a-4dfd-a7e9-d456c027ed0b&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=84b52b0c&#x26;sv=2" alt=""><figcaption></figcaption></figure>
3. Select the Edit icon to make the required changes.
4. A side window is displayed overlapping the Home page.<br>

   <figure><img src="https://docs.qapilot.io/~gitbook/image?url=https%3A%2F%2F1727045651-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Ff7DuCvkprTM62hS3tKQF%252Fuploads%252FaWCosNNb8cJ9eyooSbw4%252FEdit%2520Project%2520Image%25202.png%3Falt%3Dmedia%26token%3Dbe28dda7-b398-4648-8ca6-2290ac3b54da&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=fc6b3e8a&#x26;sv=2" alt=""><figcaption></figcaption></figure>
5. Make the required changes. Click the Update button to make the changes effective.

***

### How To Attach a New Team to the Projects? <a href="#how-to-attach-a-new-team-to-the-projects" id="how-to-attach-a-new-team-to-the-projects"></a>

1. On the Projects Home page, click the three-dot menu.
2. A dropdown appears as shown below.

<figure><img src="https://docs.qapilot.io/~gitbook/image?url=https%3A%2F%2F1727045651-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Ff7DuCvkprTM62hS3tKQF%252Fuploads%252Fct3SWgSTbPwYvhBw12KT%252FAttach%2520New%2520Team%2520Image%25201.png%3Falt%3Dmedia%26token%3D10c0a7f9-c447-4e05-b0fa-52a33732acbf&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=95fdb7ec&#x26;sv=2" alt=""><figcaption></figcaption></figure>

1. Select the Team icon to make the required changes.
2. A side window is displayed overlapping the Home page to Attach Team.

<figure><img src="https://docs.qapilot.io/~gitbook/image?url=https%3A%2F%2F1727045651-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Ff7DuCvkprTM62hS3tKQF%252Fuploads%252Fp13qKQfEGAi7zTOYVtBJ%252FAttach%2520Team%2520Image%25202.png%3Falt%3Dmedia%26token%3Df935f0ec-1f1c-450a-8333-188b6b44c5cd&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=826b5182&#x26;sv=2" alt=""><figcaption></figcaption></figure>

1. For the Select Team field, the user can attach a New team, or Select a team from the existing dropdown by using the respective toggle bar.
2. Click the dropdown and select a Team from the list. Click the Create button.
3. A New Team is attached to the respective Project as shown above. A new Team can be created and attached to the project.
4. On the Attach Team window, opt for New under the Select Team field.

<figure><img src="https://docs.qapilot.io/~gitbook/image?url=https%3A%2F%2F1727045651-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Ff7DuCvkprTM62hS3tKQF%252Fuploads%252FsX5D17tDeVTx41otL34w%252FAttach%2520a%2520New%2520Team%2520Image%25203.png%3Falt%3Dmedia%26token%3D87d294bd-4e1b-46c1-8457-fad808e6d726&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=7a48841b&#x26;sv=2" alt=""><figcaption></figcaption></figure>

1. Enter a Team Name. Select the Appearance from the given choices.
2. On the Members fields, select the member from the dropdown.
3. Select the Role from the next dropdown.

<figure><img src="https://docs.qapilot.io/~gitbook/image?url=https%3A%2F%2F1727045651-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Ff7DuCvkprTM62hS3tKQF%252Fuploads%252FQOZjWX4VebJJ2Q0ylvnZ%252FAttach%2520a%2520New%2520Team%2520Image%25204.png%3Falt%3Dmedia%26token%3Dc54873f3-2f70-46f5-abf9-c01428a93092&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=7865bec7&#x26;sv=2" alt=""><figcaption></figcaption></figure>

1. Click the Invite button to add that member to that new Team. Repeat the same procedure for adding every new Team member as per the requirement.

<figure><img src="https://docs.qapilot.io/~gitbook/image?url=https%3A%2F%2F1727045651-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Ff7DuCvkprTM62hS3tKQF%252Fuploads%252FXcA2xWsBZI8xVQkEalIg%252FAttach%2520a%2520New%2520Team%2520Image%25205.png%3Falt%3Dmedia%26token%3D2eb12be6-7744-4477-87fe-91ee4d6fef86&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=91a5bb72&#x26;sv=2" alt=""><figcaption></figcaption></figure>

<figure><img src="https://docs.qapilot.io/~gitbook/image?url=https%3A%2F%2F1727045651-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Ff7DuCvkprTM62hS3tKQF%252Fuploads%252FBaEtkuNS4y4FRtfPKZof%252FAttach%2520a%2520New%2520Team%2520Image%25206.png%3Falt%3Dmedia%26token%3D63ab1188-add1-41ca-a9a2-c832db154f33&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=9428b65e&#x26;sv=2" alt=""><figcaption></figcaption></figure>

1. Click the Create button to Attach a new team. The New Team is attached.

***

### How To Disable/Delete a Project? <a href="#how-to-disable-delete-a-project" id="how-to-disable-delete-a-project"></a>

1. On the Projects Home page, click the three-dot menu.
2. A dropdown appears as shown below.

<figure><img src="https://docs.qapilot.io/~gitbook/image?url=https%3A%2F%2F1727045651-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Ff7DuCvkprTM62hS3tKQF%252Fuploads%252F8fuY5Mfq69MgcbKCqPqT%252FDisable%2520Project%2520Image%25201.png%3Falt%3Dmedia%26token%3D8c4d4381-1da8-4cc6-a0c4-9ad5e2c5599f&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=e3fc9d02&#x26;sv=2" alt=""><figcaption></figcaption></figure>

1. Select the Disable option. A confirmation message will appear as shown below.

<figure><img src="https://docs.qapilot.io/~gitbook/image?url=https%3A%2F%2F1727045651-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Ff7DuCvkprTM62hS3tKQF%252Fuploads%252Fig25d2Sum2di1FSpXxOT%252FDisable%2520Project%2520Image%25202.png%3Falt%3Dmedia%26token%3Dbe504b0d-063a-420a-84c6-7173a1934e14&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=52a27538&#x26;sv=2" alt=""><figcaption></figcaption></figure>

1. Click the Yes button to proceed with the action. Accordingly, the Project is disabled.

Deleting a Project will delete:

* All Frameworks within this Project.
* All Test cases, Elements, Test data profiles, Custom functions, Uploads, Test suites, Test plans, Run results, and Environments associated with this project.

### Inside Projects

Once a project is created, you will be greeted with a menu that enables you to proceed with testing your mobile application. Note that the default landing menu item after project creation is "Recording". You can choose to start your testing journey from recording or take a step back start from "Crawler".

<figure><img src="/files/ejsNVDZV8vqWPXJlZAqB" alt=""><figcaption></figcaption></figure>

Learn more about each of the menu items in detail in the following pages.

* Crawler
* Recording
* Test Case
* Test Suite
* Execution


# Autonomous Android Test Generation

Use the QApilot crawler to explore Android app paths, record discovered interactions, and create reusable test coverage on local or cloud devices.

## Autonomous Android Test Generation

QApilot's crawler autonomously explores Android applications and records discovered interactions as reusable test steps. Use it to map app paths, find potential issues, and establish initial regression coverage.

A crawler is an intelligent test exploration engine. It navigates through the app to discover user flows, UI components, and potential issues with minimal manual intervention.

### How it Works in the QApilot Context?

* **Supported Platforms**
  * Currently, Crawlers in QApilot are designed for **mobile applications on Android OS**.
  * iOS crawler support is **under implementation** and will be available in upcoming releases.
* **Execution Modes**
  * **Crawl Local** → Run the crawler on a locally connected Android device/emulator.
  * **Crawl Remote** → Run the crawler on a **cloud-based Android device farm** (BrowserStack, Sauce Labs, LambdaTest).
* **Recording**
  * In both local & remote modes, the crawler **records the interactions** into structured test steps.
  * In both Local and Remote modes, the crawler automatically records interactions as structured test steps, which are then stored directly into Test Cases for reuse and execution.
* **Crawl Reports**
  * All crawler runs (local or remote) are stored in **Crawl Reports**, where you can:
    * Review steps.
    * Compare across builds.
    * Track coverage.
    * Promote recorded flows into regression suites.

For a broader explanation of this workflow, see [AI-Native and Agentic Mobile Testing](/ai-and-core-concepts/ai-native-and-agentic-mobile-testing).


# Run the Crawler

Launch the crawler in a fresh or dependent Appium session, configure app inputs, watch live progress, and review generated results from start to completion.

Click on the Project Card. Select the Crawler option from the Configurations list.

<figure><img src="/files/5i6480zp0FlcZ1YhORMr" alt=""><figcaption></figcaption></figure>

## Crawler Configuration

QApilot allows you to run the crawler either from scratch or **after executing a recorded test plan**, reusing the same Appium session instead of starting a fresh one.

This enables deeper exploration, especially for:

* Apps with login or OTP flows
* Screens reachable only after user interaction
* Complex workflows that crawler alone cannot initiate

#### **Crawler Launch Modes**

When launching the crawler, you will see two options:

#### **1. Start Crawler Without Dependency**

(Default behavior)

* Crawler starts in a fresh Appium session.
* Installs and launches the app and begins crawling from the startup screen.

#### **2. Start Crawler With Dependency**

<figure><img src="/files/bRPwycCZEMXe5bfWfQET" alt=""><figcaption></figcaption></figure>

* Select this option to run a test plan before the crawler.
* A dropdown appears listing available test plans.
* QApilot first executes the selected test plan.
* **The Appium session is not terminated afterward.**
* The crawler attaches to the same session and continues exploration from the final screen of the test plan.

## Autonomous Test Generation with the crawler

1. Configure Cloud Device Provider Integration from the Project Settings icon.

<figure><img src="/files/6YP5Eo7OtSJ7XuXzvz3T" alt=""><figcaption></figcaption></figure>

3. As you can see, the **QApilot** supports integrations with several third-party tools, including Browser Stack, TestRail, JIRA, Sauce Labs, Microsoft Teams, and Slack. Configure Cloud Device Integration. Enable Browser Stack for your integration. You can click on New [Integration ](https://docs.qapilot.io/project-settings/integrations)to integrate with various other tools.

Browser Stack is a cloud-based cross-browser testing platform that allows admins/users to test their mobile applications across different browsers, operating systems, and devices. It provides a wide range of real, physical devices for testing, along with automated and live interactive testing capabilities. This helps developers and QA teams ensure their products are compatible and function properly across diverse environments.

<figure><img src="/files/8ytiwVdew6XxojlEvWpF" alt=""><figcaption></figcaption></figure>

3. A confirmation popup will appear. Click **Yes** to enable the provider.

<figure><img src="/files/C2lzLuDz5w2Bh6vso6o3" alt=""><figcaption></figcaption></figure>

4. Once connected, the blow window will appear.

<figure><img src="/files/WApynG8QcrrbT6vrM2B5" alt=""><figcaption></figcaption></figure>

5. The next screen represents the **first step of setting up a Crawler in QApilot**.

   #### **1. Select App Platform**

   * Here, you choose the platform for crawling.
   * Currently, only **Android** is supported (iOS coming soon).
   * This tells the crawler what type of app (APK) it will be working on.

   #### **2. Set Crawler Duration**

   * You define how long the crawler should run (e.g., **10 minutes**).
   * The crawler will keep exploring the app during this duration, capturing screens and interactions.
   * Useful for balancing depth vs. execution time.

   #### **3. Upload App File**

   * You must upload your app’s APK file.
   * This APK is the version that the crawler will analyze and interact with.

   :information\_source: File name must be alphanumeric (no special characters).

   #### **4. Package Name**

   * Automatically extracted from the uploaded APK.
   * Example shown: `com.booking`.
   * Ensures that the crawler knows which app package to target.

   #### **5. Does Your App Require Login Credentials?**

   * If **yes**, you provide the **Username** and **Password**.
   * This allows the crawler to log in before starting the crawl.
   * If **no**, it will skip the login and start crawling directly.

   #### **6. Advanced Options (Optional)**

   * Key-value pairs can be injected into the app’s environment.
   * Useful for:
     * Testing specific scenarios.
     * Passing configuration flags.
     * Setting environment-specific values.

   #### **7. Ignore Keywords**

   * Enter words (like **“Terms and Conditions”**) that the crawler should skip.
   * Helps avoid unnecessary screens or dead ends during crawling.

   #### **8. Update Button**

   * After filling in all details, clicking **Update** will save the configuration and prepare the crawler to run with these settings.

<figure><img src="/files/7ci6vW0OFAIDuyrX9Etb" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/m4hrIyrYFKiKHYjkzU8v" alt=""><figcaption></figcaption></figure>

6. After setting up the **crawler configuration,** the following screen will appear to establish a connection.

<figure><img src="/files/cAH293QZa5rGLpy2ELd3" alt=""><figcaption></figcaption></figure>

7. The App will be successfully connected with the Crawler, and the Recording Screen below will be displayed.

<figure><img src="/files/Z1dRYS1vHRnSZAxzGxbm" alt=""><figcaption></figcaption></figure>

**Crawler Running Status**

* At the top-left, it shows the project name (**QApilot Demo Project**) and status (**Running**).
* A timer is running (**1 Min 14 Sec**) to track how long the crawl has been active.

#### **Current Page Under Test**

* The crawler has reached the **Onboarding Welcome Screen**.
* It has detected **16 interactable elements** (like buttons, links, input fields).
* A screenshot of the current screen is displayed on the left.

#### **Actions Captured**

* The crawler automatically **taps/clicks** on elements (in this case, the **SKIP button**) to bypass onboarding.
* This action is recorded as a **structured test step**.
* Example: *“Taps the SKIP button in the bottom-right corner to bypass onboarding and proceed directly to the home screen.”*

#### **Home Page Detection**

* The crawler asks for **user confirmation**:\
  \&#xNAN;*“Is this the home screen?”*
* Options: **Yes** or **No**.
* This ensures accuracy by letting the tester validate if the crawler has correctly reached the app’s home screen.

#### **Real-Time Updates**

* On the right panel, you can see different tabs:
  * **Updates** → Lists recorded steps sequentially.
  * **Crawler Input** → Lets you provide manual inputs (e.g., credentials, specific instructions).
  * **Activity Graph** → A visual graph showing the crawler’s navigation path across screens.

#### **Interaction Count**

* At the bottom-left, it shows:
  * **Screens Crawled:** 2
  * **Interactions:** 2
* Meaning the crawler has navigated 2 screens and performed 2 interactions so far.

#### **Recording Process**

* Every screen the crawler explores and every interaction it performs gets:
  1. **Captured visually** (screenshot).
  2. **Converted into structured test steps** (stored in Test Cases).
  3. **Logged for reporting** (for coverage analysis).

9. Once the crawler has finished exploring the app, a confirmation screen appears stating **"Crawling Completed,"** as shown below. At this stage, you are presented with the following options:
   1. **View Generated Test Cases**\
      Click this to review the structured test cases automatically created from the crawler's interactions.
   2. **View Graph Results**\
      This option lets you see the **graphical representation** of the app’s navigation path and screen transitions.
   3. **Click OK**\
      Once you’ve reviewed the results, click **OK** to exit the completion dialog and return to the main dashboard.

<figure><img src="/files/RKxs24JapyssT64fLDof" alt=""><figcaption></figcaption></figure>

10. Once the crawler runs, you can monitor or stop its execution from the **Crawler Reports** section in the QApilot project dashboard.

**✅ To Access:**

1. Click the **Crawler Icon** (camera icon on the left panel).
2. You’ll see an overview of:
   * **Total Test Cases**
   * **Device & App Info** (e.g., Samsung Galaxy S22 Ultra, `com.booking`)
   * **Execution Date & Time**
   * **Crawl Duration** (e.g., 10 minutes)
   * **Status** (e.g., Running)

**🎯 Actions Menu (Right Side)**

Click the **three-dot menu (⋮)** under the **Actions** column to view the following options:

* 👁️ **View Live Crawl**:\
  It opens a live view of the crawler's work in real time. You can see the screens being crawled and interactions occurring as they occur.
* ⏹️ **Stop**:\
  Manually stop the crawler execution if needed before the crawl duration ends.

<figure><img src="/files/hloFSTWea3yTNqz9lqr8" alt=""><figcaption></figcaption></figure>

11. After the crawl duration ends or you manually stop the crawler execution, QApilot automatically finalizes and generates the [Crawler Report](/ai-and-core-concepts/autonomous-android-test-generation/crawler-report).


# Crawler Report

Review crawl flow graphs, grouped scenarios, interaction paths, generated test cases, and failure reasons after an autonomous crawl run.

A **Crawl Report** is a structured output generated after an automated crawler explores an application. **Status (Completed)** → Confirms crawl finished successfully.

***

**Crawler Flow:**

This visual graph shows the paths taken by the automated crawler during its test run of the application. It captures all the screens visited and the transitions (navigation) between them.**🟢 Initial Screen**

* **Sign In Screen** (Green node)
  * This is where the crawl began. It represents the **starting point** of the automated journey (login or onboarding).

**🔵 Home Screen**

* **Dashboard Screen** (Blue node)
  * This is identified as the **Home Screen**.
  * All primary journeys or user flows **branch out from here**, showing that once login was successful, the app directed the user to this central hub.

**⚪ Navigation Screens (Gray nodes)**&#x45;ach of these represents a functional or navigable area discovered from the Dashboard or subsequent screens.The structure visually confirms how the crawler **mapped user journeys** and can now be used to **generate test cases** and **replay interactions**.**🎛️ Interface Elements**

* **Top Bar Options**:
  * `Crawler Flow`, `Scenarios`, `Activity Graph`, `Interaction Flow` — different views for inspecting crawl data.
* **Status: "Completed"** — Crawl finished successfully.

**🎥 Bottom Right Controls**

* **Start Playback** (Red Button):
  * Replays the entire path the crawler took, step-by-step.
* **Reset Zoom**: Returns the graph to default zoom for easy navigation.

<figure><img src="/files/R0FYkWbo7Nco2LsXynLn" alt=""><figcaption></figcaption></figure>

***

**Scenarios**

This section automatically groups the crawler's discoveries into **categorized user journeys**, turning them into **structured test cases**, with step-by-step details and visual evidence (screenshots).✅ **Status: Completed:** Confirms that the crawl ran successfully and all journeys were recorded and processed.Each collapsible group represents a major **user journey**. Inside each journey, you can see **step-by-step actions** with **screenshots**.Example for these below Journeys:

1. **Onboarding Journey** – 3 test cases
2. **Account Management** – 2 test cases
3. **Roaming Pack Purchase** – 7 test cases *(Expanded)*

**Auto-Generated Descriptions:** Plain-English breakdowns of each interaction. Missing Step Indicators clearly flag when screenshots aren’t available.<br>

<figure><img src="/files/k0zcTOuH7C0TVary7MYF" alt=""><figcaption></figcaption></figure>

***

**Activity Graph:**&#x49;t maps out the **user journeys** discovered by the crawler during its run.

* **Start Node** → The crawl begins at the **Onboarding Journey** (login screen).
* **Onboarding Steps**
* From here, multiple **branches** extend → each represents a **journey** or app flow that the crawler detected.

👉 Each box = a **screen or functional area**. 👉 The connecting lines = **navigation paths** (how the user/crawler moved from one screen to another).**Right-Side Panel (Details View)**

* Labeled **“Test Cases / All Steps”**.
* Each journey expands to show the **exact steps** taken.

Example: **Onboarding Journey**

1. Enter your email into the input field.
2. Enter the password.
3. Tap the Sign In button → proceed to Home Screen.

👉 This means the crawler automatically **converts interactions into structured test cases**.**Icons Highlighted in Red (Top Right)**

* **Test Case Counter (10)** → Total journeys/test cases generated.
* **Play/Replay Icon** → Lets you replay the crawl path or rerun it.

**Mini-Map (Bottom Right)**

* A zoomed-out overview of the whole flow, helpful for navigating large graphs.

<figure><img src="/files/D39CUdfRepWC9sGjdPXv" alt=""><figcaption></figcaption></figure>

***

**Interaction Flow**

This flow diagram shows a **step-by-step path of user interactions**, captured during the automated crawl. It highlights **what actions the crawler took on each screen**, in the order they occurred.

* **User Actions** → Not just screens, but what the crawler/user did (e.g., clicked, typed, navigated).
* **Flow Direction** → Dotted lines show the path and order.
* **Detailed Behavior Tracking** → Each box includes **interaction descriptions**.

<figure><img src="/files/hsUgM62z8EQOijT4PnJI" alt=""><figcaption></figcaption></figure>

***

**Test Cases are automatically displayed in the** [**Test Cases**](https://app.gitbook.com/o/FbyoGKdvYxBL55moKt6I/s/f7DuCvkprTM62hS3tKQF/test-plan-executions/test-case) from the crawler’s recorded steps across different user journeys. These test cases are automatically generated from the crawled scenarios and recorded interaction flows, where each user interaction (such as tap, input, or navigation) is captured as an individual step.

<figure><img src="/files/95NICYBfaYkIVpatghwP" alt=""><figcaption></figcaption></figure>

#### Failure Reasons for Crawler

In case, when crawler is initiated for a certain period of time and for some reason, the crawl fails, the corresponding reason for the failure of crawler is also displayed as shown in the image below. The failure reasons are displayed along with Trans Ids too.

<figure><img src="/files/tjdPqOFIZLCS4U682yf7" alt=""><figcaption></figcaption></figure>


# Auto Bug Finder

See issues found during crawling, including broken assets, loading failures, spelling problems, and accessibility gaps on each screen with evidence.

When a crawl completes, QApilot analyzes every discovered screen and interaction to identify common problem patterns. The results are grouped and presented as **Issues**, mapped back to the exact screens where they were found.

Each issue is backed by screenshots, UI metadata, and actionable guidance, making it easy to understand both **what failed** and **where it occurred**.

<figure><img src="/files/HTZ0wAzLLaAt8ImGdboH" alt=""><figcaption></figcaption></figure>

### Issues Categories

Issues are automatically classified into the following categories:

* **Assets Not Loaded**\
  Detects UI elements where images or visual assets failed to render correctly, resulting in blank or broken components.
* **Page Not Loaded**\
  Flags screens that did not load fully or failed to reach a stable state during navigation.
* **Spell Check**\
  Identifies spelling or textual inconsistencies detected on screens.
* **Accessibility**\
  Highlights potential accessibility violations based on UI structure and attributes.

Each category displays a count indicating how many issues were detected during the crawl.

### Pages with Issues

The left pane lists all screens where issues were identified, grouped by screen name (for example, Home Screen, Login Screen, Settings).

### Issue Details View

For each issue, QApilot provides a detailed breakdown:

* **Issue Summary**\
  A clear description of the problem detected.
* **Severity Indicator**\
  Highlights the potential impact (for example, High).
* **Screenshot Context**\
  Shows the affected screen, with the problematic element visually identifiable.
* **UI Metadata**\
  Includes element type, resource ID, class name, text, and screen bounds.
* **How to Fix**\
  Provides a recommended corrective action to help teams address the issue efficiently.

This combination of visual evidence and technical context makes issues immediately actionable for both QA and development teams.


# CoWork: Human-in-the-Loop Mobile Test Authoring

Turn written Android test cases into reviewable automated recordings with QApilot CoWork, AI planning, and live LambdaTest devices.

## CoWork: Human-in-the-Loop Mobile Test Authoring

CoWork turns plain-English or BDD test cases into reviewable mobile test recordings. It plans and performs actions on a live device, then lets you accept, edit, or manually complete the generated steps.

CoWork is QApilot's agentic, human-in-the-loop authoring mode. It reads the screen, selects actions, and can replan when the observed screen differs from the expected state.

CoWork is one among the three test authoring modes on QApilot - each mode designed for a different testing need:

<table><thead><tr><th width="101.08770751953125">Mode</th><th width="167.78472900390625">Type</th><th>Best For</th></tr></thead><tbody><tr><td><strong>Crawler</strong></td><td>Agentic · Autonomous</td><td>Fully autonomous app exploration and test generation with zero human input</td></tr><tr><td><strong>CoWork</strong></td><td>Agentic · Human in the loop</td><td>Converting existing test cases into automated recordings with AI assistance</td></tr><tr><td><strong>Record &#x26; Playback</strong></td><td>RPA · AI-Assisted</td><td>Capturing precise user interactions manually for full test coverage</td></tr></tbody></table>

> **See also:** [AI-Native and Agentic Mobile Testing](/ai-and-core-concepts/ai-native-and-agentic-mobile-testing) explains QApilot's documented AI workflows.

## How to CoWork

### Workflow at a Glance

<table><thead><tr><th width="42.454833984375">#</th><th width="157.6544189453125">Step</th><th>What Happens</th></tr></thead><tbody><tr><td>1</td><td><strong>Ingest</strong></td><td>Upload or create test cases from excel</td></tr><tr><td>2</td><td><strong>Invoke</strong></td><td>Configure and launch CoWork on a selected test case</td></tr><tr><td>3</td><td><strong>Translate</strong></td><td>Review and optionally edit the auto-generated BDD steps</td></tr><tr><td>4</td><td><strong>Execute</strong></td><td>CoWork runs the test on a live device, replanning automatically as needed</td></tr><tr><td>5</td><td><strong>Review &#x26; Accept</strong></td><td>Accept the recorded steps or hand off to the RPA module for manual recording</td></tr><tr><td>6</td><td><strong>Run &#x26; Report</strong></td><td>Execute the test suite and view results - shared across all authoring modes</td></tr></tbody></table>

***

## Prerequisites

Before using CoWork, make sure the following are set up in QApilot:

* **Device farm Integration** - Connect to a supported device farm (LambdaTest) via **Settings**
* **App uploaded** - The mobile app under test must be uploaded to the platform as an App Source

> CoWork currently supports **Android** only. iOS support is coming soon.

***

## 1. Ingest - Build Your Test Cases

Navigate to **CoWork** in the left sidebar. You'll find two sections: **Configuration** and **Test Cases**.

The **Test Cases** page is your CoWork test case bank - a library of all test cases available for CoWork to run upon. Each entry shows the test case name, ID, supported OS, last updated timestamp, scenario, source, and actions.

> **Cross-reference note:** The `Source` column in the Test Cases bank displays `CoWork` for all cases authored here. See [Test Case](/test-creation/create-and-manage-mobile-test-cases) for the full platform-wide test case view.

### Adding Test Cases

{% tabs %}
{% tab title="Option 1: Upload via Excel" %}

1. Click the **Upload** button (top right of the Test Cases page)
2. In the **CoWork Test Case Upload** modal, attach your Excel file from your local machine
3. Ensure the file includes all required fields:

   <table><thead><tr><th width="172.33502197265625">Field</th><th>Description</th></tr></thead><tbody><tr><td><code>allure_id</code></td><td>Unique identifier for the test case</td></tr><tr><td><code>name</code></td><td>Test case name</td></tr><tr><td><code>feature</code></td><td>Feature or module the test case belongs to</td></tr><tr><td><code>scenario</code></td><td>Scenario name</td></tr><tr><td><code>test steps</code></td><td>The actual steps to execute</td></tr></tbody></table>

> **Tip:** Click **Download Sample Excel File** to get the `CoWork-sample.xlsx` template. Fill in your test case details and upload.
> {% endtab %}

{% tab title="Option 2: Create Manually" %}

1. Click the **+** icon (top right of the Test Cases page)
2. Fill in the **Test Case Create** form:

   <table><thead><tr><th width="148.22998046875">Field</th><th width="107.08935546875" align="center">Required</th><th>Notes</th></tr></thead><tbody><tr><td>Test Case Title</td><td align="center">✅</td><td></td></tr><tr><td>Test ID</td><td align="center"></td><td>Reference a case in your test management tool</td></tr><tr><td>Severity</td><td align="center">✅</td><td>e.g., Critical, Major, Minor</td></tr><tr><td>OS</td><td align="center">✅</td><td>Android, iOS, or Both</td></tr><tr><td>Scenario</td><td align="center"></td><td>Associate with an existing scenario</td></tr><tr><td>Precondition</td><td align="center"></td><td>Credentials, etc.</td></tr><tr><td>Expected Result</td><td align="center"></td><td>What the test should confirm</td></tr><tr><td>User Steps</td><td align="center">✅</td><td>Step-by-step actions in plain English</td></tr></tbody></table>
3. Click **Create**

Newly created test cases appear at the top of the bank with a **Draft** status.

> **Coming soon:** Import test cases directly from test management tools such as TestRail.
> {% endtab %}
> {% endtabs %}

> Open CoWork section from the left panel -

<figure><img src="/files/HIMnGHp3BidMFePrqMx9" alt=""><figcaption></figcaption></figure>

> Upload Test Case Sheet to add Cases and Steps into the platform

<figure><img src="/files/bYsf6jQGoZW0TstycNKL" alt=""><figcaption></figcaption></figure>

> Or write cases manually through Test Case Create

<figure><img src="/files/5yUUG23bUmC26OVTSpRV" alt=""><figcaption></figcaption></figure>

### Managing Test Cases

Click the three-dot-menu on any test case row to access the following options:

<figure><img src="/files/5e5Z1NFa2diORwkETyRA" alt=""><figcaption></figcaption></figure>

<table><thead><tr><th width="169.46014404296875">Action</th><th>Description</th></tr></thead><tbody><tr><td><strong>Edit</strong></td><td>Modify the test case details</td></tr><tr><td><strong>Manage Steps</strong></td><td>View or edit recorded steps associated with the test case</td></tr><tr><td><strong>CoWork</strong></td><td>Launch CoWork directly on this test case</td></tr><tr><td><strong>Delete</strong></td><td>Permanently remove the test case</td></tr></tbody></table>

***

## 2. Invoke - Launching CoWork

CoWork can be launched from two places in the platform.

{% tabs %}
{% tab title="Option 1: From the Configuration Page" %}

1. Select **Configuration** from the CoWork left panel
2. Complete **Step 1 - Select Platform & App Source:**
   * Select **App Platform** (Android)
   * Choose your **Service** (e.g., LambdaTest)
   * Select your **App Source**
3. Complete **Step 2 - Configure Scenario & Test Case:**
   * Select a **Scenario**
   * Select the **Test Case** you want to automate
4. Click **Launch**
   {% endtab %}

{% tab title="Option 2: From the Test Cases Page" %}

1. Click the **⊙** actions menu next to any test case
2. Select **CoWork**
3. A **CoWork Configuration** modal appears with the same two-step form — the Scenario and Test Case fields are pre-filled based on your selection
4. Fill in Step 1 (platform, service, app source) and click **Launch**
   {% endtab %}
   {% endtabs %}

> Configuration Screen -

<figure><img src="/files/34zzs4ZAG9swaeZ3gmSQ" alt=""><figcaption></figcaption></figure>

> Test Cases Screen -

<figure><img src="/files/5kS1aOCvcjC0itGrGZ9n" alt=""><figcaption></figcaption></figure>

> Launch CoWork post Configuration -

<figure><img src="/files/SaLjvhQwLJRfg50AJgU6" alt=""><figcaption></figcaption></figure>

### Device Connection

After clicking Launch, CoWork allocates a device from your device farm and establishes a live connection. A progress modal displays:

* Device name (e.g., Galaxy S24)
* App name and package identifier
* Connection progress and elapsed time

Once connected, the CoWork workspace opens with the device live on the left panel.

***

## 3. Translate - Reviewing BDD Steps

The CoWork workspace is split into three panels.

<figure><img src="/files/ZVyQuqteugsJap77f7gH" alt=""><figcaption></figcaption></figure>

### **Left Panel: Live Device**

A real-time mirror of the mobile device. The app is already launched and ready. You can watch actions execute here as CoWork runs.

### Center Panel: Planner Workspace

**Source Requirements** *(expandable, read-only)*

Expand this section to view the original test case data pulled from the bank:

* Preconditions
* User Steps
* Expected Result

This is read-only. It reflects your source test case exactly as entered.

**Planner Input (BDD Steps)**

CoWork automatically translates your plain English test steps into BDD format. These steps are editable — you can refine them before starting a run.

Typical BDD steps looks like this:

```gherkin
  Scenario: Account Confirmation Letter details
    Given the app is launched
    And user enters email qa.user.example.test
    And user enters passcode: 15900
    And user clicks on Login: 15900
    And the user clicks on Account details
    And select any account
    Then the user clicks on Account confirmation letter button
```

Click **Save BDD Steps** to save any edits.

> The BDD steps generated during a CoWork run are saved back to the test case automatically for future reference.

**Additional App Context**

Use this free-text field to pass extra information to the planner - for example, login credentials, screen-specific values, or navigation hints that aren't captured in the test steps.

**Action Buttons**

<table><thead><tr><th width="209.6119384765625">Button</th><th>Action</th></tr></thead><tbody><tr><td><strong>Automate with CoWork</strong></td><td>Starts the CoWork and begins automated execution on the live device</td></tr><tr><td><strong>Record Manually</strong></td><td>Skips CoWork and opens the Record &#x26; Playback (RPA) module on the platform for manual recording</td></tr></tbody></table>

### Right Panel: Planner Output

{% tabs %}
{% tab title="Plan Tab" %}
Displays the planner's current execution plan as a numbered, live-updating step list. Each step includes:

* A plain-language description of the action
* The action type: `click`, `wait`, `scroll`, or `reactivate`
* The target selector (element identifier used to locate the UI element)
* Real-time status indicator: ○ pending · ✓ succeeded · ✗ failed

The badge on the tab reflects the total number of steps in the current plan version. If a replan occurs, this count updates.
{% endtab %}

{% tab title="Plan History Tab" %}
Logs every version of the plan generated during the session. Expand any version to see:

* Version label and status (`in_progress`, `replaced`, or `completed`)
* The planner's reasoning — a natural language explanation of the approach taken
* Full scenario context (BDD steps, app package, app context)
* Step-by-step execution summary with success/failure indicators per step
  {% endtab %}

{% tab title="Replans Tab" %}
When a step fails, CoWork does not stop - it automatically generates a new plan from the point of failure. The Replans tab records each replan event in detail:

<table><thead><tr><th width="140.20660400390625">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Triggered at</strong></td><td>The step and plan version where the failure occurred</td></tr><tr><td><strong>Error</strong></td><td>The exact error returned by the failed action</td></tr><tr><td><strong>Failed step</strong></td><td>Action type, description, and selector that was attempted</td></tr><tr><td><strong>Reasoning</strong></td><td>The planner's analysis of what went wrong and how it will recover</td></tr><tr><td><strong>New plan</strong></td><td>The version number and file generated to replace the failed plan</td></tr></tbody></table>

**Example of adaptive replanning in action:**

The planner expected a "Not now" dismiss button on an update prompt. Instead, the device showed a Change Language screen. CoWork detected the mismatch, reasoned that the language screen needed to be cleared by tapping "Proceed", generated a new 2-step plan (v2) spliced in from step 3, and continued execution — all without manual intervention.
{% endtab %}
{% endtabs %}

***

## 5. Review & Accept

Once execution completes, the plan steps are displayed with their final status. Review the run and choose how to proceed:

{% tabs %}
{% tab title="Accept Steps" %}
Click **Accept Steps** to save all generated steps to the test case on the platform.

> *The test case is saved with the recorded steps and is ready for execution.*

Use this when you're satisfied with how CoWork executed the test and want to move forward without changes.
{% endtab %}

{% tab title="Record Manually" %}
Click **Record Manually** to save the generated steps as a **Draft** and open them in the **Record & Playback** module.

> *From the Recorder screen, you can review, validate, edit, and approve each step before finalizing.*

Use this when you want to inspect the steps closely, correct specific interactions, or fill in gaps before accepting the recording.

> **Cross-reference note:** See [Creating Test Steps Using Test Recorder](/test-creation/record-mobile-test-steps/create-test-steps-with-the-test-recorder) for full documentation on the RPA module and how to work with draft steps in the Recorder screen.
> {% endtab %}

{% tab title="Edit & Rerun" %}
To adjust the BDD steps based on what was observed during execution, click **Edit & Rerun**.

This returns you to the Planner Workspace where you can edit the BDD input and re-execute the test from the beginning with the updated steps.
{% endtab %}
{% endtabs %}

<figure><img src="/files/Hc7If95jSHdrK03Yc4v9" alt=""><figcaption></figcaption></figure>

***

## 6. Run & Report

Once a test case has been recorded and accepted via CoWork, it joins your test suite and can be executed like any other test case on QApilot.

Test execution and reporting work the same way across all authoring modes - CoWork, Crawler, and Record & Playback.

> **Cross-reference note:** See [Test Plan Executions](/execution-and-reliability/run-mobile-test-plans) and [Reports Dashboard](/reports-security-and-release-readiness/mobile-test-execution-reports/reports-dashboard) for full details on scheduling runs, selecting devices, and interpreting test results.


# How QApilot Works

Learn how QApilot turns mobile app flows into reusable tests through AI exploration, recording, execution, and evidence-rich reporting.

## How QApilot Works

QApilot helps teams create, run, and maintain mobile tests from one platform. It supports local and cloud execution for Android and iOS apps.

### The workflow

1. **Prepare a project and device**

   Create a [project](/ai-and-core-concepts/projects). Connect a [local device](/getting-started/set-up-qapilot/local-recording-and-execution) or configure [cloud execution](/getting-started/set-up-qapilot/cloud-device-recording-and-execution).
2. **Create coverage**

   Record interactions, use the Android crawler, or author with [CoWork](/ai-and-core-concepts/cowork-human-in-the-loop-mobile-test-authoring). QApilot stores the resulting interactions as test steps in reusable test cases.
3. **Organize and run tests**

   Group cases into [test suites](/test-creation/test-suite). Add test data or rules when needed. Then configure and launch a [test plan](/execution-and-reliability/run-mobile-test-plans).
4. **Review results and improve tests**

   Reports include execution details, screenshots, videos, logs, and rerun evidence. [AI auto-healing](/execution-and-reliability/ai-auto-healing-for-mobile-tests) can identify changed elements during a run.

### Choose the right creation mode

| Mode     | Use it when                                         | Current scope                        |
| -------- | --------------------------------------------------- | ------------------------------------ |
| Recorder | You need precise, repeatable interactions           | Android and iOS execution workflows  |
| Crawler  | You need autonomous Android app exploration         | Android apps; local or cloud devices |
| CoWork   | You have written cases and want AI-guided authoring | Android on LambdaTest                |

### How QApilot represents an app

The crawler explores screens and user paths. It records discovered interactions as structured test steps. QApilot describes this output as a knowledge graph of app flows and screens.

That structure supports later review, reuse, execution, and regression coverage. It does not replace product-specific test design. Add explicit cases for required business outcomes.

For the AI workflows that use this application understanding, see [AI-Native and Agentic Mobile Testing](/ai-and-core-concepts/ai-native-and-agentic-mobile-testing). Use [CoWork](/ai-and-core-concepts/cowork-human-in-the-loop-mobile-test-authoring) for reviewed, human-in-the-loop authoring.

### When to use QApilot

Use QApilot when you need to:

* Build repeatable mobile coverage from real interactions.
* Run tests on local devices or supported cloud device providers.
* Investigate failures with execution artifacts and step-level evidence.

### Related documentation

* [QApilot Getting Started](/getting-started/qapilot-getting-started)
* [Autonomous Test Generation](/ai-and-core-concepts/autonomous-android-test-generation)
* [CoWork: Human-in-the-Loop Mobile Test Authoring](/ai-and-core-concepts/cowork-human-in-the-loop-mobile-test-authoring)
* [Create Test Steps with the Test Recorder](/test-creation/record-mobile-test-steps/create-test-steps-with-the-test-recorder)
* [Reports](/reports-security-and-release-readiness/mobile-test-execution-reports)


# AI-Native and Agentic Mobile Testing

Understand QApilot’s AI-native mobile testing approach, including autonomous exploration, human-in-the-loop authoring, and adaptive test recovery.

## AI-Native and Agentic Mobile Testing

QApilot applies AI to explore mobile apps, translate written test intent, and recover from selected UI changes. The platform combines autonomous and human-guided workflows with recorded test steps.

### What AI-native means in QApilot

AI is part of the testing workflow, not only a reporting add-on. QApilot uses it in documented capabilities such as:

* The Android crawler explores app paths and records discovered flows.
* CoWork plans actions from plain-English or BDD test cases.
* Auto-healing attempts alternate element identification when a locator fails.

These capabilities complement recorded tests. They do not remove the need to define expected outcomes and review results.

### Agentic workflows

An agentic workflow observes the current app state, selects an action, and can adapt when conditions differ. QApilot provides two documented authoring workflows:

#### Autonomous exploration

The [crawler](/ai-and-core-concepts/autonomous-android-test-generation) navigates Android applications with minimal manual input. It records interactions as test steps and stores results in crawl reports.

Use it to discover flows, build an initial coverage map, and identify issues during exploration.

#### Human-in-the-loop authoring

[CoWork](/ai-and-core-concepts/cowork-human-in-the-loop-mobile-test-authoring) starts from written test cases. It translates steps into editable BDD, acts on a live device, and replans after a failed action when possible.

A tester reviews the generated steps before accepting them. This keeps acceptance and release responsibility with the team.

{% hint style="info" %}
CoWork currently supports Android with LambdaTest. The crawler currently supports Android. iOS support for those workflows is documented as planned or in development.
{% endhint %}

### Application understanding and reusable coverage

During exploration, QApilot records screens, interaction paths, and test steps. The platform describes this structured output as a knowledge graph of app flows and screens.

Use that record as a starting point for reusable coverage. Promote important flows into test cases and suites. Add explicit assertions for business-critical outcomes.

### Adaptive recovery during execution

[AI auto-healing](/execution-and-reliability/ai-auto-healing-for-mobile-tests) uses locator fallback methods. The documented order includes IDs, attributes, visual matching, and coordinates.

A healed step is marked in the execution report. Review the suggested locator before updating the test case.

### When to use these workflows

* Use the crawler for early Android exploration and generated flow coverage.
* Use CoWork when existing written cases need mobile automation.
* Use auto-healing to reduce maintenance after minor UI changes.

### Related documentation

* [How QApilot Works](/ai-and-core-concepts/how-qapilot-works)
* [Run the Crawler](/ai-and-core-concepts/autonomous-android-test-generation/run-the-crawler)
* [AI Auto-Healing in QApilot](/execution-and-reliability/ai-auto-healing-for-mobile-tests)


# Debugging Mobile Applications on Local Devices

Debug mobile tests step by step on a local device, pause on failures, inspect step resources, and fix issues with more confidence in QApilot.

Debugging mobile applications on local devices with QApilot allows you to inspect and resolve errors by running test cases step-by-step. This interactive debugging feature lets you pause at specific points, inspect behavior, and analyze resources like step results, metadata, and screenshots, ensuring accurate problem identification and efficient resolution.

***

## Prerequisites

Before starting the debugging process, ensure the following:

* A [local mobile device connection](/getting-started/set-up-qapilot/local-recording-and-execution) is configured with **QApilot**. The **QApilot Local Agent** is active on your local device.
* Debugging must be performed on a local device.
* If your test case uses a test data profile, only one test data profile can be selected for debugging.

***

## Executing Test Cases using Launch Debugger

1. After establishing a local device connection, you will see the launch debugger option when creating the test plan.

<figure><img src="/files/U3T5m9pxlSs74Uj5DV1Y" alt=""><figcaption></figcaption></figure>

2. click on the Launch Debugger and Execute
3. During test case execution, you can visually follow each step. If an error occurs or a debug point is reached:
   * **QApilot** will highlight the problematic step.
   * You can pause the step to analyze the issue and determine the necessary fixes.


# Cross-Platform Execution for Android and iOS

Improve Android and iOS test reliability by handling platform differences, locators, and platform-specific steps.

## Cross-Platform Execution for Android and iOS

QApilot can execute shared mobile test cases across Android and iOS. Use platform-specific steps where UI behavior, navigation, or element mapping differs to reduce false failures.

Cross-OS execution runs a test flow across both operating systems. It does not assume identical interfaces or platform behavior.

To ensure accurate issue reporting and reduced false failures during Cross-OS execution, here are a set of checks that help teams debug in a structured manner.

### 1. Verify Application Behaviour

* Confirm that the application behaviour is functionally equivalent on both Android and iOS.
* Certain flows, UI elements, navigation patterns, and interactions may differ across platforms by design.
* Validate that the expected iOS behavior aligns with the intended implementation before proceeding with further investigation.

### 2. Check Element Identification Changes

* If a step executes successfully on Android but fails on iOS, verify whether any recent application changes have impacted:
  * Accessibility identifiers
  * Element attributes
  * UI hierarchy or structure
  * Element visibility or interaction patterns
* Confirm with the development team whether platform-specific UI updates were introduced.
* Update the locator or re-record the affected step if required.

### 3. Coordinate-Based Taps

* Steps recorded using Tap by Coordinates may behave differently across Android and iOS due to differences in:
  * Screen resolutions
  * Device dimensions
  * UI layouts and scaling
* For such failures:
  * Verify whether the target element can be interacted with directly on iOS.
  * Re-record the step for iOS if necessary.
  * Maintain platform-specific actions when required.

### 4. Android "Go Back" Keyword Handling

* The Go Back keyword is supported on Android but is not supported on iOS.
* For steps using Go Back:
  * Retain the existing Android step and configure its Step State as Android.
  * Add an equivalent iOS navigation step and configure its Step State as iOS.
* During execution:
  * Android executes only the Android-specific step.
  * iOS skips the Android step and executes the iOS-specific navigation step.

### 5. Platform-Specific Step Management

* When a workflow requires different actions across platforms:
  * Create separate Android and iOS steps.
  * Configure the appropriate Step State (Android/iOS).
  * Avoid modifying a working Android step when the issue is isolated to iOS.
* This approach improves maintainability and prevents regressions in platform-specific flows.

### 6. iOS Page Object and Element Mapping Enhancements

During Android → iOS Cross-OS execution:

* The iOS page object (XPath and associated element attributes) is stored in the database only when the corresponding step executes successfully.
* If a step fails before element mapping is completed, the iOS locator information may not be available for review or maintenance.
* Swipe behavior may vary between Android and iOS due to differences in device resolutions, screen sizes, and UI layouts. As a result, additional swipe actions or platform-specific steps may be required to ensure consistent execution.
* For Cross-OS execution, AI is used to generate iOS XPaths from the Android recording. Therefore, AI will still be invoked for XPath generation even if AI Healing is disabled at the step level. If AI is to be completely bypassed for a specific step, set the step attribute `disable_autohealing = T`

Following these guidelines will help minimize false failures, streamline issue investigation, and improve Cross-OS execution reliability across Android and iOS platforms.

For Flutter-specific setup and supported automation approaches, see [Flutter App Testing](/mobile-testing/flutter-app-testing).


# OCR-Based Element Identification

Use OCR to capture and replay text-based elements when standard locators fail, with recording controls for manual capture during precise mobile automation.

OCR-based element identification enables test automation on screens where elements are not accessible through standard widget or XPath-based strategies.

In some mobile applications, UI components are rendered in ways that make them invisible to conventional automation techniques. For example, screens built with custom rendering, image-based components, or applications where development gaps result in elements that cannot be reliably targeted.

With this capability, QApilot uses OCR during the recording phase to detect and display visible text elements on screen. When a user selects an element, QApilot stores its text content and bounding box coordinates. During execution, OCR runs again on the live device screen to locate the same text, recalculates the current bounding coordinates, and performs the interaction.

It's now possible to control OCR-based element capture at the recording level.

1. In Auto Step Mode, OCR is automatically disabled.
2. When Auto Step Mode is off, a manual toggle is available in the recording UI, giving teams precise control over when OCR is used.<br>

<figure><img src="/files/znva03JuDmuRKKeKgDFv" alt=""><figcaption></figcaption></figure>


# Flutter App Testing

Test Flutter apps in QApilot by selecting Flutter Driver during recording and managing Android and iOS steps in shared test cases.

## Flutter App Testing

QApilot supports Flutter-specific recording setup and shared Android and iOS test cases. Select Flutter Driver before recording when your application requires Flutter context.

### How Flutter testing works

When starting a cloud recording session, choose an automation type. The default is UIAutomator2. Select **Flutter Driver** to initialize Flutter-specific dependencies.

After recording, organize steps in a test case. Flutter projects support OS tags at both test case and test step levels.

### Create a Flutter test

1. Configure [cloud recording and execution](/getting-started/set-up-qapilot/cloud-device-recording-and-execution).
2. Select the target OS and app source.
3. Choose **Flutter Driver** before launching the recording session.
4. Record and review the flow in the [test recorder](/test-creation/record-mobile-test-steps/create-test-steps-with-the-test-recorder).
5. Tag the test case and individual steps for Android, iOS, or both.

### Share one case across Android and iOS

A Flutter test case tagged **Both** can contain shared and platform-specific steps. QApilot executes only the applicable steps for the selected OS.

For example, a shared sign-in flow can use one Android-specific sign-in provider step and one iOS-specific provider step. Shared setup and assertion steps run on both platforms.

This approach reduces duplicate cases. It still requires deliberate platform-specific actions where the UI or behavior differs.

### Considerations

* Select Flutter Driver before the session starts.
* Use OS tags rather than assuming identical platform behavior.
* Re-record or update locators after meaningful UI changes.
* Review [cross-platform execution guidance](/mobile-testing/cross-platform-execution-for-android-and-ios) for Android and iOS differences.

### Related documentation

* [Cloud Recording and Execution](/getting-started/set-up-qapilot/cloud-device-recording-and-execution)
* [Android and iOS Mobile Testing Quickstart](/getting-started/android-and-ios-mobile-testing-quickstart)
* [Cross-Platform Execution for Android and iOS](/mobile-testing/cross-platform-execution-for-android-and-ios)
* [Run Mobile Test Plans](/execution-and-reliability/run-mobile-test-plans)
* [Mobile Test Execution Reports](/reports-security-and-release-readiness/mobile-test-execution-reports)


# Record Mobile Test Steps

Record mobile interactions as QApilot test steps, then organize them into test cases, suites, and executable test plans.

## Record Mobile Test Steps

QApilot records device interactions as reusable test steps. Use recordings to build a test case, group coverage into a test suite, and run it through a test plan.

A recorded step captures an action performed on the selected device. Review the resulting steps before using them for repeatable test automation.

***

## Prerequisites

1. Ensure you create a [Project ](/ai-and-core-concepts/projects)before recording the test steps.
2. Establish a [Local/Cloud Device](/getting-started/set-up-qapilot/system-requirements) connection setup.
3. You should know how to create a [Test Case](/ai-and-core-concepts/qapilot-terminology#test-case)

***

## Recording Steps

1. Select the "Start Recording" option to start setting up a test.

<figure><img src="/files/BIAAMJCYpAYrGiRi7t6r" alt=""><figcaption></figcaption></figure>

2. Let us see each of these steps in detail:
   1. [**Recording**](/test-creation/record-mobile-test-steps) is the starting point of the workflow. In this step, you connect the target device, launch the application, and capture the exact user interactions that QApilot stores as test steps for automation. These actions usually include taps, text entry, navigation, waits, and validations that represent a real user flow.
   2. [**Test Case**](/test-creation/create-and-manage-mobile-test-cases) is where the recorded flow (group of test steps) is saved as a reusable automated entity. You can name the test case, organize it with metadata such as severity or module, and manage the recorded steps so the scenario is ready for repeatable execution.
   3. [**Test Suite**](/test-creation/test-suite) helps you group related test cases into one execution-ready collection. This is useful when you want to validate a full business flow, run regression coverage, or maintain the order in which multiple test cases should execute.
   4. [**Test Execution**](/execution-and-reliability/run-mobile-test-plans) is the stage where the recorded and organized tests actually run on the selected device or environment. Here, you choose the execution source, apply test data and runtime settings, start the run, and review the generated results and reports.

For step-level recording options and locator details, see [Create Test Steps with the Test Recorder](/test-creation/record-mobile-test-steps/create-test-steps-with-the-test-recorder).


# Create Test Steps with the Test Recorder

Use the recorder workspace to capture steps, edit actions, add manual steps, switch contexts, and manage screenshots and controls during recording sessions.

## Use the Mobile Test Recorder

QApilot's Test Case Recorder captures interactions on a real or virtual device as mobile test steps. Use it to create and manage reusable steps for a test case.

A test step represents one action or validation in a mobile flow. Review recorded steps before adding them to repeatable coverage.

### Layout Overview

The recorder page is divided into four main sections:

1. **Mobile App Simulation Panel (Left)** – Displays the app under test. All interactions here are recorded automatically.
2. **Widgets Panel (Center)** – Displays available actions, input options, and quick actions for the selected element.
3. **Test Steps Panel (Right)** – Shows a sequential list of all recorded or manually added test steps.
4. **Action Panes (Sidebars)** – Left sidebar for recording controls; right sidebar for gesture actions.

<figure><img src="/files/BNI9ZxmQH1omyNUugk7B" alt=""><figcaption></figcaption></figure>

***

### Mobile App Simulation Panel (Left)

* Shows a live view of the mobile app under test.
* Any user interaction (tap, swipe, text input) is automatically recorded into test steps.
* Screenshots are automatically captured for each step and can be viewed later.

***

### 2. Widgets Panel (Center)

#### **Action Widget**

* When a user selects an element on the app screen, the **Action Widget** populates context-specific options.
* **Quick Action Bar:**
  * **Get Value** – Retrieve the current value of an element.
  * **Clear Text** – Remove existing input from a field.
  * **Find Element** – Highlight or locate a UI element.
  * **Swipe Up / Swipe Down** – Add swipe actions to navigate content.
* **Input Step Options (for text/input elements):**
  * **Step Title** – Custom label for the test step.
  * **Input Value** – Value to be entered in the field.
  * **Variable Assignment** – Store the entered value in a variable for reuse.
  * **Enable Step Condition** – Toggle to define execution rules (e.g., conditional flow for success/failure).

<figure><img src="/files/JSx3UCtYRZDP6e4fRb4L" alt=""><figcaption></figcaption></figure>

#### **Accessibility Test Section**

* Allows performing accessibility checks on the selected element.

***

### Test Steps Panel (Right)

* Displays the list of recorded steps in order of execution.
* **Available Actions:**
  * **Edit Step** – Modify step title, input value, or action parameters.
  * **Delete Step** – Remove unnecessary or incorrect steps.
  * **View Screenshot** – Opens the screenshot associated with the step for verification.

<figure><img src="/files/3DS6uLaQJXZaHrS83JtH" alt=""><figcaption></figcaption></figure>

* **Manual Test Step Creation:**
  * Users can add test steps manually by clicking **“Add Test Step”** at the top.

***

### 4. Action Panes

#### **Left Sidebar (Recorder Controls)**

* **Refresh App** – Reload the application.
* **Stop Recording** – End the current recording session.
* **Disable Auto Step Creation** – Toggle to stop auto-generation of steps.
* **Enable Tap on Coordinates** – Allows tapping based on screen coordinates.
* **View Page Source** – Displays the XML/HTML source of the page.
* **Find Elements** – Search and highlight specific elements.
* **Switch Context (Native/WebView)** – Toggle between app contexts for hybrid apps.

#### **Right Sidebar (Gesture Pane)**

* Provides gesture-based controls (swipe, drag, multi-touch if supported).
* Used for simulating physical interactions beyond basic taps.

Read more about this in [Gestures](/test-creation/record-mobile-test-steps/create-test-steps-with-the-test-recorder/gestures).

***

### Key Features at a Glance

* **Record-as-you-test**: Interactions with the app are automatically converted into test steps.
* **Edit & Manage Steps**: Update or delete steps directly from the step list.
* **Screenshots per Step**: Visual verification with automatic screenshot capture.
* **Conditional Flows**: Define pass/fail branches for dynamic testing.
* **Manual Override**: Insert custom test steps as needed.
* **Multi-context Testing**: Seamlessly switch between native and webview testing.
* **Quick Actions**: Speed up test creation with commonly used actions.

***

### Typical Workflow

1. Launch the recorder and open the app under test.
2. Interact with the app (e.g., login, navigate, input data).
3. Review the automatically generated steps in the **Test Steps Panel**.
4. Edit or delete steps as required.
5. Add conditional logic for steps that require branching.
6. (Optional) Insert manual steps if additional validation is required.
7. Save and organize the recorded test case into a suite or plan.


# Gestures

Reference QApilot recorder gestures and action keywords, from alerts and swipes to waits, network toggles, orientation checks, and OCR usage.

Gestures are vital to modern applications, especially touch-based devices, as they allow users to interact with various elements using physical actions. Below is a list of common gestures along with their description and how they are applied to clickable elements in **QApilot**:

## Compare Variables

Compare Variables usually refers to comparing the values of two or more variables to validate if they meet a particular condition. It can be used in various contexts, such as writing test cases, assertions, or debugging.

1. Use Meaningful Assertions: When comparing variables, provide meaningful error messages so that any discrepancies are easily diagnosed.
2. Handle Data Format Differences: Ensure data is in the correct format before comparing, especially in scenarios where date formats, currency, or numeric precision may differ.

## Accept Alert

Accept Alert Keyword is used to handle and accept browser alerts, confirmation pop-ups, or JavaScript dialogs that appear during the execution of a test case. When a pop-up alert is triggered in the application, the automation script cannot continue interacting with the web elements until the alert is addressed.

1. Automates Manual Intervention: Automated tests can handle alerts without requiring manual intervention, which helps in running tests in continuous integration pipelines or unattended environments.
2. Ensures Test Continuity: By handling pop-up alerts, the test script can proceed to the next steps without being blocked, ensuring smooth test execution.

## HTTP Source

HTTP Source is designed to call APIs and store their responses during execution. It allows users to access and utilize specific values returned by these APIs within the current execution context. By storing the API responses, users can reference and incorporate the retrieved data into subsequent operations or calculations as needed.

1. API Testing: One of the most common uses of HTTP source testing is to validate API endpoints. Automation frameworks can send HTTP requests (GET, POST) to a server and then compare the response to the expected results. It ensures that the APIs return correct status codes, response times, headers, and data (in JSON, XML, etc.).

## Hide Keyboard

Hide Keyboard is used to close or dismiss the on-screen keyboard that appears when the user interacts with input fields (e.g., text fields, search bars, or forms).

1. Handling UI Overlap: In mobile apps, the virtual keyboard may cover buttons, input fields, or other elements after entering text into a field. Dismissing the keyboard ensures that these elements are visible and interactable for the next steps in the test.
2. Ensuring Smooth Navigation: When automating form-filling or other text-input processes, it's essential to dismiss the keyboard before proceeding to the next element, especially when performing actions like scrolling or clicking on elements that might be hidden behind the keyboard.

## Go Back

Go Back keyword or Keyword is used to simulate the action of navigating back to the previous screen, page, or state. This is equivalent to the user pressing the "Back" button on a mobile device or using the browser’s back button in a web application.

1. Navigating Between Screens: Mobile apps often have multi-screen workflows. The Go Back Keyword can simulate the user navigating back through different screens, allowing testers to verify whether the navigation works as expected.
2. Testing Navigation Flow: In scenarios where users move between pages, such as form submission screens or app settings, the Go Back Keyword helps verify that returning to the previous screen is handled correctly by the application.

## Get Text

Get Text keyword or Keyword is used to retrieve or extract text content from a specified element on a web page or a mobile application. This text could be from any UI element such as buttons, labels, headers, input fields, or other text-based elements. The retrieved text can then be used for validation, comparison, or further processing in the test script.

1. Validating UI Text: The primary use of Get Text is to verify that the displayed text on a web or mobile application matches the expected content. This is useful for checking labels, headings, error messages, success notifications, or any other on-screen text.
2. Dynamic Data Validation: In scenarios where the content is dynamically generated (e.g., user details, prices, or form submission responses), Get Text helps retrieve the actual displayed values and compare them with expected results from a database or API response.

## Get Page Source

The Get Page Source keyword captures the full HTML or XML source of the current page or mobile app screen. It's useful for debugging, verifying dynamic content, and ensuring that the app is rendering and functioning as expected across different browsers and devices.

1. Debugging and Troubleshooting: When a test fails due to an element not being found, Get Page Source allows you to inspect the structure of the entire page or screen to see if the element exists in the DOM or view hierarchy. This is especially helpful when dealing with dynamic elements or hidden content.
2. Verifying Dynamic Content: In applications where the content of the page or view changes based on user interaction or API responses, the page source can be retrieved to validate that the correct content is loaded into the DOM or view hierarchy.

## Contains Text

Contains Text keyword or Keyword is used to verify whether a particular UI element or the entire page contains the expected text. It checks if the specified text is present in the element or page, without requiring an exact match of the full content. This is useful when only part of the text needs to be validated or when the text is dynamic but contains key phrases or words that need verification.

1. Partial Text Validation: If the displayed text contains dynamic content (such as a changing date or username), the Contains Text Keyword allows you to validate only the static portion of the text without needing an exact match.
2. Checking for Keywords or Phrases: Useful when you are validating that a page or element contains important phrases or keywords, like success or error messages. For instance, you can check if a confirmation message contains the phrase "successfully" without validating the entire message string.

## Clear Text

Clear Text keyword or Keyword is used to remove any text present in an input field or text area. This action is commonly used when testing form fields or input elements, ensuring that existing content is cleared before entering new data.

1. Ensuring Clean Input: If an input field already contains text, the Clear Text Keyword removes it before entering new data. This is especially useful in scenarios where fields might be pre-populated or where previous actions in the test could have left text in the field.
2. Testing Validation Rules: When testing form validation, clearing text allows you to simulate user actions such as entering and then deleting data. This is useful for checking if a form behaves correctly when a required field is left empty after initially having text.

## Checkbox button Disabled

Checkbox Button Disabled (or Is Checkbox Disabled) keyword or Keyword is used to check whether a checkbox element on a web page or mobile app is disabled. This means the checkbox cannot be interacted with (i.e., cannot be checked or unchecked) by the user. Verifying whether a checkbox is disabled is important in scenarios where certain conditions need to be met before a checkbox is made available for interaction.

1. Form Validation: In some scenarios, checkboxes may be disabled based on certain conditions (e.g., a checkbox is only enabled after filling out other required fields). Testing the disabled state helps ensure that the form behaves as expected under these conditions.
2. Conditional UI Elements: Certain user interfaces disable checkboxes until specific actions are taken, such as checking other checkboxes, selecting options, or providing valid inputs in other form fields. Ensuring these checkboxes are disabled initially is critical for testing conditional flows in the UI.

## Checkbox button Enabled

The Checkbox Button Enabled keyword is used to check if a checkbox button is enabled, meaning it can be interacted with. It’s commonly used in scenarios involving form validation, conditional inputs, and role-based access control across web and mobile applications.

1. Form Interaction: When testing forms, it’s essential to ensure that checkboxes intended for user input are enabled. This allows users to select options relevant to the task at hand.
2. Conditional UI Elements: Some checkboxes may become enabled based on certain conditions (e.g., selecting another checkbox or filling out required fields). Testing the enabled state helps ensure that the form behaves correctly when conditions are met.

## Set Orientation LANDSCAPE

The Set Orientation Landscape keyword is vital for testing mobile applications in landscape mode, ensuring that the UI layout, responsiveness, and functionality adapt to different screen orientations.

1. Testing UI Layout: Many applications have different layouts and components that adapt to screen orientation. Using the Set Orientation Landscape Keyword allows testers to verify that UI elements are correctly displayed, positioned, and functional in landscape mode.
2. Responsive Design Validation: Testing how an app responds to orientation changes is critical for ensuring a good user experience. Testers can use this Keyword to ensure that elements resize, reposition, and display correctly in landscape orientation.

## Activate App

The Activate App keyword is essential for managing app state transitions, particularly for bringing apps from the background to the foreground, switching between apps, and ensuring apps continue to function correctly after interruptions.

1. Testing App States: When running a suite of tests, you may need to ensure that the app is active before performing actions. Using the Activate App keyword helps verify that the app is in the correct state, especially after backgrounding or switching to another app.
2. Simulating User Behavior: Users often switch between apps. The Activate App keyword simulates this behavior, allowing testers to observe how the app responds to being brought back to the foreground.

## Set Value

The Set Value allows testers to input text into fields effectively, which is essential for tasks such as filling out forms, entering login credentials, and validating application behavior based on different user inputs.

1. Form Filling: When testing forms, the Set Value keyword is used to enter data into input fields. This helps verify that the application processes user inputs correctly.
2. Data Entry Validation: You can use this keyword to test whether the application validates and handles different types of input correctly (e.g., text, numbers, special characters).

## Swipe Right

The Swipe Right action is an essential gesture in mobile automation testing, used for navigating between screens, interacting with hidden elements, and testing features like carousels or menus. It helps simulate real user behavior in mobile apps, ensuring that swipe-based interactions work correctly across different devices and conditions.

1. Navigation Between Screens: Many mobile applications use swipe gestures for navigation between different screens or tabs. The Swipe Right Keyword can be used to test this functionality, ensuring that users can navigate through the app as intended.
2. Carousel or Slider Interaction: Applications that feature image carousels or sliders often allow users to swipe right to view the next image or item. The Swipe Right Keyword can simulate this interaction to verify that the carousel responds correctly.

## Swipe Left

The Swipe Left action is used to simulate the gesture of swiping from right to left on a touchscreen device. This gesture is frequently used in mobile apps to navigate between screens, move through horizontal content (e.g., image galleries or carousels), and reveal hidden features or actions.

1. Navigation Between Screens: Many mobile applications use swipe gestures to navigate between different screens or tabs. The Swipe Left Keyword can be used to test this functionality, ensuring that users can successfully navigate through the app.
2. Carousel or Slider Interaction: Applications featuring image carousels or sliders often allow users to swipe left to view the previous image or item. The Swipe Left Keyword can simulate this interaction to verify that the carousel responds as expected.

## Swipe Down

The Swipe Down keyword is commonly used to simulate a downward swipe gesture on a mobile device's screen. This action is particularly important in applications where scrolling, refreshing content, or accessing hidden elements is required.

1. Scrolling Through Content: In applications that display long lists or scrollable content (e.g., social media feeds, product listings), the Swipe Down Keyword can be used to test whether the content scrolls as expected.
2. Refreshing Content: Many applications utilize a pull-to-refresh mechanism, where swiping down at the top of a scrollable area refreshes the content. Automating this gesture helps verify that the refresh functionality works correctly.

## Swipe Up

The Swipe Up keyword is commonly used to simulate an upward swipe gesture on a mobile device's screen. This action is particularly important in applications where scrolling, revealing hidden elements, or navigating through content is required.

1. Scrolling Through Content: In applications that display long lists or scrollable content (e.g., social media feeds, product listings), the Swipe Up Keyword can be used to test whether the content scrolls as expected when users swipe up.
2. Revealing Hidden Elements: Swiping up may uncover additional UI elements or options that are not initially visible. Testing this gesture ensures that the app displays these elements properly when the user swipes up.

## Check Orientation is Portrait

Check Orientation is Portrait Keyword used to verify if a mobile device or application is currently in portrait orientation. Portrait orientation means the screen is positioned vertically (taller than it is wide). This is important in scenarios where an app’s layout or functionality may differ based on screen orientation.

1. Validation of UI Layouts: Ensure that the application's UI elements are displayed correctly when in portrait mode. Some elements might be hidden or rearranged based on the orientation, so this check helps confirm proper layout behavior.
2. Functional Testing: Certain features of the app may only be available or behave differently in portrait mode. This Keyword helps validate that such features work as intended when the device is held vertically.

## Check Orientation is LANDSCAPE

The Check Orientation is LANDSCAPE keyword commonly used to verify that the orientation of the mobile application or device screen is set to landscape mode. This is particularly important for applications designed specifically for landscape orientation, ensuring that they display and function correctly when the device is held horizontally.

1. Validation of UI Layouts: Ensure that the application's UI elements are displayed correctly when in landscape mode. Some elements may be hidden, resized, or rearranged based on the orientation, so this check confirms proper layout behavior.
2. Functional Testing: Certain features of the app may only be available or behave differently in landscape mode. This Keyword helps validate that such features work as intended when the device is held horizontally.

## Scroll till element found (Vertical)

The Scroll till element found (Vertical) keyword is commonly used in mobile test automation to scroll through a vertically scrollable view until a specified element is located. This keyword is essential for testing applications with long lists, menus, or content that may be out of view on the current screen.

1. Testing Long Lists or Content: In applications with long lists (e.g., news feeds, product listings), this Keyword can help automate the process of scrolling to find specific items or elements, making it easier to verify their presence and properties.
2. Element Visibility Verification: Ensure that certain elements are visible to the user. This is essential for testing scenarios where elements are loaded dynamically or are initially off-screen.

## Scroll till element found (Horizontal)

The Scroll till element found (Horizontal) keyword is used to scroll through a horizontally scrollable view until a specified element is located. This keyword is essential for testing applications that feature horizontal lists, carousels, or other content that may not be fully visible within the current view.

1. Testing Horizontal Lists or Galleries: In applications that display items horizontally (e.g., image sliders, product carousels), this Keyword can automate the process of scrolling to find specific items or elements, making it easier to verify their presence and properties.
2. Element Visibility Verification: Ensure that certain elements are visible to the user when scrolling horizontally. This is essential for testing scenarios where elements are loaded dynamically or are initially off-screen.

## Reset App

The Reset App keyword is used to reset a mobile application's initial state. This action is essential during testing to ensure that each test starts with a clean slate, eliminating any residual data, settings, or states from previous tests.

1. Consistent Test Environment: Resetting the app ensures that tests start from a clean slate, eliminating any residual data or changes from previous test runs that could affect results.
2. Testing User Registration and Login: After testing user registration or login processes, you may want to reset the app to test these features again without needing to uninstall and reinstall the app.

## Radio Button Disabled

Radio Button Disabled means that a specific radio button in a user interface is in a non-interactive state. When a radio button is disabled, the user cannot select or change it. Visually, it is often grayed out or faded to indicate it is unavailable for interaction.

1. Form Validation: Verify that radio buttons that should not be selectable under certain conditions (e.g., based on previous selections) are correctly marked as disabled. This is important for ensuring that users cannot select invalid options.
2. Conditional Logic Testing: Test scenarios where the availability of certain options is dependent on user actions. For example, if selecting a specific checkbox disables certain radio buttons, this Keyword can help validate that behavior.

## Button Enabled

The Button Enabled Keyword is used to check whether a button is enabled, meaning that it is active and can be clicked or interacted with by the user. This functionality is crucial for validating the behavior of an application, ensuring that buttons are only interactive when appropriate, based on the application's logic and user input.

1. Form Validation: Verify that buttons are enabled or disabled based on the input values in a form. For example, a "Submit" button may be enabled only when all required fields are filled out correctly.
2. Conditional Logic Testing: Test scenarios where the availability of a button depends on previous user actions or selections. For example, if a user selects a specific option, a corresponding button may become enabled.

## Button Disabled

The Button Disabled Keyword is used to check whether a button is disabled, meaning that it is not interactive and cannot be clicked or activated by the user. This functionality is crucial for validating the behavior of the application, ensuring that buttons are only enabled when appropriate based on the application’s logic and user interactions.

1. Form Validation: Ensure that buttons such as "Submit" or "Next" are disabled until all required fields are filled out correctly. This prevents users from submitting incomplete or invalid information.
2. Conditional Logic Testing: Test scenarios where the availability of a button depends on certain conditions. For instance, a button may be disabled until a user selects a specific checkbox or option from a dropdown.

## Set Orientation Portrait

The Set Orientation Portrait Keyword is used to change the screen orientation of a mobile application to portrait mode. This Keyword is particularly important for testing applications that are designed to function in specific orientations, ensuring that the user interface (UI) and functionality work correctly when the device is held upright.

1. UI Testing: Validate that the application's user interface is displayed correctly in portrait mode. This includes checking the layout, visibility of elements, and overall usability.
2. Responsive Design Validation: Test how the application responds to orientation changes, ensuring that elements adapt correctly when switching from landscape to portrait mode.

## Find Element

The Find Element keyword is fundamentally used to locate and interact with web or mobile elements within a user interface. This Keyword is essential for performing actions like clicking buttons, entering text in input fields, or validating the presence of elements on the page.

1. Element Interaction: Enable testers to locate elements they need to interact with, such as buttons, text fields, checkboxes, and dropdowns, allowing them to simulate user actions.
2. Validation: Verify the presence or state of UI elements on a page, ensuring that the application is functioning as expected. For example, checking if a specific error message is displayed after a failed form submission.

## Dismiss Alert

The Dismiss Alert keyword is commonly used to handle alert dialogs or pop-ups that require user interaction before proceeding with other actions in an application. Alerts are often used in web and mobile applications to notify users of important information, confirm actions, or provide warnings. The ability to dismiss these alerts is essential for ensuring that automated tests can run smoothly without interruption.

1. Confirmation Dialogs: Automatically dismiss confirmation dialogs that appear when a user attempts to delete data or take an irreversible action, allowing the test to continue without manual intervention.
2. Warning Alerts: Handle warning alerts that inform users of potential issues, enabling the automation script to continue or proceed with a specific action.

## Swipe UP 25%

The Swipe Up 25% Keyword is used to simulate a swipe gesture on mobile devices, where the screen is swiped upward by a specified percentage (in this case, 25%) of the screen height. This Keyword is particularly useful for navigating through content in mobile applications that may be longer than the visible screen area, such as lists, scrollable views, or web pages.

1. Scrolling Through Content: Swipe up to reveal more content that is off-screen, such as loading additional items in a list or scrolling through long text in a document.
2. Navigating User Interfaces: Simulate user behavior by swiping up to navigate through app interfaces that utilize vertical scrolling.

## Double Click

The Double Click keyword is used to simulate a double-click action on an element within a user interface. This action is often associated with desktop applications and certain web elements, where a double-click triggers specific functionalities, such as opening files, selecting text, or activating features.

1. Opening Files or Folders: In desktop applications, double-clicking on a file or folder may open it. This keyword can be used to automate such actions in testing environments.
2. Selecting Text: In web applications or text editors, a double-click may be used to select a word or text block. This functionality can be tested to ensure it behaves as expected.

## Unlock Device

The Unlock Device keyword is used to programmatically unlock a mobile device. This is particularly important in mobile automation testing environments where tests need to interact with the device's user interface, and the device may be locked or require authentication (like a PIN or fingerprint) to access the home screen and application functionalities.

1. Accessing Locked Devices: When a device is locked due to inactivity, this keyword allows testers to unlock it to proceed with automated test execution.
2. Starting Test Sessions: Before initiating a test suite, unlocking the device ensures that the tests can run without interruption from the lock screen.

## Toggle WIFI

The Toggle WiFi keyword is used to enable or disable the Wi-Fi connectivity on a mobile device programmatically. This action is crucial for testing scenarios where the application's behavior may change based on the network status, allowing testers to simulate different connectivity conditions.

1. Network Connectivity Testing: Test how an application responds when Wi-Fi is enabled or disabled, ensuring that it handles network changes gracefully.
2. Offline Functionality: Verify the app’s offline functionality by toggling Wi-Fi off and checking if it behaves as expected when no network connection is available.

## Toggle Mobile Data

The Toggle Mobile Data keyword is used to enable or disable mobile data connectivity on a mobile device programmatically. This functionality is crucial for testing applications under varying network conditions, as mobile data is often used for internet access on mobile devices.

1. Network Connectivity Testing: Test how an application behaves when mobile data is turned on or off, ensuring that it can handle different connectivity scenarios effectively.
2. Offline Functionality: Verify the application's offline capabilities by disabling mobile data and ensuring it behaves correctly when no network connection is available.

## Toggle Location

The Toggle Location keyword is used to enable or disable location services on a mobile device programmatically. This capability is essential for testing applications that rely on location data, such as mapping services, ride-sharing apps, or any application that provides location-based features.

1. Location-Based Feature Testing: Validate how an application responds when location services are turned on or off, ensuring it behaves correctly under different conditions.
2. Offline Mode Testing: Test the application’s functionality when location services are disabled to verify that it handles the absence of location data appropriately.

## Toggle Airplane Mode

The Toggle Airplane Mode keyword is used to enable or disable airplane mode on a mobile device programmatically. Airplane mode disables all wireless communication, including cellular data, Wi-Fi, and Bluetooth. This functionality is vital for testing applications that must operate under various network conditions and ensure they handle connectivity changes effectively.

1. Connectivity Testing: Assess how an application behaves when switching between connected and disconnected states by enabling or disabling airplane mode.
2. Offline Functionality Verification: Test how the application functions in offline mode by enabling airplane mode and ensuring that it handles the lack of connectivity appropriately.

## Terminate App

The Terminate App keyword is used to forcefully close or terminate a mobile application on a device or emulator. This functionality is crucial for testing scenarios where the application's behavior needs to be assessed after being restarted or to ensure that resources are released appropriately when the app is no longer in use.

1. Application Restart Testing: Validate how the application behaves after being terminated and restarted, ensuring that it restores the state correctly or handles the restart gracefully.
2. Resource Management: Assess how well the application manages system resources, checking for memory leaks or performance issues when terminated and restarted frequently.

## Tap By Coordinates

The Tap By Coordinates keyword is used to simulate a tap or click action on a mobile device or emulator at specific screen coordinates. This feature is particularly useful in scenarios where standard element identification methods may not work, such as when interacting with dynamic UI elements or when performing actions on non-interactive areas of the screen.

1. Dynamic Elements: Interact with elements that may not be easily identifiable through standard locators (like IDs or class names), such as custom UI components.
2. Complex Gestures: Simulate more complex touch gestures that involve multiple taps or taps at different points on the screen.

## Swipe Up 50%

The Swipe Up 50% keyword simulates a swipe gesture on a mobile device or emulator, moving the screen content upward by a specified percentage (in this case, 50%) of the screen height. This functionality is essential for navigating through apps where content is scrollable, such as lists or pages with vertically stacked elements.

1. Scrolling Through Content: Efficiently scroll through long lists or pages where elements are not immediately visible, ensuring all parts of the interface are accessible for testing.
2. UI Testing: Validate the loading and display of new content when swiping up, checking for issues like infinite scroll, loading indicators, or layout changes.

## Swipe Up 75%

The Swipe Up 75% keyword in automation testing simulates a swipe gesture on a mobile device or emulator, moving the screen content upward by a specified percentage (in this case, 75%) of the screen height. This functionality is important for navigating through applications where content is scrollable, allowing testers to access elements that may be further down the screen.

1. Efficient Navigation: Quickly scroll through lengthy lists or pages to access content that is not immediately visible, ensuring comprehensive testing of all UI elements.
2. UI and UX Testing: Validate how the application responds to user interactions by checking the loading and display of new content as the user swipes up.

## Swipe Down 75%

The Swipe Down 75% keyword simulates a swipe gesture on a mobile device or emulator, moving the screen content downward by a specified percentage (in this case, 75%) of the screen height. This functionality is beneficial for navigating through applications where content is scrollable, allowing testers to access elements that may be lower on the screen or to refresh content in certain scenarios.

1. Accessing Hidden Content: Efficiently scroll down to view content that is not immediately visible, ensuring comprehensive testing of all UI elements within the application.
2. UI Testing: Validate that the application behaves correctly when swiping down, checking for issues such as content loading, display of loading indicators, or layout changes.

## Swipe Down 50%

The Swipe Down 50% keyword simulates a swipe gesture on a mobile device or emulator, moving the screen content downward by a specified percentage (in this case, 50%) of the screen height. This functionality is beneficial for navigating through applications where content is scrollable, allowing testers to access elements that may be lower on the screen or to refresh content in certain scenarios.

1. Accessing Hidden Content: Efficiently scroll down to view content that is not immediately visible, ensuring comprehensive testing of all UI elements within the application.
2. UI Testing: Validate that the application behaves correctly when swiping down, checking for issues such as content loading, display of loading indicators, or layout changes.

## Swipe Down 75%

The Swipe Down 25% keyword simulates a swipe gesture on a mobile device or emulator, moving the screen content downward by a specified percentage (in this case, 25%) of the screen height. This functionality is beneficial for navigating through applications where content is scrollable, allowing testers to access elements that may be lower on the screen or to refresh content in certain scenarios.

1. Accessing Hidden Content: Efficiently scroll down to view content that is not immediately visible, ensuring comprehensive testing of all UI elements within the application.
2. UI Testing: Validate that the application behaves correctly when swiping down, checking for issues such as content loading, display of loading indicators, or layout changes.

## Radio Button Enabled

The Radio Button Enabled keyword in automation testing checks the state of a radio button element within a mobile or web application. This keyword verifies whether a specific radio button is enabled (i.e., it can be interacted with) or disabled (i.e., it cannot be interacted with). Understanding the state of a radio button is crucial for ensuring that the application's user interface behaves as expected.

1. Validation of User Interaction: Ensure that the radio button is enabled and can be selected by the user during the testing process. This is particularly important in scenarios where certain conditions may enable or disable options.
2. Conditional Logic Testing: Test scenarios where the availability of the radio button is conditional based on previous user actions or selections. For example, verifying that a radio button becomes enabled when a specific checkbox is checked.

## Open Notification

The Open Notification keyword is typically used in mobile test automation to open the notification drawer on a mobile device. This is particularly relevant for mobile application testing, where notifications play a crucial role in user engagement and functionality. By using this keyword, testers can ensure that the application responds correctly to notifications and that the notification content is displayed as expected.

1. Testing Notification Display: Verify that the notifications generated by the application are displayed correctly in the notification panel. This includes checking the content, icons, and any actions associated with the notifications.
2. User Interaction Verification: Ensure that users can interact with notifications, such as tapping on them to open the associated app or specific content. This helps in validating the entire user journey from notification to app functionality.

## Long Press

Long Press is a gesture-based interaction used in mobile apps, where a user touches and holds an element on the screen for an extended time (usually more than a second). This action typically involves touching and holding a screen element for an extended period, triggering specific behaviors or actions associated with that element.

1. Accessing Contextual Menus: Test whether long pressing on certain elements, like buttons or list items, opens the expected contextual menu or options. This is common in applications that provide additional functionality via long press actions.
2. Drag and Drop Functionality: Validate the behavior of elements that can be moved or rearranged using a long press. This includes testing the ability to drag items and ensuring they drop correctly in the intended location.

## Lock Screen

The Lock Screen keyword is used in mobile test automation to simulate locking the device screen. Locking the screen is a common mobile interaction where the screen is turned off or secured with a password, PIN, or biometric authentication, preventing unauthorized access until the user unlocks it.

1. Testing Background Behavior: Verify how the application behaves when the device is locked. This includes checking whether the app maintains its state, pauses operations or continues background processes as intended.
2. Notification Verification: Ensure that notifications sent by the application are displayed correctly on the lock screen. This helps confirm that users receive important alerts even when the device is not actively being used.

## Is Installed

The installed Keyword is used to check whether a specific application is installed on a mobile device or emulator. This keyword is particularly useful in testing scenarios where the presence or absence of an app affects the outcome of the test case or the functionality being tested.

1. Pre-Condition Checks: Before starting a test suite or specific tests, verify that the application is installed. This helps avoid test failures caused by attempting to interact with an application that is not present.
2. Dynamic Testing Environments: In environments where multiple applications may be installed or uninstalled frequently, this keyword allows testers to confirm the installation status of the required application dynamically.

## Implicit Wait

Implicit Wait is a synchronization mechanism that allows the testing framework to wait for a specified amount of time when trying to locate an element on the web page or in the mobile application. If the element is found before the time expires, the execution continues immediately; if not, the test will throw an error after the timeout period has elapsed.

1. Dynamic Content Handling: In web applications with dynamic content loading (e.g., AJAX calls), implicit waits help ensure that the driver does not fail when elements are not immediately available.
2. Reducing Flaky Tests: By using implicit waits, tests are less likely to fail due to timing issues, leading to more stable test results. This can reduce false positives and negatives in your test suite.

## Compare Text

The Compare Text keyword is used in test automation to compare two text strings and verify if they are identical. This keyword is typically used in scenarios where you need to validate the output of a function, the content displayed in a UI element, or the data retrieved from a system against an expected result.

1. Validation of UI Elements: Ensure that the text displayed in labels, buttons, and other UI components matches the expected values. This is fundamental in verifying that the application is functioning as intended.
2. Error Message Verification: When an action fails, comparing the actual error message displayed against the expected message helps ensure that appropriate feedback is provided to the user.

## Close Side Menu

The Close Side Menu keyword is used in mobile and web test automation to close a side menu or a navigation drawer that is currently open in an application. Side menus, also known as navigation drawers, are common UI elements that slide in from the side of the screen, often used to provide navigation links or additional options.

1. Navigation Management: In scenarios where a side menu can be opened and closed during testing, this keyword helps manage the navigation state, ensuring that the menu does not interfere with subsequent actions.
2. UI State Verification: After verifying the contents or functionalities within the side menu, the keyword can be used to close the menu, allowing testers to confirm that the main interface returns to the expected state.

## Close Notification

The Close Notification keyword is used to close or dismiss notifications that appear on the device screen. Notifications are typically pop-ups or alerts that provide users with important information or updates from various apps.

1. User Interface Cleanup: After verifying the content of a notification, the keyword can be used to dismiss it, helping maintain a clear and manageable UI state for further actions.
2. Preventing Interference: Notifications can obscure important elements on the screen. Closing them ensures that automated actions can interact with the necessary elements without obstruction.

## Click Element

The Click Element keyword is a fundamental Keyword used in test automation to simulate a user clicking on a specific UI element, such as buttons, links, checkboxes, or other interactive components within a mobile application.

1. Navigating Through the Application: Clicking on links or buttons is essential for navigating through different pages or sections of an application. This allows testers to validate the application's flow and ensure that all features work as intended.
2. Submitting Forms: When testing forms, the Click Element keyword is used to submit the form after filling in the required fields, allowing testers to verify that the submission process works correctly.

## Wait till element not found

1. A new keyword allows steps to wait until a specified element disappears from the screen. The step is marked successful when the element is absent, and failed if it remains visible.
2. System will wait till the element disappears from the DOM.
3. AI Self-Healing is explicitly disabled for this keyword, as the intent is to confirm element removal rather than locate an alternative

## Switch Test Data Keyword

A new "Switch Test Data" keyword has been introduced to allow dynamic switching of test data sets during execution. This feature is particularly useful when multiple scenarios within a suite require different user profiles or test data combinations.

* Users can select a different test data set from a dropdown at the required step level.
* The variable keys remain the same, but the mapped values are dynamically updated for subsequent cases.
* This approach reduces the need for creating duplicate test cases and maintains efficient user context switching within the same suite execution.


# Keywords

Review supported recorder keywords like Draw Signature and Reset App, including their behavior, limits, and best-fit automation uses in tests.

QApilot’s test recorder supports a rich set of keywords, including standard interaction keywords and custom keywords designed to handle complex mobile-specific scenarios. These keywords help testers build expressive, reusable, and reliable test flows without writing code.

***

### **Draw Signature**

The **Draw Signature** keyword enables automated drawing interactions on signature or canvas-based input fields.

**Behavior:**

* Accepts an input string directly or from a variable.
* If no input is provided, a random string is automatically generated.
* Draws each character of the input string inside the selected drawing element.
* Supports only lowercase alphabets (`a–z`) with a defined maximum input length.
* Characters are rendered as simple drawn shapes; visual readability is not required and is intended only as a reference.

### **Reset App**

Clears the app cache and session data, then relaunches a fresh instance of the application.

* Platform: Android only
* Behavior: Terminates the current app session, wipes all cached data, and starts the app from a clean state - equivalent to a manual cache clear and relaunch.
* Use case: Useful for resetting application state between test runs without restarting the device.


# Code Snippet Execution

Create, test, and run secure JavaScript snippets in QApilot to add custom logic, validations, and step outcomes to test flows without leaving the platform.

## **Code Snippet Execution**

QApilot allows users to create and execute **custom JavaScript code snippets** during test execution to support conditional logic and custom validations within test flows.

***

### **Overview**

Code snippets are reusable JavaScript functions that can be executed synchronously as part of a test case. Each snippet returns a boolean value (`true` or `false`) and can be used to influence test execution logic.

***

### **Creating a Code Snippet**

* Users can create JavaScript snippets from the **Code Snippets** UI.
* Only **JavaScript functions** are allowed.
* The maximum script size is **10 KB**.
* Each snippet can be **Created, Updated, Activated, Deactivated, and Tested** from the UI.

#### **Security Restrictions**

To ensure safe execution, the following are **not permitted**:

* System and runtime access (e.g., `process`, `require`, `import`, file system access).
* Database-related keywords such as `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE`, and `SELECT`.

The UI displays a complete list of restricted keywords during snippet creation.

***

### **Testing a Code Snippet**

* Snippets can be tested directly from the UI before use.
* Test execution requires selecting a **test data profile**.
* Test data values can be edited within a popup during testing.
* Every snippet must return either `true` or `false`.

***

### **Using a Code Snippet in a Test Case**

* A new keyword, **`ExecuteSnippet`**, is available in the test step editor.
* Users can select a previously created snippet from a dropdown.
* During execution, the snippet is retrieved from the database and executed **synchronously**.
* Test execution proceeds only after the snippet completes.

***

### **Execution Behavior**

* Snippets run in a **sandboxed environment**.
* Execution is synchronous and blocking.
* The returned boolean value determines the outcome of the step.

***

This feature enables flexible, secure customization of test logic while maintaining predictable and controlled execution behavior.


# Reusable Test Blocks

Build reusable functional blocks from shared steps, insert them into tests, handle exceptions, and centralize updates across flows with clear reporting.

## **Reusable Test Blocks**

Reusable Test Blocks allow you to group commonly repeated steps into a single functional unit that can be referenced across test cases. This feature improves maintainability, reduces duplication, and enables faster creation of consistent and reliable automation flows.

Reusable Test Blocks behave like modular building blocks inside QApilot’s automation engine. You can define them once and reuse them whenever needed within a test case.

***

### **Overview**

Many mobile test cases share similar foundations such as login flows, onboarding steps, search sequences, or checkout starting points. Previously, these steps had to be recorded or maintained separately in every test case.

With **Reusable Test Blocks** you can:

* Convert any collection of steps into a functional block
* Reuse the same block multiple times in a test case
* Reorder and manage steps inside a block
* Execute blocks as part of a test and see each step individually in reports
* Maintain logic in one place rather than editing multiple test cases

This ensures consistency, reduces maintenance overhead, and accelerates authoring of long or repetitive flows.

***

## **Key Features**

### **1. Create Functional Blocks from Test Steps**

<figure><img src="/files/xLbhSukLnAnbEwyt0Jia" alt=""><figcaption></figcaption></figure>

You can select one or more steps from an existing test case and convert them into a **Functional Block**.

This is ideal for:

* Login sequences
* Navigational flows
* Reusable validation steps
* Form-filling routines
* Repeated UI action groups

Once created, the block becomes available for reuse.

***

### **2. New Keyword: Functional Block**

QApilot introduces a new keyword called **Functional Block**.

This keyword allows you to insert a predefined Functional Block anywhere inside a test case.

Example usage:

* Add **Login Block** at the beginning of multiple test cases
* Add **Search Flow Block** wherever needed
* Loop or reuse the same block multiple times within the same test case

***

### **3.** Exception Block for Failure Handling

A global exception block at a test case level, to enable automated failure handling without manual intervention.

In complex test flows, a failing step would previously halt execution or require individual error handling to be configured for each step. Now, a dedicated Exception Block can be configured at the footer section within the test case. If any step fails during execution, exception block is automatically invoked, executing the defined actions in the block.

* Click on "Show Exception Block" icon at the top right

<figure><img src="/files/wwuLwz9TX0U9KTix1Aag" alt=""><figcaption></figcaption></figure>

* There's a new "Import Functional Block" that's activated at the footer section of the screen

<figure><img src="/files/cpClIzqRVGQ4qyD0CmQh" alt=""><figcaption></figcaption></figure>

* User can choose from a set of already configured functional blocks to act as an exception block.

<figure><img src="/files/19sz0r3sITkdsuCOPkmb" alt=""><figcaption></figcaption></figure>

* Upon failure of a test step, where an exception block is triggered, the view is as depicted -

<figure><img src="/files/4ihEA2Vtftmy3SUTsLdt" alt=""><figcaption></figcaption></figure>

**Note** - In case of failure of an exception block, the subsequent steps are taken up for execution, ignoring the failed exception block execution.

***

### **4. Step Ordering & Editing**

Inside a Functional Block:

* Steps can be rearranged
* Steps can be edited as needed
* The block maintains its internal order when reused

Changes to the block automatically reflect across all test cases that reference it.

***

### **5. Execution & Reporting**

During execution:

* When the block is triggered, each step inside it runs sequentially
* Execution reports expand and display **every individual step**
* This ensures complete traceability and easier debugging

Functional Blocks behave exactly like normal test steps during execution.

### 6. Bulk Activate and Deactivate

***

## **UI & Workflow**

### **Functional Blocks Tab**

A new tab called **Functional Blocks** appears in the sidebar next to the **Test Cases** tab.

Inside this tab, users can:

* View all created blocks
* Create a new block
* Edit existing blocks
* Delete or duplicate blocks
* Inspect steps inside a block
* Activate or Deactivate existing blocks individually or in bulk

The UI mirrors the Test Cases layout for familiarity and ease of use.

***

### **1. Creating a Functional Block**

There are two ways to create a Functional Block:

#### **Method 1: Convert Steps inside a Test Case**

1. Open an existing test case
2. Select one or more steps
3. Click **Create Functional Block**
4. Name the block
5. Save

The selected steps are moved or copied into the new block.

#### **Method 2: Create from Functional Blocks Tab**

1. Go to **Functional Blocks**
2. Click **New Functional Block**
3. Add steps manually
4. Save

***

### **2. Using Functional Blocks in Test Cases**

<figure><img src="/files/smzwDO3qnHRPpvY3uLH6" alt=""><figcaption></figcaption></figure>

To use a block:

1. Open a test case
2. Click **Add Step**
3. Select the **Functional Block** keyword
4. Choose the block from the dropdown

The block will appear as a single step, but during execution expands into its full sequence.

***

### **3. Find all cases where a functional block is referenced**

A "Find Mappings across Test Cases" option is now available for functional blocks and page items.

* Selecting this option opens a panel listing every test case and step where the selected functional block or page item is referenced.
* Use this before renaming, modifying, or removing a shared component to understand the full impact across the project.

### **4. Create Functional Blocks During Recording**

Group recorded steps into a functional block on the fly, without leaving the Recorder.

**Creating a New Block**

* Select one or more recorded steps.
* Choose "Add a new block" to create a new functional block from the selected steps.
* If no functional blocks exist in the project yet, a new one will be created automatically.

**Inserting into an Existing Block**

* Steps can also be added into an already-imported functional block using the "Insert into existing block" toggle.

**Deletion Behaviour**

* Removing a functional block from the Recorder view only removes that instance from the current session.
* The underlying functional block in the project remains untouched and fully reusable.

### **5. Import Steps and Functional Blocks into the Recorder**

Bring existing test steps and functional blocks into an active recording session without leaving the Recorder.

**Importing Test Steps**

* Select the import option within the Recorder screen.
* Choose any module and test case to browse available steps.
* Selected steps are copied into the current recording session.

**Importing Functional Blocks**

* Functional blocks can be imported from anywhere in the project.
* Once imported, the steps within the block are visible in context but remain non-editable, preserving the integrity of the shared block.

**Additional Step Management in the Recorder**

* Steps can be cloned directly within the Recorder view.
* Step order can be updated via drag or reorder controls within the Recorder.

## **Maintenance**

Functional Blocks help reduce maintenance by centralizing repeated logic.

For example:

* Updating the login flow updates it across **all** test cases that use the Login Block
* The system significantly reduces the risk of stale or inconsistent automation steps

***

## **Best Practices**

* Use blocks for repeated flows like Login, Navigate to Home, Search, Add to Cart
* Avoid creating overly large blocks; keep them focused
* Name blocks clearly (e.g., *Login with Valid Credentials*, *Perform Search*, *Open Orders Screen*)
* Review execution reports to ensure block behavior matches expectations


# API Test Automation

Build, script, execute, and report QApilot API tests with collections, reusable data, value extraction, and stateful workflows.

## API Test Automation in QApilot

QApilot lets you configure, execute, and evaluate API requests and collections alongside mobile testing workflows. Use API Automation to manage request data, environments, assertions, scripts, and execution reports.

***

## 1. Overview

API Automation in QApilot allows users to:

* Create and manage API collections
* Configure requests (GET, POST, PUT, DELETE, etc.)
* Attach pre-scripts and post-scripts
* Bind requests to structured test data
* Execute individual APIs or entire collections
* Capture and reuse dynamic values across steps
* Review execution logs and responses

The system is designed to support both deterministic testing and dynamic workflows.

***

## 2. Creating API Test Cases

Users can create API test cases within a collection.

Each API step includes:

* Request Method (GET, POST, POST form-data, x-www-form-urlencoded, etc.)
* Endpoint URL
* Headers
* Query Parameters
* Request Body (JSON, form-data, x-www-form-urlencoded)
* Authentication configuration
* Test Data binding

API steps can be executed independently or as part of a collection.

***

## 3. Test Data Management

API Automation supports structured test data management to allow reusable and maintainable test cases.

### 3.1 Static Test Data

Static test data contains fixed values that can be reused across API requests.

Example:

```
email = qa.user.example.test
password = Test123
```

Static values can be updated during execution if enabled.

***

### 3.2 Dynamic Test Data

Dynamic test data generates values during execution based on configured rules. These values are not overwritten during API execution.

***

### 3.3 Test Data Binding

Users can bind request fields to test data items. During execution:

* Bound variables are replaced with their corresponding values
* Updates can optionally be persisted (see section 6)

***

## 4. Pre-Script and Post-Script Support

QApilot supports custom scripting before and after API execution.

### 4.1 Pre-Script

Executed before the API request is sent.

Used for:

* Generating tokens
* Preparing payloads
* Transforming data
* Modifying test variables

### 4.2 Post-Script

Executed after receiving the API response.

Used for:

* Extracting response values
* Performing validations
* Updating test variables
* Preparing data for the next API step

***

## 5. Execution Modes

API automation supports:

#### 5.1 Test Flow

Executes individual API steps for validation and debugging.

#### 5.2 Execute Collection

Executes the entire API collection in sequence, supporting dependency chaining between APIs.

***

## 6. Saving Updated Test Data (New Enhancement)

API Automation now supports saving updated test data values that are modified during execution.

### 6.1 Save Updated Values from Scripts

When a pre-script or post-script modifies a variable that is linked to a selected test data item:

* The updated value can now be saved back into the test data set.
* This applies to both **Test Flow** and **Execute Collection** execution modes.

### 6.2 Static vs Dynamic Behavior

To maintain predictable data handling:

* **Static test data items** can be updated and saved.
* **Dynamic test data items remain unchanged** and will not be overwritten.

This ensures that dynamically generated values preserve their intended behavior.

### 6.3 Use Cases

* Saving authentication tokens for reuse
* Capturing IDs from API responses
* Maintaining session state across API chains
* Updating dependent values during execution

***

## 7. Enhanced Test Data Handling in API Recording (New Enhancement)

The API recording interface now provides improved test data usability.

### 7.1 Dropdown-Based Test Data Selection

The previous variable text input has been replaced with a dropdown that lists all existing test data items.

Benefits:

* Prevents duplication
* Encourages reuse
* Improves consistency

***

### 7.2 Inline Test Data Creation

Users can create new test data items directly from the dropdown interface without leaving the recording screen.

This maintains flow continuity and reduces context switching.

***

### 7.3 Intelligent Value Resolution

If a user selects an existing test data item and leaves the input field blank:

* The system automatically retrieves the value from the selected test data item.
* That value is used during execution.

***

### 7.4 Backward Compatibility

Existing API test cases continue to function as before. The enhanced UI improves usability without affecting prior behavior.

***

## 8. API Automation Reporting

Execution reports include:

* Request details
* Response body
* Status codes
* Headers
* Execution logs
* Script execution results
* Validation results

Failures are clearly highlighted with error details and execution context.

***

## 9. Key Benefits

* Unified API and UI testing platform
* Structured test data management
* Support for dynamic workflows
* Script-based value manipulation
* Controlled persistence of modified data
* Reduced manual intervention
* Improved reusability and maintainability

***

## 10. Summary

QApilot’s API Automation module enables scalable, state-aware API testing with structured data management and script-driven logic. With the latest enhancements, users gain greater control over how dynamic values are captured, persisted, and reused — enabling more reliable and maintainable API test workflows.


# Create and Manage Mobile Test Cases

Create, organize, filter, and execute QApilot mobile test cases, then manage steps, conditions, and recorded flows in one place.

## Create and Manage Mobile Test Cases

QApilot test cases define the mobile test steps you want to execute and evaluate. Create them with the [Test Recorder](/test-creation/record-mobile-test-steps/create-test-steps-with-the-test-recorder), [AI Suggest](broken://pages/WEz8OJmda3QlttxcSkW2), or manual test steps.

A test case is the reusable unit of mobile test coverage. Add test cases to a test suite, then select that suite in a test plan for execution.

***

## Prerequisites

Ensure you create a [Project](/ai-and-core-concepts/projects) before creating Test Cases in **QApilot**.

***

## Create Test Case

1. When you click on Test case, it will redirect to the list of Test Cases concerning the Project of the specific page that includes the list of the test steps if already recorded.

<figure><img src="/files/eyUly6X4FjDBMHTnE0BO" alt=""><figcaption></figcaption></figure>

As you can see above, various actions can be performed for these test cases.

1. **Bulk Actions → Activate and Deactivate:** This provides a convenient way to manage the status of multiple test cases simultaneously. You can quickly activate or deactivate multiple test cases or a single test case.
2. **Filter:** It allows you to display the desired test cases based on App, Version, Severity, Status, and Module.

Filter Test Case

<figure><img src="/files/LbrheUnDbuvSjsgSHE0V" alt=""><figcaption></figcaption></figure>

3. **Conditions:** Integrate Conditional Logic Directly Within Test Cases:
   * QApilot enhances flexibility in test case execution by allowing the integration of conditional logic. This feature enables you to create dynamic test flows based on specific conditions. Please refer to [Type: If Conditions](/test-creation/create-and-manage-mobile-test-cases/if-conditions-at-test-case-level).
4. **Execute:** The Execute Test Case feature is used to perform the steps of a specific test case to verify that an application behaves as expected. During execution, test cases are run under predefined conditions and monitored for expected outcomes. Please Refer [Test Plan Executions](/execution-and-reliability/run-mobile-test-plans)
5. **Upload Test Case Steps:** It allows you to import multiple test steps into your test case quickly. Instead of manually creating each step, you can upload a structured file with predefined steps.

Test Case Upload

<figure><img src="/files/hhJ4wK3k6Q8pHlSmJxk7" alt=""><figcaption></figcaption></figure>

Download the sample Excel file & fill in the details to import

6. **Edit/Create Test Case**
7. Navigate to Test Cases in the left-side navbar. Click the Create Test Case button in the top right corner of the Test Case List page to create a test case.

<figure><img src="/files/p6zQKYRMGggjeYwHu4p9" alt=""><figcaption></figcaption></figure>

8. Enter Test Case Title
9. Enter Test ID
10. Select Severity, OS, App Version
11. Module: A Module refers to a distinct, logical grouping of related test cases or functionalities within a testing framework. Modules help organize the testing process by breaking down the application under test into smaller, manageable sections or components.
12. Feature: A Feature refers to a specific functionality, capability, or aspect of the application being tested.
13. Story: It refers to a user story that describes a specific requirement or functionality from the perspective of the end user. It is often written in plain language to communicate what the user wants to achieve and serves as the foundation for defining test cases and scenarios.
14. Within each module, create specific test cases that relate to the module's functionality.
15. Linking: Link the test cases to the relevant modules and features to ensure organized test management.
16. Tags -
    1. Assign one or more tags to the test case for better organization and filtering. Tags are common across the project and can be created dynamically.
    2. Within each module, create specific test cases that relate to the module's functionality

***

## How to Manage Test Cases?

1. click on the Manage Steps of the respective Test Case that you have created.

<figure><img src="/files/EhZYETKibjFZyGRogGZa" alt=""><figcaption></figcaption></figure>

2. It will redirect to the below window that displays all the steps that you have created for this particular Test Case.

<figure><img src="/files/7cqNkz6M5e1W2vbFLsUM" alt=""><figcaption></figcaption></figure>

3. For each of these steps, it will include a screenshot of the element which you have clicked on that specific feature.
4. It will allow you to Edit this step, Edit Page Items, Disable, Delete, and view history.

More than one Test case Module can be combined to form [Test Suites](/test-creation/test-suite), and [Execution](/execution-and-reliability/run-mobile-test-plans) follows.

5. The history log includes detailed information such as the date of modification, the user who made the changes, and a summary of the updates.
6. If you delete the Test Case, you will lose all the recorded test steps associated with it.


# If Conditions at Test Case Level

Use if and if-else logic in test cases to branch execution based on variables or other test cases and support dynamic flows during automation runs.

In **QApilot**, you can add **If**, **If-Else** in your test cases based on a true or false condition. For example: **If** verifies the login status in a login test case, and **Else** will check credentials and redirections. This article discusses using **If**, **If-Else** Conditions in **QAPilot**.

***

## Prerequisites

* You Should Know how to Create a [Project](/ai-and-core-concepts/projects).
* You should also know how to [create a test case](/test-creation/create-and-manage-mobile-test-cases).

***

## Using If, If Else conditions in Test Cases

1. Navigate to Create Test Case Conditions and click on Create Condition.

<figure><img src="/files/gV54OTdQV1dld5coOh8A" alt=""><figcaption></figcaption></figure>

2. As you can see above, it allows you to create test case conditions using the two Rule Types: IF and IF-Else.
3. Using IF Conditions: Conditional Test Flows: Define IF-ELSE scenarios within your test cases to handle different paths based on specified conditions. This allows you to tailor the test execution to various scenarios and outcomes.
4. Enter Condition Name
5. Select a Rule: If or IF-Else

Rule Type

<figure><img src="/files/o4M8dvLCXHI3gMWK2b43" alt=""><figcaption></figcaption></figure>

6. Condition Type: Select a Condition from the dropdown: Testcase or Variable. when selecting a Condition Type, you choose between two options: Testcase or Variable. This selection helps control the flow of test execution based on specified conditions.

Condition Type

<figure><img src="/files/86MYbIdzQ6tmTRWMhJFN" alt=""><figcaption></figcaption></figure>

7. Testcase:
   1. Selecting Testcase as a condition means the system will execute actions based on the pass/fail status or output of a specified test case.
   2. For example, you might set a condition that if Testcase A fails, Testcase B will not execute, or if Testcase A passes, a specific follow-up action occurs.
8. Variable:
   1. Selecting Variables allows conditions to be based on specific values or states of variables within the test.
   2. You might, for instance, set a condition where if a variable (e.g., `user_logged_in`) equals "True," the test proceeds with actions that assume a logged-in state.
9. Click on the Create button. This will add Condition to your test step. Once it is created, it appears as a card and it is in an Active state shown below:

<figure><img src="/files/7rfZuTIlgsEDUyl59Zww" alt=""><figcaption></figcaption></figure>

10. There are a few Actions you can perform. You can check the condition details like View Detail, Edit, and Disable.


# Test Steps

Reorder, clone, filter, and edit test steps with screenshot-based views, OS tags, and updated page element references across Flutter and native projects.

### Step Ordering

1. Steps within a test case can be reordered by dragging them to the desired position. The updated sequence is saved automatically and reflected during execution.
2. Alternatively, user can click on the left of each row and enter the digit where the step need to be moved. On the right, user can also click on option and also choose "Update Order".

<figure><img src="/files/qurC20kIi9tRJq8U1xUA" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/TFzm82MNJanlsu9mH4dM" alt=""><figcaption></figcaption></figure>

### OS Filtering

1. For Flutter projects, QApilot uses a two-layer OS tagging system, at the Test Case level and the Test Step level.
2. Tagging a test case as Android, iOS, or Both determines whether it runs during a test plan execution. Within a "Both"-tagged test case, individual steps can further be tagged per platform, allowing platform-specific flows to coexist in a single test case.
3. For Native (Android-only or iOS-only) projects, tagging works at the test case level and all steps follow the project's OS.

   <figure><img src="/files/uflUofoavMHOnYeR8tyT" alt=""><figcaption></figcaption></figure>

   <figure><img src="/files/DVf0H37GVU9Lli8oEcQX" alt=""><figcaption></figcaption></figure>
4. Here's a example: Login scenario in a Flutter app - a Test Plan with a case called "Login to the app" tagged as Both (iOS & Android). It has 4 steps:

<table data-header-hidden><thead><tr><th width="76.91015625"></th><th></th><th></th></tr></thead><tbody><tr><td>Step</td><td>Action</td><td>Tag</td></tr><tr><td>1</td><td>Find the email input field</td><td>Both</td></tr><tr><td>2</td><td>Tap "Sign in with Google" button</td><td>Android</td></tr><tr><td>3</td><td>Tap "Sign in with Apple" button</td><td>iOS</td></tr><tr><td>4</td><td>Verify home screen loads</td><td>Both</td></tr></tbody></table>

When the test plan runs on Android: Steps 1, 2, and 4 execute. Step 3 is skipped.

When the test plan runs on iOS: Steps 1, 3, and 4 execute. Step 2 is skipped.

This means you only need one test case to cover both platforms - QApilot handles the branching automatically at runtime based on the OS tag on each step.

## **Clone a Step**

Each step in the test case steps listing now has a "Clone" option.

* Cloning a step creates an exact copy of it, inheriting all configurations: page, element selection, step name, and any associated parameters.
* This can be done in both the recording screen and test case management screen
* The cloned step is inserted immediately after the source step.
* All subsequent steps are automatically re-indexed to reflect the new order.
* A maximum of 5 test steps can be cloned at a time.

## **Step Editing - Navigation View**

The default view for test steps in Test Case Management has been updated from a text list to a screenshot-based navigation view.

**Default View**

* Each step displays its associated screenshot as the primary visual.
* Step details and intent are shown beneath the image.
* Step-level options (edit, disable, delete, history) are accessible by clicking on the screenshot.

**Switching Views**

* The traditional text-based list remains available as an alternate view toggle.

**Editing an Element from the Step View**

* Hover over or click any element in the screenshot to highlight it.
* A dedicated tab lists all OCR-identified text elements on that screen.
* All detected page elements and their XPaths are listed, following the same logic as the Recorder.
* Clicking "Update" creates a new page element and automatically updates the step to reference it - using the stored page source, without requiring a new recording session.


# Test Suite

Group test cases into suites, import them in order, run them together, and manage suite lifecycle actions from one screen inside your QApilot project.

Organize your [test cases](/test-creation/create-and-manage-mobile-test-cases) into test suites based on common functionalities or scenarios to manage and execute them effectively. Test suites will help you in executing and reporting the test plan status. You can add a test case to multiple test suites. This document will provide an overview and guidelines to create, edit, delete, and list test suites in **QApilot**.

***

## Prerequisites

Ensure that you create [Test Cases](/test-creation/create-and-manage-mobile-test-cases) in the Same [Project ](/ai-and-core-concepts/projects)before you can manage test suites in **QApilot**.

***

## Listing Test Suites

On the Test Suites List page, you will have the below options:

1. Navigate to **Test Suites** in the left-side navbar.
2. You can easily manage test suites on the **Test Suites** list page by **filtering**, or **searching**. The page displays test suites with **titles**, **types**, **creation dates**, **creators**, and **statuses**.
3. Click **Create Test Suite** in the top right corner of the screen.

<figure><img src="/files/F8DojiB3SQsf7kQfo6fC" alt=""><figcaption></figcaption></figure>

***

## Creating a Test Suite

1. Navigate to **Test Suites** in the left-side navbar. Click the **Create Test Suite** button in the top right corner of the Test Suites List page. Provide the below details to **Create a Test Suite**:

<figure><img src="/files/Bn6UrlMy31T0FYiP5cM2" alt=""><figcaption></figcaption></figure>

2. **Name(Required)**: Enter the **title** of the Test Suite in the Name field on the Create Test Suite page.
3. Select the operating system as the recorded test cases are for Android. Selecting Android.
4. The below success message will display:

<figure><img src="/files/Jfsol7CQo7qPsofalxsJ" alt=""><figcaption></figcaption></figure>

5. The created Test Suite will be in the draft state.

<figure><img src="/files/LXgvYUoKPeFhJmb8FdJt" alt=""><figcaption></figcaption></figure>

6. Click on "Import Test Cases" to see a list of all available test cases.

<figure><img src="/files/AoQotySRLEb0rwfRtvQk" alt=""><figcaption></figcaption></figure>

7. This will redirect to the below window:

<figure><img src="/files/rXWgVDcJkVV7iWgwcrmg" alt=""><figcaption></figcaption></figure>

8. Select the test cases you wish to include in the test suite.

<figure><img src="/files/LhyjWK9dVf0s1sjofdiA" alt=""><figcaption></figcaption></figure>

9. Click on the Yes and "Move to Test Suite" to add the selected test cases.

<figure><img src="/files/7FcBp0ccMIc35mw4Ynqj" alt=""><figcaption></figcaption></figure>

10. Ensure that the test cases are ordered sequentially as required for the flow of the process.
11. Once the test suite is created, click on the "Run" button to start the [execution](/execution-and-reliability/run-mobile-test-plans).
12. The test suite will execute each test case in the order they are arranged.
13. It allows you to perform various actions on the Test Suite which are: View Details, Edit, Disable, and Delete.

<figure><img src="/files/1KdHJthBsEwAFYB9JjPv" alt=""><figcaption></figcaption></figure>

14. If you delete the Test Suite, you will lose all test cases associated with it.


# Test Rule

Associate test suites with relevant test data through rules, then execute the full grouped workflow and manage it over time within a project.

Test Rules feature facilitates the appending/associating of relevant Test Data to the Test Cases under the respective Test Suite. This is the key step before execution of Test cases to check the extent of functionality concerning the app. This specific procedure will determine the validity of Test data for the automation testing process.

***

## Prerequisites

Ensure that you create a [Test Suite](/test-creation/test-suite) in the Same [Project ](/ai-and-core-concepts/projects)before you can manage Test Rules in **QApilot**.

***

## Listing Test Rules

On the Test Suites List page, you will have the below options:

1. Navigate to **Test Rules** in the left-side navbar.
2. You can easily manage test suites on the **Test Rules** list page by **filtering**, or **searching**. The page displays test rules with **titles**, **types**, **creation dates**, **creators**, and **statuses**.
3. Click **Create Test Rule** in the top right corner of the screen.

<figure><img src="/files/uzSkl5FOzOirHUzTBKSK" alt=""><figcaption></figcaption></figure>

***

## Creating Test Rule

1. On the Test Rule Home Page, click on the Create Test Rule as shown below:

<figure><img src="/files/1FdXZ5AWglvGuytcBDyS" alt=""><figcaption></figcaption></figure>

2. A dialog box appears as shown below. Enter the Title in the placeholder text box.
3. Select Operating systems(OS). Click the Save button.

<figure><img src="/files/Yscw5LfmCK1WQ3BnS9eC" alt=""><figcaption></figcaption></figure>

4. The New Test Rule is created and it will be in the Active State.

<figure><img src="/files/nUY3YhhyBqms7ydNds56" alt=""><figcaption></figcaption></figure>

5. Click the View Details option. The below screen is shown.

<figure><img src="/files/wI72uh4HijlBp0sRNOmZ" alt=""><figcaption></figcaption></figure>

6. Click the Import Test Suites option. Add Test Suite from the available Test Suite List.
7. Like test suites, Once the test rule is created, click on the "Run" button to start the [execution](/execution-and-reliability/run-mobile-test-plans).
8. The system will execute each test suite within the rule sequentially.
9. It allows you to perform various actions on the Test Rule which are: View Details, Edit, Disable, and Delete.

<figure><img src="/files/629BsyWeluXCmIrhxFjl" alt=""><figcaption></figcaption></figure>

10. If you delete the Test Rule, you will lose all test suites associated with it.


# Test Data

Create, manage, and clone test data sets with reusable key-value items so executions can run with consistent or copied inputs across test plans.

Test Data signifies the values or the database records that are used as sample data to validate the efficiency of the application. Test data is passed in various formats based on the requirement.

Create the necessary data sets, such as valid login numbers and passwords for a login test case. Save the test data and select the preferred one while running the test case.

***

## Prerequisites

Ensure that you have the Key and Value.

***

## Listing Test Data

On the Test Data List page, you will have the below options:

1. Navigate to **Test Data** in the left-side navbar.
2. You can easily manage test data on the **Test Data** list page by **searching**. The page displays test data with **titles**, **creation dates**, and **statuses**.
3. Click **Create Test Data.**

<figure><img src="/files/dvPQIOYK4ZHp5d8otCbg" alt=""><figcaption></figcaption></figure>

***

## Creating Test Data

1. On the **Home** page, click the + icon on the top-right corner.

<figure><img src="/files/PuKLlK93Jz3MY7KO1yeZ" alt=""><figcaption></figcaption></figure>

2. The text input box to **Create Test Data Item** is displayed.
3. Enter the text for the **Title**
4. Click the **Create** button to enable the creation of a new **Test Data Item** as shown below.

<figure><img src="/files/9ZT2X76BYE04WaWqTNwJ" alt=""><figcaption></figcaption></figure>

5. On the **Test Data** card, click the three-dot menu on the right.
6. A dropdown is shown concerning the menu.

<figure><img src="/files/Ct9TulZe0lR41FokDMcG" alt=""><figcaption></figcaption></figure>

3. Click the **View Detail** option as shown above.
4. The View Details home page is shown. The User can create a new record by clicking the Create Test Data Item

<figure><img src="/files/rALMCmEYASOXYyNWymSn" alt=""><figcaption></figcaption></figure>

5. It redirects to the below popup

<figure><img src="/files/CzSrpuEne0E1KuDtnzvr" alt=""><figcaption></figcaption></figure>

6. Enter the Key and Value to Create a Test Data Item.
7. Click the three-dot menu to manage the changes concerning every **Test Data** element.
8. The users are allowed to **Edit**(make changes), Disable, and Delete Test Data elements.

## Cloning Test Data

Test data can now be cloned from one test plan to another, reducing manual setup and improving reusability across test suites.

1. Testcase Management>Test Data tab
2. Click on the "Clone" option within the options pop-up

<figure><img src="/files/G1Khkm7kohcZQnYHPTpa" alt=""><figcaption></figcaption></figure>

3. Choose a name. If user action is taken, the original name is appended with "(Cloned)". The creation timestamps of the Test Data within, would be that of the cloned time.

<figure><img src="/files/j81XGKWLr83tt8UzGH96" alt="" width="563"><figcaption></figcaption></figure>

<figure><img src="/files/F7zRpDIPsHgDOM2thbLb" alt="" width="546"><figcaption></figcaption></figure>


# Dynamic Test Data

Select existing test data from the recorder, create items inline, and update variables during execution without leaving the flow while recording.

### Dynamic Test Data during Recording

We’ve enhanced the test data handling experience within the Recorder to improve usability, reduce context switching, and provide better control over how input data is managed during test creation.

#### Background

Previously, when recording steps that required input values, users could either:

* Enter direct input data, or
* Use a variable, which would then automatically be added to the test data set along with its corresponding value.

While functional, this approach required manual entry and did not provide a structured way to reuse existing test data items efficiently.

***

### 1. Dropdown-Based Test Data Selection

The standard variable text box has now been replaced with a **dropdown menu** that lists all existing test data items for the selected test data set.

This allows users to:

* Easily select from previously defined test data items
* Maintain consistency across test cases
* Avoid manual retyping of variable names

<figure><img src="/files/fPO3CaTqT0zcXcrQQ0mX" alt=""><figcaption></figcaption></figure>

***

### 2. Inline Test Data Item Creation

Users can now create new test data items directly from the same dropdown interface.

Instead of navigating away from the Recorder screen:

* Select the option to create a new test data item
* Define the required value inline
* Continue recording without interruption

This ensures smoother workflow and eliminates unnecessary screen transitions.

***

### 3. Intelligent Selection Logic

If a user selects an existing test data item and leaves the input field blank:

* The system automatically retrieves the value from the selected test data item
* That value is used during step execution

This reduces redundancy and ensures accurate value binding without additional input.

***

### 4. Flow Continuity & Backward Compatibility

The existing logic for creating variables during recording remains fully supported.

When new items are added inline:

* They are automatically incorporated into the test data set
* The system continues to behave consistently with prior variable-handling logic

No changes are required to existing test cases.

### 5. Update Test Data During Run time

QApilot supports dynamic test data updates mid-execution using a new "Update Test Data" keyword, allowing the same functional block to be driven by different data values without duplicating steps.

<div align="left"><figure><img src="/files/kX1zmsNWNyNkqquhXeS6" alt="" width="375"><figcaption></figcaption></figure></div>

<figure><img src="/files/EVjx7xgtFSqnrw3Vg977" alt=""><figcaption></figcaption></figure>

With the new keyword, users can specify a variable name and provide the updated value as the step input.

* For dynamic variables, QApilot generates the value at runtime according to the configured rules and assigns it back to the variable automatically.
* For static variables, the value is applied directly before the step executes.

***

### **6. Custom Test Scripts**

QApilot now supports a **Custom Test Script** type that lets users write lightweight native JavaScript snippets to generate values dynamically at execution time.

This is useful for scenarios where the required test data depends on runtime context - such as today's date, a calculated future date, a formatted string, or a unique identifier - without relying on external data sources or manual updates before each run.

***

**Setting Up Custom Test Script**

When creating or editing a test data item, select **Custom Test Script** from the **Data Type** dropdown. A code editor will appear where you can write your JavaScript snippet.

<figure><img src="/files/KXzpIG9JI6mk6eK1Ifh9" alt=""><figcaption></figcaption></figure>

The snippet runs once at the start of execution. Its return value is injected into every step that references the variable for the duration of that run.

<figure><img src="/files/uoj0s75Q8AZuSrkPxjqM" alt=""><figcaption></figcaption></figure>

***

**Writing Your Snippet**

* Only standard, native JavaScript is permitted - no TypeScript, transpiled code, or external libraries.
* The snippet must explicitly `return` a value. Execution will fail if no `return` statement is present or if the script returns `undefined`.
* Maximum length: **1,000 characters**.

**Examples:**

1. Get a date 5 days from today:

```javascript
let targetDate = new Date();
targetDate.setDate(targetDate.getDate() + 5);
return targetDate.toLocaleDateString();
```

2. Format today's date as YYYY-MM-DD:

```javascript
let d = new Date();
let month = String(d.getMonth() + 1).padStart(2, '0');
let day = String(d.getDate()).padStart(2, '0');
return d.getFullYear() + '-' + month + '-' + day;
```

3. Generate a unique timestamped identifier:

```javascript
return 'testuser_' + Date.now();
```

***

**Restrictions**

The following are not permitted:

* `import` / `require` - no external libraries or modules
* `fetch`, `XMLHttpRequest`, `WebSocket` - no network access
* Scripts that return `undefined` or have no `return` statement

Violations will cause a validation error at the Test Data resolution step, before any test steps run.

***

**Execution Behaviour**

The snippet executes before the first test step runs. The resolved value is then used consistently across all steps that reference that variable within the same run.

***

**Viewing Results in Reports**

After execution, the **Test Data** tab in the execution report displays the resolved value - the actual output of the script - alongside the steps that used it. This makes it easy to audit what value was in play for any given run.

### Impact

This enhancement streamlines test data management directly within the recording flow, improves reusability of data, reduces manual effort, and ensures cleaner separation between test steps and test data configuration. The addition of Custom Test Script further extends this flexibility to handle time-sensitive, computed, or uniqueness-dependent values without any external tooling.


# HTTP Master

Configure API collections, requests, variables, scripts, assertions, and collection runs directly within QApilot’s HTTP Master for integrated API testing.

The HTTP Master feature in **QAPilot** provides an integrated solution for validating API endpoints directly within test cases, functioning similarly to tools like Postman. It enables testers to execute and validate API calls (GET and POST methods) as part of their testing workflow.

***

### Prerequisites <a href="#httpmaster-prerequisites" id="httpmaster-prerequisites"></a>

1. Obtain the required API details from your developer, including the endpoint, request type (GET or POST), and any necessary JSON code.
2. Ensure that you have a [Test Data](/test-creation/test-data)

***

### Creating HTTP Master <a href="#httpmaster-creatinghttpmaster" id="httpmaster-creatinghttpmaster"></a>

1. Navigate to the HTTP Master and it will redirect to the below screen:

<figure><img src="/files/D2VRpFKIvxOTM03OXf3b" alt=""><figcaption></figcaption></figure>

2. As you can see above, it allows you to choose any one of the above two methods:
   1. API Call: An API Call refers to a request made by a client application to a server to perform an action or retrieve data. In automation testing, API calls validate the functionality, reliability, and performance of Application Programming Interfaces (APIs) that serve as the backbone of modern software systems.
   2. Import OpenAPI: OpenAPI (formerly known as Swagger) is a widely used specification for defining RESTful APIs. Importing OpenAPI specifications into an automation testing framework enables testers to streamline the creation and management of API tests. This integration eliminates the need for manual test case creation by auto-generating API endpoints, request formats, and test scenarios from the specification.

<figure><img src="/files/DfYilB2seKstCPS4W3U9" alt=""><figcaption></figcaption></figure>

3. As you can see above, If the user wants to create a new collection, click on New Collection.
4. A confirmation popup will appear asking if you want to create a new collection.\
   Confirm the creation of the new collection in the popup.

<figure><img src="/files/41xsaluMRp1871ZYajGD" alt=""><figcaption></figcaption></figure>

5. In this collection, you can add a new module.

<figure><img src="/files/TZtnPjOhayGEUutUkCtJ" alt=""><figcaption></figcaption></figure>

6. You can add new requests within this new module. The collection is successfully created, and the new request is added.

<figure><img src="/files/derlxUkooLn3wrUkc80Q" alt=""><figcaption></figcaption></figure>

7. The dropdown on the left allows users to choose the type of HTTP request: **GET**, **POST**, **DELETE**, or **PUT**. This selection determines the kind of request that will be made in the API test.

<figure><img src="/files/5puNGKTrCRry3ggtJNK7" alt=""><figcaption></figcaption></figure>

8. In this request, we can pass the endpoint URL: and, if required, an authorization token for the API request. Please select the appropriate Auth Type:
   1. **Basic Auth**: Enter the Username and Password.
   2. **Bearer Token**: Provide the Token ID."
9. **Headers**: Here, we can provide headers. What are the prerequisites required for those headers? We need to provide headers.
10. In the Request Body section, you can choose between the following options:
    1. **Form-data**: Used for sending key-value pairs, often for file uploads or form submissions.
    2. **Raw**: Allows sending raw data in JSON, XML, or plain text formats.
11. **Scripts:** We provide two scripting options: **Pre-Request** and **Post-Response**.
    1. **Pre-Request Script**:\
       This script is executed **before** the API request is made. It can be used to set up dynamic values, generate tokens, or prepare the environment for the API call.\
       Example: Setting an authorization token or a timestamp.
    2. **Post-Response Script**:\
       This script is executed **after** the API request and response cycle. It captures and processes the response from the API. You can use this to validate response data, extract values for subsequent requests, or log outputs.
12. **Variables:** If the user needs to use variables for this API, they can be defined and provided here. Variables allow for dynamic values to be passed into the request, making it more flexible and reusable. Variables are used to store API responses, enabling data persistence and seamless reuse across subsequent requests within a collection.

<figure><img src="/files/0w4o9QnJPRUHpoJvlmMA" alt=""><figcaption></figcaption></figure>

13. **Type:** Specifies the source of the variable. For example, selecting "Response Headers" means the variable will extract data from the API response headers.
14. **XPath:** A path to pinpoint the specific part of the response from which data should be extracted. For example, you can use XPath expressions to retrieve values from JSON or XML responses.
15. **Variable:** The name of the variable where the extracted value will be stored for later use in subsequent requests.
16. **Assertion:** This dropdown allows you to define validations or checks for the extracted data. Available options include:
    1. **Save:** Save the value without additional validation.
    2. **Equal To:** Ensure the value matches a specific value.
    3. **Contains:** Check if the value contains a specific substring.
    4. **Greater than Equal / Less than Equal / Greater than / Less than:** Perform numerical comparisons on the extracted value.
17. **Asset Value:**
    1. If assertions are applied, this field specifies the value to be used in the validation.
18. **"Add New" Button:**
    1. Allows adding additional variables to extract and validate multiple pieces of data within a single request.
19. After importing the collections, executing the collection requires prerequisite test data to be imported. This test data is typically verified using environment variables in Postman. Similarly, to run the same collection in this platform, the same test data must be imported.
    1. **Collections Tab**: Displays the imported collections that contain API requests, modules, and workflows.
    2. **Test Data Tab**: Displays the associated test data files required for running the collections.

<figure><img src="/files/ejECEhi4GJz32KYXTtQR" alt=""><figcaption></figcaption></figure>

To execute the entire collection, follow these steps:

1. **Click on 'Run Collection'**: This will initiate the execution of all requests within the selected collection.

<figure><img src="/files/EgyJVABv7PE5H3v3VNeq" alt=""><figcaption></figcaption></figure>

2. **Apply Run Settings**:
   * **Select Test Data**: Choose the test data files that should be used for this run. These files will be applied to the requests based on the variables within the collection.
   * **Set Delay Time**: Specify the delay time between each request. This controls how much time should elapse between the execution of one request and the next, allowing for appropriate pacing.
   * **Save Response**: Choose whether to enable or disable the option to save the responses to the requests. Enabling this allows you to store the responses for later analysis or reporting.
3. **Click 'Save & Run'**: After configuring the settings, click on **Save & Run** to execute the entire collection. The platform will run all requests in sequence, apply the test data, and follow the delay time and response-saving rules.
4. Once the execution is completed, a detailed report will be generated, which includes the results of all requests, response times, assertions, and any failures that occurred during the run."

<figure><img src="/files/Es7B1mc3cbconTcgoR9U" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/IdRRG416cJ6E79EbFNlB" alt=""><figcaption></figcaption></figure>


# Dynamic Random Test Data Generation for APIs

Generate random API test data with formats, length rules, regex patterns, and user-defined values to reduce collisions at runtime during repeated runs.

QApilot supports **dynamic random test data generation** to reduce dependency on static values and improve test reliability across executions.

Users can mark specific test data items as **Random** instead of Static and configure how the value should be generated. This includes defining a custom format using prefix and suffix text with a `{{random}}` placeholder, selecting the data type (such as Email, Alphanumeric, or Numeric), and setting minimum and maximum length constraints.

<figure><img src="/files/C0fCp8dvHPlvgfAN0Gvm" alt=""><figcaption></figcaption></figure>

### Configuration Options

When a test data item is marked as **Random**, the following configuration options are available:

#### Text Customisation

* Users can define a custom format using **prefix** and **suffix** text.
* Use the placeholder `{{random}}` to indicate where the generated value should be inserted.
* Example: `order_{{random}}_test`

#### Length Constraints

* Users can specify minimum and maximum limits, depending on the selected data type.

### Supported Data Types

#### 1. Alphanumeric

* Accepts both letters and numbers
* Length-based generation
* **Minimum:** 1 character
* **Maximum:** 100 characters

#### 2. Numeric

* Accepts numbers only
* Value-based generation
* **Minimum value:** 0
* **Maximum value:** 9999

#### 3. Regex-Based Random Data

* Accepts a **custom regular expression pattern**
* Example: `^[A-Za-z0-9]+$`
* Regex must be valid and is verified before execution
* Generated values strictly follow the provided pattern

#### 4. User-Defined Random Data

* Accepts **single or comma-separated alphabetic values**
* Example: `small,medium,large`
* A value is randomly selected from the provided list during execution

<figure><img src="/files/Qr8sXh5WWmfPLCvqNAjv" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/uQ0ApbcEGPYMHTt9lq2f" alt=""><figcaption></figcaption></figure>

### Execution Behavior

* Random values are generated **just before execution**.
* Generated data respects all configured rules and constraints.
* Values are injected automatically into the test flow without manual intervention.
* Each execution can use a fresh value, reducing data collisions and retries.

During execution, QApilot automatically generates the required random values based on the configured rules and injects them into the test flow before execution begins. This ensures each run uses fresh data while still respecting defined structure and constraints.

This enhancement helps avoid data collisions, supports repeated executions, and improves overall test robustness without requiring manual data updates.


# Run Mobile Test Plans

Create and run test plans from suites, rules, cases, or deep links, then configure devices, data, settings, CI/CD, and reports for each run.

## Run Mobile Test Plans

A QApilot test plan defines what runs, where it runs, and which data and settings apply. Run a plan from a test suite, rule, test case, or deep link, then review the resulting execution report.

A test plan is an execution configuration. It can use a [test suite](/test-creation/test-suite), [test rule](/test-creation/test-rule), [test case](/test-creation/create-and-manage-mobile-test-cases), or [deep link](/use-cases-and-best-practices/deep-links) as its source. Configure the device, app source, test data, and execution settings before running.

This guide explains how to prepare and execute a test plan with a test suite and test case.

***

## Prerequisites

You should know how to Create a [Test Case](/test-creation/create-and-manage-mobile-test-cases), [Test Suite](/test-creation/test-suite), [Test Rule](/test-creation/test-rule), and [Deeplink](/use-cases-and-best-practices/deep-links).

***

## Listing Test Plans

On the Test Plans List page, you will have the below options:

1. Navigate to **Test Plans** in the left-side navbar.
2. You can easily manage test plans on the **Test Plans** list page by **filtering**, or **searching**. The page displays test suites with **titles**, **types**, **creation dates**, **creators**, and **statuses**.
3. Click **Create Test Plan.**

<figure><img src="/files/rBNuBHd0j9IMkyloAIAs" alt=""><figcaption></figcaption></figure>

***

## Steps to Create and Execute Test Plan

1. Navigate to **Test Plan** in the left-side navbar. Click the **Add Test Plan**. Provide the below details to **Create a Test Plan**:

<figure><img src="/files/9n6NnMbvwsDtxSwMpk7P" alt=""><figcaption></figcaption></figure>

2. It redirects to the Test Execution Screen:

<figure><img src="/files/VbpWDLtNEPnIUOXPbTm3" alt=""><figcaption></figcaption></figure>

3. The User is redirected to the execution screen. The Execution process takes three steps.
4. Enter the Title of the Execution in the respective text box as shown below.
5. Select the Operating System.
6. Select the Source From [Test Rule](/test-creation/test-rule), [Test Suite](/test-creation/test-suite), [Test Case](/test-creation/create-and-manage-mobile-test-cases), or [Deeplink](/use-cases-and-best-practices/deep-links).
7. click on the Next

<figure><img src="/files/6u0RW1yAXX3KfDpNev8g" alt=""><figcaption></figcaption></figure>

8. Select the **Virtual Device** for execution in the second step.
9. Select the respective **Device** from the dropdown. **QApilot** allows multiple devices to perform running tests concurrently across various devices to ensure an application functions correctly.
10. Select [Test Data](/test-creation/test-data) from the drop-down.
11. Select the **App Source** from the dropdown. Select the **Next** button.

<figure><img src="/files/lCjlOGGWZAld99vjjwju" alt=""><figcaption></figcaption></figure>

12. The third step includes Execution Settings which need to be applied, otherwise, default settings can be retained as per the Business Requirements.

<figure><img src="/files/Jm1qJY8unjvVCAFHvUFN" alt=""><figcaption></figcaption></figure>

13. Execution Settings are configurations to apply for the execution:
14. Enable Screenshot: Enable Screenshots allow the capture of images during test execution, which is essential for debugging, validation, and reporting purposes.
15. Step Image Screenshot: Step Image Screenshot captures a visual snapshot of the application state at specific test steps.
16. Auto close Contextual popup: This refers to the automatic dismissal of pop-up windows, tooltips, or contextual menus after a specific user action, delay, or event.
17. Enable Geo Location: This allows applications to access or simulate the user’s physical location.
18. Wait Time Between Steps: Wait Time Between Steps is the deliberate pause added between consecutive actions in a test script to ensure that each step completes properly before the next begins.
19. Command Time Out: Command Timeout is the maximum duration that an automation command is allowed to run before it is forcefully terminated.
20. Max Concurrent Errors: Max Concurrent Errors refers to the maximum number of errors or failures that are allowed to occur simultaneously within a single test execution or session.
21. Advance options: These configurable settings allow testers to fine-tune the behavior and performance of test executions.
    1. Enable Video: Enable Video allows for recording a video of the entire test execution session. This feature captures each step, action, and interaction within the application as the test progresses, creating a valuable visual record.
    2. Enable CPU: Enable CPU is a feature that allows testers to monitor the CPU usage of a device or application during test execution.
    3. Enable Memory: Enable Memory allows testers to monitor the memory usage of a device or application during the execution of tests.
    4. Enable Network Trace: Enable Network Trace allows testers to capture and analyze the network traffic generated by an application during testing.
    5. VPN Required: VPN Required typically refers to the necessity of using a Virtual Private Network (VPN) to securely connect to specific resources, environments, or networks that are not accessible over the public internet.

<figure><img src="/files/A4DiVe7oeQRBdjwWnOXT" alt=""><figcaption></figcaption></figure>

22. CI/CD Configurations: By enabling CI/CD configurations, you can ensure that your code is continuously validated through automated tests. Refer to [Continuous Integration/Continuous Deployment](broken://pages/uCMIoPmYGvvNWc5AnOuA)

For Cloud Device Execution, CD/CD Configuration is applicable.

<figure><img src="/files/WiwX6mr72Zd97K2S0cYv" alt=""><figcaption></figcaption></figure>

23. After applying the Execution Settings, click on the save button to Execute.

<figure><img src="/files/GXmUPpUKgmwjQVmP6Tzx" alt=""><figcaption></figcaption></figure>

24. The below Confirmation window will display. Click on the Yes button.

<figure><img src="/files/aQjuDRQN0YSOBw7Qrs82" alt=""><figcaption></figcaption></figure>

25. The Test Suite is executed as per the specified criteria.

<figure><img src="/files/o3Tgx13O2LCylMXy3ori" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/QreCdz6EgaFIxiiv0r3p" alt=""><figcaption></figcaption></figure>

26. As you can see below, Execution is running. Total Cases are displayed along with the Notifications.

<figure><img src="/files/H4gQggu5DBV1wsgS2Mwg" alt=""><figcaption></figcaption></figure>

27. Once the executions are completed, these are acknowledged in the form of [Reports](/reports-security-and-release-readiness/mobile-test-execution-reports).

<figure><img src="/files/qMIYU4YfHXLwFvZ9uvaV" alt=""><figcaption></figcaption></figure>

28. Click the eye/view icon under the Actions columns to View the report's details.
29. The user is redirected to the detailed view of the executed Suite.

<figure><img src="/files/vzl2Um2cIoBKOIBqw1pZ" alt=""><figcaption></figcaption></figure>

30. The report has a set of tabs displaying different aspects of the executed process.
31. The Summary tab provides the overall view as shown above.
32. The Testcase tab displays details of every step and the respective timings and status.

<figure><img src="/files/ZYvWoc0PcaWtb4ncnxyb" alt=""><figcaption></figcaption></figure>

33. The Artifacts tab shows the screenshots.

<figure><img src="/files/IfdcSQIJLgOOjLoJNU3I" alt=""><figcaption></figcaption></figure>

34. The Test Data tab displays the Test values used for the execution process.
35. Others tab displays the settings of the execution process which includes the includes of Flags and Debug Logs.

<figure><img src="/files/4VWYN1nTbnKFWBlAeZzQ" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/DcEGdVEHzMxfZ84lycYx" alt=""><figcaption></figcaption></figure>

36. The New Test Plan is created and it will be in the Active State displays on the Test Plan Listing Page.
37. It allows you to perform various actions on the Test Plan which are: Edit, Schedule Run, Enable CI/CD, Disable, Delete
38. [Schedule Run](/execution-and-reliability/schedule-test-plans)
39. [CI/CD](broken://pages/uCMIoPmYGvvNWc5AnOuA)

<figure><img src="/files/MBXhcvmJvB9vdMayXUf4" alt=""><figcaption></figcaption></figure>

40. If you delete the Test Plan, you will lose all Run reports and Run configurations associated with it.


# Schedule Test Plans

Schedule QApilot test plans to run once or daily, then review, edit, or delete upcoming runs from the scheduler list for automated regression coverage.

In **QApilot**, you can schedule your test plans to automate their execution and monitor your application's performance over time. You can schedule them for specific times and dates or run them immediately. You can even set them to run at regular intervals. Scheduling your tests for regression outside of office hours is a valuable way to minimize production disruptions and ensure optimal resource usage. This guide will show you how to schedule a test plan in **QApilot**.

***

## Prerequisites

Before you schedule a test plan in **QApilot**, you must understand the concepts of creating the [Test Plan](/execution-and-reliability/run-mobile-test-plans).

***

## Schedule a Test Plan

1. Click the **Test Plan** tab in the left sidebar of the dashboard to access the **Test Plan List** page.
2. Hover your mouse over the **Schedule Run** button on the Test Plan options you want to schedule and select the **Schedule Run** option from the dropdown list.

<figure><img src="/files/3YraNiLiN3y7AEiwjpfd" alt=""><figcaption></figcaption></figure>

2. It redirects to the below screen. Please select the date & time to schedule execution.

<figure><img src="/files/bgL6FNa0Z4pBLQZgthpK" alt=""><figcaption></figcaption></figure>

3. Click the **Calendar** icon to choose the **Date and Time** for the scheduled execution of this test plan. You can change the default value, which is set to the current date. By default, it displays the current time, but you can change it to the desired time for executing the test plan.
4. Click **Repeat** to select the **Frequency** for executing the test plan. The available options are:
   * **Don't Repeat**
   * **Daily**
5. After applying the date and time configurations., click on the Save button. At the scheduled time, the tool will automatically initiate the test plan and run all specified tests.

***

## **View Test Plan Schedules**

1. Navigate to **Schedulers** on the left-side side navbar. Click the **Schedulers** tab.
2. You can view the **Schedule Name**, **Test Plan**, **Frequency**, and **Next Run** of the scheduled test plans on the Schedules list page. Click the **ellipsis** icon to open a dropdown menu and select **Edit** or **Delete** the scheduled test plan.


# AI Auto-Healing for Mobile Tests

Learn how QApilot auto-healing recovers selected locator failures, marks healed steps in reports, and supports reviewed locator updates.

## AI Auto-Healing for Mobile Tests

QApilot auto-healing attempts to recover a test step when its original locator fails after a minor UI change. It records healed steps in the execution report so you can review and approve locator updates.

#### **Overview**

QApilot’s **AI Auto-Healing** automatically repairs broken test steps caused by minor UI or element changes between app versions, ensuring your test cases remain stable and maintainable across releases. When a locator fails during execution, QApilot intelligently re-identifies the element using a multi-layered fallback process and updates the step context accordingly.

#### **How It Works**

**1. Locator Precedence**

QApilot resolves element changes in the following order of precedence:

1. **Element ID / Accessibility ID** – Primary and most reliable source.
2. **XPath & Tag Attributes** – Used for fuzzy matching when ID changes.
3. **Visual Match (Image Processing)** – Detects elements based on visual similarity when structural identifiers differ (e.g., color or layout change).
4. **Coordinate Fallback** – As a last resort, QApilot interacts with the element’s previously recorded screen coordinates.

If a step succeeds via a fallback method, QApilot marks it as **healed** in the execution log.

***

#### **Where to View Auto-Healing**

* After **test execution**, healed steps are highlighted in the **Execution Report**.
* Each healed step displays:
  * The **original locator**
  * The **AI-generated healing locator**

#### **Approving Healed Changes**

1. Navigate to the **Reports** section and open the relevant test execution.
2. Locate any step marked that has the "AI Assisted" tag as shown in the screenshot below
3. Click **“Update XPath”** beside the healed step.
4. The new AI-generated locator is automatically saved to the test case, and subsequent runs will use the updated version.

<figure><img src="/files/HWxfORVtKlYG2ZhUKCLr" alt=""><figcaption></figcaption></figure>

This ensures your test cases evolve automatically with your app, minimising manual maintenance.

For test-suite stability practices, see [Mobile Smoke, Regression, and Release Testing](/use-cases-and-best-practices/mobile-smoke-regression-and-release-testing).


# Continuous Integration and Deployment (CI/CD)

Enable CI/CD from test plans and integrate QApilot scripts into build pipelines so automated tests gate cloud-device releases in production.

## Continuous Integration and Deployment (CI/CD)

Integrate QApilot test plans into CI/CD so pipeline jobs can trigger configured mobile test execution. Enable CI/CD for a test plan, download the generated script, and add it to your pipeline.

Continuous Integration and Continuous Deployment (CI/CD) automates build, test, and deployment work. In QApilot, it connects an existing test plan to that automated workflow.

### Enabling CI/CD

1. You can enable CI/CD in two places at the Test Plan options menu and the creation of the [Test Plan Level](/execution-and-reliability/run-mobile-test-plans).
2. Navigate to [**Test Plan**](/execution-and-reliability/run-mobile-test-plans) in the left-side navbar. It redirects to the Test Plan Listing Screen which displays all the Test Plans along with their status, and creation date.

<figure><img src="/files/mcXQxOI0HNsFRChd0ag8" alt=""><figcaption></figcaption></figure>

2. Click on the three-dot symbol, Enable CI/CD, and click on Yes.

<figure><img src="/files/e1Q8U9dJPQpD7qdObSuE" alt=""><figcaption></figcaption></figure>

3. Shell Files (.sh) and Batch Files (.bat) involve integrating scripts to automate your build, test, and deployment processes. Shell files are for Mac iOS, while batch files are used on Android. Both can execute commands to configure and trigger CI/CD pipelines.
4. Shell Scripts (.sh) and Batch Files (.bat) play an important role in executing automated test cases, configuring environments, and integrating test suites with CI/CD pipelines. These scripts provide a way to trigger test execution manage dependencies, and automate repetitive tasks.

<figure><img src="/files/jbihizGTvntrJVrkjt41" alt=""><figcaption></figcaption></figure>

To integrate the provided shell file for Mac iOS and the bat file for Android into your CI/CD pipeline, follow these steps:

5. Download .Sh file for Linux server and .bat file for Windows Server. Here, a server refers to the CICD server of the client from where Build is generated.
   1. Download the shell file for Mac iOS and the bat file for Android as provided.
6. Provide the Files to the CI/CD Integration Team:
   1. Share the downloaded shell file and bat file with your CI/CD integration team.
7. Integration into CI/CD Pipeline:
   1. The CI/CD team will integrate these files into the CI/CD pipeline for automation testing.
8. Execute Test Cases:
   1. The CI/CD pipeline will execute the test cases contained in the integrated files whenever there is a production update.
9. Handling Failures:
   1. If there is a failure in the execution of the test cases in the integrated files, the CI/CD team will need to stop the production update and fix the issues.
10. Re-running the Files:
    1. Once the issues are fixed, the CI/CD team can rerun the integrated files to retest the test cases before proceeding with the production update.

By following these steps and integrating the provided files into your CI/CD pipeline, you can ensure that test cases are run automatically before any production updates, allowing for early detection of issues and preventing faulty updates from reaching production.


# Export Appium Code

Export a QApilot Test Plan as ready-to-run Appium test scripts.

QApilot allows you to export any Test Plan as ready-to-run Appium code

### Prerequisites

* You must have at least one Test Plan already created in QApilot.
* The Test Plan must contain test cases with recorded steps.

***

### Step 1 - Trigger the Download from the Test Plan

1. Navigate to **Test Case Management** → **Test Plans** from the navigation panel.
2. Locate the Test Plan you want to export.
3. Click the **⋯ (more options)** icon on the Test Plan card.
4. Select **Download Appium Code** from the dropdown menu.

<figure><img src="/files/s4Upy9nzb5wOWCwxznKu" alt=""><figcaption></figcaption></figure>

> **Note:** The option is highlighted in the menu alongside other actions such as Edit, Schedule Run, Activate CI/CD, Deactivate, and Delete.

***

### Step 2 - Export Status

Once triggered, QApilot queues the code generation job. To track progress:

1. Go to **Settings** (gear icon in the left sidebar).
2. Select the **Appium Code** tab from the settings navigation bar.

You will see an entry for your Test Plan with the following columns:

The **Status** field will display one of the following states:

* 🟡 **Initiated** - The export job has been queued and is being processed.
* 🟢 **Completed** - The code has been generated and is ready to download.

<figure><img src="/files/Gfu3F7XlMo5y7Mv4VeVp" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/Anb9bvuqnPzpcNDz1GPC" alt=""><figcaption></figcaption></figure>

### Step 3 - Download the Generated Appium Code

Once the status changes to **Completed**:

1. Stay on the **Settings → Appium Code** page.
2. Click the **↓ (download)** icon in the **Actions** column for your Test Plan.
3. The Appium code archive will be downloaded to your machine.

> **Tip:** If the status still shows **Initiated**, wait a few moments and refresh the page. Code generation time varies depending on the size of the Test Plan.

***

### What's Included in the Download

The downloaded zip file contains Appium test scripts corresponding to the steps recorded in your Test Plan.&#x20;

You can run these scripts using your preferred IDE or CI/CD, results will automatically be populated within QApilot Reports.

***

### Related Topics

* [Creating a Test Plan](https://docs.qapilot.io/)
* [Activating CI/CD for a Test Plan](https://docs.qapilot.io/)
* [Scheduling a Test Run](https://docs.qapilot.io/)


# Camera and File Injection with LambdaTest

Simulate camera captures and file uploads on LambdaTest by injecting uploaded media into tests for QR scans, barcodes, and documents during execution.

### **Camera & File Injection**

You can now **simulate camera and file interactions** directly during test execution on LambdaTest.\
This enables seamless testing of use cases like **QR code scanning, barcode recognition, and file uploads** without manual intervention.

* **Camera Injection:** Choose any uploaded image from the new *Upload Media* screen to simulate camera input during test runs.
* **File Injection:** Upload and manage media or document files (images, PDFs, CSVs, etc.) and attach them to test plans for automated injection.
* Uploaded files are valid for **50 days**; expired files trigger a prompt to re-upload

{% @arcade/embed url="<https://app.arcade.software/share/Sey2Czy2Yc5eRvGFo3td>" flowId="Sey2Czy2Yc5eRvGFo3td" %}

This enhancement expands QApilot’s real-device automation coverage, bringing camera-driven and file-based flows into the no-code testing loop.

## Page Objects

### **Rename and Delete Page Objects**

Page Objects can be renamed and deleted directly from the Page Objects view.

**Rename**

* Select the edit option on any Page Object from the Page Objects view.
* Update the name and save.

**Delete**

* Selecting delete opens a confirmation popup that lists all test cases and steps where the Page Object is currently in use.
* If it is referenced in multiple places, deletion is blocked and the popup displays the list of usages, allowing the user to resolve dependencies before proceeding.


# PWA Testing (via LambdaTest)

Test Progressive Web Apps in QApilot with recorder, crawler, cross-browser execution, and reporting across Android and iOS devices and browsers.

## **Progressive Web App (PWA) Testing in QApilot**

QApilot now supports automated testing for **Progressive Web Apps (PWAs)**, enabling teams to validate web-based mobile experiences with the same intelligence and automation capabilities used for native apps. With PWA support, you can record, execute, and analyze tests for browser-delivered applications that behave like installable mobile apps.

***

### **Overview**

PWAs combine the reach of the web with the usability of mobile apps. QApilot brings autonomous and script-less testing to PWAs by allowing users to:

* Launch PWAs directly on real mobile devices
* Record test flows through the built-in recorder
* Run tests across Android and iOS browsers
* Validate UI elements, navigation flows, and functional behavior
* Execute tests in parallel across multiple devices
* Capture screenshots, logs, and visual states just like a native app run

This ensures seamless end-to-end testing for PWA workflows such as onboarding, authentication, browsing, search, forms, and checkout.

***

### **Key Capabilities**

#### **1. Record & Playback for PWAs**

Record user interactions on a mobile browser exactly as you would for a native app. QApilot captures taps, inputs, scrolls, validations, and dynamic elements.

#### **2. Autonomous Crawler Support**

QApilot’s crawler can explore PWA screens, generate actionable test paths, and map the app structure — helping teams discover flows and achieve meaningful coverage.

#### **3. Element Interaction & Validation**

Perform all standard actions:

* Tap / click
* Enter text
* Clear text
* Wait for element
* Visual validations
* Image or text assertions

#### **4. Cross-Browser, Cross-Device Execution**

Run the same test across:

* Android Chrome
* iOS Safari
* Multiple device sizes and OS combinations

This makes PWA regression testing scalable and consistent.

#### **5. Detailed Execution Reports**

Every PWA test run includes:

* Step-by-step logs
* Screenshots
* Recorder vs Execution comparisons
* Visual validations
* Deep-link or URL-based navigation tracking

***

### **How to Use PWA Testing in QApilot**

#### **Step 1: Add a PWA Test Source**

When creating a project or test plan:

* Select **PWA / Browser App** as the application type
* Provide the PWA’s URL

#### **Step 2: Record Your Test**

Launch the PWA on a real device and record interactions just like a native mobile app.

#### **Step 3: Configure Execution**

Choose:

* Browsers (Chrome / Safari)
* Devices
* Parallel execution settings

#### **Step 4: View Results**

Analyze results through QApilot’s execution reports and video splits.

***

### **Use Cases**

* Testing authentication flows in PWAs
* Validating dynamic forms and in-browser transactions
* Verifying offline or low-network behaviours
* Ensuring consistent UI across mobile browser environments
* Testing PWA deep links or URL-based navigation

***

### **Benefits**

* No additional setup or browser drivers required
* Same workflow for native apps and PWAs
* Increased test coverage for modern mobile web experiences
* Faster feedback with autonomous navigation and AI-driven stability


# Deep Links

Create and execute deep link suites for authentication, app downloads, and PWAs, then validate navigation with linked reports and login flows.

Deep links can be used to speed up navigation by directly accessing specific app screens, bypassing complex flows. Deep Links Tester allows users to validate deep links within their applications, ensuring that promotional or navigational links direct users to the correct pages. Three Types of Deep Links for **QApilot** are:

### Authentication Deeplinks:

Authentication deep links are used to navigate directly to authentication-related screens or processes within an application. They are especially useful in testing login flows, multi-factor authentication (MFA), and session management.

#### Use Cases in Testing:

1. Directly opening the login page or a specific OAuth provider (e.g., Google, Facebook).
2. Bypassing navigation steps to validate MFA functionality (e.g., OTP input screens).
3. Testing session timeouts or reauthentication flows.

### Download App Push Deeplinks

These deep links redirect users to download or install an app from a store (e.g., Google Play Store, Apple App Store) or a specific location. They are useful for apps that promote installations or updates via links in web pages, emails, or other apps.

#### Use Cases in Testing:

* Verifying the redirection to the correct app store page.
* Ensuring the deep link handles the "app already installed" scenario properly.
* Testing conditional flows where the app opens if installed or redirects to the store if not.

### Link Browser Portal PWA Deeplinks

These are links that open specific pages within a browser portal or Progressive Web App (PWA). They bridge the functionality of web and mobile apps, enabling access to a specific part of the app through a browser.

#### Use Cases in Testing:

* Navigating directly to a feature or section within a PWA (e.g., a product page or user dashboard).
* Validating behavior in offline mode (PWAs often provide offline capabilities).
* Ensuring links function across devices and browsers.

***

## Prerequisites

1. Ensure that you have test case scenarios to select from the dropdown.
2. You must have Deeplink URLs and elements to find them.
3. You should know how to [Execute the Test Plan](/execution-and-reliability/run-mobile-test-plans)

***

## Listing Deep links

On the Test Deep links List page, you will have the below options:

1. Navigate to **Deep links** in the left-side navbar.
2. You can easily manage Deep Links on the **Deep Links** list page by **filtering**, or **searching**. The page displays deep links with **titles**, **creation dates**, and **statuses**.
3. Click **Add Deep Links**

<figure><img src="/files/OpQL3ii5OO7CgWtICC8e" alt=""><figcaption></figcaption></figure>

***

## Creating Deep Links

1. Click the Add to add a new/Create Deeplink on the Deeplink Homepage.
2. It redirects to the below Create Deeplink window

<figure><img src="/files/H2L7vptAqa6DO49bYkco" alt=""><figcaption></figcaption></figure>

3. Enter Title
4. Enter your App Name
5. Select OS refers to choosing the operating system (OS) that a particular application or test environment will run on, such as Android or iOS.
6. A login scenario refers to a category or filter applied to group test cases specifically related to login functionality. This helps streamline test case management, enabling testers to focus on specific features or scenarios.
7. To test a deep link that requires user login in the application, you can follow a structured approach in QApilot. The goal is to verify that the deep link works correctly only after the user is authenticated and ensures redirection to the correct page or functionality.
8. Similarly, select Logout Scenario and Logout Test case from the dropdown.
9. Download a sample Deeplink Excel file and fill in the details to import that includes deep link URL and element text/XPath. Users can upload a sheet containing all the deep links they need to test. This sheet should include the link, the expected destination page, and a unique element identifier for validation.
   1. A Deeplink URL is a specific type of hyperlink that takes a user directly to a specific page or location within a mobile application, rather than just opening the app. Deeplinks enhance the user experience by allowing users to access content more quickly, bypassing unnecessary navigation steps.
   2. XPATH helps to identify and interact with elements like buttons, links, input fields, etc., based on their location.
10. Click on the Create button and the new Deeplink will be created successfully.

<figure><img src="/files/hxhUAXij7QwW7hedVP7b" alt=""><figcaption></figcaption></figure>

11. When [executed](/execution-and-reliability/run-mobile-test-plans), a deep link can open the app to a specific screen or state, bypassing the app's normal navigation flow. This makes testing deep links crucial in ensuring that users are taken to the correct location within the app when they click these links.

***

## Deep Links Execution

1. Navigate to Test Plans on the left side nav bar, and create a Test Plan for Test Execution as shown below:

<figure><img src="/files/B4DRORBD7IlxNy1Y7aui" alt=""><figcaption></figcaption></figure>

2. Select Source From Deeplink that you have already created and Import Deeplinks from the available deep links dropdown.

<figure><img src="/files/q26WHQuXpDJ7ZskkYF8L" alt=""><figcaption></figcaption></figure>

3. After clicking Import, Device Setup

<figure><img src="/files/kxXWemgo7byLFUwjeb1w" alt=""><figcaption></figcaption></figure>

3. Next, Execution Settings will apply any advanced settings from this execution.

<figure><img src="/files/MCj7pr1FX0STnzk4c2rD" alt=""><figcaption></figcaption></figure>

4. Enabling the App Installation Flow will apply check authentication on every case or check authentication on only failed cases.

<figure><img src="/files/qYQLVAttwNmyTlry3RWy" alt=""><figcaption></figcaption></figure>

5. click on Save to Execute Deep links. **QAPilot** tests each deep link by clicking the link and verifying that it navigates to the correct page. The tool checks for the presence of a unique element (e.g., a specific text field or mobile number) to confirm successful navigation.
6. If the tool identifies the unique element, the test case is marked as passed. If the element is not found, the test case fails, indicating an issue with the deep link or navigation flow. Once the executions are completed, these are acknowledged in the form of [Reports](/reports-security-and-release-readiness/mobile-test-execution-reports).
7. Click the three-dot menu to manage the changes concerning every deep link.

<figure><img src="/files/hJ8VPb9TtA8VZI89jbJp" alt=""><figcaption></figcaption></figure>

13. The users can View Details to add the elements, Edit, Disable, and Delete.

<figure><img src="/files/TDbXJ8G5tuh2eFfFVlcN" alt=""><figcaption></figcaption></figure>

14. Click on Edit to update the Deeplink data:

<figure><img src="/files/7Tokmd8ACjrDXKAkRJLf" alt=""><figcaption></figcaption></figure>

Also, read about the Deep Links Report, [here](broken://pages/bv95W0A0o2J3rfDcIYw4).


# Mobile Smoke, Regression, and Release Testing

Build reliable mobile smoke and regression coverage with QApilot using real-device execution, scheduled test plans, test artifacts, and reviewable results.

## Mobile Smoke, Regression, and Release Testing

QApilot supports repeatable mobile release validation through recorded tests, device-based execution, and detailed reports. Start with smoke coverage, then grow suites into regression coverage.

### Define the coverage

**Smoke tests** check critical paths after a build becomes available. Keep them short and focused on release-blocking journeys.

**Regression tests** check previously working behavior after changes. Organize related test cases into suites and run them through a test plan.

**Release validation** uses those results to assess the tested build. QApilot provides evidence, but teams remain responsible for release decisions.

### Build a reliable suite

1. [Record mobile test steps](/test-creation/record-mobile-test-steps) or author test cases for critical user journeys.
2. Group related cases into a [test suite](/test-creation/test-suite).
3. Create a [test plan](/execution-and-reliability/run-mobile-test-plans) with the app source, device, and test data.
4. Run on local or supported cloud devices.
5. Review the [execution report](/reports-security-and-release-readiness/mobile-test-execution-reports) before promoting the build.

### Reduce flaky mobile tests

Flaky tests often reflect unstable timing, app state, device differences, or brittle element targeting. Use QApilot features deliberately:

* Start runs from a known app state when appropriate.
* Use waits and element-based actions for dynamic screens.
* Separate Android and iOS steps when behavior differs.
* Review healed steps and update approved locators.

[AI auto-healing](/execution-and-reliability/ai-auto-healing-for-mobile-tests) can recover selected locator failures. It does not validate product correctness. Review the evidence and approve changes deliberately.

### Use real devices and evidence

Cloud recording and execution support Android APK and iOS IPA builds through configured device providers. Test plans can select devices and run multiple devices concurrently where available.

Enable screenshots or video when you need diagnostic evidence. Use reports to inspect outcomes, artifacts, and logs. Use [Device Metrics](/reports-security-and-release-readiness/device-metrics-for-android-test-performance) for supported Android performance telemetry.

For failed local runs, use [Debugging Mobile Applications on Local Devices](/mobile-testing/debugging-mobile-applications-on-local-devices) to inspect steps and resolve issues.

### Schedule regression coverage

Use [scheduled test plans](/execution-and-reliability/schedule-test-plans) for recurring coverage. Use [CI/CD](/execution-and-reliability/continuous-integration-and-deployment-ci-cd) when builds should trigger configured cloud test plans.

### Related documentation

* [Android and iOS Mobile Testing Quickstart](/getting-started/android-and-ios-mobile-testing-quickstart)
* [Cross-Platform Execution for Android and iOS](/mobile-testing/cross-platform-execution-for-android-and-ios)
* [Reports Dashboard](/reports-security-and-release-readiness/mobile-test-execution-reports/reports-dashboard)


# Mobile Test Execution Reports

Review QApilot mobile test results, failures, screenshots, videos, logs, reruns, sharing, and Jira issues from execution reports.

## Mobile Test Execution Reports

QApilot reports help teams investigate completed test runs with outcomes, step details, screenshots, videos, logs, test data, and artifacts. Use a report to diagnose a failure, share evidence, rerun coverage, or create a Jira issue.

A report is the record of a test plan run. It separates run-level summaries from test case and step-level evidence.

***

## Prerequisites

* You should know how to create a [test case](/test-creation/create-and-manage-mobile-test-cases), [test suite](/test-creation/test-suite), and [test plan](/execution-and-reliability/run-mobile-test-plans).

***

## Possible Actions on the Reports Page

1. Navigate to **Reports on the left side navbar** and click on the reports.
2. The following are the actions possible on the **Reports** page:
   1. **Search**: To search for a run result by name, use this. The search will filter all the run results names that contain your search query.
   2. **Sort by:** Click on the **Sort by** button to sort the list of Run Results according to your preference. You can sort the list based on the **Title**, **Created Date**, **Updated Date**, **Last Run**, **Ascending** or **Descending**.
   3. **Filter:** Click on **Show Filters** to add filters and sort results according to your preference. You can add filters based on the options **Created By**, **Last Run Date**, **Created Date**, **Updated Date**, **Last Run Date**, and **Labels**.

<figure><img src="/files/Gn1rHHGGZbNSf7SVSLbQ" alt=""><figcaption></figcaption></figure>

***

## QApilot Reports Dashboard Overview

1. Navigate to view details on any specific reports. **QApilot** Reports Dashboard is the control panel that provides a comprehensive overview and detailed analysis of all executed test cases.\ <br>

   <figure><img src="/files/Mn0oueWIbutqCZPA1P5y" alt=""><figcaption></figcaption></figure>
2. **Summary Overview:** The dashboard offers a high-level summary of all test cases run to date, displaying:
   1. **Total Test Cases:** Overall count of test cases executed.
   2. **Successful Test Cases:** Number of test cases that passed all steps.
   3. **Failed Test Cases:** Number of test cases with one or more failed steps.
   4. **Executed Steps:** Total number of steps executed across all test cases.
   5. **Failed Steps:** Total number of steps that encountered errors.
3. **Visual Summary:** A pictorial summary is provided to give users a quick overview:
   1. **Failed Test Cases Summary:** Displays details of the failed test cases, highlighting specific steps that failed (e.g., element ID not found).
   2. **Failure Reasons:** A chart representing the reasons for failures, such as elements not found, comparison failures, etc.
   3. **Severity Chart:** Indicates the severity of failed steps.
   4. **Keyword Failures:** Shows which keywords caused test cases to fail (e.g., compare text, click element).
   5. **Module Failures:** A bar chart representing the number of failures per module, making it easy to identify problematic areas.
4. **Accessing Detailed Reports:**
   1. Tap on the "Test Cases" option to view all recorded and executed test cases.
   2. Click on any test case to reveal all the steps involved and their execution details (passed, failed, etc.).
5. **Test Step Details:** Each test step provides a detailed view, including:
   1. **Screenshot:** Visual representation of the app screen at the time of execution.
   2. **Keyword:** The action performed (e.g., click element, set value).
   3. **Coordinates:** Location on the screen where the action was performed.
   4. **Element ID:** Unique identifier of the element interacted with.

***

## Report Details

**Test Cases**

<figure><img src="/files/aPFCeyXygnjl5LL6PPv2" alt=""><figcaption></figcaption></figure>

Here in the test cases section in the report, you will find detailed logs against each test case in that execution report complete with the screenshots for each step of the respective test case.

In addition to this, you will also find detailed artifacts (screenshots) of the execution, video, test data, debug logs, crash logs, and video splits in the following sections in execution reports as shown in the attached screenshots below.

<figure><img src="/files/dzRTLE9zEmC15m9GasAW" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/DvmNjuYA5hcFUd7sVBQO" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/60N6vvtMXoiQap01tF7o" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/2iwS1XmnCnSGgHbUWD8L" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/0dBYQETEB6rIPiD9cUdp" alt=""><figcaption></figcaption></figure>

## How to share the reports with other users?

1. On the Reports Home page, under the Actions field select the Envelop icon to configure the mail ID of the user.

<figure><img src="/files/LXeZ3u2Hq7OIXByPqfte" alt=""><figcaption></figcaption></figure>

2. A dialog box will appear to enter the email along with the configurations to be applied:
   1. Show Images
   2. Show Test Case Counts
   3. Show Crash Logs

<figure><img src="/files/6aErWeCOuucXFe0gaf1Y" alt=""><figcaption></figcaption></figure>

3. Click the **Send** button. The report will be mailed to the respective mail id.
4. It allows to sending of multiple reports to multiple emails.

<figure><img src="/files/xpkETd5ZTtCviTecqHgk" alt=""><figcaption></figcaption></figure>

5. Enter the Report Title as the multiple reports are grouped into the specific report.
6. Enter the respective email id’s to send the report.

You can send up to 5 email IDs at once and email IDs should be comma separated.

<figure><img src="/files/2C8GYOM8XhIN0sKd5ue6" alt=""><figcaption></figcaption></figure>

***

## How To Download a Report?

1. On the Reports Home page, under the Actions field select the Download icon to configure the mail ID of the user.

<figure><img src="/files/Li2iAVEkLpAGXilcq2tx" alt=""><figcaption></figcaption></figure>

2. The downloaded reports are shown on the browser in the PDF format.

<figure><img src="/files/kWZCgRACFsXmJcbqnKUr" alt=""><figcaption></figcaption></figure>

3. Click the Open file link to view the report.

***

## How To Raise an Issue?

1. Click on View detail on any respective report.

<figure><img src="/files/QF0gocVnU0JLk233Nzw3" alt=""><figcaption></figcaption></figure>

2. It redirects to the below screen. Click on the Raise issue icon

<figure><img src="/files/F2o7N75K77PJsOkXD9zA" alt=""><figcaption></figcaption></figure>

3. While viewing the detailed test steps, locate the options to raise an issue.
4. Click on "Raise Issue" if the tester believes the issue is from the app team. Describe the issue and submit it.

<figure><img src="/files/RWhyKcHplzxzdJsYKMox" alt=""><figcaption></figcaption></figure>

5. The issue is directly raised in Jira and assigned to the relevant developer.

***

## Steps to Rerun from Reports

1. Click on View detail on any respective report.

<figure><img src="/files/tyOsON57WYWRtj95Yt26" alt=""><figcaption></figcaption></figure>

2. It redirects to the below screen. Click on the Re-Run icon in the top right corner.

<figure><img src="/files/fmqSia5w8FGJW2ZTYLDE" alt=""><figcaption></figcaption></figure>

3. On the **Re-run** prompt, you will see the following popup:

<figure><img src="/files/NFOi8ChwDmqut65ub1mn" alt=""><figcaption></figcaption></figure>

4. Choose the option and click on **Start execution** to rerun.

<figure><img src="/files/3k6HwEIUMkY8OBhoKZ0e" alt=""><figcaption></figcaption></figure>

5. Once the executions are completed, these are acknowledged in the form of Reports.


# Reports Dashboard

View report summaries, failure charts, test counts, and step details from QApilot’s dashboard for executed test cases and runs in one place.

* Navigate to view details on any specific reports. **QApilot** Reports Dashboard is the control panel that provides a comprehensive overview and detailed analysis of all executed test cases.

<figure><img src="/files/Ue9Dw2f5B4Yk1pFEvHIt" alt=""><figcaption></figcaption></figure>

* **Summary Overview:** The dashboard offers a high-level summary of all test cases run to date, displaying:
  1. **Total Test Cases:** Overall count of test cases executed.
  2. **Successful Test Cases:** Number of test cases that passed all steps.
  3. **Failed Test Cases:** Number of test cases with one or more failed steps.
  4. **Executed Steps:** Total number of steps executed across all test cases.
  5. **Failed Steps:** Total number of steps that encountered errors.
* **Visual Summary:** A pictorial summary is provided to give users a quick overview:
  1. **Failed Test Cases Summary:** Displays details of the failed test cases, highlighting specific steps that failed (e.g., element ID not found).
  2. **Failure Reasons:** A chart representing the reasons for failures, such as elements not found, comparison failures, etc.
  3. **Severity Chart:** Indicates the severity of failed steps.
  4. **Keyword Failures:** Shows which keywords caused test cases to fail (e.g., compare text, click element).
  5. **Module Failures:** A bar chart representing the number of failures per module, making it easy to identify problematic areas.
* **Accessing Detailed Reports:**
  1. Tap on the "Test Cases" option to view all recorded and executed test cases.
  2. Click on any test case to reveal all the steps involved and their execution details (passed, failed, etc.).
* **Test Step Details:** Each test step provides a detailed view, including:
  1. **Screenshot:** Visual representation of the app screen at the time of execution.
  2. **Keyword:** The action performed (e.g., click element, set value).
  3. **Coordinates:** Location on the screen where the action was performed.
  4. **Element ID:** Unique identifier of the element interacted with.


# Test Case Details

Inspect step-by-step test execution with screenshots, logs, navigation view, and AI-assisted statuses to spot failures quickly in reports fast.

#### Overview

The Test Case section in QApilot’s Reports provides a detailed, step-by-step breakdown of how each test case was executed. It offers complete visibility into execution results, screenshots, and system logs, allowing QA teams to quickly analyse behaviour, verify outcomes, and identify failure points.

<figure><img src="/files/EIIBZVm5dNOIUrD2LwTy" alt=""><figcaption></figcaption></figure>

***

#### Key Components

**1. Step-by-Step Execution View**

Each test case expands into an execution timeline listing every test step in order of execution.\
For every step, QApilot captures:

* Start and End Timestamps
* Keyword / Action Type (e.g., Tap, Input, Scroll)
* Execution Time
* Status Indicator – *Success* ✅ or *Failure* ❌
* Context and Log Entries – element IDs, XPaths, automation name, and environment context

This ensures that every action performed during the test run is fully traceable.

**2. Screenshots: Recording vs. Execution**

For each step, QApilot displays a side-by-side visual comparison of:

* Recorded Screenshot – the screen state captured during initial recording.
* Execution Screenshot – the actual state of the app during playback.

This comparison helps visually validate whether UI changes affected test outcomes.

**3. Navigation View**

At the top of the test case, you can toggle Navigation View to see all screenshots from the test steps in a visual flow. This provides a quick, storyboard-style overview of the entire test run—ideal for reviewing app behaviour without diving into each log.

<figure><img src="/files/EdbOWO5OOxlkoMp3ILoi" alt=""><figcaption></figcaption></figure>

**4. Step-Level Logs**

Each step includes rich contextual logs such as:

* Element locators used (ID, XPath, or custom path)
* Execution context (e.g., automation name, resource ID)
* Element found/displayed status
* AI auto-healing traces (if applied)
* Click or input confirmation

These logs help pinpoint the exact cause of a success or failure, down to the element level.

**5. Step-Level Status Indicators**

Each test step is clearly marked with a status icon:

* ✅ Success – Step executed as expected.
* ⚠️ AI-Assisted – Step passed through [AI Auto-healing](/execution-and-reliability/ai-auto-healing-for-mobile-tests).
* ❌ Failure – Step failed due to missing or mismatched element.

This lets testers identify reliability trends and focus on failing or healed steps quickly.


# Execution Artifacts and Video Splits

Review QApilot execution screenshots and step-level video clips, switch views, and detect UI freezes or stalls from reports.

## **Artifacts**

The **Artifacts section** in QApilot consolidates all **execution screenshots** captured during a test run or test plan. It provides a complete visual record of the app’s behavior across every step and flow executed, making it easy to review, validate, and share results

#### **Key Highlights**

* **Comprehensive Visual Log:** Displays all screenshots captured during the execution in a chronological grid view. Each image corresponds to a specific action or state within the test journey.
* **Step Context:** Every screenshot is labeled with the corresponding **test step name or action keyword** (e.g., “Click on LOGIN / REGISTER”, “Tap on Learn More”).
* **Quick Navigation:** The **Navigation View** toggle allows you to switch between visual browsing and step-based navigation for faster context switching.
* **Cross-Verification:** Ideal for verifying UI flows, visual consistency, and navigation accuracy without opening each test case individually.

<figure><img src="/files/adyrA2pzeHnCyZ0a9tjg" alt=""><figcaption></figcaption></figure>

## Video Splits

The **Video Splits section** provides a detailed breakdown of the test execution video, divided into smaller clips for each action or sequence (e.g., “Click Element,” “Go Back”). This allows users to quickly review specific parts of the test without replaying the entire recording.

<figure><img src="/files/xpgD9ybak7nJW0JmZcYa" alt=""><figcaption></figcaption></figure>

#### **Key Features**

* **Split-Level Playback:** Each test run is automatically segmented by start and end nodes, making it easier to analyze interactions step-by-step.
* **Frame Freeze Detection:** QApilot’s AI automatically scans every video split to detect **frame freezes,** moments where the app visually stalls or becomes unresponsive.
  * Detected freezes are highlighted with their timestamps.
  * If no visual freezes are found, the report displays *“No Freezes Detected.”*
* **Visual Debugging:** Users can play back each split, inspect UI transitions, and validate responsiveness directly from the report.

This section enables quick visual diagnosis of app performance issues, helping teams identify lag, hangs, or UI stalls across test executions.


# Video Splits

Review execution videos as step-level clips, detect frame freezes automatically, and debug UI stalls without replaying full runs end-to-end.

The **Video Splits section** provides a detailed breakdown of the test execution video, divided into smaller clips for each action or sequence (e.g., “Click Element,” “Go Back”). This allows users to quickly review specific parts of the test without replaying the entire recording.

<figure><img src="/files/xpgD9ybak7nJW0JmZcYa" alt=""><figcaption></figcaption></figure>

#### **Key Features**

* **Split-Level Playback:** Each test run is automatically segmented by start and end nodes, making it easier to analyze interactions step-by-step.
* **Frame Freeze Detection:** QApilot’s AI automatically scans every video split to detect **frame freezes,** moments where the app visually stalls or becomes unresponsive.
  * Detected freezes are highlighted with their timestamps.
  * If no visual freezes are found, the report displays *“No Freezes Detected.”*
* **Visual Debugging:** Users can play back each split, inspect UI transitions, and validate responsiveness directly from the report.

This section enables quick visual diagnosis of app performance issues, helping teams identify lag, hangs, or UI stalls across test executions.


# Report Sharing, Deep Links

Share report links securely through authenticated access, then review deep link results, execution logs, and linked login or logout flows in reports.

## Report Sharing

Security report links can be shared via email and support secure, direct access through authentication.

Email reports include a link that redirects users to the login page when required and automatically returns them to the specific security report after successful authentication. If the user is already logged in, the system bypasses the login step and opens the report directly.

For users who are authenticated but do not have access to the associated project, a dedicated error screen is shown with an appropriate message. Authorised users are always redirected seamlessly to the intended report view.

This update improves usability while maintaining access control and security.

<figure><img src="/files/Y4gqdgCLwzNVVgXf3304" alt=""><figcaption></figcaption></figure>

***

## Deep Links

The **Deeplink section** in QApilot Reports displays the results of all executed deep links within a test run. It helps verify that each deep link correctly navigates to its intended screen and that associated login or logout flows execute successfully.

<figure><img src="/files/BgMMLk14Hocqox5YtpkM" alt=""><figcaption></figcaption></figure>

### **Key Components**

* **Deeplink Summary:** Shows the deep link URL, start time, total execution time, status, and a screenshot of the landing screen.
* **Execution Logs:** Lists step-by-step actions (e.g., click, find element, wait) performed during the deep link execution with timestamps and outcomes.
* **Linked Test Cases:** If the deep link triggers login or logout test cases, they are shown as separate expandable sections with their own execution logs and statuses.

This section provides a complete, traceable record of deep link validation, ensuring accurate navigation, correct page loads, and reliable authentication flows.


# Mobile App Security Reports

Run static security analysis for uploaded app versions, then inspect manifest, certificate, code, and network findings in QApilot reports.

## Mobile App Security Reports

QApilot can run static security analysis for an uploaded app version when enabled during App Source upload. Security Reports show version-specific manifest, certificate, code, and network findings inside Reports.

A security report is generated only when Security Analysis is enabled. It supplements test execution reporting and does not replace a complete security assessment.

<figure><img src="/files/CjmM4DQ0kR3DcXxE6AbY" alt=""><figcaption></figcaption></figure>

**Security Reports**

* A new **“Security Analysis”** checkbox is available in the **App Upload** flow under Settings → App Source.
* Security analysis runs only when this option is explicitly enabled, ensuring teams stay in control of when and how scans are performed.
* Uploaded app versions include a **“View Security Report”** option, allowing quick navigation to the corresponding security report for that specific version.

<figure><img src="/files/RY9yxPpVeBGeLfqGFILg" alt=""><figcaption></figcaption></figure>

When Clicked on "view report", the security report will be displayed as follows -

<figure><img src="/files/ViLch5ojCXKRBzruX4WF" alt=""><figcaption></figcaption></figure>

* A new **Security Reports** tab has been added under the **Reports** section, alongside Accessibility Reports.
* Each security report is listed with key metadata, including app title, OS, package or bundle name, version, analysis duration, and execution status.
* Reports are organized per app version, with a single security report generated for each uploaded version.
* Users can view detailed findings across multiple analysis areas, including:
  * Manifest Analysis
  * Certificate Analysis
  * Code Analysis
  * Network Security


# Configurable PII Blurring

Choose which PII types QApilot blurs in screenshots at the test plan level, protecting sensitive data in reports and artifacts during execution.

### **Configurable PII Blurring**

QApilot supports automatic blurring of sensitive information in screenshots to help teams maintain privacy and compliance during test execution and reporting.

***

### **Overview**

PII blurring can now be configured at the **Test Plan level**, allowing users to explicitly choose which types of personally identifiable information (PII) should be masked. Based on this selection, QApilot automatically detects and blurs the corresponding elements in all captured screenshots.

This ensures sensitive data is protected while preserving the rest of the visual context needed for debugging and analysis.

***

### **How It Works**

* During **Test Plan configuration**, users can select one or more PII types to be blurred.
* When the test plan is executed, QApilot scans all captured screenshots.
* Elements matching the selected PII types are automatically blurred.
* Blurring is applied only to screenshots; test execution logic remains unaffected.

***

### **Supported PII Types**

The following PII types are currently supported for automatic blurring:

* Phone numbers
* Email addresses
* Credit card numbers
* Social Security Numbers (SSN)
* Passport numbers
* Gender
* Date of birth (DOB)

***

### **Benefits**

* Protects sensitive user data in reports and shared artifacts
* Enables fine-grained control over what information is masked
* Supports compliance and internal security requirements
* No additional effort required during test execution


# Device Metrics for Android Test Performance

Monitor Android test performance with CPU, memory, battery, network, and rendering metrics in QApilot execution reports.

## Device Metrics for Android Test Performance

QApilot Device Metrics provides Android performance signals for each test execution report. When enabled, it appears as a dedicated **Device Metrics** tab alongside standard report tabs.

The tab captures hardware and runtime telemetry directly from the device during execution - CPU, memory, battery, network, and rendering performance, and surfaces it as threshold alerts, trend charts, and a step-by-step breakdown. This makes it possible to spot performance regressions, correlate spikes with specific test steps, and track app health across test plan runs without leaving the report.

> **Note:** Device Metrics is currently supported for **Android** only.

***

## Enabling Device Metrics

Device Metrics is off by default. To enable it for a test plan:

1. Open the test plan configuration
2. In the execution settings, Toggle **App Performance Analysis** to enabled before launching the run.

Once enabled, the **Device Metrics** tab appears in all subsequent execution reports for that test plan.

***

## Performance Thresholds

At the top of the Device Metrics tab, a row of metric cards summarises the peak and average readings recorded during the execution.

<figure><img src="/files/PRBbzvCcSy5NRKNhWxTK" alt=""><figcaption></figcaption></figure>

<table><thead><tr><th width="176.5546875">Metric</th><th>What It Shows</th></tr></thead><tbody><tr><td><strong>Peak System CPU</strong></td><td>Highest system-wide CPU usage observed, with the session average</td></tr><tr><td><strong>Peak Memory</strong></td><td>Highest app memory consumption (MB), with the session average</td></tr><tr><td><strong>Bottom (Battery)</strong></td><td>Battery drain recorded; shows drain percentage and scale</td></tr><tr><td><strong>Peak Network</strong></td><td>Highest network throughput observed; includes cumulative Rx and Tx values</td></tr><tr><td><strong>Peak Janky Frames</strong></td><td>Highest janky frame percentage recorded, with the total jank frame count average</td></tr></tbody></table>

These cards give you a health summary before you dive into the detailed alert and chart sections below.

### Benchmarks

Benchmarks define the thresholds that determine when an alert fires and at what severity level.

Benchmarks apply across every test plan. You can customise the default thresholds to match your app's specific performance targets.

***

## Alert Summary

The **Alert Summary** section reports the total number of threshold breaches detected across the entire execution, grouped by severity:

<table><thead><tr><th width="137.61328125">Severity</th><th width="132.734375">Colour</th><th>Meaning</th></tr></thead><tbody><tr><td><strong>Critical</strong></td><td>Red</td><td>Threshold exceeded significantly; likely to affect user experience or stability</td></tr><tr><td><strong>Warning</strong></td><td>Yellow</td><td>Threshold exceeded moderately; worth investigating</td></tr><tr><td><strong>Info</strong></td><td>Blue/Grey</td><td>Threshold reached within an acceptable range; flagged for awareness</td></tr></tbody></table>

Each breach is displayed as an expandable alert card below the summary counts.

#### Alert Cards

Every alert card includes a description of the breach, the measured value, and the threshold it violated. Example alerts include:

* **High app CPU detected** - App CPU reached or exceeded the critical threshold in a measured percentage of samples. Shows peak app CPU, average app CPU, and overage percentage.
* **Elevated system CPU detected** - System CPU was between defined warning and critical bands across a percentage of measured steps.
* **App startup time above 3s** - Application reached its fully drawn state in more than 3 seconds, indicating heavy initialisation work on the main thread or slow runtime at startup.
* **Moderate system CPU detected** - System CPU was between warning bands across a percentage of measured steps; shows highest observed and average values.
* **Moderate app CPU detected** - App CPU was between moderate thresholds across measured samples.
* **Moderate app memory usage detected -** Memory consumption reached a moderate threshold during execution.

***

## Visualize Metrics

The Visualize Metrics section renders time-series charts for each telemetry signal collected during the run. Use the tab bar to switch between signals:

<table><thead><tr><th width="156.17578125">Tab</th><th>Signal</th></tr></thead><tbody><tr><td><strong>CPU</strong></td><td>App CPU and System CPU usage over time</td></tr><tr><td><strong>Memory</strong></td><td>App memory consumption (MB) over time</td></tr><tr><td><strong>Janky Frames</strong></td><td>Janky frame percentage per interval</td></tr><tr><td><strong>Battery</strong></td><td>Battery drain over time</td></tr><tr><td><strong>Network</strong></td><td>Network download and upload throughput over time</td></tr></tbody></table>

Each chart plots the metric against the execution timeline. Hover over any data point to see the exact value and timestamp.

> **Janky Frames note:** The chart shows **Janky Frame %** (frames that missed their render deadline as a percentage of total frames), giving a more meaningful signal than raw frame counts.

<figure><img src="/files/r77mmEp3BT9QbHlTgnEY" alt=""><figcaption></figcaption></figure>

#### Correlating Signals

Signals in different tabs can be related. Some common correlations to look for:

* High network download activity often coincides with spikes in System CPU usage
* High System CPU usage can accelerate battery drain
* High FPS rendering load (janky frames) can contribute to elevated App CPU

Use the timeline as a shared axis - a spike in one chart at a given timestamp maps directly to the same point in other charts.

***

### Step Details

The **Step Details** panel on the right side of the Device Metrics tab ties the performance data back to individual test steps. As you review the charts, the panel shows a device screenshot corresponding to the selected point in the execution, so you can see exactly what was happening on screen when a metric spike or threshold breach occurred.

This makes it straightforward to identify which test step or user interaction triggered a performance issue.


# Report Comparison

Compare two matching reports by device and test plan to track regressions, differences, and result quality across builds with artifact-level analysis.

Report comparison is a critical process that helps teams assess the outcomes of test executions over different builds, environments, or versions of an application. This process not only ensures consistency and accuracy in test results but also aids in identifying regressions, validating fixes, and providing insights into overall application quality.

***

## Prerequisites

1. Ensure that you have executed one [test plan](/execution-and-reliability/run-mobile-test-plans) on multiple devices.
2. Test Plan and Device Name must match to ensure a valid comparison.

***

## How To Compare Reports?

1. Go to the reports listing and choose 2 reports with the same Device and Test Plan to compare.

> Test Plan and Device Name should be the same for the base report and target report.

<figure><img src="/files/5VCYshgSLR5JfeEUvbcY" alt=""><figcaption></figcaption></figure>

2. It redirects to the below window. Give a title for selected compare reports.

<figure><img src="/files/vPjD9QnGvcbRp7RFGwz4" alt=""><figcaption></figcaption></figure>

3. Click on the Create button and it redirects to the below window:

<figure><img src="/files/F2CEXADdqsX5pQUJwJqL" alt=""><figcaption></figcaption></figure>

4. The selected reports comparison has been created. Click on Yes to check the status and view of the comparisons.

<figure><img src="/files/nRrmRNnz4k9l0Lp2ckBA" alt=""><figcaption></figcaption></figure>

5. Click on View detail:

<figure><img src="/files/GgPHzN3khP1my9vOZVAO" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/1ztxsaO5BrKQEefMO4lQ" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/d2EXU1uOz7TwHQf76n3x" alt=""><figcaption></figcaption></figure>

6. When generating and comparing reports, a well-structured workflow is essential for ensuring that the process is efficient and the results are meaningful. As shown above is a detailed workflow that outlines the steps involved in report generation, artifact comparison, and analysis of results, including the use of percentage matching and color coding to represent outcomes.


# Build vs Buy Mobile Test Automation

Use a practical framework to decide whether to build and operate a mobile test automation stack or adopt a testing platform.

## Build vs Buy Mobile Test Automation

Build mobile test automation when your team needs full control over its tooling and operations. Buy a platform when faster adoption, managed workflows, and integrated evidence matter more than owning every layer.

This decision is not about one approach being universally better. It depends on your application, team skills, delivery cadence, and operating capacity.

### Define the two approaches

**Build** means selecting, integrating, and operating your own test automation stack. Your team owns the test framework, device access, execution infrastructure, reporting, and maintenance processes.

**Buy** means adopting a testing platform that provides defined workflows and product capabilities. QApilot provides documented workflows for recording, test organization, local or cloud execution, reporting, and selected AI-assisted capabilities.

### Evaluate the operating model

Consider building when you need to:

* Customize the testing stack beyond supported platform workflows.
* Own infrastructure and integration design internally.
* Invest engineering time in test framework and device operations.

Consider buying when you need to:

* Help testers create reusable coverage through [recorded mobile test steps](/test-creation/record-mobile-test-steps).
* Run configured coverage through [mobile test plans](/execution-and-reliability/run-mobile-test-plans) on local or supported cloud devices.
* Review execution evidence through [mobile test execution reports](/reports-security-and-release-readiness/mobile-test-execution-reports).

### Compare the trade-offs

#### Team skills and ownership

A built stack requires people who can design, maintain, and troubleshoot its framework and operations. A platform reduces work across documented workflows, but teams still design test coverage and review results.

#### Test creation and maintenance

A built stack can support any authoring model the team implements. QApilot supports recorded steps, Android crawler-based exploration, and CoWork for documented human-in-the-loop Android authoring.

Review [AI-Native and Agentic Mobile Testing](/ai-and-core-concepts/ai-native-and-agentic-mobile-testing) for the current scope and limitations of these workflows.

#### Execution and evidence

Building requires the team to connect test runs, devices, and diagnostics. QApilot documents local and cloud recording and execution, configurable test plans, and reports with execution artifacts.

For recurring delivery checks, connect [scheduled test plans](/execution-and-reliability/schedule-test-plans) or [CI/CD](/execution-and-reliability/continuous-integration-and-deployment-ci-cd) to your release workflow.

### Questions to answer before deciding

1. Which team will own test infrastructure and failure investigation?
2. Do you need a custom framework, or documented platform workflows?
3. How quickly must teams create coverage and review release evidence?

### QApilot considerations

QApilot supports Android and iOS mobile testing workflows. Some capabilities have narrower documented scope. For example, the crawler supports Android, while CoWork currently supports Android with LambdaTest.

Validate those constraints against your coverage needs before adopting any workflow. See [How QApilot Works](/ai-and-core-concepts/how-qapilot-works) for the end-to-end model.

### Related documentation

* [Mobile Smoke, Regression, and Release Testing](/use-cases-and-best-practices/mobile-smoke-regression-and-release-testing)
* [Cloud Device Recording and Execution](/getting-started/set-up-qapilot/cloud-device-recording-and-execution)
* [AI Auto-Healing for Mobile Tests](/execution-and-reliability/ai-auto-healing-for-mobile-tests)


# Manage QApilot Users

Manage QApilot workspace users, review account status, search or filter members, and create, edit, or disable access.

## Manage QApilot Users

Use **User Management** to review workspace accounts and manage access. Administrators can search, filter, create, edit, or disable users from the user list.

### Open the user list

#### Navigation panel

* The sidebar on the left provides access to different modules. The highlighted orange icon (person silhouette) indicates you are in the **User Management** module.
* Under this, the **"List"** option is selected.

<figure><img src="/files/8WbxrU6RewuyRRRVGrZA" alt=""><figcaption></figcaption></figure>

2. When you click on "**List**", it will redirect you to the screen below.

<figure><img src="/files/ELYVSaoOn2DwgE57L8FJ" alt=""><figcaption></figcaption></figure>

3. At the top of the screen, you can see a summary of user statuses:
   * **Active:** 85 users are currently active and can use the platform.
   * **Inactive:** 3 users who are not currently using the system.
   * **Suspended:** 23 users whose access has been disabled.
   * **Invited:** 7 users have been invited but have not yet accepted/joined.
4. **User List Table**

   The main section contains a table listing detailed user data. Each row corresponds to one user with the following columns:

   | Column       | Description                                                                                |
   | ------------ | ------------------------------------------------------------------------------------------ |
   | **Login ID** | The email or ID used to log into the system.                                               |
   | **Name**     | Full name or username of the user.                                                         |
   | **Email**    | Email address of the user.                                                                 |
   | **Created**  | Date and time the account was created.                                                     |
   | **Status**   | Current status of the user (Active, Suspended, Invited, etc.).                             |
   | **Actions**  | A button (three dots) likely gives access to more actions like edit, suspend, delete, etc. |
5. **Status Indicators:** Color-coded tags make it easy to identify user statuses:

* **Green ("Active")** – User can access the platform.
* **Red ("Suspended")** – User access has been blocked.
* **Orange/Yellow ("Invited")** – User has been invited but hasn't activated the account.

#### 6. **Actions:**

* **Search users** using the "Quick search" bar.
* **Filter users** using the filter icon next to the search bar.
* **Add new users** using the orange "+" button in the top right corner.
* **Update Users:** Use the **"Edit"** option from the **actions menu** corresponding to the user you want to update.
* **Disable Users:** Use the **"Disable"** option from the **actions menu (⋮)** next to the specific user to suspend or deactivate their account.


# Manage Your QApilot Account

Update your QApilot profile, profile picture, contact details, and password from Account Settings.

## Manage Your QApilot Account

Use **Account Settings** to update your profile details, profile picture, and password. Account Settings also shows your username, email address, mobile number, and last login details.

### Open Account Settings

1. The bottom-left corner of the **Dashboard** displays your username.

<figure><img src="/files/X0q3MXLTZeEqfEHntfJZ" alt=""><figcaption></figcaption></figure>

2. Click on the Account Settings below the **Username**.

<figure><img src="/files/u04H7Ix52x1wJJAKAGnt" alt=""><figcaption></figcaption></figure>

3. The menu shows **Account Settings** and **Logout**, plus your username and email address.
4. Select the **Account Settings** option.

**Account Settings** lets you update profile information. It displays your username, email address, and mobile number.

5. The below screen with **User Profile** information is shown below.

<figure><img src="/files/bohjILYzkIFZ5grnDPEW" alt=""><figcaption></figcaption></figure>

Manage Account deals with updates to the User Profile information. It displays **Username**, **Email id**, **Last Login** details, and **Mobile number** details.

This section facilitates the upload of a required **Profile** picture of the user.

The new **Password** update is also changed in this section as shown above. For security reasons, if the User/Admin wishes to create a new password the **Change Password** feature will be helpful.

## Updating the Profile Picture and Other details

1. On the **Manage Account** page, click the **Upload** icon to update the profile picture against the **Username** as shown below.

<figure><img src="/files/Sy5td5DLSJAxutU0ZlJm" alt=""><figcaption></figcaption></figure>

2. The Admin/User is redirected to the **Open** dialog box to pick the picture.
3. Click **Open**. The new **Profile Picture** has been uploaded as shown below.
4. An **Edit** icon is also shown beside the newly uploaded picture. The user can change the **Profile** picture as per the requirement.
5. The updated picture is shown on the **Dashboard** page also.

## Update the Profile Information?

1. On the Manage Account page, the User Profile basic information is updateable.

<figure><img src="/files/EeVrm0JyslF7EKLOtKPo" alt=""><figcaption></figcaption></figure>

2. In the **Profile Information** section, the **Username** and **Mobile Number** are editable.
3. As per the requirement, modify these fields.
4. Click the **Update** button to make the changes effective.

<figure><img src="/files/aQFNavTjdOnRRG0A5yyR" alt=""><figcaption></figcaption></figure>

5. The display of the above message confirms the update of details.

## Change the Password

1. The user can provide a **New Password** in the respective field under the **Password Information** section as shown below.

<figure><img src="/files/HGFa5rixToNMIthwPua7" alt=""><figcaption></figcaption></figure>

2. The system will prompt you to re-enter the password to confirm it.
3. Click the **Update** button\*\*.\*\* The change of password is confirmed by the below message.

<figure><img src="/files/m2PQLvQ2UDKx0jMhmbDz" alt=""><figcaption></figcaption></figure>

4. Click the **Logout** button to exit from the interface.


# QApilot FAQs

Find quick answers about supported mobile testing, failed test investigation, reports, security analysis, support, trials, and rule errors.

## QApilot FAQs

These answers cover common QApilot testing and troubleshooting questions. Follow the linked guides for complete workflow details.

### What mobile apps can I test?

QApilot documents Android and iOS mobile testing workflows for native and hybrid apps. Flutter apps use a Flutter Driver recording option when applicable.

See [Android and iOS Mobile Testing Quickstart](/getting-started/android-and-ios-mobile-testing-quickstart) and [Flutter App Testing](/mobile-testing/flutter-app-testing).

### What should I do when a test fails?

Open the execution report to inspect failed steps, screenshots, videos, logs, and artifacts. For local runs, use step-by-step debugging to investigate the device state.

See [Mobile Test Execution Reports](/reports-security-and-release-readiness/mobile-test-execution-reports) and [Debugging Mobile Applications on Local Devices](/mobile-testing/debugging-mobile-applications-on-local-devices).

### How can I review mobile app security findings?

Enable **Security Analysis** when uploading an app source. QApilot then provides version-specific static analysis findings for manifest, certificate, code, and network areas.

See [Mobile App Security Reports](/reports-security-and-release-readiness/mobile-test-execution-reports/mobile-app-security-reports). For questions about account or data security, contact QApilot support.

### How can I access test results and reports?

Open **Reports** from the navigation to review and share execution evidence. Reports can include test outcomes, step details, and configured artifacts.

See [Mobile Test Execution Reports](/reports-security-and-release-readiness/mobile-test-execution-reports).

### What support options are available?

A chat support section is available. If you need help, reach out through the [QApilot website](https://qapilot.io/).

***

### Can I try QApilot before committing to a subscription?

Yes, you can try the tool before committing to a subscription; Please reach out to our support team to discuss trial options.

***

### Why do I get an “Unable to process your request” error when creating a rule?

You may encounter the error message: "**Unable to process your request now. Please try again later**" while trying to create a condition or rule in the application.

<figure><img src="/files/AoSCPV0HZreiLYJGYjw0" alt=""><figcaption></figcaption></figure>

#### Possible cause

This error can occur if multiple tabs of the same session are opened in your browser. The system may fail to create a rule due to session conflicts between the tabs.

#### Solution

* Close any duplicate tabs of the same application session.
* After closing, refresh the remaining tab and try creating the rule or condition again.

By ensuring that only one tab of the session is active, you should be able to proceed with creating the rule successfully.


# Integrations

Configure project-level QApilot settings and integrations so each app project can connect devices and support cloud testing workflows reliably.

QApilot integrates with various tools from your software delivery cycle to make continuous testing easier. Integrations enhance testing by connecting tools, systems and streamlining processes

QApilot has built-in integrations with the following tools:

## Collaboration Tools&#x20;

Integrating collaboration tools allows real-time test results, bug reports, and notifications to be shared across teams, improving communication and decision-making. This is especially helpful for distributed or remote teams.

* **Key Tools**: [Slack](/integrations/slack), [Microsoft Teams](/integrations/microsoft-teams)
* **Benefits**:
  * Instant notifications of test failures or issues.
  * Improves communication and collaboration across development, QA, and DevOps teams.
  * Ensures timely action on critical issues, reducing delays in the development cycle.

## Bug Reporting

Integration with bug tracking tools allows for the automatic logging of defects found during automated testing. When tests fail, they can create tickets with relevant data (logs, screenshots, steps to reproduce), reducing manual effort in reporting issues.

* **Key Tool**: [Jira](/integrations/jira)
* **Benefits**:
  * Automates the process of creating tickets when tests fail.
  * Ensures detailed information (test logs, screenshots) is attached to tickets for better issue tracking and resolution.
  * Enhances collaboration between testing and development teams for faster bug fixes.

## Device Farms

Cloud testing platforms like Sauce Labs, and BrowserStack offer integrations with automation testing tools to run tests across a wide range of real devices and browsers. These platforms provide scalability and infrastructure to run tests without needing physical hardware.

* **Key Tools**: [Sauce Labs](/integrations/sauce-labs-cloud-device-integration), [BrowserStack](/integrations/browserstack-cloud-device-integration)
* **Benefits**:
  * Enables cross-browser and cross-device testing in parallel, improving test coverage.
  * Reduces the need to maintain local device farms or browser labs.
  * Provides access to a variety of environments, ensuring tests are run on real-world configurations.

## Continuous Integration/Continuous deployment

[Integrate automation testing tools](/execution-and-reliability/continuous-integration-and-deployment-ci-cd) with CI/CD pipelines for tests to run automatically in the software build and deployment process. This allows developers to get immediate feedback on their code changes and catch issues early.


# Slack

Send real-time pass, fail, and abort notifications to a Slack channel for shared test visibility.

## Pre-requisites

Slack Incoming Webhook URL. For more information, refer to [Incoming Webhooks](https://api.slack.com/messaging/webhooks).

### Steps to Integrate Slack with QApilot

1. Navigate to Settings > Integrations and enable the toggle on the Slack widget.

<figure><img src="/files/3H8n616j4JHmHm4VkTnf" alt=""><figcaption></figcaption></figure>

2. Connect to Slack to get notifications for your run instantly. Click on Add Integration to create a new account for Slack.

<figure><img src="/files/WzYCOD6bCpEkIE7wOKHr" alt=""><figcaption></figcaption></figure>

3. Enter all the details to Create a Slack integration Type.

<figure><img src="/files/5Qw1KRMFIf7kFBWZ8Pdl" alt=""><figcaption></figcaption></figure>

4. A Slack Webhook URL is a unique URL generated by Slack that allows external applications to send messages to a specific Slack channel without needing full API integration. This URL acts as an endpoint for sending data to Slack, making it a simple way to post notifications, updates, or alerts from other systems directly into Slack.

***

### Enabling Slack Notifications in the Test Plan

1. After adding the account. when you click on enable Slack. The below popup window will appear:

<figure><img src="/files/UoX8EODc6hzabpJhqS3y" alt=""><figcaption></figcaption></figure>

2. Click on the Yes button and it redirects to the below popup:

<figure><img src="/files/HXGk0mXbywJdihin7QNP" alt=""><figcaption></figcaption></figure>

3. Please map with existing Slack to your project. Enable the option to send notifications on execution issues TestCase, Step, and Test Plan. Click on the Save button.


# Microsoft Teams

Integrate Microsoft Teams with QApilot using webhooks, then send test plan, case, and step notifications to mapped channels during execution.

## Prerequisites

* Teams Incoming Webhook URL for **QApilot**. For more information, refer to [Create an incoming MS Team webhook](https://docs.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook).

## Steps to Integrate Microsoft Teams with QApilot

1. Navigate to Settings > Integrations. Enable toggle on MS Teams widget.

<figure><img src="/files/cMhtAhiEfKgDqv4hr0M8" alt=""><figcaption></figcaption></figure>

2. Connect to Microsoft Teams to manage all your team communications instantly.

<figure><img src="/files/olM2zDChCHAor3Rb4gDQ" alt=""><figcaption></figcaption></figure>

3. Enter all the details to Create a Teams integration Type.

<figure><img src="/files/Sxa4CMGpsh9jGEftj1VD" alt=""><figcaption></figcaption></figure>

4. A Teams Webhook URL is a unique URL provided by Microsoft Teams to allow external applications and services to send messages directly to a specific Teams channel. This enables seamless integration between Teams and other systems, allowing real-time notifications, updates, or alerts to be posted automatically in a Teams channel without the need for full API integration.

***

## Enabling MS Teams Notifications in the Test Plan

1. Once the MS Teams integration is added, you can enable the MS Teams notifications for your test plans.

<figure><img src="/files/vrlgRZIeO7Dmlcplt0J7" alt=""><figcaption></figcaption></figure>

2. Please map existing teams to your project. Enter Assignee. Enable the option to send notifications on execution issues TestCase, Step, and Test Plan. Click on the Save button.


# Jira

Connect Jira to QApilot, configure account credentials, and create bug reports with screenshots and annotations directly from test execution workflows.

You can integrate QApilot with Jira to push bugs directly into Jira's project. In this document, we will discuss how to integrate the tool and create the first bug from QApilot that'll flow into Jira.

## Prerequisites

To integrate Jira with **QApilot**, you need the following:

* **Account URL**: Your Jira Account URL
* **Username**: Your account username/email
* **API Key**: API Token from Jira

***

## Integrating Jira with QApilot

1. Navigate to Settings > Integrations. Enable toggle on the Jira widget.

<figure><img src="/files/9ZChgwDBqqpCrq3Ruev0" alt=""><figcaption></figcaption></figure>

2. On the Jira Details prompt, enter the Integration URL, User Name, and API Key and click on Create.

<figure><img src="/files/fGztNTo1EfX5rZKxs2Cc" alt=""><figcaption></figcaption></figure>

3. Enter all the details to Create a Jira integration Type. Click on the Create button.

***

## Enabling Jira in the Test Plan

1. Once the Jira integration is added, you can enable the Jira notifications for your test plans.

<figure><img src="/files/A297k3M2Wu8cUmhlNlON" alt=""><figcaption></figcaption></figure>

2. Please map with existing Jira project to your project. Enter Assignee. Enable the option to send notifications on execution issues TestCase, Step, and Test Plan. Click on the Save button.


# BrowserStack Cloud Device Integration

Connect BrowserStack to QApilot with account credentials, then use BrowserStack cloud devices for mobile test execution.

## BrowserStack Cloud Device Integration

QApilot connects to BrowserStack so teams can record and run mobile tests on BrowserStack cloud devices. Configure account credentials once, then select BrowserStack for a cloud device connection.

BrowserStack is a cloud device provider. QApilot uses the integration credentials to establish cloud device sessions.

## Prerequisites

Before connecting QApilot with Browserstack. You need the Integration URL, Username, and Access Key for BrowserStack which can be obtained from your BrowserStack account dashboard.

* BrowserStack: Integration URL, Username, and Access Key from BrowserStack.

This can be obtained from the Account Settings page under Automate as shown below:

<figure><img src="/files/V0xZwjSiKW33F6aTwmnM" alt=""><figcaption></figcaption></figure>

***

## Integrating with BrowserStack

1. Navigate to **Settings** → **Integrations**. Enable the toggle on the BrowserStack widget.

<figure><img src="/files/igqI8uhqKJ2IfRAd3emG" alt=""><figcaption></figcaption></figure>

2. On the Browser Stack Details prompt, enter the Integration URL, User Name, and API Key and click on Create.

<figure><img src="/files/Jv92ggPicjvAgQAXu9Ne" alt=""><figcaption></figcaption></figure>

3. After entering the details, click on the Create button to add the Integration.

***

## Using BrowserStack for Cloud Device Execution

Once the account details are added to the integration, select BrowserStack as the cloud device provider while creating the cloud device connection.

<figure><img src="/files/S9i5MsXoyFdnvIvF5e0m" alt=""><figcaption></figcaption></figure>


# Sauce Labs Cloud Device Integration

Connect Sauce Labs to QApilot with account details, then use Sauce Labs cloud devices for mobile test execution.

## Sauce Labs Cloud Device Integration

QApilot connects to Sauce Labs so teams can record and run mobile tests on Sauce Labs cloud devices. Configure account credentials once, then select Sauce Labs for a cloud device connection.

Sauce Labs is a cloud device provider. QApilot uses the integration credentials to establish cloud device sessions.

## Prerequisites

You just need the username and API Key for SauceLabs which can be obtained from your SauceLabs account dashboard.

This can be obtained from the Account Settings page as shown below:

<figure><img src="/files/qkBReZDZE3SBPkaruJgE" alt=""><figcaption></figcaption></figure>

***

## Integrating with SauceLabs

1. Navigate to Settings > Integrations. Enable the toggle on the SauceLabs widget.

<figure><img src="/files/WxG9LvRHTfPYFbXJMCV5" alt=""><figcaption></figcaption></figure>

2. On the Sauce Labs Details prompt, enter the Integration URL, User Name, Access Key, and Datacenter URL, and click on Create.

<figure><img src="/files/b7BSMIWhVEVAQVjKqr61" alt=""><figcaption></figcaption></figure>

3. After entering the details, click on the Create button to add the Integration.

***

## Using SauceLabs for Cloud Device Execution

Once the account details are added to the integration, select SauceLabs as the cloud device provider while creating the cloud device connection.

<figure><img src="/files/6EWyMkUU9oEf7hQr9unG" alt=""><figcaption></figcaption></figure>


# Partner Integrations

Integrate partner products and workflows with QApilot.

## Single Sign-On (SSO) Integration

SSO lets your users open QAPilot directly from your platform without having to log in separately.

***

### Before You Begin

Your users must already be onboarded on QAPilot. Contact your QAPilot account manager to get this set up.

***

### Step 1 - Enable SSO

1. In QAPilot, go to **Settings → Single Sign-On**
2. Toggle **Enable Single Sign-On** to **Yes**
3. Copy the **Access Key** shown and save it securely in your backend

> **Note:** If you click **Refresh**, a new Access Key is generated and the old one is deactivated immediately. Update your integration before refreshing.

***

### Step 2 - Generate an SSO Token

When a user wants to access QAPilot, your backend need to call this API to get a login URL.

**Endpoint**

```
POST https://api.qapilot.io/patapi/access/sso/v1/generate-sso-token
```

**Request body**

```json
{
  "login_id": "user@example.com",
  "accesskey": "your-access-key-here"
}
```

| Field       | Description                            |
| ----------- | -------------------------------------- |
| `login_id`  | The user's registered email on QAPilot |
| `accesskey` | The Access Key from your SSO Settings  |

Reach out to support team for assistance with hashing of the payload. On success, you will receive a signed URL. Redirect the user's browser to this URL - QAPilot will log them in automatically.

> The token in this URL is valid for **5 minutes** and can only be used once.

***

### Important

* Always make this API call from your backend, never from the browser
* Generate a fresh token each time - do not reuse or cache tokens
* The `login_id` must belong to a user already onboarded on QAPilot

***

*For help, contact your QAPilot account manager or write to* [*support@qapilot.io*](mailto:support@qapilot.io)