Core form: identify the task and outcome
Begin with app build, device, operating system and task attempted. Prefill the build when you can do so reliably, but let the participant correct it. Ask: what were you trying to accomplish, were you able to finish and at which step did you need help? Offer completed, partly completed, could not complete and did not attempt as separate outcomes. A missing attempt should not be interpreted as a successful journey.
Next ask what the person expected and what they observed. Keep the wording neutral: what happened after you tapped save is better than how easy was our excellent saving feature. Include a short field for the most confusing moment and one for an optional improvement. Separate required task evidence from feature ideas. The first report should be possible to submit without writing a long essay or choosing a positive score.
Conditional bug section: enough detail to reproduce
If the participant reports unexpected behavior, ask for the starting state, ordered steps, expected result and actual result. Add whether it happened once or repeatedly and whether an error message appeared. Ask about connectivity or permission state only when those details matter. Provide an example using harmless sample content so people understand the level of specificity without copying an answer that does not fit their experience.
Make screenshots and recordings optional, and explain how to remove private information. Do not request passwords, full payment details or personal documents in a general feedback form. A report can still be useful when attachments are unavailable. Apple's TestFlight feedback can include screenshots, crash comments and general comments in App Store Connect; check there for related context before asking someone to retype everything into another system.
Follow-up section: timing and question order
Collect a short report immediately after the task, while the sequence is easy to remember. If the research question concerns repeat use, schedule a separate follow-up after a meaningful interval for your product. Ask whether they returned, what prompted that return and whether the saved result was still useful. A first-session impression cannot establish long-term retention. Keep people who did not return in the record rather than only surveying the most enthusiastic participants.
If you include a private satisfaction score, place the explanation beside it and record it separately from observed task success. Ask what influenced the score. Avoid making a public store review the next mandatory step or sending only happy participants to the review screen. For optional community ratings on RateMyApp, treat the stars as another person's opinion and use the written report to understand the experience behind them.
Review workflow: turn responses into a queue
Give each response a report identifier and a state such as new, needs clarification, confirmed, scheduled, retest or closed. Preserve the original observation when rewriting a report into a developer ticket. Several descriptions may point to the same cause, but merge them only after checking their builds and steps. Give a tester a short acknowledgment and avoid promising a date you cannot support.
Review patterns by task and participant type instead of averaging unrelated scores. A beginner's confusion and an expert's missing shortcut can require different changes. Link a fix to the retest that checked it. Use the free bug-report and testing-brief templates to keep the form aligned with the work participants actually attempted. A tidy response sheet is useful only if somebody is responsible for the next action.
Working example
Sample private report for a habit tracker: task equals create a sample habit and mark it complete; outcome equals partly completed; build and device equal the participant's actual setup. Expected result: the completed habit remains marked after reopening. Observed result: the check mark disappears when the app is reopened offline. Steps: create a test habit, mark it complete, close the app, disable connectivity and reopen. Frequency: reproduced twice. Screenshot: optional, with the account name removed. Most confusing moment: whether the first completion had been saved. This is an illustrative form response, not a defect observed in a real RateMyApp customer's app. Route it to the responsible developer and retest the same sequence after a change.
Build a private testing briefYour next steps
- Keep the core form short: build, device, attempted task, outcome, expectation and observation.
- Show reproduction questions only for relevant problems and make redacted attachments optional.
- Separate first-session feedback, later use, private scores and voluntary public store reviews.
- Assign every actionable report a next state and connect confirmed fixes to a recorded retest.
Official sources
Sources checked October 3, 2026. Review the current provider documentation before acting on requirements.
Download the free app testing templates
Turn the next test into something useful.
Publish a focused brief on RateMyApp. Credits fund approved private reports; public store reviews are voluntary and unrewarded.
List your app for feedback