Leadership nel testing: pianificazione dei test

Il piano non è la realtà; è un modello della realtà che richiede cambiamenti costanti.

In questo articolo tratterò ogni fase della pianificazione del testing, tra cui:

• Risultati finali
• Come
• Risorse
• La tua rete di supporto
• Stime
• Dipendenze, rischi e assunzioni
• Comunicazione, impegno e comunicazione dei progressi

Ma prima, cerchiamo di comprendere bene l’utilità di un piano. 

Perché pianificare?

Lo scopo della pianificazione è solitamente creare un approccio condiviso, un insieme di impegni, dipendenze, costi e una pianificazione temporale per realizzare un progetto. Il piano rappresenta un’intesa tra gli stakeholder del progetto, i fornitori e i partecipanti e definisce generalmente quanto segue:

• Quali risorse sono necessarie e quando
• Quando devono iniziare e terminare le attività e chi le svolgerà
• Le competenze necessarie per completare le attività
• Gli strumenti e le tecnologie che supportano il piano
• I risultati finali e quando saranno consegnati
• I costi dell’impegno e delle risorse necessarie
• Il processo per far avanzare il progetto/processo attraverso le sue fasi
• I rischi che minacciano la consegna.

Alcuni di questi aspetti potrebbero essere specificati in una strategia o essere già presenti. Potrebbe essere noto, per esempio, quali fornitori sono coinvolti e che cosa faranno per il progetto. Gli strumenti e la tecnologia da utilizzare potrebbero essere già noti e disponibili. Le persone, gli ambienti di testing e i dati potrebbero essere già pronti. Potrebbe inoltre esistere una strategia che definisce il processo, l’approccio o le tecniche da utilizzare.

Tuttavia, mentre la strategia definisce i principi o la teoria, il piano descrive gli aspetti pratici o logistici relativi a come il progetto verrà realizzato concretamente.

Una strategia stabilisce in linea di principio come verrà eseguito un progetto; il piano definisce e conferma come il progetto verrà eseguito nella pratica.

Per molti responsabili di progetto il piano viene gestito tramite software come Microsoft Project, ma un piano valido dipende dal fatto che tutti i partecipanti al progetto sappiano che cosa devono fare e come farlo. Per raggiungere questo obiettivo, il piano e le conoscenze su come verranno svolte le attività devono essere comunicati e condivisi da tutte le persone coinvolte.

La pianificazione è un viaggio, non un’attività

Per citare l’ex presidente degli Stati Uniti Dwight D. Eisenhower, «la pianificazione è tutto. Il piano non è nulla». Questo sentimento è così importante da meritare di essere ripetuto in quasi ogni contesto lavorativo dei progetti informatici. Ma cosa significa dire che il piano non è nulla? Qual è il senso della pianificazione se il risultato è un piano inutile? 

Il piano con cui si finisce non è mai inutile, ma il sentimento di Eisenhower riguarda l’attività di pianificazione e il suo valore rispetto al piano. Confrontiamo rapidamente separatamente il funzionamento della pianificazione nei progetti strutturati di lunga durata e nei progetti agili/continui.

UNISCITI ALLA COMUNITÀ

Arricchisci la tua casella di posta con più saggezza sulla leadership tecnologica per offrire software e sistemi migliori.

Create Free Account

Have an account? Log In

Pianificazione strutturata e agile

In un progetto a lungo termine, la tua azienda, i fornitori e il personale IT interno devono sapere quale impegno è loro 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, oltre all’impegno e alle prestazioni dei fornitori e 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 alcuni adeguamenti. I requisiti vengono scartati; i fornitori consegnano in ritardo; gli ambienti, i dati di test o gli strumenti non sono pronti in tempo. L’elenco potrebbe continuare. La pianificazione non è mai un’attività una tantum: è un’attività continua — quasi quotidiana.

