Diecimila Città — Oggettivazione e Documentazione dei Test

O forse sì?

Ho spesso visto team QA intraprendere coscienziosamente e con diligenza l'eroico compito di documentare completamente i propri test. Per una release. E poi quella documentazione tende a finire nel dimenticatoio. Ad accumulare polvere digitale su qualche rete. E non perché il team QA abbia smesso di credere nella sua importanza. Sono semplicemente esausti dallo sforzo necessario per aggiornarla per la prossima major release. 

Perché, con zelo, il team QA ha scritto descrizioni dei test incredibilmente dettagliate, suddividendo tutto a un livello maniacalmente microscopico di iper-specificità. Creando documentazione separata per ogni aspetto o attributo di una singola funzionalità o interazione utente. Generando decine di singole descrizioni di test e attività per ciò che è fondamentalmente un'unica attività di test. È come quella persona davanti a te nella fila al supermercato che insiste a pagare 80 dollari di spesa in monete.

Il risultato di questo zelo atomizzante è la generazione di centinaia, a volte migliaia di descrizioni di test per la release in questione. La QA, inconsapevolmente, ha finito per scrivere un romanzo di Dickens. "Storia di diecimila città". Ne hai mai letto uno davvero? Neanch'io.

La conseguenza è che nessuno ha il tempo o la pazienza di aggiornare queste migliaia di descrizioni di test individuali. Perché la priorità sarà sempre testare la prossima iterazione del software, dato che ciò genera effettivamente ricavi, mentre aggiornare la documentazione non lo fa. 

Ma anche perché le applicazioni per la documentazione dei test non facilitano affatto l'aggiornamento massivo dei record di documentazione. Apportare modifiche globali a classi di test può essere laborioso e poco intuitivo nella maggior parte delle applicazioni (questo vale anche per molti software di tracciamento dei difetti — ancora oggi). Aumentando i costi in termini di tempo e salute mentale necessari per farlo.

Di conseguenza, tutta quella meticolosa documentazione viene infine abbandonata. E tutto il tempo speso per crearla risulta, alla fine, sprecato. Perché non è riutilizzabile. È un successo unico e basta. È la "I Melt With You" del software testing. Tuttavia, la documentazione dei test è una necessità assoluta per uno sforzo di test ripetibile e sistematico. Da qui il paradosso.

Esiste una via d'uscita da questo dilemma. E, per quanto mi dolga ammetterlo, dovremmo guardarci all'ingegneria per trovare la soluzione. O almeno trarne ispirazione. Gli ingegneri hanno affrontato un problema simile nei primi anni dello sviluppo software commerciale. A causa delle limitazioni dei linguaggi di programmazione dell'epoca, per ogni funzione dovevano riscrivere codice per gli stessi attributi, azioni e salvaguardie di base. Più e più volte. La gestione della memoria/garbage collection era un buon esempio (e pericoloso) di questo problema.

Di conseguenza, gli ingegneri producevano enormi quantità di codice ridondante e sprecavano molto tempo (non che agli ingegneri ciò dispiaccia necessariamente. Ebay esiste ancora per un motivo). Poi qualche genio ha inventato la programmazione orientata agli oggetti, in cui oggetti di codice potevano essere creati ereditando attributi predefiniti per loro stessa natura. Non era più necessario scrivere (o copiare/incollare) lo stesso codice ogni volta. Il che significava che la qualità non dipendeva più dalla memoria o dalle abilità di digitazione di un singolo ingegnere. Di questo la QA sarà eternamente grata.

Questa è una visione molto utile per la QA mentre si arrovella nel vicolo cieco della documentazione dei test. Il concetto di orientamento agli oggetti come esiste nell'ingegneria non può essere applicato direttamente a questo problema, ma come metafora offre molto. L'ingegno, per definizione, si adatta facilmente a nuove situazioni.

Molte volte nella mia carriera mi sono trovato ad affrontare il problema di come creare documentazione dei test che fosse completa ma concisa, utilizzabile subito ma anche facilmente riutilizzabile per le release future. E la soluzione a cui sono finalmente giunto è stata applicare proprio l'idea di un "oggetto" alla documentazione dei test. 

