Come documentare i tuoi progetti usando le User Story comportamentali

Un problema comune quando la documentazione dei requisiti prende una posizione dal punto di vista del sistema per descrivere ciò che è necessario, dimenticando che è l'utente che sarà al centro delle interazioni. Le storie degli utenti, introdotte da Agile, affrontano questo problema rendendo l'utente il centro del requisito, e Behavior Driven Development (BDD) fa un ulteriore passo avanti fornendo un quadro in cui il comportamento dell'utente è ciò che guida lo sviluppo.

L'uso delle tecniche BDD per creare storie di utenti rende più facile scrivere e leggere i requisiti di documentazione. Inoltre, fornisce strumenti aggiuntivi per comunicare l'esperienza utente prevista di un progetto, che i progettisti, gli sviluppatori e gli ingegneri di QA possono utilizzare per tracciare e automatizzare parte del loro lavoro. In questo articolo esplorerò questo approccio e mostrerò come puoi usarlo per documentare i tuoi progetti, partendo da piccole storie per organizzare quelle storie per comunicare funzionalità pienamente funzionali.

Requisiti dell'interfaccia utente rispetto ai requisiti UX

Esiste un'importante distinzione tra i requisiti UI (noti anche come specifiche) e UX. Da un lato, i requisiti dell'interfaccia utente sono documenti tecnici che elencano specifiche sull'interfaccia utente, inclusi tipi di carattere, colori, dimensioni e layout degli elementi. Un buon esempio di questo tipo di documentazione sono le guide allo stile di vita.

I requisiti UX, d'altra parte, descrivono ciò che l'esperienza dovrebbe essere per a specifico utente, dato che questo utente si trova in uno scenario specifico che fa un'azione specifica. Una user story può acquisire un requisito UX in un modo molto succinto. Per esempio:

• Come un… utente editore,
• Voglio… essere in grado di recensire gli articoli prima che vengano pubblicati,
• Così che… Posso fornire feedback e garantire la qualità in modo tempestivo.

Questa storia indica in primo luogo il ruolo dell'utente, ciò che questo utente desidera realizzare e quindi spiega il motivo alla base. Questo è ottimo in quanto fornisce informazioni a sviluppatori e tester su quale sia l'obiettivo finale: soddisfare le esigenze degli utenti. Si noti che le parole in grassetto sono il modello utilizzato per scrivere la storia. C'è sempre un utente, che vuole fare qualcosa, in modo che possa raggiungere un obiettivo specifico. Puoi seguire questi suggerimenti per scrivere buone storie di utenti.

Tenendo presente questa storia, il team di progettazione può decidere che è necessaria un'azione di "approvazione" per raggiungere l'obiettivo dell'utente. Quindi, per fornire informazioni specifiche su come funzionerà, è possibile utilizzare la sintassi Gherkin, che è uno strumento BBD per la scrittura di requisiti leggibili per il business. La sintassi Gherkin è simile alle storie utente agili in quanto fornisce un modo di scrivere requisiti che possono essere utilizzati anche come modello. Il vantaggio è che puoi entrare in più specifiche, fornendo scenari e azioni che l'utente vorrebbe fare senza entrare nel modo in cui l'implementazione dovrebbe essere eseguita. Diamo un'occhiata da vicino.

Scrivere le User Story usando la sintassi Gherkin

Le basi di una storia che utilizza Gherkin Syntax possono essere riassunte in queste parti:

• Una caratteristica
• Uno scenario
• Una precondizione
• Un'azione
• Un risultato

Una caratteristica è un luogo per descrivere il valore commerciale complessivo dell'implementazione. Può anche essere usato per fornire informazioni aggiuntive, come le regole aziendali, o qualsiasi altra cosa che renda la caratteristica più facile da capire (come collegamenti a prototipi o requisiti di interfaccia utente).

Uno scenario descrive le circostanze specifiche in cui si trova l'utente. Dal punto di vista del design dell'utente, gli scenari consentono di comunicare le molteplici variabili di un progetto e come l'interfaccia utente deve gestirli, secondo l'utente.

