In this guide
An app with no content looks broken. An app filled with real customer data is a privacy problem. Testers need something in between: realistic but fake data, and accounts that cannot hurt anyone. This is a checklist for preparing both.
Why it matters
Testers who open an empty app cannot test the screens that matter: lists, search, filters, edit flows. They will either report "nothing to see" or give up. And if they log in to a copy of your live data, you have exposed real people to strangers.
Checklist: data
- Never use real user data. No production exports, even "just for testing". Real names, emails and messages should not reach testers. This is general guidance, not legal advice; check the rules that apply to you.
- Create seed data on purpose. Write a small set of fake records that covers normal cases and edge cases.
- Cover the edges. Include a very long name, an empty field, special characters, an item with no image, a list with one entry, and a list with many.
- Make it recognizable as fake. Use obviously invented names and addresses so nobody mistakes it for real data.
- Make it resettable. Decide how you restore the start state: a reset button, a script or a fresh account. Without it, later testers see the mess earlier ones left.
- Match the feature. If you want feedback on search, there must be enough items for search to matter.
Checklist: accounts
- Provide test accounts if your app needs a login. Do not ask testers to hand over real passwords.
- One account per tester when state matters. If testers share one account, they overwrite each other's changes and cannot test sign-up or onboarding. Shared accounts are only fine for read-only checks.
- Use limited permissions. A test account should not reach admin tools, real payments or live messaging.
- Offer both paths. Allow testers to create their own account too, so sign-up gets tested.
- Do not put credentials in public places. Send them privately to the testers who need them, and change or delete them afterwards.
- Check third-party services. If logins go through another provider, make sure test users can actually get in. See Android test device and version planning for matching testers to setups.
Payments and external effects
If your app can send emails, push messages, or take payments, switch those to a test mode or point them at harmless targets. A tester tapping "Buy" should never cost anyone money or notify a real customer. For payment testing, use the test tools your payment provider offers and check their current documentation.
Put it in the test instructions
Tell testers in one short block: which account to use, what data exists, what to do first, and what to ignore. This saves them guessing and you duplicate reports. For layouts across devices, see Android screen sizes.
Back to the Android app testing guide.
Start here and describe the test setup when you request feedback.