Meny

Hvordan testere er involvert i TDD, BDD og ATDD teknikker

how testers are involved tdd

Prøv Instrumentet Vårt For Å Eliminere Problemer

Oversikt over TDD, BDD og ATDD teknikker:

TDD, BDD og ATDD er begrepene som har revolusjonert testers verden i Agile og også fått fart. Endring i tankesett til testere krever også å lære nye ferdigheter og enda viktigere, endre holdning og måte å jobbe på.

I motsetning til å jobbe isolert, må testere samarbeide og samarbeide med programmererne, det vil si

  • Deling av prøvesakene
  • Delta i å skrive akseptkriteriene til historiene
  • Gi kontinuerlig tilbakemelding til interessentene
  • Samarbeider for å løse feilene i tide.
  • Gi forslag og innspill for å forbedre kvaliteten på resultatene
  • Automasjon

Testere involvert i smidig

Før jeg hopper inn i diskusjonen om en testers involvering i denne fremgangsmåten, la oss først prøve å forstå konseptene bak disse begrepene:

Hva du vil lære:

Testdrevet utvikling

Vurder den tradisjonelle tilnærmingen til programvareutvikling der koden først skrives og deretter testes. Testdrevet utvikling eller TDD er en tilnærming som er den nøyaktige OMVENDINGEN av tradisjonell utvikling. I denne tilnærmingen gjøres testing først, og deretter skrives koden.

Forvirret? !!

Hvordan kan vi teste en programvare som ennå ikke er utviklet?

Ja!! Det er testdrevet utvikling eller TDD.

TDD fungerer i små trinn der:

  • Testen er skrevet først
  • Testen gjennomføres - som vil mislykkes (av åpenbare grunner)
  • Koden er skrevet (eller omarbeidet) bare for å få testsaken bestått
  • Testen utføres igjen
  • Hvis testen består, går du videre til neste test ELSE skriver om / endrer koden for å få testen bestått

La meg prøve å forklare det gjennom et flytskjema:

TDD flytskjema

Nå må vi forstå det faktum at TDD ikke snakker om testingen som testere gjør. Snarere snakker denne tilnærmingen faktisk om testingen som programmererne gjør.

Ja!! Du gjettet det riktig !! Det er enhetstestingen.

Testen som blir skrevet først er ikke testen som testerne skriver, men det er enhetstesten som programmererne skriver. Så jeg vil omformulere trinnene som:

  • UNIT-testen skrives først
  • UNIT-testen utføres - som vil mislykkes (av åpenbare grunner)
  • Koden er skrevet (eller omformet) bare for å få testen bestått
  • UNIT-testen utføres igjen
  • Hvis testen består, går du videre til neste test ELSE skriver om / endrer koden for å få testen bestått

Nå er spørsmålet som oppstår her - hvis TDD er en programmeringsjobb, hva er testers rolle i denne tilnærmingen?

Vel, når det er sagt at TDD er en programmeringsjobb, betyr det ikke at testerne ikke er involvert i det. Testere kan samarbeide ved å dele testscenariene som består av:

  • Grenseverdi saker
  • Ekvivalensklasse test tilfeller
  • Kritiske forretningssaker
  • Tilfeller av feilutsatte funksjoner
  • Sikring av nivåtilfeller

Det jeg mener å si er - testere bør delta i å definere enhetstestscenariene og samarbeide med programmererne for å implementere det samme. Testere bør gi tilbakemelding på testresultatene.

Hvis vi ønsker å implementere TDD, må testere oppgradere ferdighetssettene sine. De må være mer tekniske og fokusere på å forbedre sine analytiske og logiske ferdigheter.

Testere bør også gjøre et forsøk på å forstå den tekniske sjargongen som programmererne bruker, og om mulig, må de ha et fugleperspektiv på koden. På en lignende måte må programmererne gå inn i testerskoene og prøve å komme med mer sofistikerte scenarier som vil gjøre enhetstestingen mer robust og solid.

Både programmerere og testere må gå inn i hverandre, i motsetning til den gamle tradisjonelle tilnærmingen der programmererne ikke ga mye vekt på enhetstestene fordi de stolte på at testerne fant feil og mangler, og testerne ikke ønsket å unne seg til å lære de tekniske tingene fordi de tror jobben deres ender etter å ha funnet manglene.

Atferdsdrevet utvikling

Behavior Driven Development eller BDD er en utvidelse av Test Driven Development.