Una precondizione aiuta a costruire lo scenario e rimuove ogni ambiguità. Ad esempio, in uno scenario che descrive un utente che accede per la prima volta a una determinata schermata, la condizione preliminare può chiarire che l'utente ha effettuato l'accesso.

Un'azione indica esattamente ciò che l'utente fa nell'interfaccia ed è tipicamente un "trigger", come fare clic su un pulsante, inviare un modulo o navigare in un altro luogo.

Un risultato è la conseguenza dell'azione e dovrebbe sempre essere qualcosa che può essere testato.

Con queste parti in mente, scriviamo una user story per la funzione che abbiamo descritto in precedenza:

• Come un…  utente editore,
• Voglio…  essere in grado di recensire gli articoli prima che vengano pubblicati,
• Così che…  Posso fornire feedback e garantire la qualità in modo tempestivo.

Usando Gherkin Sintassi questa storia sarebbe simile a questa:

Puoi vedere come la trama iniziale si trasforma in un flusso più dettagliato che l'utente può seguire e quindi che può essere testato. Inoltre, si noti che le parole in grassetto sono le parole chiave utilizzate da software come cetriolo per automatizzare l'esecuzione dei test. Spiegherò di più su questo in seguito, ma per ora, voglio sottolineare che queste parole chiave sono molto utili anche per scrivere la storia perché aiutano a distinguere le diverse parti della storia.

Qualcos'altro da sottolineare è che sebbene la trama fornisca maggiori dettagli sul flusso dell'utente, l'interfaccia non è descritta. La ragione di ciò è che la descrizione dell'interfaccia utente può trasformare rapidamente la storia in requisiti dell'interfaccia utente, il che rappresenta un grosso problema in quanto possono essere superati abbastanza rapidamente. Ad esempio, se la storia descrive come appare l'avviso di successo e quale dovrebbe essere il messaggio specifico, allora la storia può andare fuori sincrono se una di queste modifiche cambia, creando il potenziale di test falliti.

Quindi il trucco è fornire dettagli sufficienti, senza fare il lavoro di strumenti più adeguati, come prototipi di design, prototipi e guide di stile. A questo proposito, noterai che l'azione indica "selezionare approvare" o semplicemente "approvare". "La selezione dell'approvazione" non è specifica su come si presenta questo controllo (potrebbe trattarsi di un pulsante, di un pulsante simile a un collegamento o di una casella che è possibile fare clic), ma implica l'attivazione di un elemento nell'interfaccia utente. Indica anche che questo elemento ha scritto in esso "approva". Questa è un'area grigia in cui è necessario utilizzare il buon senso, poiché in alcuni casi si vorrà essere così specifici in modo che le azioni possano essere distinte dagli altri. Ad esempio, se esiste un altro modo di approvare un articolo sulla stessa pagina, indicando che in questo scenario l'utente deve "selezionarlo", consente di effettuare la differenziazione.

L'importanza degli scenari

Oltre alla sintassi ponderata fornita da Gherkin, una delle cose che trovo più utile è l'utilizzo della parte "scenari". Gli scenari sono potenti perché possono essere utilizzati per testare il design e assicurarsi che tutte le basi siano coperte.

Di solito, i progetti di qualsiasi tipo iniziano con il "percorso felice", ovvero cosa succede quando tutto va bene nell'interfaccia e come si applica alla maggior parte degli utenti. Nel nostro esempio precedente abbiamo avuto:

Inoltre, poiché sappiamo che gli articoli hanno date di pubblicazione, possiamo anche affermare: questo è il nostro primo scenario perché nella maggior parte dei casi gli articoli che devono essere approvati devono essere pronti per la pubblicazione. Ma questo porta la domanda: cosa succede quando un articolo non è pronto per la pubblicazione e l'editore lo accede? Dovrebbero anche essere in grado di accedere a quegli articoli?

• Cosa succederebbe se un articolo approvato avesse una data di pubblicazione nel passato? L'articolo dovrebbe essere pubblicato immediatamente o dovrebbe entrare in coda? 
• E facendo un passo avanti, e se un editore approvi un articolo per errore? Qual è la procedura per annullare questa azione? Chi dovrebbe essere informato?

