Prospettive, tipi e classificazione del testing software

Classificazione del testing

Il software testing pùo essere classificato in più maniere, di seguito andremo a definirne vari tipi, con punti di vista e granularità differenti.

Prospettive di testing

Le prospettive di testing sono equiparabili a delle scuole di pensiero, e definiscono ad alto livello cosa viene testato e come. Secondo la letteratura, le dividiamo in cinque categorie:

1. Analytic school;
2. Factory school;
3. Quality school;
4. Context-Driven school;
5. Agile school.

La scuola analitica considera i programmi come artefatti logici soggetti alle leggi matematiche, per cui il testing diventa un compito rigoroso, oggettivo e formale. Per poterlo applicare è necessario avere requisiti molto precisi, in modo che coloro che svolgono i test possano assicurarsi che il software vi aderisca, per esempio il requisito “Il tempo di risposta deve essere accettabile da un utente” non è sufficiente per testare in modo analitico, mentre “Il 95% delle risposte deve arrivare entro 30 millisecondi” è decisamente più adatto. La code coverage nasce da questa scuola, in quanto capace di misurare in modo oggettivo la quantità di codice testata.

Con Factory school si intende quell’approccio dove lo sviluppo del software è considerato un progetto e i test un modo per misurare l’andamento dello stesso. Il testing diventa quindi un’attività quasi manageriale e va pianificato, gestito e programmato oltre a verificare che sia cost-effective. Questa scuola è solitamente utilizzata in grossi progetti IT e incoraggia l’utilizzo di bestpractices e l’acquisizione di certificazioni.

Il terzo punto di vista si basa sulla qualità, in questo caso il testing diventa la maniera per assicurarsi che gli sviluppatori stiano seguendo un buon processo di qualità e che non scrivano codice sporco. Solitamente esiste la figura del GateKeeper, cioè colui che controlla il codice e decide se il software sta rispettando i criteri di qualità richiesti. Questo modello viene utilizzato in organizzazioni sotto stress, poichè considerato meno alienante degli altri.

La Context-Driven school vede al suo cardine gli stakeholder, cioè le persone interessate al progetto. Un bug è definito tale solo se pùo risultare un errore per uno stakeholder. Si definisce quindi il contesto del software e si vanno a testare le funzionalità considerando questo contesto, lo stesso potrà poi cambiare durante il progetto, portando il testing ad essere un processo flessibile e adattabile.

L’ultima scuola è quella utilizzata nelle metodologie Agile. Il testing diventa un modo per aiutare il cambiamento e per capire quando una “user-story” (descrizione ad alto livello di una funzionalità utile al raggiungimento di un obiettivo di business) è finita. Questo approccio ha dato alla luce il già citato TDD e si concentra soprattutto sull’utilizzo di framework per automazione del testing. Sta diventando uno degli approcci prevalenti delle aziende IT.

Tipi di testing

Le prospettive di testing danno solo un punto di vista ad alto livello del la materia, di seguito entriamo in maggiore dettaglio definendo molte delle possibili sfaccettature dell’ambito.
I test software possono essere technology-oriented o business-oriented, nel primo caso vengono definiti “prove di verifica” e difatti verificano che il software funzioni dal punto di vista tecnologico in tutti i possibili casi. La seconda categoria definisce le “prove di validazione” che appunto validano il completamento dei requisiti. Si nota come il testing tecnology-oriented si più adatto alla Analytic school, mentre il business-oriented alla Context-Driven e alla Factory. Il testing pùo essere statico, se si effettua a livello del codice, o dinamico,
se si effettua a run-time, al giorno d’oggi quello dinamico è molto più diffuso anche se lo statico non è del tutto scomparso.

Ovviamente un ulteriore divisione sta tra testing manuale e automatico, il primo viene eseguito effettivamente da un essere umano e pùo essere una simulazione d’esecuzione (test monkey) o un ispezione del codice. Il testing automatico, invece, viene svolto da framework o script e quindi senza l’intervento umano, è di gran lunga il più utilizzato e viene considerato il miglior tipo tra i due, poichè introduce meno errori. Inoltre è uno dei cardini dell’Agile school.

Livelli di testing

Definiti questi dettagli bisogna specificare la granularità (scope) del testing, solitamente questi livelli si dividono in:

1. Unit
2. Integration
3. System
4. Acceptance

Lo unit testing comprende le prove che vengono svolte a livello di unità/funzionalità, è il testing di più basso livello e il cardine del TDD. Uno degli strumenti più utilizzati, in ambito Java, è JUnit

L’integration test si ha quando si cercano di testare più funzionalità tra loro interconnesse, per verificare che il comportamento congiunto sia corretto, è quindi il livello superiore allo unit testing. JUnit è utilizzabile anche a questo livello, ma esistono molti altri strumenti, da scegliere in base alle proprie necessità.

Sia il system che l’acceptance testing vengono svolti sull’intero sistema sviluppato, ma in due maniere differenti. Il primo metodo si concentra sulla correttezza tecnologica del software e quindi cerca di verificare che “il prodotto sia costruito nel modo giusto”, perciò si controlla che tutte le parti funzionino come dovrebbero e che rispettino i requisiti non funzionali (sicurezza, performance, etc.).