Spesso gli eventi non pianificati vengono trattati come rumore e non ricevono molta attenzione. In seguito, però, alcuni di questi piccoli inconvenienti diventano problemi rilevanti. Una delle difficoltà dei progetti a cascata è che questo adeguamento continuo può essere gravoso, perché qualsiasi modifica viene considerata un’inutile manipolazione. Spesso i progetti procedono comunque a pieno ritmo, sperando che le cose “vadano bene al momento della verità”. Ma raramente è così, e lo si è detto molte volte:

Come fa un progetto ad arrivare con un anno di ritardo? Un giorno alla volta.

L’approccio agile è in parte una reazione alla frustrazione causata dai piani fissi o inflessibili. L’agilità è l’alternativa comprovata all’inerzia degli approcci complessi e organizzati per fasi. Ma questo significa che i progetti agili non prevedono attività di pianificazione? No. 

Anche nell’agile è necessaria una certa pianificazione iniziale per strutturare il lavoro, mobilitare le risorse e programmare — almeno a un livello generale — il processo di rilascio nei mesi successivi. Tuttavia, iterazione dopo iterazione, e spesso giorno dopo giorno, il piano complessivo viene adeguato continuamente per tenere conto degli eventi e delle nuove informazioni che emergono.

La pianificazione è un percorso di apprendimento continuo, non un’attività con un prodotto da consegnare.

Pianificazione dei test

Finora abbiamo esaminato la pianificazione dei progetti nel suo complesso e abbiamo suggerito che si tratta in larga misura di un’attività continua. Ora ci concentreremo nello specifico sulla pianificazione dei test nei progetti. 

La pianificazione dei test è molto simile alla pianificazione del progetto: si tratta semplicemente di un piano su scala più ridotta. Naturalmente, il piano dei test deve anche integrarsi con il piano generale del progetto, perché dipende da altre attività e prodotti da consegnare del progetto (e altre attività dipendono dai test). Frequentemente, i piani dei test subiscono interruzioni perché queste dipendenze non vengono rispettate.

I piani dei test sono relativamente semplici a livello generale. Potrebbero esserci diverse attività che dipendono dal progetto principale. Queste sono quelle che spesso compaiono come attività nel piano generale del progetto. Tuttavia, queste attività vengono distribuite all’interno di un team, che potrebbe avere un ampio inventario di elementi di test per i quali pianificare ed eseguire i test. 

Questo livello di dettaglio non è particolarmente rilevante per la pianificazione del project manager e viene solitamente definito e gestito a livello locale all’interno del team di test.

Esaminiamo alcuni degli elementi fondamentali del tuo piano dei test.

Prodotti da consegnare

Quali sono i prodotti da consegnare dei test?

Che domanda! Sicuramente si tratta delle specifiche dei test, dei test, dei risultati e dei report? I prodotti da consegnare sono essenzialmente contenuti nella documentazione, quindi dobbiamo solo preoccuparci di produrre le pratiche e spuntare alcune caselle. 

Ma questo approccio, sebbene comune, è in parte responsabile della reputazione dei test (e dei tester) come attività costosa, burocratica e poco flessibile, con scarso valore. Dopotutto, chi legge questi documenti voluminosi?

Supponiamo che in un progetto agile non vi sia alcuna intenzione di produrre documentazione dei test. È molto probabile, quindi cosa forniscono effettivamente i test in queste situazioni? Quale valore hanno in assoluto i test? È un po’ tardi per porsi queste domande, non è vero?

Quando viene testato un componente, un sottosistema o l’intero sistema, il risultato è costituito da evidenze del comportamento del sistema in una determinata situazione o contesto. Le evidenze del comportamento del sistema vengono raccolte e organizzate per essere presentate agli stakeholder (sviluppatori, utenti, responsabili ecc.) affinché possano prendere una decisione: correggere i bug, integrare un componente, accettare o rifiutare una funzionalità, rilasciare o distribuire un sottosistema o l’intero sistema.

