Meniu

Cum sunt implicați testerii în tehnicile TDD, BDD și ATDD

how testers are involved tdd

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Prezentare generală a tehnicilor TDD, BDD și ATDD:

TDD, BDD și ATDD sunt termenii care au revoluționat lumea testerului în Agile și au căpătat și elan. Schimbarea mentalității testerilor necesită, de asemenea, învățarea unor noi abilități și, mai important, schimbarea atitudinii și a modului de lucru.

Spre deosebire de lucrul izolat, testerii trebuie să colaboreze și să lucreze împreună cu programatorii, ceea ce înseamnă

  • Partajarea cazurilor de testare
  • Participarea la scrierea criteriilor de acceptare a poveștilor
  • Furnizarea de feedback continuu părților interesate
  • Colaborând pentru a rezolva defectele la timp.
  • Oferiți sugestii și informații pentru îmbunătățirea calității livrabilelor
  • Automatizare

Testeri implicați în Agile

Înainte de a intra în discuția despre implicarea unui tester în aceste practici, să încercăm mai întâi să înțelegem conceptele din spatele acestor termeni:

Ce veți învăța:

Test Driven Development

Luați în considerare abordarea tradițională a dezvoltării software în care codul este scris mai întâi și apoi testat. Dezvoltarea bazată pe test sau TDD este o abordare care este REVERSUL exact al dezvoltării tradiționale. În această abordare, testarea se face mai întâi și apoi se scrie codul.

Confuz?!!

Cum putem testa un software care încă nu a fost dezvoltat?

Da!! Aceasta este dezvoltarea testată sau TDD.

TDD funcționează în trepte mici în care:

  • Testul este scris mai întâi
  • Testul este executat - ceea ce va eșua (din motive evidente)
  • Codul este scris (sau refactorizat) tocmai pentru a face testul să treacă
  • Testul este executat din nou
  • Dacă testul trece, treceți la următorul test ELSE rescrieți / modificați codul pentru a trece testul

Permiteți-mi să încerc să o explic printr-un diagramă:

Diagrama de flux TDD

Acum, trebuie să înțelegem faptul că TDD nu vorbește despre testarea pe care o fac testerii. Mai degrabă această abordare vorbește de fapt despre testarea pe care o fac programatorii.

Da!! Ai ghicit bine !! Este testarea unitară.

Testul care este scris mai întâi nu este testul pe care testatorii îl scriu, ci este testul de unitate pe care îl scriu programatorii. Așadar, aș reformula pașii astfel:

  • Testul UNIT este scris mai întâi
  • Testul UNIT este executat - care va eșua (din motive evidente)
  • Codul este scris (sau refactorizat) doar pentru a trece testul
  • Testul UNIT este executat din nou
  • Dacă testul trece, treceți la următorul test ELSE rescrieți / modificați codul pentru a trece testul

Acum, întrebarea care se pune aici este - dacă TDD este treaba unui programator, care este rolul testerului în această abordare?

Ei bine, după ce am spus că TDD este treaba unui programator, nu înseamnă că testerii nu sunt implicați în aceasta. Testerii pot colabora împărtășind scenariile de testare constând din:

Ceea ce vreau să spun este că testerii ar trebui să participe la definirea scenariilor de testare unitară și să colaboreze cu programatorii pentru a le implementa. Testatorii ar trebui să ofere feedback-ul lor cu privire la rezultatele testului.

Dacă dorim să implementăm TDD, testerii trebuie să-și actualizeze seturile de abilități. Ei trebuie să fie mai tehnici și să se concentreze pe îmbunătățirea abilităților lor analitice și logice.

Testatorii ar trebui, de asemenea, să depună eforturi pentru a înțelege jargonul tehnic pe care îl folosesc programatorii și, dacă este posibil, trebuie să aibă o vedere a codului. În mod similar, programatorii trebuie să meargă în locul testerului și să încerce să vină cu scenarii mai sofisticate care vor face unitatea de testare mai robustă și solidă.

Atât programatorii, cât și testerii trebuie să pătrundă în pantofi, spre deosebire de vechea abordare tradițională, în care programatorii nu acordau prea multă greutate testelor unitare, deoarece se bazau pe testeri pentru a găsi erori și defecte, iar testerii nu doreau să se răsfețe. să învețe lucrurile tehnice, deoarece ei cred că slujba lor se termină după găsirea defectelor.

Dezvoltarea condusă de comportament

Dezvoltarea condusă de comportament sau BDD este o extensie a dezvoltării conduse de testare.

BDD, așa cum sugerează și numele, ilustrează metodele de dezvoltare a unei caracteristici pe baza comportamentului acesteia. Comportamentul este practic explicat în termeni de exemple într-un limbaj foarte simplu, care poate fi înțeles de toată lumea din echipă care este responsabilă de dezvoltare.

