AI test plan for mobile builds: what to test in a new app build

A new build arrives and someone has to decide what to test. On most small teams that decision takes about thirty seconds: read the release notes, open the app, tap through the new screen, send it on. It works until the build that also asked for camera access, raised the minimum iOS version or added a payments SDK that nobody mentioned in the notes. Those changes are in the binary whether or not anyone wrote them down.

This guide covers two things. First, a practical way to decide what to test in a new iOS or Android build, with a checklist template you can copy into any ticket or chat, no tool required. Second, how the AI test plan in AppForShare writes that list for you from what changed in the build itself, not only from the text someone typed.

Why release notes are not enough

Release notes describe what the developer meant to change. The build describes what actually changed. The gap between the two is where many test rounds miss things:

• New permissions. A library update adds a location or Bluetooth permission. The notes say "updated dependencies".
• Minimum OS changes. A project setting moves the minimum iOS or Android version up, and the oldest test phone can no longer install the app.
• SDK and frameworks. A new Xcode or a higher Android target API brings behavior changes. A new framework appears for analytics, ads or payments.
• Same version number. The build kept the version and build number of the previous one, so testers cannot tell which one they have.
• Store rule findings. A missing privacy manifest entry or a target API level below Google Play's current requirement will not stop a test install, but it will stop the upload later.

Generating test cases from release notes with AI is useful, but it only knows what the notes say. A test plan that starts from the binary catches the changes nobody thought to mention.

How to decide what to test in a new build

You will never test everything in every build, so test in order of risk. A simple way to rank: for each change, ask how likely it is to break and how bad it would be for a user if it did. Data loss, crashes on launch and blocked sign in are at the top. A misaligned label is at the bottom. Then work through the list in this order.

1. Upgrade over the previous build, keeping data

Most of your users will not install fresh. They will update. Install the previous build, sign in, create some real data (a draft, a saved setting, a downloaded file), then install the new build over it without deleting the app. Check that the user is still signed in, the data is still there and nothing asks for setup again. Database migrations, renamed keys and changed storage locations break here and nowhere else.

On Android a build with a lower versionCode will not install over a higher one, and a build signed with a different key will not install over the old one at all. Both show up in this test before they reach a user.

2. Fresh install

Delete the app and install the new build on a clean device. Go through onboarding, sign up, sign in and the first screen a new user sees. Fresh install bugs hide well because developers rarely reinstall.

3. Permission prompts: deny, then allow later in Settings

Every new permission deserves its own test, and the happy path is the least interesting one. On iOS the system prompt for a permission appears only once per install. On Android, since Android 11, a user who denies the same permission twice is not asked again by the system. After that, the only way back is the Settings app. So test it like this:

1. Trigger the feature that needs the permission and tap Don't Allow or Deny.
2. Check that the app explains what is missing and does not crash, freeze or loop the prompt.
3. Leave the app, turn the permission on in Settings, return and check that the feature now works without a restart.
4. Where the platform offers partial choices, try them: limited photo access and approximate location on iOS, "only this time" on Android.

Also read the text of the prompt. On iOS it comes from your usage description strings, and vague or missing text is a common App Review issue.

4. The oldest supported OS

Install on a device running the minimum OS version the build supports. If the minimum went up, confirm the change was intended: users below it will stay on the older version. If it went down, the oldest device is where newer APIs called without a version check will crash.

5. Offline and poor network

Turn on airplane mode and open the main screens. Then switch the network off in the middle of a save or upload. The app should show a clear message, keep what the user typed and recover when the network returns. Xcode's Network Link Conditioner and the Android emulator's network settings can simulate a slow connection.

6. Background and resume

Send the app to the background in the middle of a task, lock the phone, come back a few minutes later. Take a phone call during a video or a payment. On Android, the "Don't keep activities" developer option destroys each screen as soon as you leave it, which is a quick way to find state that does not survive.

7. The changed areas, then a short smoke test

Now test the features from the release notes, the new screens and any area touched by a new framework or SDK. Finish with a short pass over the core flows that must never break: launch, sign in, the main action of the app, purchase if you have one, sign out.

