Ormai il software permea sempre più in profondità il cuore di molti prodotti e servizi. E proprio perché il software è ubiquitario in ogni settore aziendale e industriale, il controllo della correttezza e qualità, anche attraverso un’efficiente governance dei processi di release management e software testing, assurge a requisito prioritario e imprescindibile. Questo vale sia nelle applicazioni per il mercato di massa, sia in quelle business, e a maggior ragione quando il codice viene sviluppato per applicazioni embedded che controllano sistemi ‘safety critical’. D’altra parte, complessità e crescita del numero di linee di codice (LOC – lines of code) del software non favoriscono la riduzione dei costi di sviluppo e il controllo funzionale e qualitativo del codice: ad esclusione del software d’intrattenimento ‘in-flight’, nel 2007 i sistemi avionici di un Boeing 787 Dreamliner hanno richiesto 6,5 milioni di linee di codice; il kernel Linux, nel repository Git, ha inaugurato il 2020 toccando i 27,8 milioni di linee, secondo i dati statistici elaborati da GitStats. Ed anche le auto sono sempre più “fatte di codice”: le self-driving car e i veicoli a guida completamente autonoma, dice Jaguar Land Rover, citando dati Arm, richiederanno un miliardo di linee di codice.
In aggiunta, sta diventando sempre più importante, non solo scrivere software corretto e privo di bug, ma anche manutenibile nel tempo. La manutenibilità è un requisito non funzionale critico nelle metriche di qualità del software.
Release management, cos’è
Nel reparto IT di un’organizzazione, e durante tutto il ciclo di sviluppo software SDLC (software development life cycle), il processo di release management sovraintende alla gestione dei rilasci software, governandone molti aspetti. Quelli essenziali si possono identificare:
- nella pianificazione delle funzionalità e cambiamenti che entreranno nella prossima release;
- nel coordinamento delle differenti build attraverso i vari stadi di sviluppo e per i diversi ambienti;
- nel testing del software, per la verifica delle funzionalità e dei requisiti di stabilità e qualità;
- e, infine, nella fase finale di deployment.
Coordinando i reparti sviluppo, le IT operation, e il deployment del software in produzione, il processo di release management ha l’obiettivo di garantire l’aderenza del codice e delle sue funzionalità ai requisiti e alle priorità definite dai responsabili del business e, se condotto con efficacia, può tradursi in un incremento della fornitura di release caratterizzate da minori bug e difetti.
Paradigma DevOps e release management
Il fenomeno di trasformazione digitale tuttora in essere sta determinando un forte impatto sui tradizionali processi di release management e testing del software, che devono divenire sempre più efficaci e rapidi. In qualunque settore, la digital transformation chiama ogni impresa a differenziarsi, rispetto alla concorrenza, sulla base della qualità delle applicazioni e servizi digitali che è in grado di fornire a utenti e consumatori, e delle percezioni di utilizzo che essi sperimentano con tali applicazioni e servizi. Oggi il software va rilasciato con maggior frequenza, con più build di aggiornamento, sia a livello di stabilità e sicurezza, sia di nuove funzionalità, e a queste esigenze sta rispondendo il modello di sviluppo software DevOps, che introduce automazione e agilità nel processo di release management e nella fase di software testing.
DevOps si differenzia fortemente dall’approccio sequenziale tipico del ciclo di sviluppo basato su metodologia “waterfall” classica, “a cascata”, in cui ciascuna fase (raccolta requisiti funzionali, progettazione del sistema, implementazione, testing, deployment, manutenzione) comincia soltanto dopo il completamento della precedente, e dove non esiste un meccanismo di feedback e correzione degli errori tra una fase e l’altra. Nel metodo waterfall, la fase di testing, verifica, assicurazione della qualità e validazione del codice avviene solo dopo la fase d’implementazione, e trovare e correggere difetti e bug del software in questo stadio si rivela costoso.
DevOps, invece, permette di superare tali limiti attraverso l’introduzione delle metodologie di release management CI/CD (continuous Integration/continuous delivery/continuous deployment), che permettono di accelerare e rendere agile la fase di sviluppo e testing del software: ad esempio, nella pratica CI, il codice creato dagli sviluppatori risiede in un repository comune, dove tutte le modifiche al codice stesso vengono integrate in automatico in una build, verificate e poi sottoposte a test per l’individuazione di eventuali bug ed errori. In tal modo è possibile identificare prima i difetti, e instaurare una fluida iterazione del codice, con cicli di feedback continui nella pipeline CI/CD.
Software testing continuo
Nel ciclo di sviluppo software DevOps, attraverso la pipeline CI/CD il processo di release management accelera, diventando agile e continuo: di conseguenza, anche il test del software deve necessariamente procedere armonicamente con la medesima continuità. Il continuous testing in DevOps richiede un processo di test automatizzato, con relativo feedback, in diversi stadi del ciclo di sviluppo: ad esempio, i test d’integrazione sono richiesti a livello del build server, mentre i test funzionali e i test di regressione vengono eseguiti sui test server; nello stadio di deployment, invece, è necessario un testing a livello dello staging server, ossia un server su cui il software in questione viene collaudato in un ambiente simile a quello di produzione, prima di passare al rilascio vero e proprio. Molti di questi test richiedono l’esecuzione di operazioni lunghe, ripetitive e noiose, se svolte in modalità manuale dai tester, e per tale ragione, in questi casi, diventa sempre più critico impostare una strategia di test automation, adottando strumenti adeguati.
Test automation e crowdtesting: collaudo in casi d’uso reali
Il testing automatizzato può non esaurire tutte le attività di collaudo indirizzate a ottimizzare la qualità del software. Questa è una delle ragioni che spiega perché, negli ultimi anni, sono stati sviluppati anche altri paradigmi di collaudo, tra i quali il “crowdtesting”, noto anche come “crowdsourced testing”, si colloca con un ruolo complementare e peculiare.
Il crowdtesting può contare su comunità online di tester ed esperti, selezionabili secondo varie caratteristiche demografiche e differenti livelli di competenze. I crowd tester si trovano distribuiti a livello geografico, e sono quindi in grado, ad esempio, di collaudare il software localmente, in molteplici lingue, utilizzando una varietà di piattaforme e dispositivi (PC, smartphone, tablet, browser diversi) in ambienti e contesti reali.
La natura distribuita e remota del crowdtesting rende possibile estendere la copertura dei test su una più vasta gamma di hardware. Inoltre, la possibilità di espandere il numero di crowd tester pagandoli “on-demand” a consumo, consente di aumentare l’efficienza di collaudo, identificando bug e difetti in minor tempo rispetto ai metodi tradizionali, basati su team di tester in-house assunti a tempo pieno e non facilmente scalabili.
Nel crowdtesting, i gruppi di tester possono essere selezionati in funzione della tipologia di applicazione (consumer, business) da collaudare: soprattutto, a differenza dei tradizionali team di testing in-house, i crowd tester non seguono una specifica checklist con l’elenco dei test da eseguire, ma sono incaricati di provare e valutare particolari funzionalità dell’applicazione in una situazione di vita reale, come una transazione d’acquisto su un sito di e-commerce o un’operazione su una app di home banking. Da questo punto di vista, oltre al valore della propria personale esperienza e inclinazione nell’eseguire un test, i crowd tester aggiungono anche la capacità di scoprire imperfezioni e difetti, con occhi attenti a particolari e aspetti relativi anche alla usabilità del software che spesso sfuggono, o non vengono nemmeno considerati dai tradizionali team di testing.
