Leadership nei Test: Documentazione

Il valore della documentazione

Nei progetti strutturati, i documenti sono solitamente considerati deliverable a sé stanti. In regimi Agile o continui, la documentazione può essere prodotta come sottoprodotto con valore più o meno rilevante.

Scrivere documenti può essere l’attività principale degli autori tecnici professionisti, ma per la maggior parte degli operatori è una scocciatura — per quanto possa essere utile. Sebbene la stesura di documenti possa risultare noiosa 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, inesatta — o tutte e tre le cose insieme.

Ogni test manager ha scritto strategie di test che nessuno ha letto o condiviso. I tester scrivono paginate di piani di test, script e report, ma l’unica parte realmente utile agli stakeholder sono i riassunti di una pagina all’inizio o alla fine.

Questo deriva da problemi comuni con la documentazione che incontriamo in progetti sia grandi che piccoli. Per ogni documento che scriviamo, ci sono alcune domande a cui dobbiamo rispondere:

• Che tipo di documento? Una policy o strategia, un approccio o piano, una progettazione o implementazione, o un risultato e interpretazione?
• Qual è lo scopo del documento?
• Quale contenuto è necessario per raggiungere quello scopo?
• Quali fonti di conoscenza servono per creare il contenuto?
• Se il documento deve cambiare nel tempo, come sarà mantenuto?
• Quale livello di dettaglio è richiesto?

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

I pericoli dei template e del copia/incolla

Se nel tuo progetto si decide che è richiesto un certo documento, ad esempio un piano di test di sistema o un registro dei rischi, è allettante cercare su internet un template pronto per questi (e molti altri) tipi di documento.

Alcuni template possono dichiarare di seguire uno standard o una convenzione e di essere stati scaricati e utilizzati migliaia di volte. A volte un template può sembrare fare proprio al caso tuo. Ma, come vedremo, anche se l’indice sembra completo, può crearti problemi.

Potrebbe anche essere che tu o altri nella tua azienda abbiate preparato un documento simile per progetti precedenti. Potresti essere tentato di copiare e rinominare questo documento, cambiare i riferimenti al vecchio progetto ed editarne il contenuto a piacimento.

Attenzione: Per mia esperienza come revisore indipendente, questo è molto comune e spesso rappresenta davvero un problema. 

Innanzitutto, di solito è palesemente evidente che è 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é accade questo?

Utilizzare un modello predefinito o un documento esistente come fonte comporta diversi rischi:

• Sembra completo, ma potrebbe includere argomenti inappropriati ed escludere altri essenziali.
• Fornisce intestazioni per un documento, ma assolutamente nessuna indicazione su quale contenuto sia appropriato per ciascuna intestazione.
• Potrebbe contenere testi che sembrano riutilizzabili e vengono copiati invariati da un progetto precedente non correlato, ma quel testo potrebbe dare un'impressione sbagliata, oppure essere impreciso o incompleto.

Usare modelli per ottenere intestazioni e una formattazione di base può essere utile, ma il principale problema dei modelli è questo:

La tentazione dei modelli è quella di fidarsi troppo e poi scrivere contenuti vuoti per le varie sezioni. Dopotutto, si potrebbe pensare che il documento serva solo a spuntare una casella e che nessuno lo leggerà comunque. Il rischio dei modelli è smettere di riflettere e produrre un documento di scarso valore.

Tipi di documentazione di test

In questa sezione, esamineremo le varie forme di documentazione di test e discuteremo alcune considerazioni nei progetti strutturati o agili/continui rispetto ai tradizionali a cascata. 

Il set principale di documenti di test tende a rientrare nelle seguenti categorie:

• Politica e strategia (talvolta nota come Master Test Plan)
• Definizione dei test (nota anche come specifica o piani di test, in modo a volte fuorviante)
• Progettazione dei test
• Casi di test
• Procedure o script di test
• Esecuzione dei test
• Pianificazione
• Registro
• Rapporto di test

La gamma di tipologie di documenti sopra elencata copre la definizione del processo di test, le principali attività di definizione ed esecuzione e la reportistica. 

