Advertisement
  1. Web Design
  2. Documentation

Come documentare i disegni utilizzando comportamento guidato storie utente

by
Read Time:12 minsLanguages:

Italian (Italiano) translation by Loris Pizii (you can also view the original English article)

Un problema comune quando la documentazione dei requisiti è la presa di posizione dalla prospettiva del sistema per descrivere ciò che è necessario, dimenticando che è l'utente che sarà al centro delle interazioni. Storie di utente, introdotte da Agile, affrontare questo problema facendo l'utente al centro del requisito e comportamento Driven Development (BDD) prende le cose un passo ulteriore fornendo un quadro dove il comportamento dell'utente è quello che spinge lo sviluppo.

Utilizzando tecniche di BDD per creare storie utente rende più facile per scrivere e leggere documentazione requisiti. Inoltre, esso fornisce ulteriori strumenti per comunicare l'utilizzatore previsto l'esperienza di un disegno, che progettisti, sviluppatori e ingegneri QA possono utilizzare per pista veloce e persino automatizzare parte del loro lavoro. In questo articolo io esplorare questo approccio e mostrare come è possibile utilizzare per documentare i vostri propri disegni, a partire da piccole storie all'organizzazione di quelle storie per comunicare le caratteristiche completamente funzionale.

Requisiti dell'interfaccia utente vs UX requisiti

C'è un'importante distinzione da fare tra requisiti di interfaccia utente (noto anche come specifiche) e UX. Da un lato, i requisiti dell'interfaccia utente sono documenti tecnici che riportate informazioni specifiche sull'interfaccia utente, inclusi i tipi di font, colori, dimensioni e layout degli elementi. Un buon esempio di questo tipo di documentazione sono guide di stile di vita.

Requisiti di UX, d'altra parte, descrivono ciò che l'esperienza dovrebbe essere per un utente specifico, dato che questo utente è in uno scenario specifico facendo un'azione specifica. Una storia utente può catturare un requisito di UX in modo molto succinto. Per esempio:

  • Come un... utente di Publisher,
  • Vorrei.. essere in grado di esaminare articoli prima della pubblicazione,
  • In modo che.. Posso fornire un feedback e garantire la qualità in modo tempestivo.

Questa storia indica in primo luogo il ruolo dell'utente, che cosa questo utente vuole realizzare e poi spiega il motivo dietro esso. Questo è grande come esso consente agli sviluppatori e tester di ciò che è l'obiettivo finale di conoscere: sia sufficiente un utente bisogno. 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 essi possano compiere un obiettivo specifico. Potete seguire questi suggerimenti per la scrittura di storie utente buona.

Con questa storia in mente, il team di progettazione può decidere che un'azione di "approvazione" è necessario per realizzare l'obiettivo dell'utente. Quindi per fornire informazioni specifiche su come in realtà questo lavoro, è possibile utilizzare sintassi Gherkin, che è uno strumento BBD per la scrittura leggibile requisiti aziendali. Cetriolino sintassi è simile a storie utente agile in quanto fornisce un senso di scrittura requisiti che possono essere utilizzati anche come un modello. Il vantaggio è che si può ottenere in più specifiche, fornendo gli scenari e le azioni che l'utente vorrebbe senza entrare come dovrebbe essere fatto l'implementazione. Diamo un'occhiata da vicino esso.

Scrivere storie utente utilizzando la sintassi Gherkin

Le basi di una storia utilizzando Gherkin sintassi possono essere riassunti in queste parti:

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

Una caratteristica è un posto per descrivere il valore di business globale dell'attuazione. Può anche essere utilizzato per fornire informazioni aggiuntive, ad esempio le regole di business, o qualsiasi cosa che rendono più facile da capire (ad esempio collegamenti a prototipi o requisiti di interfaccia utente) la funzionalità.

Uno scenario descrive le circostanze specifiche in cui l'utente è. Da una prospettiva di progettazione utente, scenari consentono di comunicare le variabili multiple di un disegno, e come l'interfaccia utente deve gestire quelli, in base all'utente.

