Slik dokumenterer du designene dine ved hjelp av atferdsdrevne brukerhistorier

Et vanlig problem når du dokumenterer krav, tar utgangspunkt i systemperspektivet for å beskrive hva som trengs, og glemmer at det er brukeren som vil være midt i samspillet. Brukerhistorier, introdusert av Agile, takler dette problemet ved å gjøre brukeren til sentrum av kravet, og Behavior Driven Development (BDD) tar ting et skritt videre og gir et rammeverk der brukerens oppførsel er det som driver utviklingen.

Ved å bruke BDD-teknikker for å lage brukerhistorier gjør dokumentasjonskrav lettere å skrive og lese. Det gir også flere verktøy for å formidle den tiltenkte brukeropplevelsen av et design, som designere, utviklere og QA-ingeniører kan bruke til å spore og til og med automatisere en del av sitt arbeid. I denne artikkelen vil jeg utforske denne tilnærmingen og vise hvordan du kan bruke den til å dokumentere dine egne design, fra små historier til å organisere disse historiene for å kommunisere fullt funksjonelle funksjoner.

UI Krav vs UX Krav

Det er viktig å skille mellom UI-krav (også kjent som spesifikasjoner) og UX-krav. På den ene siden er UI-krav tekniske dokumenter som inneholder detaljer om brukergrensesnittet, inkludert skrifttyper, farger, dimensjoner og layout av elementer. Et godt eksempel på denne typen dokumentasjon er Living Style Guides.

UX krav, derimot, beskriver hva erfaringen skal være for en spesifikk bruker, gitt at denne brukeren er i et bestemt scenario å gjøre en bestemt handling. En brukerhistorie kan fange et UX-krav på en veldig kort måte. For eksempel:

• Som en… utgiver bruker,
• Jeg vil… kunne gjennomgå artikler før de blir publisert,
• Så det… Jeg kan gi tilbakemelding og sikre kvalitet i tide.

Denne historien indikerer først brukerens rolle, hva denne brukeren ønsker å oppnå, og forklarer årsaken bak den. Dette er bra da det gir innsikt til utviklere og testere av hva det endelige målet er: å tilfredsstille en brukerbehov. Merk at ordene i fet skrift er malen som ble brukt til å skrive historien. Det er alltid en bruker som ønsker å gjøre noe, slik at de kan oppnå et bestemt mål. Du kan følge disse tipsene for å skrive gode brukerhistorier.

Med denne historien i tankene kan designteamet bestemme at en "godkjenning" -handling er nødvendig for å oppnå brukerens mål. Deretter gir du detaljer om hvordan dette egentlig fungerer, kan du bruke Gherkin-syntaks, som er et BBD-verktøy for å skrive forretningsavlesbare krav. Gherkinsyntax ligner på smidige brukerhistorier, da den gir en måte å skrive krav på som også kan brukes som en mal. Fordelen er at du kan komme inn i flere detaljer, gi scenarier og handlinger som brukeren vil ta uten å komme inn på hvordan implementeringen skal gjøres. La oss ta en nærmere titt på det.

Skrive brukerhistorier Bruke Gherkin Syntax

Grunnleggende om en historie ved hjelp av Gherkin Syntax kan oppsummeres i disse delene:

• Et trekk
• Et scenario
• En forutsetning
• Et tiltak
• Et utfall

Et trekk er et sted å beskrive den samlede forretningsmessige verdien av implementeringen. Det kan også brukes til å gi tilleggsinformasjon, for eksempel forretningsregler eller noe som gjør at funksjonen er lettere å forstå (for eksempel koblinger til prototyper eller brukergrensesnittkrav).

Et scenario beskriver de spesifikke omstendighetene som brukeren er i. Fra et brukerdesignsperspektiv tillater scenarier å kommunisere de ulike variablene av et design, og hvordan brukergrensesnittet skal håndtere dem, ifølge brukeren.

