Godkjenningskriterier

Akseptkriterier er de spesifikke betingelsene et arbeid må oppfylle for å bli ansett som fullført. De følger med et krav eller en brukerhistorie, avtales før arbeidet starter, og gir det objektive grunnlaget som resultatet vurderes på. Deres funksjon er å konvertere en generell beskrivelse av intensjon til noe som kan verifiseres snarere enn debatteres.

Fraværet av disse kriteriene skaper et forutsigbart og dyrt mønster. Arbeidet beskrives i generelle termer, bygges opp i henhold til én persons tolkning, og gjennomgås av noen med en annen tolkning, hvoretter uenigheten dukker opp som omarbeiding på det minst passende tidspunktet. Ved å skrive kriteriene først flyttes uenigheten til det punktet hvor det å løse den koster en samtale snarere enn en gjenoppbygging.

To formater dominerer. En enkel sjekkliste angir hver betingelse som må oppfylles, noe som passer til enkle krav og er raskt å skrive. Gitt-når-så-strukturen, hentet fra atferdsdrevet utvikling, angir en startkontekst, en handling og et forventet resultat, som passer til betinget atferd og er direkte knyttet til automatiserte tester. Ingen av delene er iboende overlegne, og konsistens i et team er viktigere enn valget.

De mest verdifulle kriteriene er de som dekker det narrativet utelater. Den lykkelige veien er vanligvis åpenbar og sjelden omstridt; tvistene gjelder valideringsregler, feiltilstander, tomme og ekstreme data, tillatelsesgrenser, hva som skjer når en ekstern tjeneste feiler, og hvordan oppførselen varierer på tvers av enheter. Team som bare skriver kriterier for det forventede tilfellet oppdager resten under testing, som er dit tidsplanen vanligvis går.

Kriterier beskriver resultater snarere enn implementering, noe som bevarer teamets mulighet til å velge en tilnærming. Å si at en bruker må motta bekreftelse innen en definert periode er et kriterium; å angi hvilken køteknologi som skal sende den er en designbeslutning som ikke hører hjemme i en aksepterklæring. Kriterier som spesifiserer implementering begrenser personene som er best posisjonert til å bestemme det, og koder ofte en løsning som viser seg å være unødvendig.

Sporbarhet mellom kriterier og tester er det som hindrer at de to avviker over tid. Der hvert kriterium er knyttet til en verifisering, enten automatisert eller manuell, er dekningen synlig, og en endring i kravet fører til en endring i testen. Der de vedlikeholdes separat, begynner testene gradvis å beskrive hva systemet gjør i stedet for hva det var pålagt å gjøre, noe som fjerner deres evne til å fange opp regresjon mot hensikten.

Ikke-funksjonelle forventninger hører hjemme i kriteriene når de er viktige, og blir vanligvis utelatt. Ytelsesterskler, tilgjengelighetskrav, nettleser- og enhetsstøtte og sikkerhetsbegrensninger er alle betingelser for aksept, og å la dem være implisitte betyr at de blir adressert inkonsekvent eller oppdaget i en senere revisjon. Der et team har en felles definisjon av utført som dekker disse på tvers av alt arbeid, trenger de individuelle kriteriene bare å angi avvik fra den.

Det er å skrive dem i samarbeid som gir fordelen, snarere enn selve dokumentet. Kriterier utarbeidet av én person og overlevert som overføring av en spesifikasjon; kriterier som diskuteres mellom personen som ønsker funksjonaliteten, personen som bygger den og personen som tester den, avdekker uklarheter mens de fortsatt er billige. Diskusjonen endrer ofte kravet, som er poenget.

Fordi kriteriene definerer hva som skal testes, kobler de kravdefinisjonen direkte til kvalitetssikring i stedet for å behandle dem som sekvensielle stadier. I praksis er de skrevet innenfor produktutvikling som en del av forbedringen, med brukervennlighets- og tilgjengelighetsforholdene informert av standardene etablert gjennom UX revisjon arbeid, slik at det som teller som akseptabelt gjenspeiler opplevelsen produktet er ment å gi, snarere enn bare dets funksjonelle oppførsel.