zondag 25 januari 2026

Hoe goed moet een tester kunnen programmeren en soortgelijke vragen

 

Ik heb nu in een aantal hele verschillende organisaties testautomatisering vanaf het begin af aan opgezet. En ik ben daarbinnen regelmatig van programmeertaal en testtool geswitched. Daarnaast werk ik ook elke keer met andere mensen samen, die elke keer andere verwachtingen van me hebben qua kennis en vaardigheden. En ook hoe goed deze vaardigheden zijn. Dat maakt dat ik me als tester wel eens afvraag: wat moet ik allemaal wel niet weten en op hoeveel gebieden moet ik niet minimaal op medior niveau zitten om een goede testautomatiseerder te kunnen zijn?
En dat begint al met de vraag: hoe goed moet ik als tester kunnen programmeren? Binnen testen is zeker veel aandacht voor programmeren in Selenium of Playwright. Ook leer je bij deze basiscursus met enige regelmaat tegelijkertijd de basis voor het opzetten van een goede architectuur voor je automatische test. Waar vaak minder aandacht voor is, zijn de basisprincipes voor de programmeertaal waarin je programmeert. Als ik zelf kijk naar C#, waar ik op dit moment mijn testautomatisering in doen, zou ik bijvoorbeeld op het volgende minimale lijstje komen:
  • If / Switch / While
  • Classes
  • Datatypes
  • Namespaces
  • Exception handling
  • Async werking (async/await)
  • Werken met collections
Voor de duidelijkheid: dit lijstje beschrijft niet wat nodig is om C#-applicaties te bouwen, maar wat minimaal nodig is om testautomatisering in C# zelfstandig en onderhoudbaar op te zetten. De kennis die van een C#-developer wordt verwacht ligt vanzelfsprekend hoger en breder.

Wat je ziet is dat programmeertaal, testtool en architectuur in een cursus op 1 hoop worden gegooid. Zolang je die specifieke combinatie gebruikt, is dat geen probleem. Als je een nieuw testtool in een andere programmeertaal gaat toepassen, kan je ook beter weer vanaf het begin af aan starten. Maar wat moet je als testautomatiseerder weten van C# als je Playwright al in Typescript kan schrijven? Hoe vertaal je de architectuur principes op een goede manier in C#?

Maar voor mij zit in de tweede vraag ook meteen het juiste richting voor het antwoord
  • Je moet genoeg kennis van C# hebben om de architectuur principes voor testautomatisering goed op te kunnen zetten. 
  • Je moet genoeg kennis hebben van C# om je testtool goed te kunnen gebruiken binnen je testautomatisering.
Wat algemener gezegd: je moet genoeg kennis hebben om zelfstandig je werk goed te kunnen doen.

Dit laatste principe klinkt misschien wel erg algemeen. Maar dat wordt anders als we naar de category "Soortgelijke vragen" gaan. Over het algemeen zal je als testautomatiseerder je programmeren doen binnen een groep testautomatiseerders. Afspraken over hoe en wat je programmeert, maak je binnen deze groep. Maar er zijn ook vragen, waarbij het bovengenoemde antwoord de lading niet meer dekt.

Programmeren doe je zelf. Maar testautomatisering heeft ook onderdelen, die van belang zijn, die je waarschijnlijk niet zelf doet. Neem het opzetten van een database op een testomgeving. Kleine kans dat jij dit doet. Nu gaan we in deze blog vooral uit van een organisatie die geen ervaring heeft met testautomatisering. Dus jij weet niet hoe je een database op een omgeving voor testautomatisering neerzet, maar de persoon, die de taak uit moet voeren weet het ook niet. Dan ligt vaak toch bij jou de verantwoordelijkheid om te zorgen dat deze taken goed uitgevoerd worden. Maar aan een "je moet zelfstandig kunnen werken" heb je niet meer voldoende. Je moet nu tenslotte samen kunnen werken.

In mijn ervaring komt het nu aan op het volgend: waarin verschilt het opzetten van een database voor testautomatisering met het opzetten van een database op productie? Dan kom ik op de volgende punten uit:
  • Testdata moet soms al in de database beschikbaar zijn
  • De data in de database moet soms teruggezet kunnen worden naar een gewenste beginsituatie
Als je hier goed over wil kunnen meepraten, moet je in ieder geval in grote lijnen weten wat een Insert, Delete en Update is. En bijvoorbeeld hoe foreign keys werken en wat voor problemen deze kunnen veroorzaken in een database, als je de database verkeerd aanpast. Daarnaast zal je vaak enige kennis nodig hebben van de database in het bedrijf waar je werkt. Maar het technisch installeren van een database op een testomgeving is in de basis hetzelfde als op productie. Dit is daarom meestal geen kennis die je als testautomatiseerder nodig hebt.

Als je dit algemener formuleert, zou ik dat zo doen: "Je moet genoeg kennis hebben om de verschillen te weten tussen het standaard proces en het proces zoals gewenst voor testautomatisering. En je moet deze verschillen kunnen uitleggen aan anderen."

Dan de laatste groep, en deze zie ik het meest als je de devops wereld ingaat. Je werkt samen met andere functies, met andere verantwoordelijkheden, maar tegelijkertijd wordt ook vaak van je verwacht dat je een deel zelf ingeregeld. Zo moest ik in een bedrijf mijn eigen build straat maken voor de automatische test, maar lag in een ander bedrijf die verantwoordelijkheid bij een ander. En moest ik in het ene bedrijf zelf mijn testomgeving regelen, terwijl dat in een ander bedrijf absoluut verboden was. Dus voor het ene onderdeel moet je juist zelfstandig kunnen werken, voor het andere onderdeel moet je verschillen kunnen uitleggen.