En forutsetning hjelper til med å bygge opp scenariet og fjerner enhver tvetydighet. For eksempel, i et scenario som beskriver en første gangs bruker som får tilgang til en bestemt skjerm, kan forutsetningen klargjøre at brukeren er logget inn.

Et tiltak angir nøyaktig hva brukeren gjør i grensesnittet, og er vanligvis en "trigger", for eksempel å klikke på en knapp, sende inn et skjema eller navigere til et annet sted.

Et utfall er konsekvensen av handlingen, og bør alltid være noe som kan testes.

Med disse delene i tankene, la oss skrive en brukerhistorie for funksjonen som vi tidligere beskrev:

• Som en…  utgiver bruker,
• Jeg vil…  kunne gjennomgå artikler før de blir publisert,
• Så det…  Jeg kan gi tilbakemelding og sikre kvalitet i tide.

Bruke Gherkin Syntax denne historien vil se slik ut:

Du kan se hvordan den opprinnelige historien blir til en mer detaljert flyt som brukeren kan følge, og derfor kan den bli testet. Vær også oppmerksom på at ordene i fet skrift er søkeordene som programvare som agurk bruker til å automatisere utførelsen av tester. Jeg vil forklare mer om dette senere, men for nå vil jeg påpeke at disse søkeordene også er svært nyttige for å skrive historien fordi de bidrar til å skille mellom de ulike delene av historien.

Noe annet å påpeke er at selv om historien gir mer informasjon om brukerflyten, er grensesnittet ikke beskrevet. Årsaken til dette er at det å beskrive brukergrensesnittet raskt kan gjøre historien til brukskrav, noe som gir et stort problem da de kan bli utdatert ganske raskt. Hvis for eksempel historien beskriver hvordan suksessvarselet ser ut og hva den spesifikke meldingen skal si, kan historien komme ut av synkronisering hvis noe av dette endres, noe som skaper potensialet for testene som feiler.

Så trikset er å gi nok detalj, uten å gjøre jobben med flere tilstrekkelige verktøy, for eksempel designmockups, prototyper og stilguider. I dette henseende vil du legge merke til at handlingen viser "velg godkjenning" vs. bare ved å bruke "godkjenning". "Velger godkjenning" er ikke spesifikk for hva denne kontrollen ser ut (det kan være en knapp, en knapp som ser ut som en kobling eller en boks som kan klikkes), men det betyr at et element i brukergrensesnittet utløses. Det indikerer også at dette elementet har skrevet i det "godkjenne". Dette er et grått område hvor du må bruke sunn fornuft, da det i noen tilfeller vil du være spesielt slik at handlinger kan skille seg fra andre. For eksempel, hvis det finnes en annen måte å godkjenne en artikkel på samme side, som indikerer at i dette scenariet må brukeren "velge" den, gjør det mulig å gjøre differensieringen.

Betydningen av scenarier

I tillegg til det tankefulle syntaksen som Gherkin gir, er en av de tingene jeg finner mest nyttige å bruke "scenarier" -delen. Scenarier er kraftige fordi de kan brukes til å teste designet og sørge for at alle basene er dekket.

Vanligvis begynner design av noe slag med den "glade banen", noe som betyr hva som skjer når alt går bra i grensesnittet, og hvordan det gjelder for de fleste brukere. I vårt tidligere eksempel hadde vi:

Også fordi vi vet at artikler har publiseringsdatoer, kan vi også si: Dette er vårt første scenario fordi artikler som må godkjennes i de fleste tilfeller skal være klare for publisering. Men dette bringer spørsmålet: Hva skjer når en artikkel ikke er klar for publisering og utgiveren får tilgang til det? Skal de selv få tilgang til disse artiklene?

• Hva ville skje hvis en artikkel som er godkjent, har en publiseringsdato i det siste? Skulle artikkelen bli publisert umiddelbart, eller skal de gå inn i en kø? 
• Og går et skritt videre, hva om en utgiver godkjenner en artikkel ved en feil? Hva er prosedyren for å angre denne handlingen? Hvem skal bli varslet?

