What to Test examples for clearer betas.
What to Test is how you aim TestFlight feedback. These templates give testers a short mission instead of “try everything.” Adapt the brackets, keep the list short, and update the note whenever the build’s focus changes.
How to use these templates
Lead with the build’s purpose in one sentence, then give 3–5 concrete checks. Name devices, accounts, or locales when they matter.
Update What to Test for every build that changes focus. Stale notes produce stale feedback.
- One theme per build when you can
- Tell testers what “done” looks like
- Ask for repro steps when something fails
- Keep secrets out of public TestFlight notes
Crash fix build
Focus: confirm the crash from [screen / action] is gone on [iOS version / devices].
Please: (1) Update to this build. (2) Repeat the steps that used to crash: [steps]. (3) Use the app for 10 minutes around [feature]. (4) If it still crashes, send the crash + exact steps and device model. (5) Note anything else that feels unstable.
Onboarding redesign
Focus: first-run clarity for new accounts.
Please: (1) Delete the app or use a fresh test account. (2) Complete onboarding without skipping. (3) Tell us where you hesitated or got lost. (4) Confirm you reach [home / first success moment]. (5) Optional: try the “Skip” path if shown and say whether it felt safe.
Paywall and purchases
Focus: paywall copy, purchase, and restore on sandbox.
Please: (1) Open [paywall entry point]. (2) Read the plans and tell us what is unclear. (3) Sandbox-purchase [product]. (4) Force-quit and restore purchases. (5) Cancel or manage the sandbox subscription and confirm entitlements update. Do not use production Apple IDs.
Localization pass
Focus: [language / locale] UI and store-facing strings in-app.
Please: (1) Set device language to [language]. (2) Walk [core flows]. (3) Flag truncated text, mixed English, or awkward phrasing with screenshots. (4) Check [settings / paywall / onboarding] especially. (5) If you are a native speaker, suggest a clearer line when something feels off.
Performance and battery
Focus: smoothness and resource use on mid-range devices.
Please: (1) Test on [device models] if you have them. (2) Scroll [heavy screen] for 30 seconds and note jank. (3) Run [import / sync / export] and time how long it feels. (4) Leave the app in background 15 minutes and report unexpected heat or battery drain. (5) Attach Instruments or simple observations if you can.
Regression before App Store submit
Focus: smoke-test the release candidate.
Please: (1) Install fresh and sign in. (2) Hit [top 5 user journeys]. (3) Toggle [key settings]. (4) Make one sandbox purchase if IAP changed. (5) Reply “looks good for submit” or block with severity + repro. We ship after this build’s feedback window.
Keep What to Test in Helm
Update notes beside your builds in TestFlight, invite the right groups, and keep beta review moving. For the how-to, see write What to Test and invite external testers.
FAQ
How long should What to Test be?
Short enough to read on a phone: one focus line plus a handful of checks. Long essays get skipped.
Should every build reuse the same What to Test?
No. Change the note when the mission changes. A crash-fix build and an onboarding build need different instructions.
Can testers see What to Test in TestFlight?
Yes. It appears with the build in TestFlight so testers know what you want exercised before they tap Open.
