Aumenta la Qualità del Software e Risparmia Tempo con il Testing dell’Infrastruttura
Nota dell’editore: Benvenuto nella serie Leadership In Test del guru e consulente del testing software Paul Gerrard. La serie è pensata per aiutare i tester con alcuni anni di esperienza—in particolare quelli in team agile—a eccellere nei loro ruoli di test lead e manageriali.
In un articolo precedente, ti ho illustrato come gestire il performance testing. Ora parleremo di software per infrastrutture IT, infrastruttura per i test e ambienti di test.
Iscriviti alla newsletter The QA Lead per essere avvisato quando vengono 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, usa il nostro codice coupon esclusivo QALEADOFFER per ottenere 60$ di sconto sul prezzo completo del corso!
L’infrastruttura è il termine che usiamo per descrivere tutta l’hardware, i servizi cloud, il networking, il software di supporto e la nostra applicazione sotto test necessari per sviluppare, testare, distribuire e gestire i nostri sistemi.
Ha senso non limitare la nostra definizione alla sola tecnologia. Data center, spazi ufficio, scrivanie, desktop, laptop, tablet e smartphone con i relativi stack software installati fanno tutti parte dell’ecosistema necessario per sviluppare, testare e distribuire sistemi.
Se includi strumenti di sviluppo, strumenti e procedure DevOps, strumenti di test, i processi aziendali e le competenze di dominio richieste, c’è ancora di più da considerare.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Le cose più banali—i codici di accesso o le smart card usate per entrare negli edifici—possono diventare critiche se non sono disponibili.
L’infrastruttura, in tutta la sua varietà, esiste per supportare lo sviluppo, il test, la distribuzione e le operazioni dei tuoi sistemi. È o critica per il testing oppure necessita di essere testata.
Nell’articolo successivo parleremo degli strumenti per sviluppo, test e collaborazione. In questo articolo, invece, considereremo ciò che la maggior parte delle persone intende per ambienti di test e daremo uno sguardo a quello che spesso viene chiamato testing dell’infrastruttura. Mi occuperò di:
- Ambienti di Test
- Ambienti di Sviluppo
- Ambienti di Test a Livello di Sistema
- Ambienti Dati
- Test dell’Infrastruttura
Iniziamo.
Ambienti di Test
Tutto il testing fa un’assunzione implicita, fondamentale e semplificatoria: che i nostri test vengano eseguiti in un ambiente conosciuto.
Che cos’è un ambiente?
Tutti i sistemi devono essere testati nel contesto. Affinché un test sia significativo, il sistema deve essere installato, configurato, distribuito o costruito in un ambiente realistico che simuli il mondo reale in cui sarà utilizzato.
Possiamo utilizzare scenari di test che mettano alla prova la capacità dei sistemi in termini di funzionalità, prestazioni o sicurezza, ad esempio, ma queste sono proprietà dei test, non dell’ambiente.
Un ambiente realistico dovrebbe replicare tutti gli aspetti aziendali, tecnici e organizzativi. Molto di ciò consiste nei dati utilizzati per gestire i processi aziendali, configurare il sistema e fornire dati di riferimento.
Ma ambienti perfettamente realistici sono solitamente impraticabili o troppo costosi (anche i tester di sistemi ad alta criticità come aerei, reattori nucleari o scanner cerebrali devono scendere a compromessi ad un certo punto). Quasi tutti i test vengono eseguiti in ambienti che simulano il mondo reale con un livello di compromesso accettabile.
Le auto vengono testate su rulli stradali, in gallerie del vento, su banchi a vibrazione e piste di prova private prima di essere collaudate su strada aperta. I sistemi informatici vengono testati nei laboratori software da programmatori e tester 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 di settore, valuta l’integrazione di una di queste piattaforme di test management più apprezzate.
Testare in ambienti realistici
Gli ambienti simulati sono fallibili, proprio come i nostri requisiti e modelli di test, ma dobbiamo conviverci.
Dobbiamo organizzare test che abbiano senso negli ambienti disponibili, e i risultati dei test significano ciò che noi interpretiamo che significhino.
L’affidabilità dei risultati del test dipende dall’ambiente in cui vengono eseguiti i test. Se un test viene eseguito in un ambiente configurato in modo errato:
- Un test che fallisce può implicare che il sistema sia difettoso quando, in realtà, è corretto.
- Un test che supera può implicare che il sistema sia corretto quando, in realtà, è difettoso.
Entrambe le situazioni sono ovviamente molto indesiderabili.
Preparare e consegnare gli ambienti in tempo
Anche con l'emergere delle infrastrutture cloud, configurare e mantenere gli ambienti di test può essere difficile e costoso.
Quando i team di supporto lavorano sul nuovo ambiente di produzione, i tester richiedono ambienti di test (e forse diversi di essi). Più avanti nei test, i team di supporto spesso hanno richieste concorrenti.
Gli ambienti di sviluppo o eventuali attività di test successive possono essere consegnati in ritardo o non essere mai consegnati, oppure potrebbero non essere configurati o controllati come richiesto. Inevitabilmente, questo ritarderà i test e/o minerà la fiducia in qualsiasi risultato derivante dai test.
Un’attività critica è stabilire la necessità e i requisiti di un ambiente da utilizzare per i test, inclusa una modalità per gestire le modifiche a quell’ambiente—il prima possibile.
L'infrastruttura come codice è una recente evoluzione su come gli ambienti possono essere costruiti con strumenti seguendo procedure e utilizzando codice dichiarativo per definire la configurazione dell'ambiente.
Sebbene le piattaforme di sistemi operativi di base (server) possano essere create facilmente nel cloud o come macchine virtuali nel proprio ambiente, server completamente specificati e dedicati con tutto il software, i dati, le configurazioni e le interfacce richieste richiedono uno sforzo aggiuntivo.
Quando configuri la tua infrastruttura di test, è fondamentale integrare un software di gestione di database affidabile per prestazioni ottimali
Tuttavia, una volta configurati, offrono un metodo altamente efficiente per creare ambienti. Il codice di infrastruttura può essere controllato nelle versioni esattamente come il codice applicativo e gestito attraverso le modifiche.
Un principio fondamentale della consegna continua è che, il prima possibile, una parte di software—anche qualcosa di non utile—dovrebbe essere inviata attraverso la pipeline di consegna per dimostrare il funzionamento dei processi.
Naturalmente, questo richiede ambienti validi per i build, strumenti di integrazione continua, test a livello di sistema e distribuzione. L’obiettivo è distribuire ambienti di test e produzione senza vincoli. Una volta che le definizioni degli ambienti e i processi di deployment sono pronti, generare ambienti diventa un’attività automatica e di routine.
In ogni caso, le definizioni di questi ambienti costituiscono una consegna anticipata del progetto.
Ambienti di sviluppo
Il testing dei programmatori si concentra sulla realizzazione di componenti software che forniscono funzionalità all’interno dell’applicazione o nel layer dell’utente o di presentazione.
I test tendono a basarsi sulla conoscenza della struttura interna del codice e potrebbero non utilizzare o richiedere dati "realistici" per essere eseguiti. I test dei componenti o servizi a basso livello sono solitamente eseguiti tramite un’API utilizzando driver personalizzati o proprietari.
La gamma di strumenti di sviluppo, piattaforme e cosiddetti Ambienti di Sviluppo Integrati (IDE) è enorme. In questo articolo possiamo solo accennare ad alcuni dei principali requisiti e funzionalità sugli ambienti relativi ai test.
Per supportare lo sviluppo e i test previsti per gli sviluppatori, gli ambienti devono supportare le seguenti attività. Questo è solo un elenco parziale—potrebbero esserci attività aggiuntive o varianti in base alla tua situazione:
- Un ambiente "sandbox" per sperimentare nuovo software. Le sandbox sono spesso utilizzate per testare nuove librerie, sviluppare codice prototipo da scartare o esercitarsi con tecniche di programmazione. Tutti i linguaggi di programmazione più diffusi hanno centinaia o migliaia di librerie software. Le sandbox vengono utilizzate per installare e testare software non ancora parte del filo principale di sviluppo al fine di valutarlo e farne pratica. Questi ambienti possono essere trattati come ambienti usa e getta.
- Ambiente di sviluppo locale. Qui gli sviluppatori mantengono una copia locale di una porzione o di tutto il codice sorgente della loro applicazione da un repository condiviso e possono creare build di sistema per i test locali. Questo ambiente consente agli sviluppatori di apportare modifiche al codice sulla propria copia e di testarli. Alcuni test sono ad hoc e magari non vengono mai ripetuti. Altri test sono automatizzati. I test automatizzati vengono solitamente mantenuti permanentemente, soprattutto se seguono un approccio Test-Driven.
- Ambiente di integrazione condivisa (continua). Quando gli sviluppatori ritengono che il loro codice sia pronto, caricano le modifiche sul repository di codice condiviso e controllato. L’ambiente CI esegue build automatici ed esegue test automatici utilizzando il repository. A questo punto, il nuovo o modificato codice viene integrato e testato. Il sistema CI esegue test automatici su richiesta, ogni ora o giornalmente, e tutto il team riceve notifiche e può vedere lo stato dei test dell’ultima build integrata. I malfunzionamenti vengono segnalati rapidamente e gestiti con urgenza.
Un ambiente di sviluppo o CI supporta il testing dei programmatori, ma potrebbe non essere disponibile qualche altro server applicativo, servizio web, servizio di messaggistica o database server che completa il sistema.
Se questi sistemi di interfaccia non esistono perché non sono stati sviluppati, o perché appartengono a un'azienda partner e c'è solo un sistema live e nessuna versione di test, allora gli sviluppatori devono simulare o realizzare dei mock di queste interfacce almeno per poter testare il proprio codice.
Gli strumenti di mocking possono essere sofisticati, ma le interfacce simulate in genere non supportano i test che richiedono dati integrati tra più sistemi.
Se è disponibile agli sviluppatori un'interfaccia verso un server di database di test, i dati di test potrebbero essere minimi, non integrati o coerenti, e non rappresentativi dei dati in produzione.
I database di sviluppo condivisi all'interno di un team sono solitamente insoddisfacenti. Se non esiste una buona gestione per questa risorsa condivisa, gli sviluppatori potrebbero riutilizzare, corrompere o cancellare i dati degli altri.
Ambienti di Test a Livello di Sistema
Il test a livello di sistema si concentra sull'integrazione e la collaborazione di componenti e sottosistemi.
Questi ambienti offrono una piattaforma per supportare gli obiettivi di integrazione su larga scala, la validazione della funzionalità e le operazioni di sistema nel contesto dei processi utente o di business.
Gli ambienti possono anche essere dedicati agli aspetti non funzionali del sistema, come le prestazioni, la sicurezza o la gestione dei servizi.
Uno degli errori di test più comuni è quello in cui un tester di sistema nel proprio ambiente sperimenta un tipo di errore che, per quanto si sforzino, lo sviluppatore o il tester non riesce a riprodurre nell'ambiente di sviluppo.
“Sul mio computer funziona!”
“Sì, certo, lo so.”
Questo è quasi sicuramente causato da una mancanza di coerenza tra i due ambienti. La differenza di comportamento potrebbe essere causata dalla configurazione, da versioni diverse dei software, oppure dai dati diversi presenti nel database.
Le differenze nei dati che causano problemi sono la prima cosa da controllare. Di solito sono facili da identificare e spesso possono essere risolte rapidamente.
Quando c'è una differenza di versione o di configurazione del software, tester e sviluppatori possono perdere molto tempo per individuare la causa della discrepanza di comportamento.
Quando si verificano questi problemi, spesso significa che c'è una mancanza di comunicazione tra sviluppatore e test. Può anche indicare una perdita di controllo della configurazione nella predisposizione dell'ambiente per lo sviluppatore o il tester, o nel processo di deployment.
Infrastructure as code e provisioning automatico degli ambienti renderanno i problemi di coerenza degli ambienti un ricordo del passato.
Tipi di Ambienti di Test Dedicati
Per supportare i test di sistema, di accettazione e non funzionali, gli ambienti devono supportare le seguenti attività (potrebbero essercene di più nella vostra organizzazione):
- (Funzionale) Ambiente di test del sistema. In questo ambiente, il sistema viene validato rispetto ai requisiti documentati per l’intero sistema. I requisiti possono essere lunghi documenti di testo con casi di test tabulati definiti per un test di sistema. Nei progetti agili, questo ambiente può essere necessario per permettere ai tester di esplorare il sistema integrato senza limitarsi a funzionalità specifiche.
- Ambiente di test end-to-end. Se l’ambiente di integrazione continua (CI) consente l’integrazione di componenti con sottosistemi, i processi aziendali possono richiedere la disponibilità di altri sistemi d’interfaccia (non sotto il controllo degli sviluppatori). Sono necessari ambienti a pieno ambito per condurre test d’integrazione su larga scala, processi aziendali o test di accettazione generale. Di solito, i dati sono una copia del vivo, o almeno di scala adeguata. Quando occorre dimostrare l’integrazione su larga scala, i flussi di dati e di controllo sono esercitati usando percorsi utente più lunghi e riconciliazioni indipendenti dei dati tra sistemi integrati. Gestire i dati negli ambienti di test è fondamentale. Se già utilizzi Jira, valuta di potenziare la gestione dei dati con strumenti avanzati di gestione dei test progettati per Jira.
- Ambiente di performance. Questi ambienti devono offrire una piattaforma significativa per valutare le prestazioni di un sistema (o di alcuni sottosistemi selezionati). Potrebbero essere possibili compromessi nell’architettura dove esiste ridondanza o clonazione dei server. Tuttavia, i volumi di dati devono avere scala produttiva anche se i dati sono sintetici. Sicuramente, l’ambiente deve essere di scala tale da supportare i volumi di transazione della produzione, per permettere previsioni affidabili sulle prestazioni dei sistemi in produzione.
- Ambienti di Disponibilità, Resilienza e Gestibilità (ARM). Per certi aspetti, questi ambienti sono simili agli ambienti di performance, ma a seconda dell’obiettivo del test, possono essere necessarie delle variazioni. I test di disponibilità mirano a verificare che il sistema possa funzionare per lunghi periodi senza errori. I test di resilienza (spesso chiamati test di failover) controllano che, quando componenti del sistema falliscono, non causino interruzioni inaccettabili al servizio fornito. I test di gestibilità o di operatività dimostrano che le procedure di amministrazione, gestione, backup e ripristino del sistema funzionano efficacemente.
Dati negli Ambienti
In alcuni progetti molto grandi, possono esserci fino a 20 o anche 30 ambienti su larga scala dedicati a diversi aspetti di testing, formazione, migrazione dei dati e prove di cutover. Nei progetti più piccoli ce ne sono meno, forse anche solo uno condiviso o una modalità a delivery continua—e tutti i test potrebbero essere eseguiti automaticamente in ambienti instanziati per un solo utilizzo e poi rimossi.
Tutti gli ambienti necessitano di dati, ma la scala e il grado di realismo di questi dati può variare. Ecco alcuni schemi comuni sul modo in cui i dati di test vengono acquisiti e gestiti. Questi schemi si concentrano sulla proprietà (locale o condivisa), le modalità di creazione (manuale, automatizzata o copiata dalla produzione) e la scala:
- Dati locali, creati manualmente, su piccola scala—adatti per test ad hoc da parte di sviluppatori o tester.
- Dati locali, automatici, sintetici. Adatti a test automatici degli sviluppatori o ambienti in cui si può coprire la funzionalità di specifici moduli o funzionalità.
- Dati condivisi, creati manualmente. Utilizzati in ambienti di integrazione e test di sistema, spesso dove i dati di test si sono evoluti in parallelo a test manuali. Salvati e ripristinati quando necessario.
- Dati condivisi, generati automaticamente. Utilizzati in ambienti di integrazione e test di sistema dove i dati di test si sono evoluti in parallelo a test automatici o manuali. Generati e/o ripristinati da backup quando necessario.
- Dati condivisi su larga scala sintetici/casuali. I test di performance e ARM richiedono dati coerenti in grande quantità. Questi dati generalmente non devono essere significativi – i dati randomizzati vanno bene e vengono generati al bisogno o inizialmente e poi ripristinati dai backup.
- Dati condivisi su larga scala e significativi. I test end-to-end, di accettazione o di utente solitamente richiedono dati significativi su ampia scala. A volte vengono utilizzate copie o estratti da dati live. Attenzione a non violare le normative sui dati se non li mascherate/anonimizzate.
- Re-test e test di regressione. È necessario un dataset conosciuto e controllato, in uno stato conosciuto, di solito ripristinato dai backup. Questo vale per qualsiasi degli ambienti sopra, dato che questi test vanno ripetuti con dati in uno stato noto per riprodurre i guasti in modo affidabile.
Test dell’Infrastruttura
All’inizio di questo articolo abbiamo visto cosa include l’infrastruttura e ci siamo finora concentrati soprattutto sui componenti tecnici, cioè i sistemi software, presumendo che l’hardware—reale o virtuale—sia disponibile.
Quando costruiamo sistemi inizialmente, presumiamo che l’infrastruttura esista e che funzioni correttamente, sia performante, sicura, resiliente, ecc.
Possiamo testare tutti questi aspetti quando abbiamo integrato la nostra applicazione, e senza dubbio così vengono alla luce carenze dell’infrastruttura in una fase relativamente tarda del progetto. Ma trovare problemi di infrastruttura così avanti di solito è estremamente dirompente.
- Le modifiche necessarie per affrontare i guasti dell'infrastruttura potrebbero richiedere una riprogettazione significativa e cambiamenti nella nostra applicazione.
- I risultati dei nostri test sull'applicazione o sull'intero sistema dovranno essere ripetuti.
- Se componenti di terze parti come database, servizi web, di rete o di messaggistica dovessero fallire, siamo alla mercé dei fornitori (o della comunità open source) che li supportano.
Per assicurarci che la nostra fiducia nei componenti infrastrutturali sia ben riposta, possiamo affidarci alla nostra (o all'esperienza altrui) nell'utilizzarli in passato. Oppure dobbiamo valutarne — tramite test — l'affidabilità prima di impegnarci ad utilizzarli nella progettazione e costruzione del nostro sistema.
A seconda dell'infrastruttura oggetto di indagine, l'ambiente che utilizziamo può variare — da un singolo server a una piattaforma infrastrutturale quasi completa.
Nonostante alcuni test saranno manuali, nella maggior parte dei casi useremo strumenti, driver o robot per simulare il carico di transazioni che la nostra applicazione genererebbe. Sarà necessario simulare o emulare queste interfacce:
- Interfacce attualmente non disponibili
- Interfacce verso componenti di cui ci fidiamo e che sono semplici da simulare
- Interfacce fuori ambito che non influenzano l'infrastruttura sotto test.
L'infrastruttura, ovviamente, di solito non funziona tramite un'interfaccia utente o GUI.
L'integrazione della nostra applicazione con l'infrastruttura assumerà per lo più la forma di messaggi o chiamate di servizi remoti. Spesso il traffico da simulare richiede chiamate API verso server web o applicativi, server di messaggistica o database, oppure servizi forniti tramite cloud o sedi remote.
Gli obiettivi di prestazione e ARM possono essere noti, nel qual caso possono essere eseguiti test per assicurarsi che questi obiettivi vengano raggiunti.
Tuttavia, l'infrastruttura è spesso condivisa con altre applicazioni oltre alla nostra, quindi conoscere la capacità massima aiuta a valutare quanta capacità rimarrà quando la nostra applicazione sarà distribuita.
In questo caso, i test infrastrutturali affrontano il rischio sia per la nostra applicazione che eventualmente per altre applicazioni che in futuro potranno basarsi su di essa.
Iscriviti alla newsletter di The QA Lead per essere avvisato quando saranno pubblicate nuove parti della serie. Questi post sono estratti dal corso Leadership In Test di Paul che ti consigliamo vivamente per un approfondimento su questo e altri argomenti. Se lo farai, usa il nostro codice coupon esclusivo QALEADOFFER per ottenere $60 di sconto sul prezzo intero del corso!
Lettura consigliata: 10 MIGLIORI STRUMENTI OPEN SOURCE PER LA GESTIONE DEI TEST
