L'obiettivo di questo articolo è mettere in luce l'importanza della fase di Test nel ciclo infinito DevOps, passando in rassegna strumenti, framework e metodologie, le diverse tipologie di test e una panoramica dell'ecosistema AWS e dei servizi disponibili per applicare le best practice DevOps e, in particolare, la fase di Test. Non si tratta di un articolo tecnico, ma di una trattazione più generale e divulgativa. Non troverete dettagli tecnici su come configurare una pipeline o distribuire il codice sulla vostra infrastruttura: ci concentreremo sui punti chiave, sulle opzioni disponibili e sui servizi coinvolti.
La fase di Test
Le pratiche DevOps richiedono rilasci software rapidi, con la possibilità di effettuare più deployment al giorno. Per soddisfare questi requisiti, i team devono poter testare il codice in pochi minuti e con la massima frequenza possibile. La fase di Test stabilisce se la build è pronta per passare allo stadio successivo o, in base ai risultati dei test, la blocca senza alcun intervento umano.
Testare il software è un passaggio essenziale del Software Development Life Cycle (SDLC): individuare i bug in anticipo e risolverli prima del rilascio in produzione ha un valore inestimabile. Includere una fase di Test nella pipeline offre l'enorme vantaggio di intercettare i bug esistenti. In questa fase si utilizzano strumenti di testing automatizzato che variano in base all'applicazione. Per esempio, Newman è un modo agile per testare i metodi pubblici delle API; JUnit/Xunit o Jest sono ottimi per gli unit test di codice e componenti, mentre Playwright o Cypress sono ideali per implementare test e2e completi fino al livello UI, qualora l'applicazione sia di tipo Web.
La fase di Test è anche il momento giusto per integrare strumenti di test management come TestRail. Questo strumento genera report dettagliati sul codice e sui risultati dei test, offrendo agli stakeholder visibilità sul ciclo di sviluppo e sulla maturità dell'applicazione. Funzionalità di questo tipo mettono a disposizione degli stakeholder aziendali strumenti di reporting che aiutano a comprendere meglio il ciclo di sviluppo e la maturità dell'applicazione. Un cambio di passo fondamentale è adottare una mentalità in cui la Qualità permea tutta l'Organizzazione e non resta confinata al solo Dipartimento QA. Questo approccio è la chiave per ottenere i migliori risultati, e la fase di Test è il punto di partenza del percorso verso il successo.
Perché la fase di Test è importante
Il vantaggio più rilevante della fase di Test è permettere che testing, validazione della qualità e valutazione delle performance avvengano il più presto possibile nell'SDLC: questa pratica di shift left segna una netta discontinuità rispetto al testing tradizionale o manuale, che si concentra perlopiù alla fine del processo.
Ecco alcuni vantaggi evidenti della fase di Test:
- Implementare i test nelle prime fasi dell'SDLC abilita un processo di testing continuo, che si traduce in un rilascio del software più rapido e costante. Questo approccio favorisce un testing veloce, frequente e anticipato, riducendo il rischio che gli errori passino inosservati.
- L'automazione del testing elimina il fattore umano nel mancato rilevamento degli errori, ma rende necessaria la manutenzione e l'aggiornamento degli scenari di test. Di conseguenza, può essere utile disporre di un team dedicato di sviluppatori specializzati nel testing.
- Ogni fase dell'SDLC prevede forme diverse di testing (unit testing, API testing, e2e e UI testing). In questo modo si riducono al minimo i passi indietro quando viene rilevato un errore.
L'introduzione di questa fase abbassa i tempi di rilascio delle applicazioni e riduce al minimo errori e bug, contribuendo a costruire un modello di responsabilità condivisa sulla qualità in cui l'intero Dipartimento Engineering risponde della qualità dell'app.
La Test Pyramid
La Test Pyramid è un concetto molto noto nello sviluppo software, ripreso in numerosi articoli e pubblicazioni; la descrizione originale si deve però a Mike Cohn nel suo libro Succeeding with Agile. La metafora della piramide aiuta a visualizzare i diversi livelli di testing che dovrebbero essere presenti nello sviluppo software.
I test Behavior-Driven sono i più efficaci, perché incorporano scenari di test e risultati attesi. Questi test partono dal presupposto di coprire l'integrazione tra i componenti, il che rende i test di integrazione i più preziosi: verificano il sistema nel suo complesso o in moduli isolati e complessi, anziché le sole singole unità. Per questo motivo investire nei test UI e2e (eseguiti sul sistema dopo che è stato distribuito e integrato del tutto) può sembrare un'ottima idea, e in effetti lo è. Presenta però anche delle insidie: avere solo test UI e2e, per esempio, può comportare spese sproporzionate, grattacapi di manutenzione e parecchio stress.
Investire esclusivamente nei test UI end-to-end conduce spesso all'anti-pattern del "cono gelato" nella test pyramid, noto anche come piramide di test atipica o capovolta.
La manutenzione di questo cono diventerà un incubo, i costi possono andare fuori controllo, i risultati dei test rischiano di diventare incoerenti e l'organizzazione finirà probabilmente per perdere i benefici di una vera fase di Test.
A questo punto possiamo passare in rassegna i livelli della Test Pyramid, le tipologie di test più diffuse e i benefici di ciascuna.
- Unit Test: i test base e più granulari, focalizzati su una singola unità di lavoro, di norma un metodo o un componente. Si trovano alla base della Test Pyramid e possono essere compilati ed eseguiti già nella fase di Build. Sono semplici da implementare, economici e rappresentano una prima linea di difesa per la qualità del codice.
- Test di integrazione/API Test: l'integrazione passa per le API, quindi testare questo livello è cruciale per i sistemi. Questi test devono validare la capacità del sistema di funzionare in modalità integrata (e quindi verificare che le unità di lavoro possano coesistere e operare insieme). Possono essere implementati dagli sviluppatori o dai professionisti della qualità, a seconda della struttura organizzativa. In fin dei conti, nessuno vorrebbe salire su un aereo testato solo a livello di unit test.
La Test Automation è…
Quando si gestisce una mole di software in continua crescita — o anche solo una base relativamente statica — testare manualmente l'applicazione diventa un'impresa. Garantire che un processo ripetitivo venga eseguito correttamente e ridurre il fattore di errore umano è praticamente impossibile in modalità manuale. Ed è qui che entra in gioco l'Automation: ormai uno standard pressoché ovunque, dall'infrastruttura all'orchestrazione delle build, fino al testing del codice e delle applicazioni.
In pratica, gli sviluppatori si concentreranno sulla scrittura di unit test e test di integrazione come parte dei deliverable o dei task, mentre i professionisti della qualità si dedicheranno ai test UI e2e basati sugli scenari forniti dal business o dai product owner; la fase di test discovery, condotta principalmente con testing manuale, sarà un passaggio preliminare all'Automation.
Per automatizzare la fase di Test si può ricorrere a uno degli strumenti oggi disponibili sul mercato: le possibilità sono pressoché infinite e dipendono soprattutto dalle esigenze e dalle competenze del team di sviluppo. Playwright e Cypress aiutano a centrare gli obiettivi sui test UI e2e: entrambi hanno pro e contro e oggi possono essere usati anche come soluzione "all-in-one" (per testare tutti i livelli della Test Pyramid), per esempio se lo stack è in JS. Un altro livello è quello dell'integrazione, e anche qui la varietà di strumenti è molto ampia: Katalon, Newman by Postman e altri. Valutate sempre le funzionalità tenendo conto di complessità, interoperabilità e capacità di integrazione nella pipeline CI/CD (lo scopo stesso di questi strumenti è infatti poter essere integrati nella fase di Test, ovvero inseriti nella pipeline CI/CD). Ultimo ma non meno importante è il livello degli unit test: per scriverli ed eseguirli occorre scegliere gli strumenti più adatti al proprio codice. Per il codice .Net si può usare XUnit, per Java JUnit, mentre per JS o TS è possibile utilizzare Jest (oppure, come accennato sopra, strumenti moderni e versatili come Playwright: se il codice è in JS o TS, Playwright permette di testare l'intera piramide. Per i dettagli si rimanda alla documentazione ufficiale di Playwright).
AWS CodePipeline per implementare la fase di Test
La fase di Test può essere implementata con diversi strumenti e servizi oggi disponibili sul mercato. Servizi come Jenkins e CircleCI permettono di seguire gli stessi step per ottenere i risultati desiderati: prelevare il codice dal Source code > fare la Build > testarlo > distribuirlo in Pre-Production (Staging) > eventualmente testarlo di nuovo > distribuirlo in Production. Ed ecco fatto: il deployment è completato.
Gli strumenti e i servizi disponibili sono molti, ma soffermiamoci sui servizi AWS. AWS CodePipeline è un servizio di continuous delivery (CD) completamente gestito che aiuta a costruire pipeline, orchestrare le fasi e distribuire aggiornamenti ad applicazione e infrastruttura. AWS CodePipeline si integra alla perfezione con altri servizi DevOps di AWS come AWS CodeDeploy, AWS CodeCommit, AWS CodeBuild, oltre che con noti provider di azioni di terze parti come Jenkins e Github.
Il caso d'uso più semplice per la pipeline è: Pull del codice > Build > Deploy. Sembra lineare e in questo scenario è possibile eseguire solo gli unit test nella fase di Build. Bene! Ma cosa succede se serve una pipeline più articolata, in cui la fase di Test includa anche test di integrazione e perfino test UI e2e? La pipeline diventerà: Pull del codice > Build > Deploy in Staging > Test > Deploy in Prod. La differenza è che, estendendo la pipeline, si introduce la fase di testing che può eseguire test di integrazione e/o UI e2e contro l'ambiente di Staging distribuito nella fase precedente. Decisamente meglio! Aggiungere la fase di Test sarà semplice come inserire un ulteriore step (Stage) dalla pagina di Edit della pipeline esistente e configurare l'esecuzione dei test tramite il framework di testing nativo (a seconda dello strumento utilizzato).
Poiché si tratta di un servizio versatile, capace di interagire con molti altri servizi AWS e di terze parti, è difficile sceglierne uno per fare un esempio; vale però la pena citare alcune funzionalità utili e importanti di AWS CodePipeline:
Detection option: è una proprietà della pipeline che ne avvia l'esecuzione e, in base alla posizione di origine degli artefatti, AWS consiglia di utilizzare i webhook di Github per Github o Amazon CloudWatch Events per gli artefatti memorizzati, ad esempio, in un bucket AWS S3.
Disable/Enable transition: la transition collega le fasi della pipeline ed è abilitata di default. Se per qualche motivo non si desidera passare automaticamente da una fase all'altra, basta disabilitarla con il pulsante "Disable transition", impedendo così l'esecuzione continua della pipeline. Riattivarla è altrettanto semplice.
Add Stage: per modificare la sequenza della pipeline e introdurre una nuova fase oppure rimuovere/aggiornare una fase esistente, occorre cliccare "Edit" sulla pipeline; si verrà reindirizzati alla pagina di Edit, dove è possibile aggiungere azioni alla propria fase in serie o in parallelo rispetto a quelle esistenti. Questa funzionalità rende la pipeline flessibile ed estendibile.
Approval Action: quando si vogliono governare le fasi della pipeline, ad esempio facendo approvare la fase di deploy a una persona specifica, si può ricorrere a questa funzionalità, che mette in pausa la pipeline fino all'approvazione e ne riprende l'esecuzione una volta ottenuta.
Altri servizi DevOps AWS con cui CodePipeline funziona e si integra bene sono:
- AWS CodeCommit
- AWS CodeDeploy
- AWS CodeBuild
Riepilogo e conclusioni
Nessuna pipeline dovrebbe esistere senza una fase di Test, e nessun rilascio dovrebbe avvenire senza una fase di Test. Ridurre al minimo il fattore umano e affidarsi all'automazione e agli strumenti disponibili: è qui che dovrebbe concentrarsi lo specialista DevOps responsabile della CI/CD. E non solo lo specialista DevOps, che con tutta probabilità costruirà la pipeline, ma l'intera organizzazione di sviluppo, inclusi sviluppatori, personale QA e team DevOps. L'approccio corretto è considerare la Qualità una responsabilità di tutti e vedere la fase di Test come un momento accessibile, comodo, flessibile e a prova di errore. L'utilizzo di un servizio adeguato come AWS CodePipeline aiuterà a centrare i risultati desiderati!
Link e risorse: