Analiza wymagań produktowych poprzez zastosowanie języka Gherkin

Dobrze zdefiniowane wymagania są kluczem do zbudowania produktu, który spełni potrzeby i oczekiwania użytkowników. Aby udokumentować nasze wymagania, możemy użyć chociażby historyjek użytkownika (spotykane głównie w metodzie Scrum), przypadków użycia czy mockupów. Każda z tych technik posiada zarówno zalety jak i wady. W tym artykule chciałbym jednak opisać Ci trochę inne podejście, które wykorzystuję w swoich projektach i sprawdza się o wiele lepiej – język Gherkin.

Problem biznesowy

Problem biznesowy – to pierwszy krok przy analizie inżynierii wymagań. Formułując problem biznesowy, nie należy skupiać się na szczegółach, a raczej myśleć wysokopoziomowo.

Oto przykład problemu biznesowego:

„Coraz trudniej pozyskać wykwalifikowanych pracowników branży ICT”

Drugim krokiem jest przygotowanie rozwiązania tego problemu. Może nim być jakaś usługa lub produkt, a nawet proces. Kontynuując – przykładem rozwiązania biznesowego dla postawionego problemu będzie:

„Stworzenie aplikacji skillhunt.io – platformy rekrutacyjnej, w której za polecenie pracownika, użytkownik platformy otrzyma wysoką nagrodę pieniężną”

Na tym etapie szczegóły są zbędne. Jeżeli dokonamy oceny, przeprowadzimy badania rynku i okaże się, że nasze rozwiązanie posiada uzasadnienie biznesowe, możemy rozpocząć zbieranie wymagań.

Zbieranie wymagań

Zastanówmy się przez chwilę, jak należy zebrać wymagania, aby spełniały swoją rolę. Subiektywnie oceniając, uważam, że wymagania powinny spełniać 3 główne kryteria – powinny być:

• jednoznaczne i przejrzyste,
• zrozumiałe dla wszystkich interesariuszy,
• aktualne i udokumentowane.

Aby znacząco ułatwić zbieranie wymagań oraz właściwie spełnić wszystkie powyższe kryteria, możemy zebrać wymagania na kilka sposobów – jednym z nich jest wykorzystanie języka Gherkin, o którym chciałbym opowiedzieć Ci więcej.

Język Gherkin

Wywodzi się tak naprawdę z podejścia BDD (Behavior-driven development) i jest naturalnym językiem. Poza tym, że świetnie nadaje się do zbierania wymagań, może też służyć programistom przy tworzeniu scenariuszy do testów funkcjonalnych. Zapis wymagań w języku Gherkin jest jednoznaczny, przejrzysty i co najważniejsze – prosty do zrozumienia dla wszystkich zainteresowanych stron. Dzięki temu dyskusja nad wymaganiami staje się możliwa. Jeżeli pierwszy raz słyszysz o BDD, zachęcam Cię gorąco do zgłębienia tego tematu. Jeżeli jednak miałeś już okazję używać chociażby narzędzia o nazwie Cucumber, jestem pewien, że znasz już wartość z zastosowania tej praktyki w zespołach.

Podstawy

Jak każdy inny język, Gherkin posiada swoją składnię. Narzucona jest jej określona struktura, pojawiają się pewne słowa kluczowe, które muszą wystąpić. Spójrzmy na prosty przykład:

Feature: Log out from application

Scenario: 
        Given I am logged in

        When I click “log out” button     

        Then I am informed about successful logout     
      
        And I am redirect to login page

Zbierane wymagania są w Gherkinie zapisywane do pliku z rozszerzeniem .feature. Dzięki temu programiści mogą użyć takich plików do pisania testów automatycznych w metodyce BDD przy użyciu narzędzia Cucumber. Przystępując do tworzenia nowego opisu wymagań, zapisujemy Feature – w tej sekcji opisujemy nazwę funkcjonalności. Następnie przystępujemy do stworzenia scenariusza (Scenario). Warto zaznaczyć, że w jednym pliku może wystąpić kilka scenariuszy. Każdy scenariusz zawiera kilka kroków oznaczanych na początku każdego wersu, kolejno: Given, When i Then. Kroki poprzedzone słowem Given ustalają warunki początkowe, When służy do opisania akcji wykonywanych dla danej funkcjonalności, a Then określa spodziewany rezultat. W powyższym przykładzie znajduje się jeszcze jedno słowo kluczowe: And, które kontynuuje wcześniejszą metodę. I tak, na przykład, użyte po When, będzie kontynuowało tę sekcję. Istnieje jeszcze słowo kluczowe But, ale przyznam szczerze, że w całej swojej karierze nie znalazłem dla niego zastosowania. To tyle, jeżeli chodzi o podstawy.

