logo

Netmaking

22 71 95 97

Yngve Høiseth

Hvordan beskrive funksjonalitet i webløsninger?

Se for deg at du har et ønske om å forbedre noe i webløsningen din. Hvordan bør du gå frem for å oppnå målet ditt?

Med mindre du designer og utvikler webløsningen helt på egen hånd er du nødt til å formidle hva du ønsker. En god egenskapsbeskrivelse er essensielt for å komme raskt i mål.

Hva kjennetegner så en god egenskapsbeskrivelse?

  1. Den er lett å forstå for de som skal lese den.
  2. Den beskriver intensjonen slik at folk med ulike roller kan bidra med forslag til løsning.
  3. Den er utvetydig for å unngå misforståelser.

Å lage en god egenskapsbeskrivelse er lettere sagt enn gjort, men følger du disse tre stegene kommer du langt:

  1. Brukerhistorie
  2. Scenarier
  3. Standardisert, maskinlesbart format

Nivå 1: Brukerhistorie

Det første nivået er en brukerhistorie. Hvis du bare skal gjøre én ting, skriv en brukerhistorie.

En typisk brukerhistorie beskriver hvem, hva og hvorfor. Se for deg at du driver en nettbutikk. Du har merket deg at for kunder som ikke er logget inn tar utsjekkingsprosessen lang tid, og mange faller fra underveis. Dette gjelder særlig for kunder som bruker mobil.

Etter å ha lagt produkter i handlevognen må en ikke-innlogget kunde i dag oppgi følgende informasjon:

  1. Navn
  2. Telefonnummer
  3. Adresse
  4. E-postadresse
  5. Betalingsinformasjon

Dette er mange tastetrykk, noe som er særlig problematisk på mobil. Kan vi gjøre prosessen enklere?

Du tar opp problemet med en av utviklerne som foredler nettbutikken. Som løsning foreslår utvikleren å automatisk hente navn og adresse fra telefonkatalogen. Dere kommer sammen frem til følgende brukerhistorie:

Som ikke-innlogget kunde i ferd med å fullføre et kjøp ønsker jeg at navn og adresse fylles ut automatisk slik at jeg sparer tid.

Denne brukerhistorien inneholder følgende deler:

  1. Hvem: Ikke-innlogget kunde
  2. Hva: Automatisk utfylling av navn og adresse i utsjekkingsprosessen
  3. Hvorfor: Spare tid
Når, hvor, hva, hvem, hvordan, hvorfor.

Nivå 2: Scenarier

Det andre nivået er å sette opp ulike scenarier, eller eksempler om du vil. Dette reduserer tvetydigheten i beskrivelsen. I dette tilfellet må vi ta høyde for at telefonnummeret ikke finnes i telefonkatalogen. Vi har da to scenarier:

  1. Telefonnummeret finnes i telefonkatalogen. Navn og adresse fylles ut automatisk, og kunden får mulighet til å endre informasjonen om ønskelig.
  2. Telefonnummeret finnes ikke i telefonkatalogen. Kunden må taste inn informasjonen manuelt.

Med kombinasjonen av brukerhistorie og scenarier har vi nå et godt utgangspunkt for å sette i gang med utviklingen. Men vi kan sikte høyere – egenskapen kan beskrives i et standardisert format.

Nivå 3: Standardisert, maskinlesbart format

Det tredje (mer avanserte) nivået er altså å lage egenskapsbeskrivelsen i et standardisert, maskinlesbart format. Dette er ikke strengt nødvendig, men kan gi noen fordeler:

  1. Vi slipper å finne opp hjulet på nytt, og får utbytte av erfaringene som er gjort ved utviklingen av det standardiserte formatet.
  2. Det standardiserte formatet kan legge til rette for automatisk testing, noe som gjør webløsningen mer robust på sikt.
  3. Når egenskaper beskrives standardisert blir det lettere å vedlikeholde en levende spesifikasjon.

Gherkin

Vi benytter formatet Gherkin. Gherkin-beskrivelsen består av noen standardiserte elementer.

Den første er tittelen/egenskapen, deretter har vi brukerhistorien. 

Egenskap: Automatisk utfylling av navn og adresse basert på telefonnummer

 Som ikke-innlogget kunde i ferd med å fullføre et kjøp ønsker jeg at navn og adresse fylles ut automatisk slik at jeg sparer tid.

Deretter har vi ulike steg. Hvert steg ligger på sin egen linje og begynner med et av ordene Gitt, Når, eller Og. Stegene er gruppert i scenarier.

Steg som er felles for alle scenariene kan vi legge i bakgrunnen slik at vi slipper å gjenta oss selv. Automatiseringen av tester baserer seg på stegene.

 Bakgrunn:

   Gitt at jeg har satt i gang utsjekkingsprosessen

   Og at jeg har tastet inn telefonnummeret mitt

 Scenario: Telefonnummeret finnes i telefonkatalogen

   Gitt at telefonnummeret finnes i telefonkatalogen

   Så fylles mitt navn og adresse ut automatisk

   Og jeg får mulighet til å korrigere navn og adresse

 Scenario: Telefonnummeret finnes ikke i telefonkatalogen

   Gitt at telefonnummeret ikke finnes i telefonkatalogen

   Så fylles ikke navn og adresse ut automatisk

   Og jeg må fylle ut navn og adresse

Kompromiss

Synes du at Gherkin-beskrivelsen er litt «stiv»? Det er du ikke alene om. Ettersom deler av egenskapsbeskrivelsen skal forstås av et program bærer Gherkin preg av å være et kompromiss mellom menneske og maskin.

I tillegg kan vi ikke legge skjermbilder mellom linjene. Det gjør egenskapsbeskrivelser skrevet i Gherkin mindre anvendelige til dokumentasjon enn de kunne ha vært.

Når det er sagt så vil fordelene med Gherkin veie opp for ulempene i mange tilfeller.

Konklusjon

Ved å følge denne oppskriften for egenskapsbeskrivelser legger du til rette for rask og effektiv måloppnåelse. Husk at du ikke må gjennom alle stegene for at det skal tilføre verdi – begynn med å beskrive intensjonen din, så kan vi ta resten etter hvert.

Yngve Høiseth

Yngve Høiseth

Yngve har vært innom både befalsskole og bank før han landet hos oss. I tillegg til webutvikling er Yngve opptatt av hvordan ting kan gjøres bedre, på alle mulige måter, noe som er bra for både oss og våre kunder. Yngve har også en ullgenser.