Qui non sto parlando semplicemente di un template per la documentazione dei test. Questi sono utilissimi come strumento di standardizzazione, certo, ma irrilevanti per il problema che affrontiamo. Ho sviluppato l'idea che i test potevano essere documentati in modo da includere, in un unico documento, tutte le loro varie modalità, punti di inflessione, flussi di lavoro e condizioni speciali. Una volta accesa questa lampadina nella mia testa ottusa, la risposta è sembrata improvvisamente molto semplice. E molto realizzabile.

Entriamo nel dettaglio.

Prendere La Pillola Rossa

La risposta è vedere ogni test individuale, e quindi anche il suo artefatto documentale, non come l'asserzione/desrizione di un test su un singolo dato o condizione isolata. Ma come una descrizione dell'intera matrice (hai visto il riferimento?) di condizioni in cui la funzionalità o capacità deve essere validata. 

Questo implica un approccio olistico alla definizione dei singoli test. Un compito di test coerente e unico non può essere utilmente frammentato in dozzine di "test" indipendenti senza, paradossalmente, cancellare la specificità del test della funzionalità nel suo insieme. È una questione di non vedere la foresta per gli alberi.

Qui è utile rivedere il concetto di contesto di test. Perché, per implementare efficacemente l’idea di un oggetto di test, devi prima essere in grado di separare il nucleo immodificabile di una funzionalità dai suoi contesti secondari di applicazione e funzionamento. Questa è una questione che lo stile atomico di documentazione dei test evita, e così i tester non imparano mai come svolgere sistematicamente e consapevolmente questa analisi. Ancora uno svantaggio del potere atomico.

Detto in modo semplice, i contesti di test per una funzionalità o un sistema sono l’insieme di condizioni, ambienti, flussi di lavoro o stati che possono variare indipendentemente l’uno dall’altro nei limiti della funzionalità stessa. I sistemi operativi e le versioni del sistema operativo ne sono un esempio chiaro. Le lingue straniere un altro. Gli stati di sistema ancora un altro (ad esempio, nel caso di un server web, la cache di memoria attiva o disattiva). Una volta compresa questa distinzione, potrai facilmente trovarne molte altre rilevanti per i tipi di prodotti che stai testando.

Una volta completata questa analisi (che dovrebbe essere la base di ogni pianificazione professionale dei test), hai poi la possibilità di creare forme compatte di documentazione dei test che internalizzano questa distinzione. Nel sistema che sto descrivendo, un singolo artefatto di documentazione del test sarà composto da:

1. Una descrizione della funzionalità o capacità principale oggetto del test.
2. Un elenco di tutti i contesti in cui la funzionalità principale deve essere validata.
3. Qualsiasi altro elemento che normalmente includeresti (precondizioni affinché il test sia valido, risorse di sistema e privilegi necessari per eseguire il test, un link ai requisiti di prodotto di riferimento, ecc.). Nessuno di questi viene sostituito da ciò che sto proponendo.

A questo punto potresti pensare: "Ehi, potrebbe essere una marea di contesti!". Beh, sì. Ma guardala così: fare in questo modo non comporta più lavoro per te. Anzi, lo riduce. Redigere piani di test completi diventa più semplice con la nostra lista curata di strumenti per la documentazione dei test software. Perché questo metodo ridurrà *notevolmente* il numero di test individuali che dovrai creare e che dovrai mantenere (o rifiutarti di farlo) in futuro. Mentre nel sistema atomico, dovresti produrre un artefatto di documentazione per ciascuno di essi. Il che conduce al circolo vizioso descritto all'inizio di questo articolo.

Questo metodo di documentazione dei test ha alcune conseguenze di processo che all’inizio possono sembrare scomode. O addirittura destabilizzanti. E non solo per il QA, ma anche per altri stakeholder del progetto. Tuttavia, se tutti i coinvolti si prendono il tempo per comprenderle, vedranno che si tratta in realtà di miglioramenti. Per tutti.

