Testing software: Regole e criteri per progettare test case

Regole di buona scrittura

In questo articolo sul testing software verranno presentate una serie di regole per la buona scrittura di test (o test case), sia generali che specifiche dei test automatici su web application.

 

1. Nomenclatura

Anche se può sembrare banale è importante dare ad ogni test un nome che abbia senso sia per chi lo scrive che per chi dovrà utilizzarlo in futuro. E’ buona norma dare un nome che rappresenti il modulo, la funzione o l’insieme di funzioni che il test andrà a verificare.

2. Descrizioni

La descrizione del test deve spiegare, più dettagliatamente possibile, che cosa il test andrà a fare, qual è il suo obiettivo, qual è l’ambiente in cui dovrà essere eseguito, quali dati verranno utilizzati, ecc. E’ meglio inserire all’interno della descrizione quante più informazioni possibili.

3. Assunzioni e precondizioni

Si dovrebbero includere nella descrizione del test tutte le assunzioni applicate e ogni precondizione che deve essere soddisfatta prima che il test venga lanciato. Andrebbe specificato se il test è dipendente dalle interazioni con l’utente, dall’ambiente in cui lo si esegue o da eventuali altri test da eseguire prima, dopo o durante il test in questione.

4. Risultati attesi

Un test ben scritto dovrebbe specificare dettagliatamente, ad ogni passo, il risultato atteso. Per esempio se deve apparire una pagina bianca, o uno specifico cambiamento dopo un determinato passo.

5. Copertura

Una caratteristica fondamentale di un buon test è il fatto che debba verificare ogni aspetto della funzione o del modulo in esame. Il test non deve solamente eseguire dei passaggi che simulino il flusso di azioni di un utente, ma deve anche verificare che ogni passaggio restituisca il risultato voluto. Deve cercare quindi di analizzare il modulo o la funzione il più ampiamente possibile.

6. Leggibilità e comprensione

Come in ogni ambito della programmazione, la chiarezza è fondamentale. Bisogna considerare che il test non sarà eseguito solamente da una persona, quindi deve essere di facile comprensione, leggibile e diretto. L’obiettivo è scrivere test semplici e facilmente comprensibili a tutti, che arrivino al punto senza girarci intorno. Nonostante ciò, un test deve comunque coprire tutti gli aspetti del modulo o della funzione che sta verificando, come specificato nella regola 5.

7. Riusabilità

Come per la precedente, questa regola vale per tutta la programmazione in generale. Scrivere test troppo specifici è sicuramente un errore (a meno che non si tratti di unit test); l’idea è quella di scrivere test facilmente riutilizzabili in futuro, riducendo gli sprechi di tempo e facilitando la scrittura dei test successivi.

8. Progettare il test prima di svilupparlo

E’ sempre una buona pratica valutare l’obiettivo e lo scenario del test prima di svilupparlo. Scrivere subito il test rischia di portare lo sviluppatore a concentrarsi solo alla creazione di uno script che dia risultato positivo valutando solamente le condizioni favorevoli e non pensando a differenti scenari possibili. Inoltre, non si deve ridurre lo scope del test solo per fare in modo che funzioni e dia risultato positivo.

9. Rimuovere le incertezze dei test automatici

Una delle caratteristiche principali del testing automatico è l’abilità di dare risultati consistenti, tali da essere certi che qualcosa sia andato storto se il test è fallito.
Se un test automatico passa a un lancio e fallisce al successivo, senza nessuna modifica al software in esame, non saremo mai certi che il fallimento sia causato dall’applicazione o che sia dovuto ad altri fattori.

Quando un test fallisce bisogna analizzare i risultati per capire cosa è andato storto e, quando si hanno molte inconsistenze nei risultati o falsi positivi, il tempo per farlo aumenta notevolmente.
Non bisogna avere timore di cancellare dei test instabili ma, piuttosto, ci si deve concentrare sui risultati consistenti e puliti dei quali poterci fidare.

10. Non affidarsi troppo ai test

Dopo un aggiornamento il risultato positivo di un test automatico potrebbe dare al team di sviluppo una certa sicurezza che il nuovo codice o la modifica non presenti bug. Anche se tutti i test risultassero positivi, non avremmo comunque la certezza che non siano presenti dei difetti. Non bisogna quindi affidarci totalmente ai test automatici; come già detto in precedenza, il testing aiuta nella ricerca di bug ma non ne garantisce l’assenza.

11. Evitare di automatizzare tutti i test

La copertura totale del codice tramite test non è possibile perchè le combinazioni di scenari e azioni è enorme. I test che vengono eseguiti sono sempre un sottoinsieme di tutti quelli possibili. Questo principio è valido anche per i test automatici. Creare un test automatico costa tempo e fatica, necessita di numerose risorse e in alcuni casi, per diverse ragioni, è addirittura impossibile.
E’ però possibile utilizzare un approccio basato sul rischio che determina quali test dovrebbero essere automatizzati. Per raggiungere il massimo valore da un’automazione è bene automatizzare soltanto gli scenari e i casi di maggior valore economico. Inoltre, un alto numero di test automatici aumenta notevolmente i costi e la difficoltà di manutenzione della suite.

Un’altra considerazione da tenere a mente è che non tutti i test possono essere automatizzati. Alcuni test, infatti, hanno una natura troppo complessa, necessitano di troppi controlli e possono risultare inconsistenti. In quei casi è meglio lasciare che il test venga fatto manualmente.

12. Selettori

Per identificare un oggetto all’interno di una pagina web si può ricorrere a diversi metodi. Il più solido è sicuramento utilizzare l’ID o il nome dell’oggetto da selezionare; utilizzare questi parametri è facile, efficiente e incrementa notevolmente prestazioni e leggibilità del codice. In alcune situazioni l’unico modo per raggiungere un elemento è utilizzando il suo XPath; anche se più lento permette di verificare che un elemento sia nella corretta posizione all’interno della gerarchia della pagina. Per raggiungere gli elementi dinamici è sempre meglio utilizzare gli XPath dato che, generalmente, il loro ID o nome viene generato dinamicamente. E’ bene quindi mappare i selettori in variabili dei test, in modo da poterli cambiare nel caso in cui siano fragili o vengano modificati.

13. Attese

E’ fortemente consigliato non utilizzare dei comandi di sleep perchè potrebbero creare dei problemi all’interno del test, a partire dall’aumento del tempo di esecuzione. Quando strettamente necessario è più indicato utilizzare dei wait, o ancora meglio dei fluent wait ovvero delle attese deterministiche che sollevano un’eccezione nel caso in cui l’elemento non venga trovato. La migliore pratica è quella di utilizzare metodi di polling