Vergeef het me, ik krijg momenteel enorm veel mee van kinderseries. Het is al een gekke gewaarwording om alle series van vroeger opnieuw mee te maken als volwassene. Echter bij één specifieke serie gebeurde er iets vreemds en ontdekte ik een diepere laag. Ik ging zelfs de absurde en lachopwekkende situaties herkennen in mijn dagelijkse werkzaamheden! Helaas zijn er genoeg overeenkomsten tussen de situaties waarin Buurman en Buurman continu terechtkomen en de iteraties die ook mij overkomen binnen software testen.
Neem bijvoorbeeld de aflevering waarbij Buurman en Buurman een boekenkast op de eerste verdieping willen inrichten met boeken van de begane grond (Pas op: spoiler!).
Deze aflevering begint allemaal onschuldig, beide Buurmannen
pakken een klein stapeltje boeken en lopen de trap op.
Ter vergelijking heb je mij en mijn testautomatiseringsproject
dat ik wil opzetten. Ook ik begin onschuldig individuele testscenario’s te ontwikkelen.
Buurman bedenkt nu dat alles beter kan. Laten we
één Buurman bij de boekenkast alles inrichten en de
ander loopt met de boeken de trap op.
Ik doe iets vergelijkbaars; ik begin mijn werk op te delen in een
gedeelte dat ik wil afstemmen (wat gaan we testen) en
een gedeelte technisch bouwen van de automatiseringsscripts.
Ik stel daarom eerst BDD scenario’s op en stem deze af met de business
en PO. Als ik een bulk heb afgestemd sla ik ze op als Cucumber
scripts en ik duik in de wereld van TypeScript.
Maar dan: “Buurman ik heb een goed idee”. Het
idee is een soort roltrap te klussen waarbij
Buurman met boeken niet zoveel hoeft te traplopen.
Er komt een motortje, een touw en een set ski-latten.
Met een touw trekt de ene Buurman de andere
en vanwege de ski-latten glijdt hij naar boven.
Wat gebeurt er met de boekenkast? Na veel
klussen heeft deze enkel nog steeds maar de 2 stapeltjes
boeken van de eerste keer lopen.
Bij mij is mijn goede idee dat ik mijn testautomatiseringsframework
beter onderhoudbaar wil maken. De Cucumber scripts worden
daarom uitgebreid met voor elk scherm en validatie een
nieuwe Gherkin regel, zodat de PASS of FAIL duidelijk
gecommuniceerd worden. Maar ook bij mij
blijft de hoeveelheid geautomatiseerde testen hetzelfde.
Bij Buurman en Buurman gaat het grotendeels
goed, tot we bovenaan de trap komen. Het touw
is op en de laatste treden moeten nog genomen
worden. Het gevolg? Buurman glijdt naar beneden,
BOEM – AUW!
“Hmm” “Buurman ik weet het!” En er wordt door
beide Buurmannen een rolband geklust waarmee
beide Buurmannen een stapeltje boeken succesvol
naar boven kunnen brengen.
Ik kom erachter dat mijn verbetering in de Cucumber
scripts goed werken, maar dat ik meer flexibiliteit in het
gebruik van testdata wil hebben. Ik kies ervoor om
Example en Data tabellen te gebruiken, zodat
ik bij testen met hetzelfde doel hetzelfde Scenario
kan gebruiken, maar toch kan variëren met essentiële
data. Ik wil alleen voor de business de
data tonen die voor hen nuttig en/of belangrijk is, dus
de rest zet ik in mijn Step-definition-bestand.
Dit werkt goed, met als bijkomend voordeel dat ik
mijn hoeveelheid automatische testen heb verdubbeld.
Oei, er is toch een probleem bij Buurman
en Buurman. De rolband neemt de hele trap
in beslag en hoe komen de Buurmannen nu beneden?
Maar dan gebeurt het: A je to en ze glijden
over de leuning naar beneden. Nu kan de boekenkast
eindelijk gevuld worden met een stukje automatisering.
Ook bij mij komt er nog één laatste probleem.
Ik wil invoer-data die voor de uitkomst van de test
niet uitmaakt, maar wel ingevoerd moet worden weg uit
mijn technische bestanden. Ik besluit om testdata.json bestanden
te maken met generieke scenario’s. Deze roep ik aan
via de Cucumber scripts. Nu is alles weer overzichtelijk
en onderhoudbaar. En ik kan nu ook de afgesproken
BDD scenario’s automatiseren.
A je to, het resultaat is goed! Toch?
Nee, ik houd een rare nasmaak hieraan over. Stel er was een Product Owner bij de iteratie van Buurman en Buurman, dan zei die: “Hoezo automatiseren?! Ieder 4 stapels boeken, lopen en klaar! Hier krijg je geen tijd voor, en nu hup aan de slag!” Of een bouw-expert stond erbij “Waarom moet JIJ mee omhoog met de boeken?! Bouw gewoon een boekenlift. Deze nis is een goede plek. Hier heb je een standaard ontwerp van mij die je kan gebruiken.” Of iemand van de business “Maar ik wilde alleen snel en makkelijk een boek terugvinden! Zet ze op alfabet in de keuken en dan was je er ook al!” Ik hoor ze het al zeggen.
En bij mij hetzelfde, wie zegt dat er wel tijd en geld was voor een refactor? En waren er geen code conventies of voorbeelden waar ik op kon leunen? En was dit wel het juiste moment om te verbeteren? Ik ben binnen mijn eigen bubbel blijven itereren, waarin ik door mezelf werd overtuigd dat ik aan de goede dingen werkte. Dit gaf mij een goed gevoel, maar er is geen afstemming over de juiste prioriteiten. De kans is dus groot dat ik mijn resultaat de verkeerde kant op itereer.
Dit zie ik niet alleen bij mij maar op meerdere plekken in de IT terugkomen. Wees daarom bewust wie je uitnodigt in je iteraties. Elk ander perspectief kan je waardevolle nieuwe inzichten geven. Met als gevolg dat je een product bouwt dat bruikbaar is vanaf de eerste livegang.
Nieuwsgierig geworden en wil je meer weten over testen? Neem dan contact op met Praegus – 085-1305977 / info@praegus.nl of kijk op www.praegus.nl
