Google Play closed testing
The standard path for Android apps: a closed track in your Play Console, invited testers, and a campaign that tracks opt-ins and participation across the window.
Android App Testing Service
Coordinated testing for Android apps: device coverage, tester instructions, feedback collection and a campaign record you keep afterwards.
Testing that survives contact with real devices
The gap between your device and everyone else's
An Android app that behaves perfectly on a current Pixel can fail on a two-year-old mid-range device with a different OEM skin, a smaller heap and a battery optimiser that does not behave like the reference implementation.
Android app testing is the work of finding those failures before your users do. Doing it well needs two things that are hard to arrange: enough testers on meaningfully different hardware, and a way of collecting what they find that is not scattered across chat threads.
What this covers
- Coordinating testers across device manufacturers, Android versions and screen sizes
- Structuring a campaign so participation is visible through the testing period
- Collecting findings with the device context attached
- Running the test against a defined build so results are attributable
- Keeping the record so you can tell later what was tested and what changed
Supported testing workflows
Internal testing
A smaller, faster loop for validating that a build installs and starts before it reaches a wider tester group. Useful as a gate, not as a substitute for closed testing.
Repeat testing between releases
Reusable tester pools and campaign history so a second release does not mean rebuilding the roster and re-deriving what was already known.
Device and version coverage
Coverage is a decision, not a default
There is no way to test every Android device. The useful question is which configurations your users actually have, and whether your tester group reflects them.
- Start from your own installed-base data if you have it, and from your target market's typical devices if you do not
- Include at least one older Android version still within your minimum supported level
- Cover manufacturers whose platform customisations historically affect background work, permissions and notifications
- Include at least one device with a notably small or notably wide screen
Which Android versions to plan for
Your build's minimum supported level sets the floor. Somewhere between that floor and the newest release is where the interesting failures live, particularly around runtime permissions, background execution limits and notification behaviour.
If you are unsure what to target, testing at the floor, the previous major version and the newest release gives better value than testing three devices all running the same recent release.
Collecting findings that are usable
Steps to reproduce
A finding without reproduction steps is a rumour. Testers are asked for the sequence that triggered the problem, in the form you can act on.
Device context
Manufacturer, model and Android version captured with the finding, which is usually where the pattern behind a bug becomes visible.
Severity
Findings are recorded with how badly they affect use, so triage is a decision about priority rather than a re-reading exercise.
Build attribution
Every finding belongs to the build it was raised against, so you can see what a given release actually changed.
What a campaign holds
The scope, the testers and the results sit in one record, so nothing has to be reconstructed afterwards.
The fields that matter
- Build under test, so a finding is always attributable to a specific release
- Roster state per tester, with the Google account each one opted in with
- Opt-in date and last activity, tracked as two separate facts
- Findings, with severity and the device and Android version they were raised on
- Testing window, including any day the opted-in count fell short
That set is deliberately small. Each field exists because it answers a question somebody has to answer later, usually in writing.
Plan Your Android Testing Campaign
Tell us what the app does, which devices matter to your users and when you need results. We will shape the campaign around that.