Menu

W jaki sposób testerzy są zaangażowani w techniki TDD, BDD i ATDD

how testers are involved tdd

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Przegląd technik TDD, BDD i ATDD:

TDD, BDD i ATDD to terminy, które zrewolucjonizowały świat testerów w Agile i również nabrały rozpędu. Zmiana nastawienia testerów wymaga również uczenia się nowych umiejętności, a co ważniejsze, zmiany nastawienia i sposobu pracy.

W przeciwieństwie do pracy w izolacji, testerzy muszą współpracować i współpracować z programistami, co oznacza

  • Udostępnianie przypadków testowych
  • Udział w tworzeniu kryteriów akceptacji opowiadań
  • Zapewnianie ciągłej informacji zwrotnej interesariuszom
  • Współpraca w celu terminowego usunięcia usterek.
  • Przedstaw sugestie i informacje dotyczące poprawy jakości rezultatów
  • Automatyzacja

Testerzy zaangażowani w Agile

Zanim przejdę do dyskusji na temat zaangażowania testera w te praktyki, spróbujmy najpierw zrozumieć koncepcje kryjące się za tymi terminami:

Czego się nauczysz:

Rozwój oparty na testach

Rozważ tradycyjne podejście do tworzenia oprogramowania, w którym kod jest najpierw zapisywany, a następnie testowany. Rozwój oparty na testach lub TDD to podejście, które jest dokładnym ODWRÓCENIEM tradycyjnego programowania. W tym podejściu najpierw wykonuje się testowanie, a następnie zapisuje się kod.

Zmieszany?!!

Jak możemy przetestować oprogramowanie, które nie zostało jeszcze opracowane?

Tak!! To jest rozwój oparty na testach lub TDD.

TDD działa w małych przyrostach, gdzie:

  • Test jest napisany jako pierwszy
  • Test jest wykonywany - co zakończy się niepowodzeniem (z oczywistych powodów)
  • Kod jest zapisywany (lub refaktoryzowany) tylko po to, aby przypadek testowy przeszedł pomyślnie
  • Test jest wykonywany ponownie
  • Jeśli test zakończy się powodzeniem, przejdź do następnego testu. ELSE ponownie napisz / zmodyfikuj kod, aby test przeszedł pomyślnie

Spróbuję to wyjaśnić za pomocą schematu blokowego:

Schemat blokowy TDD

Teraz musimy zrozumieć, że TDD nie mówi o testowaniu, które przeprowadzają testerzy. Raczej to podejście faktycznie mówi o testowaniu, które robią programiści.

Tak!! Zgadłeś! To test jednostkowy.

Test, który jest napisany jako pierwszy, nie jest testem, który piszą testerzy, ale jest to test jednostkowy, który piszą programiści. Więc przeformułowałbym te kroki jako:

  • Test UNIT jest napisany jako pierwszy
  • Wykonywany jest test UNIT - co zakończy się niepowodzeniem (z oczywistych powodów)
  • Kod jest zapisywany (lub refaktoryzowany), aby test przeszedł pomyślnie
  • Test UNIT jest wykonywany ponownie
  • Jeśli test zakończy się powodzeniem, przejdź do następnego testu. ELSE ponownie napisz / zmodyfikuj kod, aby test przeszedł pomyślnie

Teraz pojawia się pytanie - jeśli TDD jest pracą programisty, jaka jest rola testera w tym podejściu?

Cóż, powiedziawszy, że TDD to praca programisty, nie oznacza to, że testerzy nie są w nią zaangażowani. Testerzy mogą współpracować, udostępniając scenariusze testów składające się z:

Chodzi mi o to, że testerzy powinni uczestniczyć w definiowaniu scenariuszy testów jednostkowych i współpracować z programistami w celu ich wdrożenia. Testerzy powinni przekazać swoją opinię na temat wyników testu.

Jeśli chcemy wdrożyć TDD, testerzy muszą ulepszyć swoje zestawy umiejętności. Muszą być bardziej techniczni i skupić się na doskonaleniu swoich umiejętności analitycznych i logicznych.

Testerzy powinni również dołożyć wszelkich starań, aby zrozumieć żargon techniczny, którego używają programiści, i jeśli to możliwe, muszą spojrzeć na kod z lotu ptaka. W podobny sposób programiści muszą wejść w buty testera i spróbować wymyślić bardziej wyrafinowane scenariusze, które sprawią, że testy jednostkowe będą bardziej solidne i solidne.

Zarówno programiści, jak i testerzy muszą wejść w siebie nawzajem, w przeciwieństwie do starego tradycyjnego podejścia, w którym programiści nie przywiązywali dużej wagi do testów jednostkowych, ponieważ polegali na testerach w zakresie znajdowania błędów i usterek, a testerzy nie chcieli sobie pozwolić uczą się technicznych rzeczy, ponieważ myślą, że ich praca kończy się po znalezieniu usterek.

Rozwój oparty na zachowaniu

Behavior Driven Development lub BDD to rozszerzenie do Test Driven Development.

