Test automation inzetten in een BDD context. Business gebruikers aanhaken bij technische TA inspanning. Logging en rapportage leesbaar maken/houden voor niet-technische gebruikers.

1. TA in een BDD context
Christian Bos | 03–03–2021

2. Even voorstellen…
Christian Bos
Test automation developer
• 3+ jaar bij Immune-it
• > 10 jaar bij Sogeti
• Test automation specialist && trainer
• Java && Python developer
• (Agile) coach && test specialist

3. Hoe we het normaal eigenlijk doen…
• In elke stap zit een vertaalslag
• Elke discipline zijn ‘eigen waarheid’
(code vs documentatie)

4. “Maatregelen”
• Test-Driven Development (TDD)
• eerst een test schrijven, deze laten falen
• daarna pas code applicatie schrijven
• Test Automation
• automatisering van de testuitvoer
• Continuous Integration en Delivery (CI/CD)
• automatische pipelines
• scheduling van nightly builds en regressietest
• DevOps
• ontwikkelteam (dev) vs beheerteam (ops)

5. Samenwerken en communiceren…

6. Hoe het zou kunnen gaan…
• Gezamenlijk beeld van en
consensus over requirements en
implementatie
• Vastleggen requirements in
leesbare taal
• Deze vastlegging is de ‘enige
waarheid’

7. Specification by example
• Duidelijke en leesbare beschrijving (kort)
• alleen (droge) tekst vaak niet duidelijk genoeg
• beschrijven van ‘key examples’ (edge-cases)
• voorkomen van slechte aannames
• Geen aparte testbasis (oracle) voor TA
• voorbeelden in specificatie zijn uitvoerbaar
• rapportage 1 op 1 tegen specificaties
• Documentatie altijd up-to-date

8. Voordelen en uitdagingen van BDD
Voordelen
• BDD bevordert samenwerking en
communicatie (consensus)
• Shift-left mogelijk door vroegtijdig
betrekken tester(s)
• Bevordert kwaliteits-mindset (TDD)
Uitdagingen
• Vereist goede samenwerking en
communicatie
• Veronderstelt Agile werkwijze
• Lijkt langzamer te gaan

9. Gherkin
• given (precondities)
• when (actie)
• then (uitkomst)
• and
• but
• korte scenario’s
• beschrijving van systeemgedrag
• Leesbaar voor iedereen (niet technisch)

10. Gherkin – do’s & don’ts

11. Gherkin – do’s & don’ts
DO
• één scenario, één ‘behaviour’
• in derde persoon tegenwoordige tijd
• definieer de context
• scenario vertelt de intentie van de
feature
DON’T
• procedurele stappen beschrijven
• implementatie beschrijven
• configuratiewaarden
• grote scenario’s met (te) veel stappen

12. Opzet TA script
• Data-driven script
• veel testcases (gevoed vanuit data file)
• relatief slecht leesbare rapportage (for-loops)
• positief vs negatief testen
• Keyword-driven script
• specifieke keywords voor teststappen en assertions
• technische benaming keywords
• Process-driven script
• high-level keywords
• naamgeving keywords scenario-gebaseerd
• complexiteit weg-geabstraheerd in keywords
business-scenario’s (e2e)
detail-functionaliteit

13. Randvoorwaarden (TA)
• Test(automatiserings)strategie
• wees heel kritisch: wat wel en vooral wat niet automatiseren
• kies juiste insteek bij automatiseren (details vs overall-proces testen)
• durf bestaande testcases weg te gooien!
• Gedeelde TA-strategie
• Stakeholders zijn betrokken bij alle TA inspanningen
• QA is verantwoordelijkheid van het gehele team
• hoe rapporteren (maak logging en rapportage leesbaar en herleidbaar)

14. Randvoorwaarden (proces)
• Agile requirementsproces
• gezamenlijk communiceren (consensus)
• acceptatiecriteria
• Test-driven development (TDD)
• developers schrijven liever code dan tests ☺
• Continuous integration en deployment (CI/CD)
• run testcases gescheduled
• checkin git gebruiken als trigger voor TA