SOLID is te veel, POM is te weinig

Ik heb al aardig wat testautomatiseringsframeworks opgezet en aangepast. En ik heb altijd al veel aandacht besteed aan begrijpelijkheid en onderhoudbaarheid. Maar sinds ik in de detachering ben gegaan, is dit onderwerp nog meer gaan leven. Je hoort opeens in korte tijd veel meer meningen over wat de ideale code is. Waarbij woorden als SOLID en POM regelmatig langskomen.

Wat SOLID betreft zie ik grotendeels twee kampen: het kamp dat de best practices altijd toepast en het kamp dat SOLID helemaal niet van toepassing vindt op testautomatisering. Ik merk dat ik hier tussenin val.

Ik heb deze best practices zelf geprobeerd toe te passen en ik merkte dat vaak testautomatiseringscode hierdoor in begrijpelijkheid en onderhoudbaarheid afneemt. De code is te eenvoudig om de best practices consistent op toe te passen. Hierdoor krijg je extra code lagen, die weinig toevoegen, maar wel zorgen dat je code nu op 2 of meer plaatsen moet aanpassen, in plaats van een. Bijvoorbeeld door het toevoegen van interfaces, die slechts een maal in de code gebruikt worden. Een ander voorbeeld is het opsplitsen van paginacode in een invoer- en een validatieklasse vanuit de S van SOLID. In de praktijk betekent dit dat een aanpassing aan één veld je dwingt twee bestanden aan te passen in plaats van één.

Maar dat betekent niet dat ik vind dat je het zomaar moet negeren. Het argument “Het is geen productiecode”, dat ik vaak hoor, vind ik niet terecht. Juist testautomatiseringscode heeft behoefte aan een goede onderhoudbaarheid. En daar kunnen principes als SOLID wel degelijk  aan bijdragen.

Over POM ben ik al veel langer ontevreden. Het is een goede structuur, zeker. Maar ik heb nooit gesnapt waarom we als testautomatiseerders regelmatig stoppen bij POM, helpers en datadriven programmeren. Qua data kan ik dit het snelste duidelijk maken: als een bedrijf besluit om in plaats van ‘Groot-Brittanië’ voortaan ‘United Kingdom’ te gebruiken, op hoeveel plaatsen in je code moet je dit dan aanpassen? Wie heeft zijn code zo geschreven dat het antwoord hierop ‘1 keer’ is?

Hoe doe ik het dan wel? Ik zal twee recente voorbeelden geven. Ik heb verschillende datasets gemaakt in mijn code, waarmee je op basis van een landcode (volgens internationale standaard) data horende bij dat land op kan halen. De data is op 1 plek vastgelegd. En bij aanpassen wordt automatisch het invoeren en controleren aangepast, omdat de landcode gelijk blijft. Daarnaast geeft dit de mogelijkheid om bij het testen eenvoudig testsets te maken van naar wens 1 land of juist een testset met data van verschillende landen.

Als extraatje heb ik de landcode zo vastgelegd, dat als ik er een toevoeg elke dataset niet meer te compileren is. Allemaal geven ze aan dat er nu een landcode mist. Dit is een variant op het L van SOLID, die je vraagt om bij een afgeleide van een interface er altijd voor te zorgen dat alle functies van die interface goed blijven werken. Door mij vertaald: door het toevoegen van een land moeten alle datasets goed opvraagbaar blijven. Een ontwikkelaar moet zich niet hoeven afvragen of standaardgebruik leidt tot een ongewenste uitkomst.

Een ander voorbeeld: een veelvoorkomend testautomatiseringsprobleem is comboboxen die niet als combobox werken. Je testtool kan in een combobox niet op de standaard manier een waarde selecteren. Dus haal je trucjes uit met klikken, invoeren of zoiets om toch maar de waarde geselecteerd te krijgen. En zo’n combobox komt vaak vaker terug. Deze code heb ik altijd gecentraliseerd, vaak in een functie. Maar nu heb ik er iets langer over nagedacht. Het eindresultaat waren twee nieuwe combobox classes. Een voor elk type dat ik in mijn code tegenkwam. Beiden hebben een selectOption() en een nth(), precies als Playwright. En beiden zijn gebaseerd op een abstracte klasse, die een eventuele nieuwe comboboxvariant dwingt dezelfde functies ook te implementeren. Deze oplossing zorgt dat ik een eventuele aanvulling zo toe kan voegen. Zo had de eerste versie alleen selectOption. De nth() is later toegevoegd. Als ik later een derde comboboxvariant tegenkom, voeg ik een nieuwe klasse toe zonder de bestaande twee aan te raken. Precies wat de O van SOLID beoogt.

In testautomatisering is onderhoudbaarheid belangrijk, net als begrijpelijkheid. Deze eisen moeten in mijn ogen altijd gaan boven SOLID, POM of welk design principe dan ook. Dat houdt in dat je geen enkel design principe pertinent moet afwijzen, omdat het de onderhoudbaarheid wel kan vergroten. Ook betekent het niet dat je elk design principe blind moet toepassen, omdat dat de onderhoudbaarheid en begrijpelijkheid kan verkleinen. En evenmin dat alleen het toepassen van design principes je code onderhoudbaar en begrijpelijk maakt, zeker niet in testautomatisering.

De vragen die ik mezelf blijf stellen zijn vragen als: wordt deze code of data op meerdere plekken herhaald? En hoe foutgevoelig is een aanpassing? Die vragen leiden soms tot een design principe als oplossing, soms tot een andere oplossing. Maar ik wil deze afweging elke keer opnieuw maken, alles om onderhoudbaarheid en begrijpelijkheid te blijven verhogen.

Van hoogst naar mogelijke

 

Ik was en ben perfectionistisch. Ik wil altijd het hoogst mogelijke bereiken. Maar naarmate mijn ervaring toenam, merkte ik iets op: hoe meer je wil bereiken, hoe minder je vaak bereikt. En dit is vooral merkbaar in testautomatisering en testverbetering. Hoe hoger de eisen aan de testautomatisering of de testverbetering, hoe kleiner de kans dat er ook maar iets verbetert.

Wat ik zag gebeuren, is twee verschillende zaken. De eerste is dat verbeteringen, al dan niet door testautomatisering, door de eisen die gesteld werden, nooit in gebruik werden genomen. De perfecte oplossing was in de huidige situatie van het bedrijf of team vaak niet haalbaar, dus gebeurde er uiteindelijk niets.

Het tweede dat ik zag gebeuren had te maken met draagvlak. Ik kan met mijn kennis en ervaring weten wat de perfecte oplossing voor een testautomatiseringsprobleem is. Maar als daaraan getwijfeld wordt, is mijn oplossing niet meer perfect. Verbetering werkt op zijn best als de personen die ze moeten uitvoeren in de oplossing geloven of het minimaal een kans willen geven. Bij twijfel of ongeloof zullen mensen de perfecte oplossing alleen volgen, wanneer je constant blijft controleren. En dat is gewoon niet haalbaar. Uiteindelijk zit je met een perfecte oplossing die niet perfect wordt uitgevoerd, waardoor de perfectie niet gehaald kan worden.

Maar ik schreef dat ik nog steeds perfectionistisch ben. Ja, ik wil nog steeds het hoogst mogelijke bereiken. Ik heb alleen mijn doel verplaatst van “hoogst” naar “mogelijke”. Ik wilde altijd uitgaan van de oplossing die in theorie het beste resultaat zou geven. Het hoogste doel halen, wat maar mogelijk is. Nu wil ik iets anders. Ik wil kijken wat er in de organisatie mogelijk is, en binnen die mogelijkheden het hoogste doel halen.

Het gekke is dat dit perfectionisme vaak gezien wordt als erg pragmatisch. Maar er zit meer achter dan alleen pragmatisme. Ik kijk niet alleen naar wat nu mogelijk is, ik kijk ook of ik de grenzen kan verleggen. Ik kijk of ik meningen van mensen kan veranderen. En ik kijk of ik iets dat binnen de organisatie al bekend is, nu op een andere manier kan inzetten om een ander doel te bereiken.

Ik zorg voor snelle, korte-termijn verbeteringen, om draagvlak te creëren voor grotere, lange-termijn verbeteringen. Dus eerst een paar eenvoudige, maar waardevolle automatische testen om te bouwen aan draagvlak voor de middelen die nodig zijn voor de complexere automatische testen.

Ik wil altijd meer en beter. Maar ik wil tegelijkertijd wel dat het testen en het testproces werkelijk verbetert, en niet wacht tot alles perfect in orde is. Ik wil dat mensen zien dat verbetering kan, waardoor mensen geloven dat meer en beter ook werkelijk iets kan opleveren. Zo komen mogelijkheden open die eerst gesloten waren. Perfectie in stappen, in plaats van in een keer.

Tijd is een factor, geen doel

 

Ik denk dat iedere tester het wel een keer heeft meegemaakt: het project waaraan je werkt moet opeens snel af. Liefst zo snel mogelijk. Vandaag is goed, gisteren was beter. Het gevolg laat zich raden: alles gaat in een noodtreinvaart. En bijna altijd zie je hetzelfde patroon terug: de tijd die zogenaamd is gewonnen in de ontwikkeling, verdwijnt genadeloos in het bugfixen.

En toch blijven we het doen.

Mijn reactie op tijdsdruk is daarom al jaren dezelfde, en die levert regelmatig fronsende wenkbrauwen op: hoe sneller iets moet, hoe langzamer ik test. Niet uit dwarsheid, maar uit ervaring. Want hoe harder een team gaat rennen, hoe sneller de kwaliteit onderuitgaat. Dat is geen mening, dat is een wetmatigheid.

Tegelijk ben ik ook niet naïef. Tijdsdruk bestaat. Soms is het onvermijdelijk. Soms zelfs terecht. Maar laten we stoppen met doen alsof “het moet snel” een volledige boodschap is. Dat is het niet. Het is hooguit de helft.

De andere helft wordt vaak bewust niet uitgesproken: hoeveel risico zijn we bereid te accepteren?
Zolang die vraag niet beantwoord is, betekent “snel” meestal: minder testen, minder nadenken, minder kwaliteit. En daar zou geen enkele tester tevreden mee moeten zijn.

Wat mij stoort, is dat snelheid zelden wordt gepresenteerd als een keuze. Het wordt gebracht als een natuurverschijnsel. Alsof we geen alternatieven hebben. Alsof morgen goed opleveren minder waardevol is dan vandaag half. Terwijl iedereen weet wat de uitkomst is: vandaag snel levert morgen gedoe op. En overmorgen frustratie.

Juist testers zouden hier harder in mogen zijn. Het is niet onze taak om blind mee te sprinten omdat de rest dat doet. Het is onze taak om zichtbaar te maken wat versnellen kost. Kwaliteit laat zich niet dwingen. Die laat zich alleen ruilen tegen stabiliteit, vertrouwen en uiteindelijk tijd.

Dus voordat we weer “even gas geven”, stel ik liever eerst een paar ongemakkelijke vragen. Versnellen we omdat het echt waarde toevoegt? Of alleen omdat iemand heeft geroepen dat het moet? En belangrijker: als dit misgaat, zijn we dan allemaal bereid de consequenties te dragen?

Want nee, we hoeven geen wedstrijd te winnen.
We proberen een goed product te leveren. En dat kost tijd. Altijd.

Ik leer niet voor mijn werkgever. Maar voor wie dan wel?

 
Ik ben op dit moment mijn kennis flink aan het uitbreiden. Zo ben ik bezig met het leren van SAFe, officieel vanuit mijn werk. Daarnaast ben ik mijn programmeerkennis aan het uitbreiden en volg ik privé een cursus Claude Code. Waarom ik dat allemaal doe? Om eerlijk te zijn: het is nauwelijks omdat mijn werkgever dat wil. Maar waarom wil ik dit dan vrijwillig doen?

CV verbetering

Ik zie het als mijn eigen verantwoordelijkheid om ervoor te zorgen dat mijn CV geschikt is voor heden en toekomst. Niet alleen voor mijn huidige werkgever en de daarbij horende opdrachten, maar ook voor toekomstige werkgevers.

Ik heb flink wat eigen tijd en geld gestopt in het verbeteren van mijn CV. Zodat de gevraagde certificaten erop staan.  En ook dat er certificaten opstaan, die mij misschien net dat extra pluspuntje kunnen geven ten opzichte van anderen. Dat geeft mij nu meer zekerheid op opdrachten, maar ook op langere termijn meer kans op baanbehoud en het wisselen van baan.

Ik heb te vaak mensen om mij heen gezien die qua kennis achter waren gebleven, hierdoor vast kwamen te zitten op een werkplek waar ze het niet meer naar hun zin hadden, of zelfs hun baan kwijtraakten en daarna niet meer aansloten op de markt. Ik weet dat ik dit niet altijd kan voorkomen, maar ik wil er zeker wel mijn best voor doen.

