Come migliorare CI / CD con test shift-left

Il test delle applicazioni era un'attività tecnicamente impegnativa e impegnativa, programmata giorni o settimane prima del rilascio di un'applicazione. I team di sviluppo hanno avuto la possibilità di programmare fino all'undicesima ora, ei tester, che hanno svolto gran parte del loro lavoro manualmente, non hanno avuto altra scelta che accontentarsi del tempo concesso loro. Il risultato è stato che molte applicazioni sono state sottoposte a test inferiori agli standard e i team tecnologici sono stati costretti a rispondere ai problemi di produzione e ai difetti aumentati dagli utenti finali e dai sistemi di monitoraggio delle applicazioni.

Le pratiche di integrazione continua di Devops, i framework di unit test e le pratiche di automazione dei test hanno ribaltato questo paradigma. Invece di eseguire la garanzia della qualità alla fine del processo di sviluppo, molte pratiche di test ora iniziano e vengono eseguite completamente durante la codifica, l'integrazione e la distribuzione. Devops e team agili automatizzano gli script di test e le pipeline CI / CD invitano a eseguire i test durante le fasi di integrazione o consegna del codice. Il risultato netto è che gli sviluppatori vengono avvisati quando le modifiche al codice interrompono la build e possono intraprendere azioni immediate per risolvere il problema segnalato.

L'automazione del test e l'integrazione degli script di test nelle pipeline CI / CD è noto come test shift-left. Ciò implica che nella fase di sviluppo possono essere eseguite più pratiche di garanzia della qualità per rilevare i problemi nelle prime fasi del rilascio. L'automazione dei test è una delle priorità di pre-distribuzione per i team agili e devops che desiderano aumentare le frequenze di distribuzione.

All'introduzione di nuove funzionalità, gli script di test costruiti convalidano le nuove capacità. Questi test possono quindi essere automatizzati e inclusi nei passaggi di compilazione o distribuzione. Invece di chiedere ai tecnici del controllo qualità di eseguire test di regressione alla fine di un processo di rilascio, è possibile eseguire e convalidare molti di questi test come parte dello sviluppo. Questi test si spostano dalla fine del processo di rilascio alle fasi di sviluppo e codifica precedenti.

Il test Shift-left consente ai team agili di impegnarsi per la qualità

Il test Shift-left non solo promuove l'efficienza e migliora la qualità, ma crea anche un cambiamento culturale significativo nel processo di sviluppo agile.

Alcuni team di sviluppo percepiscono la garanzia della qualità e il test come un ostacolo alla consegna del codice alla produzione. Dopo tutto il duro lavoro per soddisfare i proprietari di prodotti agili e completare il codice, i membri del team di controllo qualità identificano un elenco di bug che richiedono rimedio. Se il controllo qualità rileva molti bug, può influire sulla sequenza temporale del rilascio per risolverli. Ancora peggio è quando sezioni significative del codice devono essere riprogettate perché i difetti espongono problemi di logica, sicurezza o prestazioni. In questo scenario, gli sviluppatori e gli ingegneri del controllo qualità possono essere nello stesso team agile ma non agiscono come un team.

Il test Shift-left consente ai team agili di trasferire le responsabilità della qualità all'intero team di sviluppatori e tester. Quando il test viene eseguito come parte della pipeline CI / CD, offre agli sviluppatori una migliore opportunità per risolvere i problemi di qualità nel momento in cui stanno lavorando sul codice pertinente. La pipeline CI / CD avvisa lo sviluppatore della build non riuscita e la maggior parte dei team di sviluppo auto-organizzati richiedono la risoluzione immediata di questi problemi.

Il test Shift-left offre inoltre agli sviluppatori e ai tecnici addetti al controllo qualità l'opportunità di automatizzare una parte maggiore dei test. Una best practice è che i team decidano chi implementa l'automazione in base ai tipi di test richiesti per la funzionalità sviluppata. Ad esempio, gli sviluppatori sono spesso responsabili dell'automazione dei test di unità e API, ma gli ingegneri dell'automazione del controllo di qualità spesso sviluppano test dell'esperienza utente end-to-end e test delle transazioni che simulano chiamate API multistep a più servizi.

Quando applicare il test shift-left

Il test Shift-left funziona meglio per i test atomici a livello di unità che hanno tempi di esecuzione brevi. È essenziale che i test siano automatizzati nella pipeline CI / CD e che vengano eseguiti ogni volta che gli sviluppatori attivano una build, vengano eseguiti rapidamente e non rallentino i processi di build.

Test più complessi e dispendiosi in termini di tempo come test di esperienza utente end-to-end, test delle transazioni, analisi del codice statico e test di sicurezza spesso vengono eseguiti meglio al di fuori delle pipeline CI / CD e su pianificazioni giornaliere o più frequenti. Questi test forniscono ancora un feedback iniziale agli sviluppatori sui problemi di qualità, ma sono automatizzati al di fuori di CI / CD per evitare il rallentamento o il collo di bottiglia nelle build.

