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.