Che cos'è il test shift left?

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 nello sviluppo software, ho imparato l'importanza di lavorare a ritroso rispetto a una scadenza. 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 di creazione in tempo per eseguire i test manuali avesse 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 autoesplicativo. In parole semplici, si tratta della pratica di testare le fasi precedenti, coinvolgendo membri del team, inclusi tester, sviluppatori e stakeholder nella strategia di testing. Inoltre, implica integrare più spesso i test sia delle caratteristiche esistenti che di quelle nuove nel ciclo di sviluppo.

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 test di accettazione dell'utente.

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. Queste etichette sono entrambe importanti.

Dobbiamo convalidare che i nostri requisiti utente risolvano 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. La progettazione guidata dal comportamento (BDD) ha portato alla creazione di tecnologie come Cucumber, in grado di automatizzare alcune parti del processo di convalida. Ai fini del presente articolo, ci concentreremo sui test automatizzati a scopo di verifica.

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.

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.

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.

I test dell'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.

Lo shift left non riguarda solo l'automazione. Un altro modo per testare prima e più spesso è assicurarsi che gli specialisti QA siano coinvolti in ogni fase del processo, a partire dalla scoperta e dalla raccolta dei requisiti. Gli ingegneri dei test possono lavorare meglio quando dispongono di 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 e consegna continua. I test continui sono un loop di feedback essenziale in questo ciclo DevOps.

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 contratti. I test API offrono alcuni benefici:

• 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 test dei contratti 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 observability? 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 lo spostamento delle 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:

1. 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.
    

2. 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.
    

3. 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.
    

4. 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.
    

5. 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.
    

6. 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.
    

7. 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.
    

8. Test delle prestazioni: esegui i test delle prestazioni precocemente per identificare potenziali colli di bottiglia e problemi di scalabilità. In questo modo si contribuisce a ottimizzare le prestazioni dell'applicazione e a garantire che soddisfi i criteri di prestazioni richiesti.
    

9. 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.
    

10. 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 beneficio dai cicli di feedback di verifica più brevi dei test shift left.

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.

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.

Così come un software più accessibile è 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.

Migliorare l'esperienza del cliente è il nostro obiettivo. Lo shift left può eliminare alcuni incidenti che gli utenti potrebbero riscontrare e ridurre l'impatto di altri incidenti. Possiamo usare l'observability 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. Questo approccio è un percorso pericoloso.

Testare gli effetti collaterali (quel record è stato 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 observability.

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 observability è il modo perfetto per combinare i vantaggi delle pratiche shift-left e shift-right.