Helaas is voor een testautomatiseerder uiteindelijk het antwoord op "Hoe goed moet je iets kunnen" afhankelijk van het bedrijf waar je werkt. Bepaalde onderdelen zullen in bijna elk bedrijf gelijk zijn, waardoor "zelfstandig werken" of "verschillen uitleggen" onder algemene kennis beschouwd kan worden. Voor andere onderdelen is dit in de huidige ICT wereld nog niet zo duidelijk vastgelegd en zal je het proefondervindelijk moeten ondervinden. Voor die onderdelen zou mijn tip zijn: ken het proces in grote lijnen en weet in grote lijnen hoe dit proces voor testautomatisering moet werken. Dan kan je vrij snel je kennis beide kanten op verder uitbreiden. En qua programmeren? Misschien wordt het tijd voor een gerichte cursus C# voor testers.



vrijdag 2 januari 2026

Starten met BDD in Reqnroll

 

Ik geef vaak de voorkeur aan veelgebruikte, ruim ondersteunde tools. Soms komt dat echter niet uit. Zo kwam ik de afgelopen tijd in aanraking met Reqnroll. Een BDD testframework gericht op een .NET omgeving, dat de opvolger moet zijn van het meer gebruikte SpecFlow,. Ik wil jullie meenemen in mijn ervaringen, zowel met het testframework, als met de zoektocht naar kennis.

Alles begon met de zoektocht naar kennis. Veel cursussen zijn er niet echt beschikbaar. En het probleem wat ik vaak heb met open source tools: ik snap de documentatie vaak niet genoeg om hiermee te starten. Documentatie van open source tools zijn in mijn ogen best geschikt als naslagwerk, maar niet om je een tool te leren. De informatie is regelmatig kort door de bocht en/of vanuit meer technisch perspectief beschreven.

Gelukkig is YouTube hierbij een uitkomst. Het moet wel heel nieuw zijn, wil je er geen hulp over kunnen krijgen op YouTube. En ook voor Reqnroll vond ik hier de oplossing:
https://www.youtube.com/playlist?list=PL6tu16kXT9PpqWrAYzhnlulMTKU2aP58P

Ik volg graag een cursus om een tool te leren. Toch heeft dit ook zeker nadelen. De basis is meestal wel gelijk, maar voor de wat meer advanced lessen moet de cursus maar net bieden wat je zoekt. Deze cursus bood bijvoorbeeld de verschillende mogelijkheden voor data driven testen die ik zocht. Maar hoe je de input in de Given/When/Then statements kan configureren was voor mij niet voldoende. Ik weet dat er meer opties zijn, dan in de cursus getoond. En eigenlijk wil ik er ook meer.

Wat voor mij een voordeel was: ik zocht voornamelijk simpel gebruik. Gewoon een Given/When/Then formaat, vooral met tekst en getallen als invoer. Dit maakte het makkelijker om met een nieuw tool te beginnen, omdat ik niet veel kennis nodig had om een start te  maken. Gezien het feit dat ik al met Cucumber heb gewerkt, was de basis van Reqnroll voor mij geen probleem. De structuur is eigenlijk gelijk: aan de ene kant de BDD test in tekst, aan de andere kant de implementatie van de stappen.

Misschien is het ook daarom dat ik de soms wat negatieve kijk op Reqnroll, die ik online las, niet deel. Het kan ook zijn dat dit BDD framework zich verder ontwikkeld heeft. Als basis vind ik het een fijn framework om mee te werken. Ja, ik heb wat andere voorkeuren. Zo wil ik vrijer zijn in de keuze tussen Given/When/Then. Ik wil een zin als “Given I login with username and password” ook kunnen gebruiken als “When I login with username and password”. Dit is echter niet mogelijk zonder voor dezelfde implementatie zowel een aparte “Given” als een aparte “When”-ingang te definiëren. En ik moet erg wennen aan de “” die ik moet toevoegen bij strings, om het matchen met de juiste implementatie van de stap goed te laten werken. Omdat strings de enige datatypen zijn die expliciet met quotes moeten worden vastgelegd, betrapte ik mezelf er regelmatig op dat ik dit vergat. Maar beiden zijn geen overkomelijk probleem.

Reqnroll biedt goede mogelijkheden voor varianten in zinnen. Je kan aan een implementatie meerdere matchende zinnen meegeven, zolang de variabelen maar gelijk blijven. Ook vind ik dat, als je een foutje maakt, de foutmeldingen duidelijk zijn. Als laatste zijn de data driven test mogelijkheden voor mij in ieder geval voldoende. Het biedt zowel per stap als voor de gehele testcase de mogelijkheid om data via tabellen mee te geven.

Ik ben nog steeds op zoek naar mogelijkheden om meer te leren. Mijn verwachting is dat dat wel gaat lukken. Nu ik meer weet, is de officiële documentatie van Reqnroll ook beter bruikbaar. En ik heb goede hoop dat meer cursussen zich snel zullen gaan aanbieden. Maar met wat ik nu weet kan ik ook al goed uit te voeten.