Meni

Kako su ispitivači uključeni u TDD, BDD i ATDD tehnike

how testers are involved tdd

Isprobajte Naš Instrument Za Uklanjanje Problema

Pregled TDD, BDD i ATDD tehnika:

TDD, BDD i ATDD pojmovi su koji su revolucionirali svijet ispitivača u Agileu, a također su dobili zamah. Promjena u razmišljanju testera također zahtijeva učenje novih vještina i što je još važnije, promjenu stava i načina rada.

Za razliku od izoliranog rada, testeri moraju surađivati ​​i raditi zajedno s programerima, što znači

  • Dijeljenje test slučajeva
  • Sudjelovanje u pisanju kriterija prihvaćanja priča
  • Pružanje kontinuiranih povratnih informacija dionicima
  • Suradnja radi rješavanja nedostataka na vrijeme.
  • Dajte prijedloge i doprinose za poboljšanje kvalitete rezultata
  • Automatizacija

Testeri uključeni u agilnost

Prije nego što uskočim u raspravu o uključenosti testera u ove prakse, prvo pokušajmo razumjeti koncepte koji stoje iza ovih pojmova:

Što ćete naučiti:

Test Driven Development

Razmotrimo tradicionalni pristup razvoju softvera gdje se kod prvo napiše, a zatim testira. Testirani razvoj ili TDD pristup je koji je točna OBRTICA tradicionalnog razvoja. U ovom se pristupu prvo vrši testiranje, a zatim se zapisuje kôd.

Zbunjeni? !!

Kako možemo testirati dio softvera koji tek treba biti razvijen?

Da!! To je testni razvoj ili TDD.

TDD radi u malim koracima gdje:

  • Prvo je napisan test
  • Test se izvršava - koji neće uspjeti (iz očiglednih razloga)
  • Kôd je napisan (ili prepravljen) samo da bi test prošao
  • Test se ponovno izvršava
  • Ako test prođe, prijeđite na sljedeći test ELSE, ponovo napišite / izmijenite kôd da bi test prošao

Dopustite mi da to pokušam objasniti kroz dijagram toka:

TDD dijagram toka

Sada moramo shvatiti činjenicu da TDD ne govori o testiranju koje rade testeri. Umjesto da ovaj pristup zapravo govori o testiranju koje programeri rade.

Da!! Dobro ste pogodili !! To je jedinično testiranje.

Test koji je napisan prvi nije test koji pišu testeri, već je jedinični test koji programeri pišu. Dakle, preformulisao bih korake kao:

  • Prvo je napisan UNIT test
  • Izvršava se UNIT test - koji neće uspjeti (iz očitih razloga)
  • Kôd je napisan (ili prepravljen) samo da bi test prošao
  • Ponovno se izvršava UNIT test
  • Ako test prođe, prijeđite na sljedeći test ELSE, ponovo napišite / izmijenite kôd da bi test prošao

E sad, pitanje koje se ovdje postavlja je - ako je TDD posao programera, koja je uloga ispitivača u ovom pristupu?

Pa, kad smo rekli da je TDD posao programera, to ne znači da ispitivači nisu uključeni u to. Testeri mogu surađivati ​​dijeljenjem testnih scenarija koji se sastoje od:

Ono što želim reći je - testeri bi trebali sudjelovati u definiranju scenarija jediničnog testiranja i surađivati ​​s programerima kako bi primijenili isti. Ispitivači bi trebali pružiti povratne informacije o rezultatima ispitivanja.

Ako želimo implementirati TDD, testeri moraju nadograditi svoje vještine. Moraju biti tehnički više i usredotočiti se na poboljšanje svojih analitičkih i logičkih vještina.

Ispitivači bi se također trebali potruditi razumjeti tehnički žargon koji programeri koriste, a ako je moguće, moraju imati ptičji pogled na kôd. Na sličan način programeri moraju stati na mjesto testera i pokušati smisliti sofisticiranije scenarije koji će jedinstveno testiranje učiniti robusnijim i solidnijim.

I programeri i testeri moraju kročiti jedni drugima, za razliku od starog tradicionalnog pristupa u kojem programeri nisu pridavali veliku težinu jedinstvenim testovima jer su se oslanjali na testere za pronalaženje grešaka i nedostataka, a testeri se nisu htjeli prepustiti u učenje tehničkih stvari jer misle da im posao završava nakon pronalaska nedostataka.

Razvoj vođen ponašanjem

Behaviour Driven Development (BDD) proširenje je za Test Driven Development.

BDD, kao što i samo ime govori, ilustrira metode razvijanja značajke na temelju njezinog ponašanja. Ponašanje se u osnovi objašnjava primjerima na vrlo jednostavnom jeziku koji mogu razumjeti svi u timu koji je odgovoran za razvoj.

Neke od ključnih značajki BDD-a su sljedeće:

  • Jezik koji se koristi za definiranje ponašanja vrlo je jednostavan i u jedinstvenom formatu u kojem ga mogu razumjeti svi - i tehnički i netehnički ljudi uključeni u provedbu
  • Daje platformu koja omogućava trojici prijatelja (programera, ispitivača i PO / BA) da surađuju i razumiju zahtjev. Određuje zajednički predložak za dokumentiranje
  • Ova tehnika / pristup razmatra konačno ponašanje sustava ili kako se sustav treba ponašati, a NE govori o tome kako sustav treba dizajnirati ili implementirati
  • Ističe oba aspekta kvalitete:
    • Ispunite zahtjev
    • Pogodan za upotrebu

Zašto BDD?

Pa, znamo da je otklanjanje kvara / buba u kasnijoj fazi bilo kojeg razvojnog ciklusa prilično je skupo. Otklanjanje proizvodnih nedostataka utječe ne samo na kôd već i na dizajn i njegove zahtjeve. Kad napravimo RCA (analiza uzroka uzroka) bilo kojeg nedostatka, većinu vremena zaključujemo da se nedostatak zapravo svodi na pogrešno shvaćene zahtjeve.

To se u osnovi događa jer svi imaju različite sklonosti za razumijevanje zahtjeva. Stoga tehnički i netehnički ljudi mogu različito tumačiti isti zahtjev, što može dovesti do neispravne isporuke. Stoga je presudno da svi u razvojnom timu razumiju ISTI zahtjev i protumače ga na ISTI način.

Moramo biti sigurni da su cjelokupni razvojni napori usmjereni i usmjereni na ispunjavanje zahtjeva. Da bi se izbjegla bilo kakva greška 'zahtjev - promaši', cijeli ih razvojni tim mora uskladiti kako bi razumio zahtjev koji je prikladan za upotrebu.

BDD pristup omogućava razvojnom timu da to čine: -

  • Definiranje standardnog pristupa za definiranje zahtjeva na jednostavnom engleskom jeziku
  • Pružanje definirajućih primjera koji objašnjavaju zahtjeve
  • Osigurati sučelje / platformu koja tehničkim (programeri / testeri) i netehničkim (PO / BA / kupac) omogućuje suradnju i udruživanje te biti na istoj stranici kako bi razumjeli i primijenili zahtjeve

Kako implementirati BDD?

Na tržištu je dostupno mnogo alata za primjenu BDD-a. Ovdje imenujem nekoliko:

  • Krastavac
  • Fitness
  • Concordion
  • JBehave
  • Spec. Protok

Primjer:

Pokušajmo razumjeti BDD na primjeru. Za svoj slučaj koristim kornišon (krastavac):

Razmotrimo jednostavan slučaj u kojem želimo omogućiti samo ovjerenim korisnicima ulazak na XYZ web mjesto.

Datoteka Gherkin (datoteka značajki) bila bi sljedeća:

Značajka: Portal za registraciju testa

Pregled scenarija: Važeći korisnik prijavljen

Dano: Kupac otvara portal za registraciju

Kada: korisnik unosi korisničko ime kao '', a lozinku kao ''

Zatim: kupac bi trebao moći vidjeti obrazac.

Primjeri :

| korisnik | lozinka |

| korisnik1 | pwd1 |

| korisnik2 | pwd2 |

Možemo vidjeti kako se određeni zahtjev dokumentira jednostavnim engleskim jezikom. Tri amigo-a mogu zajedno raditi na dizajniranju datoteka značajki, a posebni podaci o ispitivanju mogu se dokumentirati u odjeljku primjera. BDD pruža medij za povezivanje programera, testera i poduzeća za jedan stol i uspostavljanje zajedničkog razumijevanja značajki koje se trebaju implementirati.

BDD pristup štedi napor i troškove te provjerava postoje li nedostaci nakon postavljanja proizvodnje jer je suradnja kupaca i programera bila tijekom razvojnog ciklusa značajke.

Razvojni timovi mogu koristiti ove datoteke značajki i pretvoriti ih u izvršne programe za testiranje određene značajke.

Kako?

Pa, za to trebate naučiti krastavac / fitnes !!

Razvoj vođen testom prihvaćanja

Razvoj vođen testom prihvaćanja ili ATDD tehnika je u kojoj cijeli tim surađuje kako bi definirao kriterije prihvaćanja epa / priče prije nego što implementacija zapravo započne. Ovi testovi prihvaćanja podržani su odgovarajućim primjerima i ostalim potrebnim informacijama.