Il prodotto da consegnare dei test è costituito da evidenze del comportamento del sistema utilizzate dagli stakeholder per prendere una decisione.

Ora, in alcuni progetti, è essenziale fornire una documentazione dei test per registrare come un test è stato definito, progettato, implementato ed eseguito. Ma sono le prove del comportamento del sistema a costituire il risultato finale di valore per le parti interessate.

Il valore dei test è il livello di fiducia che le parti interessate ripongono nel prendere decisioni basate sulle evidenze dei test.

Queste evidenze possono essere raccolte, organizzate in tabelle e analizzate sistematicamente in sofisticate soluzioni per la gestione dei test e presentate alle parti interessate in eleganti formati grafici. Oppure, gli appunti scritti a mano possono essere utilizzati da un collaudatore per presentare verbalmente la storia dei test a un responsabile di prodotto durante una riunione quotidiana.

Indipendentemente da come vengono raccolte e presentate, l’attività finale dei test consiste nella consegna delle evidenze.

Come

Indipendentemente dalle dimensioni o dalla metodologia del progetto, i test dipendono da una determinata serie di attività. Esamineremo un processo generico attraverso gli occhi del collaudatore (o della squadra) e analizzeremo poi alcune delle variazioni che si verificano. 

Esistono quelle che potremmo definire “attività di test” e attività di “supporto ai test” o “logistiche”. Per assicurarti di includere tutte le attività nel piano, potresti trovare utili come liste di controllo le tabelle riportate di seguito.

Un’attività nella tabella precedente che potresti non riconoscere immediatamente è quella relativa al riscontro. Probabilmente ti è già capitato di dover lavorare con requisiti di scarsa qualità. 

L’attività di riscontro, revisione e messa in discussione è quella in cui i collaudatori, dopo aver analizzato e modellato un requisito, individuano i problemi e possono usare esempi per dimostrare dove i requisiti sono mancanti, ambigui o contraddittori.

Se ritieni che i requisiti siano di scarsa qualità, vale sicuramente la pena prevedere questa attività.

Logistica dei test

La logistica dei test supporta le attività di test descritte sopra. Mentre l’elenco delle attività di test che ho fornito è abbastanza completo, la logistica dei test varia con ogni progetto e organizzazione. L’elenco seguente non è quindi esaustivo. Nel tuo progetto, prenditi il tempo necessario per analizzare ogni attività o dipendenza richiesta per svolgere i test.

Risorse (umane, fisiche)

Spesso usiamo la parola risorse per riferirci alle persone che lavorano nei nostri progetti e, per alcuni, questo non è piacevole. Le persone non sono cose, sono esseri umani, naturalmente. Nei progetti più piccoli potrebbe essere possibile usare i nomi, ma nelle organizzazioni più grandi, quando sono coinvolte squadre di progetto che potrebbero non essere ancora composte, un numero di risorse è semplicemente un modo abbreviato per indicare un numero di persone.

Ancora più importante, non è necessariamente il numero di persone a contare: ciò che conta davvero sono le loro capacità. Naturalmente, le persone lavorano in modi diversi e solitamente a velocità diverse, quindi dovrai tenerne conto nella pianificazione.

Oltre alle persone, nelle diverse fasi avrai bisogno di risorse fisiche differenti affinché i test possano procedere. Queste spaziano dalle più comuni alle altamente specifiche e la mancanza di una qualsiasi di esse potrebbe compromettere la missione di test.

Potresti essere già abbastanza fortunato da avere accesso a un laboratorio di test completamente attrezzato, gestito e dedicato. In caso contrario, potresti dover specificare tutto: dallo spazio fisico e dagli arredi fino ai foglietti adesivi e alle gomme da cancellare, per definire il tuo ambiente di lavoro.

Nella tabella seguente sono riportate alcune risorse tipicamente necessarie. Il tuo elenco sarà probabilmente molto diverso. 

