Leadership nei test: Documentazione
Nota dell’editore: Benvenuti nella serie Leadership In Test del guru del software testing e consulente Paul Gerrard. La serie è pensata per aiutare i tester con alcuni anni di esperienza—soprattutto quelli che lavorano in team agili—a eccellere nei ruoli di test lead e management.
Nell’articolo precedente, abbiamo illustrato un manifesto del rischio a supporto dei manager. In questo articolo, ci porremo la domanda classica “Quanto testing è sufficiente?”. Spoiler: dipende dagli stakeholder.
Iscriviti alla newsletter di The QA Lead per ricevere notifiche quando verranno pubblicate nuove parti della serie. Questi post sono estratti dal corso Leadership In Test di Paul che consigliamo vivamente per approfondire questo e altri argomenti. Se decidi di unirti, utilizza il nostro codice coupon esclusivo QALEADOFFER per ottenere $60 di sconto sul prezzo completo del corso!
Indipendentemente dal progetto, dall'organizzazione o dall’approccio, c’è sempre spazio per la documentazione. Una buona documentazione è una benedizione, fornendo un utile registro di approccio, ambito, piani, design e risultati delle attività di analisi, sviluppo e test.
In questo articolo parlerò di:
- Il valore della documentazione
- I pericoli dei template e del copia/incolla
- Tipi di documentazione di test
- Consigli per progettare la documentazione
Iniziamo.
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 della documentazione
Nei progetti strutturati, i documenti sono solitamente considerati deliverable a sé stanti. In contesti Agile o a rilascio continuo, la documentazione può venire prodotta come sottoprodotto di valore più o meno rilevante.
La stesura di documenti può essere l’attività principale dei technical writer professionisti ma, per la maggior parte degli operatori, è un’incombenza — per quanto utile possa essere. Anche se scrivere documenti può risultare noioso per alcuni, il vero problema della documentazione è che, in molti contesti, la maggior parte della documentazione è semplicemente una perdita di tempo. Ha poco valore, è obsoleta, inaccurata — oppure tutte e tre le cose.
Ogni test manager ha scritto strategie di test che nessuno legge o condivide. I tester producono pagine e pagine di piani di test, script e report, ma l’unico contenuto di interesse per gli stakeholder sono i riassunti di una pagina all’inizio o alla fine.
Tutti abbiamo scritto documenti di cui sappiamo che hanno poco valore e che nessuno leggerà.
Ciò deriva da problemi comuni con la documentazione che incontriamo in progetti grandi e piccoli. Per ogni documento che scriviamo, ci sono diverse domande a cui dobbiamo rispondere:
- Che tipo di documento? Una policy o una strategia, un approccio o un piano, un design o l’implementazione, oppure un risultato e un’interpretazione?
- Qual è lo scopo del documento?
- Quale contenuto serve per raggiungere quello scopo?
- Quali fonti di conoscenza servono per produrre il contenuto?
- Se il documento deve cambiare nel tempo, come verrà mantenuto?
- Quale livello di dettaglio è necessario?
I pericoli dei template e del copia/incolla
Se nel vostro progetto è richiesto un documento specifico, come ad esempio un piano di test di sistema o un registro dei rischi, è facile farsi tentare dalla ricerca su internet di un template preconfezionato per questi (e altri) tipi di documenti.
Alcuni template dichiarano di essere conformi a standard o convenzioni e di essere stati scaricati e utilizzati migliaia di volte. A volte un template può sembrare perfetto per il vostro scopo. Ma, come vedremo, anche se l’indice sembra completo può portarvi in difficoltà.
Potrebbe anche essere che voi o altri nella vostra azienda abbiate redatto un documento simile per progetti precedenti. Potreste essere tentati di copiarlo, rinominarlo, cambiare i riferimenti al vecchio progetto e adattarne i contenuti.
Attenzione: Nella mia esperienza come revisore indipendente questo è molto comune e spesso rappresenta un vero problema.
Innanzitutto, di solito è palesemente ovvio quando è stata fatta una copia o una modifica. Il linguaggio utilizzato nel testo spesso sembra scollegato dal progetto e ci sono lacune e testi superflui ovunque. Perché succede questo?
L'utilizzo di un modello predefinito o di un documento esistente come fonte comporta diversi rischi:
- Sembra completo, ma potrebbe includere argomenti inappropriati ed escluderne altri invece essenziali.
- Fornisce delle intestazioni per un documento, ma assolutamente nessuna indicazione su quale contenuto sia appropriato per ciascuna sezione.
- Potrebbe contenere testo che sembra riutilizzabile e che viene copiato inalterato da un progetto precedente non collegato, ma quel testo potrebbe trasmettere un'impressione errata, o essere inaccurato o incompleto.
Utilizzare i modelli per ottenere le intestazioni e il layout di base della formattazione può essere utile, ma il problema principale dei template è questo:
La tentazione con i modelli è di fidarsi troppo e poi scrivere frasi vuote nelle varie sezioni. Dopotutto, potresti pensare che il documento serva solo a "spuntare una casella" e che tanto nessuno lo leggerà. Il rischio con i template è che si smetta di pensare e si produca un documento che ha poco valore.
Tipi di documentazione di test
In questa sezione esamineremo le varie forme di documentazione di test e discuteremo alcune considerazioni per progetti strutturati oppure agili/continui rispetto ai tradizionali a cascata.
Il set principale di documenti di test tende a ricadere nelle seguenti categorie:
- Politica e strategia (talvolta chiamato anche Piano di Test Principale)
- Definizione dei test (detta anche specifica o piani di test, in modo confuso)
- Progettazione dei test
- Casi di test
- Procedure di test o script
- Esecuzione dei test
- Pianificazione
- Registro
- Rapporto di test
La gamma di tipologie di documenti sopra elencata copre la definizione del processo di test, le attività chiave di definizione ed esecuzione e il reporting.
Ci sono diversi altri documenti collegati ai test che, in ambienti più burocratici, includerebbero la definizione e la gestione dell’ambiente di test, le procedure di accettazione, i processi di gestione degli incidenti e così via (la gestione degli incidenti sarà trattata in un prossimo articolo).
Un’altra ovvia omissione da quanto sopra sarebbe un piano generale o una pianificazione delle attività di test. Una pianificazione in realtà non è un vero documento di test: è una sottosezione del piano generale del progetto per un progetto strutturato (anche la pianificazione verrà trattata in un prossimo articolo, quindi restate sintonizzati!).
Politica, strategia, Piano di Test Principale
| Scopo |
|
| Contenuto |
|
| Fonti |
|
| Manutenzione |
|
Considerazioni Agile/Continuous La strategia di test per progetti agile che utilizzano Scrum, ad esempio, sarà probabilmente piuttosto breve e composta solo da poche pagine (se viene documentata). Il processo di test potrebbe non avere fasi, ma ci sarà probabilmente una definizione del test ai diversi livelli. Per esempio:
| |
Definizione del Test (Design, Casi, Procedure)
| Scopo |
|
| Contenuto |
|
| Fonti |
|
| Manutenzione |
|
Considerazioni Agile/Continuous L'area della definizione dei test è quella in cui l'approccio agile si differenzia più marcatamente dai progetti strutturati. Potenzialmente, i tester che si concentrano sulle funzionalità man mano che vengono consegnate potrebbero anche non creare alcuna documentazione. Questo è appropriato se esiste una policy o una linee guida di sistema per il testing delle funzionalità, ad esempio. Più verosimilmente, ci sarebbe una breve linea guida (charter) per il test di ogni funzionalità in una sessione di test esplorativo. Una linea guida è come un piano per un breve periodo di esplorazione. Di solito, la linea guida identifica:
| |
Esecuzione dei Test (Pianificazione, Log)
| Scopo |
|
| Contenuto |
|
| Fonti |
|
| Mantenimento |
|
Considerazioni Agile/Continuous Se nei progetti agile/continuous non si usano documenti formali di definizione dei test, si compensa in parte incoraggiando i tester a tenere log migliori dell'esecuzione dei test. Quando i test vengono effettuati in sessioni su base di charters, il tester è tenuto a prendere buoni appunti sui test che esegue. Esistono pochi strumenti dedicati all'annotazione dei test che vadano oltre i blocco note, quindi molti tester usano semplici editor di testo, strumenti per prendere appunti o quaderni cartacei. I log tendono a essere utilizzati per registrare tutta l’attività significativa e le osservazioni durante le sessioni mentre vengono svolte. Un tipico log di test esplorativo include aspetti come:
| |
Report di Test
| Scopo |
|
| Contenuto |
|
| Fonti |
|
| Mantenimento |
|
| Considerazioni Agile/Continuous Lo scopo di un report di test in un progetto agile potrebbe riguardare una singola iterazione o sprint, i test in vista di un rilascio, o una fase di test di livello superiore, come l'integrazione o l'accettazione complessiva del sistema. In ogni caso, lo scopo rimane invariato. Gran parte del contenuto di un report di test sarà tratto da strumenti o appunti dei tester. Il riepilogo narrativo dei risultati viene scritto da un test lead o dal tester nelle fasi di test di scala più piccola. Come di consueto, il report sarà probabilmente meno formale e ci saranno probabilmente meno dati grezzi su cui basare analisi sofisticate. Sicuramente, durante le iterazioni, l'avanzamento all'interno dell'iterazione in termini di funzionalità o user story consegnate, testate e approvate dagli utenti, potrebbe essere registrato in uno strumento o in una bacheca KanBan pubblica. In questo modo, gli stakeholder sono tenuti informati durante tutta l'iterazione e c'è meno necessità di un report formale alla fine di un periodo di testing. La visibilità dell'avanzamento è una preoccupazione chiave per i team agili. Con meeting regolari, magari stand-up giornalieri intorno a una Scrum board, ad esempio, i membri del team condividono la comprensione dello stato dei lavori, si pongono domande e concordano costantemente la situazione (e i passi successivi). In questo modo, potrebbe non essere mai necessario un report di test formale perché il team è sempre informato e aggiornato. Se i tester tengono appunti scritti delle loro attività di sessione, allora non ci sono dati analizzabili disponibili per presentare report automatizzati, quindi la reportistica di sessione e avanzamento potrebbe essere presentata in modo pubblico e visivo. Questo richiede un alto livello di disciplina e buone capacità comunicative da parte dei tester. Il test lead o il manager dovrà fornire ai portatori di interesse dei report altrettanto informativi, basati su report verbali. | |
Alcuni Consigli
Il tema della documentazione nei progetti è delicato sia per i tester che per gli altri membri dei team di progetto.
La maggior parte delle persone considera la scrittura della documentazione come un compito noioso.
Ecco alcune cose da tenere a mente quando si progetta la propria documentazione.
- La documentazione deve avere uno scopo e un pubblico ben definiti. Se il tuo pubblico non ha bisogno della documentazione, non la leggerà. Se non è in sintonia con i suoi obiettivi, non la riterrà utile.
- In generale è meglio registrare l’attività prima o mentre la si svolge. Per esempio, TDD cattura i test prima che il codice venga scritto. I log delle sessioni di test dovrebbero essere annotati durante la sessione e non dopo.
- I dati essenziali per registrare un aspetto del testing potrebbero essere minimi. Ad esempio, un test scritto su un taccuino può bastare al tester ma non è facilmente analizzabile. Forse un semplice log testuale con un po’ di markup sarebbe altrettanto veloce da annotare ma potrebbe anche essere analizzato da uno strumento apposito.
- Le procedure di test potrebbero non essere nemmeno necessarie se i tester conoscono bene il sistema sotto test. Forse è sufficiente solo un obiettivo di test o una carta test. I casi di test preparati possono essere documentati in modo minimo tramite un foglio di calcolo.
Infine
La necessità è la madre della documentazione.
Se prepari una documentazione esaustiva per i tuoi stakeholder e loro non la leggono, è perché non ne vedono il valore.
È meglio presentare a uno stakeholder un foglio bianco e aggiungere insieme gli argomenti che desidera vedere in un documento, lavorando a partire da lì. Magari chiederà tantissimi contenuti, ma ciò di cui ha realmente bisogno spesso è molto più semplice. Continua a chiederti: "Perché lo vuole?"
Grazie per la lettura, torna la prossima volta quando ci rimboccheremo le maniche e inizieremo a pianificare i test.
Iscriviti alla newsletter di The QA Lead per essere avvisato quando le nuove parti della serie saranno pubblicate. Questi post sono estratti dal corso Leadership In Test di Paul che consigliamo vivamente per approfondire questo e altri argomenti. Se ti iscrivi, usa il nostro codice coupon esclusivo QALEADOFFER per ottenere $60 di sconto sul prezzo completo del corso!