Una precondizione aiuta a costruire lo scenario e rimuove qualsiasi ambiguità. Ad esempio, in uno scenario che descrive un utente prima volta l'accesso a una schermata specifica, la precondizione può chiarire che l'utente è connesso.

Un'azione indica esattamente che cosa fa l'utente nell'interfaccia, ed è in genere un "trigger", ad esempio facendo clic su un pulsante, invio di un modulo, o navigando per un altro posto.

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

Con queste parti in mente, scriviamo una storia utente per la funzionalità che abbiamo descritto in precedenza:

  • Come un... utente di Publisher,
  • Vorrei.. essere in grado di esaminare articoli prima della pubblicazione,
  • In modo che.. Posso fornire un feedback e garantire la qualità in modo tempestivo.

Utilizzando la sintassi Gherkin questa storia sarebbe simile a questa:

Caratteristica
Consentire ai publisher di articoli di revisione prima pubblicazione finale e timbratura loro approvazione su di loro.
Scenario
L'approvazione di un articolo che è pronto per la pubblicazione.
Condizione preliminare
  • Dato che lo scrittore ha presentato un articolo per la pubblicazione.
  • e l'editore è letta la visualizzazione di modifica articolo
Azione
  • Quando l'editore seleziona "approvare"
Risultato
  • quindi l'articolo è pubblicato secondo la data prevista
  • e l'editore vede un avviso di successo che indica l'articolo è stato pubblicato con successo
  • e l'articolo è etichettato come "approvato"
  • e viene inviata una notifica al produttore che indica che il loro articolo è stata approvata.

Si può vedere come la storia iniziale si trasforma in un flusso più dettagliato che l'utente può seguire e quindi che possono essere testati. Si noti inoltre che le parole in grassetto sono le parole chiave che software come cetriolo utilizza per automatizzare l'esecuzione dei test. Spiegherò più su questo più tardi, 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.

Un' cosa da sottolineare è che, anche se la storia fornisce più particolari circa il flusso di utenti, l'interfaccia non è descritto. La ragione di questo è che descrivere l'interfaccia utente può rapidamente trasformare la storia in requisiti di interfaccia utente, che presenta un grosso problema come essi possono diventare obsoleti piuttosto rapidamente. Ad esempio, se la storia descrive come appare l'avviso di successo e che cosa dovrebbe dire il messaggio specifico, allora la storia può ottenere sincronizzata se niente di tutto questo cambia, creando il potenziale di test fallendo.

Quindi il trucco è di fornire dettagli sufficienti, senza fare il lavoro di strumenti più adeguati, ad esempio modelli di design, prototipi e guide di stile. A questo proposito, si noterà che l'azione indica "selezione di approvare" vs usando solo "approvazione". "Selezione di approvare" non è specifico per quanto riguarda l'aspetto di questo controllo (potrebbe essere un pulsante, un pulsante che appare come un link o una casella che è cliccabile), ma implica che un elemento dell'interfaccia utente viene attivato. Esso indica inoltre che è che questo elemento ha scritto in esso "approvare". Si tratta di una zona grigia dove sarà necessario usare il buon senso, come in alcuni casi che si vuole essere questo specifico in modo che azioni possono essere distinto dagli altri. Ad esempio, se c'è un altro modo di approvare un articolo sulla stessa pagina, che indica che, in questo scenario, l'utente dispone per "selezionare", consente di effettuare la differenziazione.

L'importanza degli scenari

Oltre la sintassi premurosa che fornisce Gherkin, una delle cose che trovo più utile utilizza la parte di "scenari". Gli scenari sono potenti perché possono essere utilizzati per la progettazione di test e assicurarsi che tutte le basi sono coperti.

Solitamente, disegni di qualsiasi genere iniziano con il percorso"felice", significato che cosa succede quando tutto va bene nell'interfaccia, e come essa si applica alla maggior parte degli utenti. Nel nostro esempio precedente avevamo:

