Per collaudare un software su misura serve un accordo su quali attività devono riuscire, con quali utenti e quali risultati osservabili. Questi sono i criteri di accettazione. Scrivili prima del collaudo: una schermata che si apre o una dimostrazione del fornitore non bastano per decidere se il tuo team può iniziare a lavorare.
La guida a come progettare un gestionale su misura affronta analisi e prima versione. Qui il problema è diverso: trasformare il perimetro concordato in prove e in una decisione di avvio.
In copertina: schermata pubblica reale di Carbonetica Registry dall’archivio portfolio autorizzato. Gli scenari di prova che seguono sono esempi didattici e non risultati di collaudo di quel progetto.
Parti da chi dovrà usare il sistema
Coinvolgi una persona per ciascun ruolo essenziale: chi inserisce la richiesta, chi la approva e chi ne controlla l’esito. Il test di accettazione utente, spesso chiamato UAT, verifica il sistema dal punto di vista di chi deve usarlo. La documentazione ISTQB sull’acceptance testing mette al centro la collaborazione fra chi definisce il bisogno e chi verifica il prodotto.
Una frase come «gestire le richieste» è troppo ampia. Chiedi al referente operativo di descrivere cosa deve vedere alla fine: richiesta salvata una volta, responsabile assegnato, stato visibile e possibilità di ritrovare il record. Le aspettative vanno concordate anche per i casi che devono essere rifiutati.
Trasforma il requisito in una scheda ripetibile
Ecco un esempio fittizio per un portale di richieste interne. Non descrive una funzione già disponibile in un prodotto E-ROE.
- Situazione iniziale: utente del reparto acquisti con una richiesta in bozza.
- Azione: invia la richiesta completa e ripete l’invio dopo un’interruzione della connessione.
- Risultato atteso: esiste una sola richiesta; l’utente può verificarne stato e riferimento.
- Prova conservata: riferimento del caso, versione, esito e schermata priva di dati riservati.
- Responsabile: referente che può confermare il comportamento atteso.
Aggiungi data, dati di prova, risultato effettivo e difetto collegato quando il caso fallisce. Un altro collega dovrebbe poter ripetere la prova senza dover ricostruire una conversazione.
Prova anche permessi ed eccezioni
Un percorso riuscito non copre tutte le condizioni di lavoro. Seleziona le eccezioni in base a frequenza e conseguenze: priorità a ciò che può perdere dati, concedere un accesso improprio o impedire un’attività essenziale.
- Situazione: Campo necessario mancante
Domanda da verificare: Il sistema spiega cosa correggere senza perdere la bozza? - Situazione: Utente senza ruolo di approvazione
Domanda da verificare: Il divieto vale anche provando ad aprire direttamente la funzione? - Situazione: Servizio collegato indisponibile
Domanda da verificare: L’operazione resta riconoscibile e recuperabile? - Situazione: Correzione dopo un difetto
Domanda da verificare: Il percorso corretto e quelli collegati funzionano ancora?
Se il progetto importa dati precedenti, controlla un campione ragionato di record, relazioni e permessi. Non limitarti al numero totale di righe: due archivi con lo stesso numero di record possono contenere associazioni sbagliate.
Prepara un ambiente e dati adatti
Usa dati sintetici o anonimizzati e collegamenti di prova per evitare ordini, email o pagamenti reali involontari. Registra la versione sottoposta a test, la configurazione rilevante e le differenze note rispetto all’ambiente operativo. Una modifica durante il collaudo può rendere necessario ripetere le prove interessate.
La guida Microsoft alla pianificazione dei test, riferita a Dynamics 365, collega i casi di prova ai processi aziendali e alla versione della soluzione. Il principio è utile anche per preparare un collaudo su misura; strumenti e dettagli dipendono dal progetto.
Decidi cosa permette di partire
Concorda prima quali difetti impediscono l’avvio. Per esempio, l’accesso a dati di un altro cliente o un’operazione essenziale che perde informazioni richiedono una correzione e una nuova prova. Un’etichetta poco chiara può avere una priorità diversa, se il team riesce comunque a lavorare e il responsabile accetta il limite.
Il verbale deve identificare prove completate, problemi aperti, responsabili delle correzioni e decisione del referente. I test non dimostrano l’assenza di ogni errore: rendono valutabile il comportamento osservato sul perimetro concordato.
Se stai preparando un gestionale o un portale, porta un processo reale anonimizzato e le sue eccezioni alla valutazione di fattibilità E-ROE. Definire prima come riconoscere un risultato accettabile aiuta a rendere più chiaro anche il preventivo.