Esistono diversi altri documenti collegati ai test che, in ambienti più burocratici, includerebbero le definizioni degli ambienti di test e i processi di gestione, le procedure di accettazione, i processi di gestione degli incidenti e così via (tratteremo la gestione degli incidenti in un prossimo articolo).

Un'altra ovvia omissione dall'elenco sopra sarebbe un piano globale o la pianificazione generale delle attività di test. Un programma non è propriamente un documento di test, è una sottosezione di un piano di progetto strutturato (parleremo anche della pianificazione dei programmi in un prossimo articolo, quindi restate sintonizzati!).

Politica, strategia, Master Test Plan

Esecuzione dei Test (Pianificazione, Registro)

Scopo	Specificare l'ordine di esecuzione dei test Registrare lo stato dei test – eseguito/non eseguito e stato Fornire i risultati dell'esecuzione dei test per la reportistica
Contenuto	Identificativo del test, tester, data/ora di esecuzione, stato Per i test che mostrano un comportamento anomalo (opzionalmente): Dettagli del test come eseguito dove i dettagli differiscono dallo script Risultati effettivi vs attesi Altre osservazioni, interpretazioni Stato del test (difetto, errore di configurazione o ambientale ecc.) ID dell'osservazione o del report di difetto (dove appropriato)
Fonti	Inventario dei casi/procedure di test, tester
Mantenimento	Il programma cambierà in linea con l'ambito dei test e le procedure verranno modificate, rimosse o aggiunte al piano. I test probabilmente saranno eseguiti più volte sia come re-test che come test di regressione. Il registro dovrebbe conservare una cronologia completa di tutti i test previsti.
Considerazioni Agile/Continuous Se i progetti agile/continuous non prevedono documenti di definizione dei test, in parte compensano incoraggiando i tester a tenere registri più accurati dell'esecuzione dei test. Quando i test vengono effettuati in sessioni secondo delle "charter", ci si aspetta che il tester tenga buoni appunti sui test eseguiti. Gli strumenti dedicati al logging dei test sono pochi e molto simili a semplici taccuini, così molti tester usano editor di testo semplici, applicazioni per prendere appunti o notebook cartacei. I registri vengono utilizzati per annotare tutte le attività e osservazioni significative mentre vengono svolte le sessioni di test. Un tipico registro di test esplorativi contiene elementi quali: Struttura delle funzionalità esplorate (una mappa del territorio) Osservazioni, domande relative alle funzionalità esplorate nella sessione Modelli, elenchi, tabelle di elementi di test e idee di test Test eseguiti, annotati con dettagli sufficienti per poterli ripetere Anomalie riscontrate – fallimenti, comportamenti dubbi, risposte lente, cattiva esperienza utente e così via Tempo impiegato nell'esplorazione, preparazione dei test, esecuzione, analisi, registrazione dei bug, retest, test di regressione, tempi non produttivi Data/ora della registrazione Dove i tester annotano l'attività della sessione in strumenti di note-taking o altri strumenti, usano marcature o linguaggi specifici di dominio per strutturare i loro appunti. Questi possono essere interpretati da semplici strumenti interni per fornire riepiloghi delle attività da usare nei report di test. I test eseguiti con strumenti (proprietari o open-source) mantengono automaticamente dei registri. Tipicamente questi log sono interrogabili dallo strumento o da procedure scritte dagli utenti.

Report di Test

