afklaring af interessentens krav er et mål på højt niveau. For at gøre AC ‘ s formål klarere, lad os bryde dem ned.

Funktionsomfang detalisering. AC definerer grænserne for brugerhistorier. De giver præcise detaljer om funktionalitet, der hjælper teamet med at forstå, om historien er afsluttet og fungerer som forventet.

beskriver negative scenarier. Yor AC kan kræve, at systemet genkender usikre adgangskodeindgange og forhindrer en bruger i at fortsætte videre., Ugyldigt adgangskodeformat er et eksempel på et såkaldt negativt scenarie, når en bruger foretager ugyldige input eller opfører sig uventet. AC definerer disse scenarier og forklarer, hvordan systemet skal reagere på dem.

Indstilling af kommunikation. Acceptkriterier synkroniserer visionerne for klienten og udviklingsteamet. De sikrer, at alle har en fælles forståelse af kravene: udviklere ved nøjagtigt, hvilken slags adfærd funktionen skal demonstrere, mens interessenter og klienten forstår, hvad der forventes af funktionen.

strømlining accept test., AC er grundlaget for test af brugerhistoriens accept. Hvert acceptkriterium skal være uafhængigt testbart og således have et klart bestået eller mislykket scenario. De kan også bruges til at verificere historien via automatiserede test.

funktion estimering. Acceptkriterier angiver, hvad der nøjagtigt skal udvikles af teamet. Når teamet har præcise krav, kan de opdele brugerhistorier i opgaver, der kan estimeres korrekt.

acceptkriterier typer og strukturer

AC kan skrives i forskellige formater., Der er to mest almindelige, og den tredje mulighed er at udarbejde din egen format:

  • scenario-orienterede (Da/Da/Da)
  • regel-orienteret (checkliste)
  • brugerdefinerede formater

Som den første og den anden formater har meget specifikke strukturer, vil vi primært fokusere på dem. Du kan dog opleve, at andre formater passer bedre til dit produkt, så vi vil også kort berøre dem.

Scenarieorienterede acceptkriterier

Scenarieorienteret format for at skrive AC er kendt som den givne/hvornår / derefter (G .t) type.,

  • Får nogle forudsætning
  • Hvornår jeg gøre nogle handling
  • Så jeg forventer et resultat

Denne tilgang var arvet fra behavior-driven development (BDD) og giver en ensartet struktur, der hjælper med testere definere, hvornår man skal begynde og ende afprøvning af en bestemt funktion. Det reducerer også den tid, der bruges på at skrive testcases, da systemets opførsel beskrives på forhånd.,

Hver accept kriterier, der er skrevet i dette format har følgende udsagn:

  1. Scenario — navnet for den adfærd, der vil blive beskrevet
  2. i Betragtning — begyndelsen tilstand af scenariet
  3. Hvornår specifikke handlinger, som brugeren gør
  4. Så — resultatet af handling i “Da”
  5. Og — bruges til at fortsætte nogen af de tre foregående redegørelser

Når det kombineres disse udsagn omfatter alle handlinger, som en bruger tager for at fuldføre en opgave, og oplever udfald.

lad os se på nogle eksempler.,eksempel 1

brugerhistorie: som bruger vil jeg være i stand til at gendanne adgangskoden til min konto, så jeg kan få adgang til min konto, hvis jeg har glemt adgangskoden.,igated til login-side

Når: Den valgte bruger glemt adgangskode

Og: Indtastet en gyldig e-mail for at modtage et link til gendannelse af adgangskode

Så: systemet har sendt link til den indtastede e-mail

i Betragtning: brugeren har modtaget linket via e-mail

Når: Brugeren navigeres gennem de link, der er modtaget i e-mail

Så: systemet giver brugeren mulighed for at angive en ny adgangskode

Eksempel 2:

Bruger historie: Som en bruger, jeg ønsker at være i stand til at anmode om penge fra min konto i ATM, så jeg vil være i stand til at modtage penge fra min konto hurtigt og på forskellige steder.,alid

Og: dispenseren indeholder kontanter

Når: kunden anmoder om den kontante

Så: sikre konto debiteres

Og: sikre kontanter er doseret

Og: sørg for at kortet er vendt tilbage

Accept-kriterium 2:

i Betragtning: at kontoen overtrækkes

Og: kortet er gyldigt

Når: kunden anmoder om den kontante

Dernæst: sørg for afvisning meddelelse vises

Og: sikre kontanter er ikke udleveres

Regel-orienteret accept kriterier format

I nogle tilfælde, det er svært at passe accept kriterier, der i Givet/Når/Så-struktur., For eksempel ville g .t næppe være nyttigt i følgende tilfælde:

  • du arbejder med brugerhistorier, der beskriver systemniveaufunktionaliteten, der har brug for andre metoder til kvalitetssikring.
  • målgruppen for acceptkriterier har ikke brug for præcise detaljer om testscenarierne.
  • g .t-scenarier passer ikke til at beskrive design-og brugeroplevelsesbegrænsninger for en funktion. Udviklere kan gå glip af en række kritiske detaljer.

Du kan løse disse sager med det regelorienterede AC-format.,

den regelorienterede form indebærer, at der er et sæt regler, der beskriver et systems adfærd. Baseret på disse regler kan du tegne specifikke scenarier.

normalt ser kriterier, der er sammensat ved hjælp af denne formular, ud som en simpel kugleliste. Lad os se på et eksempel.eksempel

brugerhistorie: som bruger vil jeg bruge et søgefelt til at skrive en by, navn eller gade, så jeg kunne finde matchende hotelindstillinger.,

grundlæggende kriterier for accept af søgegrænsefladen

  • søgefeltet er placeret på øverste bjælke
  • søgning Starter, når brugeren klikker på “Søg”
  • feltet indeholder en pladsholder med en grå tekst: “hvor skal du hen?”
  • Den pladsholder, der forsvinder, når brugeren begynder at skrive
  • Søgning er udført, hvis en bruger typer i en by, hotel navn, en gade eller alle tilsammen
  • Søgningen er i engelsk, fransk, tysk og ukrainsk
  • brugeren kan ikke skrive mere end 200 symboler
  • søg ikke støtte specielle symboler (bogstaver)., Hvis brugeren har indtastet et specielt symbol, skal du vise advarselsmeddelelsen: “Søgeindgang kan ikke indeholde specielle symboler .”

andre formater

de fleste brugerhistorier kan dækkes med to ovennævnte formater. Du kan dog opfinde dine egne acceptkriterier, da de tjener deres formål, er skrevet tydeligt på almindeligt engelsk og ikke kan fortolkes forkert. Nogle hold bruger endda almindelig tekst.

Nogle gange kan dine kriterier angives som et eksempel på systemadfærd: