App testing templates.
Ready for your next build.

# App beta test plan

App: [name]
Build/version: [exact build]
Platform and supported OS: [iOS/Android and versions]
Research owner: [team role]
Round dates: [start and end]
Decision this round should inform: [one release or product decision]

## 1. Choose a journey

Write the question before inviting testers. Example: Can a new user create a note and find it after restarting? Replace the example with your own user goal. A task such as "try everything" makes it hard to compare observations or decide what to repair.

Primary task: [what the user should accomplish]
Starting state: [fresh install, returning account, permission state]
Supported device coverage: [device/OS combinations to include]
Time commitment: [realistic estimate]
Known limitations: [unavailable features or expected beta behavior]

## 2. Prepare access safely

- [ ] Open the official store/beta link using an eligible tester account.
- [ ] Confirm the named build can install and launch.
- [ ] Provide dummy data and an approved test account when needed.
- [ ] Keep passwords and recovery codes out of shared reports.
- [ ] Use provider sandbox workflows for purchase testing.
- [ ] Tell testers which actions are outside this round.
- [ ] Explain who can see submitted evidence and when it will be removed.

Access link: [official distribution URL]
Access troubleshooting contact: [business support contact]
Sensitive areas excluded: [payments, personal uploads, production changes]

## 3. Give a neutral task

Invitation task: [describe the outcome without explaining every tap]
Observation prompts:
- What did you expect to happen?
- Where did you hesitate or need help?
- What happened after the task or restart?
- Can you reproduce the problem? Which steps matter?

Approval should depend on attempting the task and providing specific observations, including build and device context. A reproducible defect or blocked task can be useful evidence. Praise, a minimum star score and a public store review are not acceptance conditions.

## 4. Review the round

Report identifier: [pseudonymous ID]
Outcome: [completed / blocked / abandoned]
Expected result: [description]
Actual result: [description]
Evidence: [optional redacted screenshot or reproduction steps]
Owner decision: [fix, investigate, follow up or defer with reason]
Retest build and task: [exact follow-up]

Separate a tester's observation from your interpretation. Record uncertainty when a report does not reproduce. Do not treat one successful task as proof that every feature works.

Template by RateMyApp: https://ratemyapp.io/resources/app-testing-templates/
Free to copy and adapt for your team's private testing. No attribution required.

# Mobile app bug report

Report ID: [pseudonymous identifier]
Short title: [observable problem, e.g. Saved note missing after restart]
App and exact build: [name/version/build]
Device model: [model]
OS version: [version]
Account state: [new/returning/signed out; never include credentials]
Permission state: [relevant allowed/denied permissions]
Network state: [offline/Wi-Fi/mobile; avoid precise location]

## Reproduction steps

1. [starting state and first action]
2. [next action]
3. [action where behavior differs]

Expected result: [what the app or task led you to expect]
Actual result: [what you actually observed]
Frequency: [e.g. two of three attempts; unknown is acceptable]
Workaround attempted: [what changed, if anything]
User impact: [lost work, blocked task, confusing message or visual issue]

## Optional evidence

Attach a redacted screenshot or short recording only when it helps explain the problem. Remove personal messages, names, tokens, email addresses and payment details. A written reproduction can be sufficient. Do not upload passwords, recovery codes, session cookies or production data.

Evidence reference: [safe attachment or report reference]
Approximate failure time: [only when necessary for authorized log investigation]

## Owner investigation

Observed again on: [build/device, or not reproduced]
Related findings: [report IDs]
Decision: [investigate / fix / defer / request clarification]
Reason: [brief evidence-based explanation]
Assigned role: [team role]
Retest build: [build]
Retest outcome: [resolved / remains / changed]

Record the problem without guessing its cause. "The save button returned an error" is an observation; "the database is broken" needs separate investigation. Keep a negative finding eligible for report approval when it contains the agreed evidence.

Template by RateMyApp: https://ratemyapp.io/resources/app-testing-templates/
Free to copy and adapt for your team's private testing. No attribution required.