Jeszcze więcej możliwości

Gherkin daje nam jednak więcej możliwości! Jeżeli zbierając wymagania chcemy dodatkowo ułatwić pracę zespołowi programistów, możemy skorzystać z jego rozszerzonych funkcji. Background pozwala nam na wyłączenie wspólnych wierszy Given dla wszystkich scenariuszy przed te scenariusze. Dzięki temu możemy zaoszczędzić cenny czas. Przykład zamieściłem poniżej:

Feature: Select profile

Background: 
        Given I am logged in  

Scenario: First profile select 

        Given I go to application after logging

        When I am asked which profile I would like to choose from my list        

        And I select profile from list 

        Then I see dashboard for this profile

Scenario: Next profile select

        Given I am on dashboard

        And I have selected profile

        When I select  from dropdown with list

        Then I see dashboard for this 

Dodatkowo, jeżeli chcemy omówić wymagania, a w przyszłości przetestować więcej niż jeden przypadek, warto użyć przykładów, czyli skorzystać z funkcji Example. Zbieranie wymagań w takiej formie jest często najbardziej jednoznaczne. Aby użyć Example wystarczy oznaczyć zmienne znakami <> oraz wprowadzić tabelę pod scenariuszem. Należy pamiętać, że jeżeli używamy przykładów, nasze scenariusze powinny się nazywać Scenario Outline. Poniższy przykład powinien wszystko rozjaśnić:

Feature: 
        Login to application

Background:
        Given I am registered user

        And my account is activated

Scenario Outline: Successful login

        Given I am on login page

        When I fill "login" with <login>

        And I fill "password" with <correct-password>      

        And click "Login" button

        Then I am redirect to page with profile select

Examples: 
        | login     | correct-password |

        | Lukasz    | Gh3rk1n          |

        | Arek      | Cucumb3r         |

Scenario Outline: Unsuccessful login

        Given I am on login page

        When I fill "login" with <login>

        And I fill "password" with <incorrect-password>      

        And clik "Login" button

        Then I am be informed about unsuccessful login

Examples: 
        | login     | incorrect-password |

        | Lukasz    | Gherkin            |

        | Arek      | Cucumber           |

Scenario: Unauthorized entry

        Given I am not logged in

        When I try to go Dashboard page

        Then I am redirect to login page

Oczywiście w projektach zwinnych wymagania się zmieniają. Wymaga to od zarządzającego takim produktem nanoszenia bieżących zmian w plikach .feature, a co za tym idzie – zmian w testach do aplikacji. Dzięki temu nasza dokumentacja może być przez cały czas aktualna. Wykonywanie prac według kolejnych scenariuszy skutkuje dostarczaniem działających elementów i świetnie wpisuje się w zasady zwinnego zarządzania.

Gherkin a kryteria akceptacji historyjek użytkownika

Doświadczenie z języka Gherkin można przenieść na kryteria akceptacyjne do user stories. Słowa kluczowe Given-When-Then w połączeniu z user stories mogą być dopełnieniem kryteriów akceptacji poszczególnej historyjki. Zdefiniowanie poprawnych i jasnych kryteriów nie jest wbrew pozorom prostym zadaniem. Posługując się jednak scenariuszem, który omówiłem powyżej, jesteś w stanie stworzyć punkty, które będą jasne dla wszystkich – zarówno programistów jak i osób nietechnicznych. To czy wygodniej jest opisać wymagania poprzez user stories i kryteria akceptacji, czy podzielić je na funkcjonalności i scenariusze – musisz zdecydować sam.

Podsumowanie

Na koniec dodam, że wdrożenie języka Gherkin z całą pewnością nie jest proste, napotkasz wiele problemów i przeszkód, ale nie poddawaj się, zaowocuje to wieloma korzyściami, które są warte poświęcenia. Dzięki Gherkinowi Twoje wymagania będą jednoznaczne, przejrzyste i  proste do zrozumienia dla wszystkich zainteresowanych stron. Jeżeli masz jakiekolwiek pytania, napisz proszę w komentarzu. A tymczasem powodzenia!