Język Gherkin: co to jest i jak go używać w testowaniu oprogramowania

Czas czytania: około 16 minut

Język Gherkin pomaga opisywać wymagania, kryteria akceptacji i scenariusze testowe w sposób zrozumiały dla testerów, programistów, analityków, product ownerów i osób biznesowych. Jego największą wartością nie jest sama składnia, ale to, że pozwala zespołowi rozmawiać o zachowaniu aplikacji prostym, wspólnym językiem.

W praktyce Gherkin jest najczęściej używany w podejściu Behavior Driven Development, czyli BDD. Dzięki niemu zespół może zapisać oczekiwane zachowanie systemu w formie scenariuszy opartych o strukturę Given, When, Then. Taki zapis może być jednocześnie dokumentacją biznesową, podstawą testów akceptacyjnych i punktem wyjścia do automatyzacji w narzędziach takich jak Cucumber.

Czym jest język Gherkin?

Gherkin to prosty, ustrukturyzowany język do zapisu scenariuszy zachowania systemu w formie Given, When, Then, czytelny jednocześnie dla biznesu, testerów i programistów, i wykonywalny przez narzędzia takie jak Cucumber.

Gherkin to prosty język opisu scenariuszy, który nadaje naturalnemu tekstowi określoną strukturę. Oficjalna dokumentacja Cucumber opisuje Gherkin jako zestaw specjalnych słów kluczowych, które nadają scenariuszom znaczenie i pozwalają tworzyć wykonywalne specyfikacje. Najważniejsze słowa kluczowe to Feature, Scenario, Given, When, Then, And, But, Background, Scenario Outline i Examples.

Najprościej mówiąc, Gherkin pozwala zapisać, co ma się wydarzyć w aplikacji, w jakich warunkach użytkownik wykonuje akcję i jaki rezultat powinien otrzymać. Dzięki temu scenariusz może zrozumieć osoba techniczna i nietechniczna. Tester widzi przypadek testowy, programista widzi zachowanie do zaimplementowania, product owner widzi kryterium akceptacji, a biznes widzi opis oczekiwanej wartości.

Gherkin nie jest magicznym narzędziem, które samo poprawia jakość projektu. Jeżeli scenariusze są pisane chaotycznie, zbyt technicznie albo bez udziału biznesu, szybko zamieniają się w dodatkową warstwę dokumentacji, której nikt nie utrzymuje. Jego wartość pojawia się wtedy, gdy wspiera rozmowę o wymaganiach, testach i ryzyku jeszcze przed implementacją.

Jak Gherkin łączy się z Behavior Driven Development?

Gherkin jest sposobem zapisu ustaleń wypracowanych w BDD, czyli we współpracy biznesu, developmentu i QA nad tym, jak produkt ma się zachowywać; BDD to proces i rozmowa, Gherkin to jej notacja.

Gherkin jest mocno związany z BDD, czyli Behavior Driven Development. Cucumber wskazuje, że BDD to proces tworzenia oprogramowania, który Cucumber został zaprojektowany wspierać, ale jednocześnie podkreśla, że BDD to coś więcej niż samo używanie narzędzia Cucumber.

To bardzo ważne rozróżnienie. BDD nie polega wyłącznie na pisaniu scenariuszy w plikach feature. BDD polega na współpracy między biznesem, developmentem i QA w celu ustalenia, jak produkt powinien się zachowywać. Gherkin jest tylko sposobem zapisania tych ustaleń w uporządkowanej formie.

Dobrze wdrożony Gherkin pomaga odpowiedzieć na pytania: co użytkownik chce osiągnąć, jakie warunki muszą być spełnione, jaką akcję wykonuje użytkownik, jaki rezultat jest poprawny, jakie scenariusze negatywne trzeba uwzględnić i kiedy można uznać funkcję za gotową.

Do czego służy Gherkin w testowaniu oprogramowania?

Gherkin służy do zapisu kryteriów akceptacji i scenariuszy testowych tak, żeby wymaganie miało jedną interpretację: w testach akceptacyjnych, funkcjonalnych i regresyjnych, w dokumentacji wymagań i jako punkt wejścia do automatyzacji.