# Beta tester invitation template

Subject: Try [app]'s [specific journey] on [platform]

Hi [name or group],

We are testing [app], which helps [specific audience] accomplish [specific goal]. We would like feedback on [one journey] in build [exact build].

If you would like to participate, the task is to [neutral task outcome]. Allow approximately [honest estimate] minutes. You need [supported device/OS] and [access requirements]. The current beta limitations are [known limitations].

Official access link: [store or approved beta distribution URL]
Private feedback route: [report form or approved business support channel]
Round closes: [date and timezone]

Please tell us what you expected, what happened and where you hesitated. Include your build and device/OS, plus reproduction steps if something fails. Screenshots are optional and should be redacted. Use dummy data and do not share credentials, recovery codes or payment details.

If a defect blocks the task, that is still useful feedback. There is no requirement to praise the app, provide a minimum score or post a public store review. [If research is compensated, state the amount, eligibility, agreed report evidence and actual payment terms accurately. Otherwise remove this sentence.]

Participation is optional. If you need help accessing the build or would like to stop, contact [business support route]. [State actual data use, audience and retention terms; link to the applicable privacy notice.]

Thanks,
[name/team and relationship to the app]

## Before sending

- Replace every bracketed placeholder and remove unused options.
- Verify the link, build and supported devices from a tester's starting state.
- Match the time estimate to the actual task.
- Use an audience that expects the invitation; check community posting rules.
- Keep participation, compensation and public reviews separate.
- Check the distribution platform's incentive rules before offering a reward. Apple's TestFlight rule: https://developer.apple.com/app-store/review/guidelines/#beta-testing.
- Confirm that the named support route and privacy information work.

This is a draft, not consent to contact anyone. Send it only through an appropriate, authorized channel.

Template by RateMyApp: https://ratemyapp.io/resources/app-testing-templates/
Free to copy and adapt for your team's private testing. No attribution required.

# App feedback and retest log

App/build under review: [exact build]
Round owner: [team role]
Decision date: [date]
Primary journey: [user goal]

Copy the finding block below for each issue. Use report IDs rather than personal names. Preserve the observed behavior even when you decide to defer it.

## Finding [ID]

Source report IDs: [IDs]
Task and starting state: [task, account and permission state]
Affected build/device/OS: [known scope; state what has not been checked]
Observation: [what the tester actually encountered]
Expected behavior: [what the task or product promised]
Frequency: [attempts and observations, or unknown]
Impact: [blocked task / lost work / confusion / cosmetic]
Confidence: [reproduced / evidence only / needs clarification]
Related findings: [IDs, or none]

Owner interpretation: [keep separate from the observation]
Priority and reason: [impact, recurrence and scope]
Decision: [fix / investigate / follow up / defer]
Decision explanation: [specific reasoning]
Assigned role: [team role]
Change reference: [ticket or revision]

Retest build: [exact build]
Retest starting state: [fresh/returning, permissions, network]
Retest task: [same journey, plus regression concern]
Observed retest result: [specific evidence]
Status: [resolved / remains / changed / not retested]
Remaining uncertainty: [untested scope]

## Round release decision

- [ ] Blocking findings have a recorded decision and owner.
- [ ] Relevant fixes were retested on the named build.
- [ ] Known limitations are stated accurately to users.
- [ ] Purchase tests used provider-supported test workflows.
- [ ] Access and support links were checked from the intended starting state.
- [ ] Reports and attachments contain no credentials or sensitive production data.

Release decision: [release / continue testing / limited rollout]
Evidence supporting the decision: [references]
Known remaining limitations: [specific items]
Follow-up task and owner: [next investigation]

This log organizes your evidence. A checked box, submitted report or completed build does not prove store approval or that every production path works.

Template by RateMyApp: https://ratemyapp.io/resources/app-testing-templates/
Free to copy and adapt for your team's private testing. No attribution required.