Menu

Ako sa testeri podieľajú na technikách TDD, BDD a ATDD

how testers are involved tdd

Vyskúšajte Náš Nástroj Na Odstránenie Problémov

Prehľad techník TDD, BDD a ATDD:

TDD, BDD a ATDD sú výrazy, ktoré spôsobili revolúciu vo svete testerov v systéme Agile a tiež nabrali na obrátkach. Zmena myslenia testerov vyžaduje tiež osvojenie si nových zručností a čo je dôležitejšie, zmena prístupu a spôsobu práce.

Na rozdiel od izolovanej práce musia testeri spolupracovať a spolupracovať s programátormi, čo znamená

  • Zdieľanie testovacích prípadov
  • Účasť na písaní kritérií prijatia príbehov
  • Poskytovanie nepretržitej spätnej väzby zainteresovaným stranám
  • Spolupráca na včasnom vyriešení chýb.
  • Poskytnite návrhy a vstupy na zlepšenie kvality výstupov
  • Automatizácia

Testéri zapojení do agility

Predtým, ako sa pustím do diskusie o zapojení testera do týchto postupov, pokúsme sa najskôr porozumieť konceptom týchto pojmov:

Čo sa dozviete:

Testovaný vývoj

Zvážte tradičný prístup vývoja softvéru, pri ktorom sa najskôr napíše kód a potom sa otestuje. Test-driven development alebo TDD je prístup, ktorý je presnou REVERZOU tradičného vývoja. V tomto prístupe sa najskôr vykoná testovanie a až potom sa napíše kód.

Zmätený? !!

Ako môžeme otestovať softvér, ktorý sa ešte len vyvíja?

Áno!! To je testovaný vývoj alebo TDD.

TDD pracuje v malých krokoch, kde:

  • Test je napísaný ako prvý
  • Test je vykonaný - ktorý však zo zrejmých dôvodov zlyhá.
  • Kód je napísaný (alebo preformátovaný) len preto, aby bol testovací prípad úspešný
  • Test sa vykoná znova
  • Ak test vyhovuje, prejdite na ďalší test ELSE, znovu napíšte / upravte kód tak, aby bol test úspešný

Pokúsim sa to vysvetliť pomocou vývojového diagramu:

Vývojový diagram TDD

Teraz musíme pochopiť skutočnosť, že TDD nehovorí o testovaní, ktoré robia testeri. Tento prístup skôr hovorí o testovaní, ktoré programátori robia.

Áno!! Uhádli ste správne !! Je to testovanie jednotky.

Test, ktorý sa napíše ako prvý, nie je testom, ktorý píšu testeri, ale je to test jednotky, ktorý píšu programátori. Kroky by som teda preformuloval takto:

  • Najprv sa píše test UNIT
  • Vykoná sa test UNIT - ktorý zo zrejmých dôvodov zlyhá.
  • Kód je napísaný (alebo preformulovaný) len na vykonanie testu
  • Test UNIT sa vykoná znova
  • Ak test vyhovuje, prejdite na ďalší test ELSE, znovu napíšte / upravte kód tak, aby bol test úspešný

Teraz tu vyvstáva otázka - ak je TDD úlohou programátora, aká je úloha testera v tomto prístupe?

Keď už sme povedali, že TDD je práca programátora, neznamená to, že sa do nej nezapájajú testeri. Testéri môžu spolupracovať zdieľaním testovacích scenárov pozostávajúcich z:

Čo tým chcem povedať je - testeri by sa mali podieľať na definovaní scenárov testovania jednotiek a spolupracovať s programátormi na ich implementácii. Testéri by mali poskytnúť spätnú väzbu k výsledkom testu.

Ak chceme implementovať TDD, testéri musia vylepšiť svoje sady zručností. Musia byť technickejší a zamerať sa na zdokonalenie svojich analytických a logických schopností.

Testéri by sa tiež mali usilovať porozumieť technickému žargónu, ktorý programátori používajú, a pokiaľ je to možné, musia mať na kód vtáčej perspektívy. Podobným spôsobom musia programátori vkročiť do testovacej obuvi a pokúsiť sa prísť s prepracovanejšími scenármi, vďaka ktorým bude testovanie jednotky robustnejšie a pevnejšie.

Programátori aj testeri si musia do seba šliapať, na rozdiel od starého tradičného prístupu, keď programátori neprikladali jednotným testom veľkú váhu, pretože sa spoliehali na testerov, ktorí zisťujú chyby a chyby, a testeri si nechceli dopriať. aby sa naučili technické veci, pretože si myslia, že ich práca končí po zistení chýb.

Vývoj založený na správaní

Behavior Driven Development alebo BDD je rozšírením k Test Driven Development.

BDD, ako už názov napovedá, ilustruje metódy vývoja vlastnosti na základe jej správania. Chovanie je v zásade vysvetlené na príkladoch veľmi jednoduchým jazykom, ktorému rozumie každý v tíme zodpovedný za vývoj.

Niektoré z kľúčových funkcií BDD sú:

  • Jazyk použitý na definovanie správania je veľmi jednoduchý a v jednom formáte, v ktorom mu rozumie každý - technický aj netechnický pracovník zapojený do implementácie.
  • Poskytuje platformu, ktorá umožňuje trom amigom (programátor, tester a PO / BA) spolupracovať a porozumieť požiadavke. Určuje spoločnú šablónu, ktorá ju dokumentuje
  • Táto technika / prístup pojednáva o konečnom správaní systému alebo o tom, ako by sa mal systém správať, a NEhovorí o tom, ako by mal byť systém navrhnutý alebo implementovaný.
  • Zdôrazňuje obidva aspekty kvality:
    • Splňte požiadavku
    • Vhodné na použitie

Prečo BDD?

No, vieme, že oprava chyby / chyba v neskoršej fáze každého vývojového cyklu je dosť nákladná. Oprava výrobných chýb nemá vplyv iba na kód, ale aj na dizajn a jeho požiadavky. Keď urobíme RCA (analýza hlavných príčin) o akejkoľvek poruche, väčšinou dospejeme k záveru, že chyba sa skutočne scvrkáva na nepochopené požiadavky.

To sa deje v zásade preto, lebo každý má iné schopnosti porozumieť požiadavkám. Z tohto dôvodu môžu technickí a netechničtí ľudia interpretovať rovnakú požiadavku odlišne, čo môže viesť k chybnej dodávke. Preto je kritické, aby všetci vo vývojovom tíme pochopili požiadavku ROVNAKÝ a interpretovali ho ROVNE.

Musíme sa ubezpečiť, že celé vývojové úsilie je zamerané a zamerané na splnenie požiadaviek. Aby sa predišlo akejkoľvek chybe typu „požiadavka - chýbaj“, musí ich celý vývojový tím zosúladiť, aby porozumel požiadavke, ktorá je vhodná na použitie.

Prístup BDD umožňuje vývojovému tímu tak urobiť: -

  • Definovanie štandardného prístupu na definovanie požiadavky v jednoduchej angličtine
  • Poskytnutie definujúcich príkladov, ktoré vysvetľujú požiadavky
  • Poskytnite rozhranie / platformu, ktorá umožňuje technickým (programátori / testéri) a netechnickým (PO / BA / zákazník) spolupráci a stretávaniu sa na jednej stránke, aby pochopili a implementovali požiadavky

Ako implementovať BDD?

Na trhu existuje veľa nástrojov na implementáciu BDD. Tu menujem niekoľko:

  • Uhorka
  • Fitnes
  • Harmonika
  • JBehave
  • Spec Flow

Príklad:

Pokúsme sa pochopiť BDD na príklade. Pre môj prípad používam Gherkin (Uhorka):

Zvážte jednoduchý prípad, keď chceme umožniť vstup na stránku XYZ iba autentifikovaným používateľom.

Súbor Gherkin (súbor funkcií) by bol tento:

Funkcia: Otestujte registračný portál

Osnova scenára: Platný používateľ prihlásený

Dané: Zákazník otvorí registračný portál

Kedy: používateľ zadá používateľské meno ako „“ a heslo ako „“

Potom: zákazník by mal mať možnosť tento formulár zobraziť.

Príklady :

| užívateľ | heslo |

| user1 | pwd1 |

| user2 | pwd2 |

Ako je konkrétna požiadavka dokumentovaná, vidíme pomocou jednoduchej angličtiny. Traja amigovia môžu pri navrhovaní súborov funkcií spolupracovať a konkrétne testovacie údaje je možné dokumentovať v sekcii príkladov. BDD poskytuje médium na privedenie programátorov, testerov a firiem k jednému stolu a na dosiahnutie spoločného porozumenia funkcií, ktoré sa majú implementovať.

Prístup BDD šetrí úsilie a náklady a kontroluje, či po zavedení výroby nie sú nejaké chyby, pretože spolupráca zákazníkov a vývojárov prebiehala počas vývojového cyklu tejto funkcie.

Vývojové tímy môžu tieto súbory funkcií využiť a previesť ich na spustiteľné programy na otestovanie konkrétnej funkcie.

Ako?

No, za to sa musíte naučiť Cucumber / Fitnesse !!

Vývoj riadený kolaudačným testom

Acceptance Test Driven Development alebo ATDD je technika, pri ktorej celý tím spolupracuje na definovaní kritérií prijatia eposu / príbehu pred skutočným začiatkom implementácie. Tieto akceptačné testy sú podporené vhodnými príkladmi a ďalšími potrebnými informáciami.

Väčšinou sa BDD a ATDD používajú zameniteľne. Prístup ATDD je možné implementovať aj pomocou formátu Given-When-Then, rovnako ako píšeme funkcie v prístupe BDD.