Quando avrai identificato tutte le risorse necessarie per realizzare il tuo piano, valuta se sia necessario inserire nel piano attività aggiuntive per acquisirle.

La tua rete di supporto

Se le persone e le competenze necessarie per svolgere i test fossero sotto il tuo controllo, i progetti potrebbero essere molto più semplici! Tuttavia, poche squadre dispongono di tutte le competenze necessarie o dell’autorizzazione e dell’accesso alle risorse fisiche indispensabili. Molti progetti sono composti e gestiti secondo lo stile della gestione a matrice. I membri chiave della squadra riportano effettivamente ai responsabili di altri reparti specialistici e otterrai da loro un impegno limitato.

Potrebbe essere necessario specificare un determinato numero di ore al giorno o programmare degli orari per accedere alle competenze specialistiche sopra indicate. A volte, ti verrà chiesto quale livello di servizio sia accettabile, ad esempio: «alle richieste ad alta priorità verrà risposto entro trenta minuti» e così via.

Stime

La stima nei progetti software è un’attività complessa. È stato scritto molto sul fatto che stimare sia difficile o addirittura impossibile. Tuttavia, le stime sono necessarie in tutti i progetti e, quanto più grande è il progetto, tanto più dipendiamo da esse.

Abbiamo bisogno delle stime per creare una pianificazione, ma il problema è che la stima non garantisce precisione. Il massimo che possiamo fare è calcolare lo sforzo o il tempo trascorso con un certo livello di confidenza o probabilità.

Alcune persone considerano la stima una forma di magia nera e persino il movimento #NoEstimates conta su un seguito considerevole. Esiste un ampio dibattito sul fatto che la stima possa mai essere sufficientemente accurata o che sia persino una buona pratica nei progetti software.

La stima non sarà mai una scienza esatta. Tuttavia, in base alle mie esperienze, ci sono alcuni principi che mi sento di condividere:

• I requisiti sono fallibili e imprecisi.
• Le persone sono più o meno competenti, coscienziose e laboriose.
• Quanto più piccolo è l’elemento di lavoro, tanto più facile è stimarlo; ove possibile, suddividi le attività grandi in unità più piccole e aggrega le stime per ottenere quella dell’attività più grande.
• La stima si basa sull’esperienza. Se non ne hai, individua i contesti in cui l’esperienza di altri è pertinente e può essere adattata.
• 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 i risultati. Discutere le discrepanze mette in luce le differenze nelle aspettative, nella fiducia e nell’accuratezza.
• Stima lo scenario migliore e poi quello peggiore. Una buona stima si trova da qualche parte nel mezzo.

Stima oggi e inizia a lavorare; domani e ogni giorno successivo, grazie alle conoscenze acquisite, la tua stima del completamento migliorerà.

Dipendenze, rischi e ipotesi

In un articolo precedente, abbiamo discusso del rischio e del ruolo dei test nella gestione del rischio. I rischi di prodotto riguardano il fatto che il prodotto soddisfi o meno le esigenze degli utenti rispetto ai requisiti funzionali o tecnici. In questo caso, l’attenzione è rivolta ai rischi relativi al piano effettivo di consegna.

Nei progetti le cose possono andare storte. Durante la pianificazione devi chiarire quali rischi di fallimento hai preso in considerazione e previsto. Ci sono tre aspetti da considerare: dipendenze, rischi e risposte.

Dipendenze

Le dipendenze rappresentano un elenco delle risorse umane e fisiche necessarie e delle attività precedenti che devono essere completate affinché le attività pianificate abbiano successo e producano i risultati previsti. 

Esistono sempre dipendenze per qualsiasi attività di test, che si tratti di un test su un sistema su larga scala o di una sessione di test esplorativo di una funzionalità. Le dipendenze riguardano tre aspetti principali.

More Articles

