«Mi servono tester» vuol dire tre cose diverse, e chi le confonde trova le persone sbagliate:
| Il lavoro | La domanda | Quanti | Chi |
|---|---|---|---|
| L'adempimento | Google mi lascia pubblicare? | 12, per 14 giorni (solo Google Play, solo alcuni account) | Chiunque abbia un telefono Android |
| Il test d'uso | Le persone riescono a usarla? | 5 per giro, più giri | Persone del tuo pubblico che non ti conoscono |
| La prova di mercato | Serve a qualcuno? Pagherebbe? | 10-20 conversazioni | Chi ha davvero il problema |
Questa guida le prende una alla volta: le regole vere degli store, i numeri della ricerca, dove si trovano le persone, quanto costano i servizi a pagamento. Una cosa da sapere subito: Humatic fa il terzo lavoro, non i primi due, e lo diciamo dove serve. In pagina non ci sono link di affiliazione.
La regola dei 12 tester di Google Play
Se hai un account sviluppatore personale creato dopo il 13 novembre 2023, Google chiede di fare prima un test chiuso con «un minimo di 12 tester, attivi ininterrottamente per almeno 14 giorni». Solo dopo puoi chiedere l'accesso alla produzione, cioè la pubblicazione, rispondendo a un modulo sul test fatto, sull'app e sulla sua idoneità. La revisione richiede «in genere fino a sette giorni» (Google, requisiti per i nuovi account personali).
Tre cose che le pagine che vendono tester non dicono:
- Vale solo per gli account personali nuovi. Un account di un'organizzazione non ha questa regola.
- Il numero è 12, non più 20. Fino a dicembre 2024 erano 20, e c'è ancora chi vende «20 tester».
- Dodici installazioni non sono un test. Gli scambi fra sviluppatori («installa la mia e io installo la tua») risolvono l'adempimento, ma chi installa non è il tuo pubblico: non ti dirà niente di utile su come si usa l'app, né se serve.
TestFlight, per iPhone
Apple non ha una regola dei 12. Con TestFlight (panoramica, tester esterni):
- fino a 100 tester interni, cioè persone del tuo account App Store Connect;
- fino a 10.000 tester esterni per app, invitati per email o con un link pubblico;
- il primo build passa la revisione di Apple, i successivi di solito no; puoi mandarne in revisione fino a sei in 24 ore;
- un build resta provabile 90 giorni;
- chi entra dal link pubblico compare come anonimo: vedi installazioni e crash, non chi è. Se ti serve parlare con chi prova, invitalo per email.
Se è una web app
Nessun negozio, nessuna revisione, nessun numero minimo: mandi un indirizzo. È il modo più rapido per far provare qualcosa, ed è il motivo per cui molte idee conviene provarle prima come pagina web, e solo dopo come app.
Quanti tester servono per i problemi d'uso
La risposta più citata viene da Jakob Nielsen: cinque persone trovano circa l'85% dei problemi d'uso, e il consiglio è di non andare oltre cinque per giro, ma di fare più giri. Con un budget da 15 persone, meglio tre test da cinque che uno da quindici: si corregge dopo ogni giro e il giro successivo trova i problemi nuovi (Nielsen Norman Group).
Due precisazioni che cambiano il conto:
- Il cinque vale per un tipo di utente. Se l'app ha due pubblici molto diversi (chi vende e chi compra, per esempio), servono 3-4 persone per ciascuno.
- Il cinque non è il dodici. I dodici di Google contano installazioni per un adempimento; i cinque di Nielsen trovano problemi. Sono due numeri che rispondono a due domande diverse.
Perché amici e parenti falsano
Sono i primi a cui si chiede, ed è il campione peggiore. Nielsen Norman Group lo dice così: chi viene dalla tua rete personale ha già un rapporto con te e può essere restio a darti un parere negativo onesto (NN/g, reclutamento). Usali per provare che tutto funzioni, non per decidere.
Dove si trovano i tester
- Le persone del tuo pubblico che non ti conoscono. Gruppi online e community dove il problema si discute, chi usa le app concorrenti, associazioni di settore. Si scrive parlando del problema, non dell'app: «cerco persone che hanno difficoltà con…» funziona più di «provi la mia app?».
- Le vetrine per le app in prova. BetaList, una delle più note, oggi è solo a pagamento: «All submissions are paid. There is no free submission option», e chiede un dominio proprio, non un sottodominio gratuito (BetaList, FAQ). Molte guide la danno ancora come gratuita.
- Gli scambi fra sviluppatori. Servono per i 12 di Google, non per altro (vedi sopra).
- I servizi a pagamento, con un loro panel di persone (sotto i prezzi).
Quanto costano i servizi a pagamento
Listini pubblici al 3 ottobre 2026, in dollari:
| Servizio | Cosa vendi | Prezzo |
|---|---|---|
| Userbrain | Test registrati, senza moderatore | 49 $ al mese per 3 tester; 249 $ al mese per 10; 1.100 $ l'anno per 30; 45 $ un tester in più |
| Lookback | Sessioni dal vivo o registrate | 49 $ a partecipante del loro panel; i partecipanti tuoi sono gratis |
| PlaybookUX | Test e interviste | 65 $ a partecipante per un test di 10-15 minuti; 115 $ per un'intervista guidata |
E quanto si paga una persona che ti dà il suo tempo: secondo il rapporto di User Interviews su circa 20.000 progetti, in media 70 dollari per una sessione a distanza sotto i 30 minuti, e per i consumatori sono consigliati 80 dollari l'ora (User Interviews, 2025). Sono cifre del mercato americano: in Italia i compensi sono più bassi, ma l'ordine di grandezza dice una cosa vera, cioè che il tempo delle persone si paga.
Il terzo lavoro: capire se l'app serve
Né i 12 di Google né i 5 di Nielsen ti dicono se qualcuno vuole l'app. Un test d'uso misura se le persone riescono a usarla: una persona può completare ogni compito senza intoppi e non aprirla mai più. Per sapere se serve bisogna parlare con chi ha il problema, di come lo risolve oggi e di quanto gli costa. Come si fa lo spieghiamo nella guida alla lean startup; quali prove contano per chi ti deve finanziare, nella guida alla traction.
Humatic fa questo lavoro: è un panel di persone verificate con il documento d'identità, che non ti conoscono. Ci dici chi vuoi ascoltare e cosa vuoi capire, la nostra AI le intervista in chat, e ricevi la sintesi con le trascrizioni integrali. Chi risponde riceve un buono regalo da 10 a 40 euro, secondo la durata. Non fa i 12 tester di Google e non guarda le persone usare l'app: per quello servono i servizi sopra.
L'ordine che conviene, se l'app non c'è ancora: prima capire se serve, poi costruire il minimo, poi il test d'uso. È lo stesso ordine della guida al vibe coding.
Gli errori che si vedono di più
- Comprare 12 installazioni e chiamarle test. Risolvi Google, non impari niente.
- Un solo test da quindici persone. Tre giri da cinque trovano di più.
- Gli amici come giudici. Ti dicono che è bella.
- Il link pubblico di TestFlight quando vuoi parlare con chi prova. Gli iscritti sono anonimi.
- Testare l'uso prima di sapere se serve. Un'app facile da usare che non serve a nessuno resta un'app che non serve a nessuno.
In breve
Tester vuol dire tre lavori. I 12 per 14 giorni di Google Play sono un adempimento per gli account personali nuovi. I problemi d'uso si trovano con cinque persone del tuo pubblico per giro, più giri. Se l'app serve a qualcuno, invece, non te lo dice nessun tester: te lo dicono le persone che hanno il problema, se le ascolti prima di costruire.
