Leadership nei test: quante prove sono sufficienti?
Nota dell’editore: Benvenuto nella serie Leadership In Test del guru e consulente di testing software Paul Gerrard. Questa serie è pensata per aiutare tester con alcuni anni di esperienza—soprattutto quelli che lavorano in team agili—a eccellere nei loro ruoli di test lead e di gestione.
Nell’articolo precedente, abbiamo delineato un manifesto del rischio per aiutare i manager. In questo articolo, porremo la domanda classica e senza risposta: “Quanti test sono sufficienti?”. Spoiler: dipende dagli stakeholder.
Iscriviti alla newsletter The QA Lead per essere informato quando verranno pubblicate nuove parti della serie. Questi articoli sono estratti dal corso Leadership In Test di Paul che ti consigliamo vivamente per approfondire questo e altri argomenti. Se decidi di acquistarlo, usa il nostro codice coupon esclusivo QALEADOFFER per ottenere $60 di sconto sul prezzo totale del corso!
Quanti test sono sufficienti? Questa è la classica, irrisolvibile, domanda filosofica che tutti i tester si pongono perché la stessa viene posta loro dagli stakeholder.
Gli stakeholder vogliono saperlo perché desiderano avere la certezza che i sistemi siano stati testati adeguatamente, ma, dovendo pagare e rispettare delle scadenze, vogliono anche conoscere il potenziale costo dei test e quanto tempo richiederanno.
Quindi, spetta agli stakeholder giudicare quanti test siano sufficienti. Il tuo compito come test manager è fornire loro quanto più valore possibile per aiutarli a prendere una decisione. In questo articolo, tratteremo:
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
- Il valore dei test per gli stakeholder
- Teoria quantistica e teoria della relatività (non fisica)
- Uso del linguaggio corretto
- Stime, budget e negoziazione
Cominciamo.
Il valore dei test per gli stakeholder
Ogni test che eseguiamo dovrebbe avere valore per gli stakeholder in quanto offre prove a supporto del loro processo decisionale in quattro modi:
- Prove che il sistema soddisferà gli obiettivi di business del progetto.
- Prove che il sistema non fallirà, oppure che, in caso di errore, l’impatto del fallimento sia sopportabile.
- Prove per riprodurre e diagnosticare i fallimenti, nonché riparare e ritestare il sistema fallito.
- Prove a sostegno delle decisioni prese nell’ambito del progetto (accettazione, rilascio, rigetto, ecc.)
Il nostro obiettivo nel testing è creare test che aumentino incrementamente la copertura del sistema rispetto a un modello di test riconoscibile. I nostri test dovrebbero dimostrare che il sistema raggiungerà gli obiettivi di business e che il rischio di fallimento è noto ed eventualmente accettabile.
Dei quattro tipi di prove sopra, i primi tre sono alla base del quarto. In definitiva, gli stakeholder devono poter prendere decisioni basate su prove. Spetta a loro decidere, non ai tester, quindi tocca a loro valutare se dispongono di abbastanza elementi per sentirsi sicuri. In ogni caso, il valore dei test sta negli occhi di chi osserva: lo stakeholder.
Ora, ogni tester prende decisioni su cosa testare utilizzando un modello formale o anche l’intuito. Queste scelte si basano su un valore percepito.
A meno che il tester non sia anche stakeholder, di solito valuta il valore sulla base di una qualche misura di completezza o copertura. Oppure, se conosce le esigenze degli stakeholder, in base all’utilità del test nell’orientare una decisione di accettazione.
I principi sopra esposti hanno alcune importanti conseguenze.
Primo, se non conosci il pensiero dello stakeholder, la tua percezione del valore del test probabilmente non coinciderà con la sua. Se selezioni i test senza riferimento ai loro valori, al momento di presentare i risultati potresti scoprire che gli stakeholder hanno dati insufficienti in certi ambiti e un eccesso in altri. Di certo, non si sentiranno sicuri quanto dovrebbero.
In secondo luogo, quando progetti o esegui un test, qual è il suo contributo alle decisioni dello stakeholder? Se un test non fornisce informazioni incrementali utili a una decisione, o se agli stakeholder non interessa se il test passi o fallisca, allora non ha motivo di esistere in un piano di test.
Abbiamo detto nell’articolo 3 sui modelli che i modelli di test che usi devono essere rilevanti per gli stakeholder. Se i tuoi risultati di test sono riconducibili a modelli che gli stakeholder comprendono e apprezzano, allora anche il tuo contributo sarà valorizzato.
Teoria quantistica e teoria della relatività
Esistono altri due principi legati al valore e all’importanza dei test. Uno lo chiamo Teoria Quantistica e l’altro Teoria della Relatività. Questi nomi suonano pretenziosi (e sono sicuramente ironici), ma descrivono due fenomeni alla base di ogni discussione sul valore dei test, sulle priorità e sui confini del test.
Quando eseguiamo un test, di solito interpretiamo il risultato come un successo o un fallimento. Il giudizio di successo/fallimento è un esito binario – vero o falso, sì o no, uno o zero. Quel risultato del test genera una quantità specifica di prove. Le prove si accumulano man mano che eseguiamo sempre più test. Qualunque sia il risultato, quel test aumenta progressivamente la copertura del nostro modello di test e la conoscenza che abbiamo del comportamento del sistema. I test che non aggiungono conoscenza non aggiungono valore.
Se un test non aumenta progressivamente la copertura in qualche modo, ha poco valore.
Il secondo aspetto è il valore di un test. Qual è il valore di un test? Si può davvero assegnare un valore in dollari, sterline o euro a un singolo test? Probabilmente no. Ma ciò che possiamo fare – e spesso anche piuttosto facilmente – è dire: "questo test vale più di quell'altro".
Supponiamo di utilizzare un modello di copertura del codice come la copertura delle istruzioni. Potremmo eseguire un test che riguarda cinque righe di codice o cinquemila righe di codice. Qual è il valore di ciascuno? È difficile dirlo. Ma se il nostro obiettivo è la copertura delle istruzioni, il secondo test ha più valore.
Non possiamo attribuire un valore assoluto a nessun test, ma di solito possiamo confrontare i test e dedurne un valore relativo. Cioè, se siamo sotto pressione temporale, possiamo di solito dire che un test ha meno valore di un altro e quindi eventualmente escludere il primo test se necessario.
Possiamo confrontare il valore dei test ma solo se provengono dallo stesso modello.
Bisogna però sottolineare che questi confronti sono davvero significativi solo se condividono lo stesso modello. Un test che copre un'ampia gamma di condizioni estreme in un processo probabilmente ha più valore di un test del percorso "diretto". I test end-to-end di un processo complesso, ad esempio, non possono essere confrontati direttamente con i test unitari di componenti critici.
Sebbene le teorie quantistiche e della relatività non si applichino direttamente al testing, i principi di adattabilità e prospettiva sì. Trova uno strumento di gestione dei test che sia in linea con questi principi per ottimizzare la tua strategia di test.
Usare il Linguaggio Giusto
Ora che abbiamo chiarito chi è responsabile per decidere "quanti test sono sufficienti", come possiamo noi, in quanto tester coscienziosi, sostenere questo processo decisionale?
Si noti che il nostro trattamento del valore dei test è molto simile alla nostra valutazione dei rischi. Come discusso nel precedente articolo, è molto difficile dare valori numerici all'entità o all'esposizione al rischio. Tuttavia, di solito è possibile confrontare un rischio con un altro e classificarli per effettuare scelte sui rischi da includere nel testing.
Utilizzando il linguaggio del rischio, i tester saranno ascoltati dalla direzione.
I leader dei team di sviluppo sembrano spesso essere ascoltati dai dirigenti, anche quando parlano in termini tecnici. La differenza è che presentano la tecnologia come entusiasmante e vantaggiosa. Quando i tester parlano nei propri termini tecnici – dei dettagli "burocratici" dei test, come le statistiche sugli incidenti – il messaggio tende a essere negativo, e i dirigenti possono annoiarsi o irritarsi.
La dirigenza può già pensare che i tester siano una specie un po' noiosa, ma si potrebbe sostenere che questo avviene perché molti manager non comprendono davvero cosa fanno i tester e quale valore aggiungano. Quindi i tester dovrebbero elevare il proprio linguaggio al livello della direzione.
Il testing basato sul rischio parla alla direzione utente e alla gestione di progetto nel loro linguaggio.
Queste sono persone che ragionano molto in termini di rischi e benefici. Se i tester si rivolgono loro con questi termini, è più probabile che la direzione li ascolti e quindi prenda decisioni migliori. Ricollegando i test agli obiettivi del progetto, possiamo concentrare l’attenzione sui deliverable di maggior valore per gli stakeholder, così da dedicare tempo a testare le cose più importanti.
Inoltre, man mano che si avanza nel testing, possiamo dimostrare che i benefici di maggior valore sono ora disponibili. La decisione di rilascio è in ultima analisi un giudizio sul fatto che i benefici ottenuti superino i rischi, quindi i test forniranno dati migliori alla direzione su cui basare le decisioni.
Utilizza il linguaggio del rischio (e dei benefici) per determinare gli ambiti, pianificare e riportare i progressi del testing.
I tester ovviamente devono parlare tecnicamente con gli sviluppatori e con il personale tecnico. Ad esempio, la qualità dei report sugli incidenti è un fattore chiave per correggere rapidamente e in modo affidabile i difetti. Intendo semplicemente dire che, parlando con la direzione, il tester si esprime in termini di rischi affrontati e ancora aperti, anziché di test, incidenti e difetti.
Stime, Budget e Negoziazione
All’inizio di un nuovo progetto, il project manager ti chiede: “Ho bisogno di pianificare e assegnare le risorse per il testing in tempo utile, puoi darmi una stima di quante persone e quanto tempo ti serviranno per fare il system testing?”
Ci rifletti un po' e vai a parlare con il capo.
“Mi servono sei tester per otto settimane.”
Il project manager riflette un attimo e consulta il suo programma preliminare e il piano delle risorse.
“Puoi avere quattro tester per sei settimane e basta.”
Tu obietti e dici: “Ma ci vorrà più di sei settimane! Costarà di più di quanto hai stanziato per testare questo sistema. Il sistema è più grande dell’ultima volta. È più complicato. È sicuramente troppo rischioso risparmiare sui test questa volta. Semplicemente non basta.”
Ma il manager è irremovibile, borbottando qualcosa su altre dipendenze, autorità superiori e così via…
Che senso ha fatto una stima se il manager sapeva già quale doveva essere il budget? Che rilevanza ha un budget arbitrario rispetto al lavoro da svolgere? Perché non prendono mai sul serio il testing? Gli sviluppatori hanno sempre il tempo che chiedono, no? Non sembra giusto.
Potresti sentirti contrariato e pensare che il tuo giudizio professionale sia sminuito. Ma il problema è, ed è sempre stato, che il budget del test in questa situazione era fisso. Tutto ciò che puoi fare è capire quale sia il testing migliore o più prezioso che puoi inserire nel tuo budget.
Ma spesso, il PM vuole davvero sapere quanto tempo ci vorrà per poter aggiustare il piano. Se pensi di essere in una negoziazione, ti servono delle leve per trattare. Devi anche discutere degli esiti del piano, non degli input. L’ambito è un risultato della pianificazione, lo sforzo che applichi è un input.
Devi negoziare l’ambito.
La negoziazione dei budget dei test dovrebbe sempre riguardare l’ambito, non lo sforzo.
L’ambito può presentarsi in uno o più formati diversi, e il modo in cui presenti e discuti l’ambito può cambiare, ma ecco alcuni schemi comuni. Qualunque sia l’ambito, dovrai usarlo come base per la tua stima e la sua difesa:
Ambito come inventario di requisiti o funzionalità
Quando la stima viene ridotta del 30% chiedi: “Quale 30% del sistema non dovrei testare?”
Ambito come inventario dei rischi
Quando la stima viene ridotta del 30% chiedi: “Quali rischi degli stakeholder dovrò togliere dal piano?”
Ambito come modello tabellare o grafico
Quando la stima viene ridotta del 30% chiedi: “Quali percorsi/itinerari/elementi dovrò segnalare agli stakeholder che non saranno testati?”
Spero che tu abbia capito cosa sta succedendo qui.
- L’ambito dei test si basa su un modello discusso e concordato prima con gli stakeholder. Questo ambito è provvisorio, soggetto a risorse e tempi disponibili, e dovresti renderlo chiaro agli stakeholder.
- Fai una stima in base a questo ambito provvisorio. Usa il modello (rischi, requisiti, processi aziendali o altro) per definire un obiettivo di copertura, contare gli elementi di copertura e poi stimare di conseguenza.
- Fai una discussione con il Project Manager. Se la stima è troppo alta, usa le risposte sopra indicate per avviare la discussione con gli stakeholder.
Come tester o test manager, non sei nella posizione ideale per negoziare i test con il project manager. Gli stakeholder hanno delle preoccupazioni e, se condividi i modelli che definiscono l’ambito dei test, avranno opinioni, accetteranno l’ambito e potranno difenderlo. Gli stakeholder sono anche responsabili della giustificazione del budget per il loro sistema, quindi sono i più adatti a bilanciare i costi dei test con la necessità di affrontare le loro preoccupazioni.
Qualche spunto di riflessione
Pensa a chi, nei tuoi progetti, si assume la responsabilità della quantità di test da eseguire:
- Sei tu come tester a definire l’ambito e la quantità di test?
- È il project manager a fissare un budget e tu fai il meglio che puoi con il tempo assegnato?
- L’ambito viene negoziato con il project manager e gli stakeholder per concordare un equilibrio tra lo sforzo e l’ampiezza dei test da eseguire?
Una delle responsabilità chiave di un tester è assicurarsi che il progetto sia consapevole dei rischi di prodotto che si stanno correndo e di documentarli. Solo se questi rischi sono evidenti il management potrà riconoscere i rischi che assume comprimendo i test.
Non esiste una formula per la quantità giusta di test. Nella maggior parte degli ambienti lavorativi, il livello dei test può essere determinato solo tramite un consenso tra project management, sponsor del cliente, sviluppatori, specialisti tecnici e tester: i test rientrano nell’ambito se affrontano i rischi di interesse.
La quantità sufficiente di test dovrebbe essere determinata per consenso, con il tester che facilita e contribuisce al processo di consenso fornendo le informazioni necessarie.
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 caldamente per approfondire questo e altri argomenti. Se lo fai, usa il nostro esclusivo codice sconto QALEADOFFER per ottenere $60 di sconto sul prezzo intero del corso!
Articoli correlati: