Så här dokumenterar du dina designer med hjälp av beteendedrivna användarhistorier

En vanlig fråga vid dokumentation av krav är att ta ställning till systemperspektivet för att beskriva vad som behövs, glöm det att det är användaren som kommer att ligga i mitten av interaktionerna. Användarberättelser, som introducerades av Agile, tar itu med problemet genom att göra användaren centralt i kravet och beteendedriven utveckling (BDD) tar saker ytterligare ett steg som ger en ram där användarbeteendet är det som driver utvecklingen.

Att använda BDD-tekniker för att skapa användarhistorier gör att dokumentationskrav är enklare att skriva och läsa. Dessutom ger det ytterligare verktyg för att kommunicera den avsedda användarupplevelsen av en design, som designers, utvecklare och QA-ingenjörer kan använda för att snabbt spåra och till och med automatisera en del av sitt arbete. I denna artikel kommer jag att utforska detta tillvägagångssätt och visa hur du kan använda den för att dokumentera dina egna mönster, från små historier för att organisera dessa historier för att kommunicera fullt fungerande funktioner.

UI Krav vs UX Krav

Det finns en viktig skillnad att göra mellan användargränssnittskrav (även kända som specifikationer) och UX-krav. Å andra sidan är användargränssnittskrav tekniska dokument som innehåller specifikationer om användargränssnittet, inklusive typsnitt, färger, dimensioner och layout av element. Ett bra exempel på denna typ av dokumentation är Living Style Guides.

UX-krav beskriver å andra sidan vad erfarenheten ska vara för specifik användare, med tanke på att den här användaren är i ett visst scenario utför en specifik åtgärd. En användarberättelse kan få ett UX-krav på ett mycket kortfattat sätt. Till exempel:

• Som en… förlagets användare,
• Jag vill… kunna granska artiklar innan de publiceras,
• Så att… Jag kan ge feedback och säkerställa kvalitet i tid.

Denna berättelse indikerar först användarens roll, vad den här användaren vill uppnå, och förklarar sedan orsaken bakom den. Det här är bra eftersom det ger insikt till utvecklare och testare av vad det ultimata målet är: att räcka till användarens behov. Observera att orden i fetstil är mallen som används för att skriva berättelsen. Det finns alltid en användare som vill göra något så att de kan uppnå ett visst mål. Du kan följa dessa tips för att skriva bra användarberättelser.

Med denna historia i åtanke kan designteamet besluta att en "godkännande" -åtgärd behövs för att uppnå användarens mål. Sedan för att ge detaljer om hur det här verkligen kommer att fungera kan du använda Gherkin-syntaxen, vilket är ett BBD-verktyg för att skriva företagsläsbara krav. Gherkinsyntax liknar agila användarberättelser eftersom det ger ett sätt att skriva krav som också kan användas som en mall. Fördelen är att du kan komma in i mer specifika, tillhandahålla scenarier och åtgärder som användaren skulle ta utan att komma in på hur genomförandet ska göras. Låt oss ta en titt på det.

Skriva användarhistorier med gherkinsyntax

Grunderna i en historia som använder Gherkinsyntax kan sammanfattas i följande delar:

• En funktion
• Ett scenario
• En förutsättning
• En handling
• Ett resultat

En funktion är en plats för att beskriva det totala affärsvärdet av genomförandet. Det kan också användas för att ge ytterligare information, till exempel affärsregler eller något som gör att funktionen är lättare att förstå (till exempel länkar till prototyper eller användargränssnitt).

Ett scenario beskriver de specifika omständigheter som användaren är i. Från ett användardesignperspektiv tillåter scenarier att kommunicera de olika variablerna för en design och hur användargränssnittet ska hantera dem, enligt användaren.

En förutsättning hjälper till att bygga upp scenariot och tar bort eventuell tvetydighet. I ett scenario som beskriver en första gångs användare som använder en viss skärm, kan förutsättningen förklara att användaren är inloggad.

En handling indikerar exakt vad användaren gör i gränssnittet och är vanligtvis en "trigger", till exempel att klicka på en knapp, skicka in ett formulär eller navigera till ett annat ställe.

Ett resultat är konsekvensen av åtgärden och bör alltid vara något som kan testas.

Med dessa delar i åtanke, låt oss skriva en användarhistoria för den funktion som vi beskrivit tidigare:

• Som en…  förlagets användare,
• Jag vill…  kunna granska artiklar innan de publiceras,
• Så att…  Jag kan ge feedback och säkerställa kvalitet i tid.

Med hjälp av Gherkinsyntax ser den här historien ut så här:

Du kan se hur den inledande historien blir till ett mer detaljerat flöde som användaren kan följa och därför kan det testas. Observera också att orden i fetstil är de sökord som programvara som gurka använder för att automatisera körning av test. Jag kommer att förklara mer om detta senare, men för nu vill jag påpeka att dessa nyckelord också är mycket användbara för att skriva historien eftersom de hjälper skilja de olika delarna av berättelsen.

Något annat att påpeka är att även om berättelsen ger mer information om användarflödet, är gränssnittet inte beskrivet. Anledningen till detta är att beskrivningen av användargränssnittet snabbt kan göra historien till användarkrav, vilket innebär ett stort problem eftersom de kan bli föråldrade ganska snabbt. Om historien exempelvis beskriver hur framgångsvakten ser ut och vad det specifika meddelandet ska säga, kan historien komma ur synkronisering om något av detta ändras, vilket skapar möjligheten att testen misslyckas.