Gherkin służy przede wszystkim do opisywania zachowania systemu. Można go stosować w testach akceptacyjnych, testach funkcjonalnych, testach regresyjnych, dokumentacji wymagań, automatyzacji testów oraz rozmowach między QA, biznesem i zespołem developerskim.

Najczęściej Gherkin jest wykorzystywany do zapisu kryteriów akceptacji dla user stories. Zamiast ogólnego opisu typu „użytkownik może się zalogować”, zespół zapisuje konkretne scenariusze: co się dzieje, gdy dane są poprawne, co się dzieje, gdy hasło jest błędne, co się dzieje, gdy konto jest zablokowane, co się dzieje, gdy użytkownik nie potwierdził adresu email.

Dzięki temu Gherkin zmniejsza ryzyko różnej interpretacji wymagań. Product owner, tester i programista mogą wspólnie przejść przez scenariusz i od razu zobaczyć, czy opis funkcji jest kompletny. To szczególnie przydatne w projektach, w których błędy powstają nie przez słaby kod, ale przez nieprecyzyjną komunikację.

Jeżeli Wasza firma ma problem z odbiorami funkcji, brakiem jasnych kryteriów akceptacji lub błędami wykrywanymi dopiero na końcu sprintu, sprawdź testy odbiorcze i akceptacyjne oraz zarządzanie testami QA.

Jak wygląda składnia Gherkin: Feature, Scenario, Given, When, Then?

Scenariusz w Gherkinie zaczyna się od Feature (funkcjonalność) i Scenario (przypadek), a kroki zapisuje się słowami Given (warunki początkowe), When (akcja) i Then (oczekiwany rezultat), z And i But do dopisania kolejnych kroków.

Podstawowa składnia Gherkin jest prosta. Scenariusz zaczyna się zwykle od Feature, czyli opisu funkcjonalności. Następnie pojawia się Scenario, czyli konkretny przypadek zachowania systemu. Kolejne kroki zapisuje się za pomocą Given, When i Then.

Given opisuje warunki początkowe. When opisuje akcję użytkownika lub zdarzenie w systemie. Then opisuje oczekiwany rezultat. And oraz But pozwalają dopisać dodatkowe warunki, akcje lub rezultaty bez powtarzania głównych słów kluczowych.

Przykład prostego scenariusza logowania może wyglądać tak:

Feature: Logowanie użytkownika

Scenario: Poprawne logowanie aktywnego użytkownika
Given użytkownik znajduje się na stronie logowania
And użytkownik ma aktywne konto w systemie
When użytkownik wpisuje poprawny adres email i poprawne hasło
And użytkownik klika przycisk Zaloguj
Then użytkownik zostaje przeniesiony do panelu aplikacji
And użytkownik widzi swoje imię w nagłówku strony

Taki scenariusz jest czytelny, ale jednocześnie konkretny. Nie opisuje technicznych szczegółów implementacji, takich jak selektory, klasy CSS czy zapytania do bazy danych. Opisuje zachowanie widoczne z perspektywy użytkownika i biznesu.

To właśnie jest jedna z najważniejszych zasad dobrego Gherkina: scenariusz powinien mówić, co ma się wydarzyć, a nie jak dokładnie kod ma to zrobić.

Jak pisać dobre scenariusze Gherkin?

Dobry scenariusz Gherkin jest krótki, opisuje jeden przypadek zachowania językiem domeny biznesowej i mówi, co ma się wydarzyć, a nie jak kod ma to zrobić; jeżeli rośnie i wymaga wielu danych, trzeba go podzielić.

Dobry scenariusz Gherkin powinien być krótki, konkretny i zrozumiały. Powinien opisywać jeden przypadek zachowania, a nie cały proces biznesowy z wieloma wyjątkami. Jeżeli scenariusz robi się długi, zawiera zbyt wiele warunków albo wymaga wielu danych, to zwykle znak, że trzeba go podzielić na mniejsze scenariusze.

Scenariusz powinien być pisany językiem domeny biznesowej. Jeżeli testujecie sklep internetowy, używaj pojęć takich jak koszyk, zamówienie, metoda dostawy, płatność, rabat i klient. Jeżeli testujecie system bankowy, używaj pojęć takich jak rachunek, przelew, saldo, odbiorca i autoryzacja. Dzięki temu scenariusze stają się dokumentacją zachowania produktu, a nie tylko technicznym opisem kroków.