Eigen opinie vormen

Maar er is nog een belangrijke reden waarom ik graag mijn kennis uitbreid. De ICT staat niet stil. Er komen constant nieuwe methoden, technieken en tools bij. En regelmatig komen er bij mij vragen op als ik mensen over deze nieuwe zaken hoor praten. Is dit werkelijk hoe deze methode in elkaar steekt? Kan dit werkelijk niet met deze nieuwe tool? Ik ben niet een persoon, die iemand zomaar op zijn of haar woord wil geloven. Maar zonder eigen kennis ga ik ook niet zomaar ergens tegenin.

Daarom vind ik het belangrijk om te blijven leren, als het gaat om nieuwe methodes en nieuwe ontwikkelingen. Maar ook als ik al langer bestaande methodes en tools tegenkom, die ik zelf nog niet eerder heb toegepast, leer ik hier graag meer van. Vaak kom ik er inderdaad achter dat een tool meer kan. Maar ook dat een methode niet op deze wijze uitgevoerd hoort te worden. Het heeft ook een extra voordeel: als je met een certificaat of cursus kan aantonen dat je officiële kennis hebt, is het ook eerder mogelijk hier iets van te zeggen.

Uitdaging zoeken

De laatste reden om te leren is de meest persoonlijke. Ik word graag uitgedaagd en hou ervan om nieuwe dingen te leren en tools uit te proberen. En ik kan niet verwachten dat ik deze uitdaging altijd binnen mijn werk kan vinden. Daarom daag ik mijzelf ook buiten mijn werk graag uit, zoals nu met het leren van Claude Code.

Maar dit is zeker niet altijd 100% werkgerelateerd. AI is op dit moment hét gebied waar de uitdagingen liggen. Daarom heb ik me bijvoorbeeld al verdiept in het maken van AI-muziek, naast natuurlijk AI-afbeeldingen.

En jij als lezer?

Ik merk dat er een groep mensen is, die leren soms als verplichting ziet. En voor een deel is dat zeker het geval. Maar het gaat er mij meer om dat, zelfs als je het als verplichting ziet, je dit nog steeds niet doet voor je werkgever. Een detacheerder heeft misschien belang bij een goed CV, maar jijzelf ook.

En het gaat niet alleen om de certificaten. Maar ook om dat je mee kan praten over de onderwerpen, die rond je werk spelen. Ook als het niet direct over testen gaat. Basiskennis hebben van methodes, al of niet rond testen, zorgt ervoor dat je beter in staat bent je testen hierop te laten aansluiten. Of algemeen kan helpen de kwaliteit van het proces te verbeteren. Zo kan je als tester niet alleen wijzen op fouten in de code, maar ook op fouten in de gevolgde methode. Omdat je weet wat de officiële regels zijn én wat de officiële bedoeling van deze regels is.

En als je, net als ik, ook nog manieren gaat vinden waardoor je het soms ook nog leuk vindt, is er helemaal niets meer wat je tegenhoudt.

Kennen we de echte gevaren van AI nog wel?

Ik krijg steeds meer moeite met wat ik lees over de gevaren van AI. Niet omdat ik geen gevaren zie. Die zie ik, die ervaar ik elke keer als ik met AI werk. Maar omdat ik steeds meer tunnelvisie zie. Ik heb steeds meer het gevoel dat, als het om AI aankomt, we deze beoordelen vanuit wat we verwachten dat er misgaat. Ik zie steeds minder een echte objectieve blik.

Laat me vanuit testperspectief een voorbeeld geven. Ik ontken absoluut niet dat b.v. security testing of performance testing belangrijke testen zijn. Dit zijn beide vormen van testen, waarbij je bewust probeert een applicatie te laten falen. Maar als deze testen tegenvallen, zal je als tester nooit zeggen dat de applicatie functioneel niet werkt. Dit gebeurt bij AI wel. Als AI bewust getest wordt op hallucinaties, bias of andere bekende fouten, is dat zeker een goede ontwikkeling. Wat geen goede ontwikkeling is, dat als we de AI vervolgens onder deze bewust uitgevoerde testen op hallucinatie of bias betrappen, we gaan beweren dat de AI functioneel niet goed werkt. Er is een groot verschil tussen een applicatie die bij normaal gebruik al performance problemen heeft en een applicatie die onder extreme omstandigheden bezwijkt. Net zo goed zouden we een verschil moeten zien tussen AI die bij normaal gebruik last heeft van hallucinaties en een AI die onder extreme omstandigheden last heeft van hallucinaties.

Een ander voorbeeld: een goede tester heeft een basis set aan testkennis. Hij of zij weet waar een gemiddelde applicatie op kan falen. En als je begint bij een nieuw bedrijf is dat je startpunt. Maar een goede tester weet ook iets anders: elk bedrijf heeft zijn eigen type kwaliteitsproblemen. Dit is afhankelijk van de hoeveelheid beschikbare documentatie, de ervaring van de developers, de mate van samenwerking, de druk in de organisatie, het domein van het bedrijf. Dus naast de algemene risico’s kijk je als tester ook naar de voor het bedrijf specifieke risico’s.

Zo gaan we, zelfs als testers, niet met AI om. Ik zie geen artikelen over wat de gevaren van AI voor testers zijn. Ik zie geen artikelen over wat voor problemen AI kan geven binnen b.v. testautomatisering. Dus ik ben zelf met een testpet AI ingedoken en heb drie experimenten gedaan.

Experiment 1 Testers bewust laten worden van de gevaren van AI

Ik heb AI gevraagd om experimenten te bedenken, waarmee testers zelf kunnen ervaren wat de gevaren van AI zijn. Hierop was de eerste reactie buitengewoon van slechte kwaliteit. De gegeven experimenten zouden misschien een paar jaar geleden inderdaad falen, maar de huidige AI’s zijn al lang getraind om dit soort problemen zoveel mogelijk te voorkomen. Je zag een duidelijke trend naar veel gegeven risico’s over een lange periode van tijd. Terwijl je voor een juiste antwoord van dit onderwerp moet kijken naar de veel gegeven antwoorden van, laten we zeggen, het afgelopen jaar. Nadat de AI hierop gewezen was, werd het antwoord al wel beter.

Experiment 2 Informatie vragen over een bedrijf waar niet al te veel informatie over is

Het bedrijf waar ik voor werk is niet zo groot, dus uitstekend geschikt om te kijken hoe een AI omgaat met een onderwerp waar weinig informatie over is. Het probleem van langere periode kwam hier weer gedeeltelijk terug. Informatie van jaren terug werd gebracht alsnog steeds van toepassing op deze tijd. Hier was in beperkte mate ook sprake van hallucinaties. Zo wist die niet goed te achterhalen welke medewerkers het laatst begonnen zijn, terwijl dit wel te vinden is. Maar waar ik dit eigenlijk startte met een verwachting dat weinig informatie zou leiden tot verzonnen informatie of informatie uit onbetrouwbare bronnen, kwam het grootste risico ergens anders op uit. De conclusies die AI trok, waren regelmatig gebaseerd op correcte bronnen en waren gebaseerd op feiten. Maar de conclusies waren gebaseerd op veel te weinig informatie. Je kan niet aangeven wat het aannamebeleid is van een bedrijf op basis van twee aangenomen medewerkers. Je kan geen uitspraak over een bedrijf doen op basis van 1 review. Dat is wel precies wat ik waarnam.

Experiment 3 Testcases genereren

Naar aanleiding van bovenstaande onderzoeken werd ik nieuwsgierig: hoe goed is AI nu met testcases genereren. Specifiek wilde ik twee onderwerpen onderzoeken:
1.      Is er verschil in kwaliteit als je een AI een volledige omschrijving geeft van wat je wil testen v.s. een specifiek onderwerp vraagt?
2.      Is er verschil in kwaliteit als je een algemene AI vraagt om een test v.s. een gespecialiseerde AI

De tweede geef ik wat toelichting. We hebben, in principe terecht, steeds meer de neiging om AI te gebruiken binnen een AI die voornamelijk geïsoleerd kijkt naar informatie van een bepaald bedrijf. Dit om het mogelijk te maken om bedrijfsgevoelige informatie te delen bij het gebruik van AI. Wat ik me af begon te vragen is of dit effect kan hebben op de kwaliteit van de test cases.

