Il test continuo è il processo di incorporazione di feedback automatizzati in diverse fasi del ciclo di vita dello sviluppo del software (SDLC) che consente una maggiore velocità ed efficienza nella gestione delle distribuzioni.

Il test continuo è un fattore critico alla base dell'efficacia dei processi CI/CD (integrazione continua/fornitura continua) e svolge un ruolo cruciale nell'accelerare le tempistiche SDLC migliorando la qualità del codice, evitando costosi colli di bottiglia e accelerando i processi DevOps .

Uno dei principi fondamentali per lo sviluppo di un approccio DevOps pratico è quello di colmare il divario tra una distribuzione rapida del software e un'esperienza affidabile per gli utenti. Tuttavia, il modo convenzionale di ottenere manualmente un feedback in ogni fase di sviluppo del software (vale a dire progettazione, codifica, test, distribuzione e manutenzione), comportava un uso insufficiente e inefficace delle risorse organizzative e, in ultima analisi, a cicli di integrazione più lunghi e a ritardi nell'aggiornamento dei prodotti.

I test continui risolvono queste inefficienze aiutando i team DevOps a concentrarsi sulle fasi iniziali del processo, fornendo loro feedback preziosi nelle prime fasi dell'SDLC, automatizzando al contempo i processi di test manuali e riducendo al minimo l'errore umano.

I test continui funzionano utilizzando strumenti automatizzati per caricare script QA predefiniti in tutte le fasi della produzione. Questi script automatizzati eliminano la necessità di un intervento umano regolare durante l'esecuzione del controllo qualità e convalidano in modo sequenziale l'efficienza del codice sorgente, assicurando al contempo che qualsiasi feedback pertinente venga immediatamente fornito ai team appropriati.

Se i test automatizzati falliscono, i team di sviluppo vengono avvisati in quella singola fase di sviluppo in modo da poter apportare le modifiche necessarie al codice sorgente “prima” che questo abbia un impatto su altri team nelle diverse fasi dell’SDLC. Se i test automatizzati superano l'ispezione, i progetti vengono automaticamente passati alla fase successiva dell'SDLC, offrendo alle organizzazioni la possibilità di creare un modello di fornitura sostenibile che massimizzi la produttività e migliori il coordinamento interdipartimentale.

Nel seguente video, Eric Minick approfondisce l'argomento:

L'integrazione di test continui nei processi DevOps offre numerosi vantaggi alle aziende in crescita.

Migliore efficienza e distribuzioni di qualità superiore. I test continui forniscono un metodo automatizzato per gestire l'assicurazione di qualità e l'interoperabilità tra i flussi di lavoro in ogni fase del ciclo di vita dello sviluppo del software (SDLC). Integrando cicli di feedback continui nei moduli di test degli utenti e delle unità, gli sviluppatori possono ricevere le informazioni utili di cui hanno bisogno per migliorare la compatibilità e le prestazioni del loro codice prima che venga distribuito. Questa efficienza risolve le disconnessioni tra più membri del team DevOps e favorisce l'accelerazione dei tempi di distribuzione del software.

Individuazione e correzione rapida degli errori per progetti distribuiti. Le moderne architetture di sviluppo sono sfaccettate e multilivello. I test continui aiutano i team di sviluppo ad abbattere queste complessità incorporando una soluzione di test scalabile e automatizzata che migliora significativamente le tempistiche di rilevamento e correzione degli errori.

Esperienza dell'utente migliorata. I metodi avanzati di test continuo possono simulare una varietà di casi d'uso e scenari di risoluzione dei problemi unici e osservare come gli utenti rispondono ad essi. Le informazioni raccolte da queste simulazioni consentono agli sviluppatori di eliminare tempestivamente le inefficienze dell'interfaccia utente ed evitare sorprese indesiderate dopo la distribuzione del prodotto fisico.

Riduzione dei costi dovuti alle interruzioni di attività legate allo sviluppo. Soprattutto nei grandi sistemi interconnessi, un errore in un solo modulo di un'applicazione può avere effetti a catena che possono causare tempi di inattività indesiderati, con un impatto negativo sulla produttività e sui profitti.

I provider di cloud, ad esempio, segnalano abitualmente guasti in una zona che paralizzano un'intera regione e causano interruzioni di diverse ore. Questo può essere particolarmente devastante per le organizzazioni che dipendono da un'elevata disponibilità di servizi. I test continui a livello granulare identificano gli errori che altrimenti potrebbero essere invisibili nei sistemi software di grandi dimensioni e aiutano a evitare i costi delle interruzioni del business.

Il test continuo prevede una serie di test che garantiscono l'affidabilità, la sicurezza, le prestazioni operative e l'usabilità del sistema. Questa serie di test include:

• Test Shift-Left: questo approccio dà la priorità ai test del software e del sistema nelle prime fasi del ciclo di vita dello sviluppo del software (SDLC) per contribuire a ridurre o prevenire problemi di debug significativi in futuro.
  
  
• Test Shift-Right: questo approccio dà la priorità ai test verso la fine dell'SDLC, concentrandosi sul miglioramento dell'esperienza dell'utente, delle prestazioni complessive, della tolleranza ai guasti e della funzionalità.
  
  
• Smoke test: questi test, che possono essere manuali o automatizzati, forniscono uno screening iniziale superficiale per individuare eventuali difetti evidenti nel software. Sebbene gli smoke test non siano complessi nella loro costruzione, forniscono comunque una soluzione rapida ed economica per l'eliminazione di errori grossolani nel software.
  
  
• Test unitari: sono ideali per controlli su piccola scala di stress, carico, volume o perdita di memoria tra le build per individuare i cali nelle prime fasi di sviluppo.
  
  
• Test di integrazione e messaggistica: verificano la presenza di errori quando i moduli software funzionano insieme. I test continui virtualizzano le dipendenze mancanti, in modo che i team possano verificare il funzionamento collettivo dei processi e degli scenari end-to-end. Il codice composito viene quindi compilato ed eseguito in fase di esecuzione per verificare se funziona come previsto.
  
  
• Test prestazionali: il solo test delle prestazioni del software applicativo potrebbe non tenere conto dell'hardware e del middleware nell'ambiente di produzione finale. Per valutare efficacemente le prestazioni complessive della soluzione è necessario un test integrato del sistema.
  
  
• Test funzionali: questa forma di test verifica se l'esperienza dell'utente soddisfa le aspettative e se i flussi di lavoro funzionali vengono eseguiti come richiesto in un sistema software. Ad esempio, il software per la supply chain dovrebbe essere in grado di avvisare i camion di arrivare alle fabbriche quando le scorte sono disponibili per la spedizione. (Al contrario, i test non funzionali si concentrano su prestazioni, usabilità, affidabilità, tempo di risposta, tempo di caricamento, scalabilità, ecc. e misurano la disponibilità del software a fornire l'esperienza desiderata al cliente.)
  
  
• Test di regressione: questo test verifica se vi sono cambiamenti nelle prestazioni, nella funzionalità o nelle dipendenze dopo la correzione degli errori in qualsiasi software dipendente e se il sistema funziona come prima.
  
  
• Test di accettazione dell'utente: chiamato anche test dell'applicazione o test dell'utente finale, è il momento in cui l'applicazione viene testata in una situazione reale da un sottoinsieme di utenti previsti. Il beta testing è un esempio di test di accettazione delll'utente.

I sistemi e le applicazioni IT corrono un rischio maggiore di errori a causa delle seguenti caratteristiche:

• Sono sempre più integrati con una serie di tecnologie emergenti: ad esempio, cloud computing, Internet of Things (IoT), networking software-defined, realtà aumentata (AR)
  
  
• Sono sempre più distribuiti in diverse regioni, con un core e un edge perfettamente interconnessi. Le applicazioni per le smart cities, le auto autonome e i servizi intelligenti sono i beneficiari di questa architettura

In questi casi, i test continui sono più impegnativi perché lo sviluppo non avviene in un’unica sede o in un’unica azienda. Alcuni elementi del sistema possono essere forniti da terzi, compresi i team da remoto. Il sistema può essere integrato con le interfacce di programmazione delle applicazioni (API). Ogni team di sviluppo opera in diversi ambienti IT, incluso il software legacy. È impossibile riprodurre l'ambiente fisico di ciascuno dei team per i test continui.

Fortunatamente, i test continui possono essere virtualizzati per creare un ambiente di test in cui l'intero sistema può essere riprodotto virtualmente in un'unica interfaccia. Un ambiente virtualizzato può essere facilmente configurato di nuovo per eseguire test su un sistema IT diverso o su uno modificato per correggere gli errori

In un ambiente DevOps, i test continui vengono eseguiti automaticamente durante tutto il ciclo di vita dello sviluppo del software (SDLC) e lavorano di pari passo con l'integrazione continua per convalidare automaticamente qualsiasi nuovo codice integrato nell'applicazione.

Gli strumenti di test sono precaricati con script di test che vengono eseguiti automaticamente ogni volta che si integra un nuovo codice nell'applicazione. In genere, i test iniziano con il test di integrazione e passano automaticamente al test di sistema, al test di regressione e al test di accettazione dell'utente.

I test generano feed di dati da ciascun modulo dell'applicazione e i feed vengono analizzati per garantire che tutti i moduli interessati dal nuovo codice funzionino come previsto. Se un test fallisce, il codice torna al team di sviluppo per la correzione; quindi viene reintegrato e il ciclo di test ricomincia.

Una volta superati tutti i test, l'applicazione o il progetto passa alla fase successiva dell'SDLC, ovvero tipicamente la distribuzione continua.

Per un approfondimento sull'argomento, vedi la spiegazione di Andrea Crawford sul DevOps:

Per le serie di test è necessario un framework di test continuo per garantirne la coerenza tra i moduli di un'applicazione, i relativi connettori (o API e container), le piattaforme, l'infrastruttura e gli scenari che ne definiscono i requisiti.

Le serie di test possono essere sequenziali (ad esempio, i test di regressione seguono i test unitari) o possono essere simultanee (ad esempio, una nuova iterazione di un modulo è accompagnata da un test con test corrispondenti per le sue dipendenze).

Un framework per il test continuo fornisce un wrapper intorno alla serie di test, in modo che vengano applicati in modo coerente e preparino la strada all'automazione. Gli sviluppatori vogliono assicurarsi che l'approccio che adottano per un modulo non sia diverso da quello applicato ai moduli correlati. Quando i moduli si evolvono, si eseguono anche una serie di test per software correlati.

I framework forniscono un modo standard per modificare comodamente gli script e le funzioni per i test. L'automazione ottiene dei vantaggi quando le incongruenze nei test vengono eliminate, altrimenti genera una serie di risultati di test fuorvianti.