Så tricket är att ge tillräckligt med detaljer, utan att göra jobbet med mer adekvata verktyg, såsom designmockups, prototyper och stilguider. I det avseendet kommer du att märka att åtgärden anger "välja godkännande" vs. bara med "godkännande". "Val av godkännande" är inte specifikt vad gäller den här kontrollen ser ut (det kan vara en knapp, en knapp som ser ut som en länk eller en låda som är klickbar), men det innebär att ett element i användargränssnittet utlöses. Det indikerar också att detta element har skrivits i det "godkänna". Det här är ett grått område där du behöver använda sunt förnuft, eftersom du i vissa fall vill vara så specifik att handlingar kan särskiljas från andra. Till exempel, om det finns ett annat sätt att godkänna en artikel på samma sida, vilket indikerar att i detta scenario måste användaren "välja" den, gör det möjligt att göra differentieringen.

Vikten av scenarier

Förutom den omtänksama syntaxen som Gurkin ger, är en av de saker som jag tycker mest användbar att använda "scenarier" -delen. Scenarier är kraftfulla eftersom de kan användas för att testa konstruktionen och se till att alla baser är täckta.

Vanligtvis börjar design av alla slag med den "glada vägen", vilket betyder vad som händer när allt går bra i gränssnittet och hur det gäller för de flesta användare. I vårt tidigare exempel hade vi:

Eftersom vi vet att artiklar har publiceringsdatum kan vi också ange: Detta är vårt första scenario eftersom artiklar som behöver godkännas i de flesta fall ska vara klara för publicering. Men det här medför frågan: Vad händer när en artikel inte är redo för publicering och utgivaren får tillgång till det? Ska de till och med kunna få tillgång till dessa artiklar?

• Vad skulle hända om en artikel som godkänts har tidigare publiceringsdatum? Ska artikeln publiceras omedelbart, eller ska de gå in i en kö? 
• Och går ett steg längre, om en utgivare godkänner en artikel av misstag? Vad är proceduren för att ångra denna åtgärd? Vem ska bli anmäld?

Alla dessa frågor är en del av designprocessen och sannolikt när du hoppar in i dokumentationskrav du kommer att känna till svaren. Den stora nyheten är att med hjälp av scenarier i din historia dokumentation hjälper dig strukturera dem och i många fall hjälper dig QA egna konstruktioner, se till att det finns en design och flöde avsedda för var och en av dem.

Låt oss se hur vår historia skulle ta form med de extra scenarierna:

Beroende på funktionen kan det finnas många scenarier att överväga. De viktigaste är att hålla dem korta, så att du kan beskriva och testa dem enkelt. Du kan också försöka gruppera dem med gemensamma nämnare. Om till exempel, om några scenarier delar samma förutsättning, kan du inkapslera detta till en "Bakgrund" som kan användas av flera scenarier. Till exempel:

Organisera historier för att kommunicera en funktion

En gemensam utmaning som uppstår vid dokumentation av krav är att bestämma vilken ordning som ska göras. Anledningen är att i de flesta fall allt är under uppbyggnad vilket gör det svårt att testa en interaktion när delarna av interaktionerna ännu inte är byggda. Till exempel, i den enkla interaktionen att "godkänna" en artikel måste många saker vara redo:

1. Användargränssnittet ska kunna returnera ett framgångsrikt meddelande om godkännandet är framgångsrikt och ett felmeddelande om det finns ett systemproblem.
2. Användargränssnittet ska kunna "tagga" artiklar som godkända.
3. UI: n ska kunna visa artikeln enligt "publicerad" affärslogik.
4. Systemanmälan ska vara aktiverad så att författare kan bli varna när godkännandet inträffar.

Ett tillvägagångssätt för att dokumentera krav för var och en av dessa beroenden att registrera dem som olika funktioner som sedan kan prioriteras enligt deras affärsvärde.

Då kan du skapa en "integration" -historia för att få alla dem tillsammans. En användarberättelse för märkningssystemet skulle till exempel gilla detta:

I integrationsberättelsen kan du hänvisa till märkningshistorien, om detaljerna för det scenariot måste verifieras igen eller om du bara vill veta om dessa ärenden redan har verifierats.

Poängen är att undvika att upprepa dokumentation som inte bara förbrukar tid i onödan, utan också det som kan bli synkroniserat.

Att sätta in användarhistorierna i testfall

Vi har sett hur användbara beteendedrivna användarhistorier kan vara för att skriva krav som är fokuserade, koncisa, men också noggranna och beskrivande. Från och med designfasen kan detta verktyg låna en bra primer för QA-ingenjörer för att skriva faktiska testfall.

Förutom dessa stora fördelar kan beteendedrivna användarhistorier faktiskt omvandlas till funktionella tester med hjälp av programvara, som gurka eller sallad. Grundtanken är att när historierna är skrivna med gherkinsyntax kan du placera dem i en .funktion filen inuti din app och kör dem sedan som test för att visa om de lyckades eller inte. För en djupgående handledning om hur man använder salat för en Python-implementering, kolla David Sale's handledning:

Slutsats

Att skriva användarberättelser som använder principerna för BDD kan tjäna för att kommunicera i detalj affärs- och designkrav, med ett användarcentrerat tillvägagångssätt, samtidigt som man använder ett språk som är läsbart men utvidgbart för tolkning av program. Dessutom kan det användas för att testa:

• dina egna mönster som du dokumenterar krav
• den faktiska applikationen manuellt, en gång förvandlas till testfall av en QA-ingenjör
• den aktuella applikationen automatiskt, när den omvandlas till funktionella test med BDD-programvara.

Det betyder att flera lager för att buggar ska gå igenom, förhindra luckor i konstruktionen och ytterligare bulletproofing din applikation från felproblem.