Warto unikać scenariuszy, które są zbyt blisko interfejsu. Zapis „klikam zielony przycisk w prawym górnym rogu” jest mniej trwały niż „użytkownik zatwierdza formularz”. Interfejs może się zmienić, ale intencja biznesowa pozostaje taka sama.

Jak używać Given, When, Then w praktyce?

Given przygotowuje kontekst, When opisuje jedną główną akcję, Then wskazuje obserwowalny efekt; najczęstszy błąd to mieszanie tych ról, na przykład akcje w Given albo kolejne kliknięcia w Then.

Struktura Given, When, Then jest prosta, ale wiele zespołów używa jej niepoprawnie. Najczęstszy problem polega na mieszaniu warunków początkowych, akcji i rezultatów. Jeśli Given zawiera akcje użytkownika, When zawiera kilka kroków procesu, a Then zawiera kolejne kliknięcia, scenariusz traci czytelność.

Given powinno przygotować kontekst. To miejsce na informacje o stanie użytkownika, danych, konfiguracji lub warunkach początkowych. When powinno opisać główną akcję, która jest testowana. Then powinno wskazać obserwowalny efekt.

Przykład scenariusza dla błędnego logowania:

Feature: Logowanie użytkownika

Scenario: Logowanie z błędnym hasłem
Given użytkownik znajduje się na stronie logowania
And użytkownik ma aktywne konto w systemie
When użytkownik wpisuje poprawny adres email i błędne hasło
And użytkownik klika przycisk Zaloguj
Then użytkownik pozostaje na stronie logowania
And użytkownik widzi komunikat o niepoprawnych danych logowania

Ten scenariusz jest dobry, ponieważ ma jasny kontekst, jedną główną akcję i oczekiwany rezultat. Nie opisuje technicznych szczegółów automatyzacji, ale jest wystarczająco konkretny, aby tester mógł go zweryfikować, developer mógł go zrozumieć, a product owner mógł zaakceptować logikę działania.

Kiedy używać Scenario Outline i Examples?

Scenario Outline z tabelą Examples stosuje się wtedy, gdy ten sam scenariusz trzeba sprawdzić dla kilku zestawów danych, na przykład w walidacji pól, kalkulacjach i regułach decyzyjnych; przy kilkudziesięciu wierszach dane lepiej przenieść do testów API lub osobnej strategii danych.

Scenario Outline i Examples są przydatne wtedy, gdy chcecie sprawdzić ten sam scenariusz dla różnych zestawów danych. Dzięki temu nie musicie pisać wielu prawie identycznych scenariuszy. Możesz zdefiniować jeden schemat i tabelę przykładów.

Przykład dla walidacji pola hasła:

Feature: Walidacja hasła podczas rejestracji

Scenario Outline: Rejestracja z niepoprawnym hasłem
Given użytkownik znajduje się na formularzu rejestracji
When użytkownik wpisuje hasło "<haslo>"
And użytkownik próbuje utworzyć konto
Then użytkownik widzi komunikat "<komunikat>"

Examples:
| haslo     | komunikat                         |
| abc       | Hasło jest za krótkie             |
| 12345678  | Hasło musi zawierać literę        |
| haslotest | Hasło musi zawierać cyfrę         |

Scenario Outline jest bardzo użyteczne w testach walidacji, kalkulacji, ról użytkowników, metod dostawy, typów płatności, limitów biznesowych i reguł decyzyjnych. Trzeba jednak uważać, aby tabela przykładów nie stała się zbyt duża. Jeżeli zawiera kilkadziesiąt wierszy, warto zastanowić się, czy Gherkin nadal jest najlepszym miejscem na wszystkie dane testowe.

Przy bardziej złożonych danych lepiej rozważyć osobną strategię danych testowych, testy API, testy integracyjne albo automatyzację na niższym poziomie. W tym obszarze przyda się Wprowadzenie do testowania API Postman oraz Bazy danych język SQL dla testerów.

Kiedy warto używać Background?

Background zapisuje kroki wspólne dla wszystkich scenariuszy jednej funkcjonalności, na przykład zalogowanego użytkownika, i ma ograniczać powtórzenia, ale nie może ukrywać kontekstu, bez którego scenariusz przestaje być zrozumiały.

Background pozwala zapisać kroki wspólne dla kilku scenariuszy w ramach jednej funkcjonalności. Może to być na przykład informacja, że użytkownik jest zalogowany, ma określoną rolę albo znajduje się na konkretnej stronie.

Przykład:

Feature: Zarządzanie koszykiem

Background:
Given użytkownik jest zalogowany
And użytkownik ma pusty koszyk

Scenario: Dodanie produktu do koszyka
When użytkownik dodaje produkt do koszyka
Then koszyk zawiera jeden produkt

Scenario: Usunięcie produktu z koszyka
Given użytkownik ma produkt w koszyku
When użytkownik usuwa produkt z koszyka
Then koszyk jest pusty

Background pomaga ograniczyć powtarzanie, ale nie powinien ukrywać kluczowego kontekstu. Jeżeli scenariusz bez Background staje się niezrozumiały, warto go uprościć albo przenieść część informacji do samego scenariusza. Gherkin ma pomagać w komunikacji, a nie zmuszać czytelnika do skakania po pliku, żeby zrozumieć warunki testu.

Czy Gherkin może być dokumentacją wymagań?

Tak, scenariusze Gherkin działają jako żywa dokumentacja wymagań, bo są precyzyjniejsze niż opis funkcji i czytelniejsze niż dokumentacja techniczna, pod jednym warunkiem: muszą być aktualizowane po każdej zmianie produktu.

Jedną z największych zalet Gherkina jest to, że może pełnić rolę żywej dokumentacji wymagań. Scenariusze zapisane w Gherkinie pokazują, jak system powinien zachowywać się w konkretnych sytuacjach. Są bardziej precyzyjne niż ogólny opis funkcji, ale bardziej czytelne niż techniczna dokumentacja implementacji.

Warunek jest jeden: scenariusze muszą być aktualne. Jeśli zespół nie aktualizuje plików feature po zmianach w produkcie, dokumentacja szybko traci wiarygodność. Wtedy Gherkin zamiast pomagać, zaczyna wprowadzać w błąd.

Dlatego scenariusze Gherkin powinny być częścią procesu pracy z wymaganiami. Warto omawiać je podczas refinementów, przeglądać przed developmentem, aktualizować po zmianach biznesowych i łączyć z testami akceptacyjnymi. Jeżeli zespół korzysta z automatyzacji, wybrane scenariusze mogą stać się wykonywalnymi testami.

Jak Gherkin wspiera testy akceptacyjne?

W testach akceptacyjnych scenariusz Gherkin staje się kryterium akceptacji user story i podstawą odbioru funkcji, bo wymusza konkret tam, gdzie ogólne wymaganie każdy rozumiałby inaczej.

Gherkin bardzo dobrze sprawdza się w testach akceptacyjnych, ponieważ pozwala jasno zapisać, kiedy funkcjonalność spełnia oczekiwania biznesu. Scenariusz może stać się kryterium akceptacji dla user story i podstawą odbioru funkcji.

To szczególnie ważne w projektach, w których wymagania są niejednoznaczne. Jeżeli user story mówi tylko „jako użytkownik chcę filtrować produkty”, każdy może rozumieć to inaczej. Product owner może myśleć o filtrze po cenie, developer o jednym dropdownie, tester o kombinacjach filtrów, a użytkownik o wielu warunkach jednocześnie. Gherkin wymusza konkrety.

Dobrze napisany scenariusz akceptacyjny może pokazać, jakie filtry są dostępne, jak zachowuje się aplikacja po wybraniu wielu filtrów, co dzieje się przy braku wyników, czy filtr pozostaje aktywny po odświeżeniu strony i jak system zachowuje się na urządzeniach mobilnych.

Jeżeli Wasza organizacja realizuje projekty z dostawcami, software houseami albo zespołami zewnętrznymi, Gherkin może pomóc w bardziej precyzyjnym odbiorze systemu. W takim przypadku warto połączyć go z testami odbiorczymi i akceptacyjnymi oraz wsparciem RFP, przetargów i compliance IT.

Jak Gherkin działa w automatyzacji testów?

W automatyzacji scenariusze z plików feature są łączone z kodem kroków, czyli step definitions, a Cucumber wykonuje je jako testy; automatyzować warto tylko scenariusze stabilne, powtarzalne i ważne biznesowo, i nie wszystkie przez interfejs użytkownika.

