Leadership nel Test: Esecuzione di un Progetto di Test

La storica pressione sul testing

Chiunque abbia testato sistemi ha vissuto la consegna tardiva del sistema da testare. A quasi tutti i livelli, dai componenti fino ai sistemi completi, gli sviluppatori incontrano problemi e le consegne subiscono ritardi o risultano incomplete. Nella maggior parte dei casi, quando viene assegnato un intervallo di tempo per eseguire i test, la scadenza non viene spostata e l’attività di testing si riduce. Questo obbliga i team a scegliere tra qualità e velocità. Per strumenti che offrono il meglio di entrambi i mondi, dai un’occhiata alla nostra lista delle migliori piattaforme di testing software.

JOIN THE COMMUNITY

Upgrade your inbox with more tech leadership wisdom for delivering better software and systems.

Sign up with:

LinkedInGoogleMicrosoft

Or sign up with email:

LinkedIn

This field is for validation purposes and should be left unchanged.

Name*

First name Last name

Business email*

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

LinkedIn profile

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Company's AI adoption maturity*

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

Consegna parziale e incrementale

Sebbene il sistema completo non possa essere consegnato per i test, può essere fornita una parte delle funzionalità – un sistema parziale – con la promessa che le release successive conterranno le funzionalità rimanenti. In qualsiasi momento, lo stato delle funzionalità di una release sarà:

• Completate come richiesto: queste funzionalità sono testabili – almeno in isolamento.
• Incomplete: le funzionalità mancano di parte delle caratteristiche e/o si sa già che sono difettose.
• Mancanti: rimandate e verranno consegnate in una release successiva.

Per quanto riguarda le funzionalità disponibili, potrebbe essere possibile testarle in isolamento. Tuttavia, potrebbero dipendere da dati creati da altre funzionalità non ancora disponibili, il che potrebbe rendere il loro test più difficile.

Le funzionalità possono essere disponibili, ma l’output di queste funzionalità non può essere verificato da altre funzionalità ancora non disponibili, quindi è necessario esaminare il database di test prima e dopo. È quasi certo che i tuoi test end-to-end, che richiedono filiere di funzionalità testabili, saranno in gran parte bloccati.

Sotto quasi tutti gli aspetti, il testing a livello di sistema di sistemi parziali è notevolmente ostacolato.

Difendere il testing

Il tuo team deve comunque fare progressi, anche se con determinazione. Se il sistema non è disponibile, o è disponibile solo in parte per il team, dovrai gestire le aspettative e difendere il tuo piano. 

Il tuo piano di testing, sia a livello micro che macro, dipende dalla disponibilità del sistema – questa è un’assunzione – quindi il tuo piano deve cambiare. Potresti non documentare criteri formali di ingresso, ma il messaggio resta il medesimo:

I Criteri di Ingresso sono assunzioni di pianificazione – se questi criteri non vengono soddisfatti, le tue assunzioni sono errate e il piano deve essere modificato.

Che tu stia aspettando la consegna del sistema o abbia accesso solo a un sistema parziale, finirai rapidamente le attività utili da svolgere. Dopodiché dovrai affrontare una conversazione difficile con il product owner o il project manager. Se la scadenza per il completamento non viene posticipata, sarai costretto a ridurre il tempo dedicato ai test. Alcune funzionalità potrebbero essere testate meno o escluse completamente dai test.

Il manager potrebbe pensare che potrai recuperare il tempo più avanti, ma nella pratica questo è quasi impossibile da realizzare.

Il tempo perso per i test a causa di consegne in ritardo o parziali non può essere recuperato semplicemente ‘lavorando di più’.

Perché i test vengono ritardati? Ci sono molte possibili cause, ma tendono a seguire questi schemi:

