Modelli e processi di User acceptance testing

Vi sono molti aspetti da valutare e considerare nel momento in cui si intraprendono attività di User acceptance testing (Uat). In questo articolo vengono esplorate le modalità che consentono di essere coerenti con i progetti utilizzando modelli (pattern) ripetibili mirati a risolvere un problema o raggiungere un risultato prevedibile. Tali modelli possono essere orientati a risolvere problematiche tipiche di attività Uat fornendo agli utenti metodi di testing adatti anche a audience non tecnici.

 

L’utilizzo di modelli, schemi, disegni prestabiliti è di grande aiuto in molteplici attività. Io, per esempio, ne faccio un grande uso nel mio hobby che consiste in lavori di falegnameria. Credo che più complesso è il progetto, più si abbia l’esigenza di poter disporre di buoni modelli.

I modelli sono utili perché:

Vi sono molti modi per eseguire attività Uat. La cosa essenziale è individuare quelli che possono soddisfare al meglio le proprie esigenze. In molti casi pattern e processi Uat possono essere divisi in due categorie: formali e informali. Non esiste una formula magica per stabilire quanta attività di processo sia corretta per voi, ma credo che sia utile tenere presente quanto segue.

 

Più è la documentazione, minore è la possibilità di utilizzare metodi informali. La documentazione può essere ottenuta attraverso approcci di tipo informale, ma se si devono produrre script test e test plan per attività di testing indipendente, sarà difficile rendere coerente la documentazione a metodi di tipo informale. Si consideri, inoltre, che gli script possono essere utilizzati in attività di formazione, documentazione e altre aree di progetto.

 

Un vantaggio dei test script è fornire un possibile percorso di ripetibilità, un fatto che si dimostra positivo nel momento in cui si vuole pianificare lo scenario in cui verrà effettuato il test. Se esiste una mancanza di conoscenza del processo di business o del sistema, o si vogliono scoprire i difetti invece che confermarne la correttezza, i test informali possono essere la soluzione migliore.

La ripetibilità è necessaria per tre ragioni: 1) essere in grado di confermare

l’insuccesso del software; 2) dire allo sviluppatore cosa si è fatto nel test e 3) essere in grado di testare nuovamente un buco del software.

 

Processi di test formali possono assorbire una certa quantità di tempo, soprattutto quando vengono eseguiti per la prima volta. Se si hanno a disposizione soltanto pochi giorni, un approccio meno formale può essere la soluzione migliore. Vi sono tecniche di session-based testing dove ogni singolo test viene eseguito in una o due ore.

A ogni modo considerate sempre che una buona pianificazione può consentire un risparmio di tempo, riducendo o eliminando la necessità di ricercare i risultati ottenuti dal test. Pensate sempre come se foste una persona che dopo un test debba rispondere alla domanda: «È un bug o una funzionalità?».

 

Una regola fondamentale è scrivere test coerenti con l’audience. Se quest’ultimo deve per esempio conoscere i comandi esatti (come nel caso di una nuova applicazione) dovrete probabilmente fornire test script dettagliati e/o casi di test. Approcci meno formali dipendono invece dalla conoscenza ed esperienza dei collaudatori.

 

Per pianificare test di accettazione si deve avere conoscenza del sistema e del processo di business. Se manca una delle due, dovrete in qualche modo ottenerla per poter creare rapidamente test documentati. Il test esplorativo è un buon modo per imparare e, nello stesso tempo, eseguire attività di testing.

 

Vi sono opinioni divergenti su questo punto, ma io ritengo che più il rischio è alto, più si abbia bisogno di una maggiore definizione. Immaginate di utilizzare un dispositivo medicale a rischio di sicurezza: cosa avreste preferito che si fosse utilizzato nelle attività di testing: un processo di test formale con casi e script che fossero stati revisionati in base ai requisiti o un’attività di testing informale?

 

Credo che per essere un buon collaudatore per una qualunque attività di test del software sia indispensabile pensare in modo critico e creativo. Questo è un requisito essenziale sia per test esplorativi sia per processi di test formali.

 

I processi formali possono presentare delle difficoltà in termini di scalabilità relativamente a un ampio numero di test, soprattutto se devono essere creati ed eseguiti in tempi brevi. I processi informali sono spesso utilizzati quando si deve affrontare un volume elevato di attività senza avere a disposizione molto tempo.

 

Ricordate che il fine di un’attività Uat è la determinazione dell’accettazione del software. Una decisione importante che deve essere presa alla fine del processo dovrebbe essere la seguente: accettiamo il sistema così com’è o vi sono alcune cose che devono essere messe a posto o cambiate? Una cosa è infatti eseguire un test allo scopo di trovare dei difetti, altra cosa è eseguire il test in funzione di una sua accettazione e approvazione.

 

Per test esplorativo si intende un test che viene creato nel momento stesso in cui viene eseguito. È una forma rapida di testing utile quando non si sa molto dell’applicazione che si sta testando. I test esplorativi non sono soluzioni ad hoc o casuali, basate su ipotesi o assunzioni. Possono essere utilizzati soltanto se gestiti in modo corretto e in modo tale che gli utenti abbiano la presunzione di stare eseguendo un vero test.

 

Se nei casi in cui è richiesta agilità è preferibile usare il test esplorativo è bene tenere presente che non sempre questo tipo di test può essere eseguito dagli utenti stessi. Qualche volta si deve infatti ricorrere a un qualche automatismo. In contesti di questo tipo, una vera attività di accettazione del software non deve quindi essere creata soltanto in un’ottica funzionale da parte di tester e sviluppatori.

 

Nella fase di beta testing si chiede agli utenti finali di provare software in pre-produzione per riscontrare possibili problemi. Nonostante questo approccio permetta di riscontrare una serie di difetti, esistono alcuni problemi: 1) non vi è nessuna garanzia che gli utenti testino alcunché, 2) il test può essere debole e 3) gli utenti possono non essere capaci di descrivere cosa è avvenuto e perché si è verificato un certo problema.

 

I processi formali vengono creati per indirizzare la maggior parte delle sfide proprie di un’attività Uat come complessità, ampiezza, scarsità di tempo e forti curve di apprendimento. Potrebbe sembrare che questi processi siano pesanti e time-consuming, ma spesso è vero il contrario. Il processo che utilizzo è stato creato per pianificare, eseguire e valutare velocemente una rigorosa attività di testing. Utilizzando questo processo in molti progetti ho capito che può essere impiegato velocemente e in modo efficace. Pattern e processi Uat strutturati:

Il modello Uat che viene selezionato deve essere coerente con il progetto e le esigenze dell’organizzazione. Il modello Uat strutturato è un metodo efficace e organizzato per creare un test di accettazione basato su processi di business. Questo modello permette a un utente non tecnico di iniziare a comprendere il business e il sistema per creare un rigoroso test di accettazione.