Voor de duidelijkheid: ik heb dit niet echt getest met een AI die specifiek voor een bedrijf is ingericht. Daar heb ik geen toestemming voor. Ik heb een gespecialiseerde AI genomen, in dit geval een AI gespecialiseerd in het samenstellen van mocktails. Wat voor mij enigszins vergelijkbaar is met een bedrijf, waar het merendeel van de informatie niet getraind is op testdata, maar op bedrijfsspecifieke informatie. Deze specialistische AI heb ik gevraagd om testcases te maken voor een app, die voorstellen doet voor mocktails. Datzelfde heb ik vervolgens gevraagd aan een niet specialistische AI. De specialistische AI scoorde veel hoger op domein gerelateerde antwoorden, maar veel lager op algemene kwaliteitstestcases. Wat mij doet zeggen: laten we als testers eens onderzoeken of we werkelijk alleen een AI moeten gebruiken, die werkt binnen een bepaald bedrijfsdomein.

Volledige omschrijving v.s. specifiek onderwerp was ook heel interessant. Wat ik zag is dat de AI op basis van de prompt in de meeste gevallen een aandachtsgebied bepaalde. Zo werd bij een mobiele applicatie voor vergelijkingen de nadruk van de testcases gelegd op vergelijken, niet op mobiele applicaties. En als je een scherm omschreef dat een IBAN-veld bevatte kreeg je meer hoog niveau testcases, dan als je specifiek vroeg een IBAN-veld te testen. En als je dan werkelijk je AI-onzin wil laten uitkramen, moet je hem vragen waarom hij de ene keer testcases niet noemt en de andere keer wel. Die redenaties stonden vol van aannames, die niet klopten. Zo gaf hij aan dat een IBAN-veld als enige op een scherm strengere controle vereist dan een IBAN-veld in een algemeen formulier. Een redenering die misschien waar kan zijn, maar in heel veel gevallen hebben IBAN-velden echt dezelfde controles, ongeacht met hoeveel velden ze gecombineerd staan.

Conclusie

In mijn ogen wordt het tijd dat we wakker worden voor de echte gevaren van AI. En hier zie ik zeker een rol van testers weggelegd, omdat vele van ons al gewend zijn om het risico bepalen niet alleen te baseren op de theorie, maar ook op onze eigen ervaringen. Laten we, voor we AI inzetten voor iets, eerst controleren in hoeverre AI geschikt is voor de wijze waarop wijzelf het willen gaan gebruiken. Net als we doen als we een ander tool in gebruik nemen, b.v. een testautomatiseringstool of een bevindingentool. Laten we af en toe een expert vragen om naar een resultaat te kijken. En laten we beseffen wat we testen en hoe we testen als we AI testen. Testen op extreme situaties is waardevol, maar hetzelfde is testen op normaal gebruik. Testen op algemene problemen is waardevol, maar hetzelfde is testen op domein of bedrijfsspecifieke problemen. Laten we ons, zeker als tester, bij AI ook als ervaren testers gedragen.

Hoe maak je een team van losse testers

In de testwereld komt het met enige regelmaat voor dat er 1 tester in een team zit. Het bedrijf is te klein voor meerdere testers per team, maar te groot om één centrale tester te laten volstaan. En toch wil je deze samen brengen, om de organisatie als geheel verder te brengen. Maar er kan ook een andere situatie zijn, die b.v. senior testers uit verschillende organisaties samenbrengt. In beide gevallen gaat het om testers, die gewend zijn zelf de touwtjes in handen te hebben. Individuen, die meestal zelf beslissingen nemen, zeker als het op testen aankomt.

Wat ik in de praktijk vaak heb zien gebeuren, is dat er een groep testers samenkomt, met ieder eigen ideeën en prioriteiten. De kans is groot dat iedereen zijn eigen lijn blijft volgen. Het zijn wat ik noem, losse testers, en dat is geen belediging. Juist die zelfstandigheid maakt hen vaak sterke senior testers of effectieve solisten binnen hun team.

Maar wie testen wil versterken binnen een organisatie of project, heeft meer nodig dan individuele kracht. Een verzameling losse testers verandert weinig. Pas wanneer zij als groep optrekken, kunnen patronen worden doorbroken en structurele verbeteringen worden gerealiseerd.

Mijn ervaring is dat testverbetering niet ontstaat door één dominante visie, maar door het samenbrengen van verschillende vakmatige zorgen. Wanneer iedere tester de ruimte krijgt zijn belangrijkste punt in te brengen, ontstaat er balans. Niet omdat iedereen gelijk heeft, maar omdat verschillende perspectieven elkaar corrigeren en aanvullen, zoals binnen een Scrum team techniek, kwaliteit en klantwaarde elkaar in evenwicht houden.

