Archive

Posts Tagged ‘utente’

Feb
28

Test

Brevi considerazioni, nulla di più. Con alcune parole su questo post intendo focalizzare l’attenzione su tutte quelle attività che, in ambito sviluppo software, vengono gettate in un immenso unico calderone etichettato con le quattro letterine magiche. TEST.

 

Per prima cosa, iniziamo a separare gli ingredienti della minestra. Senza investire troppo tempo, un primo elenco potrebbe essere così strutturato:

 

 

 

test

Test-live time: Sviluppo e verifico quanto ho appena sviluppato. Effettuo una modifica e ne verifico immediatamente le conseguenze, intervenendo se necessario fino al raggiungimento del risultato atteso.

 

Test del requisito: Spesso il progetto censisce diversi requisiti. Se è buona cosa testare live-time quando si sviluppa la singola funzionalità, è un’abitudine altrettanto buona quella di fare un giro di verifica nel momento in cui viene ultimato lo sviluppo di un intero requisito. E ‘ anche un buon momento per fare un backup, o un “commit” del sorgente se si gestiscono i documenti di progetto con un software svn.

 

Test dell’intero prodotto: Ultimati i requisiti, è importante dedicare del tempo all’atività di test del prodotto finito. E’ buona cosa immedesimarsi nell’utente finale, ripercorrere le stesse operazioni uscendo dal ruolo di genitore della soluzione. La cosa migliore sarebbe far testare il prodotto ad una risorsa che non si è direttamente occupata dello sviluppo, così da avere un feedback assai più verosimile. Anche in questo caso, sono naturalmente valide le considerazioni riguardo back-up e svn.

 

Test sulla macchina di produzione: Se non si tratta di un’applicazione web, è assai importante fare delle verifiche sulla macchina che ospiterà il software. Aspetti da non sottovalutare sono: Versione del sistema operativo, versione di eventuali framework coinvolti, versione del database, presenza di librerie per l’integrazione con altri formati (comunemente Excel, a volte Access), risoluzione dello schermo. Visibilità di più pc nella rete, se ad esempio il database si trova su server come spesso accade. Naturalmente le attività di passaggio sono decisamente delicate. Al momento del test si dovrà verificare che tutti gli elementi siano alla versione finale, il database sia aggiornato come struttura e dati, etc…

 

test2Bontà del dato: Se tutti i punti precedenti riguardano principalmente attività tecniche e strutturali, di pari passo è fondamentale non perdere mai l’occhio critico riguardo i dati. Se non si dispone di dati ufficiali, si deve optare per dei dati verosimili. In questo modo si potrà familiarizzare con gli ordini di grandezza attesi, così da poter intercettare errori dovuti a conversioni, unità di misura e quant’altro. Le tabelle popolate con zeri, probabilmente, non sono troppo d’aiuto.

 

Test con l’utente: Se tutte le fasi di test precedentemente citate hanno l’effettiva utilità di evidenziare malfunzionamenti o migliorie, questa ultima fase deve servire esclusivamente alla condivisione di quanto realizzato con l’utente finale. Mischiare questa attività con una delle precedenti può risultare assai poco conveniente.

 

Tutto qui, come “post-it” da attaccare al monitor mi sembra sufficiente! Questa pubblicazione non dirà probabilmente nulla di nuovo, ma un retweet di tanto in tanto non può di sicuro far male.

Dimenticavo, questo breve articolo è stato scritto con una nuova versione del software, e il blog si è da poco spostato su un nuovo dominio di terzo livello. Non prima dei dovuti test :-)

, , , ,