L’acceptance testing, invece, è in stretta relazione con la Context-Driven school e si basa sui criteri di accettabilità definiti con gli stakeholders, quindi si concentra di più nel “costruire il prodotto giusto” per i clienti. Framework come Cucumber o FitNesse sono adatti a questo tipo prove.

Regression testing

Il regression testing, o testing di regressione, è un particolare tipo di test che normalmente si svolge dopo la messa in produzione del software, il suo scopo è verificare che una modifica al codice non abbia avuto effetti dannosi sul resto del programma. Solitamente il processo di regression testing inizia con la scoperta di un errore nell’applicazione sviluppata, dopo di che avvengono i seguenti passi:

•  Individuazione dell’errore
• Correzione dell’errore
• Run delle test suite a disposizione

A questo punto, se i test hanno dato esito positivo, si procede a creare un test che simuli la situazione di errore appena riscontrata e risolta, in modo da poterlo aggiungere alle suite per il futuro. Successivamente il fix viene rilasciato in produzione. Se, invece, si è generato un fallimento, è presente una regressione, ciò significa che il fix prodotto per correggere l’errore ha provocato danni nel software, facendolo quindi “regredire”. In questo caso è necessario rivedere il codice prodotto, modificandolo in modo da far passare le test suite presenti. Si fa notare che è importante scegliere se eseguire tutte le test suite a disposizione o no, infatti questo potrebbe portare via molto tempo e non essere sempre necessario, soprattutto quando la correzione è strettamente relativa a un solo modulo dell’applicazione.

I regression test vengono quindi svolti durante la manutenzione del software e si differenziano in due tipi in base al genere della stessa. I progressive regression test vengono svolti durante le fasi di manutenzione adattiva o perfettiva e in generale quando è presente una modifica alle specifiche del software. I corrective regression test, invece, sono relativi alla manutenzione correttiva e quindi a quelle modifiche al codice che non ne impattano la struttura interna. Dato che la manutenzione adattativa e perfettiva normalmente avvengono a cadenze regolari, anche i progressive regression test seguono questo andamento, mentre le correzioni devono essere svolte appena si incontra un errore, e quindi non ci sono intervalli fissi per questo tipo di test.

Whitebox vs Blackbox

Durante il testing bisogna scegliere se considerare i componenti del software come delle scatole chiuse di cui non si conoscono i dettagli o, al contrario, concentrarsi anche sull’implementazione interna. Questa scelta, che normalmente viene effettuata a livello di integration o system testing, descrive rispettivamente le categorie di blackbox e whitebox testing. Il blackbox testing viene definito anche testing funzionale, in quanto verifica che tutte le funzionalità diano il giusto risultato agli occhi di un utente esterno, viene largamente utilizzato durante le fasi pre-rilascio di un’applicazione, per verificare che i clienti non possano incontrare errori visibili. Pùo essere automatizzato, ma molto spesso, soprattutto nel caso di system testing, è presente anche una componente manuale, in modo da simulare in modo più accurato le azioni di una
persona.

Nei test a “scatola aperta”, invece, si verificano dettagli strutturali e quindi di più basso livello, come il percorso del flusso di controllo all’interno del codice. Le due tipologie si mescolano spesso a formare un approccio graybox dove si cerca di testare come un utente esterno, ma considerando alcuni dei path interni del codice, questo solitamente avviene durante i primi integration test, quando il codice non è ancora totalmente sviluppato.

Performance testing

Il performance testing è un tipo di prova che permette di valutare le prestazioni di un sistema prima che vada in produzione. Al contrario delle altre categorie di test citate, non si concentra sulle funzionalità, ma su tre aspetti fondamentali:

1. Velocità, cioè il grado di risposta dell’applicazione;
2. Scalabilità, cioè come il programma reagisce alle variazioni nel numero degli utenti;
3. Stabilità, cioè la proprietà che permette di funzionare alla stessa maniera sotto diversi carichi.

Senza performance testing l’applicazione potrebbe avere vari problemi, tra cui: risultare lenta o non funzionare quando molti utenti la utilizzano, avere inconsistenze di velocità tra i vari sistemi operativi e mostrare mancanze di usabilità. Queste caratteristiche impattano molto gli utenti, tanto che i team che ignorano o non svolgono i performance test spesso ottengono prodotti con una cattiva reputazione tra il pubblico, che porta a una diminuzione delle entrate.

Questa categoria di controlli pùo essere divisa in:

1. Load testing
2. Stress testing
3. Endurance testing
4. Spike testing
5. Volume testing
6. Scalability testing

Nei load test si verificano alcune metriche del sistema, come throughput e tempo di risposta medio, sotto i carichi di lavoro previsti, per assicurarsi che l’applicazione resti utilizzabile.

Per stress testing si intendono le prove fatte per monitorare l’andamento del sistema in condizione non usali (attacchi DoS) e quelle per controllare i limiti superiori di sopportazione del sistema.

La terza categoria riguarda i test necessari a verificare che il sistema, sotto il carico previsto, abbia prestazioni normali in modo continuo per un periodo relativamente lungo di tempo.

Lo spike testing comprova se l’applicazione riesce a gestire picchi improvvisi di carico.

I volume test, invece, sono creati per verificare le performance a fronte di variazioni nel volume dei dati gestiti dal programma, essi riguardano soprattutto i database.

Infine, l’ultimo tipo di test permette di capire se il sistema “scala” in modo corretto, in pratica si verifica che riesca a gestire continui aumenti di utenza.