Gherkin a przypadki użycia

Wielokrotnie już pisałem o metodach zwinnych oraz bardziej klasycznych. W tym tekście także wejdę w ten temat, a mianowicie postaram się porównać podejście analityczne oparte o przypadki użycia i Gherkin wywodzące się z nurtu Behavior-Driven Development. Czym jest Gherkin a czym przypadek użycia?

Przypadek użycia

Zacznę od przypadku użycia. Przypadek użycia (ang. use case) to zbiór scenariuszy powiązanych ze sobą wspólnym celem użytkownika. Przypadek użycia jest graficzną reprezentacją wymagań funkcjonalnych. Definiuje zachowanie systemu bez informowania o wewnętrznej strukturze i narzucania sposobu implementacji. Podstawowe elementy opisu to:

• nazwa
• opis
• przepływ zdarzeń (scenariusze)
• warunki wstępne
• warunki końcowe

Przykładowy diagram wraz z opisem może wyglądać następująco:

Oczywiście to bardzo uproszczony opis, który wraz z listą wymagań funkcjonalnych i poza funkcjonalnych może stanowić wartość. Więcej na temat przypadków użycia można przeczytać tutaj: https://wolski.pro/diagramy-uml/diagram-przypadkw-uzycia/

Gherkin

Po drugiej stronie jest Gherkin. Gherkin to język używany przez Cucumber do definiowania przypadków testowych. Został zaprojektowany tak, aby był nietechniczny i czytelny dla człowieka oraz zbiorczo opisuje przypadki użycia związane z systemem oprogramowania. (definicja własna na bazie https://techtalksonline.com/gherkin/). Dla wyjaśnienia Cucumber to narzędzie wspierające rozwój oprogramowania w oparciu o podejście Behavior-Driven Development. (więcej https://cucumber.io/docs/bdd/).

Gherkin cechuje uporządkowana składania. Podstawowe jej elementy to:

• Feature – opis danej funkcjonalności
• Background – założenia
• Scenario – przejrzysty opis tego, co scenariusz będzie wykonywał
• Given – warunki początkowe
• When – opis wykonywanej akcji
• Then – oczekiwany rezultat

Warto wspomnieć jeszcze o słówku AND będącego kontynuacją wcześniejszego zdarzenia może występować w połączeniu z Given, When i Then. Polskie odpowiedniki tych słów to: odpowiednio funkcjonalność, założenia, scenariusz, założenia, jeżeli i wtedy. Przykładowy scenariusz dla wcześniej przedstawionej sytuacji może wyglądać następująco:

Tak opisana funkcjonalność pięknie może stanowić uzupełnienie historyjki użytkownika, które bazując na formacie  „Jako <rola użytkownika> chcę…” – może wyglądać następująco: Jako Pracownik BOK chcę przekazywać zamówienia do odpowiedniego działu, który podejmie realizację zlecenia.

Gherkin a przypadki użycia

Nasuwa się pytanie czy skoro Gherkin to scenariusze a przypadki użycia to tez scenariusze to jest to jedno i to samo?

Otóż tak i nie.

Tak, gdyż obie metody opierają się na opisie zachowania – bazują na scenariuszach. Obie metody wymagają przeanalizowania każdego pojedynczego kroku działania aplikacji i interakcji z użytkownikiem. Zmuszają do tego by biznes z IT usiedli razem i zastanowili się wspólnie co się stanie gdy…. W obu przypadkach poza spisanie funkcji trzeba je omówić wspólnie by biznes zrozumiał możliwości techniczne jakie oferuje IT, a IT zrozumiało cel i potrzeby biznesu.

Nie, gdyż Gherkin i przypadki użycia w swoich metodykach zajmują trochę inne miejsce. Podejściu zwinnym możemy wyróżnić epiki, historyjki użytkownika a Gherkin idealnie wkomponowuje się rolę kryteriów akceptacji.
Po stronie klasycznej mamy: procesy biznesowe, przypadki użycia i wymagania. Połączenia między tymi elementami można przedstawić w poniższej tabeli (oczywiście to tylko bardzo uproszczony przykład, gdyż w Twojej organizacji może to wyglądać trochę inaczej).

Co więcej, jak słusznie zauważono: „… to co autorzy Gherkin nazywają przypadkiem użycia, nie jest nim w rozumieniu notacji UML i nie należy używać notacji UML do odwzorowania historyjek użytkownika znanych z metod agile.” źródło (https://it-consulting.pl/2021/11/17/opis-wymagan-z-uzyciem-gherkin-czyli-duuuzo-korniszonow ). Gherkin jest zaadoptowanym językiem z obszaru testów i nie jest techniką, który rozwiąże problemy z analizą.

Jak wynika z powyższego, niezależnie od tego czy idziemy drogą zwinną, czy klasyczną to zawsze sprowadza się do kompletnego zrozumienia jak ma działać dana funkcja aplikacji, jak jej istnienie pomoże w działaniu biznesu. Przy dzisiejszej złożoności systemów ani historyjki użytkownika, ani przypadki użycia nie rozwiążą problemu. Potrzebne jest jedno repozytorium wiedzy w całym przedsięwzięciu i dostosowanie technik opisu funkcji aplikacji do jej złożoności.

Jako jedno repozytorium wiedzy mam na myśli miejsce, gdzie analiza spotka się z architekturą, gdzie funkcje aplikacji będą jednoznacznie zdefiniowane i gdzie legendarne JIRA taski będą przyporządkowane do funkcji, by łatwiej się odświeżało pamięć a modele będzie można komentować w czasie rzeczywistym, a nie na podstawie przepasłej dokumentacji. Gdzie czasem zamiast opisu słownomuzycznego albo u strukturyzowanego jak na powyższych przykładach, będzie miejsce na diagram aktywności, maszyny stanowej, diagram sekwencji i inne artefakty potrzebne do zrozumienia złożoności działania aplikacji.

Podsumowując ten wirtualny spór Gherkin a przypadki użycia, można zauważyć, że obie techniki wymagają współpracy biznesu z IT, tak by każdy krok działania aplikacji był zrozumiały. Obie metody, mimo że oparte na scenariuszach, to bez kontekstu, wspólnej analizy nie będą rozwiązaniem problemów. Obie narzucają pewien standard opisu i obie wymagają czasem wsparcia innymi technikami.

Wydaje się, że niezależnie od tego czy pracujemy zwinnie, czy klasycznie trzeba zrobić tę samą robotę. Niestety samo się nie zrobi.