BDD/TDD vs JAD?

Question

Proponuję, aby moje miejsce pracy wdrażało Behavior-Driven-Development, pisząc wysokopoziomowe specyfikacje w formacie scenariuszowym, w taki sposób, aby można było sobie wyobrazić napisanie testu dla niego.

Wiem, że działanie wbrew testowalnym specyfikacjom zmierza do increase developer productivity. I już mogę wymyślić kilka przykładów, w których dotyczy to naszego własnego projektu.

Trudno jest jednak wykazać wartość tego faktu dla firmy.

To dlatego, że mamy już wdrożony proces wspólnego opracowywania aplikacji (JAD), w którym programiści, kierownictwo, użytkownicy i testerzy spotykają się, aby uzgodnić wspólny zestaw wymagań.

Pytają więc, dlaczego deweloperzy powinni pracować przeciwko testom stworzonym przez testerów? Są one przeznaczone do weryfikacji i są oparte na specyfikacjach wyższego poziomu tworzonych przez zespół UX, które deweloperzy obecnie pracują.

To, jak mówią, jest wystarczające dla programistów i nie trzeba zmieniać sposobu zapisywania specyfikacji.

Wydają się mieć rację.

Jaka jest rzeczywista korzyść z BDD/TDD, jeśli masz już zespół testowy, którego przypadki testowe są w pełni zgodne ze specyfikacjami wyższego poziomu, które są obecnie przekazywane programistom?

Answer 1

Jeśli chcesz przekonać ich, że to pomogłoby, najważniejszą rzeczą, którą musisz zrobić, to zidentyfikować problem, który rozwiąże.

Co się stanie w Twojej sytuacji, że uważasz, że to się poprawi?

Główną zaletą BDD jest poprawa komunikacji między interesariuszami i programistami.

Jeśli tworzysz kod, który nie przejdzie testów weryfikacyjnych, programiści zrozumieli specyfikację inaczej niż testerzy, co oznacza, że ​​specyfikacja nie jest jasna, a BDD może zdecydowanie poprawić sytuację.

Są również części procesu, w którym jako programista można pracować bez zmiany całego procesu zespołu. Jeśli skoncentrujesz się na poziomie testowania jednostkowego i wykonasz tradycyjne, oparte na testach opracowanie, może to zwiększyć produktywność.

Answer 2

Pomóc może myśleć o BDD w swojej najlżejszej formie; jako dyskusje wokół konkretnych scenariuszy.

Masz swoje przypadki użycia. Masz swoje wymagania. Teraz chcesz sprawdzić, czy naprawdę dobrze je rozumiesz. Więc ktoś - może programista, może tester - mówi: "Okej, tylko po to, aby zweryfikować, że rozumiem ... biorąc pod uwagę, że zaczynamy od <to>, kiedy użytkownik robi <ten> następnie <ten> powinien się wydarzyć. dobrze?"

A tester powie: "Tak, to prawda".

Następnie UX lub analityk mówi: "Cóż, to prawda, chyba że < ten inny kontekst istnieje >".

Dzięki dyskusjom wokół scenariuszy drastycznie skraca się czas potrzebny do zapewnienia, że ​​wszyscy mają wspólne rozumienie. Zwykle glosujemy nad oczywistymi scenariuszami i koncentrujemy się na przypadkach skrajnych; na temat nowych terminów domen, koncepcji, które różnią się między działami, trudnych interakcji ze starszymi systemami.

Deweloperzy tak naprawdę nie działają poza przypadkami testowymi. Działają zgodnie z wymaganiami i kryteriami akceptacji dokładnie w taki sam sposób, jak zawsze. Sprawy testowe stają się po prostu przykładem tego, czego mogą się spodziewać; scenariusze, w których użytkownicy mogą czerpać korzyści z wartości systemu lub przekazywać je. Automatyzacja tych przypadków testowych może być przydatna, ponieważ wysiłek testowania wzrasta w przybliżeniu proporcjonalnie do rozmiaru bazy kodów.

BDD działa najlepiej w projektach, w których występuje duża niepewność związana z wymaganiami lub domeną, a zrozumienie innych osób znacznie się różni. Jeśli twój projekt już działa, to trzymaj się go. Być może mógłbyś rzucić okiem na to, gdzie największa luka między wymyślaniem pomysłów a ich realizacją jest, a jeśli BDD pomaga ci w tej przestrzeni, użyj go; inaczej wybierz coś innego. To, co robisz, brzmi bardzo podobnie do procesów BDD.

Answer 3

To jest doskonałe pytanie, w rzeczywistości jest to kwestia "dolnej linii", jeśli chodzi o BDD. Jednym z głównych wyzwań TDD lub pisania testów jednostkowych jest to, że programiści nigdy nie wydają się mieć szerszego obrazu i perspektyw biznesowych. Ćwiczenie pisania specyfikacji i testów jednostek wytwórczych w celu przetestowania rzeczywistych scenariuszy biznesowych pomaga rozwijającym się projektom wykroczyć ponad ich "kunszt" i zrozumieć perspektywę biznesową. Sprawdź ten post więcej szczegółów

http://codingcraft.wordpress.com/2011/11/12/bdd-get-your-tdd-right/

Answer 4

Właśnie natknąłem się na to pytanie, a myślałem, że ważą, bo to naprawdę jest bardzo ciekawe pytanie.

Metodologia jest zepsuta tylko wtedy, gdy cały zespół czuje, że jest zepsuty, a jeśli wynikiem końcowym jest projekt zakończony niepowodzeniem.

Jeśli obecny system działa dobrze, to naprawdę musisz zadać sobie pytanie: "czy mogę tak pracować, nawet jeśli wolę BDD/TDD?". Jeśli twoja odpowiedź brzmi "nie", a ty czujesz, że możesz być nieszczęśliwy w pracy z jakimkolwiek innym systemem, być może to wskazuje, że twoja kariera musi przenieść się gdzie indziej. Jeśli tak, to objąć system.

Właściwie, jeśli to ja, to i tak skorzystam z nowego systemu. Po pierwsze, jeśli masz szansę na dokładne zapoznanie się z nim, to pozwoli ci to na bardziej świadomą ocenę względnych plusów i minusów, a dzięki tej wiedzy możesz zaproponować ewentualne ulepszenia w późniejszym terminie, jeśli były konieczne.

Pod koniec dnia metodologia jest tak dobra, jak jej wynik końcowy. Oprogramowanie robocze i zadowolenie wszystkich zainteresowanych stron.

:-)