A test plan for every build, written from what actually changed
Every plan with an account (uses AI actions)
A new build lands and someone has to decide what to test. Usually that is a quick guess from the release notes, and the new camera permission or the raised minimum iOS version slips through because nobody wrote it down.
AppForShare already reads every build: permissions, minimum OS, SDK and frameworks, size, and how they changed since the previous build, plus the store readiness check. The test plan turns those facts and your release notes into concrete tasks, and every task says which fact it comes from.
Example
Test plan, 2 of 8 done
- Upgrade from 1.3 and check dataWhy: previous build 1.3
- Camera prompt, deny, allow laterWhy: new permission
- Fresh install on iOS 15.1Why: minimum iOS raised
- New booking calendarWhy: release notes
Made for
- Small teams without a full time QA person
- Agencies that send builds to clients and want a repeatable check before each one
- Testers who get a link and need to know where to look
- Developers who want a second pair of eyes on what a build changed
What it ends
- Writing the same test list by hand for every build
- Missing a new permission prompt or an OS change that the notes did not mention
- Not knowing which checks a teammate already did
How it works
Step 1
Open the build
Any build in your account, from the dashboard, the CLI or a GitHub Actions run. Its page already shows what changed and the store check.
Step 2
Write a test plan
Press Write a test plan. Optionally name an area to focus on, for example the new checkout. The plan arrives in a few seconds.
Step 3
Test and tick
Each task has short steps. Tick it when it is done; the team sees who did what and when. Copy the plan as a checklist for a ticket or a chat.
Grounded in the build, not only in the notes
Many AI test case tools only read the text a person typed. AppForShare also gives the AI the facts it reads from the .ipa, .apk or .aab: a permission that was added, a minimum OS that went up, a framework that appeared, a build that kept the same version number, and any store readiness finding. Those become their own tasks, such as denying a new permission and allowing it later in Settings, or installing over the previous build to check that data is kept.
Features come only from your release notes and the focus you type. The AI is told not to invent screens it cannot know about, so a build with no notes gets general checks plus the technical ones.
Made for a team
Ticks are shared by the workspace and show who did each task and when. Writing a new plan keeps the ticks on tasks that come back with the same title. Viewers can read the plan; Developers and up write plans and tick tasks.
Your AI coding tool can read the plan too: the MCP tool test_plan returns the tasks with their ticks, and can write a new plan when you ask.
Good to know
- It writes the plan; a person still does the testing on a phone. It does not run tests or find bugs by itself.
- One plan uses 1 AI action (Free 5, Pro 100, Team 500 a month). Asking again for the same build and focus is free.
- No export to Jira or Linear yet. Copy as checklist gives plain text you can paste anywhere.
- Written by AI: read it and add your own checks.
Questions
- Which plan do I need?
- Any plan with an account. Each plan uses 1 AI action from your monthly AI actions, the same pool as release notes and fix plans.
- Where do the tasks come from?
- From what changed since the previous build of the same app (read from the binary), the store readiness check, the release notes of the build and the focus you type. Each task shows which one under Why.
- Does it test my app?
- No. It tells a person what to test and in which order. The testing happens on real phones.
- Can my testers see it?
- Members of your workspace see it on the build page. People who only install through the link do not; copy the checklist into your chat or ticket if you want to share it with them.
Read next
Try it on your own app
Free account in a minute. Pro starts with a 7 day free trial.