Leadership nei Test: Pianificazione dei Test
Nota dell’editore: Benvenuti nella serie Leadership In Test a cura del guru e consulente di testing software Paul Gerrard. La serie è pensata per aiutare i tester con qualche anno di esperienza — soprattutto quelli in team agili — a eccellere nei propri ruoli di test lead e gestione.
Nell’articolo precedente abbiamo approfondito la documentazione e alcune best practice. Stavolta applichiamo molte delle conoscenze degli articoli precedenti e le usiamo per pianificare un progetto di test.
Iscriviti alla newsletter The QA Lead per ricevere notifiche quando usciranno nuovi episodi della serie. Questi post sono estratti dal corso Leadership In Test di Paul, che raccomandiamo fortemente per un approfondimento su questo e altri argomenti. Se decidi di acquistarlo, usa il nostro codice coupon esclusivo QALEADOFFER per ottenere $60 di sconto sul prezzo intero del corso!
Cos’è realmente un Piano?
Un piano di progetto combina i compiti del progetto, le durate stimate, le dipendenze e i deliverable in un modello programmato della realtà.
Se consideri il piano come una previsione del futuro sarai molto cauto nel farci affidamento, ma è proprio ciò che di solito facciamo.
Potresti aver incontrato project manager che trattano il loro piano come una realtà personale — un loro mondo illusorio. Ma non dovremmo essere troppo severi con i project manager: spesso sono motivati a creare un piano e a rispettarlo a ogni costo.
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 piano non è la realtà; è un modello della realtà che richiede continui cambiamenti.
In questo articolo coprirò tutte le fasi della pianificazione dei test, incluse:
- Deliverable
- Come
- Risorse
- La tua rete di supporto
- Stime
- Dipendenze, Rischi e Assunzioni
- Comunicazione, Impegno e Report sullo Stato di Avanzamento
Ma prima, cerchiamo di chiarire l’utilità di un piano.
Perché pianificare?
Lo scopo della pianificazione è solitamente quello di creare un approccio condiviso, un insieme di impegni, dipendenze, costi e un programma per la realizzazione di un progetto. Il piano rappresenta un’intesa tra stakeholder di progetto, fornitori e partecipanti che tipicamente include quanto segue:
- Quali risorse sono necessarie e quando
- Quando le attività devono iniziare e terminare e chi le eseguirà
- Le competenze necessarie per completare le attività
- Gli strumenti e le tecnologie di supporto al piano
- I deliverable e quando saranno consegnati
- I costi di sforzo e risorse richiesti
- Il processo per far avanzare il progetto/il processo attraverso le sue fasi
- I rischi che minacciano la delivery.
Alcuni di questi aspetti potrebbero essere già specificati in una strategia o già operativi. Potrebbe essere già noto, ad esempio, quali fornitori sono coinvolti e cosa faranno per il progetto. Gli strumenti e le tecnologie da usare potrebbero già essere individuati e disponibili. Persone, ambienti di test e dati potrebbero essere pronti. Potrebbe anche esserci una strategia che definisce processo, approccio o tecniche da adottare.
Ma, mentre la strategia definisce i principi o la teoria, il piano descrive la praticità o la logistica necessari per realizzare realmente il progetto.
La strategia definisce come un progetto sarà eseguito in linea di principio, il piano definisce e conferma come il progetto sarà eseguito in pratica.
Per molti project manager il piano è ciò che si trova in Microsoft Project, ma un piano efficace dipende dal fatto che tutti i partecipanti al progetto sappiano cosa devono fare e come. Per ottenere questo risultato, il piano e la conoscenza di come si faranno le cose devono essere comunicati e condivisi da tutti gli attori coinvolti.
La pianificazione è un percorso, non un compito
Citando l’ex Presidente degli Stati Uniti Dwight D. Eisenhower: “La pianificazione è tutto. Il piano non è nulla.” Questo pensiero è così importante da meritare di essere ripetuto in quasi ogni contesto di lavoro nei progetti informatici. Ma cosa significa dire che il piano non è nulla? Che senso ha pianificare se il risultato è un piano senza valore?
Il piano che si ottiene alla fine non è mai inutile, ma il pensiero di Eisenhower si riferisce all’atto della pianificazione e al suo valore rispetto al piano stesso. Confrontiamo rapidamente come funziona la pianificazione nei progetti lunghi e strutturati rispetto ai progetti agili/continuativi.
Pianificazione strutturata vs Agile
In un progetto a lungo termine, la tua azienda, i fornitori e il personale IT interno devono sapere quale impegno è richiesto, così da poter programmare la disponibilità delle persone e delle risorse fisiche.
Raccogliere le informazioni necessarie per creare un piano richiede tempo prezioso. Con tutte le dipendenze da risorse e persone, e l’impegno e le prestazioni sia dei fornitori che del personale interno, molte cose possono andare storte. Alcune cose andranno storte. Per questo motivo, il piano, in quanto previsione del futuro, è pieno di difficoltà.
Il giorno dopo la pubblicazione di un piano, e ogni giorno successivo, emergono nuove informazioni e sono necessari degli aggiustamenti. I requisiti vengono eliminati; i fornitori consegnano in ritardo; ambienti, dati di test o strumenti non sono pronti in tempo. E l’elenco continua. La pianificazione non è mai un’attività una tantum, è un’attività continua — quasi quotidiana.
Spesso gli eventi non pianificati vengono trattati come rumore di fondo e non ricevono molta attenzione. Ma, successivamente, alcuni di questi piccoli problemi diventano grandi ostacoli. Una delle sfide dei progetti a cascata è che questi continui aggiustamenti possono diventare pesanti, poiché ogni cambiamento viene visto come una modifica non necessaria. I progetti spesso proseguono comunque, sperando che le cose vadano “bene la sera dell’evento”. Ma questo accade raramente ed è stato detto molte volte:
Come fa un progetto a diventare in ritardo di un anno? Un giorno alla volta.
L’approccio agile nasce in parte come reazione alla frustrazione derivante dai piani fissi o inflessibili. L’agilità è l’alternativa collaudata all’inerzia dei metodi pesanti e a fasi. Ma questo significa che i progetti agili non fanno pianificazione? No.
Anche nell’agile è necessaria una certa pianificazione iniziale per strutturare il lavoro, organizzare le risorse e pianificare — almeno ad alto livello — il processo di rilascio nei mesi successivi. Tuttavia, iterazione dopo iterazione, e spesso giorno per giorno, il piano complessivo viene costantemente aggiustato per tener conto degli eventi e delle nuove informazioni che emergono.
La pianificazione è un percorso di apprendimento continuo, non un’attività con un risultato fisso.
Pianificazione dei test
Finora abbiamo esaminato la pianificazione del progetto in generale e suggerito che si tratta di un’attività continua. Ora ci concentriamo specificamente sulla pianificazione dei test nei progetti.
La pianificazione dei test è molto simile alla pianificazione di progetto – in realtà è solo un piano su scala minore. Naturalmente, il piano di test deve anche integrarsi con il piano di progetto più generale, perché dipende da altre attività e deliverable (e altre attività dipendono dai test). Spesso i piani di test vengono sconvolti perché queste dipendenze non sono soddisfatte.
I piani di test sono relativamente semplici nel complesso. Potrebbero esserci molte attività che dipendono dal progetto principale. Queste spesso compaiono come compiti nel più ampio piano di progetto. Ma queste attività vengono distribuite nel team, magari con un vasto inventario di elementi di test da pianificare e per cui eseguire i test.
Questo livello di dettaglio non è così rilevante per la pianificazione del project manager ed è solitamente definito e gestito a livello locale all’interno del team di test.
Vediamo ora alcuni degli elementi principali del tuo piano di test.
Deliverable
Quali sono i deliverable dei test?
Che domanda! Sicuramente saranno le specifiche di test, i test, i risultati e i report? I deliverable sono essenzialmente contenuti nella documentazione, quindi tutto ciò di cui dovremmo preoccuparci è produrre la documentazione e spuntare delle caselle.
Ma questo approccio, sebbene diffuso, è in parte responsabile della reputazione che hanno i test (e i tester) di essere costosi, lenti e burocratici, con poco valore reale. Dopotutto, chi legge davvero questi documenti voluminosi?
Supponiamo che in un progetto agile non ci sia intenzione di produrre documentazione di test. È probabile che sia così, quindi cosa fornisce effettivamente il testing in queste situazioni? Che valore ha il testing, in definitiva? È un po' tardi per farsi queste domande, vero?
Quando viene testato un componente, un sottosistema o l’intero sistema, il risultato è costituito da evidenze di come il sistema si comporta in una situazione o contesto particolare. Le evidenze sul comportamento del sistema vengono raccolte e riunite per essere presentate agli stakeholder (sviluppatori, utenti, manager, ecc.) così che possano prendere decisioni: correggere bug, integrare un componente, accettare o rifiutare funzionalità, rilasciare o distribuire un sottosistema o l’intero sistema.
Il deliverable dei test è l’evidenza del comportamento del sistema utilizzata dagli stakeholder per prendere una decisione.
Ora, in alcuni progetti, è essenziale fornire documentazione di test che registri come è stato definito, progettato, implementato ed eseguito un test. Ma è l’evidenza del comportamento del sistema che rappresenta il vero deliverable di valore per gli stakeholder.
Il valore del testing è il livello di fiducia che gli stakeholder hanno nel prendere decisioni basate sulle evidenze dei test.
Queste evidenze possono essere raccolte, tabulate e analizzate sistematicamente in sofisticate soluzioni di gestione dei test e presentate agli stakeholder in formati grafici eleganti. Oppure, degli appunti scritti a mano possono essere usati da un tester per raccontare verbalmente la storia dei test a un product owner durante una riunione stand-up.
Indipendentemente da come vengono raccolte e presentate, il compito finale del testing è la consegna delle evidenze.
Come
Indipendentemente dalla scala del progetto o dalla metodologia, il testing dipende da una certa serie di attività. Esamineremo un processo generico dal punto di vista del tester (o del team) e poi vedremo alcune delle variazioni che si possono verificare.
Ci sono quelle che potremmo chiamare "attività di test" e ci sono attività di "supporto al test" o "logistiche". Per essere sicuri di includere tutte le attività nel piano, potreste trovare utili le tabelle qui sotto come checklist.
Un'attività nella tabella sopra che potresti non riconoscere subito è l'attività di feedback. Sicuramente ti sarà già capitato di lavorare con requisiti poco chiari.
L'attività di feedback, revisione e contestazione è quella in cui i tester, dopo aver riflettuto e modellato un requisito, individuano criticità e possono utilizzare esempi per dimostrare dove i requisiti sono mancanti, ambigui o contraddittori.
Se ritieni che i requisiti siano inadeguati, vale sicuramente la pena prevedere questa attività.
Logistica del Test
La logistica di test supporta le attività di test sopra citate. Sebbene la lista delle attività di test che ho fornito sia ragionevolmente completa, la logistica di test varia con ogni progetto e organizzazione. La lista seguente quindi non è esaustiva. Nel tuo progetto, prenditi il tempo di riflettere su ogni attività o dipendenza necessaria per realizzare il testing.
Risorse (umane, fisiche)
Spesso usiamo la parola risorse per riferirci alle persone nei nostri progetti e, per alcuni, questo può risultare sgradevole. Le persone non sono cose, sono esseri umani ovviamente. Nei progetti più piccoli, può essere possibile usare i nomi, ma nelle grandi organizzazioni, quando sono coinvolti team di progetto che potrebbero non essere ancora composti, un numero di risorse è semplicemente una sintesi per indicare un numero di persone.
Ancora più importante, non è necessariamente il numero di persone che conta – sono le loro competenze quelle che fanno davvero la differenza. Ovviamente, le persone lavorano in modi diversi e solitamente a velocità diverse, quindi dovrai considerare questo aspetto nella tua pianificazione.
Oltre alle persone, a diversi stadi, serviranno diverse risorse fisiche affinché il testing possa proseguire. Queste variano dalle più banali alle altamente specifiche e la mancanza di una qualsiasi di esse può compromettere la missione di testing.
Potresti già essere abbastanza fortunato da avere accesso a un laboratorio di test completamente attrezzato, gestito e dedicato. Se non ce l’hai, dovrai forse specificare tutto – dallo spazio fisico e l’arredo fino ai post-it e le gomme – per definire il tuo ambiente di lavoro.
Nella tabella qui sotto sono indicate alcune delle risorse tipiche richieste. La tua lista sarà sicuramente diversa.
Quando hai identificato tutte le risorse necessarie per realizzare il tuo piano, valuta se sia necessario aggiungere ulteriori attività nel tuo piano per acquisirle.
La tua rete di supporto
Se le persone e le competenze di cui hai bisogno per fare testing fossero sotto il tuo controllo, i progetti potrebbero essere molto più semplici! Ma pochi team hanno tutte le competenze necessarie, oppure l'autorizzazione e l'accesso alle risorse fisiche necessarie. Molti progetti sono organizzati e gestiti secondo il modello del management a matrice. I membri chiave del team in realtà rispondono ai manager di altri reparti specialistici e otterrai da loro un impegno limitato.
Potresti dover specificare un certo numero di ore al giorno o pianificare orari per accedere alle competenze specialistiche sopra menzionate. A volte, ti verrà chiesto quale livello di servizio sia accettabile, ad esempio "le richieste ad alta priorità riceveranno risposta entro trenta minuti" e così via.
Stime
Stimare nei progetti software è un compito complicato. Molto è stato scritto su quanto sia difficile o persino impossibile fare delle stime. Ma le stime sono richieste in tutti i progetti e più il progetto è grande, più ne dipendiamo.
Abbiamo bisogno di stime per creare una pianificazione, ma il problema è che la stima non garantisce accuratezza. Il meglio che possiamo fare è calcolare uno sforzo o un tempo trascorso con un certo livello di confidenza o probabilità.
Alcune persone considerano la stima una sorta di arte oscura ed esiste persino un movimento #NoEstimates con un seguito considerevole. C'è molta discussione sul fatto che la stima possa mai essere sufficientemente accurata o se sia addirittura una buona pratica nei progetti software.
La stima non sarà mai una scienza esatta. Ma, dalla mia esperienza, mi sento di condividere questi principi:
- I requisiti sono fallibili e imprecisi.
- Le persone sono più o meno competenti, coscienziose e laboriose.
- Più piccolo è l’elemento di lavoro, più facile è stimarlo; suddividi le attività grandi in unità più piccole ove possibile e aggrega le stime sull’attività più estesa.
- La stima si basa sull’esperienza. Se non ne hai, trova casi in cui l’esperienza di altri sia rilevante e adattabile.
- Il tuo elemento di lavoro è unico, quindi cerca schemi di lavoro in altre situazioni note in cui hai esperienza.
- Chiedi ad altri di stimare e confronta. Discutere le discrepanze mette in luce differenze nelle aspettative, nella confidenza e nella completezza.
- Stima la situazione migliore e poi quella peggiore. Una buona stima si trova da qualche parte nel mezzo.
Stima oggi e inizia a lavorare; domani e ogni giorno successivo, con le conoscenze acquisite, la tua stima fino al completamento migliorerà.
Dipendenze, Rischi e Assunzioni
In un articolo precedente, abbiamo discusso del rischio e del ruolo dei test nella gestione del rischio. I rischi di prodotto riguardano se il prodotto soddisfa le esigenze degli utenti rispetto ai requisiti funzionali o tecnici. Qui, l'attenzione è sui rischi relativi al piano di consegna effettivo.
Le cose possono andare storte nei progetti. Durante la pianificazione devi chiarire quali rischi di fallimento hai considerato e gestito. Ci sono tre aspetti da considerare: dipendenze, rischi e risposte.
Dipendenze
Le dipendenze rappresentano un elenco di risorse umane e materiali necessarie, e attività propedeutiche, che devono essere completate affinché le tue attività pianificate abbiano successo e vengano realizzate.
Ci sono sempre dipendenze per qualsiasi attività di test, sia che si tratti di un test a livello di sistema su larga scala o di una sessione esplorativa sulla funzionalità. Le dipendenze coprono tre aspetti principali.
Rischi
Il rischio è la probabilità che il tuo piano fallisca in fase di esecuzione. Il rischio riguarda, ad esempio:
- Le tue stime: cosa potrebbe causare errori nelle tue stime? Il sistema che si rivela più complesso, difettoso, incompleto o in continua evoluzione può influenzare le tue stime.
- Persone non disponibili, carenti di esperienza o competenze, o non completamente coinvolte nella tua fase del progetto. Questi potrebbero essere membri del team o persone nella tua rete di supporto.
- Infrastruttura come ambienti di test, strumenti (o formazione sull’utilizzo degli strumenti) o spazi ufficio non disponibili, non adeguatamente predisposti o difettosi.
- Attività propedeutiche che non si concludono in tempo (o che vengono abbandonate, che consegnano prodotti parziali o difettosi, oppure che non consegnano affatto).
Risposte
Per ciascuno di questi rischi occorre valutare la probabilità, l’impatto e, quando significativo, una risposta appropriata o la conseguenza attesa. Queste risposte tendono a prendere una delle seguenti forme:
- Assunzione: il rischio è ritenuto sufficientemente basso da poter essere ignorato o considerato ininfluente. Ma viene monitorato e registrato come assunzione (di disponibilità, completezza, ecc.)
- Adattamento: il rischio è significativo, ma è possibile attuare azioni per ridurne l'impatto sul piano. Ad esempio, se il sistema sotto test è parzialmente consegnato e mancano alcune funzionalità, il piano può essere adattato per testare solo le funzionalità disponibili.
- Conseguenza: alcuni rischi non possono essere gestiti. Se il sistema viene consegnato in ritardo, i test non possono iniziare fino alla sua consegna.
Comunicazione, Impegno e Reportistica di Avanzamento
Infine, passiamo a un aspetto cruciale ma spesso trascurato della pianificazione. Potresti produrre un piano di progetto con tutte le attività, i partecipanti, le risorse, le responsabilità, le dipendenze, i tempi, lo sforzo e i costi inclusi. Oppure potrebbe essere una comprensione verbale tra i membri di un team agile.
In ogni caso, il piano deve essere comunicato efficacemente a tutti, così che ciascuno sappia cosa è richiesto e quando.
Un piano concordato è un contratto tra i partecipanti. Se un responsabile di team approva un piano, questo rappresenta implicitamente o esplicitamente un impegno a mantenere la parte del contratto del suo team.
Il piano è un contratto tra i partecipanti.
Nei progetti meno formali potrebbe non esserci alcun piano scritto o impegni documentati. In queste circostanze, il piano è una conversazione continua tra i membri del team. Il team si riunisce quotidianamente e le attività attive previste dal piano vengono discusse in tempo reale. Su cosa stanno lavorando le persone? Il progresso procede secondo le aspettative? Quali problemi stanno incontrando le persone? Ci sono problemi che bloccano l'avanzamento?
In tutti i progetti, lo scopo del reporting sull'avanzamento è duplice. Ovviamente è necessario comunicare a che punto si trova ognuno rispetto all'attività attuale del progetto. Ma il report sullo stato di avanzamento è anche un controllo periodico e continuo che serve a mantenere il progresso e a verificare che l'impegno dei partecipanti sia affidabile.
Grazie per averci letto, unitevi a noi la prossima volta per... esatto, l'esecuzione!
Iscriviti alla newsletter di The QA Lead per essere avvisato quando le nuove parti della serie saranno online. Questi post sono estratti dal corso Leadership In Test di Paul che ti consigliamo vivamente per approfondire questo e altri argomenti. Se lo fai, usa il nostro codice coupon esclusivo QALEADOFFER per ottenere uno sconto di $60 sul prezzo intero del corso!