Her er tre ting du kan gjøre:

Splitt opp på domene

Dette er kanskje den vanligste og enkleste måten å splitte opp brukerhistorier på. I domenet ditt vil du gjerne finne flere type kategorier av for eksempel produkter. Disse er ideelle å dele opp historiene dine på. La oss tenke oss et forsikringsselskap som tilbyr en rekke forskjellige forsikringsprodukter. Mye av tiden går til å behandle forsikringssaker og man skal lage et nytt system for å forbedre saksbehandlingstiden.

Eksempel:
Som en saksbehandler
Ønsker jeg å behandle en forsikringssak
Slik at ..

Hva slags type forsikring er dette? Er det en skadeforsikring eller kanskje en livsforsikring? Her kan vi dele brukerhistorien opp på de forskjellige produktkategoriene.

Som en saksbehandler,
Ønsker jeg å behandle en skadeforsikringssak,
Slik at..

Hvis 70% av alle forsikringssaker er skadeforsikring vil jeg anta at denne vil ha en høyere prioritet enn en livsforsikringssak som kanskje gjelder 5% av alle sakene. Dette hjelper deg til å prioritere brukerhistoriene dine bedre.

Splitt opp på operasjon

Mange brukerhistorier handler om å skrive eller lese noe data. Dette kan vi dele opp i fire operasjoner: opprett, oppdater, slett og les.

Som en administrator,
Ønsker jeg å administrere brukere
Slik at jeg har kontroll på hvem som har tilgang til systemet

Etter samtaler med administratoren finner vi ut at han har behov for å opprette, endre og slettte brukere. Og ikke minst vise en brukerprofil som da blir les operasjonen. Du har nå mulighet til å dele opp en brukerhistorien i fire nye brukerhistorier.

Eksempel på å opprette:
Som en administrator,
Ønsker jeg å opprette en ny bruker
Slik at jeg enkelt kan gi nye brukere tilgang

Splitt opp på roller

Når vi diskuterer en brukerhistorie handler den som oftest om flere type brukere. Det kan være alt fra brukere som skal ha begrenset tilgang til brukere som bruker funksjonaliteten mer enn andre. Det kan lønne seg å identifisere hva slags type brukere som skal bruke funksjonaliteten og ut i fra dette bryte opp historien som beskriver hvem disse brukerene er og hva de trenger å kunne gjøre.

Som en kunde,
Ønsker jeg å angi en leveringsadresse,
Slik at …

Du har sikkert mange forskjellig typer kunder. Noen er kanskje innom daglig? Kanskje har du noen gode kunder som du ønsker å gjøre brukeropplevelsen bedre for?

Som en jevnlig kunde,
Ønsker jeg å kunne velge en leveringsadresse fra mine tidligere ordre,
Slik at jeg sparer tid på å fylle ut adressen min hver gang

Konklusjon

Ved å bryte ned historiene så får du noe som er enklere å prioritere innenfor en leveranse. Bryter du ned historiene dine vil du også ha mulighet til å implementere den viktigste funksjonaliteten først og unngå å bruke tid på å implementere funksjonalitet som sjelden blir brukt.

Her var tre eksempler på hvordan du kan bryte ned brukerhistoriene dine. Det er ikke alle brukerhistorier dette vil fungere på, men stort sett de fleste av dem.

Hvilke teknikker bruker du på å bruker historiene dine?

Fokus på “hvorfor”, ikke “hvordan”

Hva forsøker denne testen å uttrykke:

Når en bruker registrerer en betaling med beløp “-1234567890″, så skal brukeren se en feilmelding

Hva med denne:

Når en bruker registrerer en betaling med et negativt beløp så skal brukeren få en passende feilmelding

Magiske tall, tekster og verdier i tester skjuler hva vi forsøker å spesifisere. Noen flere eksempler: “når en bruker utelater et eller flere påkrevde felter, så skal brukeren få en feilmelding knyttet til de manglende feltene”, “gitt at brukeren leverer en lottorekke med for få tall”.

Å koble slike tester mot systemet krever mer arbeid, spesielt de første gangene, men testene blir mye klarere etterpå. Og hovedformålet med en akseptansetest er at den er en spesifikasjon som kan diskuteres mellom prosjektet og omverdenen. Og da er det viktig å være klar. Noen ganger vil det virke svært vanskelig å automatisere forståelige spesifikasjoner. Da bør du huske at en god beskrivelse er mer verdifull enn en dårlig test.

