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.

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.

Er is iets vreemds in Selector land

 

Dit hele verhaal begon omdat ik keek naar een stukje door AI gegenereerde Playwright code. En onmiddellijk voelde “Hier klopt iets niet.” Maar toen ik hier later met een collega over sprak, merkte ik dat ik met mijn uitleg niet veel verder wist te komen dan “Dat doe je zo niet”. Niet dat de code niet zou werken, in de meeste gevallen wel. Maar als de code wel werkt, waarom voelde de code dan toch verkeerd?

Wat ik in de Playwright code miste was veel GetBy… selectors. En dat terwijl er wel degelijk selectors waren op basis van tekst en rol. GetByRole, GetByText, GetByLabel, een van het eerste wat je leert bij Playwright. Aangeleerd door cursussen, gebruikt in voorbeelden, maar ik vraag me toch af: hoeveel mensen weten waarom?

Daarnaast viel mij nog iets anders op: de door AI gegenereerde code deed me ook aan iets denken. Aan de manier waarop ik met Selenium een selector maakte op tekst en rol. Dat deed mij beseffen: ik ben onbewust steeds meer overgeschakeld van de standaard manier van selectors binnen Selenium naar de standaard manier van selectors in Playwright. Gewoon, omdat de cursus dat zei en mijn collega’s dat al deden. En dat voor een persoon, die een sterk voorstander is van beargumenteerde keuze.

Wat de door AI gegenereerde code betreft zijn er meerdere mogelijke verklaringen. Het zou kunnen dat oudere voorbeelden een rol spelen, uit een tijd waarin Playwright nog minder GetBy… selectors had. Daarnaast lijkt de code aan te sluiten bij selectiemethoden die ook uit b.v. Selenium bekend zijn. Dat zou kunnen verklaren waarom de code afwijkt van de huidige standaard, maar wel correct is.

Wat betreft mijn eigen onbewuste switch? Ik had geleerd dat tekst te vaak wijzigt om te gebruiken. En ID of Name zou stabieler zijn. Maar in de praktijk heb ik hier nooit zoveel verschil in gemerkt. Het ene moment blijft de naam eeuwig staan, maar wordt constant geëxperimenteerd met de wijze van tonen en/of invoer, waardoor vaak ook ID of Name wijzigen. De andere keer blijft de wijze van invoer steeds gelijk, maar probeert men steeds andere varianten van tekst uit. Maar in de praktijk wijzigen beide eigenlijk niet zo vaak. En het grootste voordeel van een GetByText ten opzichte van een By.Id heb ik eigenlijk nergens gelezen: ik hoef het element meestal niet in de HTML-code op te zoeken om een selector te kunnen schrijven. Tekst en role kan ik namelijk altijd zien. Name en id moet ik bewust zoeken.

Toch blijf ik het wat vreemd vinden. Door middel van cursussen en voorbeeldcodes worden ons voorkeuren aangeleerd. Voorkeuren waardoor het merendeel van ons waarschijnlijk onmiddellijk denkt “Hier klopt iets niet”, als code hiervan afwijkt. Zonder dat het fout is, zonder dat we weten waarom. De belangrijkste reden, die wordt gegeven voor een selector voorkeur is stabiliteit. Maar dit is vooral voor de door de tool beter ondersteunde selectors t.o.v. css of xpath selectors. Informatie waarom Selenium geen expliciete By.text() aanbiedt (waardoor tekstselectie via vaak XPath loopt) en waarom Playwright geen getById() heeft (waardoor id-selectie vaak via CSS blijft lopen), kon ik moeilijk terugvinden.

Het voelt een beetje als “Wij bepalen voor jou wat beter is”. Maar ach, gebeurt dat uiteindelijk niet meer in de wereld van testen en ICT? Waarin vele van ons doen wat ons aangeleerd is, zonder te bedenken waarom? Zonder soms zelfs te weten dat er andere opties zijn?

Voor testautomatisering draait het er uiteindelijk om dat je code goed tegen wijzigingen kan. Naar mijn mening, ondanks alle voorkeuren van testframeworks, is dat toch iets wat project afhankelijk is. Zoals ik eerder schreef wordt bij het ene project meer gespeeld met de tekst en bij de andere met de elementen. Dus de meest stabiele testautomatiseringscode is code die daar rekening mee houdt. Ongeacht of dit de aangeraden wijze is of niet.

Maar het was een buitengewone interessante ontdekkingstocht. Hopelijk was het net zo interessant om te lezen.