> For the complete documentation index, see [llms.txt](https://learning.contextqa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learning.contextqa.com/mobile-testing/mobile-testing-tutorial.md).

# Tutorial: Your First Mobile Test

## Quick answer

Upload an Android APK, create an AI-assisted mobile smoke test, select a device and build, run it, and review the execution evidence. Follow the documented prerequisites and steps, then verify the expected result before using the workflow in a shared or production process.

## What this page covers

This tutorial uses an Android example, but the same sequence applies to iOS when you select **IPA** and **iOS**.

## What you will create

A focused smoke test that launches a sample application and verifies its welcome screen. Use only an app build and data approved for testing.

## Before you begin

* Obtain a test-installable APK.
* Confirm the supported Android versions.
* Choose one representative device.
* Use a fictional or dedicated test account if authentication is required.

## Step 1: Add the Android build

1. Select **Uploads** in the left navigation.
2. Select **Create Folder**.
3. Enter `Sample App — Android 2.4.1 Staging` for **File Name**.
4. Select **APK** for **File Type**.
5. Keep versioning enabled if you want to retain later revisions.
6. Select **Create**.
7. Open the folder and upload the approved `.apk`.
8. Wait until the Uploads table shows a file path, non-zero size, and **Completed** status.

{% hint style="warning" %}
Do not put production credentials or customer data in the folder name, app filename, or documentation screenshots.
{% endhint %}

## Step 2: Start a mobile test case

1. Open **Test Cases**.
2. Select **New Test Case**.
3. Choose **AI Assistance**.
4. Under **Select Target Platform**, select **Mobile**.
5. Leave **Prerequisites** empty for this independent smoke test.

## Step 3: Describe the scenario

Enter:

```
Launch the sample app and verify that the Welcome heading is visible.
Tap Get started and verify that the Sign in screen opens.
```

This prompt is effective because it identifies the starting action, visible controls, and expected results.

Select **Generate & Execute Test Case** to continue to mobile configuration.

## Step 4: Select the platform, device, and build

1. Review the **Parallel** and **Queued** capacity indicators.
2. Select **Android** under **Select Platform**.
3. Select a compatible Android device.
4. Select `Sample App — Android 2.4.1 Staging` under **App Build**.
5. Confirm that the final action is enabled.
6. Select **Generate & Execute Test Case**.

## Step 5: Review the live run

Verify that the execution uses the selected build and device. Follow the step status as the test launches the app, verifies the welcome screen, taps **Get started**, and verifies the sign-in screen.

If a step fails, use the nearest screenshot or recording timestamp to determine whether:

* The wrong screen was open.
* The visible label differed from the prompt.
* The app needed more time or prerequisite state.
* The selected build behaved differently from the expected version.

## Step 6: Review and refine the generated case

After execution:

1. Open the saved test case.
2. Check that its type is **Mobile**.
3. Compare each generated step with the original prompt.
4. Make the title goal-based, for example `Android — Open the sign-in screen`.
5. Add `mobile`, `android`, and `smoke` labels.
6. Rerun the case after any meaningful edit.

## Step 7: Review result evidence

Open the latest result and record:

| Evidence              | What to verify                               |
| --------------------- | -------------------------------------------- |
| Overall status        | The final pass or fail state                 |
| Step details          | The exact action or verification that failed |
| Screenshots           | What was visible at the relevant step        |
| Logs                  | Device, timing, and execution context        |
| Video, when available | The sequence leading to the failure          |

## Definition of done

Your first mobile test is ready for a suite when:

* It uses an approved completed build.
* Its title and labels are searchable.
* Generated steps match the intended flow.
* It passes on the selected supported device.
* Its evidence is sufficient to explain a failure.

Next, [add the test to a mobile suite and plan](/mobile-testing/mobile-test-plans.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://learning.contextqa.com/mobile-testing/mobile-testing-tutorial.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
