You find 12 Android developers. Everyone agrees to test everyone else's app.
Problem solved?
Each app has 11 other people available to test it. The owner isn't an extra tester.
I got this wrong in an earlier Dozena post. A reader pushed me to explain the dropout math more clearly. Here's the model I'm building now — including where it can fail.
The group size is not the tester count
Assume each developer brings one app and tests every other app:
| Developers in the group | Other developers per app | Margin above 12 |
|---|---|---|
| 12 | 11 | Below the minimum |
| 13 | 12 | None |
| 15 | 14 | Two |
The formula is simply testers per app = participating developers − 1.
These are potential testers, not confirmed opt-ins. The table only holds if everyone actually joins each relevant test. Fifteen names in a group chat aren't fourteen testers in Play Console.
The calendar matters as much as the headcount
For personal developer accounts created after November 13, 2023, Google's current requirement includes at least 12 testers opted in continuously for 14 days before applying for production access. Meeting that threshold doesn't guarantee approval.
Google's official testing requirements
Consider an app starting with exactly 12 eligible testers:
- Day 1: all 12 opt in.
- Day 9: one opts out.
- Day 9: a new person joins.
- Day 14: the newcomer has not accumulated 14 consecutive days.
The replacement hasn't inherited the departing person's history.
That doesn't mean the remaining testers lose their own history. It means this app no longer has the required twelve people with the necessary continuous opt-in history at that point.
Starting with 14 confirmed testers can absorb two opt-outs if the remaining twelve stay continuously opted in. That's a buffer, not a promise that people won't leave.
Attendance still isn't useful feedback
A counter can't tell you whether onboarding makes sense.
One reader suggested asking for the screen name and what the tester expected to happen. That's much more actionable than collecting “looks good” until a text box reaches its character minimum.
For a testing round, I'd want to know:
- Which flow did you try?
- Where did the result differ from what you expected?
- What changed after the developer fixed it?
The aim is to improve the apps, not just exchange names on a list.
Why I'm building Dozena
Dozena is my attempt to organize this into synchronized rounds of 13–16 developers, targeting 15: a shared setup period, the same testing window, check-ins and private feedback.
It's still in development. The public site explains the format and accepts waitlist signups. I haven't completed a real pilot yet. The MVP will be free and open source.
It won't sell testers, ask for public Play Store ratings or promise Google approval.
If your Android app is approaching closed testing, and you're willing to test other developers' apps too, join the Dozena waitlist.
I'm the developer behind it. The math above is useful whether you use Dozena or organize your own group.
Top comments (0)