Leadership nei test: Eseguire un progetto di test

La classica stretta sul testing

Chiunque abbia testato sistemi ha sperimentato la consegna tardiva del sistema da testare. Quasi a ogni livello, dai componenti ai sistemi completi, gli sviluppatori incontrano problemi e la consegna viene ritardata o è incompleta. Nella maggior parte dei casi, quando è stato assegnato un intervallo di tempo per condurre i test, la scadenza non si sposta e il testing viene compresso. Ciò costringe i team a scegliere tra qualità e velocità. Per strumenti che offrano il meglio di entrambi gli aspetti, dai un’occhiata alla nostra lista delle migliori piattaforme di test software.

UNISCITI ALLA COMUNITÀ

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

Sign up with:

LinkedInGoogleMicrosoft

Or sign up with email:

Name*

First name Last name

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Business email*

Create Password*

This field is hidden when viewing the form

LinkedIn profile

This field is hidden when viewing the form

Company's AI adoption maturity

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

Consegna parziale e incrementale

Sebbene il sistema completo non possa essere consegnato per il testing, alcune funzionalità – un sistema parziale – possono essere fornite con la promessa che le release successive conterranno le restanti funzionalità. 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 della logica e/o sono note per contenere errori.
• Mancanti: posticipate a 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, rendendo il testing più difficile.

Le funzionalità possono essere disponibili, ma il risultato di tali funzionalità non può essere verificato da altre funzioni ancora non disponibili, quindi è necessario esaminare il database di test prima e dopo la prova. È quasi certo che i test end-to-end che richiedono sequenze testabili di funzionalità saranno perlopiù bloccati.

In quasi tutti i casi, il testing a livello di sistema per sistemi parziali è seriamente ostacolato.

Difendere il testing

Il tuo team deve comunque fare progressi, anche con tenacia. Se il sistema non è disponibile, o lo è solo parzialmente, dovrai gestire le aspettative e difendere il tuo piano. 

Il tuo piano per il testing sia nel piccolo che nel grande dipende dalla disponibilità del sistema – questa è un’assunzione – quindi il tuo piano deve cambiare. Potresti non documentare criteri di ingresso formali, ma il messaggio è lo stesso:

I criteri di ingresso sono ipotesi di pianificazione: se questi criteri non sono soddisfatti, le tue ipotesi di pianificazione sono errate e il piano deve essere adeguato.

Che tu stia aspettando la consegna del sistema o abbia accesso a un sistema parziale, finirai abbastanza rapidamente le attività utili da svolgere. A quel punto dovrai affrontare una conversazione difficile con il tuo product owner o project manager. Se la scadenza per il completamento non viene posticipata, sarai costretto a ridurre l’attività di test. Alcune funzionalità potrebbero essere testate meno, o addirittura escluse dai test.

Il manager potrebbe credere che tu possa recuperare il tempo successivamente, ma questo accade molto raramente nella pratica.

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

Perché i test vengono ritardati? Le cause possono essere molteplici, ma tendono a seguire uno di questi modelli:

• Gli ambienti non possono essere configurati in tempo. Le persone hanno iniziato tardi, erano troppo occupate o non qualificate per creare un ambiente di test significativo. Ciò che è disponibile è parziale, configurato male o incompleto.
• La consegna è ritardata perché la quantità di lavoro è stata sottovalutata.
• La consegna è ritardata perché il software presenta molti errori, risultando difficile da testare e correggere.
• La consegna è ritardata perché il team di sviluppo manca delle competenze, dell’esperienza o della conoscenza del dominio aziendale o delle tecnologie utilizzate.
• La consegna è ritardata perché lo sviluppo è iniziato tardi.
• La consegna è ritardata perché i requisiti continuano a cambiare.

Dalla lista sopra sono esclusi eventi di forza maggiore e altri fattori esterni fuori dal controllo del team di progetto. Se il project manager insiste che la scadenza dei test non cambia e anche l’ambito dei test resta fisso, ti trovi davanti a una sfida importante. In ognuna delle cause elencate sopra, il ritardo della consegna giustifica la necessità di fare più test, non meno.

