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: 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 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 primary keywords are:Feature - The purpose of this keyword is to provide a high-level description of a software feature, and to group related (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 (or Scenario) - This is a concrete example that illustrates a business rule. It consists of a list of - steps are used to describe the initial context of the system - the scene of the scenario. It is typically something that happened in the - 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 structuredBackground - it is common Given steps for more than one FeatureScenario Outline (or Scenario Template) - The Scenario Outline keyword can be used to run the same Scenario multiple times, with different combinations of [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 listAnd user clicks on checkbox in selected itemAnd user clicks on three dots iconAnd user choose Change cityAnd user set up new city nameWhen user clicks on Update selected itemsThen modal is closedAnd in selected items city is changedNie 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 profileBackground: 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 profileScenario: 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 thisJak 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