Unele dintre caracteristicile cheie ale BDD sunt următoarele:

  • Limbajul folosit pentru a defini comportamentul este foarte simplu și într-un singur format în care poate fi înțeles de toată lumea - atât persoane tehnice, cât și non-tehnice implicate în implementare
  • Oferă o platformă care permite celor trei prieteni (programator, tester și PO / BA) să colaboreze și să înțeleagă cerința. Determină un șablon comun pentru al documenta
  • Această tehnică / abordare discută comportamentul final al sistemului sau cum ar trebui să se comporte sistemul și NU vorbește despre modul în care ar trebui proiectat sau implementat sistemul
  • Accentuează ambele aspecte ale calității:
    • Îndeplinește cerința
    • Potrivit pentru utilizare

De ce BDD?

Ei bine, știm că remedierea unui defect / gândac în etapa ulterioară a oricărui ciclu de dezvoltare este destul de costisitor. Remedierea defectelor de producție nu numai că afectează codul, ci și designul și cerințele acestuia. Când facem RCA (Analiza cauzei radiculare) a oricărui defect, de cele mai multe ori, concluzionăm că defectul se reduce la cerințele înțelese greșit.

Acest lucru se întâmplă practic pentru că toată lumea are aptitudini diferite pentru a înțelege cerințele. Prin urmare, persoanele tehnice și non-tehnice pot interpreta aceeași cerință în mod diferit, ceea ce poate duce la o livrare defectuoasă. Prin urmare, este esențial ca toată lumea din echipa de dezvoltare să înțeleagă ACEASTA cerință și să o interpreteze în același mod.

Trebuie să ne asigurăm că toate eforturile de dezvoltare sunt direcționate și concentrate către îndeplinirea cerințelor. Pentru a evita orice fel de defecțiune „cerință - ratare”, întreaga echipă de dezvoltare trebuie să le alinieze pentru a înțelege cerința potrivită pentru utilizare.

Abordarea BDD permite echipei de dezvoltare să facă acest lucru prin: -

  • Definirea unei abordări standard pentru a defini cerința în limba engleză simplă
  • Furnizarea de exemple definitorii care explică cerințele
  • Furnizați o interfață / platformă care permite tehnicilor (programatori / testeri) și non-tehnici (PO / BA / Client) să colaboreze și să se reunească și să fie pe aceeași pagină pentru a înțelege și a implementa cerințele

Cum se implementează BDD?

Există multe instrumente disponibile pe piață pentru implementarea BDD. Numesc câteva aici:

  • Castravete
  • Fitness
  • Concordion
  • JComportă-te
  • Flux spec

Exemplu:

Să încercăm să înțelegem BDD cu un exemplu. Pentru cazul meu, folosesc pepene verde (Castravete):

Luați în considerare un caz simplu în care dorim să permitem doar utilizatorilor autentificați să intre pe site-ul XYZ.

Fișierul Gherkin (fișier caracteristică) ar fi după cum urmează:

Caracteristică: Portal de înregistrare a testelor

Schița scenariului: Utilizator valid autentificat

Dat: Clientul deschide portalul de înregistrare

Când: utilizatorul introduce numele de utilizator ca „” și parola ca „”

Atunci: clientul ar trebui să poată vizualiza formularul.

Exemple :

| utilizator | parolă |

| utilizator1 | pwd1 |

| user2 | pwd2 |

Putem vedea cum este documentată o anumită cerință folosind limba engleză simplă. Cei trei prieteni pot lucra împreună pentru a proiecta fișierele de caracteristici și datele de test specifice pot fi documentate în secțiunea de exemplu. BDD oferă un mediu pentru a aduce programatori, testeri și companii pe o singură masă și pentru a stabili o înțelegere comună a caracteristicilor care urmează să fie implementate.

Abordarea BDD economisește eforturi și costuri și verifică dacă există defecte după implementarea producției, deoarece colaborarea clienților și dezvoltatorilor a fost pe tot parcursul ciclului de dezvoltare a caracteristicii.

Echipele de dezvoltare pot utiliza aceste fișiere de caracteristici și le pot converti în programe executabile pentru a testa o anumită caracteristică.

Cum?

Ei bine, trebuie să înveți Castravete / Fitnesse pentru asta !!

Dezvoltare determinată de testul de acceptare

Acceptance Test Driven Development sau ATDD este o tehnică în care întreaga echipă colaborează pentru a defini criteriile de acceptare ale unei epopee / povești înainte ca implementarea să înceapă efectiv. Aceste teste de acceptare sunt susținute de exemple adecvate și alte informații necesare.

