Indipendentemente dal proprio settore imprenditoriale, oggi ogni organizzazione deve diventare anche una ‘software company’. Tutte le imprese, infatti, hanno l’esigenza di fornire in modo tempestivo soluzioni IT moderne ed efficienti, quando queste vengono richieste dai responsabili del business, o dai clienti. Riuscire a fare ciò però implica la capacità di sfruttare le metodologie Agile/DevOps e utilizzare tecnologie di automazione più intelligenti, oltre che soluzioni ‘as-a-service’ per erogare i servizi IT in modo più rapido e con maggior flessibilità.
A delineare questi trend nel mondo del software è il Continuous Testing Report 2019 (CTR 2019), realizzato da Capgemini, Sogeti e dalla Enterprise Software Division di Broadcom. Ancora sul versante delle sfide, il rapporto traccia un quadro di sempre maggiore complessità: cresce la dipendenza dalle soluzioni IT; la necessità d’integrazione tra le app di front-office, che fanno da interfaccia con i consumatori, e i sistemi di back-end; cresce l’uso del cloud e dei microservizi. E cresce l’integrazione con le applicazioni IoT, senza poi contare l’emergere dell’intelligenza artificiale (AI), come tecnologia destinata a rendere queste soluzioni autonome e capaci di autoapprendimento.
Testing, collo di bottiglia principale
Il rapporto, basato sulle risposte di 500 decisori aziendali con funzioni di gestione IT a livello corporate in aziende private e pubbliche di otto paesi (Stati Uniti, Regno Unito, Benelux, Germania, Paesi Nordici, Francia, Italia, Canada), rivela che le organizzazioni comprendono i benefici del continuous testing, ma faticano ad adottarlo. Qualche grado di automazione del testing esiste nelle attività di collaudo che fanno parte del ciclo di sviluppo software. E il tasso di nuove implementazioni in genere sta crescendo: il 58% dei rispondenti alla survey afferma di fare implementazioni giornalmente, o anche più frequentemente. Ma il testing continua a restare il principale collo di bottiglia per fornire ai clienti software dotato di nuove funzionalità, con la velocità, il volume e la qualità desiderati. Ciò accade, ad esempio, perché si impiega una grande quantità di tempo per la manutenzione di ambienti di test che, adottando gli odierni metodi di testing, potrebbe essere automatizzata. Invece, in media, si spende fino al 47% del tempo per costruire, gestire, manutenere e dismettere tali ambienti.
Lo scenario sull’automazione del test è poi ancora frammentato, e manca di orchestrazione. Il CTR 2019 rivela gap significativi nell’automazione, che rallentano l’intero processo: in media solo il 25% dei dati di test è generato usando tool, e solo il 24% dei test case per le prestazioni è eseguito usando strumenti di automazione del test.
Il CTR 2019 analizza anche alcuni dei principali trend in differenti aree del continuous testing, evidenziando sfide, lacune, e indicando alcune misure che le organizzazioni possono adottare, da subito, per migliorare la situazione.
Progettazione dei test, tre aspetti da ottimizzare
Progettare un test significa creare, scrivere e aggiornare i test case in funzione dei cambiamenti nei requisiti, e ciò, indicano i risultati della survey, crea alle imprese almeno tre tipi di sfide.
Migliore gestione dei requisiti. Il 40% dei rispondenti riporta che l’attuale approccio alla raccolta, analisi e ingegnerizzazione dei requisiti di test non è automatizzato. Alcuni usano strumenti di raccolta rudimentali in modalità stand-alone, mentre altri si avvalgono di carta, lavagne, o software di videoscrittura. Quando si domanda a quale livello il testing è considerato o incorporato nella fase di definizione dei requisiti e di change management, il 62% risponde che, sebbene i requisiti chiave dell’applicazione vengano evidenziati, il design e lo sviluppo del test case completo resta una funzione separata. Alcuni riportano in modo molto esplicito che il testing non è stato mai incorporato nel processo di definizione dei requisiti.
Copertura adeguata dei requisiti. Negli ambienti Agile/DevOps dove i requisiti cambiano frequentemente, mantenere adeguata la loro copertura è cruciale: ma il 67% afferma che “mantenere una corretta copertura del test, mentre i requisiti cambiano, è una grossa sfida”. Un 56% riporta che “si finisce generalmente per avere molti più test case di quelli necessari, con molte sovrapposizioni e ridondanza”.
Uso di automazione intelligente. Oggi diventa impraticabile procedere ancora con la creazione manuale di test in contesti complessi, dove una singola applicazione può risultare connessa a migliaia di altri sistemi nell’impresa, microservizi, dispositivi IoT, che rendono difficile comprendere in toto lo scopo del testing richiesto. Serve dunque una piattaforma di test automation in grado di generare la massima copertura usando il minor numero di test case.
Tra le raccomandazioni, il report suggerisce l’adozione di tecniche di ‘model-based testing’ (MTB), che consentono ai team di collaborare per ottenere una completa comprensione del comportamento atteso per un sistema, e di modificare il modello a seconda dei requisiti. Nei prossimi anni tecniche di progettazione dei test come queste si diffonderanno, assieme a un maggior utilizzo di intelligenza artificiale (AI) e machine learning (ML) per migliorare la copertura e ridurre i tempi di testing.
Testing funzionale e prestazionale: ecco come i paradigmi cloud e DevOps lo trasformano
Nelle organizzazioni che applicano le metodologie DevOps e Agile, gli sviluppatori lavorano a stretto contatto con i team del business per migliorare la ‘user experience’ (UX), e anche i tester devono abbandonare la mentalità legata al tradizionale modello ‘waterfall’, per diventare parte di questi agili e veloci gruppi di lavoro. Tuttavia, per lavorare liberamente, gli sviluppatori necessitano di una robusta infrastruttura in grado di supportarli, e ciò include anche la libertà di scegliere il set di strumenti: quando si domanda quali sono i componenti critici (figura 3) che i team Agile cercano per modernizzare le metodologie di esecuzione dei test di carico e prestazioni, il 31% risponde che l’abilità di supportare i popolari framework open source è un “must-have”, mentre il 48% li ritiene un “nice to have”. In effetti, tali framework permettono agli sviluppatori di sentirsi parte di una community, e accedere ai tool richiesti semplicemente scaricandoli dalla piattaforma. In aggiunta, oggi, sviluppatori e aziende stanno rivolgendosi in modo crescente verso le soluzioni PaaS (platform-as-a-service) cloud-based per impostare gli ambienti di test: questo perché le piattaforme PaaS sono in grado di gestire elevati carichi di utenti virtuali a costo ragionevole, e di scalarli verso l’alto o verso il basso, quasi istantaneamente, a seconda dei requisiti.
I tester lavorano in parallelo con gli sviluppatori e i team del business, e sono coinvolti molto prima nel ciclo di sviluppo del software, per comprenderne i requisiti, la progettazione, l’architettura, la codifica, le funzionalità. In aggiunta, per mandare a buon fine il test funzionale e prestazionale, i tester devono focalizzarsi subito sull’analisi delle cause che creano i colli di bottiglia: ad esempio, se un sito web è lento nel caricare immagini o video, essi devono valutare la banda, la latenza, la piattaforma su cui tali dati vengono salvati. A proposito di test di carico e prestazioni, il 32% dei rispondenti alla survey dichiara che in tale area, nella propria azienda, viene fatto poco o nulla. Gli esperti ritengono che la causa sia l’insufficiente allocazione di budget per il performance testing nelle prime fasi del progetto.
Gestione dei dati di test: troppo tempo perso nelle attività di TDM
Regolamenti come GDPR, i crescenti problemi di sicurezza, privacy dei dati, e l’aumento della disponibilità di vari strumenti commerciali per la gestione dei dati di collaudo, accentuano l’importanza del tema test data management (TDM) come leva per ridurre uno dei principali colli di bottiglia che ostacola il raggiungimento del modello di continuous testing in DevOps. Il 55% dei rispondenti sta attualmente spendendo tra il 30 e il 60% del proprio tempo totale di testing nelle attività TDM (figura 4): questa è un’eccessiva quantità di tempo, e, spiega la survey, molte organizzazioni ora comprendono che indirizzare tale area potrà migliorare in modo notevole la velocità e l’efficienza dell’intero ciclo di sviluppo software.
Tre sono le sfide principali sui dati di test (figura 5): la prima, come indicato dal 33% dei rispondenti, è costituita dalla difficoltà e dal tempo impiegati per l’estrazione dei dati, distribuiti in molteplici database; la seconda sfida, per il 28%, è che i team di testing hanno accesso limitato (come del resto è giusto che sia, per sistemi ‘business critical’, ndr.) ai sistemi di produzione, e dipendono dagli amministratori di database per ottenere i dati di cui hanno bisogno. La terza sfida, riportata dal 27%, è dover manutenere molteplici versioni dei set di dati di test per differenti tipologie di collaudo.
Di fronte a tali sfide, il rapporto raccomanda di standardizzare i tool e il processo di TDM, creando un team centralizzato, per gestire il provisioning dei dati di test per tutti i team del progetto: in questo modo, è possibile tenere traccia dei dati di test richiesti dai diversi team e recuperare efficienza.
Se si sta utilizzando un tool TDM sviluppato internamente, è bene analizzare quali limitazioni presenta, ed esaminare le soluzioni TDM sul mercato, definendo le proprie priorità sui dati di test e cercando gli strumenti che soddisfano le esigenze attuali e future. Una volta adottati i tool TDM commerciali appropriati, va creato il team di supporto per i dati di test: è preferibile partire con un singolo team o processo, e implementare la soluzione selezionata, che può essere poi estesa all’intera organizzazione, non prima però di aver acquisito la competenza necessaria.
Gestione dell’ambiente di test, servono team centralizzati, cloud e virtualizzazione
La mancanza di appropriati ambienti di test, assieme alle difficoltà legate al reperimento dei dati di collaudo, appena illustrate, costituiscono il maggior collo di bottiglia per l’implementazione ed evoluzione del continuous testing (figura 6). Il problema esiste perché l’adozione dei modelli Agile/DevOps ha portato alla formazione di singoli team di progetto che svolgono attività di sviluppo, testing e integrazione in parallelo: e questi flussi di lavoro paralleli necessitano di un gran numero di ambienti in momenti diversi. In effetti, oggi le organizzazioni stanno lottando per rispondere a questa esigenza, perché raramente possiedono ambienti di test ‘end-to-end’.
Uno degli ostacoli principali è la mancanza di procedure centralizzate, in ambienti dove i differenti team di progetto definiscono i propri standard e decidono i tool e l’infrastruttura. Alla domanda sulla percentuale del tempo allocato per costruire, gestire, manutenere e dismettere gli ambienti di test, ben il 40% dei rispondenti dichiara di aver speso più del 50% del proprio tempo nel fare ciò. Per ridurre questo tempo, le organizzazioni si rivolgono agli strumenti di automazione. Tuttavia, questi ultimi richiedono tempo per apprenderne l’uso, e molte organizzazioni stanno ancora lottando per sincronizzare i processi tra diversi team di progetto. Ecco perché gli esperti stanno ora suggerendo la creazione di team centralizzati per la selezione e adozione dei tool. Il tempo viene chiamato ancora in causa quando si chiede quali sono le sfide connesse agli ambienti di test che hanno impedito di migliorare il ciclo di sviluppo software: il 36% dei rispondenti punta il dito sui “tempi di attesa e costi per il provisioning degli ambienti”. Anche alla domanda su quali sono i vincoli legati all’ambiente di test che hanno avuto maggior impatto in termini di limitazioni del testing, il 28% risponde i “vincoli di programmazione”, seguito da un 16% che cita un “accesso ristretto a servizi, componenti, applicazioni”.
Per rimuovere questi ostacoli, le raccomandazioni chiave sono: da un lato, creare team di supporto dedicati all’ambiente di test, in grado di fornire ai team Agile soluzioni per il provisioning, l’uso e la manutenzione di tali ambienti; dall’altro, impostare la trasformazione degli ambienti di test adottando il provisioning cloud-based, e suddividendo i grandi e complessi ambienti di test in componenti virtualizzati. Infine, il suggerimento è anche implementare soluzioni di self-provisioning basate sulla containerizzazione del software.
Orchestrazione del test, per eliminare i silos di automazione
Un altro trend chiave emergente dal CTR 2019 è la necessità di orchestrare le attività di test, per accrescere la velocità di rilascio delle release software figura 7). Secondo la survey, il 29% dei rispondenti gradirebbe distribuire nuove build giornalmente, e un altro 28% vorrebbe farlo su base settimanale. Inoltre, ben il 18% vorrebbe rilasciare nuove build diverse volte nell’arco di un’ora. Per soddisfare tale domanda di maggior velocità e qualità, negli ultimi anni le organizzazioni si sono rivolte ai tool di automazione, a ciò ha portato a uno scenario in cui si sono create ‘isole di automazione’ nel ciclo di sviluppo software, legate assieme da processi manuali. Tuttavia poiché la velocità di un sistema è determinata dal componente più lento, l’intero processo risulta incapace di scalare la domanda di velocità ed efficienza richieste. E tale situazione è ulteriormente complicata dalla crescente complessità delle architetture e dalla mancanza di visibilità per tutti i team nella pipeline di sviluppo. Il 62% dei rispondenti riporta che “le release stanno diventando molto complesse”, spesso coinvolgendo molteplici applicazioni con dipendenze, e differenti tecnologie con risorse potenzialmente in conflitto.
Il prossimo passo, precisa la survey, è quindi indirizzare i silos di automazione con l’orchestrazione. Nel dominio del testing, l’orchestrazione dei test elimina le isole di automazione, combinando i task manuali e automatici in maniera olistica. Così facendo, è possibile evitare spreco di tempo in passaggi manuali, dipendenze, tempi di attesa, ottenendo un processo in cui generazione ed esecuzione dei test risultano completamente integrate, come parte di una pipeline di continuous delivery (CD) complemente automatizzata e ottimizzata. La strada per raggiungere questo livello è però ancora lunga: quando si chiede quali funzionalità di orchestrazione del test sono più importanti, il 35% indica il “completo percorso di controllo delle attività di testing, dallo sviluppo alla produzione” (figura 8).
Per indirizzare queste sfide di orchestrazione nella pipeline CI/CD, conclude la survey, le organizzazioni devono creare visibilità nella qualità dei processi, implementando cruscotti personalizzati, e ottimizzando i tool di automazione del test e le test operation nei team Agile. Occorre poi configurare cicli di test automatizzato per identificare i difetti subito nella fase iniziale del ciclo di sviluppo software, e automatizzare il self-provisioning dei dati di test. Infine, è necessario sfruttare le tecnologie di AI e machine learning (ML) per ottimizzare i cicli di collaudo.
