Il test del software: cos’è e chi lo fa

test del software

Il test di un’applicazione o di un programma è un’attività fondamentale del ciclo di vita del software, ma molto spesso sottovalutata o sottodimensionata.

Pensiamo a moltissime attività quotidiane oramai usuali  (inviare una mail, fare acquisti on line, ecc.) e automatizzate. Dietro c’è sempre una verifica e di fatto un tester.

Con questo articolo, cercherò di spiegare brevemente cosa vuol dire essere un tester e cosa vuol dire fare testing.

Molto spesso, infatti, quando si entra nel mondo del lavoro o ci si accosta al testing si pensa che per farlo in modo proattivo sia sufficiente conoscere il programma su cui sia andrà a lavorare, affiancati magari da un collaboratore o da un collega per un “training on the job”.

Questo aiuta ,certamente, ma ci sono altri fattori importanti da considerare.

Questi fattori trascendono dal metodo utilizzato nell’approccio effettivo (tradizionale o waterfall, agile, test driven) e contribuiscono ad avere consapevolezza delle validazioni che si vanno ad effettuare e ai risultati incrementali ottenuti.

Non dimentichiamoci, infatti, che  i vari tool automatici di test che le grandi multinazionali distribuiscono devono essere “istruiti” prima di iniziare ad operare ed essi restituiscono informazioni e dati che occorre interpretare in modo corretto.

Ma quali sono questi fattori? Principalmente quattro:

  • Applicare un giusto compromesso fra la “grezza” della singola funzionalità (cd test a scatola nera o “black box testing”) e il controllo delle sue singole componenti (c.d. test a scatola bianca o “white box testing”), ossia come effettuerò le validazioni? La metodologia applicata (una specifica o entrambe, c.d. grey testing) consente, infatti, non solo di velocizzare o rendere più intuibile la percezione dell’errore, ma anche e soprattutto di valutare il grado di copertura dei casi di test e degli scenari.

 

  • Comprendere il significato della “tempificazione” del test, ossia quanto tempo mi costerà?  In sintesi, la tempificazione deve coprire non solo il pieno rispetto della mera data di consegna, ma anche eventuali ritorni alle correzioni delle anomalie trovate più un adeguato numero di ore (o giorni) “polmone” che permettano di gestire eventuali criticità dell’ultimo minuto o richieste spot dell’utilizzatore finale.

 

  • Cercare sempre di tendere “all’astrazione del test”, ossia sapere in ogni momento se ho coperto tutti i casi di test del mio scenario o per meglio dire i casi di test coprono tutte le possibili combinazioni? Ciò significa soprattutto coprire non solo i casi reali, ma anche quelli poco probabili.

 

  • Soprattutto in alcuni ambiti in cui il flusso di dati raggiunge livelli molto alti (banche, assicurazioni, e-commerce su web): capire quando è necessario effettuare quello che in gergo tecnico si chiama “stress test” o “performance test”. Tali verifiche permettono di valutare la risposta dell’applicativo in condizioni critiche di carico (esempio accessi contemporanei ad un sito web, salvataggi contemporanei su una tabella sql, numero di righe visualizzate o paginate)

Tutti questi elementi, che nella realtà si combinano in varie proporzioni, costituiscono la base su cui poggiare il proprio approccio, qualunque sia poi il metodo applicato o utilizzato nella singola realtà aziendale in cui ci si inserisce.

Al termine di questo articolo, un’ultima riflessione: perché è necessario un tester?

In un’epoca come quella attuale, in cui le innovazioni tecnologiche corrono a velocità incredibile, questa figura professionale rappresenta un plus che molte (tutte oserei dire), le medie –grandi aziende cercano, in tutti i settori.

È opportuno quindi che l’attività di test sia efficace e puntuale, ma soprattutto che sia effettuata da persone puntuali.

Non penso solamente al rispetto delle scadenze di consegna, ma ad un atteggiamento mentale di curiosità e aggiornamento continui che portino il soggetto ad una naturale elasticità professionale.

Ecco una caratteristica che il tester deve avere o sviluppare nel tempo: l’andare oltre la specifica o meglio verificarla prevedendo TUTTI i casi in TUTTI gli scenari pertinenti (pensiamo ad esempio ai diversi sistemi operativi o alle caratteristiche dell’hardware su cui l’applicativo sarà installato).

Esperienza insegna, infatti, che una vulnerabilità (c.d. “bug”) può emergere anche in casistiche poco comuni o inserendo ad esempio importi o date differenti da quelle previste

Questi aspetti in taluni ambiti, ad esempio in settori life critical come l’avionico o il sanitario, sono assolutamente obbligatori: la validation è affidata quasi totalmente a tool automatici o script di codice.

Ciò pur essendo assolutamente coerente dal punto di vista prettamente tecnico, può portare anche ad una astrazione del gruppo di lavoro la quale, anche se non sembra, molto spesso ha ripercussioni dirette sull’attività.

Ecco perché (in proporzioni variabili certamente) è opportuno e necessario favorire un clima sereno e ampiamente colloquiale nel team.

In questo modo, infatti, se le esigenze operative lo richiedono, è possibile passare da un approccio basato su step rigorosi e presenza di documentazione scritta ad un approccio agile, in cui prediligere il confronto one to one fra i vari collaboratori ed eventualmente anche con l’utilizzatore finale, perseguendo quindi l’obiettivo: distribuire software di qualità con una percentuale di errore significativamente bassa in relazione alle scale di tolleranza previste.