• Gli ambienti non possono essere configurati in tempo. Le persone hanno iniziato tardi, erano troppo impegnate o non qualificate per creare un ambiente di test adeguato. Ciò che è disponibile è parziale, configurato male o incompleto.
• La consegna è ritardata perché l'entità del lavoro è stata sottovalutata.
• La consegna è ritardata perché il software contiene errori, è difficile da testare e da correggere.
• La consegna è ritardata perché al team di sviluppo mancano le competenze, l'esperienza o le conoscenze necessarie nel dominio aziendale o nelle tecnologie che stanno utilizzando.
• La consegna è ritardata perché lo sviluppo è iniziato tardi.
• La consegna è ritardata perché i requisiti continuano a cambiare.

Sono esclusi dall'elenco sopra eventi eccezionali e altri fattori esterni fuori dal controllo del team di progetto. Se il project manager insiste che la scadenza per i test non cambi e anche l’ambito dei test sia fisso, allora hai davanti una sfida importante. In tutti i casi sopra indicati, le cause del ritardo nella consegna giustificano la necessità di eseguire più test, non di meno.

Se il lavoro di sviluppo è stato sottostimato, è probabile che lo siano anche i test. Se il software contiene bug, i test richiederanno più tempo. Se agli sviluppatori mancano le competenze, probabilmente il software sarà di qualità scadente e ci vorrà più tempo per testarlo. Se gli sviluppatori hanno iniziato tardi (perché?) e l'ambito resta invariato, perché si dovrebbero ridurre i test? Se i requisiti cambiano, è probabile che i tuoi piani siano comunque errati – lavorare su un piano sbagliato rende inevitabilmente tutto più difficile.

Quante delle cause comuni di ritardo nella consegna suggeriscono di dover eseguire meno test? Nessuna. Difendi il tuo piano.

Riferire Successi e Fallimenti

La maggior parte dei tester sa che per testare in modo efficace servono curiosità, perseveranza e un buon intuito per i problemi. La principale motivazione è stimolare i malfunzionamenti e produrre abbastanza prove perché i difetti possano essere ricondotti ad errori da correggere. 

Sebbene trovare (e correggere) difetti migliori la qualità del prodotto, comunicare i difetti spesso equivale a dare brutte notizie a qualcuno. Potrebbe trattarsi di uno sviluppatore che ha commesso un errore e deve risolverlo, oppure potresti dover comunicare agli stakeholder che una funzionalità critica non funziona correttamente e il sistema subirà un ritardo.

Nessuno ama dare cattive notizie ed è naturale sentirsi a disagio all’idea di turbare gli altri, soprattutto colleghi con cui si lavora a stretto contatto. Ma la percezione che una notizia sia buona o cattiva non dovrebbe riguardare chi la comunica. 

I difetti sono sempre una cattiva notizia per qualcuno, ma il ruolo dei test non è giudicare in questa maniera. Da certi punti di vista, il tester è come un giornalista, alla ricerca della verità. Nel racconto "Il Bambino Elefante" di Kipling si trovano questi versi:

Ho sei onesti servitori:
    (Mi hanno insegnato tutto ciò che so)
I loro nomi sono Cosa, Dove e Quando
    E Come e Perché e Chi.

Allo stesso modo in cui un giornalista racconta una notizia, tu stai raccontando quello che hai scoperto testando un sistema.

La verità – la notizia – può essere buona o cattiva, ma la tua responsabilità è semplicemente scoprire sia i problemi che i successi nel modo più completo possibile. Stai cercando di capire cosa fa un sistema e come lo fa. 

Alla fine di un progetto l'obiettivo è consegnare in produzione con il minor numero possibile di problemi aperti. Vuoi che tutti i tuoi test siano superati, ma il percorso verso il successo è ostacolato da errori nei test che devono essere investigati e risolti. Il tuo obiettivo tattico è trovare velocemente i problemi, ma alla fine vorresti non averne da segnalare. 

Per riferire con precisione il successo o il fallimento del tuo progetto di test, considera di integrare strumenti avanzati di gestione dei test che offrano un’analisi completa

Devi comportarti proprio come un giornalista investigativo – alla ricerca di una storia con mente critica e indipendente. Come ha scritto Kipling:

Se riesci a incontrare Trionfo e Disfatta, e trattare quei due impostori allo stesso modo …

Allora manterrai il sangue freddo e farai un buon lavoro per il tuo progetto e i tuoi stakeholder.