BDD, som navnet antyder, illustrerer metodene for å utvikle en funksjon basert på oppførselen. Atferden er i utgangspunktet forklart i form av eksempler på et veldig enkelt språk som kan forstås av alle i teamet som er ansvarlige for utviklingen.

Noen av hovedtrekkene i BDD er som følger:

  • Språket som brukes til å definere atferden er veldig enkelt og i et enkelt format der det kan forstås av alle - både tekniske og ikke-tekniske personer som er involvert i implementeringen
  • Gir en plattform som gjør det mulig for de tre amigoen (programmerer, tester og PO / BA) å samarbeide og forstå kravet. Bestemmer en vanlig mal for å dokumentere den
  • Denne teknikken / tilnærmingen diskuterer den endelige oppførselen til systemet eller hvordan systemet skal oppføre seg, og det snakker IKKE om hvordan systemet skal utformes eller implementeres
  • Understreker begge aspektene ved kvalitet:
    • Oppfylle kravet
    • Passer til bruk

Hvorfor BDD?

Vel, vi vet at å fikse en feil / feil på det senere stadiet av en hvilken som helst utviklingssyklus er det ganske kostbart. Å fikse produksjonsfeilene påvirker ikke bare koden, men også designet og kravene. Når vi gjør det RCA (Root Cause Analysis) av enhver feil, mesteparten av tiden, konkluderer vi med at feilen faktisk koker ned til misforståtte krav.

Dette skjer i utgangspunktet fordi alle har forskjellige evner til å forstå kravene. Derfor kan tekniske og ikke-tekniske personer tolke det samme kravet annerledes, noe som kan føre til feil levering. Derfor er det avgjørende at alle i utviklingsteamet forstår Samme krav og tolker det på samme måte.

Vi må sørge for at hele utviklingsarbeidet er rettet og fokusert mot å oppfylle kravene. For å unngå enhver form for 'krav-savn' -feil, må hele utviklingsteamet justere dem for å forstå kravet som er egnet for bruk.

BDD-tilnærming tillater utviklingsteamet å gjøre det ved å: -

  • Definere en standard tilnærming for å definere kravet på enkel engelsk
  • Tilrettelegging for å definere eksempler som forklarer kravene
  • Gi et grensesnitt / plattform som gjør det mulig for tekniske (programmerere / testere) og ikke-tekniske (PO / BA / kunde) å samarbeide og komme sammen og være på samme side for å forstå og implementere kravene

Hvordan implementere BDD?

Det er mange verktøy tilgjengelig i markedet for implementering av BDD. Jeg nevner noen her:

  • Agurk
  • Fitness
  • Concordion
  • JBehave
  • Spesifikk flyt

Eksempel:

La oss prøve å forstå BDD med et eksempel. For mitt tilfelle bruker jeg Gherkin (agurk):

Tenk på et enkelt tilfelle der vi vil la bare autentiserte brukere komme inn på XYZ-nettstedet.

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

Trekk: Testregistreringsportal

Scenariooversikt: Gyldig bruker logget inn

Gitt: Kunden åpner registreringsportalen

Når: bruker angir brukernavnet som '' & passord som ''

Deretter: kunden skal kunne se skjemaet.

Eksempler :

| bruker | passord |

| bruker1 | pwd1 |

| bruker2 | pwd2 |

Vi kan se hvordan et bestemt krav dokumenteres ved hjelp av enkel engelsk. De tre amigoen kan arbeide sammen for å designe funksjonsfilene, og spesifikke testdata kan dokumenteres i eksemplet. BDD gir et medium for å bringe programmerere, testere og virksomheter til ett bord og etablere en felles forståelse av funksjonene som skal implementeres.

BDD-tilnærming sparer krefter og kostnader og sjekker om det er noen feil etter produksjonsdistribusjonen slik samarbeidet mellom kunder og utviklere var gjennom hele utviklingssyklusen til funksjonen.

Utviklingsteam kan bruke disse funksjonsfilene og konvertere dem til kjørbare programmer for å teste en bestemt funksjon.

Hvordan?

Vel, du må lære Agurk / Fitnesse for det !!

Akseptprøvedrevet utvikling

Acceptance Test Driven Development eller ATDD er en teknikk der hele teamet samarbeider om å definere akseptkriteriene til et epos / en historie før implementeringen faktisk begynner. Disse godkjenningstestene støttes av riktige eksempler og annen nødvendig informasjon.

BDD og ATDD brukes mest om hverandre. ATDD-tilnærmingen kan også implementeres ved å gi formatet Given-When-Then, akkurat som hvordan vi skriver funksjoner i BDD-tilnærmingen.

La oss raskt prøve å oppsummere forskjellene mellom de tre tilnærmingene:

  • TDD er mer teknisk og er skrevet på samme språk som funksjonen er implementert i. Hvis funksjonen er implementert i Java, skriver vi JUnit test tilfeller . Mens BDD & ATDD er skrevet på enkelt engelsk språk
  • TDD-tilnærmingen fokuserer på implementering av en funksjon. Mens BDD fokuserer på funksjonen til funksjonen, og ATDD fokuserer på å fange opp kravene
  • For å implementere TDD må vi ha teknisk kunnskap. Mens BDD og ATDD ikke krever teknisk kunnskap. Skjønnheten til BDD / ATDD ligger i dette faktum at både tekniske, så vel som ikke-tekniske personer, kan delta i å utvikle funksjonen
  • Siden TDD utvikles gir det rom for god design og fokuserer på “Meeting Requirement” -aspektet av kvalitet; mens BDD / ATDD fokuserer på 2ndaspekt av kvalitet som er “Fit for use”

Alle disse teknikkene snakker i utgangspunktet om 'test-First' -tilnærmingen, i motsetning til 'test-last' -tilnærmingen som brukes i tradisjonelle utviklingsmetoder.

Når testene skrives først, spiller testere en veldig viktig rolle. Ikke bare trenger testere å ha et enormt domenekunnskap og forretningskunnskap, men de må også ha gode tekniske ferdigheter slik at de kan tilføre verdi i idédugnad under de 3 amigos-diskusjonene.

Med konseptene som CI (Continuous Integration) og CD (Continuous Delivery), må testere samarbeide godt med programmererne og bidra likt til utviklings- og operasjonsområdet.

typer funksjoner c ++

La meg oppsummere denne diskusjonen med den berømte Testpyramiden i smidig:

Test Pyramid in Agile

Det laveste laget av denne pyramiden består av enhetstestlaget. Dette laget er grunnlaget; Derfor er det viktig at dette laget er solid. De fleste testene bør skyves inn i dette laget. Dette laveste laget fokuserer bare på TDD.

I Agile verden, legges det vekt på å gjøre dette laget av pyramiden sterkere og robust, og det understrekes at det meste av testingen oppnås ved dette laget.

Verktøy som brukes i dette laget av en pyramide er alle Xunit-verktøyene.

Det midterste laget av pyramiden er tjenestelaget, og forklarer testnivået på tjenestenivået. Dette laget fungerer som en bro mellom applikasjonsbrukergrensesnittet og enheten / komponenten på lavere nivå. Dette laget består for det meste av APIene som godtar forespørsler fra brukergrensesnittet og sender svaret tilbake. BDD- og TTDD-tilnærmingen er aktiv i dette laget av pyramiden.

Verktøy som brukes i det midterste laget av pyramiden er - Fitnesse, Agurk og Robot Framework .

Det øverste laget av pyramiden er det faktiske brukergrensesnittet, som viser at dette laget skal inneholde minst antall tester, eller jeg burde si, testinnsatsen ved dette laget skal være minimal. Det meste av testingen av funksjonen burde vært fullført når vi når det øverste laget av pyramiden.

Verktøy som brukes i det øverste laget er - Selen , QTP og RFT.

Siden vi jobber i små trinn i Scrum (kalt Sprints), er ikke manuell implementering av alle disse tilnærmingene gjennomførbare. Disse tilnærmingene krever automatisk inngrep. I dette tilfellet er automatisering veldig kritisk.

Faktisk utføres disse tilnærmingene gjennom automatisering. På slutten av hver sprint blir nye funksjoner lagt til, så det blir viktig at den tidligere implementerte funksjonen fungerer som forventet; derav, Automasjon blir HELTEN her.

Konklusjon

Mot slutten av artikkelen må du ha lært om hvordan testere er involvert i TDD, BDD og ATDD teknikker.

I den tredje delen av serien vil jeg fokusere diskusjonen på automatisering i en smidig verden.

Om forfatteren: Denne artikkelen er av STH-forfatter Shilpa. Hun jobber i programvaretestingsfeltet de siste 10+ årene innen domener som Internett-annonsering, Investment Banking og Telecom.

Fortsett å se på denne plassen for mye mer oppdateringer.

Anbefalt lesing

^