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!
Wszystko super fajnie pięknie, jednak autor zapomnial o innej przeciwnosci w zrozumieniu wymagań przez klienta. Czesto wsród klientow w Polsce są tacy którzy w ogole angielskiego nie rozumieją więc przedstawienie wymagan w ten sposob nie pomaga w dyskusji nad nimi a wręcz utrudnia. Dla klientow anglojęzycznych sposób ciekawy
Oskar, mam dla Ciebie dobrą wiadomość. Gherkin może być stosowany z powodzeniem w języku polskim. W składni gherkina istnieją jeszcze tagi, które zapisujemy na początku pliku .feature, wystarczy napisać „# language: pl” i nasze scenariusze będą odczytywane przez narzędzia typu cucumber i będą dalej współpracować. Należy pamiętać o tym, że słowa kluczowe też są po polsku, więc składnia wygląda tak:
Funkcja:
Scenariusz:
Zakładając że…
Kiedy…
Wtedy…
Warto pamiętać, że jeżeli chcemy użyć „And” używamy „Oraz”. Narzedzia do testowania obsługują około 30 języków z tego co pamiętam i polski na pewno jest jednym z nich. Powodzenia!
Czy mógłbyś Łukaszu polecić jakąś literaturę po polsku lub angielsku na temat BDD i Gherkina?
Zaczalem czytac te pozycje http://helion.pl/ksiazki/bdd-w-dzialaniu-sterowanie-zachowaniem-w-rozwoju-aplikacji-john-ferguson-smart,bdddzi.htm
Doac dobrze mnie wrowadza w BDD
Łukaszu,
my na co dzień tworzymy wszystko w moqupach w tym procesy BPMN i opisy wymagań.
Wymagania się zmieniają, ale nie można wszystkich zmian wrzucać do jednego worka. Zmiana nazwy pole to temat inny niż zmiana polegająca w systemie produkcyjnym MES:
– dodaniu do magazynu podmagazynów
– pobieranie surowców z podmagazynów do odpowiednich etapów
– trzymanie FIFO w podmagazynach + magazyn centralny
Warto zwrócić uwagę na rodzaj umowy z klientem
– fixed price
– time & material
Z naszej praktyki wynika, że metodologia X czy Y nie uratuje tematu jeśli po dwóch stronach nie ma zaangażowanych osób.
Łukaszu,
minęło troche czasu od publikacji materiału, czy coś się zmieniło w kwestii twojego postrzegania i używania gherkina? Jest to jeden z nielicznych artykułów, gdzie stosuje się rozwiązanie systemowe jako potrzebę biznesową. Czy BDD powinno sprawdzać system, bezpieczenstwo, a może skupić się tylko na potrzebach biznesowych. Można powiedzieć, że nie wpuszczenie do aplikacji użytkownika jest potrzebą biznesową ?