Meny

Hur testarna är involverade i TDD-, BDD- och ATDD-tekniker

how testers are involved tdd

Prova Vårt Instrument För Att Eliminera Problem

Översikt över TDD, BDD och ATDD tekniker:

TDD, BDD & ATDD är de termer som har revolutionerat testarens värld i Agile och också fått fart. Förändring av testares tankesätt kräver också att lära sig nya färdigheter och ännu viktigare, att ändra attityd och sätt att arbeta.

Till skillnad från att arbeta isolerat, måste testare samarbeta och arbeta tillsammans med programmerarna vilket betyder

  • Dela testfall
  • Delta i att skriva berättelsernas acceptanskriterier
  • Ge kontinuerlig feedback till intressenterna
  • Samarbetar för att lösa bristerna i tid.
  • Ge förslag och input för att förbättra kvaliteten på leveranserna
  • Automatisering

Testare involverade i smidig

Innan jag hoppar in i diskussionen om en testares engagemang i dessa metoder, ska vi först försöka förstå begreppen bakom dessa termer:

Vad du kommer att lära dig:

Testdriven utveckling

Tänk på det traditionella tillvägagångssättet för mjukvaruutveckling där koden skrivs först och sedan testas. Testdriven utveckling eller TDD är ett tillvägagångssätt som är den exakta BAKGRUNDEN för traditionell utveckling. I detta tillvägagångssätt görs testningen först och sedan skrivs koden.

Förvirrad?!!

Hur kan vi testa en mjukvara som ännu inte har utvecklats?

Ja!! Det är testdriven utveckling eller TDD.

TDD fungerar i små steg där:

  • Testet skrivs först
  • Testet utförs - vilket kommer att misslyckas (av uppenbara skäl)
  • Koden är skriven (eller ombyggd) bara för att testfallet ska klara
  • Testet utförs igen
  • Om testet passerar, gå vidare till nästa test ELSE skriv om / modifiera koden för att göra testet godkänt

Låt mig försöka förklara det genom ett flödesschema:

TDD flödesschema

Nu måste vi förstå det faktum att TDD inte pratar om de test som testare gör. Snarare detta tillvägagångssätt talar faktiskt om de test som programmerarna gör.

Ja!! Du gissade rätt !! Det är enhetstestningen.

Testet som skrivs först är inte testet som testarna skriver, utan det är enhetstestet som programmerarna skriver. Så jag skulle omformulera stegen som:

  • UNIT-testet skrivs först
  • UNIT-testet utförs - vilket kommer att misslyckas (av uppenbara skäl)
  • Koden är skriven (eller ombyggd) bara för att testet ska klara
  • UNIT-testet utförs igen
  • Om testet passerar, gå vidare till nästa test ELSE skriv om / ändra koden för att göra testet godkänt

Nu är frågan som uppstår här - om TDD är en programmerares jobb, vilken är testarens roll i detta tillvägagångssätt?

Med tanke på att TDD är ett programmeringsjobb betyder det inte att testarna inte är inblandade i det. Testare kan samarbeta genom att dela testscenarierna som består av:

Vad jag menar att säga är att testare bör delta i att definiera enhetens testscenarier och samarbeta med programmerarna för att implementera detsamma. Testare bör ge sin feedback om testresultaten.

Om vi ​​vill implementera TDD måste testare uppgradera sina kunskapsuppsättningar. De måste vara mer tekniska och fokusera på att förbättra sina analytiska och logiska färdigheter.

Testare bör också anstränga sig för att förstå den tekniska jargongen som programmerarna använder och om möjligt måste ha en fågelperspektiv på koden. På liknande sätt måste programmerarna gå in i testarens skor och försöka komma med mer sofistikerade scenarier som gör enhetstestningen mer robust och solid.

Både programmerare och testare måste kliva in i varandra, till skillnad från det gamla traditionella tillvägagångssättet där programmerarna inte gav mycket vikt åt enhetstesterna eftersom de litade på testarna för att hitta buggar och defekter, och testarna ville inte skämma bort sig själva att lära sig de tekniska sakerna eftersom de tror att deras jobb slutar efter att ha upptäckt bristerna.

Beteendedriven utveckling

Behavior Driven Development eller BDD är en förlängning av Test Driven Development.