Given-when-then

Noe av det første du lærer med tester er “bruk formen ‘gitt X, når Y, så Z’”. Men det er ikke alltid så klart hva X, Y og Z skal være. Tester består av tre typer steg:

• Arrange (oppsett, “given”): Beskriver tilstanden til systemet før testen starter. Typiske eksempler er “gitt at det eksisterer en bruker med utestående betalinger“, “gitt at tjenesten levert fra vår partner har registrert et varenummer” eller kanskje “gitt at det er en fredag” (du får vente til freddan). Avhengig av systemet og tilstanden vi beskriver, kan testen benytte disse stegene på forskjellige måter: Vi kan sette opp brukeren og betalingene i systemet, vi kan se på steget som en forutsetning som vi sjekker om er oppfylt, for eksempel ved å gjøre et søk mot tjenesten fra vår partner, vi kan forutsette, eller endog håpe at det er oppfylt og vi kan la steget kun være dokumentasjon, slik at når testen feiler, så vet vi noen ting vi kan verifisere manuelt, eller det kan være en ren løgn. Kanskje systemet er satt opp på en spesiell måte slik at det ikke er avhengig av ukedagen. Men vi har lyst til å dokumentere hvordan det hadde sett ut om det hadde vært “på ordentlig.”
• Act (utfør, “when”): Beskriver stimuli inn fra omverden. “Når brukeren registrerer en ny betaling,” “når klientsystemet sender en betalingsforespørsel med manglende kundeinformasjon”. Disse kan implementeres på flere måter i de fleste systemer: Et test av et web-grensesnitt kan simulere en klient med for eksempel webdriver, den kan gjøre et http-kall og direkte, eller testen kan bruke klassene som implementerer tjenesten direkte. For funksjonelle tester foretrekker jeg nesten alltid det siste. Det gjør at testene vil kjøre hundre ganger raskere, og vil som regel innebære mindre jobb. Husk: Det er ikke nødvendig å teste brukergrensesnittet på nytt for hver valideringsregel eller spesialtilfelle i applikasjonen din.
• Assert (sjekk, “then”): Beskriver hvordan systemet skal reagere på stimuli og hva tilstanden til systemet skal være etterpå. For eksempel “så skal brukeren få en feilmelding om at alle betalinger må være utført før en ny betaling kan registreres”, “så skal den nye betalingen ikke lagres i systemet.”

Veien fra testscript til spesifikasjoner

Når prosjekter først tar i bruk FitNesse er det veldig vanlig å se tester som ser cirka slik ut:

• Putt inn en kjempeliste med rader med en bråte kolonner inn i tabell A.
• Putt inn en ny kjempelist med rader etc i tabell B
• Send inn et kjempemessig XML dokument
• Sjekk at svaret matcher et nytt XML dokument

Dette er ikke en spesifikasjon – det er et testscript. Og det er ikke slike tester som gir verdi til et prosjekt. Men det er et sted å starte, for det krever ikke så veldig mye kreativitet. Og vi kan gjenbruke lærdommen fra slike tester. Men før det blir en hel skog av tester som dytter XML-dokumenter hit og dit, kan det være lurt å løfte testene opp på et mer logisk nivå:

• Gitt at det ikke eksisterer noen betalingsforespørsler
• Og en bruker er registrert
• Når brukeren sender inn en betalingsforespørsel med ett gitt problem
• Så skal brukeren få feilmeldingen en gitt feilmelding

I FitNesse-terminologi kan en slik test implementeres som en ColumnFixture. Det vil si: Hvert par av “problem” og “feilmelding” er en rad i en tabell. Slik kan vi uttrykke mange regler ved systemet klart og konsist.

Dersom du har startet å gå veien med testscript, er det ikke vanskelig å snu: For hver rad i den nye spesifikasjonen din skal du utføre alt det testscriptet ditt gjorde.

Jeg vil bruke jobben med akseptansetester til ikke bare å gjøre automatiske kjøringer av systemet mitt, men til å spesifisere og diskutere de egentlige kravene brukerne mine bryr seg om. Og dersom jeg må velge mellom tester som lar seg automatisere og spesifikasjoner som beskriver kravet, vil jeg alltid velge det siste.