Nel mondo dello sviluppo del software, l’argomento del testing automation è un argomento sempre molto dibattuto, da un lato perché tutti ne riconoscono l’importanza, dall’altro perché in pochi li adottano.
Software tester succeed
where others fail!
Più passa il tempo comunque e più mi accorgo di quanto complesso sia questo settore, ho scritto personalmente test per moltissimi software, ma non ostante ciò ho sempre cosa nuove da imparare in questo mondo.
Cosa sono i test e a cosa servono?
Sviluppiamo software personalizzato per aziende, e siamo quindi giornalmente di fronte a richieste di modifiche, correzioni all’ultimo momento, features che era sfuggite e richieste di qualsiasi genere.
Sappiamo bene che ogni volta che si mette mano ad un codice sorgente, c’è sempre una possibilità, se pur piccola, che la modifica possa impattare in altre aree del software e quindi renderlo inutilizzabile causando i famosi bug di regressione.
Il testing automation è una pratica che permette di evitare tali problematiche e di far si che tali errori non si verifichino. Lo scopo principale dei test è quello di ridurre al minimo il numero di bug nel software ma soprattutto di assicurarsi che vecchi bug già risolti rimangano tali.
Scrivere test per il software è come scrivere un piccolo programma parallelo che ad ogni modifica del codice sorgente controlla al posto nostro che tutto continui a funzionare.
Esistono diverse tipologie di test (unitari, funzionali, di integrazione, di stress, di performance, ecc…), spesso descritti con il disegno di una piramide come questa che li racchiude in vari livelli:
Lo scopo di questa guida non è quello di essere un manuale per la scrittura di test, per i quali vi consiglio di leggere documentazione specifica, ma grazie all’immagine sopra è quello di fissare il fatto che: esistono diversi tipi test per il software che appartengono a livelli differenti, non è mai escluso l’utilizzo finale di test manuale, più la piramide si restringe, più tempo è richiesto per l’esecuzione e la scrittura di test.
Chi dovrebbe scrivere i test sul software?
Partendo dalla parte bassa della piramide, dovrebbe essere il programmatore a scrivere test unitari ogni volta che implementa una nuova funziona, anzi, nella migliore delle ipotesi sarebbe più corretto seguire una programmazione TDD (Test Driven Development) in cui il test viene scritto ancora prima del codice. A seconda poi delle dimensioni dell’azienda di software, potrebbero anche esserci figurate specifiche che scrivono solamente test per i livelli più alti della piramide.
Devo sempre testare il mio software?
Per questo punti si potrebbe aprire un dibattito infinito, diverse sono le scuole di pensiero in merito all’argomento, c’è chi afferma che i test sono uno spreco troppo grande di tempo e soldi, c’è chi sostiene che solo le parti critiche andrebbero testate, chi sostiene che la code coverage (ovvero la percentuale di codice coperto da test) debba essere al 100% e cosi via.
Personalmente credo che in ognuna delle affermazioni sopra ci siano fondi di verità e di cose non vere, credo personalmente che seppur richiedano uno sforzo, maggiore è la quantità di test nel codice e minore sarà la possibilità che il tuo telefono squilli di notte perché il software ha smesso di funzionare. Questo è vero a patto che i test siano sensati, e non messi li giusto per aumentare la percentuale di coverage.
Se commissiono un software ad un azienda, devo sempre richiedere i test?
Come già detto in precedenza, ribadisco ancora, rischiando di essere ripetitivo che scrivere i test equivale a scrivere un programma parallelo, che richiede quindi tempo e costi.
Una domanda che facciamo porre di solito agli imprenditori che ci commissionano la realizzazione di un software, nel momento in cui va scelto se creare o meno i test è:
Se il tuo software smettesse di funzionare a causa di un aggiornamento errato, quanto sarebbe grave per te? che danno ti arrecherebbe?
Se la risposta alla domanda seguente è: “Niente di preoccupante, posso tranquillamente aspettare che venga sistemato”, allora potresti anche optare per avere un codice sorgente non testato. Se invece la risposta è: “Sarebbe un problema per me e per la mia azienda” in questo caso ti consigliamo l’adozione del testing automation.
Le statistiche comunque dimostrano che nel lungo termine, paga comunque molto di più, in termini economici, spendere un pò più inizialmente per vivere tranquillamente durante il flusso di vita del software.
Tutte le aziende sono in grado di fare software corredato da test?
Purtroppo la risposta è NO, come non tutti i cuochi sanno fare cucine da stelle Michelin. Avere un software enterprise di alto livello, richiede un azienda con ottime competenze in materia. Se vuoi realizzare un software o vuoi analizzare la situazione del tuo software attuale puoi contattarci e saremo Felici di discuterne insieme a te.
RIFERIMENTI: