Tijdens de Test Automation Day 2018 te Rotterdam, woonde ik onder andere twee seminars bij over Gherkin Script. Gherkin Script is de manier waarop de testautomatiseringsstappen in het Engels / Nederlands (ofwel de businesstaal) worden opgesteld, zodat beter te begrijpen is wat de testautomatisering doet. De eerste sessie gaf Bas Dijkstra (ontestautomation.com) en de tweede Anne Colder (PGGM).

 

Mijn best practices die ik hieruit meenam naar de praktijk:

1. Wees je bewust van de doelgroep
Wie zijn de lezers en/of gebruikers?

Gherkin is een communicatietool, dus gebruik ook dusdanig: formuleer volzinnen en val niet in de valkuil door enkele steekwoorden te gebruiken, die (later) niemand meer begrijpt.
Goed uitgangspunt kan zijn: ‘shared understanding’ onder de Three amigo’s:

1. De developer weet wat hij moet bouwen
2. De Tester weet wat hij moet testen
3. De PO/Businessvertegenwoordiger weet wat hij kan verwachten

Mijn visie hierop is dat de PO niet snel de Gherkin code meeleest en voornamelijk de (Jira) stories leidend zijn. Echter voor de tester, developer en beheerder kan Gherkin de ideale uitkomst bieden laagdrempelig en snel inzicht te krijgen in wat de applicatie doet. Wanneer de lezers enkel het developmentteam zijn, bestaat geen bezwaar tegen technischer opgesteld Gherkin. Edoch, niet té technisch. Als men de informatie later opnieuw bekijkt en dan nog een vertaalslag tussen techniek en praktijk moet maken, kan dat vertraging opleveren.

2. Verleg de focus van “hoe?” naar “wat?”

Een veel voorkomende valkuil is de focus teveel te leggen op de technische implementatie. Regelmatig beschrijft Gherkin meer “hoe” een bepaalde functionele wens in te vullen. Moet later, bijvoorbeeld een Change Request doorgevoerd, komen ongetwijfeld vragen over bepaalde testwijzen.

Voor de leesbaarheid en begrijpelijkheid is het veel beter meer het “wat” te beschrijven. Welke stappen moet de eindgebruiker functioneel doorlopen om zijn functionele eindwens te vervullen? Val niet in de valkuil de tekst technischer te maken om de herbruikbaarheid van de code achter Gherkin te verhogen. Werk eventueel met een tussenlaag of stop de herbruikbaarheid/technische oplossing van de test in de (hulp)functies achter de Gherkinstappen en dus niet in de stappen zelf.

Mijn visie hierop is zoek naar balans. Ja, soms zijn de scenario’s te technisch geformuleerd en zodoende voor verbetering vatbaar. Anderzijds biedt deze opzet vaak laagdrempelige mogelijkheden voor het runnen van de testscenario’s in debug-mode. Wat gebeurt er bij het eenvoudig wijzigen van een bepaalde variabele in Gherkin. Zeker als er eenmaal een robuuste basis staat van de op Gherkin gebaseerde testcases, komen de meeste bevindingen niet meer uit de rode kruisjes van falende testen. Deze komen eerder uit testen die initieel slagen, maar wanneer je er even iets dieper induikt (bijvoorbeeld in debug-mode) kom je pas echt interessante ‘onverwachte’ dingen tegen.

3. Maak de Gherkin documentatie leidend

Specificaties blijven overzichtelijk door deze op één plaats bij te houden. Is het besluit de documentatie in Gherkin vast te leggen, houdt dan niet ook nog eens de documentatie bij op een shared platform en/of in lijvige documentatie, die snel kan verouderen.

Mijn visie hierop is dat het soms toch erg lastig blijkt de scenario’s en stappen overzichtelijk en leesbaar te houden. We willen toch nog nét een extra regeltje of informatie meegeven, met name ook om de samenhang tussen scenario’s en features vast te leggen. Een oplossing is niet het scenario of de stappenomschrijving langer (dus minder leesbaar) te maken, maar de requirements meer samen te vatten in de Featurebeschrijving. De eerste 3 regels beschrijven de kern van de Feature en de regels eronder dienen ter ondersteuning om meer over de feature te weten. Wil je echt de diepte in, lees dan de scenario’s met bijbehorende steps. Zo belandt alle documentatie op één (logische) plaats.

4. Draag zorg voor het leesbaar houden van scenario’s:

Maak gebruik van modellen. Het leesbaar houden van testscenario’s is soms een behoorlijke uitdaging. Zeker als bestaande testen groeien door nieuwe aanvullende requirements. Hierdoor bestaat het risico dat bijvoorbeeld scenario-outlines en data tabellen worden uitgebreid. Om dit overzichtelijk te houden, is het gebruik van modellen handig. Zo blijft de datatabel beperkt tot het melden van enkel de data die echt relevant zijn voor het betreffende scenario.  Alle andere noodzakelijke, maar niet concreet relevante data, om het functionele requirement helder te maken, kan op de achtergrond gezet. Kortom specificeer enkel de relevante data die overschreven moet worden in het Gherkin script. Bijkomend voordeel is dat, indien iets blijvend moet veranderen in de uitgangspositie, dit enkel in het model gewijzigd hoeft te worden en niet in elk scenario afzonderlijk.

Voorbeeld: Model

Voorbeeld: Situatie gebruik voor en na gebruik van bovenstaand model

Mijn visie hierop is dat deze toepassing helaas nog weinig plaatsvindt. Wel zie ik steeds vaker de meerwaarde hiervan in. We hergebruiken steeds meer test-stappen en deze bevatten vaker onnodige data die voor de desbetreffende test niet direct relevant zijn. De leesbaarheid kan dus nog aanzienlijk verbeterd.

5. Ga bewust om met ‘verborgen’ testdata

Voor het leesbaar houden van testscenario’s worden de given/when/then stappen vaak kort, maar krachtig, geformuleerd. Althans dat is wenselijk de scenario’s leesbaar te houden. Hierbij is het echter wel van belang bewust te zijn van verborgen requirements in de testdata. Stel een bepaalde complex samengestelde query moet gecontroleerd. Dan is een mogelijkheid in de when-step te zeggen ‘When customer ordered at least 5 times, last 5 years, for at least 100.000 Euro for each order, and always paid within the payment term ’ gevolgd door ‘Then the customer will receives a discount voucher’. The when-step kan dan ook kort, maar krachtig zijn: ‘When customer is loyal’. Wellicht is dit een te simpel voorbeeld en is dit ook op te lossen door een datatabel of aparte then-steps te formuleren. Anderzijds kan dat teveel afleiden en wanneer 1 van de requirements verandert, is het gemakkelijker die in een ‘model’ aan te passen, dan in elk afzonderlijk scenario dat de stap van de ‘loyal customer’ hergebruikt. Stel hier dus wederom de vraag: wie is je publiek en kan het geen kwaad bepaalde requirements iets dieper in de code weg te zetten?

Mijn visie hierop is dat wanneer zinnen te lang worden in scenario’s en stappen, dit vaak al aanleiding is de stap of het gehele scenario eens beter te bekijken. Vaak is dan de conclusie dat we hier meer dan één requirement testen.

Zijn beide requirements belangrijk genoeg? Dan is dit een goede reden het scenario op te splitsen. Je wilt immers niet altijd het requirement generaliseren of dieper in de code van het model wegstoppen.

Hierop ben ik echter wel kritischer geworden. Zeker nu doorlooptijden vaker toenemen door de hoeveelheid reeds geautomatiseerde scenario’s. Wanneer een verborgen requirement minder belangrijk blijkt, besluiten we steeds vaker deze in debug-modus mee te checken, en waar mogelijk in een (t.o.v. de systeemtesten) relatief snellere unittest af te vangen. Zo waarborgen we zowel de kwaliteit en lopen niet op tegen alsmaar langere doorlooptijden van relatief trage systeemtesten. Ook hier is het dus zoeken naar een goede balans.

Als toegift nog een tip (uit een van de andere interessante sessies op de Test Automation conferentie): Ga eens in de zoveel tijd na of de bestaande testen nog relevant zijn. Zo worden bepaalde requirements in de loop van de tijd minder belangrijk of reeds in andere scenario’s voldoende afgedekt. Toon daarom lef door af en toe testen te schrapen. Doe je dit niet ontstaat een steeds groter groeiend probleem.  De doorlooptijd van het runnen van alle testen duurt langer en langer, wat het snel schakelen en het continuous deployment onnodig in de weg kan gaan zitten.

Benieuwd naar nog meer inspiratie en of een sfeerimpressie van de conferentie kijk dan ook eens naar de blog van Jose Pita. Hij is één van de internationale bezoekers waarmee ik na afloop nog even sprak tijdens de borrel.

Lopen jullie tegen vergelijkbare uitdagingen aan? Laat gerust wat van je horen, wie weet kunnen we van elkaar leren!