Se il lavoro di sviluppo è sottovalutato, è probabile che anche il testing lo sia. Se il software è pieno di bug, i test richiederanno più tempo. Se gli sviluppatori hanno competenze carenti, il software sarà probabilmente di qualità inferiore e richiederà più tempo per essere testato. Se gli sviluppatori hanno iniziato tardi (perché?) e l’ambito resta invariato, perché ridurre l’attività di test? Se i requisiti cambiano, è probabile che i tuoi piani siano sbagliati comunque: continuare a lavorare seguendo un cattivo piano rende tutto più difficile.

Quante delle cause comuni di ritardo nella consegna suggeriscono che sia necessario ridurre i test? Nessuna. Difendi il tuo piano.

Rendicontare Successi e Fallimenti

La maggior parte dei tester sa che il testing efficace richiede curiosità, tenacia e un certo fiuto per i problemi. La principale motivazione è quella di stimolare i fallimenti e raccogliere sufficienti prove perché gli errori siano rintracciati e possano essere corretti. 

Anche se rilevare (e correggere) difetti è positivo per la qualità del prodotto, comunicare i difetti spesso dà la sensazione di dover dare cattive notizie a qualcuno. Potrebbe trattarsi di uno sviluppatore che ha commesso un errore e dovrà risolverlo, oppure potresti dover informare gli stakeholder che alcune funzionalità critiche non funzionano correttamente e il sistema subirà ritardi.

Nessuno ama dare cattive notizie ed è naturale sentirsi riluttanti a turbare altre persone, specialmente colleghi stretti. Ma la percezione che la tua notizia sia buona o cattiva non è una responsabilità di chi la riporta. 

I difetti sono sempre una cattiva notizia per qualcuno, ma il ruolo del testing non è quello di giudicare in questo senso. In certi aspetti, il tester è come un giornalista, con la missione di ricercare la verità. La storia de “Il Figlio dell’Elefante” di Kipling include questi versi:

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

Così come un giornalista racconta una notizia, tu stai raccontando ciò che hai scoperto mentre testavi un sistema.

La verità, la notizia, può essere buona o cattiva, ma la tua responsabilità è soltanto quella di individuare sia i problemi, sia i successi nel modo più oggettivo possibile. Stai cercando di scoprire 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 irrisolti. Vorresti che tutti i tuoi test passassero, ma il percorso verso il successo è intralciato dai fallimenti dei test che devono essere indagati e risolti. Il tuo obiettivo tattico è individuare velocemente i problemi, ma l’obiettivo finale è non avere problemi di cui segnalare. 

Per riportare con precisione il successo o il fallimento del tuo progetto di test, valuta l’integrazione di strumenti avanzati di gestione dei test che offrano analytics completi

Devi comportarti come un giornalista investigativo: alla ricerca della storia con mente critica e indipendente. Come scrisse Kipling:

Se puoi incontrare Trionfo e Sconfitta, e trattare quei due impostori allo stesso modo…

Così manterrai la calma e farai un buon lavoro per il tuo progetto e gli stakeholder.

Erosione della Copertura

Qualsiasi obiettivo di copertura venga fissato all’inizio dei test, diversi fattori complottano per ridurre la copertura effettivamente raggiunta. "Erosione" è un termine adatto, perché riflette davvero la graduale riduzione dell’ambito dei test pianificati e l’inevitabile presa di coscienza che non tutti i test previsti possono 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 a tale scopo. I piani di solito presumono un budget per i test – che è sempre un compromesso.
• Requisiti sistema, progettazioni e specifiche scadenti, instabili o incompleti rendono la specifica dei test più complicata. La copertura del sistema viene compromessa dalla mancanza di dettagli nella specifica.
• La tarda disponibilità o l’inadeguatezza degli ambienti di test rendono alcuni test pianificati impraticabili o poco significativi. Test di integrazione su larga scala potrebbero essere impossibili da eseguire come pianificato perché non tutte le interfacce o i sistemi di interfacciamento possono essere resi disponibili.
• I test di performance potrebbero essere compromessi se gli ambienti non hanno la scala adeguata o non riflettono la produzione.
• La consegna tardiva del software da testare comporta che, se le scadenze restano fisse, la quantità di test eseguibili deve ridursi.

L’erosione della copertura nell’esecuzione dei test ha, durante i test, anch’essa varie cause:

