Shift-left e shift-right sono due metodologie complementari che servono a testare la qualità del software.
Shift-left: che cos’è e a che cosa serve
Il test con spostamento incrementale a sinistra è quello più diffuso nell’ambito dello sviluppo di sistemi grandi e complessi con integrazione hardware specifica. La modalità incrementale rende possibile garantire che ogni segmento del programma sia funzionante prima di aggiungere qualsiasi altra cosa.
Più in dettaglio, il test Shift left è progettato per rilevare i problemi nelle prime fasi del ciclo di sviluppo, lasciando tempo a disposizione per le correzioni opportune.
Dal momento che lo sviluppo può essere opportunamente suddiviso in pacchetti separati, gli elementi di un programma possono essere testati da diversi team contemporaneamente. Questo fa si che i test possano essere ulteriormente accelerati e meglio organizzati. Le alternative all’approccio incrementale includono il tradizionale test shift left, Agile / DevOps e il test shift left basato su modello.
Shift-right: che cos’è e a che cosa serve
Il test Shift-right è un metodo per testare continuamente il software in un ambiente di post-produzione e si riferisce allo spostamento del test a destra su una sequenza temporale. Conosciuto anche come “test in produzione“, questo approccio aiuta gli sviluppatori a scoprire scenari inaspettati che potrebbero non essere stati rilevati nell’ambiente di sviluppo.
L’obiettivo del test shift-right è garantire il comportamento, le prestazioni e la disponibilità corretti durante l’uso di produzione di un’applicazione. Come funziona? Questo tipo di approccio mira a incorporare prima possibile i test, con un focus sulla prevenzione dei problemi piuttosto che sul rilevamento. I team di sviluppo software conducono esperimenti controllati verso la fine del ciclo di vita dello sviluppo software (SDLC) per esaminare funzionalità, prestazioni, tolleranza ai guasti e esperienza utente (UX). Il test Shift-right è importante per garantire che un’applicazione funzioni in tutte le circostanze e in tutti gli ambienti, come le diverse opzioni cloud. Inoltre, il test durante la produzione è fondamentale per garantire la qualità del software perché consente un ciclo di feedback continuo da parte degli utenti e l’analisi di casi d’uso che non possono essere anticipati, come arresti anomali, guasti e prestazioni lente.
Shift-left e shift-right per ottenere i migliori risultati
Per i tester spingersi in una direzione o nell’altra può essere destabilizzante ma applicare tecniche di shift-right e shift-left è vantaggioso per garantire la qualità del software. Questa duplice modalità, infatti, funziona sia per lo sviluppo di software a ciclo infinito che per una programmazione che prevede il rilascio di piccoli gruppi di funzionalità.
Uno spostamento a sinistra e uno spostamento a destra ben eseguiti riducono i difetti del prodotto software, velocizzando il ciclo di sviluppo rispetto al relegare il test a una fase dedicata del processo. I test Shift-Left e Shift-Right sono spesso strategie complementari, piuttosto che concorrenti. Tuttavia, ogni approccio comporta rischi, ostacoli da eliminare e contrasti da evitare.
I consigli degli esperti
Le organizzazioni che si occupano di sviluppo software hanno a disposizione diverse tecniche di test per promuovere turni efficaci sia a sinistra che a destra: da unit test automatizzati a flag di funzionalità in produzione. Nel 2020, i relatori della STAREAST Virtual + Testing Conference hanno fatto quadrato per definire alcune linee guida importanti.
Suggerimenti per il test shift-left
Come sottolineano gli esperti, nei modelli SDLC per i professionisti del controllo qualità il test del software è spesso limitato a una singola fase. Effettuare i test in una fase avanzata del ciclo significa che il team rileva la maggior parte dei difetti dopo che gli sviluppatori sono passati a progetti diversi. Bisognerebbe indurre gli ingegneri addetti al controllo qualità a eseguire il maggior numero di valutazioni possibili durante la fase di test per capire cosa possa influire negativamente sia sulla qualità del test che sul programma di rilascio.
Con i test shift-left, le organizzazioni eseguono alcuni test nelle prime fasi del processo di sviluppo per ridurre i colli di bottiglia. Gli sviluppatori portano o consentono agli ingegneri QA di entrare nella stanza il prima possibile, in modo che possano aiutare gli sviluppatori a eseguire valutazioni e test già in fase preliminare. Lo spostamento a sinistra fa risparmiare tempo e denaro alle organizzazioni. L’approccio si traduce in un minor numero di difetti che raggiungono la produzione, dove sono più costosi da affrontare.
“È normale che i team di sviluppo si sentano a corto di tempo e saltino questi test- ha spiegato Matthew Weinstock, direttore della qualità del software presso Align Technology, un fornitore nell’ambito dell’ortodonzia -. Anche le revisioni del codice e la programmazione in coppia possono cadere nel dimenticatoio nella fretta di rispettare una scadenza.
Tuttavia, è molto importante coinvolgere da subito tutti i team, anche quelli addetti al controllo qualità. Con lo shift-left non si tratta solo di testare prima. Spostarsi a sinistra richiede una modalità di comunicazione e collaborazione aperta. Non possono esserci silos tra sviluppatori, tester e altri ruoli. I tester possono persino aiutare gli sviluppatori a scrivere questi test iniziali perché sono loro a avere tutte le domande. Per questo è importante che entrino in gioco prima possibile”.
“Se l’esecuzione dei tuoi unit test richiede due ore, i tuoi sviluppatori non aspetteranno mai i risultati – ha commentato Glenn Buckholz, responsabile tecnico di Coveros, una società di consulenza Agile e DevOps -. I test non possono rallentare lo sviluppo. Più sei a sinistra, più velocemente devono essere fatte le cose. È importante spostare la sicurezza a sinistra nella pipeline dei test continui, promuovendo cicli di feedback di unit test brevi e serrati. Ad esempio, quando gli sviluppatori eseguono il commit e il push del codice, dovrebbero ricevere un feedback immediato automatico. Il team di sviluppo non può eseguire gli unit test manualmente: deve impostare gli unit test per l’attivazione automatica. Uno sviluppatore dovrebbe avere una minima cognizione del fatto che può aver distrutto o meno l’intera applicazione a causa delle modifiche che ha appena apportato”.
“Durante gli eventi e le cerimonie Agile, i membri del team devono discutere ed esaminare a fondo i requisiti, non solo seguire i movimenti – ha aggiunto Weinstock-. Sviluppatori e tester possono rilevare la maggior parte dei bug nel momento in cui prestano molta attenzione ai requisiti. Eventi con un approccio Tre Amigos [modello Agile che combina le prospettive di business, sviluppo e garanzia di qualità per la pianificazione e la valutazione dello sprint ndr] possono aiutare i team a capire dove aumentare la copertura dei test. Con i Tre Amigos si riuniscono lo sviluppatore, il tester, l’analista aziendale o il proprietario del prodotto, a seconda di come è organizzato il gruppo, per discutere le storie degli utenti prima di iniziare qualsiasi lavoro su di essi. Durante questo incontro, lo sviluppatore e il tester determinano quali storie utente sono troppo difficili da sviluppare e suggeriscono approcci alternativi. Il gruppo potrebbe anche scrivere dei test durante la riunione”.
Suggerimenti per il test shift-right
Lo spostamento a destra spinge alcuni test nella fase di post-rilascio. L’unico modo per essere certi che una funzionalità funzioni correttamente anche per gli utenti reali è testarla in produzione. L’obiettivo del test shift-right è proprio quello di individuare i difetti nell’ambiente di produzione e risolverli prima che gli utenti interagiscano con essi. Tuttavia, è rischioso quando il software è live. Alcuni team pensano che i test in un ambiente di staging possano servire come alternativa al passaggio direttamente alla produzione. Altri insistono che un ambiente di staging non possa imitare correttamente i dati o l’utilizzo visto nella produzione.
Lo spostamento a sinistra porta i test nel dominio degli sviluppatori. Lo spostamento a destra entra nell’ambiente di produzione, che è il dominio dell’operatività IT. Si basa su tecniche come i test canary e i flag di funzionalità per rilasciare nuovo codice in produzione e fare un ripristino se qualsiasi modifica non funziona come previsto.
“I team Ops possono proteggere il software live, soprattutto quando sono coinvolte delle transazioni finanziarie – ha affermato Weinstock -. I test shift-right sono sinonimo di DevOps. Pertanto, gli Ops dovrebbero aiutare a eseguire test shift-right perché hanno le giuste competenze operative per implementare strumenti di test, registrazione e monitoraggio che avvisano rapidamente dei problemi di rilascio”.
Per condurre i test delle prestazioni nell’ambiente di produzione, è necessario aspettare tempi di traffico ridotto e prepararsi alle interruzioni. Inoltre, se un’app si integra con terze parti, bisogna condividere anche con loro l’informazione che si sta testando in produzione.
“Molte organizzazioni non si fidano abbastanza di sé stesse per eseguire test in produzione – ha detto Talia Nassi, Developer Advocate in Split Software ma anche keynote speaker di fama internazionale, nel suo intervento Testing in Production – Hanno il timore di causare problemi”.
Quando il test in produzione non è consigliabile, come quando le organizzazioni hanno rigidi standard di sicurezza o conformità dei dati, ci sono soluzioni alternative. I responsabili del QA possono estrarre i dati dalla produzione per utilizzarli nella gestione temporanea ed eseguire così test accurati. In alternativa è possibile creare un ambiente containerizzato per build, utilizzando Docker per avviare i microservizi.
Ecco secondo Nassi, le best practice per testare in produzione:
- Flag di funzionalità o alternanza di funzionalità: un meccanismo mediante il quale gli sviluppatori distribuiscono nuovo codice a un piccolo sottoinsieme di utenti come, ad esempio, solo il personale interno.
- Test canary o implementazioni canary: una strategia di rilascio in cui un team implementa pina piano le modifiche al codice da parte di piccoli gruppi di utenti. Se il nuovo codice presenta difetti, il team ritira le modifiche. In caso contrario, la versione raggiunge in modo incrementale tutti gli utenti.
- Collaboration: collaborare con il proprietario del prodotto per determinare quali caratteristiche o criteri testare in produzione
