Om du är bekant med TDD så är ATDD på något sätt TDD med en högre nivå av testning och med fler intressenter inblandade, med andra ord är det mer av acceptanstestning än enhetstestning. Om du vill veta mer om TDD kan du läsa följande inlägg:
Acceptance test-driven development (ATDD) är en utvecklingsmetodik som bygger på kommunikation mellan företagskunder, utvecklare och testare. ATDD omfattar många av samma metoder som specifikation genom exempel, beteendedriven utveckling (BDD), exempeldriven utveckling (EDD) och stöddriven utveckling även kallad story testdriven utveckling (SDD). Alla dessa processer hjälper utvecklare och testare att förstå kundens behov före genomförandet och gör det möjligt för kunderna att samtala på sitt eget domänspråk.
Tidigare implementerad i agila team är ATDD en metod där affärsanalytiker, utvecklare, testare och användare samarbetar för att definiera acceptanskriterierna för varje story (eller funktion) i ett tidigt skede av utvecklingsprocessen (innan kodningen börjar). Detta tillvägagångssätt gör det möjligt för alla intressenter att ha och upprätthålla samma nivå av förväntade resultat innan någon utvecklare börjar koda.
Jag vet att vi alla har hört stereotypen ”utvecklare bryr sig inte om specifikation och testare vill inte automatisera”, men med ATDD kommer detta att spara mycket slöseri med tid och pengar genom att se till att utvecklarna är mer involverade i de tidiga skedena av specifikationen och att testarna automatiserar acceptanstesterna.
Hur implementeras ATDD i ”det verkliga livet”?
Använder ni SCRUM? Om ja så gör du redan det mesta av arbetet inom ATDD.Om inte så måste följande exempel väcka din nyfikenhet :
Exempel
Vi antar att produktägaren eller kunden har begärt följande funktion i vår mobilapplikation: ”Efter att ha granskat denna begäran med hela teamet (affärsanalytiker, utvecklare, testare…) och med fler detaljer till berättelsen eller funktionen, kommer vi att ha några acceptans- eller funktionella tester som liknar detta (Observera att detta bara är ett exempel, många acceptanstester saknas för denna funktion):
- Acceptanskriterium 1: Programmet accepterar valfritt inloggning/lösenord för inloggning
- Acceptanskriterium 2: Knappen bypass gör det möjligt för användaren att bläddra i programmet utan inloggning.
- Acceptanskriterium 3: När knappen bypass är vald lagrar eller visar programmet inte någon användarspecifik information
- Acceptanskriterium 4: När inloggning/lösenord används måste programmets grafiska gränssnitt anpassas till användarinställningarna.
Fördelar
1- Anpassning mellan kund och säljare: Genom att ha acceptanskriterierna ovan som indatainformation är vi (varje gruppmedlem) nu säkra på att applikationen kommer att bibehålla sin funktion för inloggning/lösenord och att den bara kommer att lägga till en knapp så att användaren kan kringgå inloggningsskärmen.
2- Kvalitet och kostnadseffektivitet: Testerna ovan kan enkelt automatiseras redan innan utvecklarna börjar koda.
3- Time to Market: När testerna väl är implementerade kan utvecklarna validera sina nödvändiga uppgifter innan de meddelar att de är klara.
ATDD kräver inga särskilda verktyg. Det är viktigt att veta att INTE alla acceptanstester måste automatiseras. Automatisering av testerna beror på flera aspekter, t.ex. tekniska utmaningar, tidsfrister och kostnader.
Några rekommenderade verktyg?
ATDD kräver inga särskilda verktyg. Det är viktigt att veta att INTE alla acceptanstester måste automatiseras. Att automatisera dina tester beror på flera aspekter som: tekniska utmaningar, deadline och kostnad.
I det här avsnittet kommer jag att ge dig en översikt över de mest använda automatiseringsverktygen för ATDD:
FitNess: Det fullt integrerade fristående ramverket för wiki- och acceptanstestning
Robot framework: Generiskt ramverk för testautomatisering för acceptanstestning och acceptanstestdriven utveckling (ATDD)
Calabash: Automatiserad acceptanstestning för mobilappar – Observera att detta ramverk kanske inte stöder den senaste OS-versionen (över Android O )