Scenario
L'approvazione di un articolo che è pronto per la pubblicazione.

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

  • Che cosa accadrebbe se un articolo che è stato approvato ha una data di pubblicazione in passato? L'articolo dovrebbe essere pubblicato immediatamente, o dovrebbero andare in una coda?
  • E facendo un passo avanti, che cosa succede se un editore approva un articolo per errore? Qual è la procedura per annullare questa azione? Chi deve ottenere informato?

Tutte queste domande fanno parte del processo di progettazione e molto probabilmente con il tempo si salta in requisiti di documentazione che si sa le risposte. La grande notizia è che utilizzando scenari nella documentazione di storia vi aiuterà strutturarli e in molti casi vi QA aiuterà i vostri propri disegni, assicurandosi che vi sia un disegno e il flusso destinato per ciascuno di essi.

Vediamo come la nostra storia sarebbe prendere forma con gli scenari aggiuntivi:

Caratteristica Consentire ai publisher di articoli di revisione prima pubblicazione finale e timbratura loro approvazione su di loro.
Scenario 1 L'approvazione di un articolo che è pronto per la pubblicazione.
  • Dato che lo scrittore ha presentato un articolo per la pubblicazione
  • e l'editore è letta visualizzazione articolo edit
  • Quando l'editore sceglie "approvare"
  • quindi l'articolo è pubblicato secondo la data prevista
  • e l'editore vede un avviso di successo che indica l'articolo è stato pubblicato con successo
  • e l'articolo è etichettato come "approvato"
  • e viene inviata una notifica al produttore che indica che loro articolato è stato approvato.
Scenario 2

L'accesso a un articolo che non è pronto per la pubblicazione.

  • Quando...
Scenario 3

Approvazione di un articolo che ha un passato data di scadenza

  • Quando...
Scenario 4

Unapproving un articolo che ha una data di pubblicazione in futuro

  • Quando...
Scenario 5

Unapproving un articolo che è stato pubblicato

  • Quando...

A seconda della funzione, possono esserci molti scenari da considerare. La chiave è quello di tenerli corti, in modo che è possibile descrivere e testarli facilmente. Si può anche provare raggruppandoli, utilizzando comuni denominatori. Ad esempio, se alcuni scenari condividono la stessa condizione, è possibile incapsulare questo in un "Background" che può essere utilizzato da più scenari. Per esempio:

Priorità bassa
Lo scrittore ha presentato un articolo per la pubblicazione e l'editore è letta visualizzazione articolo edit.
Scenario 1
L'approvazione di un articolo che è pronto per la pubblicazione.
  • Dato che lo sfondo è soddisfatta
  • Quando...
Scenario 2
Approvazione di un articolo che ha un passato data di scadenza.
  • Dato che lo sfondo è soddisfatta
  • Quando...
Scenario 3
Unapproving un articolo che ha una data di pubblicazione in futuro.
  • Dato che lo sfondo è soddisfatta
  • Quando...

Organizzazione di storie di comunicare una caratteristica

Una sfida comune che si pone quando la documentazione dei requisiti è nel decidere quale ordine di farlo. Il motivo che, nella maggior parte casi, tutto ciò che è in costruzione, che rende difficile per testare un'interazione quando le parti delle interazioni non sono ancora costruite. Ad esempio, nell'interazione semplice di "approvazione" di un articolo, molte cose devono essere pronti:

  1. L'interfaccia utente dovrebbe essere in grado di restituire un messaggio di successo se l'approvazione è successo e un fallimento messaggio nel caso in cui c'è un problema di sistema.
  2. L'interfaccia utente dovrebbe essere in grado di "tag" articoli come approvato.
  3. L'interfaccia utente dovrebbe essere in grado di visualizzare l'articolo secondo la logica di business "pubblicato".
  4. Le notifiche di sistema devono essere attivate, scrittori possono ottenere avvertiti in caso di approvazione.

Un approccio alla documentazione dei requisiti per ciascuna di queste dipendenze di registrarli come diverse caratteristiche che possono quindi essere la priorità secondo il loro valore di business.