Gherkin często kojarzy się z automatyzacją testów w Cucumberze. W takim podejściu scenariusze zapisane w plikach feature są łączone z kodem kroków, czyli step definitions. Cucumber interpretuje tekst scenariusza i uruchamia odpowiadający mu kod testowy. Oficjalna dokumentacja Cucumber wskazuje, że Gherkin nadaje strukturę tekstowi w taki sposób, aby narzędzia mogły go zrozumieć i wykonywać jako specyfikację.

Warto jednak pamiętać, że nie każdy scenariusz Gherkin powinien być automatyzowany. Niektóre scenariusze najlepiej sprawdzają się jako dokumentacja biznesowa albo podstawa rozmowy. Do automatyzacji warto wybierać scenariusze stabilne, powtarzalne i ważne biznesowo, szczególnie te, które wspierają regresję lub decyzję release.

Największy błąd polega na automatyzowaniu wszystkiego przez warstwę UI. Jeżeli każdy scenariusz Gherkin uruchamia przeglądarkę, loguje użytkownika i przechodzi przez wiele ekranów, zestaw testów może stać się wolny i kosztowny w utrzymaniu. Część logiki warto sprawdzać przez API, testy integracyjne albo niższe poziomy automatyzacji.

Kiedy warto używać Gherkin?

Gherkin warto stosować tam, gdzie biznes, QA i development muszą uzgodnić oczekiwane zachowanie systemu: w procesach biznesowych, testach akceptacyjnych, regułach walidacji, ścieżkach krytycznych, płatnościach, uprawnieniach i wszędzie tam, gdzie istnieje ryzyko różnej interpretacji wymagań.

Kiedy Gherkin nie jest najlepszym wyborem?

Gherkin jest nadmiarowy przy funkcjach bardzo technicznych, o małej wartości biznesowej albo lepiej opisanych testami jednostkowymi, testami API lub dokumentacją techniczną, i nie ma sensu, gdy nikt poza testerem nie będzie tych scenariuszy czytał.

Jakie są najczęstsze błędy w scenariuszach Gherkin?

Najczęstsze błędy to scenariusze pisane zbyt technicznie, z selektorami i nazwami pól zamiast zachowania, zbyt długie i wielowątkowe, pisane w pojedynkę po zakończeniu developmentu oraz nieaktualizowane po zmianach.

Najczęstszy błąd to pisanie scenariuszy zbyt technicznie. Jeśli scenariusz zawiera szczegóły selektorów, nazwy pól technicznych, klasy CSS albo instrukcje implementacyjne, traci swoją biznesową wartość. Gherkin powinien opisywać zachowanie, nie mechanikę kliknięć.

Drugim błędem jest tworzenie zbyt długich scenariuszy. Jeśli scenariusz ma kilkanaście kroków, kilka rezultatów i wiele danych, trudno go zrozumieć, utrzymać i automatyzować. Lepiej podzielić go na mniejsze przypadki.

Trzecim błędem jest duplikacja kroków. W automatyzacji prowadzi to do bałaganu w step definitions i rosnącego kosztu utrzymania. W dokumentacji prowadzi do niespójności. Jeżeli ten sam proces jest opisany w pięciu miejscach inaczej, zespół szybko przestaje ufać scenariuszom.

Czwartym błędem jest pisanie scenariuszy bez udziału biznesu. Wtedy Gherkin staje się narzędziem QA, a nie wspólnym językiem zespołu. Największa wartość pojawia się wtedy, gdy scenariusze są omawiane wspólnie przed implementacją.

Piątym błędem jest automatyzowanie scenariuszy, które są niestabilne albo często zmieniane. Automatyzacja powinna wspierać regresję i decyzje release, a nie generować codzienny szum w pipeline.

Jak wygląda dobry scenariusz Gherkin dla e-commerce?

Dobry scenariusz e-commerce opisuje warunki, jedną akcję i oczekiwany rezultat z perspektywy klienta i biznesu, na przykład zakup produktu z rabatem, bez szczegółów technicznych interfejsu.

Poniżej przykład scenariusza, który opisuje zachowanie systemu z perspektywy użytkownika i biznesu. Nie skupia się na szczegółach technicznych, ale jasno pokazuje warunki, akcję i oczekiwany rezultat.

