Il test shift-left è un approccio allo sviluppo del software che sottolinea l'importanza di svolgere le attività di test all'inizio del processo di sviluppo per garantire una migliore qualità del software, una migliore copertura dei test, un feedback continuo e un time-to-market più rapido.
Hai partecipato a un progetto software che ha superato il budget prestabilito e non ha rispettato nessuna scadenza? Certo che sì, è successo a tutti. In effetti, se non ti è mai capitato, allora sei davvero un caso raro mi piacerebbe sapere la tua opinione.
Nelle prime fasi della mia carriera nel software development, ho imparato l'importanza di lavorare a ritroso rispetto a una deadline. Se un progetto deve essere completato entro una certa data e sappiamo che il test richiederà un certo periodo di tempo, allora possiamo usare queste informazioni per tornare indietro e scegliere una data di scadenza per il nostro progetto. Perfetto, vero?
Beh, non proprio. Anche se pianificare la fase creazione in tempo per eseguire i test manuali abbia ridotto un po' lo stress negli ultimi giorni di realizzazione dei progetti, c'erano ancora troppe sorprese.
Completare la creazione in tempo per i test di QA è un'ottima cosa in teoria, ma nella pratica perde utilità non appena viene identificato il primo bug o difetto.
Quanto tempo ci vorrà per risolvere questo difetto? Quanto influirà sulla tempistica? Verranno introdotti nuovi bug? Come faremo a garantire che ogni correzione venga verificata in tempo per correggere tutto ciò che abbiamo compromesso mentre correggevamo il primo problema?
In definitiva, non sono mai riuscito a trovare la giusta quantità di tempo da dedicare al QA. Inevitabilmente, correzioni affrettate venivano combinate all'ultimo minuto; ho imparato a tenere il mio calendario libero per un paio di settimane dopo i lanci più importanti, in modo da poter valutare tutti i problemi che ci sono sfuggiti (o che abbiamo introdotto).
Il problema, in fin dei conti, non era il tempo disponibile per i test, ma piuttosto la tempistica dei test. Avevo bisogno di fare i test prima e più spesso. Avevo bisogno di un test shift-left.
Se immaginiamo il nostro processo di sviluppo software come una linea temporale che scorre da sinistra a destra, allora il "test shift-left" diventa in qualche modo autoesplicativo. In parole povere, si tratta di eseguire test nelle fasi più precoci, coinvolgendo nella strategia di test i membri del team, compresi i tester, gli sviluppatori e gli stakeholder, e integrando i test sia per le funzioni esistenti sia per quelle nuove più spesso nel ciclo di vita dello sviluppo.
Consulta un'analisi dei costi e dei benefici di IBM Robotic Process Automation (RPA).
Leggi una guida all'automazione intelligente
Il modello V è un modo utile per concettualizzare i cicli di sviluppo del software. Se prendiamo il tradizionale flusso a cascata e "capovolgiamo" l'asse Y nella fase di implementazione, otteniamo il modello V.
Un ciclo di sviluppo inizia con requisiti di alto livello. Questi requisiti vengono ridotti a ogni passaggio successivo lungo la “V” fino a raggiungere l’implementazione a livello di codice vera e propria. Verifichiamo quindi l'implementazione, iniziando con i test unitari più granulari e procedendo verso l'alto fino al più astratto user acceptance testing.
In un processo a cascata, l'intero progetto è costituito da una singola "V". Come settore, abbiamo imparato che quando si lascia tutta la convalida alla fine di un progetto complesso, ciò significa sostanzialmente prepararsi al fallimento.
In un processo iterativo, possiamo pensare a ogni sprint o iterazione come a una «V» più piccola Abbiamo teoricamente raggiunto i nostri obiettivi di shift-left: testare prima e più spesso. Problema risolto, giusto? Beh, non proprio.
Avrai notato che ci sono due etichette sul canale di feedback integrato nel modello V: verifica e convalida. Sono entrambe importanti.
Dobbiamo verificare che i nostri requisiti utente risolvano effettivamente i problemi che ci siamo prefissati di risolvere. Dobbiamo anche verificare che la nostra implementazione corrisponda alle specifiche che otteniamo da quei requisiti utente.
I test automatizzati possono essere applicati sia alle convalide che alle verifiche. Il BDD (Behavior Driven Design) ha portato alla creazione di tecnologie come Cucumber in grado di automatizzare alcune parti del processo di validazione. Ai fini del presente articolo, ci concentreremo sui test automatizzati a scopo di verifica.
Test unitario
I test unitari verificano la funzionalità di un modulo specifico all'interno di un'applicazione più ampia. Il modulo viene testato in isolamento e qualsiasi comunicazione con altri processi esterni viene simulata o ignorata. I test unitari e il TDD rappresentano la prima fase di sviluppo dei test shift-left.
Test di integrazione
I test di integrazione cercano di verificare la funzionalità complessiva di un servizio o di un'applicazione, compresi gli effetti collaterali. Questo processo è un anti-pattern per ragioni che discuteremo più avanti.
Test API e "contract testing"
I test API verificano gli endpoint esterni di un singolo servizio. L'ambito dei test API è simile a quello dei test di integrazione. Tuttavia, in un contesto SOA o di microservizi, possiamo pensare ai test API come ai nuovi test unitari.
Test dell'interfaccia utente
I test del'interfaccia utente verificano la funzionalità completa di un'applicazione dal livello dell'interfaccia utente. Strumenti come Selenium rendono ampiamente accessibili i test automatizzati dell'interfaccia utente.
Più di una semplice automazione
Shift-left non riguarda solo l'automazione. Un altro modo per eseguire i test prima e più spesso è assicurarsi che i suoi specialisti del controllo qualità siano coinvolti in ogni fase del suo processo, a cominciare dalla scoperta e dalla raccolta dei requisiti. Gli ingegneri dei test possono lavorare meglio quando hanno una maggiore comprensione dell'implementazione complessiva e i loro insight possono contribuire a rendere l'architettura più trasparente e resiliente.
Quando pensiamo di testare "prima e più spesso" ci viene in mente una certa parola: continuità. Molti (la maggior parte) dei team di sviluppo software praticano una qualche forma di integrazione continua e consegna continua. I test continui sono un loop di feedback essenziale in questo ciclo DevOps.
Controllo continuo
Se pensiamo al TDD come a uno “shift-left per monoliti”, allora il test continuo è uno “shift-left architetture distribuite”.
Il TDD ci ha fatto concentrare sui test unitari. Per i test continui dovremmo concentrarci sui test API e sui contract test. I test API presentano una serie di vantaggi:
I test API possono prevenire uno dei modi più comuni per introdurre errori in un'applicazione di microservizi: la modifica di una dipendenza non sincronizzata con i relativi servizi upstream o downstream.
I test API possono essere di proprietà dello stesso team proprietario del servizio.
I test API evitano la fragilità dei test sugli effetti collaterali e sui dettagli di implementazione.
Idealmente, questi test API verranno eseguiti continuamente sia negli ambienti di produzione che in quelli di pre-produzione. Gli strumenti di contract testing possono aiutare ad automatizzare questo processo, ma ciò richiede un'infrastruttura aggiuntiva.
E se potessimo utilizzare il test continuo delle API integrato nel nostro strumento di osservabilità? La prossima funzione di test API sintetico di Instana ti consentirà di eseguire continuamente test API su tutti i suoi ambienti con il minimo sforzo.
Lo shift-left comporta spostare le attività di test all'inizio del ciclo di vita dello sviluppo del software, consentendo un feedback più rapido e riducendo il tempo e l'impegno necessari per la correzione dei bug. Ecco alcune best practice per il test shift-left nello sviluppo agile:
Coinvolgimento iniziale: le attività di test dovrebbero iniziare il prima possibile nel processo di sviluppo. I tester dovrebbero essere coinvolti fin dalla fase di raccolta dei requisiti per comprendere l'ambito e gli obiettivi del progetto e le aspettative degli utenti.
Collaborazione e comunicazione: promuovi una stretta collaborazione e comunicazione tra sviluppatori, tester e altri stakeholder. Incoraggia stand-up meeting quotidiani, sessioni di pianificazione degli sprint e retrospettive periodiche per garantire una comprensione e un allineamento condivisi.
Automazione dei test: investi nell'automazione dei test per consentire test frequenti ed efficienti. I test automatizzati devono essere creati insieme al processo di sviluppo e integrati nelle pipeline di integrazione e distribuzione continue. Questo aiuta a rilevare precocemente i difetti, a ridurre i problemi di regressione e ad accelerare i cicli di feedback.
Sviluppo basato sui test (TDD): incoraggia la pratica del TDD, in cui gli sviluppatori scrivono casi di test prima di scrivere il codice effettivo. Questo approccio di test shift-left aiuta a definire in anticipo il comportamento desiderato e i risultati attesi, cosa che si traduce in un codice più solido e testabile.
Integrazione continua e distribuzione continua (CI/CD): implementa pipeline CI/CD per automatizzare i processi di compilazione, test e distribuzione. Questa pratica garantisce che ogni modifica al codice sia accuratamente testata e implementata negli ambienti di produzione in modo rapido e frequente, riducendo così il rischio che si verifichino problemi di integrazione.
Test di sicurezza shift-left: prendi in considerazione l'integrazione di pratiche di test di sicurezza nelle prime fasi del processo di sviluppo. Esegui revisioni del codice di sicurezza, analisi statiche del codice e test incentrati sulla sicurezza per identificare le vulnerabilità e affrontarle in modo proattivo.
Test esplorativi: oltre ai test automatizzati, incoraggia l'esecuzione di test esplorativi per esplorare l'applicazione dal punto di vista dell'utente. I tester esperti possono identificare potenziali problemi di usabilità, casi limite e scenari che i test automatizzati potrebbero non notare.
Test delle prestazioni: esegui i test delle prestazioni precocemente per identificare potenziali colli di bottiglia e problemi di scalabilità. Ciò consente di ottimizzare le prestazioni dell'applicazione e di garantire che siano soddisfatti i requisiti prestazionali richiesti.
Ambienti e dati di test: fornisci ambienti di test che assomiglino molto agli ambienti di produzione per garantire test del software realistici. Assicurati inoltre che siano disponibili dati di test sufficienti e rappresentativi per simulare scenari reali.
Apprendimento e miglioramento continui: promuovi una cultura dell'apprendimento e del miglioramento continui. Organizza retrospettive regolari per riflettere sui processi di test, identificare i colli di bottiglia e implementare modifiche per migliorare l'efficacia dei test shift-left.
Implementando queste best practice, i team agili possono ottenere una migliore collaborazione, un feedback più rapido e prodotti software di qualità superiore tramite i test shift-left.
I cicli di feedback più brevi integrati nei processi shift-left ci offrono vari vantaggi: i difetti possono essere individuati più rapidamente, le correzioni possono essere applicate in modo più efficiente e le lezioni apprese in un'iterazione possono essere applicate in quella successiva, solo per citarne alcuni.
Qualunque sia la metodologia di gestione dei progetti o la cadenza di rilascio del tuo team, puoi trarre vantaggio dai cicli di feedback di verifica più brevi dei test shift-left.
Riduzione dei costi
Un difetto rilevato da un test unitario automatizzato sulla macchina locale di uno sviluppatore risulta meno costoso da identificare e risolvere. Ma quando un difetto arriva fino a un ambiente a contatto con i clienti, il costo per risolverlo aumenta.
Benessere degli sviluppatori
Se eseguiti correttamente, i test automatizzati e l'implementazione continua possono fornire la sicurezza di cui gli ingegneri del software hanno bisogno per implementare spesso, anche il venerdì. Individuare i difetti con anticipo significa ridurre i momenti di panico tra tutti gli operatori. Poiché le release sono così indolori, anche correggere i pochi errori che comunque passano inosservati è più rapido e semplice.
Architettura resiliente
Così come un software più accessibile è di solito più facile da usare per tutti noi, un software più testabile può essere più facile da analizzare e mantenere. Pensare di testare in anticipo può portare a una migliore separazione delle preoccupazioni e a un'architettura complessiva più resiliente.
Maggiore qualità complessiva
Migliorare l’esperienza del cliente è il nostro obiettivo finale. Il metodo shift-left può eliminare alcuni incidenti che coinvolgere gli utenti finali e ridurre l'impatto di altri incidenti. Possiamo usare l'osservabilità per completare questo ciclo di feedback e migliorare lo stato di salute generale del nostro software.
Con i potenti strumenti di automazione a nostra disposizione, si può essere tentati di implementare ogni tipo di test su ogni riga di codice. Ma questo è un percorso pericolo.
Testare gli effetti collaterali (quel record è stato effettivamente salvato nel database?) è un'idea interessante. Ma testare i dettagli dell'implementazione è un anti-pattern perché questo tipo di test è estremamente fragile. Potrebbe essere necessario modificare i test ogni volta che si modifica l'applicazione. Anche l'interfaccia utente è un dettaglio di implementazione, quindi i test dell'interfaccia utente si trovano su questa stessa barca.
I test di verifica si preoccupano solo del "cosa", non del "come" o del "perché". Idealmente, i requisiti degli utenti sono stati progettati per convalidare il "perché". Per rispondere alla domanda "come" possiamo fare affidamento su un’automazione più potente sotto forma di piattaforma di osservabilità.
Il test shift-right consiste nel testare più avanti nel processo di sviluppo, di solito in ambienti di produzione. Anche se può sembrare strano, i test shift-left e shift-right sono complementari.
Il test shift-right ci consente di identificare i problemi di produzione prima dei nostri clienti. I cicli di feedback più brevi dei test shift-left ci danno la capacità di rispondere e porre rimedio rapidamente a questi problemi di produzione.
Il test API sintetico come parte della piattaforma di osservabilità è il modo perfetto per combinare i vantaggi delle pratiche shift-left e shift-right.
Esplora come l'osservabilità fornisce visibilità approfondita sulle moderne applicazioni distribuite per consentire un'identificazione e una risoluzione dei problemi più rapide e automatizzate.
Leggi come il test continuo svolge un ruolo cruciale nell'accelerare lo sviluppo del software, nel migliorare la qualità del codice e nell'evitare costosi colli di bottiglia.
Esplora come DevOps accelera la distribuzione di software di qualità superiore combinando e automatizzando il lavoro dei team di sviluppo software e delle operazioni IT.
Scopri tutto ciò che c'è da sapere sul monitoraggio sintetico: cos'è, come usarlo, quali sono le sfide e altro ancora.
Impara come l'applicazione di tecnologie, programmi, robotica o processi possa contribuire a raggiungere risultati con un contributo umano minimo.
Prevedi e previeni i problemi di prestazioni prima che influiscano sulla tua attività con l'application performance management.