Skúsme rýchlo zhrnúť rozdiely medzi týmito 3 prístupmi:

  • TDD je technickejší a je napísaný v rovnakom jazyku, v ktorom je funkcia implementovaná. Ak je funkcia implementovaná v Jave, napíšeme JUnit testovacie prípady . Zatiaľ čo BDD a ATDD sú napísané v jednoduchom anglickom jazyku
  • Prístup TDD sa zameriava na implementáciu funkcie. Zatiaľ čo BDD sa zameriava na správanie sa funkcie a ATDD sa zameriava na zachytenie požiadaviek
  • Na implementáciu TDD musíme mať technické znalosti. Zatiaľ čo BDD a ATDD nevyžadujú žiadne technické znalosti. Krása BDD / ATDD spočíva v tom, že na vývoji tejto funkcie sa môžu podieľať technickí aj netechnickí ľudia.
  • Od vývoja TDD dáva priestor pre dobrý dizajn a zameriava sa na aspekt kvality „Splnenie požiadaviek“; keďže BDD / ATDD sa zameriavajú na 2ndaspekt kvality, ktorý je „Vhodné na použitie“

Všetky tieto techniky v zásade hovoria o prístupe „test-first“, na rozdiel od prístupu „test-last“, ktorý sa používa v tradičných vývojových metodikách.

Pretože testy sú písané ako prvé, testéri hrajú veľmi dôležitú úlohu. Testéri musia mať nielen rozsiahle znalosti a obchodné znalosti, ale aj dobré technické zručnosti, aby mohli počas 3 diskusií o amigose pridať hodnotu do brainstormingu.

S konceptmi ako CI (kontinuálna integrácia) a CD (kontinuálna dodávka) musia testeri dobre spolupracovať s programátormi a rovnako prispievať do oblasti vývoja a prevádzky.

kruhový prepojený zoznam v c ++

Dovoľte mi zhrnúť túto diskusiu so slávnou Testovacou pyramídou v Agile:

Vyskúšajte agilnú pyramídu

Najnižšia vrstva tejto pyramídy je tvorená jednotkovou testovacou vrstvou. Táto vrstva je základnou vrstvou; preto je imperiálne, že táto vrstva je pevná v skale. Väčšina testov by mala byť vložená do tejto vrstvy. Táto najnižšia vrstva sa zameriava iba na TDD.

V Agilný vo svete sa kladie dôraz na to, aby bola táto vrstva pyramídy pevnejšia a robustnejšia, a zdôrazňuje sa, že väčšina testov sa dosahuje práve v tejto vrstve.

Nástroje použité v tejto vrstve pyramídy sú všetky nástroje Xunit.

Stredná vrstva pyramídy je vrstva služieb, ktorá vysvetľuje testy na úrovni služieb. Táto vrstva slúži ako most medzi užívateľským rozhraním aplikácie a jednotkou / komponentom na nižšej úrovni. Táto vrstva sa väčšinou skladá z rozhraní API, ktoré prijímajú požiadavky z používateľského rozhrania a odosiela späť odpovede. Prístup BDD a TTDD je aktívny v tejto vrstve pyramídy.

Nástroje použité v strednej vrstve pyramídy sú - Fitnesse, Cucumber a Robot Framework .

Najvyššia vrstva pyramídy je skutočné používateľské rozhranie, ktoré ukazuje, že táto vrstva by mala obsahovať najmenší počet testov, alebo by som mal povedať, že testovacie úsilie v tejto konkrétnej vrstve by malo byť minimálne. Väčšina testovania objektu mala byť dokončená, keď sa dostaneme k vrchnej vrstve pyramídy.

Nástroje použité v hornej vrstve sú - Selén , QTP a RFT.

Pretože pracujeme v malých prírastkoch v Skrumáž (tzv. Sprinty), je manuálna implementácia všetkých týchto prístupov nemožná. Tieto prístupy si vyžadujú automatizovaný zásah. Automatizácia je v tomto prípade veľmi dôležitá.

Tieto prístupy sa v skutočnosti vykonávajú prostredníctvom automatizácie. Na konci každého šprintu sa pridávajú nové funkcie, takže je dôležité, aby predtým implementovaná funkcia fungovala podľa očakávania; teda Automatizácia sa tu stáva HRDINOM.

Záver

Na konci článku ste sa museli dozvedieť viac o tom, ako sa testéri podieľajú na technikách TDD, BDD a ATDD.

V tretej časti série sa zamerám na automatizáciu v svižnom svete.

O autorovi: Tento článok je autorom STH Shilpa. Posledných 10 rokov pracuje v oblasti testovania softvéru v doménach, ako je internetová reklama, investičné bankovníctvo a telekomunikácie.

Neustále sledujte tento priestor, aby ste získali oveľa viac aktualizácií.

Odporúčané čítanie

^