• Se la qualità del software da testare è bassa all’ingresso in una fase di test, eseguire le prove può essere particolarmente frustrante. Potrebbero fallire anche i test più basilari, e i difetti rilevati potrebbero essere talmente fondamentali che gli sviluppatori impiegheranno più tempo del previsto a correggerli. Se i test vengono sospesi a causa di qualità troppo insoddisfacente, sarai in ritardo. Se la scadenza non viene posticipata, alcuni test verranno esclusi.
• Se si verificano più difetti del previsto, il ciclo di correzione e riesecuzione dei test richiederà più tempo e finirai per non riuscire a completare tutti i test.
• Quando il tempo finisce e si decide di rilasciare, non tutti i tuoi test saranno stati completati. Oppure alcuni test previsti non sono stati eseguiti o rimangono errori che bloccano il completamento dei test falliti. Se la data di go-live non si sposta, questa è la consueta "stretta" sui test sopra menzionata.

Affrontare l’erosione della copertura dei test è una delle sfide con cui i tester si confrontano in ogni progetto. Raramente tutto fila liscio e ridurre il tempo per i test (e la copertura) è spesso l’unica opzione per mantenere il progetto in carreggiata.

Non è sbagliato ridurre la quantità di test; è sbagliato solo ridurre i test in modo arbitrario. Di conseguenza, quando si scelgono i test da tagliare, occorre rivalutare l’impatto sugli obiettivi di test e sui rischi da affrontare. Potresti dover affrontare discussioni difficili con gli stakeholder.

Quando l’impatto è significativo, potresti dover facilitare un incontro tra chi chiede i tagli (tipicamente il project management) e chi potrebbe esserne interessato (gli stakeholder). Il tuo ruolo è illustrare la situazione rispetto ai test completati, lo stato attuale del sistema testato, i test che falliscono e/o bloccano l’avanzamento, e la quantità di test ancora da svolgere.

I tuoi piani e modelli rappresentano l’ambito originale dei test e sono fondamentali per aiutare stakeholder e management a comprendere le lacune e i rischi aperti e decidere se continuare o fermare i test.

Gestione degli Incidenti

Una volta che il progetto passa alle fasi di System Testing e Acceptance Testing, viene in gran parte guidato dagli incidenti che si verificano durante l’esecuzione dei test. Gli incidenti innescano attività nel prosieguo del progetto, e le statistiche degli incidenti a volte possono offrire una buona indicazione sullo stato del progetto. Quando classifichiamo gli incidenti, dobbiamo pensare a come queste informazioni saranno usate 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 altre azioni.

Usiamo un termine neutrale per questi eventi non pianificati – incidente. Tuttavia, spesso vengono definiti anche con altri termini; alcuni più neutrali di altri. 

I test che falliscono possono essere definiti osservazioni, anomalie o problemi – termini neutri che non presumono una causa. Ma a volte si usano termini come problemi, bug, difetti o guasti – che presuppongono che il sistema sia difettoso. Tuttavia, questa potrebbe essere una conclusione prematura e tali etichette possono fuorviare.

Ti consigliamo di riservare i termini bug, difetto o guasto per gli esiti diagnostici dei malfunzionamenti riscontrati nella costruzione del sistema sotto test che di solito comportano un lavoro di correzione 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, cioè fallisce in qualche modo o sembra non soddisfare un requisito.
2. Interruzione o compromissione dei test: si verifica un evento che influisce sulla capacità dei tester di completare le loro attività, come la perdita o il malfunzionamento dell’ambiente di test, dei dati, delle interfacce, di sistemi o servizi integrati o di supporto, oppure qualche altra influenza esterna.

Fallimento del sistema

Questi incidenti sono spesso quelli di maggiore rilievo diretto perché minano la fiducia nella qualità del sistema. 

Interruzioni e test compromessi

Alcune organizzazioni non considerano questi eventi come veri e propri incidenti – le interruzioni sono viste come parte delle difficoltà tipiche dei progetti che si avviano alla conclusione. I test compromessi, cioè quelli in cui l’ambiente o la configurazione del test non sono corretti, possono essere attribuiti al team di test (per l’allestimento o almeno per non averlo verificato prima dell’esecuzione).

In entrambi i casi, l’avanzamento del testing viene influenzato e, se gestisci il processo, sei responsabile di spiegare i ritardi. Per questo motivo, dovresti registrare questi eventi come incidenti oppure chiedere al team di tenere un diario di test e annotare i periodi di interruzione dell’ambiente, i problemi di configurazione o la mancanza delle versioni software appropriate da testare. Se non lo fai, avrai difficoltà a giustificare i ritardi e ciò potrebbe riflettersi negativamente su di te e sul team.

