How we know testing is real
Tester swaps fail when people opt in, grab rewards and vanish. TestersZone's checks run inside Google Cloud Firestore security rules, on the server, where the browser can't skip them.
Server-timed sessions
Before checking in, a tester starts a session whose start time is written by the server, not the phone. The check-in is rejected unless at least 60 seconds have passed, and the session expires after 6 hours.
One check-in per app per day
Each check-in document has a deterministic ID made from app, tester and UTC day. Trying to check in twice for the same day is rejected by the database itself.
In-app verification code
Developers can hide a short code inside their app. The code is stored in a private document that testers can't read. Our rules compare it to what the tester types, so a correct code proves the app was actually opened.
Required written feedback
Every check-in needs a 1-5 rating and at least 20 characters of feedback. Developers read it daily, and copy-paste answers are easy to spot.
Developer moderation
Developers see each tester's Play email, streak and feedback. They can remove anyone who never opted in or fakes check-ins. Removal costs the tester 20 credits and adds a strike.
Strikes & limits
3 strikes lock an account out of new tests. Members can hold at most 8 active tests, which stops "join everything, finish nothing" farming.
Rules-enforced ledger
Credits can only change together with a validated ledger entry in the same atomic write. Balances cannot be edited from the browser, and every movement is visible in your history.
Leaving costs credits
Leaving a test early costs 15 credits and you cannot re-join the same app. That protects developers whose 14-day clock depends on you.
What one check-in has to prove
- 1The tester is signed in and is the owner of this check-in
- 2They joined this app and their seat is still active
- 3They have not already checked in today (UTC)
- 4A server-timed session started 60+ seconds ago (and under 6 h)
- 5Feedback is 20-2000 characters with a 1-5 rating
- 6The in-app code matches, if the developer enabled one
- 7The reward equals exactly the amount for this day number
- 8Their tester progress advances by exactly one day
If any condition fails, the entire write is rejected: no check-in, no credits, no progress.
What we can't see, honestly
A website can't read what happens on someone's phone, and Google doesn't share Play Console opt-in data with third parties. That's why the in-app code and developer verification matter: the developer can confirm in Play Console that each tester's email shows as opted in, and mark them verified on TestersZone. Combined with timed sessions and daily feedback, faking becomes more work than simply testing.
See also: credit rules · keeping testers engaged