Ogórek ogórek zielony ma garniturek :)
3 listopada bieżącego roku odbyło się webinarium organizowane przez nasz firmowy dział QA. Kto nie był, a chciałby posłuchać lub był a chciałby sobie przypomnieć o czym rozmawialiśmy to zapraszamy tu . W trakcie wystąpienia poruszane były tematy odnośnie procesu testowania, aplikacji mobilnych, testów bezpieczeństwa, automatyzacji testów oraz analizy biznesowej. W trakcie jednej z wypowiedzi na temat tworzenia dokumentacji projektowej, wspomniano o wykorzystaniu języka Gherkin w trakcie pisania User Stories. Ów temat spowodował dyskusję wśród naszych słuchaczy. W trakcie trwania nie mieliśmy wystarczająco dużo czasu aby w pełni odpowiedzieć, dlatego też postanowiliśmy napisać ten artykuł :).
Wróćmy na chwilę do owej wypowiedzi na temat dokumentacji. Jak wiemy nikt jej nie lubi pisać ;) ale jednak jakaś musi powstać aby dobrze zbudować system. Podstawowym elementem jaki możemy uznać za dokumentacje to User Story. W TSH dla ustandaryzowania formy opisu wykorzystujemy wewnętrzny szablon tzw. opis Kuśmierza - Polaka, po więcej szczegółów odsyłamy tutaj: https://tsh.io/blog/how-to-write-good-user-stories-in-software-development/ Jednym z ważniejszych elementów tego szablonu jest opis Normal flow i ewentualnie Alternative flow. Do opisu przebiegu procesów jakie mają zaistnieć po zaimplementowaniu tej funkcjonalności wykorzystujemy składnie Given - When - Then, która pochodzi właśnie języka Gherkin.
Skąd wziął się ten język w świecie tak technicznym jak IT? Składnia Given - When - Then swoje początki zawdzięcza pewnemu podejściu do tworzenia oprogramowania, a mianowicie Behaviour Driven Development (BDD), które powstało na bazie is a synthesis and refinement of practices stemming from Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD) [1]. Jak pisze twórca tego podejścia - Dan North, BDD powstało w odpowiedzi na ciągle powtarzające się pytania: I kept coming across the same confusion and misunderstandings. Programmers wanted to know where to start, what to test and what not to test, how much to test in one go, what to call their tests, and how to understand why a test fails [2].
W trakcie prac nad nowym podejściem, Dan North zderzał swoje pomysły, z różnymi współpracownikami. W pewnym momencie odkryli oni, że nowa forma zapisu testów jest zbliżona do języka wykorzystywanego przy zbieraniu wymagań. Cel jaki im przyświecał to stworzenie takiego słownictwa, które będzie zrozumiałe dla wszystkich interesariuszy. Zainspirowani opublikowanym artykułem odnośnie Domain-Driven Design wzięli pod lupę format zapisu User Story i jak to opisują: discovering what every agile tester already knows: A story’s behaviour is simply its acceptance criteria – if the system fulfills all the acceptance criteria, it’s behaving correctly; if it doesn’t, it isn’t. So we created a template to capture a story’s acceptance criteria [2]. I tak właśnie powstał wzór składni Given-When-Then.
Spójrzmy w takim razie, z czego on się składa. Posłużę się tutaj dokumentacją z cucumber.io:
The primary keywords are:
Feature - The purpose of this keyword is to provide a high-level description of a software feature, and to group related scenarios.
Rule (as of Gherkin 6) - The purpose of this keyword is to represent one business rule that should be implemented. It provides additional information for a feature. A Rule is used to group together several scenarios that belong to this business rule.
Example (or Scenario) - This is a concrete example that illustrates a business rule. It consists of a list of steps.
Given - steps are used to describe the initial context of the system - the scene of the scenario. It is typically something that happened in the past.
When - steps are used to describe an event, or an action. This can be a person interacting with the system, or it can be an event triggered by another system.
Then - steps are used to describe an expected outcome, or result.
And, But for steps (or *) - used to write description in more fluidly structured
Background - it is common Given steps for more than one Feature
Scenario Outline (or Scenario Template) - The Scenario Outline keyword can be used to run the same Scenario multiple times, with different combinations of values.
Examples [3]
Teoria, teorią ale trzeba zastosować ją w praktyce ;). Posłużę się tutaj dwoma przykładami. Jeden z nich pochodzi z naszego projektu i dotyczył nadania uprawnień użytkownikowi do zmiany danych, w tym przypadku miasta:
Given user is on list
And user clicks on checkbox in selected item
And user clicks on three dots icon
And user choose Change city
And user set up new city name
When user clicks on Update selected items
Then modal is closed
And in selected items city is changed
Nie jest to rozbudowany scenariusz ponieważ dotyczy tylko jednego elementu, a szerszy opis tej funkcjonalności znajduje się w naszym wzorze opisu User Story. W tym przypadku chodziło nam jedynie o opisanie tzw. zielonej ścieżki użytkownika. Natomiast jeżeli mielibyśmy zamiar opisać wiele scenariuszy dotyczących jednej funkcjonalności, wtedy należałoby podejść do tego tak jak przykład z ProductVision:
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
Jak możemy zauważyć w drugim przykładzie opisano więcej niż jeden scenariusz. W takim przypadku, gdy występują elementy wspólne, tak jak tutaj - trzeba być zalogowanym, wtedy możemy wyciągnąć ten element powyżej wszystkich scenariuszy i umieścić go w background.
No to dobra. Wiemy już skąd wziął się wzór i język Gherkin. Wróćmy jednak do naszego webinaru wspomnianego na wstępie tego artykułu. Jak już wcześniej wspomniałem, podczas wypowiedzi odnośnie zastosowania tego języka wywiązała się dyskusja. Chciałbym przedstawić swój punkt widzenia odnośnie Gherkin.
Pracując jako Analityk Biznesowy ale również jako QA bardzo często pracujemy na granicy pomiędzy Biznesem a zespołami technicznymi. Bardzo często spotykałem się z sytuację, że osoba oddelegowana do prowadzenia projektu po stronie KLienta nie zawsze ma wiedzę techniczną i posługuje się “mową potoczną” w trakcie opisywania swoich potrzeb. W takiej sytuacji zaprezentowanie korzyści z implementacji danej funkcjonalności lub omówienie ścieżki, ścieżek jakie będzie przechodził użytkownik końcowy wykorzystanie struktury Given-When-Then jest bardziej zrozumiały i czytelny dla naszego Biznesu. W wielu publikacja autorzy również mocno zwracają na to uwagę. Potwierdzenia można znaleźć u Dana North [2], Michał Bartyzel [4] czy też na stronie ProductVision [5].
Osobiście Gherkina wykorzystuję również w analizowaniu zadań i sprawdzeniu czy zostały omówione różne ścieżki lub czy znamy warunki końcowe po wykonaniu zadanej akcji. Tworzenie kolejnych scenariuszy przypadków użycia z zastosowaniem języka Gherkin pomaga w dokładniejszym przeanalizowaniu zadań jak również w prezentowaniu tych zadań Biznesowi. Czemu? Nie zawsze jest tak, że osoba od strony Klienta posiada wystarczającą wiedzę techniczną aby móc dyskutować z deweloperami na temat kodu. Zdarza się, że osobą oddelegowaną do prowadzenia naszego projektu będzie osoba bez wiedzy technicznej, pochodząca np. z działu customer service.
W takim przypadku prezentowanie zadań z punktu widzenia rozwiązania technologicznego nie sprawdza się. Wtedy przemawiają obrazy i tu można posłużyć się mockup’ami, designami lub kartką i ołówkiem ;) ale również świetnie sprawdza się właśnie język Gherkin. Dzięki temu w jasny sposób mamy opisane jakie kolejne kroki będzie wykonywał nasz użytkownik aby zrealizować postawione przed nim zadanie. Zdarzyło się już parokrotnie w mojej historii, że większą wartością dla KLienta było przeczytanie kolejnych kroków jakie będzie wykonywał w swoim systemie i zobrazowanie sobie tego niż głęboka dyskusja z deweloperami co będzie się działo poniżej wykonywanych akcji.
Język Gherkin nie jest wykorzystywany tylko do zbierania i opisywania wymagań aby pomóc zrozumieć wszystkim zainteresowanym co będzie się działo w danej funkcjonalności. Bardzo często kolejne scenariusze piszę się z myślą o automatyzacji testów właśnie opisanych ścieżek. Jakie są tego korzyści a jakie trudności? Na te i inne pytania odpowieTomasz Górskiw swoim artykule :) Miłego czytania i jedzcie dużo warzyw ;) szczególnie ogórków, gorąco polecam.
Bibliografia:
[1] https://www.agilealliance.org/glossary/bdd/#q=~(infinite~false~filters~(postType~(~'page~'post~'aa_book~'aa_event_session~'aa_experience_report~'aa_glossary~'aa_research_paper~'aa_video)~tags~(~'bdd))~searchTerm~'~sort~false~sortDirection~'asc~page~1)
[2] https://dannorth.net/introducing-bdd/
[3] https://cucumber.io/docs/gherkin/reference/
[4] https://www.michalbartyzel.pl/po-co-mi-gherkin/
[5] https://productvision.pl/2016/analiza-wymagan-produktowych-gherkin/
Komentarze
Prześlij komentarz