Tutte queste domande fanno parte del processo di progettazione e molto probabilmente, nel momento in cui salti nei requisiti della documentazione, conoscerai le risposte. La grande notizia è che l'utilizzo di scenari nella documentazione della tua storia ti aiuterà a strutturarli e in molti casi ti aiuterà a progettare i tuoi stessi progetti, assicurandoti che ci sia un design e un flusso destinati a ciascuno di essi.

Vediamo come la nostra storia prenderà forma con gli scenari aggiuntivi:

A seconda della funzione, ci possono essere molti scenari da considerare. La chiave è di tenerli corti, in modo che tu possa descriverli e testarli facilmente. Puoi anche provare a raggrupparli, utilizzando denominatori comuni. Ad esempio, se alcuni scenari condividono la stessa condizione preliminare, è possibile racchiuderlo in uno "Sfondo" che può essere utilizzato da più scenari. Per esempio:

Organizzazione delle storie per comunicare una caratteristica

Una sfida comune che si presenta quando si documentano i requisiti è nel decidere quale ordine farlo. Il motivo è che nella maggior parte dei casi tutto è in costruzione, il che rende difficile testare un'interazione quando le parti delle interazioni non sono ancora state costruite. Ad esempio, nella semplice interazione di "approvare" un articolo, molte cose devono essere pronte:

1. L'interfaccia utente dovrebbe essere in grado di restituire un messaggio di successo se l'approvazione ha esito positivo e un messaggio di errore nel caso in cui vi sia un problema di sistema.
2. L'interfaccia utente dovrebbe essere in grado di "etichettare" gli articoli come approvati.
3. L'interfaccia utente dovrebbe essere in grado di visualizzare l'articolo in base alla logica di business "pubblicata".
4. Le notifiche di sistema devono essere abilitate, in modo che gli autori possano ricevere un avviso quando si verifica l'approvazione.

Un approccio per documentare i requisiti di ciascuna di queste dipendenze per registrarle come caratteristiche diverse che possono quindi essere priorizzate in base al loro valore aziendale.

Quindi puoi creare una storia di "integrazione" per riunirli tutti insieme. Ad esempio, una user story per il sistema di tagging vorrebbe questo:

Nella storia di integrazione, puoi fare riferimento alla storia del tagging, nel caso in cui i dettagli per tale scenario debbano essere nuovamente verificati o se semplicemente vuoi sapere se questi casi sono già stati verificati.

Il punto è evitare di ripetere la documentazione che non solo consuma il tempo inutilmente, ma anche che può diventare fuori sincrono.

Trasformare le User Story in Test Case

Abbiamo visto quanto siano utili le User Story comportamentali utili per la scrittura di requisiti focalizzati, concisi, ma anche completi e descrittivi. A partire dalla fase di progettazione, questo strumento può dare un buon primer agli ingegneri del controllo qualità per scrivere casi di test reali.

Oltre a questi grandi vantaggi, le User Story comportamentali possono essere trasformate in test funzionali con l'aiuto di software come Cucumber o Lettuce. L'idea di base è che una volta che le storie sono state scritte usando la sintassi Gherkin, puoi inserirle in a .caratteristica file all'interno della tua app, quindi eseguili come test per mostrare se hanno avuto successo o meno. Per un approfondito tutorial su come usare l'implementazione di Lettuce for a Python, segui il tutorial di David Sale:

Conclusione

Scrivere storie di utenti usando i principi di BDD può servire a comunicare in dettaglio i requisiti di business e di progettazione, con un approccio incentrato sull'utente, mentre si utilizza un linguaggio che è leggibile dall'uomo ma estendibile per l'interpretazione del software. Inoltre può essere usato per testare:

• i tuoi disegni personali come documenti requisiti
• l'applicazione effettiva manualmente, una volta trasformata in casi di test da un ingegnere di qualità
• l'applicazione effettiva automaticamente, quando trasformata in test funzionali mediante software BDD.

Ciò significa che devono passare più livelli per i bug, evitare lacune nella progettazione e proteggere ulteriormente l'applicazione da errori di bug.