Menu

Jak se testeři účastní technik TDD, BDD a ATDD

how testers are involved tdd

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

Přehled technik TDD, BDD a ATDD:

TDD, BDD a ATDD jsou výrazy, které způsobily revoluci ve světě testerů v Agile a také nabraly na obrátkách. Změna v myšlení testerů také vyžaduje osvojení nových dovedností a co je důležitější, změna přístupu a způsobu práce.

Na rozdíl od práce v izolaci musí testeři spolupracovat a spolupracovat s programátory, což znamená

  • Sdílení testovacích případů
  • Účast na psaní kritérií přijetí příběhů
  • Poskytování průběžné zpětné vazby zúčastněným stranám
  • Spolupráce na včasném vyřešení vad.
  • Poskytněte návrhy a podněty pro zlepšení kvality výstupů
  • Automatizace

Testeři zapojeni do agility

Než se pustím do diskuse o zapojení testera do těchto postupů, zkusme nejprve porozumět konceptům za těmito pojmy:

Co se naučíte:

Testovaný vývoj

Zvažte tradiční přístup vývoje softwaru, kde je nejprve napsán kód a poté testován. Test-driven development neboli TDD je přístup, který je přesným ZPĚTEM tradičního vývoje. V tomto přístupu se nejprve provede testování a poté se zapíše kód.

Zmatený?!!

Jak můžeme otestovat software, který se teprve vyvíjí?

Ano!! To je testovaný vývoj nebo TDD.

TDD pracuje v malých krocích, kde:

  • Test je napsán jako první
  • Test je proveden - což selže (ze zřejmých důvodů)
  • Kód je napsán (nebo refaktorován), jen aby testovací případ vyhověl
  • Test se provede znovu
  • Pokud test proběhne úspěšně, přejděte k dalšímu testu JINÉ, přepište / upravte kód tak, aby test proběhl úspěšně

Pokusím se to vysvětlit pomocí vývojového diagramu:

Vývojový diagram TDD

Nyní musíme pochopit skutečnost, že TDD nemluví o testování, které provádějí testeři. Tento přístup spíše hovoří o testování, které provádějí programátoři.

Ano!! Uhádli jste správně !! Je to testování jednotky.

Test, který je napsán jako první, není testem, který píší testeři, ale programátorem je test jednotky. Kroky bych tedy přeformuloval takto:

  • Nejprve se napíše test UNIT
  • Je proveden test JEDNOTKY - který selže (ze zřejmých důvodů)
  • Kód je napsán (nebo refaktorován) pouze proto, aby proběhl úspěšně
  • Test JEDNOTKY se provede znovu
  • Pokud test proběhne úspěšně, přejděte k dalšímu testu JINÉ, přepište / upravte kód tak, aby test proběhl úspěšně

Nyní zde vyvstává otázka - pokud je TDD úlohou programátora, jaká je role testera v tomto přístupu?

Když už jsme řekli, že TDD je programátorská práce, neznamená to, že se do ní testeři nezapojují. Testeři mohou spolupracovat sdílením testovacích scénářů skládajících se z:

Chci tím říci, že - testeři by se měli podílet na definování scénářů testování jednotky a spolupracovat s programátory na implementaci stejných. Testeři by měli poskytnout zpětnou vazbu k výsledkům testu.

Pokud chceme implementovat TDD, musí testeři upgradovat své sady dovedností. Musí být techničtější a soustředit se na zdokonalování svých analytických a logických dovedností.

Testeři by se měli také snažit porozumět technickému žargonu, který programátoři používají, a pokud je to možné, musí mít na kód pohled z ptačí perspektivy. Podobným způsobem musí programátoři vstoupit do obuvi testeru a pokusit se přijít s propracovanějšími scénáři, díky nimž bude testování jednotky robustnější a pevnější.

Programátoři i testeři si musí do sebe vkročit, na rozdíl od starého tradičního přístupu, kdy programátoři nepřikládali jednotkovým testům velkou váhu, protože spoléhali na testery při hledání chyb a defektů a testeři se nechtěli dopřát naučit se technické věci, protože si myslí, že jejich práce končí po zjištění závad.

Vývoj založený na chování

Behavior Driven Development nebo BDD je rozšíření pro Test Driven Development.

BDD, jak název napovídá, ilustruje metody vývoje funkce založené na jejím chování. Chování je v zásadě vysvětleno pomocí příkladů ve velmi jednoduchém jazyce, kterému rozumí každý v týmu zodpovědný za vývoj.

Některé z klíčových funkcí BDD jsou následující:

  • Jazyk používaný k definování chování je velmi jednoduchý a v jediném formátu, ve kterém mu rozumí každý - technický i netechnický člověk zapojený do implementace
  • Poskytuje platformu, která umožňuje třem amigům (programátor, tester a PO / BA) spolupracovat a porozumět požadavku. Určuje společnou šablonu, která ji dokumentuje
  • Tato technika / přístup pojednává o konečném chování systému nebo o tom, jak by se měl systém chovat, a NEMluví o tom, jak by měl být systém navržen nebo implementován
  • Zdůrazňuje oba aspekty kvality:
    • Splňte požadavek
    • Vhodné pro použití

Proč BDD?

Víme, že oprava vady / Chyba v pozdější fázi jakéhokoli vývojového cyklu je poměrně nákladná. Oprava výrobních vad má dopad nejen na kód, ale také na design a jeho požadavky. Když uděláme RCA (Root Cause Analysis) jakékoli vady, většinou dospějeme k závěru, že vada se skutečně scvrkává na nepochopené požadavky.

K tomu v zásadě dochází, protože každý má jiné schopnosti porozumět požadavkům. Proto mohou techničtí i netechničtí lidé interpretovat stejný požadavek odlišně, což může vést k chybné dodávce. Proto je zásadní, aby všichni ve vývojovém týmu pochopili STEJNÝ požadavek a interpretovali jej STEJNĚ.

Musíme zajistit, aby celé vývojové úsilí směřovalo a bylo zaměřeno na splnění požadavků. Aby se předešlo jakémukoli defektu „požadavek - chybět“, musí je celý vývojový tým sladit, aby porozuměli požadavku, který je vhodný k použití.

Přístup BDD umožňuje vývojovému týmu tak učinit: -

  • Definování standardního přístupu k definování požadavku v jednoduché angličtině
  • Poskytnutí definujících příkladů, které vysvětlují požadavky
  • Poskytněte rozhraní / platformu, která umožňuje technickým (programátoři / testeři) a netechnickým (PO / BA / zákazník) spolupracovat a setkávat se a být na stejné stránce, aby pochopili a implementovali požadavky

Jak implementovat BDD?

Na trhu existuje mnoho nástrojů pro implementaci BDD. Zde jmenuji několik:

  • Okurka
  • Zdatnost
  • Harmonika
  • JBehave
  • Spec Flow

Příklad:

Zkusme pochopit BDD na příkladu. V mém případě používám okurku (okurku):

Zvažte jednoduchý případ, kdy chceme umožnit vstup na web XYZ pouze ověřeným uživatelům.

Soubor Gherkin (soubor funkcí) by byl následující:

Vlastnosti: Otestujte registrační portál

Osnova scénáře: Platný uživatel přihlášen

Dané: Zákazník otevře registrační portál

Když: uživatel zadá uživatelské jméno jako „“ a heslo jako „“

Pak: zákazník by měl mít možnost formulář zobrazit.

Příklady :

| uživatel | heslo |

| uživatel1 | pwd1 |

| user2 | pwd2 |

Můžeme vidět, jak je konkrétní požadavek dokumentován pomocí jednoduché angličtiny. Tři amigové mohou společně navrhnout soubory funkcí a konkrétní testovací data lze dokumentovat v sekci příkladů. BDD poskytuje médium, které přivede programátory, testery a obchod k jednomu stolu a vytvoří společné porozumění funkcím, které mají být implementovány.

Přístup BDD šetří úsilí a náklady a kontroluje, zda po nasazení výroby nenastaly nějaké vady, protože spolupráce zákazníků a vývojářů probíhala během vývojového cyklu této funkce.

Vývojové týmy mohou tyto soubory funkcí využít a převést je na spustitelné programy k otestování konkrétní funkce.

Jak?

Za to se musíte naučit Cucumber / Fitnesse !!

Vývoj řízený akceptačním testem

Acceptance Test Driven Development nebo ATDD je technika, při které celý tým spolupracuje na definování kritérií přijatelnosti epického příběhu před zahájením implementace. Tyto akceptační testy jsou podporovány správnými příklady a dalšími nezbytnými informacemi.

Většinu času se BDD a ATDD používají zaměnitelně. Přístup ATDD lze také implementovat pomocí formátu Given-When-Then, stejně jako při psaní funkcí v přístupu BDD.