BDD, som namnet antyder, illustrerar metoderna för att utveckla en funktion baserat på dess beteende. Uppförandet förklaras i princip i termer av exempel på ett mycket enkelt språk som kan förstås av alla i teamet som är ansvariga för utvecklingen.

Några av de viktigaste funktionerna i BDD är följande:

  • Språket som används för att definiera beteendet är mycket enkelt och i ett enda format där det kan förstås av alla - både tekniska och icke-tekniska personer som är involverade i implementeringen
  • Ger en plattform som gör det möjligt för de tre amigorna (programmerare, testare och PO / BA) att samarbeta och förstå kravet. Bestämmer en gemensam mall för att dokumentera den
  • Denna teknik / metod diskuterar systemets slutliga beteende eller hur systemet ska bete sig och det talar INTE om hur systemet ska utformas eller implementeras
  • Betonar båda aspekterna av kvalitet:
    • Uppfyll kravet
    • Passar för användning

Varför BDD?

Vi vet att fixa en defekt / insekt i det senare skedet av varje utvecklingscykel är det ganska kostsamt. Åtgärdande av produktionsfel påverkar inte bara koden utan också designen och dess krav. När vi gör RCA (Root Cause Analysis) av alla defekter, för det mesta, drar vi slutsatsen att defekten faktiskt beror på missförstått krav.

Detta händer i grunden för att alla har olika förmåga att förstå kraven. Följaktligen kan tekniska och icke-tekniska personer tolka samma krav olika, vilket kan leda till en felaktig leverans. Därför är det viktigt att alla i utvecklingsteamet förstår samma krav och tolkar det på samma sätt.

Vi måste se till att hela utvecklingsinsatsen riktas och fokuseras mot att uppfylla kraven. För att undvika någon form av ”krav - miss” -fel måste hela utvecklingsteamet anpassa dem för att förstå kravet som är lämpligt att använda.

BDD-metod tillåter utvecklingsgruppen att göra det genom att: -

  • Definiera en standardmetod för att definiera kravet på enkel engelska
  • Tillhandahållande av att definiera exempel som förklarar kraven
  • Ge ett gränssnitt / plattform som gör det möjligt för de tekniska (programmerare / testare) och icke-tekniska (PO / BA / kunden) att samarbeta och samlas och vara på samma sida för att förstå och genomföra kraven

Hur implementerar man BDD?

Det finns många verktyg på marknaden för att implementera BDD. Jag nämner några här:

  • Gurka
  • Kondition
  • Concordion
  • JBehave
  • Specflöde

Exempel:

Låt oss försöka förstå BDD med ett exempel. För mitt fall använder jag Gherkin (Gurka):

Tänk på ett enkelt fall där vi endast tillåter autentiserade användare att komma in på XYZ-webbplatsen.

Gherkin-filen (funktionsfil) skulle vara som följer:

Funktion: Testregistreringsportal

Scenarioöversikt: Giltig användare inloggad

Given: Kunden öppnar registreringsportalen

När: användaren anger användarnamnet som '' & lösenord som ''

Sedan: kunden ska kunna se formuläret.

Exempel :

| användare | lösenord |

| användare1 | pwd1 |

| användare2 | pwd2 |

Vi kan se hur ett visst krav dokumenteras med enkel engelska. De tre amigos kan arbeta tillsammans för att designa funktionsfilerna och specifika testdata kan dokumenteras i exempelavsnittet. BDD tillhandahåller ett medium för att föra programmerare, testare och affärer till ett bord och skapa en gemensam förståelse för de funktioner som ska implementeras.

BDD-tillvägagångssätt sparar ansträngning och kostnader och kontrollerar om det finns några fel efter produktionsdistributionen eftersom samarbetet mellan kunder och utvecklare var under hela utvecklingscykeln för funktionen.

Utvecklingsteam kan använda dessa funktionsfiler och konvertera dem till körbara program för att testa en viss funktion.

Hur?

Du måste lära dig gurka / fitness för det !!

Acceptance Test Driven Development

Acceptance Test Driven Development eller ATDD är en teknik där hela teamet samarbetar för att definiera acceptanskriterierna för en episk / berättelse innan implementeringen faktiskt börjar. Dessa acceptantest stöds av korrekta exempel och annan nödvändig information.

För det mesta används BDD och ATDD omväxlande. ATDD-tillvägagångssättet kan också implementeras med formatet Given-When-Then, precis som hur vi skriver funktioner i BDD-metoden.

Låt oss snabbt försöka sammanfatta skillnaderna mellan de tre metoderna:

  • TDD är mer teknisk och är skriven på samma språk som funktionen implementeras. Om funktionen är implementerad i Java skriver vi JUnit testfall . BDD & ATDD är skrivet på ett enkelt engelska språk
  • TDD-metoden fokuserar på implementeringen av en funktion. Medan BDD fokuserar på funktionens beteende, och ATDD fokuserar på att fånga kraven
  • För att implementera TDD måste vi ha teknisk kunskap. BDD & ATDD kräver ingen teknisk kunskap. Skönheten i BDD / ATDD ligger i detta faktum att både tekniska och icke-tekniska personer kan delta i utvecklingen av funktionen
  • Eftersom TDD utvecklas ger det utrymme för bra design och fokuserar på aspekten ”Meeting Requirement” av kvalitet; medan BDD / ATDD fokuserar på 2ndaspekt av kvalitet som är 'Fit for use'

Alla dessa tekniker talar i princip om 'test-First' -metoden, till skillnad från 'test-last' -metoden som används i traditionella utvecklingsmetoder.

När testerna skrivs först spelar testare en mycket viktig roll. Inte bara behöver testare ha en enorm domän- och affärskunskap, utan de måste också ha goda tekniska färdigheter så att de kan tillföra värde i brainstorming under de 3 amigos-diskussionerna.

Med begreppen CI (Continuous Integration) och CD (Continuous Delivery) måste testare samarbeta bra med programmerarna och bidra lika till utvecklings- och operationsområdet.

c ++ datum och tid

Låt mig sammanfatta denna diskussion med den berömda Testpyramiden i Agile:

Testpyramiden i smidig

Det lägsta lagret i denna pyramid består av enhetstestskiktet. Detta lager är grundlagret; Därför är det viktigt att detta lager är solid. De flesta testerna ska tryckas in i detta lager. Detta lägsta lager fokuserar bara på TDD.

I Vig världen läggs en tonvikt på att göra detta lager av pyramiden mer stark och robust och det betonas att det mesta av testningen uppnås vid detta lager.

Verktyg som används i detta lager av en pyramid är alla Xunit-verktyg.

Pyramidens mittlager är servicelager, vilket förklarar servicenivåtesterna. Detta lager fungerar som en brygga mellan applikationsanvändargränssnittet och enhet / komponent på lägre nivå. Detta lager består främst av API: er som accepterar förfrågningar från användargränssnittet och skickar tillbaka svaret. BDD- och TTDD-metoden är aktiv i detta lager av pyramiden.

Verktyg som används i pyramidens mittlager är - Fitnesse, Gurka och Robot Framework .

Pyramidens översta lager är det faktiska användargränssnittet, vilket visar att detta lager bör innehålla minst antal tester, eller jag borde säga, testansträngningen vid detta specifika lager bör vara minimal. Det mesta av testningen av funktionen borde ha slutförts när vi når pyramidens övre lager.

Verktyg som används i det översta lagret är - Selen , QTP och RFT.

Eftersom vi arbetar i små steg i Klunga (kallas Sprints) är manuell implementering av alla dessa tillvägagångssätt inte genomförbar. Dessa tillvägagångssätt kräver automatiskt ingripande. I detta fall är automatisering mycket kritisk.

I själva verket utförs dessa tillvägagångssätt faktiskt genom automatisering. I slutet av varje sprint läggs nya funktioner till, så det blir viktigt att den tidigare implementerade funktionen fungerar som förväntat; därmed, Automatisering blir HELTEN här.

Slutsats

I slutet av artikeln måste du ha lärt dig om hur testarna är involverade i TDD-, BDD- och ATDD-tekniker.

I den tredje delen av serien kommer jag att fokusera min diskussion om automatisering i en smidig värld.

Om författaren: Denna artikel är av STH-författaren Shilpa. Hon arbetar inom programvarutestningsområdet de senaste 10+ åren inom domäner som Internetannonsering, Investment Banking och Telecom.

Fortsätt titta på detta utrymme för mycket fler uppdateringar.

Rekommenderad läsning

^