Feature: Zakup produktu w sklepie internetowym

Scenario: Złożenie zamówienia przez zalogowanego użytkownika
Given użytkownik jest zalogowany do sklepu
And użytkownik ma produkt dostępny w magazynie w koszyku
And użytkownik ma zapisany adres dostawy
When użytkownik wybiera płatność online
And użytkownik potwierdza zamówienie
Then zamówienie zostaje utworzone
And użytkownik widzi numer zamówienia
And użytkownik otrzymuje potwierdzenie zamówienia na adres email

Ten scenariusz można wykorzystać jako kryterium akceptacji, podstawę testu manualnego albo punkt wyjścia do automatyzacji. Jeżeli sklep internetowy ma wiele wariantów dostawy, płatności i promocji, warto przygotować dodatkowe scenariusze albo Scenario Outline z przykładami.

Jeżeli chcecie zobaczyć szersze podejście do jakości w e commerce, przeczytaj artykuł Testowanie e commerce: jak testować sklep internetowy, by sprzedawał bez przerw. W przypadku krytycznych procesów zakupowych warto też rozważyć testy end to end oraz testy funkcjonalne i regresję.

Czy Gherkin nadaje się do API i systemów bez interfejsu?

Tak, Gherkin opisuje zachowanie, nie ekrany, więc równie dobrze zapisuje scenariusze dla API, backendu, integracji i procesów biznesowych bez klasycznego interfejsu użytkownika.

Gherkin nie musi dotyczyć wyłącznie aplikacji webowych z interfejsem użytkownika. Można go stosować także do opisu zachowania API, systemów backendowych, integracji i procesów biznesowych, które nie mają klasycznego UI.

Przykład scenariusza dla API może wyglądać tak:

Feature: Pobieranie danych klienta przez API

Scenario: Pobranie danych istniejącego klienta
Given istnieje aktywny klient o identyfikatorze 12345
When system wysyła żądanie pobrania danych klienta
Then API zwraca status 200
And odpowiedź zawiera imię, nazwisko i adres email klienta

Taki scenariusz nadal jest biznesowo czytelny, ale może zostać zautomatyzowany przez testy API. To często lepsze rozwiązanie niż testowanie tej samej logiki wyłącznie przez UI, ponieważ testy API są zwykle szybsze, bardziej stabilne i łatwiejsze do uruchamiania w pipeline.

Kto powinien pisać scenariusze Gherkin: tester, analityk czy product owner?

Scenariusze Gherkin dają najwięcej, gdy powstają w rozmowie testera, analityka, product ownera i developera, a nie gdy pisze je tester sam po zakończeniu developmentu; każda z ról wnosi inną perspektywę.

Gherkin najlepiej działa wtedy, gdy nie jest pisany samotnie przez testera po zakończeniu developmentu. Największą wartość daje, gdy scenariusze powstają podczas rozmowy między testerem, analitykiem, product ownerem i developerem.

Tester wnosi myślenie o ryzyku, scenariuszach negatywnych, danych testowych i regresji. Analityk pomaga doprecyzować reguły biznesowe. Product owner odpowiada za wartość i akceptację funkcji. Developer ocenia techniczną wykonalność i wskazuje potencjalne ograniczenia. Wspólnie mogą stworzyć scenariusze, które są jednocześnie zrozumiałe, testowalne i zgodne z potrzebą biznesową.

To podejście szczególnie pomaga w zespołach, które mają problem z błędami wynikającymi z niejasnych wymagań. Jeżeli defekty często pojawiają się dlatego, że każdy inaczej zrozumiał user story, Gherkin może znacząco poprawić komunikację.

Dla testerów i analityków dobrym kierunkiem rozwoju będzie Analiza testowa dla testerów i analityków, Podstawy analizy biznesowej dla testerów oraz Modelowanie wymagań i przypadków użycia UML BPMN.

Jak wdrożyć Gherkin w zespole?

Wdrożenie Gherkina zaczyna się od małego zakresu: jednej funkcjonalności albo kilku user stories z ważnymi kryteriami akceptacji, wspólnego standardu pisania i przeglądu scenariuszy na refinementach, a nie od przepisywania całej dokumentacji.

