Testing a Game During Closed Testing: What Testers Should Focus On

If you ask testers to "try your game," most will open it, play a few minutes, and tell you it was fine. That is not much use to you. A game fails in ways a utility app doesn't: it overheats phones, it breaks when a call comes in mid-level, it loses progress, and it frustrates people in the first two minutes. Give testers a clear focus and you get feedback you can act on.

This post lists what testers should look at in a game during a closed test, and how to turn it into a short daily brief. It assumes you already have a closed testing track running. If not, start with the FAQ.

Why games need a different test brief

A closed test on Google Play currently requires 12 testers opted in for 14 days in a row for new personal developer accounts. Rules can change, so check Play Console Help for the current requirement. The requirement is only the minimum. The 14 days are also a chance to find out how your game behaves on phones you don't own.

Games push hardware harder than most apps. They use the GPU, audio, touch input, sensors, network and storage at once. A bug that never shows on your test phone can be the first thing a player hits on a cheaper device. Testers on their own Android phones, with different brands, screen sizes and Android versions, are the closest thing to a real audience you can get before launch.

1. The first five minutes

Most players decide whether to keep a game very quickly, so ask testers to describe the opening in detail.

• How long from tapping the icon to actually playing?
• Was there a loading screen that felt too long or looked frozen?
• Did the tutorial explain the controls, or did they have to guess?
• Were there any prompts (permissions, ads, login, rating) before they had played anything?
• Could they tell what the goal was?

Ask them to write down the exact moment they felt confused or bored, if it happened. "The tutorial was unclear" is weak feedback. "I didn't know the second button was for jumping until level 3" is something you can fix.

2. Performance on their device

Don't ask testers whether the game is "fast." Ask for specifics, and always ask for the phone model and Android version.

• Frame drops or stutter: when, and in which screen or level?
• Does the phone get noticeably warm after 10 to 15 minutes?
• How much battery did a session use, roughly?
• Any long load times between levels or menus?
• Does the game feel the same on Wi-Fi and mobile data?

You can't expect lab-grade measurements from testers, and you shouldn't need them. You are looking for patterns. If three testers on low-memory phones report stutter in the same level, you have your answer.

3. Interruptions and lifecycle

This is where games fail most often and where solo developers test least. Real phones get interrupted constantly. Ask testers to deliberately do these things during a session:

1. Press the home button mid-level, wait a minute, and return.
2. Switch to another app and come back.
3. Receive a notification or call while playing, if they happen to.
4. Lock and unlock the screen.
5. Rotate the phone if your game claims to support both orientations.
6. Use the system back button or back gesture in menus and during play.

Each should end with the game in a sensible state: paused or resumed correctly, audio restored, no black screen, no lost progress. Ask testers to note anything that doesn't.

4. Saves, progress and offline behaviour

Losing progress is one of the quickest ways to earn a bad review. Testers should check:

• Does progress survive closing the app completely and reopening it?
• What happens when the network drops mid-game? Does it show a clear message, hang, or crash?
• If the game needs a connection, is that obvious before they start?
• If you offer cloud save or an account, does it work after an uninstall and reinstall?

Suggest they try airplane mode on purpose. It takes a minute and often exposes problems that normal play never will.

5. Controls and screen fit

Touch controls that feel fine on your phone may be awkward on a smaller or larger one. Ask testers to report:

• Buttons that are too small, too close together, or covered by their thumb.
• UI elements hidden by a notch, camera cutout or rounded corners.
• Gesture conflicts, such as accidentally triggering the system back gesture near screen edges.
• Text that is hard to read at their screen size.

Screenshots help a lot here. Encourage them to attach one when something looks wrong.

6. Ads and in-app purchases

If your game has monetisation, test it as carefully as the gameplay.

• Ads: do they appear at sensible moments? Can they be closed? Does the game recover properly after an ad ends?
• Purchases: does the purchase flow open and complete, and does the item arrive? Use licence testers or test payment methods as described in Play Console Help, so testers are not charged real money by accident.
• Restore: after reinstalling, can a purchased item be restored?

Be clear in your instructions which of these testers should try. Don't ask anyone to spend their own money.

7. Difficulty, fun and pacing

Technical checks are only half of it. Ask a few plain questions about the experience:

• Where did you get stuck or quit?
• Was any level unfairly hard or boringly easy?
• Did the rewards feel worth the effort?
• Would you play again tomorrow, and why or why not?

Testers will not all agree, and that is fine. One opinion is an anecdote. The same complaint from several people is a signal.

A simple 14-day focus plan

Testers who use the app for about 20 minutes a day can cover different areas on different days. TesterMob testers work this way, giving written feedback as they go. A rotating plan stops every report from saying the same thing. Here is one you could adapt:

• Days 1 to 2: first-run experience, tutorial, controls.
• Days 3 to 5: core gameplay, difficulty, performance on their device.
• Days 6 to 8: interruptions, background and resume, rotation, back button.
• Days 9 to 10: saves, offline behaviour, reinstall.
• Days 11 to 12: ads, purchases, settings, audio.
• Days 13 to 14: a free play session, plus an overall summary and what they would change first.

Put this in the tester instructions for your closed test, not just in your head. If you use TesterMob, you can describe what you want checked when you add your app from the developer page. If you are curious how the testing side works from the other end, the tester page explains it.

What to ask testers to include in every report

Whatever the focus of the day, a useful report has the same basics:

1. Phone model and Android version.
2. What they were doing when the issue happened.
3. What they expected and what actually happened.
4. Whether it is repeatable.
5. A screenshot or short description of the screen.

If your build includes the optional TesterMob Android SDK (an .aar file), your dashboard shows daily tester activity. That lets you see whether testers are actually opening the game each day, which is helpful when you are waiting on a 14-day window. It does not replace the written feedback.

After the test

Sort the feedback into three piles: crashes and data loss, things that block or confuse new players, and polish. Fix the first two before anything else, then release an updated build to the closed track so testers can confirm the fixes. How to handle that process is covered in other posts on the blog.

One caution: good testing improves your game, but it does not guarantee that Google will approve production access. Google decides that, and its requirements can change. TesterMob is not affiliated with Google and cannot promise an outcome. What you can do is use the 14 days properly, so that when you do launch, the first players are not the ones finding your bugs.