Alle disse spørsmålene er en del av designprosessen og mest sannsynlig når du hopper inn i dokumentasjonskrav, vil du vite svarene. Den gode nyheten er at bruk av scenarier i historien din vil hjelpe deg med å strukturere dem, og i mange tilfeller vil du hjelpe deg med å lage dine egne design, og sørge for at det er design og flyt beregnet for hver av dem.

La oss se hvordan historien vår ville ta form med de ekstra scenariene:

Avhengig av funksjonen kan det være mange scenarier å vurdere. De er nøkkelen til å holde dem korte, slik at du enkelt kan beskrive og teste dem. Du kan også prøve å gruppere dem, ved hjelp av fellesbetegnere. For eksempel, hvis noen få scenarier deler samme forutsetning, kan du inkapslere dette til en "Bakgrunn" som kan brukes av flere scenarier. For eksempel:

Organiserende historier for å kommunisere en funksjon

En felles utfordring som oppstår ved dokumentasjon av krav er å bestemme hvilken rekkefølge å gjøre det. Årsaken er at alt i alt er under bygging, noe som gjør det vanskelig å teste samspill når delene av samspillet ikke er bygget ennå. For eksempel, i det enkle samspillet med å "godkjenne" en artikkel, må mange ting være klar:

1. Brukergrensesnittet skal kunne sende en suksessmelding hvis godkjenningen er vellykket og en feilmelding i tilfelle det er et systemproblem.
2. Brukergrensesnittet bør kunne "merke" artikler som godkjent.
3. Brukergrensesnittet skal kunne vise artikkelen i henhold til "publisert" forretningslogikk.
4. Systemvarsler bør aktiveres, slik at forfattere kan bli varslet når godkjenningen skjer.

En tilnærming til å dokumentere krav til hver av disse avhengighetene, å registrere dem som forskjellige funksjoner som deretter kan prioriteres i henhold til deres forretningsverdi.

Deretter kan du lage en "integrasjons" historie for å bringe alle sammen. For eksempel vil en brukerhistorie for merkingssystemet gjerne like dette:

I integrasjonshistorien kan du referere til taggingshistorien, i tilfelle at detaljene for det scenariet må bekreftes på nytt, eller hvis du bare vil vite om disse sakene allerede er bekreftet.

Poenget er å unngå å gjenta dokumentasjon som ikke bare forbruker tid unødvendig, men også det som kan bli synkronisert.

Snu brukerhistorier til testfaser

Vi har sett hvor nyttig atferdsdrevne brukerhistorier kan være for å skrive krav som er fokuserte, konsise, men også grundige og beskrivende. Med utgangspunkt i designfasen kan dette verktøyet låne en god primer for QA-ingeniører for å skrive faktiske testtilfeller.

Foruten disse store fordelene kan Behavioral Driven User Stories faktisk bli omgjort til funksjonelle tester ved hjelp av programvare, som agurk eller salat. Den grunnleggende ideen er at når historiene er skrevet ved hjelp av Gherkin-syntaks, kan du plassere dem i en .trekk filen i appen din, og kjør dem som tester for å vise om de var vellykkede eller ikke. For en grundig veiledning om hvordan du bruker Salat for en Python-implementering, sjekk David Sale's veiledning:

Konklusjon

Skrive brukerhistorier som bruker prinsippene for BDD, kan tjene til å kommunisere i detalj forretnings- og designkrav, med en bruker-sentrisk tilnærming, mens du bruker et språk som er lesbart men utvides for programvarefortolkning. I tillegg kan det brukes til å teste:

• dine egne design som du dokumenterer krav
• den faktiske søknaden manuelt, en gang ble omgjort til test tilfeller av en QA ingeniør
• Den faktiske applikasjonen automatisk, når den ble omgjort til funksjonelle tester ved bruk av BDD-programvare.

Dette betyr at flere lag for bugs skal gå gjennom, hindre hull i design og ytterligere bulletproofing din søknad fra feil feil.