Erosione della Copertura

Qualunque sia il target di copertura stabilito all'inizio del testing, diversi fattori concorrono a ridurre la copertura effettivamente raggiunta. Erosione è un termine appropriato in quanto riflette realmente la riduzione progressiva dell'ambito dei test pianificati e la consapevolezza inevitabile che non tutti i test previsti possano essere eseguiti nel tempo disponibile.

L’erosione della copertura ha diverse cause prima dell'esecuzione dei test:

• Innanzitutto, i piani di test identificano i rischi da affrontare e l’approccio da utilizzare. I piani solitamente prevedono un budget per il testing – che rappresenta sempre un compromesso.
• Requisiti, progettazioni e specifiche di sistema carenti, instabili o incomplete rendono più difficile la specifica dei test. La copertura del sistema viene compromessa dalla mancanza di dettaglio nelle specifiche.
• La disponibilità tardiva o l’inadeguatezza degli ambienti di test rende alcuni test pianificati impraticabili o poco significativi. I test di integrazione su larga scala possono essere impossibili da eseguire come pianificato perché non tutte le interfacce o i sistemi integrati possono essere resi disponibili.
• I test sulle prestazioni potrebbero essere compromessi perché gli ambienti mancano di adeguata scala o non riflettono la produzione.
• La consegna tardiva del software da testare implica che, quando le scadenze rimangono fisse, la quantità di test nell'ambito deve essere ridotta.

L’erosione della copertura dei test in esecuzione durante l’esecuzione dei test ha anch’essa diverse cause:

• Se la qualità del software da testare è scarsa all’ingresso in una fase di test, eseguire i test può risultare particolarmente frustrante. Anche i test più basilari potrebbero fallire e i difetti trovati potrebbero essere così fondamentali che agli sviluppatori servirà più tempo per risolverli di quanto previsto. Se il testing viene sospeso perché la qualità del software è troppo scadente, sarai in ritardo. Se la scadenza non viene spostata, alcuni test verranno eliminati dall'ambito.
• Se i difetti riscontrati sono più numerosi di quanto previsto, il ciclo di correzione e ri-test stesso richiederà più tempo e non ci sarà tempo sufficiente per completare tutti i test.
• Quando il tempo finisce e si prende la decisione di rilasciare, non tutti i test saranno completi. Alcuni test possono non essere stati raggiunti nel piano o alcuni difetti restano e bloccano il completamento dei test falliti. Quando la data di go-live non viene spostata, si verifica la classica compressione del testing sopra citata.

Gestire l’erosione della copertura del testing è una delle sfide che i tester affrontano in tutti i progetti. Raramente tutto va per il verso giusto e ridurre il tempo per i test (e quindi la copertura) è solitamente l’unica opzione per mantenere il progetto sulla buona strada.

Non è sbagliato ridurre la quantità di testing; è sbagliato solo ridurla in modo arbitrario. Di conseguenza, quando si fanno delle scelte su quali test tagliare, è necessario rivedere l’impatto sugli obiettivi di test e sui rischi da affrontare. Potresti dover affrontare qualche discussione impegnativa con gli stakeholder per venirne a capo.

Quando l’impatto è significativo, potrebbe essere necessario organizzare una riunione tra chi richiede i tagli (tipicamente la direzione di progetto) e chi potrebbe essere coinvolto dagli stessi (gli stakeholder). Il tuo ruolo è quello di illustrare la situazione in relazione ai test completati, lo stato attuale conosciuto del sistema testato, i test che falliscono e/o bloccano l’avanzamento e la quantità di test che resta da svolgere.

I tuoi piani e i tuoi modelli articolano l’ambito originale del testing e sono fondamentali per aiutare stakeholder e management a comprendere i gap e i rischi ancora presenti e a prendere la decisione se continuare i test o fermarsi.

Gestione degli Incidenti

Quando il progetto entra nelle fasi di Test di Sistema e di Accettazione, il processo è guidato principalmente dagli incidenti che si verificano durante l’esecuzione dei test. Gli incidenti attivano attività nel resto del progetto e le statistiche sugli incidenti possono talvolta fornire una buona visione sullo stato del progetto. Al momento di categorizzare gli incidenti, bisogna già pensare a come queste informazioni saranno utilizzate in seguito.

