Gherkin is een syntax die door zowel business als it te begrijpen is. Hiermee wordt de kloof die er vaak tussen beiden is verkleind. En dat draagt bij aan de ontwikkeling van kwalitatief betere software. De toepassing van Gherkin lijkt dus veelbelovend en makkelijk, maar is dat wel zo? In dit artikel komen de vijf valkuilen aan bod die voorkomen bij het schrijven van specificaties en acceptatietests in Gherkin.
Gherkin is niets meer dan gewone tekst die volgens een bepaalde structuur het gedrag van een systeem beschrijft. Zonder daarbij in detail te treden over hoe dat gedrag geïmplementeerd is of moet worden.
Simpel voorbeeld:
Scenario: Multiple Givens
Given one thing
And another thing
When I open my eyes
Then I see something
But I don’t see something else
Valkuil 1: Het onvoldoende betrekken van de business
Wanneer de business onvoldoende betrokken is bij het opstellen van de requirements in Gherkin dan is de kans aanwezig dat de acceptatieperiode langer duurt. Bij een acceptatieperiode van (tijdens de sprint) geautomatiseerde tests kan het zijn dat niet het juiste is getest en er in productie vervolgens fouten ontstaan. Met handmatige acceptatie van de software begrijpt de business niet altijd wat er in de requirements staat en kan het zijn dat gedurende die periode meer issues (bugs) ontstaan. Door samen met de business de requirements zo veel mogelijk als Gherkin scenario’s te beschrijven, is de business al in een vroeg stadium betrokken. Met het opstellen van acceptatiecriteria in Gherkin scenario’s zijn user stories namelijk ‘smart’–er en voor alle stakeholders leesbaar. Hierdoor ontstaat bewustwording en betrokkenheid. Dat geeft de business een beter gevoel over de kwaliteit van de opgeleverde software. De scenario’s zijn door met Gherkin te werken bovendien te gebruiken voor geautomatiseerde acceptatietests en zo is de acceptatieperiode te verkorten.
Valkuil 2: Het beschrijven van acties in plaats van gedrag
Het beschrijven van acties in plaats van gedrag in de Gherkin scenario’s kan zorgen voor een langere acceptatieperiode en meer issues in die periode.
Fout: Het beschrijven van acties in een scenario
Scenario Show welcome message
Given I have a user called ‘Peter’
And I have opened the login page
When I enter my login name
And I enter my password
And I press the login button
Then I see a welcome message
Goed: Het beschrijven van gedrag in een scenario
Scenario Show welcome message
Given I have a user called “Peter”
When I log on
Then I see a welcome message
Het eerste voorbeeld is voor de business niet of minder goed leesbaar dan het tweede voorbeeld, omdat het tweede voorbeeld beter scanbaar is. Door de formuleringswijze van het eerste voorbeeld voelt de business zich minder betrokken bij het scenario. Hierdoor is de business minder gemotiveerd om samen nieuwe (acceptatie) scenario’s op te stellen. In voorbeeld twee is voor zowel de business als de it-afdeling duidelijk wat het doel van de test is en wat er mee bereikt wordt. Daarnaast zijn de stappen uit het scenario beter te onderhouden en te hergebruiken. Dit voorkomt in de toekomst problemen bij een gewijzigde user interface, omdat dan alleen de achterliggende code herschreven hoeft te worden en niet het hele scenario.
Valkuil 3: Te complex door meerdere Given’s/When’s/Then’s
Maak een scenario geschreven in Gherkin niet te complex. Het kan voorkomen dat enkele Given’s en Then’s nodig zijn, maar probeer het gebruik van meerdere When’s te voorkomen. Schrijf liever meerdere simpele scenario’s die uit gaan van een enkele actie, dan enkele complexe en slecht leesbare scenario’s die uit gaan van meerdere acties.
Valkuil 4: Verkeerd of meertalig taalgebruik in een scenario
Gherkin kan in verschillende talen geschreven worden. Denk vooraf goed na en bepaal in welke taal de scenario’s te gaan schrijven. Gebruik vervolgens de juiste termen uit die taal. Wanneer er is gekozen voor Engels, gebruik dan Given/When/Then. Wanneer er is gekozen voor Nederlands, gebruik dan Gegeven/Wanneer/Dan. Verkeerd taalgebruik in een scenario – bijvoorbeeld door slechte beheersing van de gekozen taal – kan ervoor zorgen dat een andere persoon het scenario verkeerd interpreteert. Hierdoor ontstaan fouten. In het algemeen wordt gekozen voor de taal die de business hanteert. Zodat zij de terminologie niet hoeven te vertalen of twee talen door elkaar gebruiken, zoals in onderstaande voorbeelden:
Fout:
Given a user with status ‘Weduwe’
When the user opens the pensioenoverzicht
Then partnerpensioen is mentioned apart
Goed:
Gegeven een gebruiker met status ‘Weduwe’
Wanneer de gebruiker het pensioenoverzicht opent
Dan staat het partnerpensioen apart vermeld
Valkuil 5: Gherkin en refactoring
Bij elk goed softwareontwikkelingsproces is refactoring (herstructureren) van de code een belangrijk onderdeel van het proces. Net als dat je de code van de software refactored, is refactoring van de Gherkin-scenario’s ook aan te raden. Het komt de leesbaarheid en onderhoudbaarheid ten goede. Let op dat wanneer er sprake is van scenario refactoring, de aanpassingen ook doorgevoerd moeten worden in de achterliggende code van het scenario. Dit geldt ook voor aanpassingen in de code van de software. Elke keer als deze code verandert, is het ook belangrijk om te kijken of het bijbehorende scenario ook aangepast dient te worden. Refactoring werkt dus beide kanten op!
Zelf de slag met Gherkin?
Het vergt de nodige oefening om niet alleen syntactisch correcte Gherkin, maar ook praktisch werkbare scenario’s te schrijven. Maar goed geschreven scenario’s zijn voor alle stakeholders leesbaar, wat zorgt voor betrokkenheid. Betrek de business bij het opstellen van de testscenario’s voor wederzijds begrip en inzicht in de businesswens. Denk vooraf goed na over wat je opschrijft. Beschrijf gedrag en houd de scenario’s beknopt. Bekijk op een later moment de scenario’s en refactor indien nodig.
Veel succes met het opstellen van jouw scenario’s in Gherkin!
Rob den Broeder, testconsultant bij Bartosz ICT