A mobile app test plan template you can copy

Paste this into a ticket or chat for each build and delete what does not apply. Put the reason next to each task, so the next person knows why it is there.

Build: [app] [version] ([build number]), [iOS / Android]
Previous build tested: [version] ([build number])
What changed: [permissions, minimum OS, SDK, frameworks, notes]

High priority
[ ] Upgrade over previous build: signed in, data kept, no repeat setup
[ ] Fresh install: onboarding, sign up, sign in
[ ] New permission [name]: deny, app explains, allow in Settings, feature works
[ ] Oldest supported OS ([version]) on a real device: install and launch

Medium priority
[ ] Changed feature: [from release notes]
[ ] Offline: main screens, network lost during save
[ ] Background and resume during [main task]
[ ] Version and build number differ from the previous build

Smoke test
[ ] Launch, sign in, main action, purchase, sign out

Tested by: [name]   Devices: [model, OS]   Date: [date]

For iOS builds there is also a set of checks to run before testers see the file at all, such as export method, provisioned devices and profile expiry. They are covered in the iOS test build checklist for 2026.

Generating the test plan with AI in AppForShare

AppForShare already reads every build uploaded to an account: permissions, minimum OS, SDK and frameworks, size, and how each of those changed since the previous build of the same app, plus the store readiness check. The AI test plan turns those facts and your release notes into the kind of list above.

On the build page, press Write a test plan. You can type an optional focus, for example "the new checkout". A few seconds later the card shows 6 to 15 test tasks ordered by risk. Each task has:

• 1 to 5 short steps,
• an area and a priority,
• a Why line that names the fact it comes from: a new permission, a raised minimum OS, a new framework, a build that kept the same version number, a store readiness finding, the release notes or your focus.

When a previous build exists, the plan includes an upgrade task: install over that build and check the data is kept. A new permission becomes a deny then allow later in Settings task. Features come only from your release notes and your focus. The AI is told not to invent screens it cannot know about, so a build without notes gets general checks plus the technical ones.

Working through it as a team

Tick a task when it is done. Ticks are shared by the workspace and show who did each task and when, so two people do not test the same thing. If you write a new plan for the same build, ticks stay on tasks that come back with the same title. Developers and above write plans and tick tasks; Viewers can read them. Copy as checklist gives plain text for a ticket, a chat or a client email. People who only install through the link do not see the plan, so copy it to them if they need it.

If you use an AI coding tool, the MCP tool test_plan returns the plan with its ticks and can write a new one when you ask. The MCP server is part of Pro and Team; setup for Claude, Cursor, VS Code and others is on the MCP docs page.

What it does not do

• It writes the plan. A person still tests on a phone. It does not run tests or find bugs by itself.
• There is no export to Jira or Linear yet, and no CLI command for it. Copy as checklist works anywhere plain text does.
• It is written by AI. Read it, remove what does not apply and add the checks only you know about.

Which plan you need

The test plan works on every plan with an account. One plan uses 1 AI action from the same monthly pool as release notes drafts and fix plans: Free includes 5 AI actions a month, Pro 100 and Team 500 shared by the workspace. Asking again for the same build with the same focus is free. See pricing for the rest of each plan, and AI for mobile app releases for where else AI helps in release work and where it should not.

Other tools also generate QA tasks with AI, including TestApp.io; the AppForShare vs TestApp.io page sets out how the two products differ.

Common questions

How many test cases should a new build get?

Enough to cover every change and the core flows, and few enough that someone actually finishes them. For a typical update that is somewhere between six and fifteen tasks, which is the range the AI test plan writes. A large release can be split into several focused rounds.

Can AI write test cases from release notes alone?

Yes, and they are a fair start, but they cover only what the notes mention. Adding the facts from the binary, such as permissions and the minimum OS, catches changes that were never written down.

Should I test on simulators or real devices?

Use simulators and emulators for quick layout and flow checks. Use real devices for permissions, camera, push notifications, performance, the oldest supported OS and upgrade over an installed build.

Does the AI test plan test my app?

No. It tells a person what to test and in which order. The testing happens on real phones, by people.