Un incidente è un evento imprevisto che si verifica durante il testing e che può avere un impatto sul completamento con successo dei test, sulla decisione di accettazione o sulla necessità di intraprendere qualche altra azione.

Utilizziamo un termine neutro per questi eventi imprevisti – incidente. Tuttavia, questi eventi vengono spesso indicati anche con altri termini; alcuni più neutrali di altri. 

I test che falliscono possono essere chiamati osservazioni, anomalie o problemi – termini neutri che non presuppongono una causa. Ma a volte si usano termini come problemi, bug, difetti o errori – che presuppongono un malfunzionamento del sistema. Tuttavia, questa può essere una conclusione prematura e queste etichette possono indurre in errore.

Ti suggeriamo di riservare i termini bug, difetto o errore per descrivere i risultati delle diagnosi dei fallimenti nella costruzione del sistema oggetto di test che di solito richiedono un nuovo lavoro per il team di sviluppo.

Gli incidenti si manifestano in due modi:

1. Fallimento del sistema: il sistema non si comporta come previsto in un test, ossia fallisce in qualche modo o sembra non soddisfare qualche requisito.
2. Interruzione o compromissione del testing o dei test: qualche evento che influenza la capacità dei tester di completare le loro attività, come la perdita o il malfunzionamento dell’ambiente di test, di dati, di interfacce o di sistemi o servizi di supporto integrati, o qualche altra influenza esterna.

Fallimento del Sistema

Questi incidenti sono spesso fonte di maggiore preoccupazione diretta perché minano la fiducia nella qualità del sistema. 

Interruzioni e Test Compromessi

Alcune organizzazioni non trattano affatto questi incidenti come tali – le interruzioni sono considerate parte della natura turbolenta dei progetti in fase di conclusione. I test compromessi, ovvero quelli in cui l’ambiente o la configurazione del test è errata, possono essere imputati al team di test (per la configurazione o almeno per non averla verificata prima di iniziare la prova).

In entrambi i casi, il progresso nei test viene compromesso e, se stai gestendo il processo, sei responsabile di spiegare eventuali ritardi. Per questo motivo, dovresti registrare questi eventi come incidenti oppure chiedere al team di tenere un log dei test e annotare le interruzioni dell’ambiente, i problemi di configurazione o la mancanza di versioni software idonee per i test. Se non lo fai, avrai difficoltà a giustificare i ritardi nel progresso e ciò potrebbe riflettersi negativamente su di te e sul team.

Registrare o meno gli incidenti?

Con l’avvento degli approcci agili e di continuous delivery, la visione tradizionale della gestione degli incidenti è stata messa in discussione. Nei progetti a fasi, gli incidenti sono trattati come potenziali task di lavoro per gli sviluppatori, che vengono approvati in base alla gravità e/o all’urgenza. 

Esiste un processo formale, spesso burocratico, da seguire attraverso cui gli incidenti vengono esaminati, prioritizzati e presi in carico dal team di sviluppo (o da altri team). Potrebbero essere coinvolti strumenti avanzati di gestione degli incidenti.

Nei piccoli team agili, la relazione tra tester e sviluppatore è stretta. Il team, nel suo insieme, può incontrarsi quotidianamente per discutere degli incidenti maggiori ma, il più delle volte, i bug vengono rilevati, diagnosticati, corretti e ritestati informalmente, senza necessità di registrare un incidente o coinvolgere altri membri del team o personale IT/di business esterno. I bug più gravi possono essere discussi e inseriti nel lavoro di una user story, o raccolti in iterazioni o sprint dedicati alla correzione dei problemi.

Abbiamo discusso lo scopo e la necessità della documentazione in un articolo precedente. Tale discussione è pertinente anche per gli incidenti. Il team deve valutare se è necessario uno strumento e un processo di gestione degli incidenti e se questo sia utile per il team e/o richiesto dalle persone esterne al gruppo di lavoro.

