Perchè usare l’automatizzazione della fase di testing in azienda

Perchè usare l’automatizzazione della fase di testing in azienda

Automatizzazione della fase di testing

Nell’ambito dello sviluppo del software, chi sviluppa il codice è in grado di eseguirlo e testarlo continuamente in ambienti production-like, tracciando qualunque modifica in un sistema di version control. Tuttavia, i test eseguiti dai developers in fase di sviluppo, rappresentano una sola delle categorie di testing cui il software viene sottoposto attraversando la pipeline. Solo quando la fase di development viene portata a termine, infatti, il team di controllo qualità eseguirà una seconda fase di testing. Quello che spesso accade, però, è che questa seconda fase venga eseguita tipicamente due o tre volte in un anno, data la scarsa frequenza con cui uno sviluppatore rilascia il suo codice. Si rischia, così, che agli sviluppatori stessi vengano notificati gli errori dopo mesi, annullando i vantaggi intrinsechi della continuous integration.

Una strategia automatizzata per il testing, invece, mira a risolvere il problema, evitando di sprecare una quantità di tempo proporzionale alle linee di codice che vengono aggiunte in fase di sviluppo. Non appena uno sviluppatore esegue un commit, delle suite contenenti migliaia di test vengono eseguite in maniera automatica sul codice modificato. Se tutti i test vengono superati, il codice è già pronto per il deployment in produzione. A partire dal 2013, l’utilizzo del testing automatizzato e della continuous integration ha permesso, in una grande organizzazione come Google, di coordinare migliaia di piccoli team tra loro, tutti impegnati simultaneamente nello sviluppo, integrazione di codice, testing e deployment in produzione. Il loro codice è condiviso in un’unica repository, composta da miliardi di file, in cui il codice viene continuamente compilato e revisionato; circa il 50% di questo codice viene modificato in un solo mese. Per dare un esempio di quanto questo approccio possa essere produttivo, ecco alcune delle loro statistiche:

  • 40 mila commit al giorno
  • 50 mila build giornaliere
  • 120 mila suite utilizzate per il testing automated e 75 milioni di test complessivi
  • Più di 100 mila ingegneri che progettano nuovi tool per la continuous integration e release automation del software, al fine di incrementare la produttività di ogni singolo sviluppatore.

Perchè usare l'automatizzazione della fase di testing in azienda

L’importanza di seguire questo approccio è dunque evidente, visti gli eccellenti risultati. Prima di entrare nei dettagli della continuous delivery pipeline, analizzando il flow di esecuzione delle diverse categorie di test, cerchiamo di descriverle singolarmente, dalla più veloce alla più lenta:

  1. Unit tests: Essi vanno a testare un singolo metodo, classe o funzione, notificando lo sviluppatore circa la correttezza del proprio codice. I test unitari sono scritti e gestiti esclusivamente dallo sviluppatore all’interno della fase di development. Sono la categoria di test più rapida in quanto non interagiscono con alcun’altra componente, quali database o filesystem, che richieda delle chiamate esterne. Ciò implica, d’altro canto, un testing poco dettagliato che si limita a verificare localmente la corretta esecuzione del codice. Nel deployment di applicazioni moderne, le quali comunicano con diversi database oppure scambiano dati di diversa natura con servizi esterni, i test unitari non sono sufficienti da soli a garantire la totale affidabilità del software.
  2. Functional acceptance tests: Essi rispondono alle domande “Come faccio a sapere se ho finito?” degli sviluppatori, e “Ho ottenuto quello che volevo?” dell’utente. A differenza dei test unitari che vanno a validare una singola e isolata parte dell’applicazione, con i test funzionali si dimostra che l’applicazione si comporta come il cliente ha richiesto e non che funziona semplicemente come lo sviluppatore ha programmato.
  3. Integration tests: Sono la tipologia di automated tests meno utilizzata, data la loro elevata complessità e onerosità computazionale. Molto spesso, infatti, dopo la corretta esecuzione dei test funzionali, si preferisce sottoporre l’applicazione alla fase di testing manuale (es. test esplorativi, test sull’interfaccia grafica). Questo perchè non tutto può essere automatizzato: aspetti come l’usabilità, l’aspetto, la percezione, sono difficili da automatizzare ed è per questo che i test manuali devono continuare ad essere utilizzati, seppure in percentuale decrescente.

L’approccio ideale sarebbe quello di eseguire prima i test più veloci, unit tests, e poi quelli che richiedono più tempo, rispettivamente acceptance tests e integration tests. La differenza in termini di velocità di esecuzione tra queste categorie, si riflette anche nella loro capacità di inviare il prima possibile un feedback agli sviluppatori circa gli errori rilevati in fase di testing. Qualora, infatti, lo sviluppatore risolvesse velocemente un bug riscontrato dagli integration tests (o analogamente dagli acceptance tests), dovrà comunque attendere qualche ora prima di capire se esso è stato risolto o meno. Al contrario, se il bug fosse rilevato dai test unitari, il feedback e la risoluzione degli errori sarebbero pressochè immediati.

Sarebbe ideale, dunque, che la maggior parte degli errori venisse rilevata dagli unit tests ma molte volte, la piramide di testing, assume la forma inversa. Una possibile contromisura, può essere quella di creare un nuovo caso di test unitario ogni volta che un errore viene scoperto dalle tipologie di test più lente; si cerca, in questo modo, di allargare la base della piramide non ideale il più possibile, incrementando la copertura degli test più rapidi attraverso una logica di caching degli errori. Al fine, inoltre, di eseguire i test il più velocemente possibile, si potrebbe pensare di eseguirli in parallelo, potenzialmente distribuendoli su diversi server.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *