Leadership nei Test: Modellizzazione e Copertura
Nel mondo del collaudo software, una leadership efficace sa come definire una direzione chiara affinché le strategie di test siano allineate agli obiettivi di sviluppo. Con la crescente complessità dei sistemi software, i metodi di test tradizionali fanno fatica a tenere il passo.
Ed è qui che approcci innovativi come la modellazione dei test e l'analisi della copertura diventano fondamentali. Queste pratiche assicurano che i team coprano percorsi critici e casi limite e favoriscono una migliore collaborazione, un rischio ridotto e una consegna più rapida.
In questo articolo esploreremo cosa significa guidare con un focus sulla modellazione e sulla copertura. Discuteremo di come i responsabili dei test possano sfruttare queste strategie per ottimizzare i processi, migliorare la qualità del prodotto e garantire una copertura di test completa—tutto favorendo una cultura dell'eccellenza e della responsabilità. Che tu sia un responsabile QA, un team lead o semplicemente desideri approfondire la tua comprensione sulla leadership nel testing, questa guida ti offrirà spunti e tecniche pratiche per portare il tuo approccio di test a un livello superiore.
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
Immergiamoci.
Cos'è un modello di test?
Il test è un processo in cui creiamo modelli mentali dell'ambiente, del programma, della natura umana e dei test stessi. Ogni modello viene utilizzato fino a quando non accettiamo che il comportamento sia corretto oppure finché il modello non è più sufficiente allo scopo.
Boris Beizer, Tecniche di test del software, 1990
La progettazione dei test è il processo con cui selezioniamo, tra la miriade di opzioni disponibili, i test che riteniamo più preziosi per noi e per le parti interessate. I modelli di test ci aiutano a selezionare i test in modo sistematico e sono fondamentali per il testing.
Come utilizzano i tester i modelli:
- Individuiamo ed esploriamo le fonti di conoscenza per costruire modelli di test.
- Usiamo questi modelli per mettere in discussione e validare le nostre fonti, migliorando sia le fonti che i modelli.
- Usiamo questi modelli per guidare il testing, ma anche lo sviluppo.
Data una missione di test, il nostro primo compito è identificare le fonti di conoscenza. Queste possono essere:
- Documentazione: specifiche, progetti, requisiti, standard, linee guida, ecc.
- Persone: Stakeholder, utenti, analisti, progettisti, sviluppatori e altri.
- Esperienza: la tua conoscenza ed esperienza di sistemi simili (o dissimili), le tue preferenze, pregiudizi, intuizioni, credenze e bias.
- Nuovo sistema: il sistema sotto test, se esiste, è disponibile e accessibile.
- Vecchio sistema: il sistema da sostituire è ovviamente una fonte – in alcune aree funzionali, può fornire un oracolo per il comportamento atteso.
È importante notare che tutte le nostre fonti di conoscenza sono fallibili e incomplete, così come i nostri modelli. I tester usano esperienza, competenza e giudizio per vagliare queste fonti, confrontarle, metterle in discussione e raggiungere un consenso.
Tutti i modelli sono sbagliati, alcuni sono utili
George Box, Economista.
Un modello di test può consistere in una checklist o un insieme di criteri. Potrebbe anche essere un diagramma derivato da un documento progettuale o un'analisi di un testo narrativo. Molti modelli di test non vengono mai messi per iscritto—possono anche essere modelli mentali costruiti appositamente per guidare il tester mentre esplora il sistema sotto test.
Lo scopo dei modelli è semplificare situazioni complesse, omettendo dettagli che non sono rilevanti in questo momento. Usiamo i modelli per semplificare un problema—come la selezione degli elementi da testare, per esempio. Il modello informa il nostro pensiero e selezioniamo i test identificando le occorrenze di alcuni aspetti chiave del modello.
Potremmo selezionare rami in un diagramma di flusso o diagramma di controllo di flusso, transizioni di stato in un modello di stati, confini in un modello di dominio di input (o di output) e scenari derivati da user story scritte nel linguaggio specifico di dominio Gherkin.
Attenzione però, a volte i modelli fanno omissioni che non sono sicure—magari il modello semplifica eccessivamente una situazione—e occorre stare attenti a questo. Per rendere i tuoi modelli di test più efficienti, è fondamentale utilizzare software di gestione dei test specializzati.
Se non abbiamo modelli direttamente dalle nostre fonti, dobbiamo inventarli. Per esempio, quando i requisiti sono presentati come testo narrativo, dobbiamo usare il linguaggio dei requisiti per derivare le funzionalità e la logica dei loro comportamenti. Questo può essere difficile per sviluppatori e tester, e spesso è uno sforzo collaborativo, ma è necessario insistere.
Usare i modelli per testare
Utilizziamo i modelli di test per:
- Semplifica il contesto del test. Dettagli irrilevanti o trascurabili vengono ignorati nel modello.
- Concentra l’attenzione su una sola prospettiva del comportamento del sistema. Queste possono essere funzionalità critiche o rischiose, aspetti tecnici, operazioni utente di interesse o aspetti della costruzione o architettura del sistema.
- Genera un insieme di test unici (nel contesto del modello) che siano diversi (rispetto a quel modello).
- Permetti che il test possa essere stimato, pianificato, monitorato e valutato per la sua completezza (copertura).
Dal punto di vista del tester, un modello ci aiuta a riconoscere aspetti del sistema che potrebbero essere oggetto di test.
Modelli e Copertura
Copertura è il termine che usiamo per descrivere la completezza o l’esaustività dei nostri test rispetto al nostro modello di test. Un elemento di copertura è qualcosa che vogliamo esercitare nei nostri test.
Idealmente, il nostro modello di test dovrebbe identificare gli elementi di copertura in modo oggettivo. Quando abbiamo pianificato o eseguito test che coprono gli elementi identificati dal nostro modello, possiamo quantificare la copertura raggiunta e, come proporzione di tutti gli elementi nel modello, esprimere tale copertura come una percentuale.
Qualsiasi modello che permetta di identificare elementi di copertura può essere usato.
I modelli sono spesso grafici, con esempi quali diagrammi di flusso, casi d’uso, diagrammi di sequenza, e così via. Questi e molti altri modelli hanno elementi (o bolle) collegati da linee o frecce. Questi sono solitamente chiamati grafi orientati.
Immagina un modello grafico che comprende bolle e frecce. Si potrebbero definire almeno due obiettivi di copertura:
- Copertura di tutte le bolle
- Copertura di tutte le frecce
- E così via
Quindi, qualunque modello che sia un grafo orientato può essere trattato allo stesso modo.
Un modello formale consente di identificare in modo affidabile gli elementi di copertura. Si può quindi definire una misurazione quantitativa della copertura, che può essere usata come obiettivo misurabile.
I modelli informali tendono ad essere liste di controllo o criteri utilizzati per individuare elementi di copertura, stimolare idee per test, o per il testing durante una sessione esplorativa. Queste liste o criteri possono essere predefiniti o preparati come parte di un piano di test o adottati durante una sessione di testing esplorativo.
I modelli informali si differenziano da quelli formali perché l’individuazione degli elementi di copertura dipende dall’esperienza, intuizione e immaginazione del professionista, quindi la copertura con questi modelli non può mai essere quantificata. Non potremo mai sapere cosa significhi copertura completa rispetto a questi modelli.
I test derivati da un modello informale sono validi quanto quelli ricavati da un modello formale se aumentano la nostra conoscenza del comportamento o delle capacità del sistema.
I Modelli Semplificano, Quindi Usane Più di Uno
Un buon modello fornisce un modo per comprendere la complessità e lo fa anche escludendo dettagli che non sono rilevanti. Il tuo modello potrebbe utilizzare il concetto di stato, modalità di guasto o flussi, combinazioni di input, valori di dominio e così via.
Un solo modello non è mai sufficiente per testare pienamente un sistema. Tutti i modelli apportano dei compromessi, perciò occorrono più modelli. Questo concetto viene solitamente indicato come ‘mezze misure varie’. Ciò significa che abbiamo bisogno di una varietà di modelli parziali per testare adeguatamente un sistema.
Anche se di solito non sono descritti in questi termini, le fasi di test in un progetto a cascata utilizzano modelli da prospettive differenti. Test di unità, integrazione di sottosistemi, test a livello di sistema e test utente hanno tutti obiettivi differenti; ciascuno usa un modello e una prospettiva diversi – ed è da qui che nasce la diversità.
Utilizzare i Modelli per Gestire
I modelli sono al centro del testing e anche della gestione dei test. Ci sono quattro aspetti chiave in questo:
- Coinvolgimento degli stakeholder
- Ambito
- Copertura
- Stima e Monitoraggio dei Progressi
Coinvolgimento degli stakeholder
Quando pianifichiamo e definiamo l’ambito dei test e spieghiamo ai portatori di interesse i progressi e il significato della copertura, dobbiamo usare modelli che siano comprensibili e significativi rispetto agli obiettivi degli stakeholder.
Se pianifichiamo un test con utenti, probabilmente adotteremo il flusso di processo aziendale come modello e come modello di riferimento per tracciare i percorsi e mettere alla prova le funzionalità di sistema rilevanti per l’utente. Se stiamo verificando l'integrazione dei servizi per conto di un architetto tecnico, useremo il modello architetturale, diagrammi di collaborazione, specifiche di interfaccia, e così via come base per i nostri test. Se stiamo testando funzionalità definite dagli utenti, utilizzeremo le user story prodotte dal lavoro collaborativo sui requisiti effettuato in precedenza.
Se gli stakeholder non comprendono i tuoi modelli, non capiranno, non avranno fiducia e non investiranno nel tuo testing. Potrebbero addirittura non fidarsi di te.
Gestione dello Scope
La prima attività in una disciplina basata sul pensiero sistemico è definire il perimetro del sistema. Nel testing, il primo modello che definisci ti aiuterà a circoscrivere il perimetro dei test. Il diagramma qui sotto è uno schema dell’architettura di sistema – un ‘sistema di sistemi’ – all’interno di un’organizzazione.
Ogni sistema (i cerchi concentrici) si trova in un’area applicativa come CRM, contabilità o il sito web. Tutti i sistemi e le aree applicative fanno parte del ‘sistema di sistemi’. Non ci sono dettagli sul modello, ovviamente, ma è evidente come ogni sistema si inserisca nell’architettura globale.
Potremmo facilmente definire l’ambito dei nostri test, per esempio, sui sistemi ERP.
Nel secondo diagramma qui sotto, abbiamo aggiunto qualche dettaglio in più all’architettura del sistema e suggerito tre modalità in cui potremmo definire lo scope in modo più specifico.
- I sistemi evidenziati in giallo sono i cosiddetti systems of record. Questi sistemi potrebbero, ad esempio, condividere un database, e modifiche allo schema del database potrebbero impattare negativamente su uno qualsiasi di questi sistemi – e rientrare nell’ambito del test.
- I sistemi racchiusi dalla linea viola potrebbero condividere alcune funzionalità o infrastrutture comuni – per esempio, potrebbero tutti usare uno stesso set di web services, lo stesso sistema di messaggistica, o girare sullo stesso server.
- La linea blu tratteggiata indica un percorso utente che attraversa i sistemi collegati dalla linea. Forse il percorso è cambiato e la nostra attenzione è sulla coerenza e l’accuratezza del flusso dati tra questi sistemi.
Un modello può mostrare ciò che è incluso nello scope dei test ma, altrettanto importante, anche ciò che è escluso.
Un modello aiuta a definire l’ambito di un test e anche a spiegare lo scope agli stakeholder in termini che comprendono, apprezzano e (si spera) approvano.
Quando usiamo un modello per definire lo scope, il modello ne definisce il territorio e gli elementi in scope identificano i luoghi che intendiamo esplorare e testare.
Gestione della Copertura
La misurazione della copertura può rendere il testing più gestibile. Se non abbiamo una nozione di copertura, potremmo non essere in grado di rispondere a domande come: ‘cosa è stato testato?’, ‘cosa non è stato testato?’, ‘abbiamo finito?’, ‘quanti test restano?’ Questo è particolarmente scomodo per un test manager.
Il livello di copertura che intendiamo raggiungere è il naturale passo successivo una volta definito lo scope.
Usiamo il modello di scope per definire dove andremo a testare. Il nostro modello di copertura spiega agli stakeholder con quale grado di approfondimento intendiamo testare in quei punti.
I modelli di test e le misure di copertura possono servire a definire obiettivi quantitativi o qualitativi per la progettazione e l’esecuzione dei test. A diversi livelli possiamo usare tali obiettivi per pianificare e stimare. Possiamo anche misurare i progressi e dedurre il livello di approfondimento o completezza dei test pianificati o effettuati. Tuttavia, dobbiamo prestare molta attenzione alle metriche di copertura quantitative o percentuali che utilizziamo.
Una metrica di copertura (basata su un modello di test formale) può essere calcolata oggettivamente, ma non esiste alcuna formula o legge che dica che X copertura equivalga a Y qualità o Z livello di fiducia. Tutte le metriche di copertura forniscono solo indicazioni indirette, qualitative e soggettive sul grado di approfondimento o di completezza dei nostri test. Non esiste alcuna relazione significativa tra copertura e la qualità o accettabilità dei sistemi.
Gli obiettivi quantitativi di copertura sono spesso usati per definire i criteri di uscita alla fine dei test, ma tali criteri sono arbitrari. Un obiettivo di copertura più stringente potrebbe generare il doppio degli elementi da coprire. Tuttavia, il doppio dei test a un costo doppio non rende un sistema due volte più testato o due volte più affidabile. Un’interpretazione di questo tipo è priva di senso e fuorviante.
A volte, i modelli formali utilizzati per definire e costruire un sistema possono essere imposti ai tester affinché li utilizzino per definire gli obiettivi di copertura. Altre volte, i tester possono avere poca documentazione a disposizione e devono creare modelli propri. La selezione di qualsiasi modello di test e obiettivo di copertura è in qualche modo arbitraria e soggettiva. Di conseguenza, i modelli di test e le misure di copertura informali possono essere utili quanto i modelli formali e consolidati.
Esercizio rapido di creazione modelli
Un esercizio veloce per concludere. Nei seguenti esempi, abbozza come pensi che potrebbe apparire il modello – solo la sua forma – sia come immagine/diagramma, tabella o elenco:
- Gli utenti sono interessati ai percorsi end-to-end nel sistema.
- Un servizio di messaggistica può trovarsi in quattro stati: spento, in esecuzione, in avvio e in spegnimento.
- Un calcolatore di premi assicurativi ha 40 valori di input che, combinati, influenzano il calcolo; esistono delle dipendenze tra alcuni input.
- Un processo di estrazione/trasformazione/caricamento ha sette fasi. Dopo l’estrazione, ogni fase o rifiuta i record, li invia a un file di sospensione oppure li trasforma e li passa alla fase successiva. L’ultima fase è un processo di caricamento, che gestisce i rifiuti. Verifica che tutti i record estratti siano contabilizzati.
Iscriviti alla newsletter di The CTO Club per ulteriori approfondimenti sul testing!
