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:

opis przypadku uzycia

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:

gherkin przyklad

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).

zwinnie vs klasycznie

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ą.

gherkin vs przypadki uzycia

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.

propaborate jira

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. 

Podobne wpisy
Analityk w podejściu zwinnym

Rola analityka i znaczenie analizy w wielu organizacjach umacnia się a w innych zanika. Dość często tam, gdzie pojawia się więcej

5 wskazówek dla analizy w ujęciu AGILE

Scrott Ambler kilkanaście miesięcy temu opublikował 5 wskazówek, które powinny usprawnić analizę w ujęciu AGILE Oto one: 1. Aktywny udział więcej

Planowanie w projekcie w nurcie Agile

Planując pracę  swoją czy też swojego zespołu staram się przestrzegać kilku zasad. Oto one: Plan szczegółowy buduję jedynie dla najbliższych więcej

Wymagania biznesowe a wymagania systemowe

Wiele się mówi o potrzebie identyfikacji celów projektowych, celów organizacji a także o potrzebie identyfikacji wymagań biznesowych oraz systemowych. Wszystko po więcej

Reklama
MODESTO - licencje Enterprise Architect

1 komentarz dla “Gherkin a przypadki użycia”

  1. No napisałeś to tak ostrożnie, że nie ma się do czego przyczepić 🙂
    Poza jednym, Gherkin nie służy do pisania przypadków testowych. Patrzenie na Gherkina w ten sposób prowadzi o testowania kilikania albo wielganych testów end2end koszmarnych w utrzymaniu. Gherkin służy do porządkowania rozmowy o tym, jak ma działać oprogramowanie, aby upewnić się, że wszyscy rozumieją to tak samo. Scenariusze mogą prowadzić do automatycznego weryfikowania czy zachowanie oprogramowania jest zgodne z oczekiwaniem i to jest benefit. Jednakże nie należy utożsamiać scenariuszy z testami, podobnie jak User Stories nie należy utożsamiać z wymagniami funkcjonalnymi.

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany.

Przewiń do góry