Wdrożenie Gherkina warto zacząć od małego zakresu. Nie trzeba od razu przepisywać całej dokumentacji. Lepiej wybrać jedną funkcjonalność, jeden proces biznesowy albo kilka user stories, w których kryteria akceptacji są szczególnie ważne.

Na początku zespół powinien ustalić, po co używa Gherkina. Czy celem jest lepsza komunikacja z biznesem, precyzyjniejsze kryteria akceptacji, testy akceptacyjne, automatyzacja regresji, czy dokumentacja zachowania systemu. Bez jasnego celu Gherkin szybko stanie się kolejnym formatem dokumentu.

Następnie warto ustalić standard pisania scenariuszy. Scenariusze powinny być krótkie, biznesowe, jednoznaczne i możliwe do weryfikacji. Zespół powinien też zdecydować, które scenariusze będą automatyzowane, a które pozostaną dokumentacją lub podstawą testów manualnych.

Najczęstsze pytania o Gherkin

Co to jest język Gherkin?

Gherkin to język opisu scenariuszy używany najczęściej w BDD i testach akceptacyjnych. Pozwala zapisywać zachowanie systemu w czytelnej strukturze Given, When, Then, dzięki czemu scenariusze są zrozumiałe dla biznesu, testerów i programistów.

Do czego służy Gherkin w testowaniu?

Gherkin służy do opisywania scenariuszy testowych, kryteriów akceptacji i zachowania aplikacji. Może być używany jako dokumentacja wymagań, podstawa testów manualnych lub punkt wejścia do automatyzacji w narzędziach takich jak Cucumber.

Co oznaczają Given, When i Then?

Given opisuje warunki początkowe, When opisuje akcję użytkownika lub zdarzenie, a Then opisuje oczekiwany rezultat. Taka struktura pomaga oddzielić kontekst, działanie i wynik scenariusza.

Czy Gherkin jest tylko dla testerów automatyzujących?

Nie. Gherkin jest przydatny także dla testerów manualnych, analityków, product ownerów, developerów i QA leadów. Automatyzacja jest tylko jednym z możliwych zastosowań. Najważniejszą wartością Gherkina jest poprawa komunikacji o wymaganiach i zachowaniu systemu.

Czym różni się Gherkin od Cucumbera?

Gherkin to język zapisu scenariuszy, a Cucumber to narzędzie, które może wykonywać scenariusze zapisane w Gherkinie przez powiązanie ich z kodem testowym. Gherkin opisuje zachowanie, a Cucumber pomaga uruchamiać testy oparte o ten opis.

Kiedy warto używać Scenario Outline?

Scenario Outline warto stosować wtedy, gdy ten sam scenariusz trzeba sprawdzić dla różnych zestawów danych. Dzięki sekcji Examples można uniknąć pisania wielu podobnych scenariuszy i zachować czytelność testów.

Jak pisać dobre scenariusze Gherkin?

Dobre scenariusze Gherkin powinny być krótkie, konkretne, biznesowe i możliwe do weryfikacji. Powinny opisywać zachowanie systemu, a nie techniczne szczegóły kliknięć lub implementacji. Najlepiej tworzyć je wspólnie z biznesem, QA i developmentem.

Czy każdy scenariusz Gherkin trzeba automatyzować?

Nie. Nie każdy scenariusz powinien być automatyzowany. Do automatyzacji najlepiej wybierać stabilne, powtarzalne i ważne biznesowo scenariusze, które wspierają regresję lub decyzję release. Część scenariuszy może pozostać dokumentacją albo podstawą testów manualnych.

Powiązane na blogu Quality Island

• Jak napisać dobry scenariusz testów
• Testy end to end: jak sprawdzić, czy cały system działa od początku do końca
• Shift left testing: co to jest, zalety, wady i jak wdrożyć krok po kroku
• Jak napisać plan testów: kompletny przewodnik
• Testowanie w Scrumie: kompleksowy przegląd

Pełna lista źródeł

• Cucumber, Gherkin Reference, oficjalna dokumentacja składni
• Cucumber, Behaviour-Driven Development
• ISTQB Glossary, hasło behavior-driven development
• Przykłady scenariuszy: opracowanie własne Quality Island na potrzeby szkoleń z analizy testowej