Czy BDD jest w rzeczywistości zapisywalny przez osoby niebędące programistami?


24

Rozwój oparty na zachowaniach z charakterystyczną składnią scenariuszy „Given-When-Then” został ostatnio podekscytowany ze względu na możliwe zastosowania go jako obiektu granicznego do oceny funkcjonalności oprogramowania.

Zdecydowanie zgadzam się, że korniszon , lub jakikolwiek skrypt definicji funkcji, który wolisz, jest czytelną dla biznesu DSL i już zapewnia taką wartość.

Jednak nie zgadzam się, że jest zapisywalny przez nie-programistów (podobnie jak Martin Fowler ).

Czy ktoś ma relacje ze scenariuszy pisanych przez nie-programistów, a następnie opracowywanych przez programistów?

Jeśli rzeczywiście istnieje konsensus co do braku możliwości zapisu, to czy widziałbyś problem z narzędziem, które zamiast zaczynać od scenariuszy i ich instrumentowania, generowałoby scenariusze czytelne dla biznesu z rzeczywistych testów?

Aktualizacja: w odniesieniu do narzędzia „generatora scenariuszy” oczywiście nie odgadłoby magicznie języka biznesowego;) Ale podobnie jak obecnie używamy dopasowań wyrażeń regularnych do tworzenia testów w podejściu odgórnym (w wymiarze abstrakcji), moglibyśmy użyć konstruktory ciągów do tworzenia scenariuszy w podejściu oddolnym.

Przykład „dać tylko pomysł”:

Given I am on page ${test.currentPage.name}
And I click on element ${test.currentAction.element}
…

Upłynie dużo czasu, zanim ludzie będą w stanie stworzyć wspólny język czytelny dla innych ludzi dokładnie, nawet jeśli komputery będą już w stanie pisać kod dla komputerów.

Jak na ironię, JBehave 1 (pierwsze narzędzie BDD) rozpoczęło się od wygenerowania scenariuszy czytelnych dla biznesu. Nie analizowaliśmy angielskiego aż do ogórka. Myślę, że JBehave 1 był przydatny do przypomnienia ludziom, że najpierw musieli o nich porozmawiać ...
Lunivore,

Odpowiedzi:


20

Widziałem to. Nie skończyło się dobrze.

Myślę, że ogórek jest nieporęczną (<- lol: D) abstrakcją z tego właśnie powodu. Zbyt trudne dla osób nietechnicznych, by same pisały; zbyt gadatliwy dla ludzi technicznych.

Ludzie nietechniczni po prostu nie nauczyli się myśleć jak programiści. Naszym przywilejem jest zrozumienie abstrakcyjnej wiedzy, jej rozbicie, ponowne zbudowanie i wciąż być w stanie skutecznie uciec od dwuznaczności. Za to jesteśmy opłacani.

Jeśli rzeczywiście istnieje konsensus co do braku możliwości zapisu, to czy widziałbyś problem z narzędziem, które zamiast zaczynać od scenariuszy i ich instrumentowania, generowałoby scenariusze czytelne dla biznesu z rzeczywistych testów?

Samo narzędzie nie będzie w stanie ich wygenerować. Komputer nie wie nic o domenie biznesowej. Ostatecznie - programista byłby odpowiedzialny za narysowanie tego, co i tak trzeba wygenerować, a nawet wtedy - prawdopodobnie scenariusze te byłyby zbyt szczegółowe / tajemnicze dla ich użytkowników końcowych.


20
Non technical people just haven't learned to think like programmers. Prawda. Ta sama koncepcja została przeforsowana i opracowana na nowo wiele razy w ciągu ostatnich 20 lat i prawie zawsze kończy się to słabymi wynikami. Firmom podoba się koncepcja uzyskiwania oprogramowania bez płacenia tym chciwym twórcom oprogramowania pijawek pijących krew, ale zapominają, że najtrudniejszą częścią tworzenia oprogramowania jest przez większość czasu zrozumienie zasad biznesowych głębiej i bardziej misternie niż samych biznesmenów.
wałek klonowy

2
„Ludzie nietechniczni po prostu nie nauczyli się myśleć jak programiści.” Tak, umiejętność rozkładania problemów i wyrażania ich w ramach określonych atomowych terminów logicznych jest prawdopodobnie tym, co czyni programistą / analitykiem. Pomysł, że wyglądając jak angielski sprawia, że ​​korniszon jest użyteczny dla każdego, wydaje mi się niezwykle naiwny. Dzięki za potwierdzenie :) Computer knows nothing about business domain.Oczywiście. Przepraszam za to, że mój pomysł nie był jasny. Dodam informacje do pytania.
MattiSG,

8
@maple_shaft: Ostatnie 20 lat? Wypróbuj ostatnie 60 lat. Jednym z wczesnych szumów wokół COBOL było to, że ludzie biznesu mogli to napisać, eliminując potrzebę programistów. Kiedy tak się nie stało, ludzie wymyślili kilka języków, które nazywali językami czwartej generacji, które miały robić to samo.
David Thornley,

11

Część trudności w pisaniu dokumentu specyfikacji przez klienta polega na tym, że klient często nie wie, jak tłumaczyć rzeczy, których chce klient, na język, który faktycznie opisuje to, czego potrzebuje klient. Chociaż klient może powiedzieć, że chce, aby pewne zachowanie istniało w systemie, na ogół nie jest tak bardzo zainteresowany drobiazgami, dopóki nie zobaczy, nie użyje i nie doświadczy oprogramowania działającego w sposób, który według niego nie do końca odpowiada jego wymagania.

Kiedy klienci opisują proces biznesowy, często pomijają wiele istotnych informacji. Często te informacje dotyczą rzeczy o procesie, który jest powszechnie rozumiany w konkretnej domenie klienta, a zatem jest brany za pewnik i często nie jest przekazywany programiście. Innym razem klient tak naprawdę nie wie, jak radzić sobie ze wszystkimi warunkami brzegowymi w systemie, i zwraca się do programisty o wskazówki. Czasami jest to prosty przypadek użyteczności, gdy klient myśli, że chce, aby coś działało w jeden sposób, ale później zmienia zdanie, gdy staje się jasne, że wszystko powinno działać inaczej.

Ok, wystarczy „relacji z klientami 101 dla programistów”. Pytanie brzmi, czy nadal warto korzystać z DSL czytelnego dla biznesu, aby zdefiniować sposób definiowania specyfikacji. Uważam, że z wytycznymi odpowiedź jest wstępna „tak” i mówię niepewnie, ponieważ następne pytanie, które przychodzi mi na myśl, brzmi: dlaczego miałbyś mieć klienta wytwarzającego DSL, skoro programista może łatwiej zdefiniować taki, który będzie zapewnić klientowi prosty, ale bogaty język, aby zdefiniować, jak system musi działać?

Kiedy podasz klientowi język do opisania, jak chciałby, aby system działał, skończysz na stwierdzeniach, które mówią coś w stylu:

"for a given 'subsystem', as a 'business entity' I want 'some feature' so that I might achieve 'some result'".

Ten rodzaj oświadczenia kończy opisanie wymagania w bardzo jasny sposób, podając ogólny kształt, który klient zasadniczo chce, aby system przyjął, lub inny sposób patrzenia na to, że klient opisuje, czym jest system. Jeśli chcesz, aby klient pomyślał o czymś nieco dalej, możesz poprosić go o opisanie zasad, których musi przestrzegać ta funkcja, używając szeregu instrukcji podobnych do:

"Given 'some system state', When 'some action occurs', Then expect 'some result'

Znowu bardzo jasne opisy, tym razem o tym, jaksystem powinien się zachowywać. Chodzi o to, że nie zastąpi to konieczności wypełniania pustych pól przez programistę i wypowiadania się o dalszych szczegółach, o których klient może wiedzieć tylko peryferyjnie. Podczas gdy klient może być w stanie zostać „przeszkolony” przez programistę w zakresie opisywania funkcji i zachowań w przyjemnym, przyjaznym dla programisty formacie, klient tak naprawdę nie będzie miał umiejętności ani wiedzy do generowania znaczących przypadków testowych, ani do zapewnienia implementacji kod. Wydaje mi się, że o to chodzi w artykule Martina Fowlera, o którym wspomniał PO. Tak, sam program nie jest zapisywalny przez klienta, ale opis oprogramowania z pewnością może - i IMHO powinien - być napisany przez klienta. Za to, co jest warte, nie przeczytałem artykułu Fowlera, mówiącego, że klient nie powinien

Wydaje mi się, że my programiści czasami zapominamy, że nasi klienci są na ogół bardzo inteligentni, jeśli chodzi o rozumienie swoich firm i procesów biznesowych, z pewnością znacznie lepiej niż my. Kiedy nie mają programisty, który powiedziałby im, jak zbudować system oprogramowania, klienci zazwyczaj uciekają się do innych - być może mniej wydajnych - środków rozwiązywania konkretnych problemów zarządzania przedsiębiorstwem. Rozumiem przez to proste bazy danych (think Access) lub arkusze kalkulacyjne, a nawet ręcznie pisane księgi rachunkowe oraz dobrze zdefiniowane reguły i procedury zarządzania tymi procesami. To, czego brakuje wielu klientom, nie jest sposobem na określenie, jak system musi działać, ale raczej na tym, jak powinien zostać zbudowany , a co ważniejsze, jak skutecznie opisać reguły zachowania systemu osobom, którenie mają umiejętności, aby faktycznie zbudować system.

Jeśli rzeczywiście istnieje konsensus co do braku możliwości zapisu, to czy widziałbyś problem z narzędziem, które zamiast zaczynać od scenariuszy i ich instrumentowania, generowałoby scenariusze czytelne dla biznesu z rzeczywistych testów?

Myślę, że to źle patrzy na ten problem. Widziałbym duży problem z narzędziem generującym dokumentację z testów, gdyby dokumentacja ta miała w jakikolwiek sposób reprezentować specyfikację. Aby przetestować scenariusz, musisz go zrozumieć, dlatego scenariusz musi już istnieć, aby oboje mogli zdefiniować test. Jeśli opisujesz scenariusz w składni BDD, oznacza to, że już go określiłeś, dzięki czemu możesz instrumentować scenariusze tylko po fakcie. Jeśli z drugiej strony masz narzędzie, które pozwoli klientowi opisać system w ładnym, przyjaznym programistycznie DSL, i jeśli to narzędzie może zostać użyte do wygenerowania szablonów kodu, które będą użyte jako pakiet testowy, to „ Powiedzmy, że takie narzędzie miałoby wielką wartość. Nie zobaczyłby, że klient wyjęłby programistów z równania i pomógłby zmniejszyć wysiłek wymagany do spełnienia życzeń klienta i wygenerowania wymagań zakodowanych w teście w sposób BDD, a być może ułatwiłby zrozumienie życzeń klienta. Nie zastąpiłoby to jednak posiadania doświadczonego programisty, który pomógłby klientowi oddzielić potrzeby klienta od jego potrzeb.


„Aby przetestować scenariusz, musisz go zrozumieć, dlatego scenariusz musi już istnieć, aby oboje mogli zdefiniować test” . Zgadzam się. Pytam o to, czy egzekwowanie ograniczeń językowych jest coś warte. Nie twierdzę, że powinniśmy pisać tylko testy; ale zastanawiam się, czy nie powinniśmy zaakceptować faktu, że opis firmy będzie (i prawdopodobnie powinien) zawsze być prostym, wolnym opisem formularza . W związku z tym dysponowalibyśmy czystymi biurami biznesowymi i wygenerowalibyśmy czytelne scenariusze, pozwalając ludziom decydować, czy pasują do siebie; zamiast udawać, że używamy rzeczywistych komputerów do testowania.
MattiSG,

@MattiSG ...whether enforcing language constraints is worth anything. To dobre pytanie. Dowolne opisy są bardziej ekspresyjne i naturalne dla pisarza, ale skutkują nieprzyjemnymi komentarzami, które wymagają rozbioru w celu uzyskania użytecznej specyfikacji. Definiując formalne „reguły” (inaczej DSL) dotyczące pisania wymagań i specyfikacji, masz wspólny język, który zarówno klient, jak i programista mogą zrozumieć, ograniczając nieporozumienia. Jeśli poprawnie otrzymasz opisy, można je używać dosłownie jako szablonu do testów. Dlatego nie ma potrzeby stosowania złożonych narzędzi do „generowania” czegokolwiek.
S.Robins,

@MattiSG FWIW, za pomocą DSL i BDD to system, którego sam używam. Wymagania są zdefiniowane jako oświadczenia podmiot-cecha-korzyść, a następnie specyfikacja, która rozszerza początkowe oświadczenia o wymaganiach przy użyciu oświadczeń AAA (Tj. Given-When-Then) ... zasadniczo oświadczeń scenariuszowych. Trudność przy próbie odkodowania dowolnego tekstu polega na tym, że bez DSL nie ma łatwego sposobu na zdefiniowanie algorytmu, który może generować sensowne scenariusze gromadzenia. Chodzi mi o to, że użycie testów jako punktu wyjścia do generowania scenariuszy jest swego rodzaju odwrotnością.
S.Robins

5

Widziałem programistów piszących scenariusze; testerzy piszą scenariusze, a nawet właściciel produktu pisze scenariusze. Przeprowadziłem również rozmowy mające na celu przedstawienie scenariuszy - „Biorąc pod uwagę ten inny kontekst>, co wtedy powinno się stać?” - i zapisał słowa używane przez firmę.

Najlepsze wyniki, jakie miałem, to rozmowa z właścicielem produktu, gdy był w biurze, przechwytywanie ich na wiki, a następnie wysyłanie ich do niego, aby mógł poprawić i dodać więcej. Znalazł parę, za którą tęskniliśmy w rozmowach. To kołysało.

Najgorsze scenariusze, jakie widziałem, to te, które napisali sami programiści bez rozmowy z biznesem. Mogę powiedzieć, ponieważ używają terminów takich jak „Kiedy przeprowadzam wyszukiwanie” lub „Kiedy przesyłam formularz z datą dzisiejszą + 3”. Zwykle nie są to bardzo ciekawe scenariusze, o wiele za dużo, zbyt niski poziom szczegółowości i dlatego całkowicie niemożliwy do utrzymania. Firma też ich nie czyta.

Znacznie lepiej skupić się na rozmowach IMO. Widziałem kilka zespołów, które robią to teraz przez kilka miesięcy z ogromną poprawą jakości, niezależnie od automatyzacji. Pewnemu zespołowi kilka tygodni później udało się uruchomić automatyzację w bardzo trudnym środowisku, ku wielkiej radości testera! Ale tak naprawdę, dopóki zespół prowadzi rozmowy i korzysta ze scenariuszy do rysowania innych scenariuszy, nie sądzę, że liczy się, kto je spisuje.


+1 Komunikacja jest naprawdę kluczem, a scenariusze naprawdę muszą polegać na tym, że ludzie biznesu nas, więc zgodnie z pytaniem PO, jeśli tworzymy DSL, to naprawdę musi być w stanie być bliżej na to, co powie klient, a nie na to, co zdaniem programistów powinien powiedzieć klient.
S.Robins

0

Z mojego doświadczenia wynika, że ​​najlepiej pozostawić licencjata (Business Analyst) napisanie GWT ( Given-When-Then ) (doświadczenie przy użyciu SpecFlow). BA może przełożyć wymagania klienta na GWT, a firma może je przeczytać. Klienci rozumieją systemy, ale nie mają wiedzy technicznej, aby napisać wymagania w sposób, który możemy wykorzystać.

Idealnie BA napisałaby GWT, dokonałabym kilku poprawek, BA przeglądałaby / poprawiała powtarzanie, aż BA i biznes byli pewni zasięgu. Praktycznie licencjat dałby mi szorstki szkic, który posprzątałem i wykonałem pracę. Firma wzrusza ramionami, mówiąc, że jest pewna, a potem zastanawia się, dlaczego nie objęła niektórych obszarów, o których nikt nie pomyślał.


Czy możesz wyjaśnić, co dla Ciebie oznacza GWT ? :)
MattiSG,

@MattiSG: zgadnij, że chodzi o Given-When-Then (patrz OP).
sleske

@MattiSG - zaktualizowano post dobry połów.
SoylentGray,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.