Una lista dei problemi noti dice ai tester cosa sai già, così spendono il tempo su ciò che non conosci. Riduce le segnalazioni doppie e rende chiaro quali problemi sono accettati per questa build e quali no.
Modello da copiare e incollare
PROBLEMI NOTI: [nome app], build [versione / numero build], [data]
Già noti, non serve segnalarli:
1. [Titolo breve] - [Dove succede]. Soluzione alternativa: [soluzione o "nessuna"]. Stato: [sarà corretto nella build X / accettato per ora].
2. ...
Non ancora pronto, per favore salta:
- [Schermata o funzione] - [una riga sul perché]
Segnala comunque:
- Qualsiasi cosa che si blocchi o perda dati, anche in un'area elencata sopra.
- Un problema noto che si comporta diversamente da come descritto qui.
Come segnalare: [link o canale]. Includi dispositivo, versione del sistema e passaggi.
Esempio (inventato)
PROBLEMI NOTI: Pocket Budget, build 0.9.3 (42), 2026-10-17
Già noti, non serve segnalarli:
1. Modalità scura: le etichette dei grafici sono difficili da leggere nella schermata Statistiche. Soluzione alternativa: usa la modalità chiara. Stato: sarà corretto nella prossima build.
2. L'esportazione CSV è lenta con più di qualche centinaio di voci. Soluzione alternativa: nessuna. Stato: accettato per ora.
Non ancora pronto, per favore salta:
- Impostazioni > Backup - non ancora collegato
Segnala comunque:
- Qualsiasi cosa che si blocchi o perda dati, anche in un'area elencata sopra.
- Un problema noto che si comporta diversamente da come descritto qui.
Come segnalare: rispondi a questo messaggio. Includi dispositivo, versione del sistema e passaggi.
Come adattarla
- Mantienila breve. Se la lista ha più di una decina di voci, i tester smettono di leggerla. Rimuovi i punti risolti a ogni build.
- Indica la build. Una lista senza numero di build è sbagliata già alla release successiva.
- Descrivi i sintomi, non le cause. I tester riconoscono ciò che vedono, non i nomi dei tuoi ticket interni.
- Mantieni le righe "segnala comunque". Altrimenti i tester pensano che un'area elencata sia off limits, e ti sfuggono nuovi crash lì.
- Non nascondere i problemi seri. Un bug che perde dati va nella lista, con un avviso, non taciuto.
- Usala insieme alla build. Invia la lista nello stesso messaggio con cui distribuisci la build, e linkala nelle note di rilascio.
Correlati: checklist go / no-go per il rilascio, checklist per le correzioni urgenti, e l'hub checklist per il test delle app mobile.
Vuoi tester che segnalino in modo strutturato? Inizia gratis.