Menu

Hvordan testere er involveret i TDD, BDD & ATDD teknikker

how testers are involved tdd

Prøv Vores Instrument Til At Fjerne Problemer

Oversigt over TDD, BDD og ATDD teknikker:

TDD, BDD & ATDD er de termer, der har revolutioneret testernes verden i Agile og også fået fart. Ændring i testers tankegang kræver også at lære nye færdigheder og vigtigere, ændre holdning og måde at arbejde på.

I modsætning til at arbejde isoleret, skal testere samarbejde og arbejde sammen med programmørerne, hvilket betyder

  • Deling af testsagerne
  • Deltagelse i skrivning af acceptkriterierne for historierne
  • At give løbende feedback til interessenterne
  • Samarbejde for at løse manglerne til tiden.
  • Giv forslag og input til forbedring af kvaliteten af ​​leverancerne
  • Automatisering

Testere involveret i smidig

Før jeg springer ind i diskussionen om en testers involvering i denne praksis, skal vi først prøve at forstå begreberne bag disse vilkår:

Hvad du vil lære:

Testdrevet udvikling

Overvej den traditionelle tilgang til softwareudvikling, hvor koden først skrives og derefter testes. Testdrevet udvikling eller TDD er en tilgang, der er den nøjagtige BAGVENDIGE for traditionel udvikling. I denne tilgang udføres test først, og derefter skrives koden.

Forvirret? !!

Hvordan kan vi teste et stykke software, der endnu ikke er udviklet?

Ja!! Det er testdrevet udvikling eller TDD.

TDD fungerer i små trin, hvor:

  • Testen skrives først
  • Testen udføres - hvilket mislykkes (af åbenlyse grunde)
  • Koden er skrevet (eller refaktoriseret) bare for at få testsagen til at bestå
  • Testen udføres igen
  • Hvis testen består, skal du gå videre til den næste test ELSE omskrive / ændre koden for at få testen bestået

Lad mig prøve at forklare det gennem et rutediagram:

TDD-flowdiagram

Nu er vi nødt til at forstå det faktum, at TDD ikke taler om den test, som testere udfører. Snarere taler denne tilgang faktisk om den test, som programmørerne foretager.

Ja!! Du gættede det rigtigt !! Det er enhedstesten.

Den test, der først skrives, er ikke den test, som testerne skriver, men det er den enhedstest, som programmørerne skriver. Så jeg vil omformulere trinnene som:

  • UNIT-testen skrives først
  • UNIT-testen udføres - hvilket vil mislykkes (af åbenlyse grunde)
  • Koden er skrevet (eller refaktoriseret) bare for at få testen til at bestå
  • UNIT-testen udføres igen
  • Hvis testen består, skal du gå videre til næste test ELSE omskrive / ændre koden for at få testen bestået

Nu er spørgsmålet, der opstår her - hvis TDD er programmørjob, hvad er testers rolle i denne tilgang?

Når det er sagt, at TDD er et programmørjob, betyder det ikke, at testerne ikke er involveret i det. Testere kan samarbejde ved at dele testscenarierne bestående af:

  • Grænseværdi sager
  • Ækvivalensklasse test tilfælde
  • Kritiske forretningssager
  • Tilfælde af de fejlbehæftede funktionaliteter
  • Sikring af niveau sager

Hvad jeg mener at sige er - testere skal deltage i at definere enhedstestscenarierne og samarbejde med programmørerne for at implementere det samme. Testere bør give deres feedback om testresultaterne.

Hvis vi ønsker at implementere TDD, skal testere opgradere deres færdigheder. De skal være mere tekniske og fokusere på at forbedre deres analytiske og logiske færdigheder.

Testere bør også gøre en indsats for at forstå det tekniske jargon, som programmørerne bruger, og hvis det er muligt, skal de have et fugleperspektiv af koden. På en lignende måde er programmørerne nødt til at træde ind i testernes sko og forsøge at komme med mere sofistikerede scenarier, der gør enhedstesten mere robust og solid.

Både programmører og testere er nødt til at træde ind i hinanden, i modsætning til den gamle traditionelle tilgang, hvor programmørerne ikke gav meget vægt på enhedstestene, fordi de stolede på testerne for at finde fejl og mangler, og testerne ikke ønskede at forkæle sig selv til at lære de tekniske ting, fordi de tror, ​​at deres job slutter efter at have fundet manglerne.

Adfærdsdrevet udvikling

Behavior Driven Development eller BDD er en udvidelse til Test Driven Development.

