1. Decidi chi userà la prima versione
Prima di pubblicare, scrivi chi userà il prodotto e cosa potrà fare. Stai invitando cinque persone a una beta oppure aprendo gli abbonamenti a chiunque? Quali dati ti affideranno? Queste risposte aiutano a scegliere le verifiche da fare adesso. Se una funzione non è pronta, puoi anche escluderla dalla prima versione. L’importante è sapere quali operazioni stai rendendo disponibili e quali conseguenze avrebbe un errore per chi le usa.
- Scrivi i tre percorsi che devono funzionare per il primo gruppo di utenti.
- Indica le operazioni con effetti economici o difficili da annullare.
- Definisci chi decide il lancio e chi gestisce eventuali problemi.
2. Prova un’operazione completa
Prendi un'azione concreta, per esempio l'invito di un collega in un gestionale. Segui il percorso dalla schermata al backend, all'email e al database. Quale componente controlla il ruolo di chi invita? Che cosa succede se l'email fallisce dopo che l'invito è stato salvato? Questa lettura trasversale rende visibili decisioni che una review dei singoli file può perdere. Disegna il percorso su una pagina e annota ogni passaggio verso un altro sistema.
- Per ogni passaggio, identifica input, autorizzazione ed effetto prodotto.
- Aggiungi almeno un caso di errore e uno di richiesta ripetuta.
- Segna le parti che nessuno sa ancora spiegare.
3. Controlla i permessi dopo il login
Il login identifica un utente; serve poi decidere a quali risorse può accedere. La guida OWASP sull'autorizzazione raccomanda verifiche coerenti per ogni richiesta e accessi negati quando non esiste una regola che li consenta. Per il tuo prodotto, traduci questo principio in esempi leggibili: un membro può modificare un progetto della propria organizzazione, ma non quello di un'altra. Verifica questi confini anche fuori dalla schermata che normalmente avvia l'operazione.
4. Prova cosa succede dopo un errore
In un ambiente di prova, fai scadere una sessione durante un salvataggio, interrompi un servizio esterno oppure invia la stessa operazione due volte. Guarda il messaggio sullo schermo, poi controlla il database. Il dato è stato salvato? Il pagamento è stato registrato? L’utente può riprovare senza creare un duplicato? Scrivi il risultato di ogni prova. Se non riesci a capire se un’operazione è riuscita o fallita, hai già trovato qualcosa da sistemare prima del lancio.
- Registra il comportamento atteso prima di eseguire il caso.
- Conserva dati di prova ripetibili e privi di informazioni personali reali.
- Aggiungi test mirati alle regole più importanti emerse.
5. Prepara log e procedure di recupero
Dopo il lancio devi sapere dove leggere gli errori e come recuperare da una modifica sbagliata. La guida Google SRE sui lanci include anche dipendenze, capacità e possibili guasti. Per iniziare, prepara istruzioni che tu o un collega possiate seguire: dove trovare i log, come riconoscere la versione online e come ripristinare il servizio o un dato. Provale nell’ambiente adatto prima di averne bisogno. Controlla anche di avere gli accessi necessari, compresi quelli ai servizi esterni.
- Prova le istruzioni di rilascio in un ambiente coerente con la produzione.
- Verifica che un errore significativo sia visibile a chi deve intervenire.
- Controlla la procedura di recupero, includendo gli eventuali file esterni al database.
6. Elenca cosa manca prima del lancio
Raccogli i problemi in un elenco con descrizione, effetto sugli utenti, persona incaricata e prova da ripetere dopo la correzione. Un errore che mostra i dati di un cliente a un altro richiede attenzione prima di un difetto grafico. Per ciò che rimane aperto, decidi se correggere, limitare la funzione o rimandare il lancio. Conserva anche la versione che hai provato: nuove funzioni e modifiche ai permessi possono richiedere di ripetere le verifiche.