BDD, jak sama nazwa wskazuje, ilustruje metody tworzenia cechy w oparciu o jej zachowanie. Zachowanie jest w zasadzie wyjaśnione na przykładach w bardzo prostym języku, który jest zrozumiały dla każdego w zespole, który jest odpowiedzialny za rozwój.

Niektóre z kluczowych cech BDD są następujące:

  • Język użyty do zdefiniowania zachowania jest bardzo prosty i ma jeden format, w którym może być zrozumiały dla każdego - zarówno osoby techniczne, jak i nietechniczne zaangażowane w implementację
  • Daje platformę, która umożliwia trzem amigos (programista, tester i PO / BA) współpracę i zrozumienie wymagań. Określa wspólny szablon do udokumentowania go
  • Ta technika / podejście omawia ostateczne zachowanie systemu lub sposób, w jaki system powinien się zachowywać, a NIE mówi o tym, jak system powinien być zaprojektowany lub wdrożony
  • Podkreśla oba aspekty jakości:
    • Spełnij wymagania
    • Nadaje się do użytku

Dlaczego BDD?

Cóż, wiemy, że naprawa usterki / pluskwa na późniejszym etapie każdego cyklu rozwojowego jest dość kosztowne. Naprawianie wad produkcyjnych ma wpływ nie tylko na kod, ale także na projekt i jego wymagania. Kiedy robimy RCA (analiza przyczyn źródłowych) w przypadku jakiejkolwiek wady przez większość czasu dochodzimy do wniosku, że wada faktycznie sprowadza się do niezrozumiałych wymagań.

Zasadniczo dzieje się tak, ponieważ każdy ma różne zdolności do zrozumienia wymagań. Dlatego osoby techniczne i nietechniczne mogą różnie interpretować to samo wymaganie, co może prowadzić do wadliwej dostawy. Dlatego niezwykle ważne jest, aby wszyscy w zespole programistycznym rozumieli to SAMO wymaganie i interpretowali je w TEN SAM sposób.

Musimy upewnić się, że cały wysiłek rozwojowy jest ukierunkowany i ukierunkowany na spełnienie wymagań. Aby uniknąć wszelkiego rodzaju defektów typu „wymóg - brak”, cały zespół programistów musi dostosować je, aby zrozumieć wymaganie, które jest odpowiednie do użycia.

Podejście BDD pozwala zespołowi programistów na to poprzez: -

  • Definiowanie standardowego podejścia do definiowania wymagań w prostym języku angielskim
  • Zapewnienie definiujących przykładów wyjaśniających wymagania
  • Zapewnij interfejs / platformę, która umożliwia technicznym (programistom / testerom) i nietechnicznym (zleceniodawca / zleceniodawca / klient) współpracę i wspólne przebywanie na tej samej stronie w celu zrozumienia i wdrożenia wymagań

Jak wdrożyć BDD?

Na rynku dostępnych jest wiele narzędzi do wdrażania BDD. Wymieniam kilka tutaj:

  • Ogórek
  • Zdatność
  • Concordion
  • JBehave
  • Przepływ Spec

Przykład:

Spróbujmy zrozumieć BDD na przykładzie. W moim przypadku używam Gherkin (Cucumber):

Rozważmy prosty przypadek, w którym chcemy, aby tylko uwierzytelnieni użytkownicy mogli wejść na stronę XYZ.

Plik Gherkin (plik funkcji) wyglądałby następująco:

Funkcja: Portal rejestracji testów

Zarys scenariusza: Zalogowany prawidłowy użytkownik

Dany: Klient otwiera portal rejestracyjny

Gdy: użytkownik wprowadza nazwę użytkownika jako „”, a hasło jako „”

Następnie: klient powinien mieć możliwość przeglądania formularza.

Przykłady :

| użytkownik | hasło |

| użytkownik1 | pwd1 |

| użytkownik2 | pwd2 |

Możemy zobaczyć, jak określone wymaganie jest udokumentowane za pomocą prostego języka angielskiego. Trzej amigos mogą współpracować przy projektowaniu plików funkcji, a szczegółowe dane testowe można udokumentować w sekcji przykładów. BDD zapewnia medium łączące programistów, testerów i biznes przy jednym stole i ustalające wspólne rozumienie funkcji do zaimplementowania.

Podejście BDD oszczędza wysiłek i koszty oraz sprawdza, czy po wdrożeniu produkcyjnym są jakieś defekty, ponieważ współpraca klientów i programistów trwała przez cały cykl rozwoju funkcji.

Zespoły programistyczne mogą wykorzystać te pliki funkcji i przekształcić je w programy wykonywalne w celu przetestowania określonej funkcji.

W jaki sposób?

Cóż, musisz się do tego nauczyć Ogórek / Fitness !!

Rozwój oparty na testach akceptacyjnych

ATDD to technika, w ramach której cały zespół współpracuje w celu zdefiniowania kryteriów akceptacji eposu / historii przed faktycznym rozpoczęciem wdrażania. Te testy akceptacyjne są poparte odpowiednimi przykładami i innymi niezbędnymi informacjami.

