Van manueel klikken tot AI-driven QA: mijn reis als software tester (2014–2025)
By Kenny Sporck • 7 oktober 2025

Toen ik in 2014 begon als software tester, stapte ik binnen in een wereld die totaal anders was dan vandaag. Softwarekwaliteit werd toen vooral “verzekerd” door zware analyses en eindeloze documentatie. Ik herinner me master testplannen van tientallen pagina’s, testplannen die tot in de kleinste details beschreven hoe een knop getest moest worden, en testcases die één-op-één uitgevoerd werden.
Alles verliep in een watervalmethodologie: een lange analysefase, maanden bouwen, en dan kwam het testteam in actie. Regressiecycli duurden gerust drie tot vier weken en werden uitgevoerd door een volledig team testers. Het voelde vaak alsof we met z’n allen in een fabriek stonden: klikken, noteren, afvinken.
Documentatie werd netjes in Word of PDF aangeleverd, bugs werden met discipline gelogd in Excel of bugtracker. Maar dat betekende ook dat er gigantisch veel manuren verloren gingen aan repetitief en foutgevoelig werk. Elk foutje in de administratie – een verkeerd bugnummer, een vergeten teststap – kon tot misverstanden en tijdverlies leiden.
Ik heb in die beginjaren heel wat geleerd, vooral over discipline en nauwkeurigheid. Maar eerlijk gezegd voelde het vaak traag, log en vermoeiend. De creativiteit en snelheid die ik vandaag in QA ervaar, waren toen ondenkbaar.
De eerste stapjes richting automatisatie (2015–2017)
Mijn eerste concrete ervaring met automatisatie kwam eigenlijk nog vóór de echte hype. Als DTV tester bij een televisie-operator mocht ik meewerken aan het optimaliseren van de testinfrastructuur. Tot dan toe testten we elk toestel afzonderlijk, met aparte afstandsbedieningen en manuele inputs. Dat betekende dus letterlijk: toestel A aanzetten, knopjes indrukken, resultaat noteren. Daarna toestel B, opnieuw dezelfde cyclus. Urenlang.
De doorbraak kwam toen we een centrale IR receiver installeerden en alle toestellen hieraan koppelden. Plots konden we meerdere toestellen tegelijk aansturen, en bovendien werden de transportstromen configureerbaar via een centraal platform. Het was geen geautomatiseerde test zoals we die vandaag kennen, maar het voelde als een revolutie: infrastructuur slim inzetten om repetitief werk te vermijden.
Voor mij was dit een eyeopener: automatisatie hoeft niet altijd scripts of code te zijn. Slimme infrastructuurkeuzes konden ons ook al veel efficiënter maken.
De automatisatie-hype (2018–2020): Alles automatiseren!
Rond 2018 veranderde het landschap echt. UI-automatisatie kwam in een stroomversnelling en werd gezien als dé oplossing. Ik werkte op dat moment als software tester voor een webapplicatie en zag de shift van dichtbij gebeuren.
Mijn rol bestond steeds vaker uit het automatiseren van end-to-end scenario’s, alsof ik een eindklant was die door de applicatie klikte. Inloggen, een aankoop doen, door de checkout flow gaan – alles werd omgezet in scripts. De belofte: “Als de belangrijkste klantflows automatisch getest zijn, dan zijn we safe.”
En aanvankelijk voelde dat fantastisch. In plaats van telkens opnieuw diezelfde checkout test manueel uit te voeren, draaide ik een script en zag ik meteen het resultaat. Alleen bleek de praktijk minder rooskleurig: die scripts waren ontzettend fragiel.
Een kleine wijziging in de UI – een button-ID dat veranderde of een nieuw veld in een formulier – en de helft van mijn test suite lag plat. Dan zat ik uren of dagen te debuggen en te fixen. De energie die vrijkwam door repetitieve taken te vermijden, ging evengoed verloren aan onderhoud.
Dit was ook de periode waarin de sector massaal in de val trapte van het bekende automation ice cream cone antipatroon: een brede laag fragiele UI-tests bovenop een smalle basis van unit- en integratietests. Het zag er mooi uit in rapportages, maar in realiteit kostte het gigantisch veel tijd en leverde het minder waarde op dan gehoopt.
Voor mij persoonlijk was dit de periode waarin ik voor het eerst écht de SDET-rol begon te voelen: halve tester, halve developer. Er werd gesleuteld aan frameworks, pipelines en code. Nuttig, maar ik begon me af te vragen: Wie bewaakt hier nog de strategie, de risico’s, de focus op kwaliteit zelf?
IoT & shift-left (2020–2024): Tester als ontwikkelaar
De volgende golf kwam met de opkomst van IoT en gekoppelde systemen. Plots moest alles samen getest worden: embedded devices, mobiele apps, webplatformen en API’s. Ik werkte bijvoorbeeld op een platform waarbij een mobiele app, een API en hardwarecomponenten naadloos moesten samenwerken. Eén foutje in de firmware kon de hele keten verstoren.
Het antwoord van de sector was shift-left testing. Testen zo vroeg mogelijk in de lifecycle: tijdens analyse, development en integratie. CI/CD-pipelines werden standaard, testing op niveaus en subsystemen werd ingezet, en testers werden volwaardige developers in test.
Ik vond het boeiend dat die rol opkwam, maar tegelijk merkte ik dat de pet van de tester meer en meer verloren ging? Omdat we allemaal met techniek bezig waren, verdween soms de aandacht voor het grotere plaatje:
- Welke risico’s willen we écht afdekken?
- Wat test je manueel, wat automatiseer je?
- Waar zit de businesswaarde?
In retrospectives hoorde ik vaak uitspraken als: “We hebben honderden tests draaien, maar weten we eigenlijk of we de juiste dingen testen?” En dat raakte me. Want net daar zit de essentie van QA: niet méér, maar béter testen.
2025 en verder: AI als partner in kwaliteit
Vandaag, in 2025, zie ik opnieuw een verschuiving en die maakt me enthousiaster dan ooit. AI schuift mee aan tafel. Niet als gimmick, maar als serieuze partner in QA. Wat ik vroeger manueel moest bedenken of wekenlang moest scripten, kan AI nu versnellen of zelfs overnemen:
- AI analyseert requirements en stelt automatisch testcases voor.
- Het genereert synthetische testdata, inclusief randgevallen.
- Rapportages worden door AI gebundeld, zodat trends en risico’s sneller zichtbaar zijn.
- AI reviewt zelfs mijn automatisatiecode en geeft feedback op onderhoudbaarheid.
Dat geeft mij als tester eindelijk weer de ruimte om te focussen op wat écht telt: het maken van keuzes. Welke scenario’s zijn het belangrijkst? Waar ligt het risico? Hoe zorgen we dat QA niet alleen een kostenpost is, maar een strategisch voordeel? Voor mij voelt het alsof de cirkel meer gesloten wordt.
- In 2014 was ik uitvoerder van repetitieve manuele testen.
- In 2018 de tester die halve developer werd die scripts schreef.
- Vandaag de regisseur van kwaliteit – met AI als copiloot die het uitvoerend werk versnelt.
Slotgedachte
De afgelopen tien jaar heb ik QA zien evolueren van manueel klikken naar AI-driven strategie. Ik heb de traagheid van waterval meegemaakt, de hype van blinde automatisatie, de complexiteit van IoT en shift-left, en nu de belofte van AI.
Wat mij het meest is bijgebleven? Tools, frameworks en trends komen en gaan. Maar kwaliteit is nooit vanzelfsprekend. Het is geen Excel-sheet, geen framework en zelfs geen AI-model. Het is een mindset.
Of je nu tester, developer, analist of manager bent: de vraag blijft altijd dezelfde – maken we vandaag bewuste keuzes om waarde te leveren en risico’s te beheersen?
Dat is en blijft, voor mij, de kern van ons vak.
Meer van dit




