Migliora la qualità del software & risparmia tempo con i test dell’infrastruttura
Nota del redattore: Benvenuti nella serie Leadership nei test del guru e consulente di test del software Paul Gerrard. La serie è pensata per aiutare i tester con alcuni anni di esperienza, in particolare quelli che lavorano in team agili, a eccellere nei ruoli di responsabili e manager dei test.
In un articolo precedente, ti ho spiegato come gestire i test delle prestazioni. Ora parleremo del software per l'infrastruttura IT, dell'infrastruttura di test e degli ambienti di test.
Iscriviti al notiziario di The QA Lead per ricevere una notifica quando saranno pubblicate nuove parti della serie. Questi articoli sono estratti dal corso Leadership nei test di Paul, che consigliamo vivamente per approfondire questo e altri argomenti. Se decidi di iscriverti, usa il nostro codice coupon esclusivo QALEADOFFER per ottenere uno sconto di $60 sul prezzo intero del corso!
Con il termine infrastruttura descriviamo tutto l'hardware, i servizi cloud, le reti, il software di supporto e la nostra applicazione sottoposta a test necessari per sviluppare, testare, distribuire e gestire i nostri sistemi.
È tuttavia ragionevole non limitare la nostra definizione alla tecnologia. I centri dati, gli spazi degli uffici, le scrivanie, i computer fissi, i computer portatili, i tablet e i telefoni cellulari con i relativi insiemi di software installati fanno tutti parte dell'ecosistema necessario per sviluppare, testare e distribuire i sistemi.
Se includiamo gli strumenti per sviluppatori, gli strumenti e le procedure DevOps, gli strumenti di test, i processi aziendali e le competenze in materia necessarie, l'insieme diventa ancora più ampio.
Vuoi di più da The CTO Club?
Crea un account gratuito per completare questo articolo e unirti a una comunità di CTO e leader ingegneristici che condividono framework, strumenti e approfondimenti reali per progettare, implementare e scalare tecnologie guidate dall'IA.
Have an account? Log In
Le cose più banali, come i codici di accesso o le smart card utilizzati per accedere agli edifici, possono diventare critiche se non sono disponibili.
L'infrastruttura, in tutte le sue varie forme, esiste per supportare lo sviluppo, i test, la distribuzione e le operazioni dei sistemi. È fondamentale per i test oppure deve essere sottoposta a test.
Nel prossimo articolo esamineremo gli strumenti per lo sviluppo, i test e la collaborazione. In questo articolo considereremo ciò che la maggior parte delle persone definisce ambienti di test e analizzeremo brevemente quello che viene spesso chiamato test dell'infrastruttura. Tratterò:
- Ambienti di test
- Ambienti di sviluppo
- Ambienti di test a livello di sistema
- Ambienti dei dati
- Test dell'infrastruttura
Cominciamo.
Ambienti di test
Tutti i test si basano su un presupposto implicito, fondamentale e semplificativo: i nostri test verranno eseguiti in un ambiente noto.
Che cos'è un ambiente?
Tutti i sistemi devono essere testati nel loro contesto. Affinché un test sia significativo, il sistema deve essere installato, configurato, distribuito o realizzato in un ambiente realistico che simuli il mondo reale in cui verrà utilizzato.
Potremmo utilizzare scenari di test che portano al limite le capacità dei sistemi in termini, ad esempio, di funzionalità, prestazioni o sicurezza, ma queste sono proprietà dei test, non dell'ambiente.
Un ambiente realistico dovrebbe replicare tutti gli ambienti aziendali, tecnici e organizzativi. Gran parte di questo è costituita dai dati utilizzati per guidare i processi aziendali, configurare il sistema e fornire dati di riferimento.
Tuttavia, gli ambienti perfettamente realistici sono generalmente impraticabili o troppo costosi (anche i tester di sistemi ad alta criticità, come aeroplani, reattori nucleari o scanner cerebrali, devono scendere a compromessi prima o poi). Quasi tutti i test vengono eseguiti in ambienti che simulano il mondo reale con un livello di compromesso accettabile.
Le automobili vengono testate su banchi a rulli, nelle gallerie del vento, su piattaforme vibranti e su piste di prova private prima di essere testate su strada. I sistemi informatici vengono testati nei laboratori software da programmatori e tester del software prima che gli utenti finali vengano coinvolti per provarli in un ambiente simile a quello di produzione.
Per assicurarti che i tuoi ambienti di test siano conformi agli standard del settore, valuta l'integrazione di una di queste piattaforme di gestione dei test più apprezzate.
Testare in ambienti realistici
Gli ambienti simulati sono fallibili, proprio come i nostri requisiti e modelli di test, ma dobbiamo accettare questa situazione.
Dobbiamo organizzare test significativi negli ambienti a nostra disposizione e interpretare i risultati dei test per ciò che significano.
L'affidabilità dei risultati dei test dipende dall'ambiente in cui vengono eseguiti. Se un test viene eseguito in un ambiente configurato in modo errato:
- Un test che fallisce può far pensare che il sistema sia difettoso quando, in realtà, è corretto.
- Un test che supera può far pensare che il sistema sia corretto quando, in realtà, è difettoso.
Ovviamente, entrambe le situazioni sono altamente indesiderabili.
Configurazione e consegna tempestive degli ambienti
Anche con l'emergere dell'infrastruttura cloud, gli ambienti di test possono essere difficili e costosi da configurare e mantenere.
Quando i team di supporto lavorano sul nuovo ambiente di produzione, i tester richiedono ambienti di test (e forse diversi). In seguito, durante i test, i team di supporto si trovano spesso a dover soddisfare richieste concorrenti.
Gli ambienti di sviluppo o qualsiasi attività di test successiva possono essere forniti in ritardo o non essere forniti affatto, oppure potrebbero non essere configurati o controllati come richiesto. Inevitabilmente, ciò ritarderà i test e/o minerà la fiducia in qualsiasi risultato dei test.
Un'attività fondamentale consiste nello stabilire la necessità e i requisiti di un ambiente da utilizzare per i test, compreso un meccanismo per gestire le modifiche a tale ambiente—il prima possibile.
L'infrastruttura come codice è una recente evoluzione nel modo in cui è possibile costruire gli ambienti, con strumenti che seguono procedure e utilizzano codice dichiarativo per definire la configurazione dell'ambiente.
Sebbene le piattaforme dei sistemi operativi di base (server) possano essere create facilmente nel cloud o come macchine virtuali nel proprio ambiente, i server specializzati e completamente specificati, dotati di tutto il software, dei dati, delle configurazioni e delle interfacce necessari, richiedono più lavoro.
Quando si configura la propria infrastruttura di test, è fondamentale integrare un software affidabile per la gestione dei database per ottenere prestazioni ottimali
Tuttavia, una volta configurati, essi offrono un mezzo altamente efficiente per la creazione degli ambienti. Il codice dell'infrastruttura può essere sottoposto al controllo del codice sorgente proprio come qualsiasi codice applicativo e gestito tramite modifiche.
Un principio fondamentale della consegna continua è che, il prima possibile, del software—anche se non è utile—dovrebbe essere fatto passare attraverso la pipeline di consegna per dimostrare che i processi funzionano.
Naturalmente, ciò richiede ambienti idonei per le compilazioni, gli strumenti di integrazione continua, i test a livello di sistema e la distribuzione. L'obiettivo è distribuire gli ambienti di test e di produzione senza vincoli. Una volta definite le definizioni degli ambienti e i processi di distribuzione, la generazione degli ambienti diventa un'attività automatizzata e ordinaria.
In qualsiasi circostanza, le definizioni di questi ambienti costituiscono uno dei primi risultati del progetto.
Ambienti di sviluppo
I test degli sviluppatori si concentrano sulla costruzione di componenti software che forniscono funzionalità internamente all'applicazione o a livello dell'utente o della presentazione.
I test tendono a essere guidati dalla conoscenza della struttura interna del codice e potrebbero non utilizzare o richiedere dati «realistici» per essere eseguiti. I test dei componenti o dei servizi di basso livello vengono generalmente eseguiti tramite un'API utilizzando driver o strumenti realizzati appositamente o proprietari.
La varietà di strumenti e piattaforme di sviluppo e dei cosiddetti Ambienti di sviluppo integrati (IDE) è enorme. In questo articolo possiamo solo accennare ad alcuni dei principali requisiti e delle funzionalità degli ambienti correlati ai test.
Per supportare lo sviluppo e i test di competenza degli sviluppatori, gli ambienti devono supportare le seguenti attività. Questa è solo una selezione—nella propria situazione potrebbero essere necessarie attività aggiuntive o varianti di queste attività:
- Un ambiente «Sandbox» per sperimentare con nuovo software. Le sandbox vengono spesso utilizzate per testare nuove librerie, sviluppare codice prototipale usa e getta o fare pratica con le tecniche di programmazione. Tutti i linguaggi di programmazione più comuni dispongono di centinaia o migliaia di librerie software. Le sandbox vengono utilizzate per installare e testare software che non fa ancora parte del flusso principale di sviluppo, allo scopo di valutarlo e fare pratica nel suo utilizzo. Questi ambienti possono essere trattati come ambienti usa e getta.
- Ambiente di sviluppo locale. È il luogo in cui gli sviluppatori mantengono una copia locale di una parte o di tutto il codice sorgente della propria applicazione, proveniente da un repository di codice condiviso, e possono creare compilazioni del sistema per i test locali. Questo ambiente consente agli sviluppatori di apportare modifiche al codice nella propria copia locale e di testarle. Alcuni test sono ad hoc e forse non vengono mai ripetuti. Altri test sono automatizzati. I test automatizzati vengono generalmente conservati per sempre, soprattutto se seguono un approccio basato sui test.
- Ambiente di integrazione (continua) condiviso. Quando gli sviluppatori ritengono che il proprio codice sia pronto, inviano le modifiche al repository di codice condiviso e controllato. L'ambiente CI esegue compilazioni automatizzate ed esegue test automatizzati utilizzando il repository. A questo punto, il codice nuovo o modificato viene integrato e testato. Il sistema CI esegue test automatizzati su richiesta, ogni ora o ogni giorno, e l'intero team riceve notifiche e può visualizzare lo stato dei test dell'ultima compilazione integrata. Gli errori vengono individuati tempestivamente e gestiti con la massima urgenza.
Un ambiente di sviluppo o CI supporta i test degli sviluppatori, ma altri server applicativi, servizi web, sistemi di messaggistica o server di database che completano il sistema potrebbero non essere disponibili.
Se questi sistemi di interfacciamento non esistono perché non sono ancora stati sviluppati, oppure perché appartengono a un'azienda partner e ne esiste solo un sistema live senza una versione di test, gli sviluppatori devono creare stub o mock per queste interfacce, così da poter almeno testare il proprio codice.
Gli strumenti di mocking possono essere sofisticati, ma le interfacce simulate generalmente non sono in grado di supportare test che richiedono dati integrati tra più sistemi.
Se gli sviluppatori hanno accesso a un'interfaccia per un server di database di test, i dati di test potrebbero essere minimi, non integrati o coerenti e non rappresentativi dei dati di produzione.
I database di sviluppo condivisi all'interno di un team sono solitamente insoddisfacenti. Se non esiste un buon regime per la gestione di questa risorsa condivisa, gli sviluppatori potrebbero riutilizzare, danneggiare o eliminare i dati degli altri.
Ambienti di test a livello di sistema
Il test a livello di sistema si concentra sull'integrazione collaborativa di componenti e sottosistemi.
Questi ambienti forniscono una piattaforma per supportare gli obiettivi dell'integrazione su larga scala, della convalida delle funzionalità e delle operazioni di sistema nel contesto dei processi degli utenti o aziendali.
Gli ambienti potrebbero essere dedicati anche agli aspetti non funzionali del sistema, come prestazioni, sicurezza o gestione dei servizi.
Uno degli inconvenienti più comuni dei test si verifica quando un tester di sistema riscontra un qualche tipo di errore nel proprio ambiente, ma, per quanto si impegni, lo sviluppatore o il tester non riesce a riprodurre l'errore nell'ambiente di sviluppo.
«Funziona sulla mia macchina!»
«Sì, certo che funziona.»
Quasi certamente ciò è causato da una mancanza di coerenza tra i due ambienti. La differenza nel comportamento potrebbe essere causata dalla configurazione, da differenze tra versioni software o dalla differenza nei dati del database.
Le differenze nei dati che causano problemi sono la prima cosa da verificare. Di solito sono facili da identificare e spesso possono essere risolte rapidamente.
Quando esiste una discrepanza nella versione del software o nella configurazione, i tester e gli sviluppatori possono sprecare molto tempo per individuare la causa della differenza nel comportamento.
Quando si verificano questi problemi, spesso significa che c'è un problema di comunicazione tra lo sviluppatore e il test. Potrebbe anche indicare una perdita del controllo della configurazione nella configurazione dell'ambiente di sviluppo o di test, oppure nel processo di distribuzione.
L'infrastruttura come codice e il provisioning automatizzato degli ambienti renderanno un ricordo del passato i problemi di coerenza tra gli ambienti.
Tipi di ambienti di test dedicati
Per supportare i test di sistema, di accettazione e non funzionali, gli ambienti devono supportare le attività seguenti (nella vostra organizzazione potrebbero essercene altre):
- Ambiente di test del sistema (funzionale). In questo ambiente, il sistema viene convalidato rispetto ai requisiti documentati per il sistema nel suo complesso. I requisiti possono essere costituiti da documenti di testo di grandi dimensioni con casi di test tabulati definiti per un test del sistema. Nei progetti agili, questo ambiente può essere necessario per consentire ai tester di esplorare il sistema integrato senza limitarsi a funzionalità specifiche.
- Ambiente per i test end-to-end. Mentre l'ambiente CI consente di integrare i componenti con i sottosistemi, i processi aziendali possono richiedere la disponibilità di altri sistemi di interfacciamento (non sotto il controllo degli sviluppatori). Per eseguire test di integrazione su larga scala, test dei processi aziendali o test di accettazione complessivi sono necessari ambienti con un ambito completo. Di solito, i dati sono una copia di quelli in produzione o, almeno, hanno una scala adeguata. Quando è necessario dimostrare l'integrazione su larga scala, i flussi di dati e di controllo vengono verificati utilizzando percorsi utente più lunghi e riconciliazioni indipendenti dei dati tra i sistemi integrati. La gestione dei dati negli ambienti di test è fondamentale. Se si utilizza già Jira, si consideri il potenziamento delle funzionalità di gestione dei dati con strumenti avanzati di gestione dei test progettati per Jira.
- Ambiente per le prestazioni. Questi ambienti devono fornire una piattaforma significativa per valutare le prestazioni di un sistema (o di determinati sottosistemi). Possono essere possibili compromessi nell'architettura in presenza di ridondanza o clonazione dei server. Tuttavia, i volumi di dati devono essere della stessa scala di quelli di produzione, anche se i dati sono sintetici. In ogni caso, l'ambiente deve avere una scala sufficiente a supportare i volumi delle transazioni di produzione, così da consentire una previsione utile delle prestazioni dei sistemi in produzione.
- Ambienti di disponibilità, resilienza e gestibilità (ARM). Per alcuni aspetti, questi ambienti sono simili agli ambienti per le prestazioni, ma, a seconda dell'obiettivo del test, le variazioni possono essere inevitabili. I test di disponibilità mirano a verificare che il sistema possa operare per periodi prolungati senza guasti. I test di resilienza (spesso chiamati test di failover) verificano che, quando i componenti del sistema si guastano, non causino un'interruzione inaccettabile del servizio fornito. I test di gestibilità o operativi mirano a dimostrare che le procedure di amministrazione, gestione, backup e ripristino del sistema funzionino efficacemente.
Dati negli ambienti
In alcuni progetti molto grandi, possono esserci fino a 20 o persino 30 ambienti su larga scala dedicati a diversi aspetti di test, formazione, migrazione dei dati e prove di passaggio al nuovo sistema. Nei progetti più piccoli ci saranno meno ambienti, forse un solo ambiente condiviso o un regime di distribuzione continua; tutti i test potrebbero essere implementati automaticamente in ambienti istanziati per un singolo utilizzo e successivamente dismessi.
Tutti gli ambienti hanno bisogno di dati, ma la scala e il livello di realismo di tali dati possono variare. Di seguito sono riportati alcuni schemi comuni relativi al modo in cui i dati di test vengono acquisiti e gestiti. Questi schemi si concentrano sulla titolarità (locale o condivisa), sulle modalità di creazione (manuale, automatizzata o mediante copia dalla produzione) e sulla scala:
- Dati locali, creati manualmente e su piccola scala, adatti ai test ad hoc da parte di sviluppatori o tester.
- Dati locali, automatizzati e sintetici. Adatti ai test automatizzati degli sviluppatori o agli ambienti in cui è possibile coprire le funzionalità di moduli o caratteristiche specifici.
- Dati condivisi, creati manualmente. Utilizzati negli ambienti di test di integrazione e del sistema, spesso quando i dati di test si sono evoluti parallelamente ai test eseguiti manualmente. Vengono sottoposti a backup e ripristinati quando necessario.
- Dati condivisi, creati automaticamente. Utilizzati negli ambienti di test di integrazione e del sistema quando i dati di test si sono evoluti parallelamente ai test automatizzati o eseguiti manualmente. Vengono generati e/o ripristinati dai backup, quando necessario.
- Dati sintetici/casuali condivisi su larga scala. I test di prestazioni e ARM richiedono dati coerenti in grandi volumi. Di solito, questi dati non devono essere significativi: i dati casuali funzionano bene e vengono generati quando necessario, oppure generati inizialmente e ripristinati dai backup.
- Dati significativi condivisi su larga scala. I test end-to-end, di accettazione o eseguiti dagli utenti richiedono solitamente dati significativi su larga scala. Talvolta vengono utilizzate copie o estratti dei dati in produzione. Occorre tuttavia prestare attenzione a non violare le normative sui dati se questi non vengono rimescolati o anonimizzati.
- Nuovi test e test di regressione. Sarà necessario un insieme di dati noto e controllato, in uno stato noto, quindi di solito viene ripristinato dai backup. Ciò si applica a tutti gli ambienti precedenti, poiché questi test devono essere rieseguiti con dati in uno stato noto per riprodurre gli errori in modo affidabile.
Test dell'infrastruttura
All'inizio di questo articolo abbiamo esaminato cosa comprende l'infrastruttura e da allora ci siamo concentrati principalmente sui componenti tecnici, ovvero sui sistemi software, dando per scontato che l'hardware, reale o virtuale, fosse disponibile.
Quando costruiamo inizialmente i sistemi, presumiamo che l'infrastruttura esista e che funzioni correttamente, sia efficiente, sicura e resiliente, ecc.
Possiamo testare tutti questi aspetti quando abbiamo integrato la nostra applicazione e, senza dubbio, individuare carenze nell'infrastruttura in una fase relativamente avanzata dei nostri progetti. Tuttavia, scoprire problemi nell'infrastruttura così tardi in un progetto è solitamente estremamente destabilizzante.
- Le modifiche necessarie per risolvere i guasti nell'infrastruttura potrebbero richiedere una riprogettazione significativa e modifiche alla nostra applicazione.
- Sarà necessario ripetere i test dei risultati della nostra applicazione o dell'intero sistema.
- Se componenti di terze parti, come database, servizi web, di rete o di messaggistica, si guastano, siamo alla mercé dei fornitori (o della comunità open source) che li supportano.
Per assicurarci che la nostra fiducia nei componenti dell'infrastruttura sia fondata, possiamo basarci sulla nostra esperienza (o su quella di altri) nell'utilizzarli in passato. In alternativa, dobbiamo valutarne l'affidabilità tramite test prima di impegnarci a utilizzarli nella progettazione e nella realizzazione del nostro sistema.
A seconda dell'infrastruttura oggetto dell'analisi, l'ambiente utilizzato può variare da un singolo server a una piattaforma infrastrutturale quasi completa.
Sebbene alcuni test saranno manuali, per la maggior parte utilizzeremo strumenti, driver o robot per simulare il carico di transazioni che la nostra applicazione genererebbe. Dovremmo simulare o sostituire temporaneamente queste interfacce:
- Interfacce attualmente non disponibili
- Interfacce verso componenti di cui ci fidiamo e che sono facili da simulare
- Interfacce fuori ambito che non influiscono sull'infrastruttura sottoposta a test.
L'infrastruttura, inutile dirlo, di solito non opera tramite un'interfaccia utente o GUI.
L'integrazione della nostra applicazione con l'infrastruttura avverrà principalmente sotto forma di messaggistica o chiamate a servizi remoti. Spesso il traffico da simulare richiede chiamate API verso server web o applicativi, server di messaggistica o database, oppure servizi erogati tramite il cloud o da sedi remote.
Gli obiettivi di prestazioni e ARM potrebbero essere noti; in tal caso, è possibile eseguire test per verificare che tali obiettivi siano raggiunti.
Tuttavia, l'infrastruttura è spesso condivisa con applicazioni diverse dalla nostra, quindi conoscerne la capacità complessiva aiuta a valutare quanta capacità resterà quando la nostra applicazione sarà distribuita.
In questo caso, il test dell'infrastruttura affronta il rischio per la nostra applicazione e, forse, per altre applicazioni che in futuro potrebbero basarsi su di essa.
Iscriviti alla newsletter di The QA Lead per ricevere una notifica quando saranno pubblicate nuove parti della serie. Questi post sono estratti dal corso Leadership In Test di Paul, che consigliamo vivamente per approfondire questo e altri argomenti. Se decidi di iscriverti, utilizza il nostro codice coupon esclusivo QALEADOFFER per ottenere $60 di sconto sul prezzo del corso completo!
Lettura consigliata: I 10 MIGLIORI STRUMENTI OPEN SOURCE PER LA GESTIONE DEI TEST