Većinu vremena BDD i ATDD koriste se naizmjenično. Pristup ATDD-u također se može implementirati pomoću formata dato-kad-tada, baš kao i kako pišemo značajke u BDD pristupu.

Pokušajmo brzo sažeti razlike između 3 pristupa:

  • TDD je više tehnički i napisan je na istom jeziku na kojem je značajka implementirana. Ako je značajka implementirana u Javi, pišemo JUnit test slučajevi . Dok su BDD i ATDD napisani na jednostavnom engleskom jeziku
  • TDD pristup usredotočen je na implementaciju značajke. Dok se BDD usredotočuje na ponašanje značajke, a ATDD usredotočuje se na hvatanje zahtjeva
  • Da bismo primijenili TDD, moramo imati tehničko znanje. Dok BDD i ATDD ne zahtijevaju nikakva tehnička znanja. Ljepota BDD / ATDD-a leži u činjenici da i tehnički i netehnički ljudi mogu sudjelovati u razvoju značajke
  • Budući da je TDD razvijen, daje prostor za dobar dizajn i usredotočuje se na aspekt kvalitete „Udovoljavanje zahtjevima“; dok se BDD / ATDD usredotočuju na 2ndaspekt kvalitete koji je 'Prikladan za upotrebu'

Sve ove tehnike u osnovi govore o pristupu 'test-first', za razliku od 'test-last' pristupa koji se koristi u tradicionalnim metodologijama razvoja.

Kako su testovi prvi napisani, testeri igraju vrlo važnu ulogu. Ne samo da testeri moraju imati široko područje i poslovno znanje, već moraju posjedovati dobre tehničke vještine kako bi mogli dodati vrijednost u mozganju tijekom 3 amigos rasprave.

S konceptima poput CI (kontinuirana integracija) i CD (kontinuirana isporuka), testeri moraju dobro surađivati ​​s programerima i podjednako pridonijeti razvoju i operativnom području.

najbolje web stranice za gledanje sinkroniziranih animea

Dopustite mi da rezimiram ovu raspravu poznatom Ispitnom piramidom u agilnom:

Testirajte piramidu u okretnom

Najniži sloj ove piramide sastoji se od sloja jedinice za ispitivanje. Ovaj sloj je temeljni sloj; stoga je imperativ da je ovaj sloj čvrst. Većinu testova treba gurnuti u ovaj sloj. Ovaj najniži sloj fokusira se samo na TDD.

U Okretan svijetu naglasak je stavljen na to da ovaj sloj piramide postane snažniji i robusniji i naglašava se da se većina ispitivanja postiže na ovom sloju.

Alati korišteni u ovom sloju piramide su svi Xunit alati.

Srednji sloj piramide je servisni sloj koji objašnjava testove razine usluge. Ovaj sloj djeluje kao most između korisničkog sučelja aplikacije i jedinice / komponente niže razine. Ovaj se sloj uglavnom sastoji od API-ja koji prihvaćaju zahtjeve iz korisničkog sučelja i vraća odgovor. Pristup BDD i TTDD aktivan je u ovom sloju piramide.

Alati koji se koriste u srednjem sloju piramide su - Fitnesse, Cucumber i Robot Framework .

Najviši sloj piramide je stvarno korisničko sučelje, što pokazuje da bi taj sloj trebao sadržavati najmanji broj testova, ili bih trebao reći da bi napor ispitivanja na ovom određenom sloju trebao biti minimalan. Većina ispitivanja značajke trebala je biti završena kad dođemo do gornjeg sloja piramide.

Alati koji se koriste u gornjem sloju su - Selen , QTP i RFT.

Budući da radimo u malim koracima u Ološ (nazvani Sprints), ručna primjena svih ovih pristupa nije izvediva. Ovi pristupi zahtijevaju automatiziranu intervenciju. U ovom je slučaju automatizacija vrlo bitna.

Zapravo se ti pristupi zapravo provode automatizacijom. Na kraju svakog sprinta dodaju se nove značajke, pa postaje važno da prethodno implementirana značajka radi kako se očekivalo; stoga, Automatizacija ovdje postaje HEROJ.

Zaključak

Na kraju članka morali ste naučiti o tome kako su ispitivači uključeni u TDD, BDD i ATDD tehnike.

U trećem dijelu serije fokusirat ću svoju raspravu na automatizaciju u okretnom svijetu.

O autoru: Ovaj članak napisao je autor STH Shilpa. Posljednjih 10 i više godina radi na polju testiranja softvera na domenama poput internetskog oglašavanja, investicijskog bankarstva i telekoma.

Nastavite gledati ovaj prostor za puno više ažuriranja.

Preporučena literatura

^