Una delle principali è che, integrando la matrice dei contesti di una funzionalità all’interno del test principale, ciò significa, logicamente, che se quel singolo test fallisce anche solo in uno di quei contesti, allora l’intero test è considerato fallito. Anche se si tratta solo di uno. Posso già immaginare il panico tra gli ingegneri. Perché potrebbe sembrare che tu stia creando condizioni svantaggiose, fissando il limite per considerare "superato" un test a un livello impossibile. Ma questa paura si può facilmente dissipare. Basta far notare due cose a loro, e una terza a te stesso:

1. Questo metodo in realtà ridurrà il numero di bug rilevati sui loro lavori tramite i test. Con il metodo atomico, infatti, il fallimento di uno solo di quei contesti avrebbe prodotto un suo bug separato. Quindi aumentando il numero totale di bug associati a quella unica funzionalità. Questo dovrebbe far sorridere gli ingegneri. E i project manager.
2. Secondo, testare con questa metodologia fornisce automaticamente il contesto per l’effettiva portata del malfunzionamento funzionale. Perché qual è la prima domanda che l’ingegnere che riceve il bug ti farà sempre? "Uh, succede ovunque? O solo nel contesto X?" E invece di dover correre alla scrivania per ripetere il test nel contesto X (magari te ne eri dimenticato durante i test iniziali?), avrai già quella risposta, e l’ingegnere non avrà scuse per evitare di lavorarci sopra (quello che il QA dà, con meno bug, lo toglie poi).
3. Terzo, l’analisi dei contesti per la documentazione del test garantisce che tu abbia effettivamente considerato tutti i contesti rilevanti quando hai documentato il test. Il che significa che sarà meno probabile dover affrontare quei momenti di panico—tre giorni prima o, peggio, dopo la release—in cui ti accorgi di aver dimenticato contesti importantissimi. Un’azione QA guidata dal panico non è né efficace né psicologicamente piacevole.

In Machina

Questo metodo di documentazione dei test ispirato agli oggetti ridurrà drasticamente la quantità di artefatti di documentazione da produrre, rendendo quindi molto più probabile che tu possa (e voglia) aggiornarli costantemente per le versioni successive.

L’unico elemento di difficoltà è che poche applicazioni per la documentazione dei test sono predisposte per documentare i test in questo modo in modo nativo. Tendono a dare per scontato il modello atomico di documentazione, poiché purtroppo è la norma, e quindi non dispongono di funzionalità integrate per supportare facilmente il modello a oggetti che ho descritto qui. 

È per questo motivo che spesso ho fatto ricorso a soluzioni applicative molto meno elaborate — come Excel — che in realtà, a questo scopo, sono molto più flessibili e facili da personalizzare, perché sono di uso generale. Lo svantaggio di questa strategia è che integrarle con Jira e simili diventa complicato. Ma forse, dopotutto, l’integrazione è sopravvalutata.

In ogni caso, resta il fatto che molte applicazioni di documentazione dei test e dei difetti rendono diabolico l’aggiornamento in massa dei singoli record. Indipendentemente dai protocolli che scegli di utilizzare per crearli. Ma questo è vero, qualunque sia il modo in cui scegli di scrivere la tua documentazione di test. Affrontiamo un problema alla volta, gente.

Chiedo scusa in anticipo (o nel tuo caso, a posteriori) per non averti fornito un modello di oggetto di test. Per esperienza, fornire dei modelli di solito è una cattiva idea perché le persone iniziano semplicemente a usare il tuo modello. La disponibilità di template pronti e generici tende a bloccare e a interrompere la creatività del team stesso nel creare un modello che risponda alle sue reali esigenze, ai propri processi e agli strumenti utilizzati sul campo. Quindi, niente rancore.

Sono sempre disponibile per domande e suggerimenti. Inviami pure un post o un messaggio su LinkedIn.

Come sempre, ti auguro buona fortuna.