De cele mai multe ori, BDD și ATDD sunt utilizate în mod interschimbabil. Abordarea ATDD poate fi de asemenea implementată folosind formatul Date-Când-Atunci, la fel ca modul în care scriem caracteristici în abordarea BDD.

Să încercăm rapid să rezumăm diferențele dintre cele 3 abordări:

  • TDD este mai tehnic și este scris în aceeași limbă în care este implementată caracteristica. Dacă caracteristica este implementată în Java, scriem JUnit cazuri de testare . În timp ce BDD și ATDD sunt scrise în limba engleză simplă
  • Abordarea TDD se concentrează pe implementarea unei caracteristici. În timp ce BDD se concentrează pe comportamentul caracteristicii, iar ATDD se concentrează pe captarea cerințelor
  • Pentru a implementa TDD trebuie să avem cunoștințe tehnice. În timp ce BDD și ATDD nu necesită cunoștințe tehnice. Frumusețea BDD / ATDD constă în faptul că atât tehnicii, cât și cei non-tehnici, pot participa la dezvoltarea caracteristicii
  • Deoarece TDD este evoluat, acesta oferă posibilități pentru un design bun și se concentrează pe aspectul „Cerințe de întâlnire” al calității; întrucât BDD / ATDD se concentrează pe 2ndaspect al calității care este „Potrivit pentru utilizare”

Toate aceste tehnici vorbesc practic despre abordarea „test-First”, spre deosebire de abordarea „test-last” folosită în metodologiile tradiționale de dezvoltare.

Deoarece testele sunt scrise mai întâi, testerii joacă un rol foarte important. Nu numai că testerii trebuie să aibă un domeniu vast și cunoștințe de afaceri, dar trebuie să posede și abilități tehnice bune, astfel încât să poată adăuga valoare în brainstorming în timpul discuțiilor de 3 amigos.

Cu concepte precum CI (Integration Continuous) și CD (Continuous Delivery), testerii trebuie să colaboreze bine cu programatorii și să contribuie în mod egal la zona de dezvoltare și operațiuni.

care sunt cele mai bune aplicații de realitate virtuală

Permiteți-mi să rezum această discuție cu celebra Piramidă de testare în Agile:

Testați piramida în Agile

Stratul inferior al acestei piramide este alcătuit din stratul de testare unitar. Acest strat este stratul de fundație; Prin urmare, este imperios ca acest strat să fie solid. Majoritatea testelor trebuie introduse în acest strat. Acest strat inferior se concentrează doar pe TDD.

În Agil în lume, se pune accentul pe a face acest strat al piramidei mai puternic și mai robust și se subliniază că majoritatea testelor se realizează la acest strat.

Instrumentele utilizate în acest strat al unei piramide sunt toate instrumentele Xunit.

Stratul de mijloc al piramidei este stratul de serviciu, explicând testele de nivel de serviciu. Acest strat acționează ca o punte între interfața de utilizare a aplicației și unitatea / componenta de nivel inferior. Acest strat cuprinde în principal API-urile care acceptă cereri din interfața de utilizare și trimit răspunsul înapoi. Abordarea BDD și TTDD este activă în acest strat al piramidei.

Instrumentele utilizate în stratul de mijloc al piramidei sunt - Fitnesse, Castravete și Robot Framework .

Stratul cel mai de sus al piramidei este interfața reală, care arată că acest strat ar trebui să conțină cel mai mic număr de teste sau ar trebui să spun că efortul de testare la acest strat special ar trebui să fie minim. Cea mai mare parte a testării caracteristicii ar fi trebuit finalizată atunci când ajungem la stratul superior al piramidei.

Instrumentele utilizate în stratul superior sunt - Seleniu , QTP și RFT.

De vreme ce lucrăm în mici trepte în Scrum (numit Sprints), implementarea manuală a tuturor acestor abordări nu este fezabilă. Aceste abordări necesită intervenție automatizată. Automatizarea, în acest caz, este foarte critică.

De fapt, aceste abordări sunt de fapt executate prin automatizare. La sfârșitul fiecărui sprint, sunt adăugate noi caracteristici, așa că devine important ca caracteristica implementată anterior să funcționeze conform așteptărilor; prin urmare, Automatizare devine EROUL aici.

Concluzie

Până la sfârșitul articolului, trebuie să fi aflat despre modul în care sunt implicați testerii în tehnicile TDD, BDD și ATDD.

În a treia parte a seriei, îmi voi concentra discuția asupra automatizării într-o lume agilă.

Despre autor: Acest articol este al autorului STH Shilpa. Lucrează în domeniul testării software-ului în ultimii 10 ani în domenii precum publicitatea pe internet, Investment Banking și Telecom.

Urmăriți în continuare acest spațiu pentru mai multe actualizări.

Lectură recomandată

^