• Ciclo di vita dei test del software: fasi, strumenti e migliori pratiche
• Progettazione dei Test: Una Competenza Fondamentale per il QA
• 5 vantaggi dei test Shift-Left per ridurre i costi oggi stesso

Rischi

Il rischio è la probabilità che il tuo piano fallisca durante l’esecuzione. Il rischio riguarda aspetti come:

• Le tue stime: cosa potrebbe far sì che le tue stime siano errate? Il fatto che il sistema sia più complesso, difettoso, incompleto o soggetto a continui cambiamenti potrebbe influire sulle tue stime.
• La mancata disponibilità delle persone, la loro scarsa esperienza o competenza oppure il loro impegno non completo nella tua fase del progetto. Potrebbero essere membri del team o persone della tua rete di supporto.
• Un’infrastruttura, come ambienti di test, strumenti (o formazione sull’uso degli strumenti) o spazi d’ufficio, non disponibile, preparata in modo inadeguato o difettosa.
• Il mancato completamento puntuale delle attività precedenti (oppure il loro abbandono, la consegna di prodotti parziali o difettosi o la mancata consegna).

Risposte

Per ciascuno di questi rischi, devi valutarne la probabilità, l’impatto e, quando rilevante, una risposta appropriata o la conseguenza prevista. Queste risposte tendono ad assumere una di queste forme:

• Ipotesi: il rischio è considerato sufficientemente basso da poter essere ignorato o ritenuto irrilevante. Tuttavia, viene tenuto sotto osservazione e registrato come ipotesi (di disponibilità, completezza ecc.)
• Adeguamento: il rischio è significativo, ma esiste un’azione in grado di ridurne l’impatto sul piano. Ad esempio, se il sistema sottoposto a test è stato consegnato parzialmente e alcune funzionalità sono mancanti, il piano può essere adeguato per testare solo le funzionalità disponibili.
• Conseguenza: alcuni rischi non possono essere assorbiti. Se il sistema viene consegnato in ritardo, i test non possono iniziare prima della consegna.

Comunicazione, impegno e resoconto dei progressi

Infine, arriviamo a un aspetto cruciale ma spesso trascurato della pianificazione. Potreste elaborare un piano di progetto che includa tutte le attività, i partecipanti, le risorse, le responsabilità, le dipendenze, le tempistiche, l'impegno e i costi. Oppure potrebbe trattarsi di un'intesa verbale tra i membri di un team agile. 

In ogni caso, il piano deve essere comunicato efficacemente a tutti, affinché sappiano cosa è richiesto e quando.

Un piano concordato è un contratto tra i partecipanti. Se un responsabile del team approva un piano, si impegna implicitamente o esplicitamente a rispettare la parte del contratto spettante al proprio team.

Il piano è un contratto tra i partecipanti.

Nei progetti meno formali potrebbe non esserci alcun piano scritto né alcun impegno formale. In queste circostanze, il piano consiste in 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? I progressi stanno procedendo secondo le aspettative? Quali problemi stanno riscontrando? Quali problemi stanno bloccando i progressi?

In tutti i progetti, lo scopo della rendicontazione dei progressi è duplice. Ovviamente, è necessario comunicare a che punto si trova ciascuno rispetto all'attività corrente del progetto. Ma il rapporto sullo stato di avanzamento rappresenta anche una verifica periodica e continuativa del fatto che i progressi possano essere mantenuti e consente di verificare che ci si possa affidare all'impegno dei partecipanti.

Grazie per aver letto, vi aspettiamo la prossima volta per… indovinate un po', l'esecuzione!

Iscrivetevi alla newsletter di The QA Lead per ricevere una notifica quando saranno pubblicate nuove parti della serie. Questi post sono estratti dal corso Leadership nei test di Paul, che consigliamo vivamente per approfondire questo e altri argomenti. Se decidete di iscrivervi, utilizzate il nostro codice coupon esclusivo QALEADOFFER per ottenere $60 di sconto sul prezzo completo del corso!