Thomas J. Sweet, VP in IT Services presso GM Financial, ha condiviso con me le sue intuizioni personali sui limiti delle strategie di test shift-left. Suggerisce: "Spostare a sinistra è sempre una strategia, tranne quando si eseguono test di integrazione su consegne di fornitori di terze parti, poiché spesso non si ha accesso al loro codice sorgente. Anche quando hai app interne con architetture monolitiche legacy, puoi iniziare applicando criteri di check-in di base che richiedono una revisione del codice e una scansione di sicurezza. Il check-in deve essere rifiutato se la scansione include avvisi e errori essenziali. "

Una potenziale soluzione per i test a valle con i partner di integrazione è implementare la virtualizzazione dei servizi. Questa tecnica consente ai team di sviluppo di simulare la risposta di un sistema a valle a diversi input. Funziona bene quando i sistemi a valle sono ben definiti. Gli strumenti di Micro Focus, Tricentis e altri consentono questa funzionalità.

Rob Pociluk, un esperto responsabile della garanzia della qualità, è un forte sostenitore del test shift-left nello sviluppo agile. "Essere pronti e in grado di testare piccole sezioni di codice mantiene il QA flessibile e aggiornato durante lo svolgimento di uno sprint. I team dovrebbero comunque stare attenti a non usare troppo il tasto Maiusc sinistro in quanto potresti perdere lo scopo del codice stesso ".

Quindi, anche quando i team adottano completamente i test shift-left, ci sono buone ragioni per pianificare ancora una finestra di test su una build con codice completo destinata al rilascio. Assicura che tutti i test automatizzati vengano eseguiti sulla build finale, ma consente anche la pianificazione di test aggiuntivi che richiedono un sistema completamente funzionante.

Uno di questi test è l'UAT (test di accettazione dell'utente), in cui utenti finali selezionati ed esperti in materia convalidano e forniscono feedback. Alcuni UAT possono essere eseguiti durante lo sviluppo, ma potrebbe non essere facile convincere le persone a eseguire questo test frequentemente o quando la funzionalità non è completamente pronta.

Prerequisiti per le strategie di test shift-left

Il test Shift-left è una pratica devops in crescita, ma ha i suoi prerequisiti e investimenti iniziali. Sono necessarie alcune capacità e pratiche essenziali.

  • Sono necessari una capacità di test e ambienti sufficienti per supportare il numero di build e test eseguiti contemporaneamente.
  • I team Agile richiedono un toolkit di prodotti di test che si integrino facilmente nelle pipeline CI / CD e negli strumenti di pianificazione dei lavori e che possano convalidare funzionalità, qualità del codice, sicurezza e prestazioni.
  • Architetti, specialisti di infosec, responsabili del controllo qualità e altri membri senior dell'organizzazione dovrebbero stabilire standard di test e obiettivi a livello di servizio che costituiscono i criteri di accettazione predefiniti.
  • Quando le applicazioni richiedono l'input dell'utente, i team di test necessitano di dati e modelli di test sufficienti per convalidare un numero sufficiente di persone, casi d'uso e modelli di input.
  • All'impegno di sprint o prima, i team di Scrum, inclusi gli ingegneri dell'automazione del test QA, dovrebbero impostare una strategia di test su quali funzionalità vengono testate, quali tipi di test vengono implementati, quali processi di automazione vengono aggiornati e chi sviluppa i test.
  • I team Devops dovrebbero misurare la durata delle esecuzioni della pipeline CI / CD e segnalare quando i passaggi di test automatizzati influiscono sulla produttività. I team Devops spesso richiedono programmi di test aggiuntivi al di fuori delle pipeline CI / CD per eseguire test di lunga durata.
  • I team dovrebbero discutere regolarmente le lacune nei loro test automatizzati, in particolare le convalide che richiedono esperti in materia, UAT o test con i partner. Se i team agili non sono in grado di affrontare queste lacune con l'automazione, i cicli di rilascio dovrebbero tenere conto del sovraccarico per ridurre i rischi e completare questi test.

Infine, i team agili e le organizzazioni devops dovrebbero misurare e discutere regolarmente la copertura dei test. L'impiego di una strategia di test con spostamento a sinistra non funziona se i team di sviluppo e gli ingegneri dell'automazione della qualità non implementano, automatizzano e integrano test sufficienti per rilevare i problemi e affrontare i rischi.

L'accelerazione dei cicli di rilascio o l'abilitazione della distribuzione continua senza un'automazione dei test sufficiente può causare problemi di qualità significativi che degradano l'esperienza per gli utenti finali. I team di sviluppo agile che spingono i rilasci troppo frequentemente si trovano ad affrontare problemi e difetti di produzione invece di investire in una maggiore e migliore automazione.