Registrare o no gli incidenti?

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

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

Nei team agili più piccoli, il rapporto tra tester e sviluppatore è stretto. L’intero team può incontrarsi quotidianamente per discutere i principali incidenti ma, più spesso, i bug vengono rilevati, diagnosticati, corretti e ritestati informalmente, senza bisogno di registrarli o coinvolgere altri membri del team o personale aziendale o IT esterno. I bug più seri possono essere discussi e integrati nelle attività relative a una user story, oppure raccolti in specifici sprint o fasi di bug fixing dedicati.

Abbiamo discusso lo scopo e la necessità della documentazione in un articolo precedente. Quella discussione è valida anche per gli incidenti. Il team deve valutare se sia necessario uno strumento e un processo per la gestione degli incidenti, se sia di supporto al gruppo e/o richiesto da persone esterne al team.

I team più grandi 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 vengano rivisti dagli stakeholder e dalla direzione di progetto 
3. Per raccogliere metriche che potrebbero essere utili durante e dopo il progetto.

More Articles

• Progettazione dei Test: Una Competenza Fondamentale per il QA
• 5 vantaggi dei test Shift-Left per ridurre i costi oggi stesso
• Scannerizzazione delle Vulnerabilità vs. Test di Penetrazione

Separare urgenza da gravità

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

• La priorità viene assegnata dal punto di vista del testing e influenza quando un incidente verrà risolto. Il tester dovrebbe decidere se un incidente è di priorità alta o bassa (o una delle gradazioni intermedie consentite). La priorità indica l’urgenza di questo difetto per i tester stessi ed è basata sull’impatto che il fallimento del test ha sul resto dell’attività di testing.
• La gravità viene assegnata dal punto di vista dell’utente e indica l’accettabilità o meno di un difetto (di solito). Gli utenti finali o chi li rappresenta dovrebbero assegnare la gravità, oppure (in modo più efficiente) modificarla se necessario rispetto alla valutazione iniziale dei tester. La gravità riflette l’impatto che quel difetto avrebbe sull’azienda se non venisse risolto prima della messa in produzione. Normalmente, un difetto grave rende inaccettabile il sistema. Se un difetto ha gravità bassa, può essere ritenuto troppo trascurabile per essere corretto subito e quindi potrebbe essere risolto in una release successiva.

Se un incidente blocca il testing e il test è sul percorso critico, l’intero progetto si ferma.

Un incidente ad alta priorità blocca tutti i test e di solito anche il progetto.

È importante ricordare che negli schemi di classificazione degli incidenti, non tutti gli incidenti urgenti sono gravi e non tutti gli incidenti gravi sono urgenti.

Gestire la fase finale

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

Ricorda, lo scopo del testing è fornire informazioni alle parti interessate perché possano prendere una decisione – accettare, correggere, rifiutare, estendere il progetto o abbandonarlo del tutto. 

Se avete una comprensione condivisa dei modelli da utilizzare per i test, è molto più semplice spiegare cosa "funziona" (rispetto al modello) e anche dove le cose smettono di funzionare e quali rischi comportano questi fallimenti. Spetta agli stakeholder utilizzare queste informazioni per prendere le loro decisioni, guidati da voi.

Uno dei vantaggi nell'adottare un approccio di test basato sul rischio è che, quando le attività di test vengono ridotte nelle fasi finali di un progetto, si può utilizzare il rischio residuo per sostenere l'importanza di continuare a testare, o addirittura aumentarne la frequenza. 

Quando la direzione insiste nel comprimere i tempi dei test, i tester dovrebbero semplicemente presentare i rischi che vengono "barattati". Questo è molto più semplice quando è stata eseguita una valutazione dei rischi nelle fasi iniziali, utilizzata per guidare le attività di test e monitorata durante tutto il progetto. Quando la direzione è costantemente consapevole dei rischi residui, è meno probabile che decida di comprimere le attività di test fin dall'inizio.

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

Iscriviti alla newsletter di The QA Lead per essere avvisato quando uscirà una nuova parte di questa serie. Questi post sono estratti dal corso Leadership In Test di Paul, che consigliamo vivamente per un approfondimento su questo e altri argomenti. Se decidi di iscriverti, usa il nostro codice esclusivo QALEADOFFER per ottenere $60 di sconto sul prezzo intero del corso!