Introduksjon til Acceptance Test Driven Development (ATDD)

Oppgaver (User Stories) i smidige prosjekter er ofte uklare og/eller mangelfulle.

Dette fører potensielt til utvikling av løsninger som ikke tilfredsstiller produkteiers krav. Slike scenarioer ser vi gang på gang i utviklingsprosjekter og er noe som ofte fører til forhøyede kostnader, forsinkelser og frustrasjon.

Som kvalitetssikrere er vi ute etter å fange opp denne type potensielle feil så tidlig som mulig i utviklingsprosessen – før selve utviklingen tar til. Endringer etter at utviklingen er ferdig er mye mer kostbare enn endringer av formuleringer i en User Story.

Når en ny oppgave introduseres for et team som benytter akseptanse-testdrevet utvikling (ATDD) samles de involverte til en analyse av oppgaven før man går i gang med selve utviklingen.

I dette analysemøtet er minimum følgende roller tilstede:

–       Utvikler

–       Tester/testleder

–       Produkteier

Intensjonen med analysen er å utarbeide et sett med akseptansekriterier som representerer produkteiers krav til løsningen. En effektiv måte å utarbeide disse kriteriene på er å konkretisere oppgaven gjennom et sett av eksempler – i tillegg til å stille en rekke granskende spørsmål til selve formuleringen av oppgaven.

Som tester i et slikt møte er vi opptatt av spørsmålet: hvordan kan vi teste dette? Svaret på dette spørsmålet er ofte behjelpelig for å skape bedre forståelse og klarhet av oppgaven.

Når eksemplene og akseptansekriteriene er klarlagte utarbeider testeren samsvarende akseptansetester samtidig med at selve utviklingen starter.

Disse akseptansetestene fungerer som mål utviklerne jobber mot – når testene er ”grønne” kan man være ganske trygge på at man har utviklet det produkteier ønsker.

Hvis mulig bør akseptansekriteriene automatiseres og føyes til en regresjonssuite av akseptansetester som til enhver tid verifiserer at det som utvikles samsvarer med produkteiers krav. Testene bør versjoneres på lik linje med kildekoden og bør vedlikeholdes slik at akspetansekrav og tester alltid samsvarer.

Suiten av akseptansetester fungerer ikke bare som mål for godkjent utvikling, men også som ”levende” dokumentasjon for hele produktet – man kan få veldig god forståelse av hva produktet skal gjøre bare ved å se på disse testene.

Denne prosessen skaper felles forståelse for – og forventning om – hva som skal leveres i tillegg til at man får etablert en kravsbundet test-suite som validerer koden opp mot kriteriene satt av produkteier.

ATDD er ofte beskrevet som ”the missing link” mellom produkteier og utvikler.
Ved å sette fokuset på produkteiers akseptansekriterier og styre utviklingen etter disse gjennom akseptansetester skaper man en helhetlig utvilklingsprosess fra krav til leveranse.

Facebooktwittergoogle_pluslinkedinmailFacebooktwittergoogle_pluslinkedinmailby feather