Caratteristica
Descrizione
Priorità
Sistema di allarme
L'interfaccia utente dovrebbe essere in grado di restituire un messaggio di successo, come pure un messaggio di errore, nel caso in cui c'è un problema di sistema
2
Sistema di etichettatura
L'interfaccia utente dovrebbe essere in grado di "tag" articoli approvato
4
Sistema di pubblicazione
L'interfaccia utente dovrebbe essere in grado di visualizzare l'articolo secondo la logica di business "pubblicato"
1
Sistema di notifiche
Le notifiche di sistema devono essere abilitate, quindi scrittori possono ottenere avvertiti in caso di approvazione
3

Quindi è possibile creare una storia di "integrazione" per portare tutti insieme. Per esempio, una storia di utente per il sistema di etichettatura sarebbe come questo:

Caratteristica
Consentire agli utenti e il sistema di tag articoli secondo un determinato stato (inedito, approvato, pubblicato o archiviati).
Scenario 1
Come contrassegnare un articolo come non pubblicati.
  • (dettagli...)
Scenario 2
Come contrassegnare un articolo approvato.
  • (dettagli...)
Scenario 3
Come contrassegnare un articolo pubblicato.
  • (dettagli...)
Scenario 4
Come contrassegnare un articolo come archiviati.
  • (dettagli...)

La storia di integrazione, è possibile fare riferimento la storia tagging, nel caso in cui i dettagli per tale scenario è necessario verificare nuovamente o se volete semplicemente sapere se tali casi sono stati già verificati.

Caratteristica
Consentire ai publisher di rivedere articoli prima della pubblicazione finale e timbro loro approvazione su di loro.
Scenario 1
L'approvazione di un articolo che è pronto per la pubblicazione.
  • Dato che lo scrittore ha presentato un articolo per la pubblicazione
  • e l'editore è letta visualizzazione articolo edit
  • Quando l'editore sceglie "approvare"
  • quindi l'articolo è pubblicato secondo la data prevista
  • e l'editore vede un avviso di successo che indica l'articolo è stato pubblicato con successo
  • e l'articolo è etichettato come "approvato" (scenario di riferimento 2 da storia di tagging)
  • e viene inviata una notifica al produttore che indica che il loro articolo è stata approvata.

Il punto è quello di evitare la ripetizione di documentazione che non solo consuma tempo inutilmente, ma che può anche diventare sincronizzati.

Trasformando le storie utente in casi di Test

Abbiamo visto quanto sia utile storie utente Driven comportamentale può essere per la scrittura di requisiti che sono stati trattati, concisa, ma anche approfondita e descrittivo. A partire dalla fase di progettazione, questo strumento può dare un buon primer per ingegneri QA per la scrittura di casi di test reali.

Oltre a questi grandi vantaggi, storie di utente del comportamento guidato in realtà può essere trasformate in test funzionali con l'aiuto di software, come cetrioli o lattuga. L'idea di base è che una volta le storie sono scritte utilizzando la sintassi di cetriolino, può metterli in un file con estensione feature all'interno della tua app e quindi eseguirli come test per mostrare se erano successo oppure no. Per un tutorial approfondito su come usare lattuga per un'implementazione di Python controllare il tutorial di David Sale:

Conclusione

Scrivere storie utente utilizzando i principi di BDD può servire per comunicare a requisiti aziendali e progettazione di dettaglio, con un approccio incentrato sull'utente, durante l'utilizzo di un linguaggio che è umano leggibile ma estensibile per interpretazione del software. Inoltre può essere utilizzato per testare:

  • i tuoi disegni come requisiti del documento
  • l'effettiva applicazione manualmente, una volta trasformato in casi di test da un assistente tecnico di QA
  • l'effettiva applicazione automaticamente, quando trasformato in test funzionali utilizzando software BDD.

Ciò significa più strati per i bug di passare attraverso, prevenire lacune nella progettazione e Bulletproof ulteriormente l'applicazione da bug errori.

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.