Tester feedback
Closed-Testing Feedback Template for Android Apps
Copy focused questions and download a structured CSV for collecting useful Android closed-test feedback, reproducible defects, device context, and consent.
“Please test the app and send feedback” usually produces silence or opinions that are hard to act on. Give each tester a defined journey, then ask short questions that capture context, expectation, outcome, impact, and evidence.
Start with a scenario brief
Build: [version code and version name]
Your assigned journey: [starting state → desired outcome]
Test account/data: [safe credentials or setup; never real sensitive data]
Environment: [network, language, device capability, or interruption]
Stop and report immediately if: [privacy, payment, data-loss, or security concern]
Private feedback channel: [form/email/tool and response window]
This structure makes results comparable while leaving room for observation. Never ask testers to submit passwords, one-time codes, financial data, or other sensitive material through the feedback form.
Copy these core feedback questions
- What were you trying to accomplish?
- Were you able to complete it? Choose: yes, partly, or no.
- At which exact step did the result differ from what you expected?
- What did you expect to happen, and what happened instead?
- Can you reproduce it? If yes, list the shortest reliable steps.
- How much did this affect the task? Choose: blocker, major friction, minor friction, or suggestion.
- Which app build, device model, and Android version did you use?
- Were network, permissions, language, orientation, battery, or another app involved?
- May the team contact you privately for clarification?
Ask a separate open question—“What, if anything, felt confusing?”—after the structured fields. Avoid leading questions such as “Did you love the new navigation?”
Capture a defect in a reproducible format
Separate severity from priority
| Tester impact | Meaning | Example triage response |
|---|---|---|
| Blocker | Core journey cannot be completed or safety/data is at risk | Stop affected testing, investigate now |
| Major | Journey completes only with a difficult workaround | Triage in the release candidate |
| Minor | Task completes but friction or presentation is wrong | Schedule based on frequency and reach |
| Suggestion | Preference or possible improvement | Validate before committing |
The tester should describe impact. The product team sets priority after considering reach, risk, cost, policy, and release timing. Preserve both fields rather than treating them as the same.
Close the loop without coaching the answer
When a report is unclear, ask for the starting state, build, shortest steps, and observable result. When a fix is available, give the tester a clean retest scenario without telling them the expected “correct” answer. Record whether the issue is fixed, still reproducible, or replaced by a different problem.