Lasciare il test solo alla fine del progetto può far sì che i problemi emergano in una fase in cui sono ormai interconnessi. Un approccio più utile è discutere il comportamento atteso prima dello sviluppo e verificare le parti completate lungo tutto il percorso. Così il giorno della consegna non è il primo vero giorno di prova.
01Condividere il comportamento atteso
In un'attività, la frase "si farà la schermata dei report" può non significare la stessa cosa per tutti. Quale intervallo di date verrà usato, come apparirà un risultato vuoto, chi potrà esportare il report? Quando le risposte a queste domande vengono trasformate in scenari di test, sviluppatore, designer e cliente possono valutare lo stesso risultato. Una chiarezza anticipata aiuta a ridurre i lavori ripetuti in seguito.
02Testare anche i flussi che falliscono
L'utente può inserire informazioni errate, la sessione può scadere o si può premere di nuovo il pulsante di salvataggio. Il piano di test deve coprire non solo chi segue i passaggi corretti, ma anche queste situazioni. Le informazioni salvate vengono conservate, il messaggio di errore è comprensibile, l'operazione non viene creata per errore due volte? L'affidabilità di un prodotto si vede proprio in questi piccoli momenti.
03Verificare i punti di integrazione tra i team
Quando sviluppatori diversi lavorano in parallelo sullo stesso progetto, non basta che ogni modulo funzioni per conto proprio. Anche le informazioni trasferite da una schermata all'altra, il ruolo utente e il formato dei dati devono essere coerenti. L'ampio team di sviluppo e il team di test professionale di Paradigma7 trattano questi punti di integrazione come parte del piano di consegna. Abbiamo descritto l'assetto di lavoro parallelo nel nostro articolo sul team globale. La velocità non si ottiene eliminando i passaggi di controllo.
04Presentare in modo chiaro la prova di consegna
Il risultato del test non deve consistere solo nella parola "superato". Vanno registrati quale scenario è stato testato in quale versione, l'eventuale impatto di un problema residuo e l'esito del ricontrollo. Così il cliente può vedere quale ambito è stato completato. I test riducono il rischio; tuttavia, invece di promettere che non si verificherà mai alcun errore, offrono qualità visibile e un processo tracciabile. Abbiamo trattato il ruolo della prova di test nel pacchetto di consegna nella nostra guida al software chiavi in mano. In ogni fase del nostro servizio di software su misura il test è presente in questo modo.
05Checklist rapida
- Per ogni compito importante il comportamento atteso è stato trasformato in uno scenario scritto?
- Sono stati testati flussi falliti come dati errati, fine sessione e doppio clic?
- Il trasferimento di dati tra i moduli e i permessi dei ruoli sono stati testati insieme?
- I risultati dei test sono registrati insieme al numero di versione?
- L'impatto dei problemi ancora aperti è stato spiegato al cliente?
Scritto da
Il team Paradigma7
Prodotto, ingegneria e operations
Siamo un team con base a Ankara che sviluppa software per l'Europa. Qui non c'è teoria: sono i processi che usiamo davvero nei progetti dei clienti.
Chi siamo