BDD, som navnet antyder, illustrerer metoderne til at udvikle en funktion baseret på dens adfærd. Adfærden forklares grundlæggende med eksempler på et meget simpelt sprog, som kan forstås af alle i teamet, der er ansvarlige for udviklingen.

Nogle af nøglefunktionerne i BDD er som følger:

  • Det sprog, der bruges til at definere adfærd, er meget simpelt og i et enkelt format, hvor det kan forstås af alle - både tekniske og ikke-tekniske personer, der er involveret i implementeringen
  • Giver en platform, der gør det muligt for de tre amigoer (programmør, tester og PO / BA) at samarbejde og forstå kravet. Bestemmer en fælles skabelon til dokumentation
  • Denne teknik / tilgang diskuterer systemets endelige opførsel, eller hvordan systemet skal opføre sig, og det taler IKKE om, hvordan systemet skal designes eller implementeres
  • Understreger begge aspekter af kvalitet:
    • Opfyld kravet
    • Velegnet til brug

Hvorfor BDD?

Nå, vi ved, at reparation af en defekt / insekt på det senere tidspunkt i enhver udviklingscyklus er det ganske dyrt. Fastsættelse af produktionsfejl påvirker ikke kun koden, men også designet og dets krav. Når vi gør det RCA (rodårsagsanalyse) af enhver defekt, det meste af tiden, konkluderer vi, at manglen faktisk koger til misforståede krav.

Dette sker grundlæggende, fordi alle har forskellige evner til at forstå kravene. Derfor kan tekniske og ikke-tekniske personer fortolke det samme krav forskelligt, hvilket kan føre til en forkert levering. Derfor er det afgørende, at alle i udviklingsteamet forstår det samme krav og fortolker det på samme måde.

Vi er nødt til at sikre, at hele udviklingsindsatsen er rettet og fokuseret på at opfylde kravene. For at undgå enhver form for en ”krav-miss” -fejl skal hele udviklingsteamet tilpasse dem for at forstå det krav, der er egnet til brug.

BDD-tilgang gør det muligt for udviklingsteamet at: -

  • Definition af en standard tilgang til at definere kravet på enkel engelsk
  • Levering af definerende eksempler, der forklarer kravene
  • Giv en grænseflade / platform, der gør det muligt for de tekniske (programmører / testere) og ikke-tekniske (PO / BA / kunde) at samarbejde og komme sammen og være på samme side for at forstå og implementere kravene

Sådan implementeres BDD?

Der er mange værktøjer til rådighed på markedet til implementering af BDD. Jeg navngiver et par her:

  • Agurk
  • Fitnesse
  • Concordion
  • JBehave
  • Spec Flow

Eksempel:

Lad os prøve at forstå BDD med et eksempel. For min sag bruger jeg agurk (agurk):

Overvej et simpelt tilfælde, hvor vi kun vil tillade godkendte brugere at komme ind på XYZ-webstedet.

Gherkin-filen (funktionsfil) vil være som følger:

Funktion: Testregistreringsportal

Scenariooversigt: Gyldig bruger logget ind

Givet: Kunden åbner registreringsportalen

Hvornår: bruger indtaster brugernavnet som '' & adgangskode som ''

Derefter: kunden skal kunne se formularen.

Eksempler :

| bruger | adgangskode |

| bruger1 | pwd1 |

| bruger2 | pwd2 |

Vi kan se, hvordan et bestemt krav dokumenteres ved hjælp af enkel engelsk. De tre amigoer kan arbejde sammen om at designe funktionsfilerne, og specifikke testdata kan dokumenteres i eksempelsektionen. BDD giver et medium til at bringe programmerere, testere og forretninger til et bord og etablere en fælles forståelse af de funktioner, der skal implementeres.

BDD-tilgang sparer indsats og omkostninger og kontrollerer, om der er defekter efter produktionsimplementeringen, da samarbejdet mellem kunder og udviklere var gennem hele udviklingscyklussen for funktionen.

Udviklingsteam kan bruge disse funktionsfiler og konvertere dem til eksekverbare programmer for at teste en bestemt funktion.

Hvordan?

Nå, du skal lære agurk / fitness til det !!

Acceptanstestdrevet udvikling

Acceptance Test Driven Development eller ATDD er en teknik, hvor hele teamet samarbejder om at definere acceptkriterierne for en episk / historie, før implementeringen faktisk begynder. Disse acceptstest understøttes af korrekte eksempler og anden nødvendig information.

