Casi e scenari di test

 

casi e scenari di test del software

In questo articolo affronteremo, in maniera breve ma completa, una delle tematiche pratiche più importanti per un tester che ha ripercussioni dirette nella quotidiana attività professionale. Parleremo infatti di casi e scenari di test.

Nell’approcciarsi alle verifiche di una funzionalità, soprattutto se si tratta di controllare non regressioni o nuove funzioni di ampio contenuto, ne è oramai obbligatoria la stesura, sia come detto a fini pratici che, nei contesti modernamente organizzati secondo principi agile, al fine di fornire riscontri formali agli altri enti aziendali.

 

Ma cos’è esattamente un caso di test?

Può essere definito come un insieme di passi attraverso i quali è possibile certificare che tutti i requisiti previsti dalla analisi funzionale o tecnica siano rispettati e che lo siano anche tutti i comportamenti previsti dalle specifiche.

Nella pratica come lo si costruisce? Secondo alcune regole di base che andiamo ad elencare.

1) Ogni passaggio deve essere formalizzato con almeno due condizioni una in cui il requisito è positivo e una in cui è negativo.

2) Ogni requisito deve essere esposto ponendo particolare cura nella attribuzione della sua priorità, intesa come ordine gerarchico di stesura. A tal fine è opportuno esporli con adeguata granularità.

3) Ogni requisito (o condizione) va obbligatoriamente numerato in modo crescente e descritto in formato breve.

4) ogni requisito deve avere almeno un prerequisito.

4.1) Non può essere verificato un requisito (n) se i suoi prerequisiti non sono stati controllati.

4.2) Un requisito (n) può essere testato positivamente se e solo se:

  • tutti i pre-requisiti gerarchicamente a lui superiori, sono soddisfatti;
  • tutte le condizioni che lo compongono sono verificate con esito positivo.

5) Ogni caso e requisito di test deve riportare una descrizione del risultato atteso e del risultato rilevato.

6) Ogni caso e requisito di test deve riportare in modo esplicito il risultato della verifica.

7) Ogni condizione di test deve riportare l’indicazione della data e ora di esecuzione e dell’autore delle verifiche.

8) Il caso di test (inteso come contenitore di almeno due condizioni) deve avere data di esecuzione maggiore o uguale a quella più prossima rispetto alle condizioni componenti e orario di esecuzione ​sempre ​successivo (per convenzione almeno di un minuto). Ciò garantisce che la sequenza cronologica del test sia sempre crescente e che le informazioni condivise nel team e con gli altri enti aziendali siano univoche, chiare e certe.

9) Deve essere sempre espresso il ​grado di tolleranza delle condizioni​ ossia va esplicitato se l’enunciato al punto 4.2 deve essere seguito rigidamente (grado 0) o con intensità crescente (da 1 a 5 dove 5 rappresenta il massimo grado di tolleranza applicabile solo in teoria).

10) I casi di test vanno esposti con una determinata forma (documento word, tabella excel, tabella su database) che non può essere alterata in corso d’opera.

Queste linee guida rispettano i principi teorici formulati per la prima volta nel 2003 (il cosiddetto ​oracolo del test)​: rappresentano sempre e comunque un faro per il tester, ma negli ultimi anni sono state affiancate e in parte sovrapposte ad un altro concetto: lo scenario di test​.

 

Cos’è lo scenario di test?

Lo scenario di test può essere definito come una parte propedeutica ai casi o per meglio dire ad una sua rappresentazione astratta. Per rendere meglio l’idea pensiamo ad un film cinematografico: gli attori recitano un ruolo e compiono delle azioni sul set, rispettando un copione e una sceneggiatura.

Il parallelo è immediato… l’attore è il tester, le azioni e le battute da copione sono i casi e la sceneggiatura è lo scenario.

Quindi lo scenario descrive analiticamente il test e le sue condizioni sotto forma di trattazione ampia e discorsiva. Questa trattazione nella pratica corrisponde alla descrizione particolareggiata delle azioni operative dell’utilizzatore finale.

Da ciò consegue che lo scenario implica sempre un ripetersi di casi a seconda dell’elemento operativo che varia. Si pensi ad esempio al device su cui “gira” il software (apparecchi mobile, PC desktop) o all’ambiente di installazione (fisico o cloud) o ancora alle modalità di installazione (client, server o completa) e a quelle di “​raggiungimento” ​della base dati (da remoto o meno, da terminal server o da macchina virtuale). Tutti questi fattori, sapientemente valutati, portano ad elaborare scenari diversi e casistiche diverse con l’obiettivo di coprire al massimo grado tutte le possibili realtà operative.

Conclusioni

Le realtà aziendali moderne (siano esse piccole, medie o grandi) hanno a cuore che i loro prodotti o servizi abbiano un grado di robustezza e maturità tecnologica sempre crescente. La conoscenza e la stesura di casi e scenari di test innovativi e agili rappresenta un importante fattore di crescita professionale per il singolo e per tutta l’azienda a cui appartiene e permette un posizionamento sul mercato sempre più strategico.

Ecco perché bisogna conoscerli… per innovarsi sempre e perché solo con basi solide si lavora in maniera non improvvisata. Non scordiamolo mai infatti: ciò che facciamo in fase di collaudo è ciò che fa l’utente finale… la nostra soddisfazione sarà anche la sua!

Articoli correlati

Leggi l’articolo successivo sulle doti pratiche di un buon tester.