Agenda
Voorjaarsevenement 2026
| Datum | woensdag 6 mei 2026 |
| Tijd | 09:00 - 22:30u |
| Locatie |
NBC Nieuwegein
Blokhoeve 1 3438LC Nieuwegein |
We kijken terug op een gezellig en leerzaam voorjaarsevenement.
Hou deze pagina in de gaten voor updates van foto's en presentaties
Workshops
Ochtendprogramma: workshops
09:30 - 13:00Grand Hall | Rob van Steenbergen & Bram van den Berg
Stel de vraag aan tien mensen in de software-industrie wat testen is en je krijgt tien verschillende antwoorden. Stel de vraag wat de waarde is van testen en je krijgt opnieuw tien verschillende antwoorden, of zelfs helemaal geen antwoord. Als dat al het geval is bij deze relatief simpele vraag, hoe kun je dan bepalen waar je het testen kunt verbeteren?
Soms wordt vanuit een organisatie bepaald wat het gewenste niveau van testen is. Dit gaat vaak samen met eisen aan het testproces en audits om te meten of aan deze eisen wordt voldaan. Dit zijn meestal eisen vanuit een kwaliteitsmodel die managers prettig vinden, omdat iedereen in de organisatie op dezelfde manier zou moeten werken. Deze regels worden echter opgelegd aan teams en sluiten vaak niet aan bij de echte problemen binnen het team. Hoe krijg je die problemen dan wél boven tafel?
Als team ben je verantwoordelijk voor de kwaliteit van de software en je eigen werk. Een sessie met je team om dit samen te bespreken en te bepalen wat je gaat verbeteren, lijkt de beste optie. Maar hoe pak je dat aan?
In deze workshop gaan we in op wat testen is en hoe je daar met je team een goede discussie over kunt voeren. Dit doen we aan de hand van een visueel model waarop je alle testactiviteiten kunt plotten.
Onderdelen:
• Testactiviteiten visualiseren met het Agile Test Model (ATM)
• Testretrospective
• Acties documenteren en plannen
• Tips en tricks om zelf een workshop te geven
Stel de vraag aan tien mensen in de software-industrie wat testen is en je krijgt tien verschillende antwoorden. Stel de vraag wat de waarde is van testen en je krijgt opnieuw tien verschillende antwoorden, of zelfs helemaal geen antwoord. Als dat al het geval is bij deze relatief simpele vraag, hoe kun je dan bepalen waar je het testen kunt verbeteren?
Soms wordt vanuit een organisatie bepaald wat het gewenste niveau van testen is. Dit gaat vaak samen met eisen aan het testproces en audits om te meten of aan deze eisen wordt voldaan. Dit zijn meestal eisen vanuit een kwaliteitsmodel die managers prettig vinden, omdat iedereen in de organisatie op dezelfde manier zou moeten werken. Deze regels worden echter opgelegd aan teams en sluiten vaak niet aan bij de echte problemen binnen het team. Hoe krijg je die problemen dan wél boven tafel?
Als team ben je verantwoordelijk voor de kwaliteit van de software en je eigen werk. Een sessie met je team om dit samen te bespreken en te bepalen wat je gaat verbeteren, lijkt de beste optie. Maar hoe pak je dat aan?
In deze workshop gaan we in op wat testen is en hoe je daar met je team een goede discussie over kunt voeren. Dit doen we aan de hand van een visueel model waarop je alle testactiviteiten kunt plotten.
Onderdelen:
• Testactiviteiten visualiseren met het Agile Test Model (ATM)
• Testretrospective
• Acties documenteren en plannen
• Tips en tricks om zelf een workshop te geven
Zaal 1 | AI & BDD werkgroepen
Herken je dit? Als team heb je hard gewerkt aan een nieuwe feature. Het is goed ontwikkeld, de testen hebben aangetoond dat het werkt, maar tijdens de GAT (of erger: zodra het in productie staat) blijkt het toch niet helemaal aan de wensen en eisen van de eindgebruiker te voldoen?
Wat als je dit structureel kunt voorkomen?
In deze interactieve workshop ontdek je dat hier al ruim 10 jaar een doeltreffende methodiek voor bestaat: eerst samen helder maken wat het systeem moet doen, voor wie en waarom, voordat er ook maar één regel code wordt geschreven. En juist deze methodiek is in een tijd van AI, vibe coding en generatieve tooling belangrijker dan ooit!
Immers, als AI steeds meer code kan genereren, wordt de kwaliteit van de specificatie de echte bottleneck.
We laten zien hoe technieken uit BDD en specification driven development teams helpen om betere gesprekken te voeren, aannames zichtbaar te maken en gezamenlijk eigenaarschap te creëren over het probleem én de oplossing.
Tijdens de workshop ervaar je dit zelf aan de hand van een praktische casus. Je ontdekt hoe je met een paar relatief eenvoudige technieken:
sneller tot gedeeld begrip komt
misverstanden vroeg voorkomt
betere input creëert voor zowel developers, testers als AI-tools
Doe mee en ervaar hoe samenwerking aan de hand van technieken als Impact Mapping, Event Storming en Example Mapping de basis vormen voor betere software – vandaag én in het AI-tijdperk.
Herken je dit? Als team heb je hard gewerkt aan een nieuwe feature. Het is goed ontwikkeld, de testen hebben aangetoond dat het werkt, maar tijdens de GAT (of erger: zodra het in productie staat) blijkt het toch niet helemaal aan de wensen en eisen van de eindgebruiker te voldoen?
Wat als je dit structureel kunt voorkomen?
In deze interactieve workshop ontdek je dat hier al ruim 10 jaar een doeltreffende methodiek voor bestaat: eerst samen helder maken wat het systeem moet doen, voor wie en waarom, voordat er ook maar één regel code wordt geschreven. En juist deze methodiek is in een tijd van AI, vibe coding en generatieve tooling belangrijker dan ooit!
Immers, als AI steeds meer code kan genereren, wordt de kwaliteit van de specificatie de echte bottleneck.
We laten zien hoe technieken uit BDD en specification driven development teams helpen om betere gesprekken te voeren, aannames zichtbaar te maken en gezamenlijk eigenaarschap te creëren over het probleem én de oplossing.
Tijdens de workshop ervaar je dit zelf aan de hand van een praktische casus. Je ontdekt hoe je met een paar relatief eenvoudige technieken:
sneller tot gedeeld begrip komt
misverstanden vroeg voorkomt
betere input creëert voor zowel developers, testers als AI-tools
Doe mee en ervaar hoe samenwerking aan de hand van technieken als Impact Mapping, Event Storming en Example Mapping de basis vormen voor betere software – vandaag én in het AI-tijdperk.
Zaal 2 | Erik Haartmans & Arnie Schrage
Vibe coding is tegenwoordig een hot topic, ook in de test automation wereld. Iedereen wil dit want het is lekker makkelijk … maar is dat zo?
Deze hands-on workshop zal inzicht geven in het werken met Playwright en AI gerelateerde tools als MCP, CLI en Test Agents. Doel van de workshop is om zelf te zien hoe deze tools werken en of dit voldoet aan jouw eisen en wensen. Naast coderen zonder een letter te programmeren gaan we ook de discussie aan of dit ook goed (genoeg) is.
Vibe coding is tegenwoordig een hot topic, ook in de test automation wereld. Iedereen wil dit want het is lekker makkelijk … maar is dat zo?
Deze hands-on workshop zal inzicht geven in het werken met Playwright en AI gerelateerde tools als MCP, CLI en Test Agents. Doel van de workshop is om zelf te zien hoe deze tools werken en of dit voldoet aan jouw eisen en wensen. Naast coderen zonder een letter te programmeren gaan we ook de discussie aan of dit ook goed (genoeg) is.
Zaal 3 | Suzanne Kraaij & Boyd Kroneneberg
Wil je als tester sterker meedenken over kwaliteit over de gehele software development lifecycle? Beter meepraten met ontwikkelaars in de shift left? Of juist beter meepraten met operations in de shift right? Dan is deze workshop echt iets voor jou!
Tijdens deze workshop maak je kennis met verschillende kwaliteitsmaatregelen die ontwikkelaars, beheerders en architecten dagelijks gebruiken. Je ontdekt dat het toepassen van een Quality Engineering (QE) mindset helemaal niet ingewikkeld hoeft te zijn. Hoeveel weet je bijvoorbeeld over Blue/Green deployments, Post Mortems en Architecture Decision Records? Hoe nauw werk je samen met alle disciplines in de keten?
Door je kennis te verbreden met juist de niet-testspecifieke kwaliteitsmaatregelen, werk je aan je vakbekwaamheid als tester. Dit is in lijn met hoe wij Quality Engineering zien. Testen is daarin zeker belangrijk, maar het is slechts één onderdeel.
Deelnemers kunnen zelf kwaliteitsmaatregelen aandragen. Tijdens de workshop brainstormen we samen en gebruiken we een praktische lijst waarmee we direct aan de slag gaan.
Na afloop van de workshop heb je jouw toolbox van kwaliteitsmaatregelen verder uitgebreid en heb je de volgende stap gezet richting Quality Engineering.
Wil je als tester sterker meedenken over kwaliteit over de gehele software development lifecycle? Beter meepraten met ontwikkelaars in de shift left? Of juist beter meepraten met operations in de shift right? Dan is deze workshop echt iets voor jou!
Tijdens deze workshop maak je kennis met verschillende kwaliteitsmaatregelen die ontwikkelaars, beheerders en architecten dagelijks gebruiken. Je ontdekt dat het toepassen van een Quality Engineering (QE) mindset helemaal niet ingewikkeld hoeft te zijn. Hoeveel weet je bijvoorbeeld over Blue/Green deployments, Post Mortems en Architecture Decision Records? Hoe nauw werk je samen met alle disciplines in de keten?
Door je kennis te verbreden met juist de niet-testspecifieke kwaliteitsmaatregelen, werk je aan je vakbekwaamheid als tester. Dit is in lijn met hoe wij Quality Engineering zien. Testen is daarin zeker belangrijk, maar het is slechts één onderdeel.
Deelnemers kunnen zelf kwaliteitsmaatregelen aandragen. Tijdens de workshop brainstormen we samen en gebruiken we een praktische lijst waarmee we direct aan de slag gaan.
Na afloop van de workshop heb je jouw toolbox van kwaliteitsmaatregelen verder uitgebreid en heb je de volgende stap gezet richting Quality Engineering.
Zaal 4 | Bas Dijkstra
Wat weet jij eigenlijk over de kwaliteit van je geautomatiseerde tests?
Die vraag stel ik regelmatig, aan mijn klanten, maar ook aan de deelnemers aan mijn trainingen. En eigenlijk altijd krijg ik daar of geen antwoord op, of een antwoord gebaseerd op (een vorm van) code coverage.
Maar… code coverage alleen is niet genoeg. Het zegt niets over of je test wel in staat is om ongewenste wijzigingen in je code en het gedrag van je software te detecteren.
Mutation testing is een techniek die je kan helpen om meer te weten te komen over hoe goed je tests nu eigenlijk echt zijn. Dat was altijd al belangrijk, maar in een tijd waarin we onze tests (deels) door AI laten genereren is het testen van je tests essentieel.
In deze workshop gaan we aan de slag met mutation testing en zien we hoe moderne mutation testing tools werken, en welke informatie ze geven over de geautomatiseerde tests die we (zouden moeten kunnen) vertrouwen.
Na een korte introductie van het hoe en waarom van mutation testing, gaan we aan de slag met Java en PITest om een testsuite voor een API te analyseren en te verbeteren. In een aantal rondes gebruiken we PITest om de huidige testset te testen en de resultaten te leren begrijpen, en aan de hand daarvan gaan we onze testset verbeteren. Zo bouwen we stap voor stap aan een betere testset en testdekking voor onze API.
We sluiten af met een aantal tips en valkuilen waarmee de deelnemers na de conferentie kunnen beginnen met het toepassen van mutation testing in hun eigen project en codebase.
Wat weet jij eigenlijk over de kwaliteit van je geautomatiseerde tests?
Die vraag stel ik regelmatig, aan mijn klanten, maar ook aan de deelnemers aan mijn trainingen. En eigenlijk altijd krijg ik daar of geen antwoord op, of een antwoord gebaseerd op (een vorm van) code coverage.
Maar… code coverage alleen is niet genoeg. Het zegt niets over of je test wel in staat is om ongewenste wijzigingen in je code en het gedrag van je software te detecteren.
Mutation testing is een techniek die je kan helpen om meer te weten te komen over hoe goed je tests nu eigenlijk echt zijn. Dat was altijd al belangrijk, maar in een tijd waarin we onze tests (deels) door AI laten genereren is het testen van je tests essentieel.
In deze workshop gaan we aan de slag met mutation testing en zien we hoe moderne mutation testing tools werken, en welke informatie ze geven over de geautomatiseerde tests die we (zouden moeten kunnen) vertrouwen.
Na een korte introductie van het hoe en waarom van mutation testing, gaan we aan de slag met Java en PITest om een testsuite voor een API te analyseren en te verbeteren. In een aantal rondes gebruiken we PITest om de huidige testset te testen en de resultaten te leren begrijpen, en aan de hand daarvan gaan we onze testset verbeteren. Zo bouwen we stap voor stap aan een betere testset en testdekking voor onze API.
We sluiten af met een aantal tips en valkuilen waarmee de deelnemers na de conferentie kunnen beginnen met het toepassen van mutation testing in hun eigen project en codebase.
Zaal 5 | Sabine Frissen & Jens Don
In deze hands-on workshop ontdek je hoe je AI inzet als krachtige copilot bij het werken met Robot Framework. Je leert hoe AI je helpt om vanaf nul nieuwe testdocumentatie op te stellen die direct voldoet aan de documentatiestandaard van jouw organisatie, hoe je slimme keuzes maakt in je testarchitectuur, en hoe je razendsnel het volledige Robot Framework verkent. Bijvoorbeeld door gericht te vragen "welke keywords zijn er beschikbaar met login?" Robot
Framework fungeert daarbij als de kapstok waaraan alles samenkomt: AI zorgt ervoor dat je sneller, consistenter en doelgerichter werkt, maar weet je nog wel wat je test? Na deze workshop weet je hoe je AI niet als speeltje, maar als volwaardig hulpmiddel inzet in je dagelijkse testpraktijk.
In deze hands-on workshop ontdek je hoe je AI inzet als krachtige copilot bij het werken met Robot Framework. Je leert hoe AI je helpt om vanaf nul nieuwe testdocumentatie op te stellen die direct voldoet aan de documentatiestandaard van jouw organisatie, hoe je slimme keuzes maakt in je testarchitectuur, en hoe je razendsnel het volledige Robot Framework verkent. Bijvoorbeeld door gericht te vragen "welke keywords zijn er beschikbaar met login?" Robot
Framework fungeert daarbij als de kapstok waaraan alles samenkomt: AI zorgt ervoor dat je sneller, consistenter en doelgerichter werkt, maar weet je nog wel wat je test? Na deze workshop weet je hoe je AI niet als speeltje, maar als volwaardig hulpmiddel inzet in je dagelijkse testpraktijk.
Middagprogramma
14:00 - 17:30Grand Hall | Kristof van Kriekingen
In the depths of the internet lurks the shadows where the nefarious operate – child abusers, drug dealers, and weapon peddlers. However, amidst these dark corners lies a beacon of hope – Open-Source Intelligence (OSINT) Researchers. This innovative approach combines the power of both the dark web and traditional OSINT techniques to combat these evil crimes and aid in the search for missing individuals.
Join me as I delve into the details of OSINT, exploring how it empowers investigators to shine a light into the abyss of criminality through Crowd Sourced OSINT.
I’ll demonstrate how OSINT serves as a crucial ally in the fight against child abuse, drug trafficking, weapon proliferation, and the scourge of missing people. Prepare to embark on a journey into the shadows, where every clue uncovered brings us one step closer to making the world a safer place.
Be careful about what you post online. I’ll show some creepy tips & tricks to trace people’s home address, locations, fingerprints, old photos and so much more.
This is not a session for the paranoid. See you there!
In the depths of the internet lurks the shadows where the nefarious operate – child abusers, drug dealers, and weapon peddlers. However, amidst these dark corners lies a beacon of hope – Open-Source Intelligence (OSINT) Researchers. This innovative approach combines the power of both the dark web and traditional OSINT techniques to combat these evil crimes and aid in the search for missing individuals.
Join me as I delve into the details of OSINT, exploring how it empowers investigators to shine a light into the abyss of criminality through Crowd Sourced OSINT.
I’ll demonstrate how OSINT serves as a crucial ally in the fight against child abuse, drug trafficking, weapon proliferation, and the scourge of missing people. Prepare to embark on a journey into the shadows, where every clue uncovered brings us one step closer to making the world a safer place.
Be careful about what you post online. I’ll show some creepy tips & tricks to trace people’s home address, locations, fingerprints, old photos and so much more.
This is not a session for the paranoid. See you there!
Zaal 1 | AI & BDD werkgroepen
Naarmate AI een steeds grotere rol speelt in softwareontwikkeling, wordt kwaliteit niet minder belangrijk, het wordt juist kritischer. Hoe zorgen we ervoor dat we de juiste dingen bouwen? En hoe voorkomen we problemen voordat ze ontstaan?
Behaviour-Driven Development (BDD) biedt al jaren een aanpak om de samenwerking te verbeteren tussen business, development en testing. Maar wat als we GenAI als actieve deelnemer in dit proces zouden inzetten? In deze sessie delen we de inzichten van twee werkgroepen (AI en BDD) die de handen ineen hebben geslagen om te onderzoeken hoe ze elkaar kunnen versterken.
We zijn gestart met focussen op de discovery fase binnen BDD en zijn vier concrete toepassingen van GenAI binnen BDD aan het onderzoeken:
– GenAI als Fourth Amigo
– GenAI als Context Assistant
– GenAI als DSL Translator
– GenAI als Discovery Facilitator
Voor elk onderwerp delen we onze experimenten, de verrassende inzichten én de grenzen die we tegenkwamen.
Naarmate AI een steeds grotere rol speelt in softwareontwikkeling, wordt kwaliteit niet minder belangrijk, het wordt juist kritischer. Hoe zorgen we ervoor dat we de juiste dingen bouwen? En hoe voorkomen we problemen voordat ze ontstaan?
Behaviour-Driven Development (BDD) biedt al jaren een aanpak om de samenwerking te verbeteren tussen business, development en testing. Maar wat als we GenAI als actieve deelnemer in dit proces zouden inzetten? In deze sessie delen we de inzichten van twee werkgroepen (AI en BDD) die de handen ineen hebben geslagen om te onderzoeken hoe ze elkaar kunnen versterken.
We zijn gestart met focussen op de discovery fase binnen BDD en zijn vier concrete toepassingen van GenAI binnen BDD aan het onderzoeken:
– GenAI als Fourth Amigo
– GenAI als Context Assistant
– GenAI als DSL Translator
– GenAI als Discovery Facilitator
Voor elk onderwerp delen we onze experimenten, de verrassende inzichten én de grenzen die we tegenkwamen.
Zaal 2 | Heini Veneberg
Je ziet organisaties AI omarmen als onderdeel van hun SDLC. De reden: we kunnen met minder mensen sneller functionaliteit realiseren, in een tijd waarin het vinden van goede mensen steeds meer een aandachtspunt wordt. Misschien staan we wel aan de vooravond van een nieuwe industriële revolutie.
In mijn eerste ervaringen zie ik ook een terugkeer van de problemen waarmee wij als testers worden geconfronteerd. Het lijkt wel dweilen met de kraan open als het gaat om bugs die we vinden. Je kunt het bijna niet bijbenen hoe snel de volgende versie komt, met fixes, nieuwe functionaliteit én omgevallen functionaliteit. Herkenbaar? Het lijkt wel een ‘beginnend’ softwareontwikkelingsteam.
Wat kunnen wij als QA nu doen? In mijn presentatie wil ik ingaan op de verschuiving van bug-finder naar risico-regisseur, hoe technische schuld verschuift naar testschuld, en de impact van hallucinaties in businesslogica en securitykwetsbaarheden. Natuurlijk sta ik ook stil bij hoe wij AI zelf kunnen gebruiken. Wat betekent dit voor ons vak? Kan AI ons werk overnemen?
Mijn eerste indruk is dat we het moeten omarmen en moeten meegroeien. Met mijn presentatie wil ik je bewust maken van deze revolutie en je laten nadenken over hoe jij je hierop kunt instellen.
Je ziet organisaties AI omarmen als onderdeel van hun SDLC. De reden: we kunnen met minder mensen sneller functionaliteit realiseren, in een tijd waarin het vinden van goede mensen steeds meer een aandachtspunt wordt. Misschien staan we wel aan de vooravond van een nieuwe industriële revolutie.
In mijn eerste ervaringen zie ik ook een terugkeer van de problemen waarmee wij als testers worden geconfronteerd. Het lijkt wel dweilen met de kraan open als het gaat om bugs die we vinden. Je kunt het bijna niet bijbenen hoe snel de volgende versie komt, met fixes, nieuwe functionaliteit én omgevallen functionaliteit. Herkenbaar? Het lijkt wel een ‘beginnend’ softwareontwikkelingsteam.
Wat kunnen wij als QA nu doen? In mijn presentatie wil ik ingaan op de verschuiving van bug-finder naar risico-regisseur, hoe technische schuld verschuift naar testschuld, en de impact van hallucinaties in businesslogica en securitykwetsbaarheden. Natuurlijk sta ik ook stil bij hoe wij AI zelf kunnen gebruiken. Wat betekent dit voor ons vak? Kan AI ons werk overnemen?
Mijn eerste indruk is dat we het moeten omarmen en moeten meegroeien. Met mijn presentatie wil ik je bewust maken van deze revolutie en je laten nadenken over hoe jij je hierop kunt instellen.
Zaal 5 | Tom Broekmans
Unit Testing is één van de best practices die een ontwikkelaar kan doen. Het is snel, efficiënt & krachtig. Het draagt een groot steentje bij aan de kwaliteit van software. Maar met de opkomst van AI-coding & -testing en Vibe-coding & -testing komt Unit Testing in het gedrang. Immers, hoe maak ik tests voor code die ik niet zelf heb geschreven ? Hoe onderhoud ik tests voor code die ik niet zelf gewijzigd heb ? Menige ontwikkelaar raakt bij deze gedachten al in lichte paniek. Welcome to the Dark Side!
Gelukkig is de redding nabij. Wij – testers en test automatiseerders – kunnen de ontwikkelaars helpen. Wij zijn immers de “Rebels of Quality”. Wij kunnen ontwikkelaars ondersteunen met bijvoorbeeld risico-analyses en functionele decomposities. Wij hebben de know-how om de juiste tests te ontwerpen en weg te laten. En wij kunnen ontwikkelaars helpen om kritische vragen te stellen over hun code.
Laat je meenemen met een nieuw Star Wars verhaal over hoe testers het unit testen kunnen ondersteunen. Ontdek welke middelen testers hebben om ontwikkelaars te helpen. Ervaar hoe een verandering van mind set de samenwerking tussen tester, ontwikkelaar en AI kan verbeteren.
En daag de ontwikkelaars uit: “Join the Light Side of Unit Testing!”
Unit Testing is één van de best practices die een ontwikkelaar kan doen. Het is snel, efficiënt & krachtig. Het draagt een groot steentje bij aan de kwaliteit van software. Maar met de opkomst van AI-coding & -testing en Vibe-coding & -testing komt Unit Testing in het gedrang. Immers, hoe maak ik tests voor code die ik niet zelf heb geschreven ? Hoe onderhoud ik tests voor code die ik niet zelf gewijzigd heb ? Menige ontwikkelaar raakt bij deze gedachten al in lichte paniek. Welcome to the Dark Side!
Gelukkig is de redding nabij. Wij – testers en test automatiseerders – kunnen de ontwikkelaars helpen. Wij zijn immers de “Rebels of Quality”. Wij kunnen ontwikkelaars ondersteunen met bijvoorbeeld risico-analyses en functionele decomposities. Wij hebben de know-how om de juiste tests te ontwerpen en weg te laten. En wij kunnen ontwikkelaars helpen om kritische vragen te stellen over hun code.
Laat je meenemen met een nieuw Star Wars verhaal over hoe testers het unit testen kunnen ondersteunen. Ontdek welke middelen testers hebben om ontwikkelaars te helpen. Ervaar hoe een verandering van mind set de samenwerking tussen tester, ontwikkelaar en AI kan verbeteren.
En daag de ontwikkelaars uit: “Join the Light Side of Unit Testing!”
Zaal 3 | Dean Bodart
AI bouwen voor software testers is niet voor mietjes; het is als een koorddans boven een ravijn vol professionele sceptici die ervan leven om "perfecte" oplossingen vakkundig te slopen. In deze sessie deelt Dean (SQAI Suite) de rauwe lessen uit de "Seven Hells" van het ontwikkelen van een AI-platform voor de meest kritische doelgroep op de planeet. De centrale boodschap: als je AI-tool deze kamer vol critici overleeft, is het pas echt bulletproof.
Bezoekers leren:
Waarom "bijna goed" in de testwereld direct een enkeltje prullenbak betekent.
Hoe je genadeloze kritiek ombuigt naar een onverwoestbare roadmap.
De shift van gebakken AI-lucht naar praktische utility waar een tester écht wat aan heeft.
Hoe je vertrouwen wint van mensen die betaald worden om achterdochtig te zijn.
AI bouwen voor software testers is niet voor mietjes; het is als een koorddans boven een ravijn vol professionele sceptici die ervan leven om "perfecte" oplossingen vakkundig te slopen. In deze sessie deelt Dean (SQAI Suite) de rauwe lessen uit de "Seven Hells" van het ontwikkelen van een AI-platform voor de meest kritische doelgroep op de planeet. De centrale boodschap: als je AI-tool deze kamer vol critici overleeft, is het pas echt bulletproof.
Bezoekers leren:
Waarom "bijna goed" in de testwereld direct een enkeltje prullenbak betekent.
Hoe je genadeloze kritiek ombuigt naar een onverwoestbare roadmap.
De shift van gebakken AI-lucht naar praktische utility waar een tester écht wat aan heeft.
Hoe je vertrouwen wint van mensen die betaald worden om achterdochtig te zijn.
Zaal 4 | Karl van Heijster
Testen is cruciaal voor softwarekwaliteit. En toch, toen ik de kans kreeg een nieuw agile softwareteam samen te stellen, "vergat" ik de tester. Hoe verklaren we deze paradox? Hoe kan een tester tegelijkertijd zó belangrijk en toch ongewenst zijn?
Met hulp van systeemdenken laat ik zien hoe goedbedoelde testrollen onbedoeld kwaliteitsproblemen kunnen veroorzaken - en hoe we dat kunnen doorbreken. Gebaseerd op praktijkervaringen laat ik zien welke patronen tussen testers en ontwikkelaars de kwaliteit ondermijnen, en hoe een alternatieve rolverdeling juist tot betere software leidt.
Na deze sessie herken je schadelijke dynamieken in je eigen team, en weet je hoe je testen weer een gedeelde verantwoordelijkheid maakt.
Testen is cruciaal voor softwarekwaliteit. En toch, toen ik de kans kreeg een nieuw agile softwareteam samen te stellen, "vergat" ik de tester. Hoe verklaren we deze paradox? Hoe kan een tester tegelijkertijd zó belangrijk en toch ongewenst zijn?
Met hulp van systeemdenken laat ik zien hoe goedbedoelde testrollen onbedoeld kwaliteitsproblemen kunnen veroorzaken - en hoe we dat kunnen doorbreken. Gebaseerd op praktijkervaringen laat ik zien welke patronen tussen testers en ontwikkelaars de kwaliteit ondermijnen, en hoe een alternatieve rolverdeling juist tot betere software leidt.
Na deze sessie herken je schadelijke dynamieken in je eigen team, en weet je hoe je testen weer een gedeelde verantwoordelijkheid maakt.
Grand Hall | Voorzitter TestNet
Opening van het voorjaarsevenement door de voorzitter van TestNet
Opening van het voorjaarsevenement door de voorzitter van TestNet
Avondprogramma
18:30 - 22:30Zaal 5 | Gilbert Smulders
Tegenwoordig werken bijna alle testers in een Agile of DevOps omgeving. Dat betekent dat procesverbetering over het algemeen wordt opgepakt via de retrospective. Echter worden daar vaak alleen de dagelijkse problemen aangepakt. De structurele procesverbetering over de verschillende teams heen blijft daarbij vaak onderbelicht. Een verbetermodel zoals TMMi kan hierbij uitkomst bieden. Alleen hebben theorieën en verbetermodellen vaak het imago niet op onze moderne werkwijze te passen. TMMi heeft daarom uitbreidingen geschreven voor Agile en DevOps. Hoe pas je testprocesverbetering toe in dit soort situaties? Tijdens deze presentatie krijg je daar meer beeld bij.
Tegenwoordig werken bijna alle testers in een Agile of DevOps omgeving. Dat betekent dat procesverbetering over het algemeen wordt opgepakt via de retrospective. Echter worden daar vaak alleen de dagelijkse problemen aangepakt. De structurele procesverbetering over de verschillende teams heen blijft daarbij vaak onderbelicht. Een verbetermodel zoals TMMi kan hierbij uitkomst bieden. Alleen hebben theorieën en verbetermodellen vaak het imago niet op onze moderne werkwijze te passen. TMMi heeft daarom uitbreidingen geschreven voor Agile en DevOps. Hoe pas je testprocesverbetering toe in dit soort situaties? Tijdens deze presentatie krijg je daar meer beeld bij.
Grand Hall | Voorzitter TestNet
Afsluiting van de dag en zoals elk evenement een verloting van een ticket naar AutomationStar, dit jaar in Antwerpen op 4 en 5 november.
Afsluiting van de dag en zoals elk evenement een verloting van een ticket naar AutomationStar, dit jaar in Antwerpen op 4 en 5 november.
Grand Hall |
Mocktails, borrelhapjes, netwerken en informatiemarkt
Mocktails, borrelhapjes, netwerken en informatiemarkt
Grand Hall | Felienne Hermans
Wat is AI? Waar is AI voor en wat zijn de doelen? Het zou makkelijk zijn om in 2026 te geloven dat AI onmiskenbaar goed is en dat iedereen dat altijd al heeft gedacht. Door de geschiedenis heen hebben veel verschillende stemmen echter kritische vragen gesteld over AI en andere vormen van technologie, van Socrates tot Ada Lovelace, Martin Luther King tot Emily M. Bender. In deze lezing neemt Felienne je mee door de alternatieve geschiedenis van AI en wat we kunnen leren van meer dan een eeuw aan techkritiek, en bespreekt wat we daarvan kunnen leren voor de huidige staat van programmeren.
Wat is AI? Waar is AI voor en wat zijn de doelen? Het zou makkelijk zijn om in 2026 te geloven dat AI onmiskenbaar goed is en dat iedereen dat altijd al heeft gedacht. Door de geschiedenis heen hebben veel verschillende stemmen echter kritische vragen gesteld over AI en andere vormen van technologie, van Socrates tot Ada Lovelace, Martin Luther King tot Emily M. Bender. In deze lezing neemt Felienne je mee door de alternatieve geschiedenis van AI en wat we kunnen leren van meer dan een eeuw aan techkritiek, en bespreekt wat we daarvan kunnen leren voor de huidige staat van programmeren.
Zaal 5 | Roy de Kleijn
Key message:
Stop relying on cloud-based tools with their often unpredictable pricing models for API testing. Build local, secure sensitive data and integrate seamlessly into your own pipeline.
Abstract:
Other API testing tools are bloated, sometimes slow, and send your test data to the cloud. In this session I'll show you how to set up a fully-fledged API testing strategy with API Spector, an open, local, and secure alternative, ranging from exploratory testing to automated CI-pipelines.
What you'll take away:
- You'll learn how to pass variables between requests using pre/post-scripts, chaining calls like login, token retrieval, and the next request.
- Contract testing comes built in, covering both consumer and provider verification.
- Code generation lets you turn recorded requests into Playwright, SuperTest, Robot Framework, or RestAssured tests in a single click.
- The CLI runner brings the same tests and the same logic straight into your CI/CD pipeline.
- And with the built-in mock server, you can develop without depending on a live backend.
Suitable for testers, developers, and teams looking to level up their API testing strategy without vendor lock-in.
Key message:
Stop relying on cloud-based tools with their often unpredictable pricing models for API testing. Build local, secure sensitive data and integrate seamlessly into your own pipeline.
Abstract:
Other API testing tools are bloated, sometimes slow, and send your test data to the cloud. In this session I'll show you how to set up a fully-fledged API testing strategy with API Spector, an open, local, and secure alternative, ranging from exploratory testing to automated CI-pipelines.
What you'll take away:
- You'll learn how to pass variables between requests using pre/post-scripts, chaining calls like login, token retrieval, and the next request.
- Contract testing comes built in, covering both consumer and provider verification.
- Code generation lets you turn recorded requests into Playwright, SuperTest, Robot Framework, or RestAssured tests in a single click.
- The CLI runner brings the same tests and the same logic straight into your CI/CD pipeline.
- And with the built-in mock server, you can develop without depending on a live backend.
Suitable for testers, developers, and teams looking to level up their API testing strategy without vendor lock-in.
Zaal 4 | Simardeep Singh
In 2,5 jaar tijd ben ik gegroeid van een startende quality engineer naar een test manager die kwaliteitsverbeteringen toepast en erover adviseert.
Tijdens deze sessie neem ik de deelnemers mee in mijn reis bij een snelgroeiend telecombedrijf, waar de uitdagingen op het gebied van quality engineering zich razendsnel opstapelden. Ik laat zien hoe ik het vertrouwen heb gewonnen om die uitdagingen aan te pakken en hoe ik ben gegroeid door anderen actief op te zoeken.
We verkennen hoe je knelpunten snel kunt herkennen en hoe je ze bespreekbaar maakt binnen verschillende teams. Ik geef ook mee hoe je draagvlak creëert voor je ideeën, zelfs wanneer de organisatie in beweging is en de druk hoog ligt.
Een belangrijk onderdeel van deze sessie is de vraag: waar begin je? Ik deel praktische handvatten die deelnemers direct kunnen toepassen bij hun eigen klant of project.
Onderwerpen die voorbij komen zijn onder andere risk-based testing en het opzetten van chapters. Maar bovenal draait deze sessie om community en verbinding: hoe je groeit door samen te werken, hoe je de kracht van je omgeving benut en hoe je zo zelfvertrouwen opbouwt in je eigen ideeën en in de impact die jij kunt maken.
In 2,5 jaar tijd ben ik gegroeid van een startende quality engineer naar een test manager die kwaliteitsverbeteringen toepast en erover adviseert.
Tijdens deze sessie neem ik de deelnemers mee in mijn reis bij een snelgroeiend telecombedrijf, waar de uitdagingen op het gebied van quality engineering zich razendsnel opstapelden. Ik laat zien hoe ik het vertrouwen heb gewonnen om die uitdagingen aan te pakken en hoe ik ben gegroeid door anderen actief op te zoeken.
We verkennen hoe je knelpunten snel kunt herkennen en hoe je ze bespreekbaar maakt binnen verschillende teams. Ik geef ook mee hoe je draagvlak creëert voor je ideeën, zelfs wanneer de organisatie in beweging is en de druk hoog ligt.
Een belangrijk onderdeel van deze sessie is de vraag: waar begin je? Ik deel praktische handvatten die deelnemers direct kunnen toepassen bij hun eigen klant of project.
Onderwerpen die voorbij komen zijn onder andere risk-based testing en het opzetten van chapters. Maar bovenal draait deze sessie om community en verbinding: hoe je groeit door samen te werken, hoe je de kracht van je omgeving benut en hoe je zo zelfvertrouwen opbouwt in je eigen ideeën en in de impact die jij kunt maken.
Zaal 3 | Anko Tijman
In een wereld vol technologie waarin ketens steeds bedrijfskritischer en onoverzichtelijker worden, word je als tester gedwongen om nauw samen te werken. En dat is een fikse uitdaging met verschillende belangen, roadmaps en vooral: mensen die soms héél anders in de wedstrijd zitten dan jij!
Om effectieve samenwerking tot stand te brengen moet je de kwaliteit van je eigen interacties verhogen! De eerste stap is jezelf kennen: wat zijn mijn sterktes en zwaktes, mijn voorkeuren en mijn profiel. Stap 2 is de profielen van andere leren ontdekken en goed in staat zijn om de verschillen te overbruggen. Dat doe je door je eigen gedrag aan te passen! Stap 3 is verschillen waarderen en technieken hebben om slim om te gaan met ogenschijnlijke tegenstellingen. In deze sessie krijg je vanuit principes van interpersoonlijk leiderschap concrete handreikingen om hiermee morgen aan de slag te gaan. Ook als je een ander profiel hebt als ik 😉
In een wereld vol technologie waarin ketens steeds bedrijfskritischer en onoverzichtelijker worden, word je als tester gedwongen om nauw samen te werken. En dat is een fikse uitdaging met verschillende belangen, roadmaps en vooral: mensen die soms héél anders in de wedstrijd zitten dan jij!
Om effectieve samenwerking tot stand te brengen moet je de kwaliteit van je eigen interacties verhogen! De eerste stap is jezelf kennen: wat zijn mijn sterktes en zwaktes, mijn voorkeuren en mijn profiel. Stap 2 is de profielen van andere leren ontdekken en goed in staat zijn om de verschillen te overbruggen. Dat doe je door je eigen gedrag aan te passen! Stap 3 is verschillen waarderen en technieken hebben om slim om te gaan met ogenschijnlijke tegenstellingen. In deze sessie krijg je vanuit principes van interpersoonlijk leiderschap concrete handreikingen om hiermee morgen aan de slag te gaan. Ook als je een ander profiel hebt als ik 😉
Zaal 2 | Ard Kramer & Laurens Kramer
Wij, software testers, moeten vooral niet denken dat we de enige zijn die testen (en ja dat is een open deur). In ieder geval kan het niet kwaad om af en toe eens om ons heen te kijken, hoe ‘anderen’ testen. In dit specifieke geval een sportarts.
In onze presentatie komt aan de orde hoe een sportarts met testen omgaat (en natuurlijk gericht op het hart waarbij we graag ook de nieren willen proeven van de sportarts). Hierbij zullen we kijken naar verschillende invalshoeken waarbij de verschillen en overeenkomsten in de aanpak, tools, rapportage aan de orde komen.
We willen dit doen in een tweegesprek aan de hand van een aantal vragen, zoals
- Hoe maak je een goede risico-inschatting, van een systeem onder test versus een sporter (zowel in de spreekkamer als op het sportveld)?
- Hoe worden de testuitkomsten bepaald, welke testprocessen worden daarbij gevolgd?
- Hoe sluit een testaanpak aan op basis van de complexiteit van het systeem of de software die je test? Zou een vergelijkbare benadering werken voor fysieke tests bij mensen? En welke tools kunnen hierbij gebruikt worden?
- Hoe geef je goed feedback over de testresultaten? Wat kunnen we leren van een sportarts waar de patiënt ook het testobject is?
We willen ook ruimte aan het publiek geven om ook nog een aantal vragen te stellen, gerelateerd worden aan het thema (Vragen over persoonlijke klachten worden niet in behandeling genomen 😉). We hopen hiermee meer inzichten te geven in de afwegingen van een testende sportarts versus een software tester, waarmee onze kijk op testen verrijkt kan worden.
Wij, software testers, moeten vooral niet denken dat we de enige zijn die testen (en ja dat is een open deur). In ieder geval kan het niet kwaad om af en toe eens om ons heen te kijken, hoe ‘anderen’ testen. In dit specifieke geval een sportarts.
In onze presentatie komt aan de orde hoe een sportarts met testen omgaat (en natuurlijk gericht op het hart waarbij we graag ook de nieren willen proeven van de sportarts). Hierbij zullen we kijken naar verschillende invalshoeken waarbij de verschillen en overeenkomsten in de aanpak, tools, rapportage aan de orde komen.
We willen dit doen in een tweegesprek aan de hand van een aantal vragen, zoals
- Hoe maak je een goede risico-inschatting, van een systeem onder test versus een sporter (zowel in de spreekkamer als op het sportveld)?
- Hoe worden de testuitkomsten bepaald, welke testprocessen worden daarbij gevolgd?
- Hoe sluit een testaanpak aan op basis van de complexiteit van het systeem of de software die je test? Zou een vergelijkbare benadering werken voor fysieke tests bij mensen? En welke tools kunnen hierbij gebruikt worden?
- Hoe geef je goed feedback over de testresultaten? Wat kunnen we leren van een sportarts waar de patiënt ook het testobject is?
We willen ook ruimte aan het publiek geven om ook nog een aantal vragen te stellen, gerelateerd worden aan het thema (Vragen over persoonlijke klachten worden niet in behandeling genomen 😉). We hopen hiermee meer inzichten te geven in de afwegingen van een testende sportarts versus een software tester, waarmee onze kijk op testen verrijkt kan worden.
Zaal 1 | Mickel Jacobs
In veel teams wordt testdata primair functioneel benaderd: ondersteunt deze data het scherm, de flow of het proces dat we testen? Dat werkt, tot het niet meer werkt. Zodra data complexer wordt, ontstaan instabiliteit, onvoorspelbaarheid en frustratie. Testautomatisering wordt kwetsbaar, frameworks worden lastig te onderhouden en data moet steeds opnieuw worden opgebouwd of gerepareerd. Teams herkennen deze symptomen, maar missen vaak een structurele manier om ermee om te gaan. Data blijft een noodzakelijk kwaad, in plaats van een krachtig fundament.
Mijn grootste inzicht: functioneel kijken is niet genoeg! Echte vooruitgang ontstond pas toen ik testdata begon te zien zoals data engineers dat doen: niet als statische input, maar als een systeem. Als een stroom. Iets dat je moet begrijpen, modelleren en beheersen. Wanneer data het centrale perspectief wordt, komen problemen en patronen aan het licht die je functioneel nooit ziet. Dat perspectief maakt complexiteit hanteerbaar en vereenvoudigt testautomatisering fundamenteel.
In deze sessie deel ik de principes, patronen en denkrichtingen die mij hebben geholpen om data van bijzaak naar middelpunt te brengen. Je gaat naar huis met concrete inzichten om morgen al anders naar je testdata te kijken, zodat je testautomatisering voorspelbaarder, robuuster en aantoonbaar effectiever wordt.
In veel teams wordt testdata primair functioneel benaderd: ondersteunt deze data het scherm, de flow of het proces dat we testen? Dat werkt, tot het niet meer werkt. Zodra data complexer wordt, ontstaan instabiliteit, onvoorspelbaarheid en frustratie. Testautomatisering wordt kwetsbaar, frameworks worden lastig te onderhouden en data moet steeds opnieuw worden opgebouwd of gerepareerd. Teams herkennen deze symptomen, maar missen vaak een structurele manier om ermee om te gaan. Data blijft een noodzakelijk kwaad, in plaats van een krachtig fundament.
Mijn grootste inzicht: functioneel kijken is niet genoeg! Echte vooruitgang ontstond pas toen ik testdata begon te zien zoals data engineers dat doen: niet als statische input, maar als een systeem. Als een stroom. Iets dat je moet begrijpen, modelleren en beheersen. Wanneer data het centrale perspectief wordt, komen problemen en patronen aan het licht die je functioneel nooit ziet. Dat perspectief maakt complexiteit hanteerbaar en vereenvoudigt testautomatisering fundamenteel.
In deze sessie deel ik de principes, patronen en denkrichtingen die mij hebben geholpen om data van bijzaak naar middelpunt te brengen. Je gaat naar huis met concrete inzichten om morgen al anders naar je testdata te kijken, zodat je testautomatisering voorspelbaarder, robuuster en aantoonbaar effectiever wordt.
Zaal 4 | Simon Koudijs
Veel veranderingen met productie-impact zitten niet in code, maar in configuratie. Dat begrip is bovendien breder dan vaak wordt gedacht: van business rules, feature flags en content tot rate limits, deployment-instellingen en connectiedetails voor databases. Juist doordat configuratie zo breed en verspreid kan zijn, is het vaak onduidelijk wat er precies onder valt, wie het mag aanpassen en hoe je zulke wijzigingen goed test.
In deze sessie laat ik zien waarom dat een kwaliteitsprobleem is, en hoe je configuratiewijzigingen zichtbaar, reviewbaar en testbaar maakt vóór productie. Aan de hand van een concreet voorbeeld laat ik zien hoe een wijziging via een pull request een tijdelijke omgeving krijgt, zodat de impact vooraf bekeken en getest kan worden.
Juist nu AI het makkelijker maakt om snel wijzigingen door te voeren, wordt die vraag urgenter. Ook configuratie wordt sneller aangepast, vaak door mensen die “even” iets willen veranderen. De kern van de sessie is daarom bewustwording: configuratiewijzigingen zijn in de praktijk vaak net zo risicovol als codewijzigingen, en verdienen ook een zorgvuldig proces.
Veel veranderingen met productie-impact zitten niet in code, maar in configuratie. Dat begrip is bovendien breder dan vaak wordt gedacht: van business rules, feature flags en content tot rate limits, deployment-instellingen en connectiedetails voor databases. Juist doordat configuratie zo breed en verspreid kan zijn, is het vaak onduidelijk wat er precies onder valt, wie het mag aanpassen en hoe je zulke wijzigingen goed test.
In deze sessie laat ik zien waarom dat een kwaliteitsprobleem is, en hoe je configuratiewijzigingen zichtbaar, reviewbaar en testbaar maakt vóór productie. Aan de hand van een concreet voorbeeld laat ik zien hoe een wijziging via een pull request een tijdelijke omgeving krijgt, zodat de impact vooraf bekeken en getest kan worden.
Juist nu AI het makkelijker maakt om snel wijzigingen door te voeren, wordt die vraag urgenter. Ook configuratie wordt sneller aangepast, vaak door mensen die “even” iets willen veranderen. De kern van de sessie is daarom bewustwording: configuratiewijzigingen zijn in de praktijk vaak net zo risicovol als codewijzigingen, en verdienen ook een zorgvuldig proces.
Zaal 3 | Vincent Vonk & Menno van den Berg
Met de opkomst van AI-assistenten en vibe coding groeit de capability van ontwikkelteams razendsnel. Code, tests en analyses kunnen tegenwoordig in minuten worden gegenereerd. Taken die vroeger specialistische kennis vereisten, worden steeds toegankelijker ervaren met behulp van tooling.
Maar verhoogt AI werkelijk de capability van teams, of creëert het vooral de illusie daarvan?
In deze sessie verkennen we het spanningsveld tussen capability en commitment in een AI-gedreven ontwikkelomgeving. Wat gebeurt er met professioneel testvakmanschap wanneer AI een groot deel van het werk kan genereren? Wanneer is AI een echte capability-versterker, en wanneer slechts een “one-trick pony”? En hoe zorgen organisaties ervoor dat snelheid en tooling niet ten koste gaan van kritisch denken en verantwoordelijkheid voor kwaliteit?
Aan de hand van ons beider praktijkervaring bespreken we hoe teams AI effectief kunnen inzetten zonder het commitment aan kwaliteit en vakmanschap te verliezen.
Met de opkomst van AI-assistenten en vibe coding groeit de capability van ontwikkelteams razendsnel. Code, tests en analyses kunnen tegenwoordig in minuten worden gegenereerd. Taken die vroeger specialistische kennis vereisten, worden steeds toegankelijker ervaren met behulp van tooling.
Maar verhoogt AI werkelijk de capability van teams, of creëert het vooral de illusie daarvan?
In deze sessie verkennen we het spanningsveld tussen capability en commitment in een AI-gedreven ontwikkelomgeving. Wat gebeurt er met professioneel testvakmanschap wanneer AI een groot deel van het werk kan genereren? Wanneer is AI een echte capability-versterker, en wanneer slechts een “one-trick pony”? En hoe zorgen organisaties ervoor dat snelheid en tooling niet ten koste gaan van kritisch denken en verantwoordelijkheid voor kwaliteit?
Aan de hand van ons beider praktijkervaring bespreken we hoe teams AI effectief kunnen inzetten zonder het commitment aan kwaliteit en vakmanschap te verliezen.
Zaal 2 | Kristiana Moretti, Yanick Kros en Hans Tan
In deze presentatie nemen wij jullie mee in een wereld die verrassend rijker is dan veel testers vermoeden: de IT en testpraktijk binnen een drinkwaterbedrijf. We kijken naar de innovaties die nodig zijn om de waterlevering en waterkwaliteit te garanderen. Van sensordata, AI, Virtual Reality, tot slimme netwerken: elke verandering vraagt om doordacht testwerk.
Waar testen en water elkaar raken, ontstaat een stroom van inzichten die verder reikt dan de kraan.
In deze presentatie nemen wij jullie mee in een wereld die verrassend rijker is dan veel testers vermoeden: de IT en testpraktijk binnen een drinkwaterbedrijf. We kijken naar de innovaties die nodig zijn om de waterlevering en waterkwaliteit te garanderen. Van sensordata, AI, Virtual Reality, tot slimme netwerken: elke verandering vraagt om doordacht testwerk.
Waar testen en water elkaar raken, ontstaat een stroom van inzichten die verder reikt dan de kraan.
Zaal 1 | Kyra Hameleers
What is AI based testing? What is Model Based Testing? And what is Behavior Driven Development?
All three techniques have been around for a while, but especially MBT and AI Based testing have been very hype sensitive. They all have their strength and weaknesses but get presented as the silver bullet that will solve all our issues, but so far this has been proven to not be the case.
With the current AI hype and the history of MBT & BDD, I see much confusion on what is what, and would like to share my vision on what they mean and how they differ but also compliment each other. It is always hard to predict what the future holds, but these techniques will help evolve the test field, and enhance the overall quality of the products and collaboration.
What is AI based testing? What is Model Based Testing? And what is Behavior Driven Development?
All three techniques have been around for a while, but especially MBT and AI Based testing have been very hype sensitive. They all have their strength and weaknesses but get presented as the silver bullet that will solve all our issues, but so far this has been proven to not be the case.
With the current AI hype and the history of MBT & BDD, I see much confusion on what is what, and would like to share my vision on what they mean and how they differ but also compliment each other. It is always hard to predict what the future holds, but these techniques will help evolve the test field, and enhance the overall quality of the products and collaboration.
Grand Hall | René van Veldhuijzen
Vibe coding is een hele coole benaming van ontwikkelaars waarmee ze “gewoon even iets proberen” bedoelen te zeggen. Code laten ontstaan vanuit het universum, en documentatie zien als een optionele bijlage voor toekomstige archeologen. Wat kan er in hemelsnaam misgaan? Nou… volgens test specialisten: ongeveer alles.
In mijn presentatie ga ik in op hoe de testcommunity effectief omgaat met vibe coding. Niet door het te verbieden (dat werkt toch nooit), maar door er een volwassen, pragmatisch antwoord op te formuleren. Want als ontwikkelaars op gevoel gaan bouwen, moeten wij test specialisten op scherp testen. Ik laat zien hoe technieken als Exploratory Testing, heuristieken, risico denken en context analyse precies die plekken blootleggen waar vibe coding zijn sporen achterlaat; denk bijvoorbeeld aan onvoorspelbare edge cases, halfbakken configuraties en features die alleen werken op de laptop van de ontwikkelaar die ze “even snel” gemaakt heeft.
Met voorbeelden uit moderne DevOps teams, zoals microservices die spontaan stoppen met praten en API’s die alleen reageren als je ze lief aankijkt. Ik zoom in hoe vibe testing een natuurlijke tegenreactie vormt. Test specialisten herkennen patronen, voelen risico’s aan en stellen de vragen die vibe coders vergeten te stellen.
Het resultaat: geen strijd tussen disciplines, maar een samenwerking waarin intuïtie én structuur elkaar versterken. Vibe coding geeft snelheid; vibe testing geeft richting. En samen voorkomen ze dat “Wat kan er in hemelsnaam misgaan?” verandert in “Wie heeft dit pareltje in productie gezet?"
Vibe coding is een hele coole benaming van ontwikkelaars waarmee ze “gewoon even iets proberen” bedoelen te zeggen. Code laten ontstaan vanuit het universum, en documentatie zien als een optionele bijlage voor toekomstige archeologen. Wat kan er in hemelsnaam misgaan? Nou… volgens test specialisten: ongeveer alles.
In mijn presentatie ga ik in op hoe de testcommunity effectief omgaat met vibe coding. Niet door het te verbieden (dat werkt toch nooit), maar door er een volwassen, pragmatisch antwoord op te formuleren. Want als ontwikkelaars op gevoel gaan bouwen, moeten wij test specialisten op scherp testen. Ik laat zien hoe technieken als Exploratory Testing, heuristieken, risico denken en context analyse precies die plekken blootleggen waar vibe coding zijn sporen achterlaat; denk bijvoorbeeld aan onvoorspelbare edge cases, halfbakken configuraties en features die alleen werken op de laptop van de ontwikkelaar die ze “even snel” gemaakt heeft.
Met voorbeelden uit moderne DevOps teams, zoals microservices die spontaan stoppen met praten en API’s die alleen reageren als je ze lief aankijkt. Ik zoom in hoe vibe testing een natuurlijke tegenreactie vormt. Test specialisten herkennen patronen, voelen risico’s aan en stellen de vragen die vibe coders vergeten te stellen.
Het resultaat: geen strijd tussen disciplines, maar een samenwerking waarin intuïtie én structuur elkaar versterken. Vibe coding geeft snelheid; vibe testing geeft richting. En samen voorkomen ze dat “Wat kan er in hemelsnaam misgaan?” verandert in “Wie heeft dit pareltje in productie gezet?"
Grand Hall | Gilbert Smulders
De meeste teams werken tegenwoordig interactief, waarbij retrospective over het algemeen de belangrijkste bron voor procesverbetering is. Echter in de praktijk blijkt dat de basis van het testproces vaak tekort schiet. Als we een TMMi volwassenheidsmeting doen bij organisaties zien we bijna altijd dat zij niet voorbij level 1 komen. Dat betekent gechargeerd dat iedereen maar wat doet. Teams zijn erg afhankelijk van de individuele testers en die doen hun best, maar de basis rammelt. En hoe kom je nu tot een hoger niveau van testen? Hoe kunnen we op niveau 2 komen, waarbij het testen beheerst verloopt binnen de teams? Of nog beter, hoe komen we op niveau 3, waarbij het testen gedefinieerd is vanuit een organisatiebreed perspectief en teams die kaders en richtlijnen in hun dagelijkse praktijk toepassen? Tijdens deze presentatie krijg je inzicht in bekende knelpunten en hoe je hier praktisch mee aan de slag kan. Je krijgt praktische handvatten om echt stappen te maken naar een volwassen testproces.
De meeste teams werken tegenwoordig interactief, waarbij retrospective over het algemeen de belangrijkste bron voor procesverbetering is. Echter in de praktijk blijkt dat de basis van het testproces vaak tekort schiet. Als we een TMMi volwassenheidsmeting doen bij organisaties zien we bijna altijd dat zij niet voorbij level 1 komen. Dat betekent gechargeerd dat iedereen maar wat doet. Teams zijn erg afhankelijk van de individuele testers en die doen hun best, maar de basis rammelt. En hoe kom je nu tot een hoger niveau van testen? Hoe kunnen we op niveau 2 komen, waarbij het testen beheerst verloopt binnen de teams? Of nog beter, hoe komen we op niveau 3, waarbij het testen gedefinieerd is vanuit een organisatiebreed perspectief en teams die kaders en richtlijnen in hun dagelijkse praktijk toepassen? Tijdens deze presentatie krijg je inzicht in bekende knelpunten en hoe je hier praktisch mee aan de slag kan. Je krijgt praktische handvatten om echt stappen te maken naar een volwassen testproces.