Test del software automatizzati

Why is testing automation important to continuous delivery?

La continuous delivery (CD) consiste nel fornire nuovi rilasci di codice il più rapidamente possibile ai clienti. I test automatizzati sono fondamentali per questo obiettivo. Non c'è modo di automatizzare la distribuzione agli utenti in presenza di un passaggio manuale molto dispendioso in termini di tempo nell'ambito del processo di distribuzione.

La CD fa parte di una pipeline di distribuzione più ampia. La CD è il successore della continuous integration (CI) e dipende molto da lei. La CI è completamente responsabile dell'esecuzione di test automatizzati rispetto a qualsiasi nuova modifica al codice e della verifica che tali modifiche non interrompano le funzionalità consolidate o introducano nuovi bug. La CD viene attivata quando la fase di continuous integration supera il piano di test automatizzato.

Questa relazione tra test automatizzati, CI e CD offre molti vantaggi per un team di software a velocity elevata. I test automatizzati garantiscono la qualità in ogni fase dello sviluppo, assicurando che i nuovi commit non introducano bug, in modo che il software rimanga sempre pronto per la distribuzione.

1. Test end-to-end

Probabilmente i test più efficienti da implementare sono i test end-to-end (E2E). I test E2E simulano un'esperienza a livello di utente per l'intero stack di un prodotto software. I piani dei test E2E generalmente coprono story a livello di utente come: "un utente può accedere", "un utente può effettuare un deposito", "l'utente può modificare le impostazioni di posta elettronica". Questi test sono molto utili da implementare in quanto offrono la garanzia che gli utenti reali abbiano un'esperienza fluida e priva di bug, anche quando viene eseguito il push di nuovi commit.

Gli strumenti di test E2E acquisiscono e riproducono le azioni degli utenti, quindi i piani di test E2E diventano registrazioni dei flussi chiave dell'esperienza utente. Se un prodotto software non dispone di alcun tipo di code coverage del test automatizzata, otterrà il massimo valore implementando i test E2E dei flussi aziendali più critici. I test E2E possono comportare costi iniziali importanti, per acquisire e registrare la sequenza di flusso dell'utente. Se il prodotto software non esegue rilasci giornalieri rapidi, può essere più economico eseguire manualmente i piani di test E2E.

2. Unit test

