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.

Herken jij het plaatselijke testdialect?

 

Elk bedrijf heeft zijn eigen manier van praten en zijn eigen woordgebruik. Ook als het aankomt op testen. Het plaatselijke testdialect is vaak een combinatie van woorden van het domein waarbinnen het bedrijf actief is, woordgebruik binnen de meest gebruikte applicaties en (test)tools en het meegebrachte woordgebruik van de plaatselijke experts. Als je het plaatselijke testdialect nog niet spreekt, kan dat de communicatie flink bemoeilijken.

Neem het woord testplan. Door mijn carrière heen heb ik dit zien gebruiken met drie betekenissen.

1.      Een aan het begin van een project opgesteld document, waarin het gehele testproces beschreven stond, meer een soort plan van aanpak/risicoanalyse

2.      Als vervanging voor het woord testscript, dus een document dat stap voor stap beschrijft welke handelingen tijdens testen uitgevoerd moeten worden

3.      Als verwijzing naar een collectie testen binnen een testautomatiserings- of devops tool

Hopelijk kan je je dan voorstellen dat de vraag “Moeten we het testplan gebruiken?” heel anders beantwoord wordt bij elke betekenis. En je antwoord niet begrepen wordt, als de vraagsteller een andere betekenis in zijn hoofd heeft.

Het grootste gevaar van het plaatselijke testdialect is dat het gebruik daarvan vaak onbewust is. Men staat er niet meer bij stil of weet oprecht niet dat een woord ook andere betekenissen kan hebben. Men staat er niet bij stil, dat bepaalde testgewoontes of tradities binnen andere bedrijven, programmeertalen of tools best wel eens anders genoemd kunnen worden. Waardoor men onbewust vragen stelt of meningen geeft, die op een hele andere manier opgevat kunnen worden, dan oorspronkelijk de bedoeling was.

Ik ben net begonnen met een nieuwe baan, begonnen in de detachering en begonnen met een nieuwe opdracht. Dat maakt dat ik hier op dit moment zeer sterk tegenaan loop. Gesprekken lopen soms moeilijker, waarbij soms ik, soms mijn gesprekspartner, soms beiden niet beseffen dat woorden en zinnen voor ons andere betekenissen hebben. Maar ik merk wel op dat het gesprek niet vloeiend verloopt. Alsof je een beetje langs elkaar heen loopt te praten.

Laat me duidelijk zijn: meestal is dat geen ernstig probleem. Je brengt het onderwerp later nog een keer ter sprake. Of naarmate je het bedrijf beter leert kennen, begrijp je beter hoe woorden en zinnen gebruikt worden. Het merendeel van mijn gesprekspartners zien het feit dat ik “rare antwoorden geef” of “bepaalde begrippen niet weet” niet automatisch als signaal dat ik niet zo goed ben in mijn vak als ik me voor doe. Maar helaas gebeurt het toch met enige regelmaat dat ik door “verkeerd woordgebruik” als tester lager wordt ingeschat.

Jaren geleden had ik een sollicitatiegesprek waarin mij gevraagd werd of ik binnen testautomatisering wel eens POM toepaste. Omdat ik de term niet kende, ging ik ervan uit dat ik dit ook niet deed. En ik voelde onmiddellijk dat dat antwoord een min punt was. Toen ik later de term opzocht en ontdekte dat het Page Object Model was, dacht ik achteraf: “Is dat alles? “ Je hoeft de term POM niet te kennen, om op het idee te komen dat centraliseren van selectors voor elementen op een webpagina de onderhoudbaarheid van je code vergroot. En dat deze vervolgens groeperen per pagina een logische keuze is. Zelf zou ik dan ook de voorkeur geven aan een vraag, die meer vaardigheden dan woordgebruik checkt: Hoe zorg je dat je testautomatiseringscode goed onderhoudbaar blijft?

Ik vind dat we als testers altijd in ons achterhoofd moeten houden dat ieder van ons een plaatselijk test dialect spreekt. En daarom moeten onthouden dat “een raar antwoord krijgen” niet meteen inhoud dat een tester niet weet waar die het over heeft. Ook zou ik graag zien dat de vraag “Ik ken dat woord niet” als iets positiefs wordt gezien en niet als bewijs van gebrek aan senioriteit. En als laatste zou ik er sterk voor pleiten, dat we als testers onderling minder praten in “Gebruik je X” of “Doe je Y”, maar meer in “Hoe zorg je ervoor dat?” of “Welke stappen nam je om tot dit resultaat/besluit te komen?” Niet alleen zie ik hier mogelijkheden om spraakverwarring te voorkomen. Daarnaast voorkom je dat mensen door puur “woorden uit het hoofd leren” als senior over kunnen komen.

Chat GPT is een sterk hulpmiddel, maar geen toverstaf

Ik gebruik regelmatig Chat GPT, zowel privé als voor mijn werk. Dat betekend echter niet dat ik alles overlaat aan een AI. Wat ik belangrijk vind, zeker als tester, is dat ik in controle blijf. Dat maakt dat ik de volgende regels heb ontdekt bij het gebruik hiervan:

1. Ik moet het werk kunnen controleren qua kennis
2. Ik moet het werk kunnen controleren qua hoeveelheid
3. Ik bepaal de teststrategie of de testarchitectuur
4. Als ik een betrouwbaar resultaat wil, gebruik ik Chat GPT om een tool te creeeren, niet het belangrijke resultaat

De eerste twee spreken vrij voor zich en wordt door meer mensen aangeraden. Als je Chat GPT gebruikt, moet je niet meteen ervan uitgaan dat het resultaat betrouwbaar is. Daarom moet je in staat zijn het resultaat te controleren. Dit houdt in, dat ik het werk qua kennis grotendeels moet kunnen controleren. Voor code houdt dit in ,dat ik de code test. Voor belangrijke informatie houdt dit in, dat ik om bronnen vraag, als ik niet zelf genoeg kennis hebben voor controle.

Nog belangrijker is de hoeveelheid. Veel mensen gebruiken Chat GPT voor hele documenten of voor hele geprogrammeerde applicaties. Ik niet vaak. Ik vraag Chat GPT om functies, om concepten, om tool ideeën. En daarmee breidt ik mijn eigen werk stap voor stap uit. En daarmee is het een kleine stap naar teststrategie en architectuur. Als het om onderhoudbaarheid, betrouwbaarheid, volledigheid, enz. komt, ben ik in controle. Dus ik bepaal hoe het geheel eruit ziet. Juist door kleinere delen te laten genereren, in plaats van alles, ben ik in staat zelf de grote lijn neer te zetten.

En wat voor mij als tester het belangrijkste is: betrouwbaarheid. Waarom zou je Chat GPT 1 + 1 laten optellen, als een rekenmachine dat met 100% zekerheid goed kan uitvoeren. Als ik iets wil, dat aan vaste regels moet voldoen, dan laat ik dat niet door Chat GPT uitvoeren. Geen berekeningen, geen pairwise testing, geen generatie van test data. In plaats daarvan laat ik Chat GPT me helpen een tool de maken. Een tool, dat deze regels volgt. Een tool dat ik kan testen. Waarvan ik zelf de architectuur kan bepalen. Deel voor deel ontwikkeld. En waarvan ik zeker weet, dat het steeds een betrouwbaar resultaat geeft.

Chat GPT heeft niet als hoofddoel om betrouwbaar te zijn. Hoe meer betrouwbaarheid belangrijk is, hoe minder ik Chat GPT als direct tool gebruik om mijn doel te bereiken. Het kan uitstekend zijn voor het vinden van webpagina’s met de juiste informatie of helpen bij het maken van een goede functie. Waarmee het een uitstekend indirect tool wordt. Vaak beter dan een Google search of gevonden code, die ik anders zou kopiëren. Zolang ik in controle blijf, is het een sterk hulpmiddel. Anders een zeer onbetrouwbare collega.