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 online, eccetera. Dietro c’è sempre una verifica e di fatto un tester. Con questo articolo, cercheremo 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 si 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 a 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 a operare ed essi restituiscono informazioni e dati che occorre interpretare in modo corretto.

Fattori che impattano il test del software

Ma quali sono questi fattori? Principalmente quattro.

• Applicare un giusto compromesso fra la verifica “grezza” della singola funzionalità (il test a scatola nera o “black box testing”) e il controllo delle sue singole componenti (test a scatola bianca o “white box testing”), ossia come effettuerà le validazioni. La metodologia applicata (una specifica o entrambe nel caso del 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 se 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 a 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.

Il tuo percorso completo di Analisi dei Dati

Perché è necessario un tester?

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) delle medie e 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 a un atteggiamento mentale di curiosità e aggiornamento continui che portino il soggetto a 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 le vulnerabilità (i famosi bug) possono 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 a una astrazione del gruppo di lavoro la quale, anche se non sembra, molto spesso ha ripercussioni dirette sull’attività di test del software. 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 a 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.