Come suggerisce il nome, gli unit test riguardano singole unità di codice. Le unità di codice si misurano meglio nelle definizioni delle funzioni. Uno unit test riguarderà una singola funzione. Gli unit test affermeranno che l'input previsto per una funzione corrisponde all'output previsto. I codici che presentano calcoli sensibili (per quanto riguarda la finanza, l'assistenza sanitaria o il settore aerospaziale) sono coperti meglio dagli unit test, che sono economici e veloci da implementare e offrono un elevato ritorno sull'investimento.

3. Test di integrazione

Spesso un'unità di codice effettua una chiamata esterna verso un servizio di terze parti. La codebase principale in fase di test non avrà accesso al codice di questa utilità di terze parti. I test di integrazione controllano in modo fittizio queste dipendenze di terze parti e affermano che il codice che si interfaccia con esse si comporta come previsto.

I test di integrazione sono simili agli unit test nel modo in cui sono scritti e nella loro strumentazione. I test di integrazione possono essere un'alternativa economica ai test E2E; tuttavia, il ritorno sull'investimento è discutibile quando sono già disponibili combinazioni di unit test ed E2E.

4. Test delle prestazioni

Quando utilizzata nell'ambito dello sviluppo del software, la parola "prestazioni" indica la velocità e la reattività di un progetto software. Alcuni esempi di metriche delle prestazioni sono: "tempo di caricamento della pagina", "tempo di rendering iniziale", "tempo di risposta dei risultati della ricerca". I test delle prestazioni creano misurazioni e asserzioni per questi casi di esempio. I test automatizzati delle prestazioni eseguiranno test case su queste metriche e poi avviseranno il team di eventuali regressioni o perdita di velocità.

Quali tipi di test del software devono essere eseguiti manualmente?

Non è detto che tutti i test automatizzabili debbano essere automatizzati. Ogni automazione comporta l'ottimizzazione della produttività e un aumento dei costi correlati al tempo dedicato a tale automazione. Detto questo, ci sono momenti in cui il ROI derivante dallo sviluppo di una suite di test automatizzata non è vantaggioso rispetto all'esecuzione di un test manuale.

1. Test esplorativi

I test automatizzati sono controllati da script e seguono una sequenza di passaggi per convalidare il comportamento. I test esplorativi sono più casuali e tentano sequenze non controllate da script per trovare bug o comportamenti imprevisti. Sebbene esistano strumenti software per creare una suite di test esplorativi del software, non sono ancora completamente maturi e ampiamente adottati. Può essere molto più efficiente assegnare un tester manuale di controllo di qualità e sfruttare la creatività umana per esplorare come scomporre un prodotto software.

2. Test di regressione visiva

Una regressione visiva si verifica quando viene introdotto un difetto di progettazione visiva nell'interfaccia utente del software. Potrebbero essere elementi dell'interfaccia utente posizionati male, caratteri sbagliati, colori sbagliati o altro. Come per i test esplorativi, sono disponibili strumenti per scrivere test automatizzati per rilevare queste regressioni. Questi strumenti acquisiscono screenshot da vari stati di un prodotto software e quindi utilizzano l'OCR per confrontarli con i risultati attesi. Questi test sono costosi da sviluppare e gli strumenti non sono ampiamente adottati. Può essere molto più efficace aggiungere un passaggio manuale e dare un'occhiata per controllare eventuali problemi visivi.

3. Creazione di un framework di automazione dei test per il tuo team DevOps

Non esiste una soluzione universale per i test automatizzati. Quando pianifichi una soluzione di test automatizzata per il tuo team, è necessario fare alcune considerazioni.

4. Frequenza di rilascio

Per i prodotti software che vengono rilasciati a intervalli fissi, ad esempio mensilmente o settimanalmente, potrebbero essere più adatti i test manuali. I prodotti software che vengono rilasciati più rapidamente trarranno grandi vantaggi dai test automatizzati poiché CI e CD dipendono dai test automatizzati.

5. Strumenti ed ecosistema disponibili

Ogni linguaggio di programmazione ha il proprio ecosistema di strumenti e utilità complementari. Ogni tipo di modello di test automatizzato ha il proprio set di strumenti che possono o meno essere disponibili in un particolare ecosistema di linguaggi di programmazione. L'implementazione corretta di un modello di test automatizzato richiederà un'intersezione tra il linguaggio e il supporto degli strumenti.

6. Adeguamento al mercato del prodotto e scadenza della codebase

Se il tuo team sta lavorando alla creazione di un nuovo prodotto, che non ha ancora un pubblico target o un modello di business comprovato, potrebbe non avere senso investire nei test automatizzati. I test automatizzati fungono da meccanismo assicurativo per limitare regressioni impreviste del codice. Se il tuo team si sta muovendo ad alta velocità, può essere incredibilmente costoso dover aggiornare e mantenere test automatizzati quando il codice continua a cambiare rapidamente

Rendere i test automatizzati parte integrante della pipeline di CD

I test automatizzati sono una pratica standard moderna per lo sviluppo di software. I migliori team e le migliori aziende utilizzano test automatizzati. Le pipeline di CI/CD dipendono dai test automatizzati, che sono fondamentali per aiutare i migliori team a fornire software affidabili e robusti ai propri clienti.

Open DevOps di Atlassian fornisce una piattaforma di toolchain aperta che ti consente di creare una pipeline di sviluppo basata su CD con gli strumenti che preferisci. Dai un'occhiata ai nostri tutorial sui test DevOps per scoprire come Atlassian e gli strumenti di terze parti possono integrare i test nel tuo flusso di lavoro.