Deel 7 - De factor mens: competenties, rollen, taken en organisatie

Totnutoe hebben we het vooral over tools en methodes gehad. En nu is het hooooog tijd voor de grootste succesfactor: de factor mens.

Maar eerst iets over Cucumber en tools

Aflevering 5 ging over de vier manieren voor het bouwen van scripts: Opnemen, Componeren, Programmeren of Genereren uit een model. Tom van den Berg komt met de volgende vraag: wij doen aan BDD en leggen de specs vast in Cucumber en daarmee runnen we de geautomatiseerde testen. Welke van jouw vier methoden past daar eigenlijk bij? Het antwoord is: een combinatie van genereren en programmeren. Dat moet ik even toelichten: om te beginnen: Cucumber is basically een specificatietool en geen test tool. In Cucumber leg je met het give-when-then Gherkin formaat het gedrag vast in zogenaamde feature files. Dat is als het ware je model, de beschrijving van het gedrag van het te bouwen en te testen systeem. Maar daarmee heb je nog geen geautomatiseerde testset en Cucumber runt NIET zelf de tests. Hetzelfde geldt voor SpecFlow (Cucumber voor .NET) en Fitnesse.
Je hebt vervolgens programmeurs nodig die met een zelfgebouwde testrunner of met b.v. JUnit de zogenaamde Steps programmeren die van de Given-When-Then specificaties automatische testen maken. Met wat ze ook wel de glue noemen plak je als het ware de feature files aan de steps. Daarna kun je de Cucumber testen geautomatiseerd uitvoeren, maar Cucumber is dus niet zelf de testrunner. Uiteraard zijn er allerlei frameworks, zoals Behat die daarbij helpen zodat je het hele bouwwerk niet helemaal van scratch hoeft te bouwen, daarom heten ze ook frameworks.


Ik zei twee dingen, de tweede vraag die ik van verschillende kanten krijg is namelijk: ik kom er niet uit, help me, vertel me wat momenteel de beste tools in de markt zijn. Een onmogelijke vraag natuurlijk want het aanbod is enorm en ze zijn allemaal ergens heel goed in. Maar maak je geen zorgen, ik trek gewoon de stoute schoenen aan en zal in de volgende aflevering een aantal namen noemen die wat ons betreft anno nu op je longlist moeten staan. Mét disclaimer, want dit wordt uiteraard slechts een momentopname.
Dat waren de twee dingen vooraf. Nu snel terug naar ons thema:

De factor mens: competenties, taakverdeling en organisatie

Een succesvolle strategie voor geautomatiseerd testen staat of valt met mensen die samen de technische én organisatorische uitdaging aangaan. Dat vraagt om samenwerking tussen excellente technici, professionele testers én de ‘klant': gebruikers, beheerders en wellicht meer stakeholders. Aan die drie kanten moet er bewustwording en draagvlak zijn en moet er tijd worden vrijgemaakt. Want op termijn ga je tijd besparen, maar in het begin moet je investeren. In goed Nederlands: de kost gaat voor de baat uit.
Hoe hoger in de testpiramide, hoe belangrijker de samenwerking. Aan de onderkant van de piramide kunnen goede ontwikkelaars nog tamelijk zelfstandig ‘de goede dingen goed bouwen' en goed unit testen. ‘technische excellentie' is niet voor niets één van de 12 agile principes. ‘Quality Built In' noemen we dat tegenwoordig, een belangrijk principe in SAFe, het Scaled agile framework. Quality Built In vanaf het eerste begin!

Die eerste kwaliteitsklap is dus een daalder waard en de slagers, de developers, hebben hierin een belangrijke zelfstandige rol! Maar een slager alleen is ook maar een slager alleen en meer naar de bovenkant van de testpiramide is de samenwerking met testers en de klant doorslaggevend. Hier kunnen we plezier hebben van het Slager-Keurmeester-Klant model uit de SmarTEST praktijk.


Voor geautomatiseerd testen is de bijdrage van deze rollen als volgt:

  1. De Slager - Die keurt eigen vlees, heel goed! De slager is dan de ontwikkelaar in een technische ‘test automation engineer' rol. Deze softwarespecialist verzorgt de unit testen en programmeert de technisch moeilijke gevallen in de gebruikerstesten. De slager kent zowel de techniek van de applicatie als van de test tooling en de infrastructuur, zo nodig geholpen door technisch beheerders. Als ik slager zeg bedoel ik ook de vegetarische slager.
  2. De Keurmeester - Dat is een tester of beheerder in een testrol met als specialisme geautomatiseerd testen. Hij bepaalt wat geautomatiseerd kan worden en zet business scenario's om in robuuste geautomatiseerde scripts. Hij beheerst het testambacht en de testtechnieken en heeft professionele ontwerp- en versiebeheercompetenties. Hij kent de tools, is niet bang voor code en bouwt zelfstandig 80% van de scripts. By the way: Als ik hij zeg bedoel ik ook zij
  3. De klant - De klant is de gebruiker, veelal vertegenwoordigd door een product owner of business analist. Zij beschrijft in gewone taal de business scenario's die geautomatiseerd moeten worden. Zij kent het business proces en de risico's en stelt vast of de geautomatiseerde testen voldoende zekerheid bieden en welke aanvullende handmatige ketenacceptatietesten nog nodig zijn. By the way, nou ja, je snapt hem wel.

Die hele SKK driedeling is totaal niet exotisch. Dit is nou eenmaal hoe de wereld werkt. Je hebt mensen die dingen maken, mensen die ze controleren en mensen die ze opeten of gebruiken. Alle drie testen ze op hun manier en op hun niveau en hoe beter de voorganger het heeft gedaan, hoe makkelijker jij het hebt. Dat lijkt me niet zo schokkend allemaal.

Interessanter voor ons thema zijn denk ik de volgende acht inzichten:

  1. Dit zijn verschillende róllen en niet per se verschillende persónen. Maar de rollen zijn zo verschillend qua attitude en skills dat de vereniging in 1 persoon niet voor de hand ligt.
  2. Hoe meer T-shaped de leden van een agile team zijn, hoe vaker ze in staat zullen zijn combinatierollen te vervullen. Een professional is T-shaped als hij of zij én een specialisme heeft, bijvoorbeeld testen, (de verticale poot van de T) én de skills heeft om andere disciplines waar te nemen of ermee samen te werken, bijvoorbeeld programmeren of analyse (de horizontale poot van de T)
  3. De klantrol en de keurmeester rol zijn en blijven ook bij handmatig testen onmisbaar.
  4. Bij externe leveranciers en standaardpakketten is de slagersrol meestal niet in eigen huis. Dit vraagt om technische competenties in eigen huis óf korte lijnen met de leverancier
  5. Met gebruiksvriendelijke intuïtieve tools kan de niet-technische klant zelf een groot deel van de geautomatiseerde testset opbouwen. Zorg wel voor een gedegen architectuur en goede training en begeleiding. De kans op onderhoudsproblemen op termijn is anders groot.
  6. De combinatie keurmeester en beheerder (FB, FAB) is vaak een goede: maak de beheerorganisatie verantwoordelijk voor de geautomatiseerde testset.
  7. Gerichte training en coaching bij geautomatiseerd testen en tools is onmisbaar.
  8. Testautomatisering vergt in veel gevallen ook betrokkenheid van afdelingen als Inkoop, HRM en Technisch Beheer / Infra.

Dat waren de acht inzichten bij de SKK driedeling. Nu wil ik nog ingaan op de waarde van full-stack testers, op Intuitieve testautomatisering en automatiseren in gewone mensentaal met keywords en BDD.

De full-stack tester

De klassieke ‘onafhankelijke' tester leunde vooral op functionele kennis en kennis van het testambacht. Met de hier onder besproken intuïtieve tools kan hij de testen ook automatiseren. Maar voor optimale samenwerking in agile teams en geautomatiseerd testen in de hele testpiramide is iets meer nodig. Namelijk technische kennis, zowel van het te testen systeem als van de tool en de scripts, liefst van back-end tot front-end, op alle lagen van de ‘technology stack'. De ideale agile tester is daar niet bang voor. Zo iemand is behalve T-shaped ook nog eens ‘full-stack' tester.
Of je nu wel of niet met gebruikersvriendelijke tools werkt, een onderhoudbare testset vraagt altijd om ‘good software design practices' en de softwareontwikkelaars en technici die daar bedreven in zijn. Zonder experts met ‘software-DNA' is de kans groot dat de testset geen toekomstvaste architectuur heeft en op termijn slecht onderhoudbaar is.

Intuïtieve testautomatisering

Naarmate testautomatisering meer gemeengoed wordt willen ook niet-technische gebruikers ermee aan de slag. Intuïtieve testautomatisering is een concept dat hierop inspeelt en gevolgen heeft voor rollen en taakverdeling. Het maakt automatiseren van testen laagdrempeliger omdat er niet geprogrammeerd hoeft te worden. De gebruiker is afgeschermd van de onderliggende techniek en kan de testscenario's vaak in een soort ‘tree browser view' bekijken en bewerken, voor maximale toegankelijkheid en onderhoudbaarheid. Dit stelt de niet-technische tester in staat om tot 80 à 90% van de testen zelfstandig te automatiseren.
Sommige tools faciliteren dat heel goed, anderen wat minder. Soms maakt een ‘schil' om een bestaande tool deze bruikbaar voor niet-technische testers. Zo'n schil kun je zelf bouwen en onderhouden of afnemen van een leverancier of test partner. Een voorbeeld is het JOSF framework, als schil om Selenium.
Daarnaast zitten de grote leveranciers niet stil en worden nieuwe en bestaande tools in de markt ook steeds intuïtiever. Voorbeelden zijn onder andere Tosca van Tricentis en ICTestAutomation van Trendic.


Figuur 18.1 De ‘tree browser‘-view op een testscript in een populaire tool

Automatiseren in gewone mensentaal: keywords en BDD

Om de actieve betrokkenheid van ‘de business' maximaal te faciliteren is het vaak verstandig om een knip te maken tussen de beschrijving van testgevallen in gewone mensentaal enerzijds en de technische scripts anderzijds.
De al lang bestaande keyword driven of actiewoorden aanpak is daar een voorbeeld van: generieke functionele testen die met behulp van parameters specifiek worden gemaakt. Bijvoorbeeld ‘log aan met gebruikersnaam Piet en wachtwoord Test01'. Of ‘voer een polis op voor een inboedelverzekering voor bedrag X met de kenmerken Y en Z'. Bij elk keyword of actiewoord hoort een script in een test tool dat de gevraagde actie uitvoert met de opgegeven parameters. Het voordeel hiervan is dat gebruikers het (logische) testontwerp kunnen doen en de data kunnen aanleveren, terwijl specialisten de achterliggende scripts voor hun rekening nemen.
Hieraan verwant is de Behaviour Driven Development aanpak (BDD). Daarbij wordt samen met de gebruikers het gewenste gedrag beschreven in het Gherkin ‘Given... When... Then ...' formaat, vastgelegd in een tool als Cucumber of SpecFlow. Meestal wordt dat vervolgens via één of meer lagen en tools doorvertaald naar scripts in de test ‘engine' die de daadwerkelijke geautomatiseerde testuitvoering verzorgt.

Tot slot misschien wel de belangrijkste: regel een strateeg!

Toekomstvast geautomatiseerd testen vergt een gebalanceerde inzet van competenties in de testpiramide. In combinatie met je toolkeuze en je hele Way of Work. Daarvoor heb je niet alleen slimme handjes en kritische testers en gebruikers nodig, maar ook een regisseur die de dynamiek en de implicaties van keuzes op de langere termijn overziet. Die regisseur moet ook nog evangelist en verkoper zijn die het enthousiasme erin houdt en de business case gezond houdt. Zorg dat je zo'n regisseur in huis hebt!

Tot zover deze 7e aflevering. Volgende keer, zoals beloofd: de toptools anno nu .... Denk ik.