Ik werk in zulke situaties vanuit de redenering, dat ik anderen niet direct kan veranderen. Het enige wat ik kan proberen is mijn eigen gedrag anders te laten zijn, met de hoop anderen mee te krijgen. En bij een groep losse testers begint dat met luisteren. Wat is belangrijk voor mijn mede-tester? Waar willen ze graag tijd aan besteden? Willen ze nieuwe tools inzetten? Willen ze documentatie verbeteren? Testautomatisering verbeteren? Van daaruit gaat dan mijn belangrijkste regel in werking: “Wat belangrijk is voor hen, is belangrijk voor mij.” Geen discussie over “Is er niet iets belangrijkers?”. Maar ik stel een deel van mijn tijd beschikbaar, om hen te helpen hun doel te bereiken. En dat voor iedereen in de groep.

Ik ben van nature geneigd mijn mening stevig neer te zetten. Ervaring geeft overtuiging. Maar ik heb ook gemerkt dat gelijk krijgen niet hetzelfde is als samen verder komen. Juist door ruimte te maken voor andere perspectieven ontstaat meer draagvlak. Vaak ook met betere oplossingen dan ik zelf had bedacht.

Daarnaast is er voor mij iets anders waar ik op probeer te letten. Besluiten moeten genomen worden op basis van argumenten, ervaring, kennis, vertrouwen. Er zijn talloze gronden waarop je besluiten kan nemen. Maar voor groepsvorming mogen hiërarchie en macht niet bepalen welke stem het zwaarst weegt. Hiërarchie is duidelijk. Macht zie ik vrij ruim. Dit kan ook het vertrouwen zijn dat managers in een persoon hebben, woordgebruik om je zin door te douwen of gewoon wegkomen met weigeren. Waarom ik hier altijd tegenin zal gaan? Voor groepsvorming moet een situatie ontstaan waarin iedereen gelijk is. Ieder neemt zijn eigen kennis en ervaring mee. Daardoor is iedereen binnen een groep testers ergens expert in. Senioriteit is niet algemeen, maar thematisch. Maar dit kun je alleen gebruiken, als een bepaalde groep mensen niet door hiërarchie of macht het pad van de groep naar zich toe trekken. En daardoor anderen, per ongeluk of expres, de mond snoeren.

Laat ik realistisch zijn: een groep op deze manier opbouwen vraagt óók om macht. Zorgen dat iedereen aan het woord komt en dat ieder perspectief ruimte krijgt, vraagt om invloed. Voor mij zit het verschil echter in hoe je die invloed inzet. Gebruik je haar om ruimte te maken voor anderen, of om je eigen agenda door te drukken? Balans bewaken betekent voor mij niet bepalen wat belangrijk is, maar het proces bewaken waarin we dat samen bepalen.

Waar je wel voor op moet passen, is dat er sprake blijft van wederzijdsheid. Er is niets mis mee om tijdelijk anderen te helpen met hun doelen en voor de groepsvorming vooral aandacht te geven aan anderen. Maar op de lange termijn zal er ook verandering vanuit anderen moeten komen. Meestal gaan anderen ook je aanpak kopiëren. En ontstaat er langzaamaan een groep. Maar ook jij hebt kennis en ervaring die bijdragen. Ook jijzelf mag je prioriteiten inbrengen. Vraag die tijd ook op. Zeker als de groep wat langer samen is, kan je variëren tussen momenten waarin je er voor de ander bent en momenten waarin je tijd vraagt voor jouw kant. Juist een goede afwisseling van geven en van nemen is de voorbeeldrol, die een team nodig heeft.

Een groep losse testers wordt geen team door afspraken of structuur alleen. Het wordt een team wanneer invloed niet wordt ingezet om te bepalen wie gelijk heeft, maar om ruimte te maken voor elkaars perspectief. Dat vraagt om bewust omgaan met invloed. Niet om haar te vermijden, maar om haar dienstbaar te maken aan het proces.

Want uiteindelijk gaat het niet om wie de meeste ervaring heeft, maar om hoe we die ervaring samen inzetten om het testen beter te maken dan ieder van ons afzonderlijk zou kunnen.

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.