I gruppi più numerosi tendono a fare affidamento su processi e strumenti per gestire gli incidenti per tre motivi: 

1. Per assicurarsi che gli incidenti non vengano dimenticati
2. Affinché i problemi gravi siano valutati da stakeholder e project manager 
3. Per raccogliere metriche che possono essere utili durante e dopo il progetto.

More Articles

• Leadership nei Test: Pianificazione dei Test
• Leadership nei test: quante prove sono sufficienti?
• La Leadership nel Testing: Definire una Strategia di Test

Separare Urgenza e Gravità

Qualunque sia il processo di gestione degli incidenti adottato, consigliamo di assegnare a tutti gli incidenti sia un codice di priorità che uno di gravità.

• La priorità viene assegnata dal punto di vista dei test e influenza quando un incidente verrà risolto. Il tester dovrebbe decidere se un incidente è di alta o bassa priorità (o su una scala intermedia, se prevista). La priorità indica l’urgenza di questo problema per coloro che stanno effettuando i test ed è determinata dall’impatto che l’errore ha sul resto della fase di test.
• La gravità, invece, è definita dal punto di vista dell’utente e indica l’accettabilità o meno (generalmente) di un difetto. Gli utenti finali o i loro responsabili dovrebbero assegnare la gravità, o (con maggiore efficienza) correggere se necessario la valutazione iniziale dei tester. La gravità riflette l’impatto che quel difetto avrebbe sul business se non venisse corretto prima della consegna. Normalmente, un difetto grave rende il sistema inaccettabile. Se un difetto è di lieve entità, può essere ritenuto troppo banale per necessitare di una correzione prima della messa in produzione, ma può essere sistemato in una release successiva.

Se un incidente blocca l’attività di test e i test sono sul percorso critico, allora si ferma l’intero progetto.

Un incidente ad alta priorità blocca tutti i test, e solitamente il progetto.

La cosa importante da ricordare negli schemi di classificazione degli incidenti è che non tutti gli incidenti urgenti sono gravi e non tutti gli incidenti gravi sono urgenti.

Gestire l’End-Game

Chiamiamo le ultime fasi del nostro processo di test “End-Game” perché la gestione delle attività di test durante questi ultimi giorni, spesso frenetici e stressanti, richiede una disciplina diversa rispetto al periodo precedente, apparentemente molto più rilassato, della pianificazione dei test.

Ricorda, lo scopo del collaudo è fornire informazioni agli stakeholder per permettere loro di prendere una decisione – accettare, migliorare, rifiutare, estendere il progetto o abbandonarlo del tutto. 

Se condividi con il team la comprensione dei modelli di test da adottare, è molto più semplice spiegare ciò che “funziona” (rispetto al modello adottato), ma anche dove le cose non funzionano e quali sono i rischi associati a tali guasti. Saranno gli stakeholder a utilizzare queste informazioni per prendere le loro decisioni, guidati da te.

Uno dei valori dell’adozione di un approccio di test basato sul rischio è che, quando i tempi per i test sono stretti verso la fine di un progetto, il rischio residuo può essere usato per argomentare la necessità di continuare a testare, o persino intensificare l’attività. 

Dove la direzione insiste nel comprimere l’attività di testing, i tester dovrebbero semplicemente presentare i rischi che vengono ‘trascurati’. Questo risulta molto più semplice quando è stata eseguita una valutazione dei rischi nelle fasi iniziali, utilizzata per orientare le attività di test e monitorata durante tutto il progetto. Quando la direzione è consapevole dei rischi residui in modo continuativo, è meno probabile che tenterà di comprimere il testing in primo luogo.

E questo è tutto, in bocca al lupo con i vostri test!

Iscriviti alla newsletter di The QA Lead per ricevere una notifica quando verranno pubblicate nuove parti della serie. Questi post sono estratti dal corso Leadership In Test di Paul, che raccomandiamo vivamente per approfondire questo e altri argomenti. Se decidi di iscriverti, usa il nostro codice sconto esclusivo QALEADOFFER per ottenere $60 di sconto sul prezzo totale del corso!