W większości przypadków BDD i ATDD są używane zamiennie. Podejście ATDD można również zaimplementować przy użyciu formatu Given-When-Then, tak jak piszemy funkcje w podejściu BDD.

Spróbujmy szybko podsumować różnice między trzema podejściami:

  • TDD jest bardziej techniczny i napisany w tym samym języku, w którym zaimplementowano tę funkcję. Jeśli funkcja jest zaimplementowana w Javie, piszemy JUnit przypadki testowe . Natomiast BDD i ATDD są napisane prostym językiem angielskim
  • Podejście TDD koncentruje się na implementacji funkcji. Podczas gdy BDD skupia się na zachowaniu funkcji, a ATDD skupia się na uchwyceniu wymagań
  • Aby wdrożyć TDD potrzebujemy wiedzy technicznej. Natomiast BDD i ATDD nie wymagają żadnej wiedzy technicznej. Piękno BDD / ATDD polega na tym, że zarówno osoby techniczne, jak i nietechniczne mogą uczestniczyć w tworzeniu funkcji.
  • Ponieważ TDD ewoluuje, daje pole do dobrego projektowania i koncentruje się na aspekcie jakości „Spełnienia wymagań”; podczas gdy BDD / ATDD koncentrują się na 2ndaspekt jakości „Zdatny do użytku”

Wszystkie te techniki zasadniczo mówią o podejściu „najpierw test”, w przeciwieństwie do podejścia „test-ostatni” stosowanego w tradycyjnych metodologiach programowania.

Ponieważ testy są pisane jako pierwsze, testerzy odgrywają bardzo ważną rolę. Testerzy muszą nie tylko posiadać rozległą wiedzę branżową i biznesową, ale także posiadać dobre umiejętności techniczne, aby mogli wnieść wartość dodaną podczas burzy mózgów podczas 3 dyskusji amigos.

Dzięki koncepcjom takim jak CI (Continuous Integration) i CD (Continuous Delivery) testerzy muszą dobrze współpracować z programistami i w równym stopniu przyczyniać się do rozwoju i obszaru operacyjnego.

gdzie mogę oglądać anime za darmo online

Pozwólcie, że podsumuję tę dyskusję słynną piramidą testową w Agile:

Przetestuj piramidę w Agile

Najniższa warstwa tej piramidy składa się z warstwy testowej. Ta warstwa jest warstwą fundamentową; dlatego konieczne jest, aby ta warstwa była solidna jak skała. Większość testów należy umieścić w tej warstwie. Ta najniższa warstwa skupia się tylko na TDD.

w Zwinny świecie, nacisk kładzie się na uczynienie tej warstwy piramidy mocniejszą i bardziej wytrzymałą i podkreśla się, że większość testów jest wykonywana na tej warstwie.

Narzędzia użyte w tej warstwie piramidy to wszystkie narzędzia Xunit.

Środkowa warstwa piramidy to warstwa usług, wyjaśniająca testy poziomu usług. Ta warstwa działa jako pomost między interfejsem użytkownika aplikacji a jednostką / komponentem niższego poziomu. Ta warstwa składa się głównie z interfejsów API, które akceptują żądania z interfejsu użytkownika i odsyła odpowiedź. Podejście BDD i TTDD jest aktywne w tej warstwie piramidy.

Narzędzia użyte w środkowej warstwie piramidy to - Fitnesse, Cucumber i Robot Framework .

Najwyższą warstwą piramidy jest rzeczywisty interfejs użytkownika, który pokazuje, że ta warstwa powinna zawierać najmniej testów, lub powinienem powiedzieć, że wysiłek testowania w tej konkretnej warstwie powinien być minimalny. Większość testów tej funkcji powinna zostać zakończona, gdy dotrzemy do górnej warstwy piramidy.

Narzędzia zastosowane w górnej warstwie to - Selen , QTP i RFT.

Ponieważ pracujemy w małych przyrostach w Scrum (zwane Sprintami), ręczne wdrożenie wszystkich tych podejść nie jest możliwe. Te podejścia wymagają automatycznej interwencji. W tym przypadku automatyzacja jest bardzo krytyczna.

W rzeczywistości te podejścia są faktycznie realizowane poprzez automatyzację. Pod koniec każdego sprintu dodawane są nowe funkcje, dlatego ważne jest, aby zaimplementowana funkcja działała zgodnie z oczekiwaniami; W związku z tym, Automatyzacja staje się tu BOHATEREM.

Wniosek

Pod koniec artykułu musieliście się dowiedzieć, w jaki sposób testerzy są zaangażowani w techniki TDD, BDD i ATDD.

W trzeciej części serii skupię się na dyskusji na temat automatyzacji w świecie Agile.

O autorze: Ten artykuł jest autorstwa STH Author Shilpy. Od ponad 10 lat zajmuje się testowaniem oprogramowania w takich dziedzinach, jak reklama internetowa, bankowość inwestycyjna i telekomunikacja.

Obserwuj tę przestrzeń, aby uzyskać znacznie więcej aktualizacji.

rekomendowane lektury

^