For det meste bruges BDD og ATDD om hinanden. ATDD-metoden kan også implementeres ved hjælp af formatet Give-When-Then, ligesom hvordan vi skriver funktioner i BDD-tilgangen.

Lad os hurtigt prøve at sammenfatte forskellene mellem de 3 tilgange:

  • TDD er mere teknisk og er skrevet på det samme sprog, som funktionen er implementeret. Hvis funktionen er implementeret i Java, skriver vi JUnit test tilfælde . Mens BDD & ATDD er skrevet på et enkelt engelsk sprog
  • TDD-tilgangen fokuserer på implementeringen af ​​en funktion. Mens BDD fokuserer på funktionens opførsel, og ATDD fokuserer på at indfange kravene
  • For at implementere TDD skal vi have teknisk viden. Mens BDD & ATDD ikke kræver teknisk viden. Skønheden ved BDD / ATDD ligger i denne kendsgerning, at både tekniske såvel som ikke-tekniske mennesker kan deltage i udviklingen af ​​funktionen
  • Da TDD udvikles, giver det plads til godt design og fokuserer på ”Mødekrav” -aspektet af kvalitet; mens BDD / ATDD fokuserer på 2ndaspekt af kvalitet, som er 'Fit to use'

Alle disse teknikker taler dybest set om 'test-First' tilgang, i modsætning til 'test-last' tilgang, der anvendes i traditionelle udviklingsmetoder.

Da testene først skrives, spiller testere en meget vigtig rolle. Ikke kun skal testere have et stort domæne og forretningskendskab, men de skal også have gode tekniske færdigheder, så de kan tilføre værdi i brainstorming under de 3 amigos-diskussioner.

Med begreberne CI (Continuous Integration) og CD (Continuous Delivery) skal testere samarbejde godt med programmørerne og bidrage ligeligt til udviklings- og driftsområdet.

gratis app til at planlægge instagramindlæg

Lad mig opsummere denne diskussion med den berømte Testpyramide i Agile:

Test pyramide i smidig

Det laveste lag af denne pyramide består af enhedstestlaget. Dette lag er fundamentlaget; derfor er det vigtigt, at dette lag er bundsolid. De fleste af testene skal skubbes ind i dette lag. Dette laveste lag fokuserer kun på TDD.

I Adræt verden, lægges der vægt på at gøre dette lag af pyramiden mere stærk og robust, og det understreges, at det meste af testen opnås ved dette lag.

Værktøjer, der bruges i dette lag af en pyramide, er alle Xunit-værktøjer.

Det midterste lag i pyramiden er servicelaget, der forklarer serviceniveautestene. Dette lag fungerer som en bro mellem applikationsbrugergrænsefladen og enhed / komponent på lavere niveau. Dette lag består for det meste af API'erne, der accepterer anmodninger fra brugergrænsefladen og sender svaret tilbage. BDD- og TTDD-tilgangen er aktiv i dette lag af pyramiden.

Værktøjer, der bruges i pyramidens midterlag, er - Fitnesse, Agurk og Robot Framework .

Det øverste lag af pyramiden er den faktiske brugergrænseflade, som viser, at dette lag skal indeholde det mindste antal tests, eller jeg skulle sige, testindsatsen ved dette særlige lag skal være minimal. Det meste af testen af ​​funktionen skulle have været afsluttet, når vi når pyramidens øverste lag.

Værktøjer, der bruges i det øverste lag, er - Selen , QTP og RFT.

Da vi arbejder i små trin i Scrum (kaldet Sprints), er manuel implementering af alle disse tilgange ikke mulig. Disse tilgange kræver automatisk indgriben. I dette tilfælde er automatisering meget kritisk.

Faktisk udføres disse tilgange faktisk gennem automatisering. I slutningen af ​​hver sprint tilføjes nye funktioner, så det bliver vigtigt, at den tidligere implementerede funktion fungerer som forventet; derfor Automatisering bliver HELDEN her.

Konklusion

Ved slutningen af ​​artiklen skal du have lært om, hvordan testere er involveret i TDD, BDD & ATDD teknikker.

I den tredje del af serien vil jeg fokusere min diskussion på automatisering i en agil verden.

Om forfatteren: Denne artikel er af STH-forfatter Shilpa. Hun arbejder inden for softwaretestfeltet i de sidste 10+ år inden for domæner som internetannoncering, Investment Banking og Telecom.

Bliv ved med at se dette rum for meget flere opdateringer.

Anbefalet læsning

^