Far partecipare i tester alla raccolta dei requisiti riduce i difetti

In una Three Amigos su una nuova funzionalità, il tester chiede: cosa vede un utente senza permesso quando apre questa pagina? La stanza si ferma. Nessuno ha scritto le regole di autorizzazione. La squadra aggiorna i requisiti prima di toccare il codice¹.

Requirements elicitation significa tirare fuori, chiarire e rifinire cosa deve fare un sistema parlando con gli stakeholder. Si lavora con domande e scenari, più che con documenti. È anche chiamata requirements gathering o discovery, ed è una competenza chiave per business analyst e, sempre più spesso, per tester e test manager¹.

Perché conta: i requisiti raramente arrivano completi. Dentro ci sono buchi, assunzioni e casi limite. Se restano occulti, diventano difetti. I tester portano un’angolazione utile, pensano a cosa può andare storto e innescano correzioni prima dello sviluppo¹.

In pratica, l’elicitation si fa in conversazione. Formati comuni:

• Three Amigos, dove business, sviluppo e testing rivedono una feature insieme. È il momento in cui saltano fuori regole di permesso mancanti o ambiguità di percorso¹.
• Lavoro fianco a fianco con il business analyst, per capire logica e obiettivi. Un caso tipico: integrare due applicazioni che si passano utenti, concordando scenari positivi, negativi ed edge case da testare¹.
• Walkthrough dei percorsi utente. Prima il happy path, poi i negative path, infine gli edge case. Ogni risposta aggiorna requisiti e copertura di test pianificata¹.
• Una domanda guida: quale problema di business risolve questo work item o questa funzionalità¹?

Esempi concreti aiutano a far emergere le zone d’ombra. In una Three Amigos: cosa succede se un utente senza il ruolo corretto prova a salvare? Il sistema mostra l’azione, la nasconde o blocca con errore? In un’integrazione tra due app: se il trasferimento dell’utente fallisce a metà, quale stato rimane di qua e di là? Se il happy path è chiaro, i negative path esplicitano regole, messaggi e ripristini. Queste domande portano cambi a specifiche e test, prima di scrivere una riga di codice¹.

Il tempismo è decisivo. Fare domande solo quando parte il testing costa molto di più che cambiare requisiti in analisi. Un altro errore è trattare l’elicitation come compito esclusivo del business analyst. Così le preoccupazioni sulla testabilità non emergono. Coinvolgere i tester nelle conversazioni iniziali riduce rischi e rework¹.

Chiarire i termini evita fraintendimenti: elicitation riguarda l’estrazione di informazioni dagli stakeholder. Analysis riguarda l’esame, l’organizzazione e la validazione di quelle informazioni per costruire e testare il sistema. Sono fasi distinte, ma si alimentano a vicenda¹.

Output attesi dall’elicitation: requisiti aggiornati, scenari concordati, copertura di test allineata al rischio. Non serve un tomo, bastano note condivise dove ogni decisione è tracciabile. Quando una domanda “what if” cambia una regola, si aggiorna subito il requisito collegato e lo scenario di test. La squadra vede lo stesso film, dal business all’ingegneria¹.

Chiusura operativa: mettete in calendario una Three Amigos all’ingresso in analisi. Portate tre domande “what if” per il happy path, tre per i negative path e tre edge case. Annotate le risposte e aggiornate requisito e test sul posto. È un’ora spesa che toglie giorni di difetti downstream¹.