Zkusme rychle shrnout rozdíly mezi 3 přístupy:

  • TDD je více technický a je napsán ve stejném jazyce, ve kterém je funkce implementována. Pokud je funkce implementována v Javě, napíšeme JUnit testovací případy . Zatímco BDD & ATDD jsou psány v jednoduchém anglickém jazyce
  • Přístup TDD se zaměřuje na implementaci funkce. Zatímco BDD se zaměřuje na chování funkce a ATDD se zaměřuje na zachycení požadavků
  • K implementaci TDD potřebujeme mít technické znalosti. Zatímco BDD a ATDD nevyžadují žádné technické znalosti. Krása BDD / ATDD spočívá v tom, že se na vývoji funkce mohou podílet jak techničtí, tak netechničtí lidé.
  • Protože se TDD vyvíjí, dává prostor pro dobrý design a zaměřuje se na aspekt kvality „Splnění požadavku“; zatímco BDD / ATDD se zaměřuje na 2ndaspekt kvality, který je „vhodný k použití“

Všechny tyto techniky v zásadě hovoří o přístupu „test-první“, na rozdíl od přístupu „test-poslední“, který se používá v tradičních vývojových metodikách.

Protože jsou testy psány jako první, hrají testeři velmi důležitou roli. Nejen, že testeři musí mít rozsáhlou doménu a obchodní znalosti, ale také musí mít dobré technické dovednosti, aby mohli během debat o 3 amigosech přidat hodnotu při brainstormingu.

S koncepty jako CI (Continuous Integration) a CD (Continuous Delivery) musí testeři dobře spolupracovat s programátory a rovnoměrně přispívat do oblasti vývoje a provozu.

Dotazy na rozhovor s kódováním v C ++

Dovolte mi shrnout tuto diskusi se slavnou Test Pyramid in Agile:

Vyzkoušejte agilně pyramidu

Nejnižší vrstva této pyramidy je tvořena jednotkovou testovací vrstvou. Tato vrstva je základní vrstvou; proto je imperiální, že tato vrstva je pevná. Většina testů by měla být vložena do této vrstvy. Tato nejnižší vrstva se zaměřuje pouze na TDD.

V Agilní ve světě je kladen důraz na to, aby tato vrstva pyramidy byla silnější a robustnější a je zdůrazněno, že většiny testů je dosaženo v této vrstvě.

Nástroje použité v této vrstvě pyramidy jsou všechny nástroje Xunit.

Střední vrstva pyramidy je servisní vrstva, která vysvětluje testy na servisní úrovni. Tato vrstva funguje jako most mezi uživatelským rozhraním aplikace a jednotkou / komponentou nižší úrovně. Tato vrstva se většinou skládá z rozhraní API, která přijímají požadavky z uživatelského rozhraní a odesílají zpět odpovědi. V této vrstvě pyramidy je aktivní přístup BDD a TTDD.

Nástroje použité ve střední vrstvě pyramidy jsou - Fitnesse, Cucumber a Robot Framework .

Nejvyšší vrstva pyramidy je skutečné uživatelské rozhraní, které ukazuje, že tato vrstva by měla obsahovat nejmenší počet testů, nebo bych měl říci, že testovací úsilí v této konkrétní vrstvě by mělo být minimální. Většina testování této funkce měla být dokončena, když dosáhneme horní vrstvy pyramidy.

Nástroje použité v horní vrstvě jsou - Selen , QTP a RFT.

Protože pracujeme v malých krocích v Skrumáž (tzv. Sprinty), ruční implementace všech těchto přístupů není proveditelná. Tyto přístupy vyžadují automatizovaný zásah. Automatizace je v tomto případě velmi kritická.

Ve skutečnosti jsou tyto přístupy skutečně prováděny pomocí automatizace. Na konci každého sprintu se přidávají nové funkce, takže je důležité, aby dříve implementovaná funkce fungovala podle očekávání; proto, Automatizace zde se stává HERO.

Závěr

Na konci článku jste se museli dozvědět, jak se testeři podílejí na technikách TDD, BDD a ATDD.

Ve třetí části seriálu se zaměřím na automatizaci v agilním světě.

O autorovi: Tento článek je autorem STH Shilpa. Posledních 10 let pracuje v oblasti testování softwaru v doménách, jako je internetová reklama, investiční bankovnictví a telekomunikace.

Sledujte tento prostor a získejte mnohem více aktualizací.

Doporučené čtení

^