Scopo	Comunicare l’esito di una fase di test, di test selezionati o di una sessione di test Può anche applicarsi a requisiti tecnici o ad attività di test non funzionali, in tal caso il contenuto differirà per adattarsi all’obiettivo del test Informare parzialmente gli stakeholder in modo che possano prendere una decisione sull’accettazione o il rilascio di un sistema o di un sottosistema.
Contenuto	Orari di inizio/fine dei test e durata Ambiente di test Versione/i del software e del sistema sotto test Obiettivi e ambito dei test (da strategia di test, definizione del test) Riepilogo narrativo dei risultati Funzionalità ritenute conformi ai requisiti Rischi ritenuti gestiti Test rilevanti ancora aperti (falliti o bloccati) Funzionalità parzialmente o non testate Rischi parzialmente o non affrontati. Dettagli dei risultati dei test con output dai log dei test ecc. Stato delle soluzioni temporanee per anomalie ancora presenti Analisi dei test Progresso e stato dei test nel tempo Statistiche sugli incidenti
Fonti	Strategia di test, definizioni di test, log dei test, rapporti sugli incidenti Gran parte del contenuto di un report di test sarà costituito dagli strumenti utilizzati per registrare le definizioni di test, il log dei test e il registro degli incidenti o difetti.
Mantenimento	Questo è uno snapshot in un momento specifico della fase di esecuzione dei test e non viene mantenuto.
Considerazioni Agile/Continuous Lo scopo di un report di test in un progetto agile potrebbe coprire una singola iterazione o sprint, il testing per un rilascio, oppure una fase di test ad un livello superiore come integrazione o accettazione dell’intero sistema. Comunque sia, lo scopo non cambia. Gran parte del contenuto di un report di test deriva da strumenti o appunti dei tester. Il riepilogo narrativo dei risultati è scritto da un test lead o dal tester per una fase di test di dimensioni ridotte. Come di consueto, il report sarà probabilmente meno formale e ci saranno probabilmente meno dati grezzi che possano costituire la base per analisi sofisticate. Sicuramente, durante le iterazioni, il progresso rispetto all’iterazione in termini di funzionalità o storie consegnate, testate e approvate dagli utenti, potrebbe essere registrato in uno strumento o in una KanBan board pubblica. In questo modo, gli stakeholder sono costantemente aggiornati sul progresso durante l’iterazione e c’è minore necessità di un report formale al termine di un periodo di test. La visibilità sul progresso è una preoccupazione chiave per i team agili. Con riunioni frequenti, magari giornaliere attorno a una Scrum board ad esempio, i membri del team condividono la loro comprensione del progresso, si mettono in discussione tra loro e concordano costantemente la situazione (e i passaggi 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 i report di sessione e di progresso potrebbero essere presentati in modo pubblico e visuale. Ciò richiede un livello elevato di disciplina e buone capacità comunicative da parte dei tester. Il responsabile dei test dovrà fornire un report altrettanto informativo agli stakeholder basandosi su report verbali.

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

Alcuni consigli

Il tema della documentazione nei progetti è delicato tanto per i tester quanto per gli altri membri del team di progetto.

Ecco alcuni aspetti da tenere a mente nella progettazione della vostra documentazione.

1. La documentazione deve avere uno scopo e un pubblico ben definiti. Se il vostro pubblico non ha bisogno della documentazione, non la leggerà. Se non è in linea con i loro obiettivi, non vi si sentiranno coinvolti.
2. In generale è meglio raccogliere la registrazione di un’attività prima o mentre la si svolge. Ad esempio, il TDD definisce i test prima che venga scritto il codice. I log delle sessioni di test dovrebbero essere raccolti durante la sessione e non scritti successivamente.
3. I dati essenziali per registrare un aspetto del testing possono essere minimi. Ad esempio, un test annotato su un quaderno può essere sufficiente per il tester ma difficilmente sarà analizzabile. Forse un semplice log testuale con qualche markup potrebbe essere altrettanto veloce da registrare ma anche analizzabile da uno strumento personalizzato.
4. Le procedure di test potrebbero non essere affatto necessarie se i tester conoscono bene il sistema sotto test. In certi casi potrebbe bastare un semplice obiettivo o mandato di test. I casi di test preparati possono essere documentati in modo minimale in un foglio di calcolo.

Infine

Se preparate una documentazione completa per i vostri stakeholder e loro non la leggono, è perché non vedono valore in essa.

È meglio presentare a uno stakeholder un foglio bianco e aggiungere insieme gli argomenti che deve vedere in un documento e lavorare da lì. Potrebbero chiedere moltissimi contenuti, ma in realtà ciò di cui hanno davvero bisogno è piuttosto semplice. Continuate a chiedervi: “perché vogliono questo?”

Grazie per la lettura, seguiteci la prossima volta quando ci rimboccheremo le maniche per cominciare con un po’ di test planning.

Iscriviti alla newsletter di The QA Lead per ricevere una notifica quando saranno pubblicate le 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 iscriverti, utilizza il nostro codice sconto esclusivo QALEADOFFER per ottenere $60 di sconto sul prezzo completo del corso!