Artikelen door Jurien Terlage

Als Scrum Master aan de slag bij DUO: Samen van code naar productie

Vat samen met AI



OpenAI
ChatGPT



Perplexity
Perplexity



Claude
Claude



Gemini
Gemini

Blog

Als Scrum Master aan de slag bij DUO: Samen van code naar productie

Waarom vertrouwen de sleutel is tot succesvolle Scrum-teams

Een Scrum Master zorgt voor structuur, dat is vaak het eerste waar mensen aan denken. Maar in de praktijk is het zoveel meer dan het begeleiden van sprints. Echte impact ontstaat wanneer teams goed samenwerken, zich veilig voelen om kwetsbaar te zijn, elkaar om hulp durven te vragen en verantwoordelijkheid nemen.

Inmiddels begeleidt Scrum Master Dennis al zes maanden twee DevOps-teams binnen Dienst Uitvoering Onderwijs (DUO): het team Openbare Sites & Applicaties en het team achter het DUO-designsysteem UNO. In zijn rol ondersteunt hij de teams en hun Product Owners bij het werken volgens de Scrum-principes en draagt hij actief bij aan het versterken van de DevOps-cultuur.

Met een frisse blik stapte hij binnen. Al snel werd duidelijk dat zijn grootste bijdrage niet lag in het aanpassen van processen, maar in het creëren van rust, vertrouwen en eigenaarschap. Daarmee helpt hij de teams om software sneller én betrouwbaarder van idee tot productie te brengen.

Een Daily Scrum draait niet om de status

Een werkdag begint voor Dennis en zijn collega’s meestal met een kop koffie en een kort gesprek. Pas daarna volgt de Daily Scrum.

Dat is veel meer dan ‘gewoon’ een dagelijks overleg. Natuurlijk is het een moment om de voortgang van werkzaamheden te bespreken, maar belangrijker is dat er een open en veilige omgeving ontstaat. Een overleg waarin teamleden zich vrij voelen om aan te geven wanneer ze ergens vastlopen.

Dat klinkt vanzelfsprekend, maar dat is het niet. “Waar teamleden in het begin nog terughoudend waren, zie ik nu dat ze steeds makkelijker om hulp vragen. Daarvoor zijn vertrouwen, respect en psychologische veiligheid nodig,” vertelt Dennis Voorham, Scrum Master bij Identify.

Juist wanneer die veilige en vertrouwde basis aanwezig is, ontstaat er ruimte voor samenwerking, kwetsbaarheid en nemen teams steeds meer eigenaarschap over hun werk.

De grootste impact zit tussen de Scrum-events

Naast de stand-up bestaat een werkdag uit refinements, afstemming met Product Owners en andere belangrijke stakeholders. Toch probeert Dennis zijn agenda bewust niet volledig vol te plannen.

“Als Scrum Master wil je beschikbaar zijn wanneer een team of collega behoefte heeft aan een sparringspartner. Die ruimte maakt het mogelijk om snel in te spelen op wat er op dat moment speelt.”

En juist daar ligt volgens Dennis een belangrijk onderdeel, teamleden geven aan meer rust en structuur te ervaren. Ook waarderen zij dat hun zorgen en behoeften beter worden vertaald richting het management, waardoor knelpunten eerder worden besproken en teams zich kunnen blijven richten op waar zij goed in zijn.

“Kijk verder dan je eigen team. Leer de organisatie echt kennen.”

– Dennis, Scrum Master

De rol van business analist verandert door AI; technologie wordt slimmer, maar er is altijd menselijke duiding nodig.

Iedere opdracht biedt nieuwe inzichten

Werken met twee verschillende DevOps-teams binnen Dienst Uitvoering Onderwijs (DUO) en een uiteenlopend productportfolio houdt je niet alleen scherp, maar zorgt er ook voor dat je jezelf iedere dag verder ontwikkelt. Zo leert Dennis meer over UX, digitale toegankelijkheid en de manier waarop verschillende ontwikkelteams samenwerken binnen een grote organisatie.

Dennis zijn belangrijkste advies aan andere Agile-professionals? “Kijk verder dan je eigen scrum-team. Leer de organisatie kennen, spreek mensen buiten je directe omgeving en sluit aan bij vakgroepen of themadagen. Daarmee bouw je niet alleen een netwerk op, maar creëer je ook meer rust en focus voor de teams die je begeleidt.”

Samen bouwen we aan digitale transformatie

Bij Identify geloven we dat duurzame digitale transformatie ontstaat wanneer mensen, processen en techniek elkaar versterken. Onze professionals helpen organisaties vanuit verschillende expertises: van het creëren van wendbare teams en meer eigenaarschap binnen Agile Werken, tot het inzichtelijk maken van complexe vraagstukken via Business Analyse en het borgen van kwaliteit met IT-Testen. Samen zorgen we ervoor dat organisaties niet alleen veranderen, maar blijvend verbeteren.

Klaar om te sparren?

Benieuwd wat Agile werken voor jouw organisatie kan betekenen? Bij Identify helpen we dagelijks toonaangevende organisaties om wendbaarder, efficiënter en succesvoller te worden. Neem contact met ons op of ontdek hoe je kan beginnen met Agile werken.

Over de auteur


Foto van Dennis Voorham

Dennis Voorham

Dennis Voorham is Agile Consultant bij Identify. Als ervaren Scrum Master ondersteunde hij teams bij onder andere het Nationaal Archief en de Belastingdienst en helpt organisaties hun samenwerking en resultaten te verbeteren. Zijn menselijke aanpak en focus op continu ontwikkelen brengen teams dagelijks naar een hoger niveau.


Mail

Lees ook dit artikel eens

Hoe AI de rol van business analist verandert

Vat samen met AI



OpenAI
ChatGPT



Perplexity
Perplexity



Claude
Claude



Gemini
Gemini

Blog

Hoe AI de rol van de business analist verandert

Wat recente inzichten over AI betekenen voor het vak van Business Analyse.

Onlangs sprak ik een twintiger die tussen twee banen in zat. Ze had een ambitieus plan: een platform ontwikkelen waarmee jongeren eenvoudig vrijwilligerswerk op projectbasis kunnen vinden. Opvallend was niet zozeer het idee zelf, maar de manier waarop ze het wilde realiseren.

Ze wilde het grotendeels alleen bouwen, met behulp van AI. Wat een paar jaar geleden nog een compleet ontwikkelteam vereiste, lijkt vandaag de dag binnen handbereik van één ondernemer met de juiste AI-tools. Dat zegt veel over hoe snel technologie zich ontwikkelt. Maar misschien nog wel meer over hoe ons werk verandert.

AI wordt vaak benaderd als een technologische innovatie. Nieuwe tools, nieuwe mogelijkheden en meer efficiëntie. Toch zit de grootste verandering niet in de technologie zelf. Die zit in de manier waarop mensen ermee werken, processen veranderen en organisaties besluiten nemen. En precies daar begint het werk van de Business Analist.

AI-gebruik is niet standaard

Recente analyses laten zien dat de waarde van AI niet wordt bepaald door hoeveel mensen het gebruiken, maar vooral door hoe ze het gebruiken.

Twee collega’s kunnen dezelfde AI-tool inzetten en toch compleet verschillende resultaten behalen. De één gebruikt AI om sneller documenten te schrijven of taken uit handen te geven. De ander gebruikt dezelfde technologie juist om vraagstukken beter te doorgronden, alternatieven te onderzoeken of besluitvorming te verbeteren. En dan laten we de bekende hallucinaties van AI nog buiten beschouwing.

Voor Business Analisten is dat een belangrijke ontwikkeling. Analyse gaat niet langer alleen over processen en systemen. Minstens zo belangrijk wordt het begrijpen van menselijk gedrag. Hoe gebruiken stakeholders AI? Waar vertrouwen zij op? Welke aannames maken ze? En waar ontstaan risico’s doordat AI als vanzelfsprekend wordt gezien?

De centrale vraag verschuift daarmee van: “Wat moet het systeem doen?” naar: “Hoe gebruiken mensen dit systeem daadwerkelijk?”

AI verdwijnt in het proces

AI wordt binnen organisaties zelden als een losse applicatie geïntroduceerd. Veel vaker wordt het ongemerkt onderdeel van bestaande processen.

Denk aan automatische aanbevelingen, gegenereerde content, slimme zoekfuncties of AI die medewerkers ondersteunt bij het nemen van beslissingen. Daardoor worden processen minder voorspelbaar dan voorheen.

Waar een proces vroeger grotendeels lineair en uitlegbaar was, ontstaan nu dynamische stappen die afhankelijk zijn van data, context en algoritmes. Dat maakt het modelleren, analyseren en verbeteren van processen aanzienlijk complexer.

De rol van de Business Analist verschuift daardoor. Niet langer draait het vooral om het documenteren van processen, maar om het doorgronden ervan. Waarom komt een systeem tot een bepaalde uitkomst? Welke aannames liggen eraan ten grondslag? En welke risico’s brengt dat met zich mee? Juist die vragen worden steeds belangrijker.

“Technologie wordt slimmer, maar juist daardoor wordt menselijke duiding nog belangrijker. ”

– Rik, Business Analist

De rol van business analist verandert door AI; technologie wordt slimmer, maar er is altijd menselijke duiding nodig.

Als interfaces verdwijnen, verandert ook Business Analyse

Nog een ontwikkeling die steeds zichtbaarder wordt, is de manier waarop gebruikers met systemen omgaan.

Waar we jarenlang gewend waren aan schermen, formulieren en vaste processtappen, verschuift interactie steeds vaker naar gesprekken, prompts en contextgedreven ondersteuning. Denk bijvoorbeeld aan een chatbot van een zorgverzekeraar of een AI-assistent die medewerkers ondersteunt tijdens hun werk. Dat heeft directe gevolgen voor het werk van de Business Analist.

Want als er geen vast scherm of vooraf gedefinieerde gebruikersflow meer is, wat leg je dan precies vast? Hoe formuleer je requirements wanneer de uitkomst kan verschillen per situatie? En hoe stel je acceptatiecriteria op voor een systeem dat zich continu aanpast aan context?

Dat vraagt om een andere manier van denken. Minder focus op exacte specificaties en schermontwerpen. Meer aandacht voor intentie, context, gewenste uitkomsten en de kwaliteit van interacties.

De Business Analist wordt belangrijker, niet minder belangrijk

AI neemt steeds meer uitvoerend werk over. Daardoor ontstaat soms het beeld dat ook de rol van de Business Analist onder druk komt te staan.

In de praktijk lijkt juist het tegenovergestelde te gebeuren. Naarmate technologie complexer wordt, groeit de behoefte aan mensen die verbanden leggen, keuzes expliciet maken en organisaties helpen om de juiste beslissingen te nemen.

Voor de Business Analist betekent dat een duidelijke verschuiving:

  • minder nadruk op documentatie, meer op interpretatie;
  • minder zekerheid vooraf, meer werken met aannames en validatie;
  • meer aandacht voor stakeholdergedrag en besluitvorming;
  • een sterkere rol in het expliciet maken van keuzes, risico’s en impact.

Conclusie: wat betekent dit voor jou?

Technologie wordt slimmer, maar juist daardoor wordt menselijke duiding nog belangrijker. De Business Analist van de toekomst is niet degene die vooral beschrijft hoe een systeem werkt. Het is degene die begrijpt hoe mensen, processen en technologie samen waarde creëren.

En misschien is dat wel de belangrijkste les die AI ons leert: niet alles wat slimmer wordt, hoeft minder menselijk te zijn. Integendeel. Juist in een wereld waarin AI steeds meer kan, wordt het vermogen om context te begrijpen, de juiste vragen te stellen en betekenis te geven belangrijker dan ooit. Dat is precies waar de blijvende waarde van de Business Analist ligt.

Samen aan de slag?

De impact van AI gaat verder dan technologie alleen. Het vraagt om scherpe analyses, duidelijke keuzes en een goede vertaling naar de praktijk. Wil je ontdekken hoe Business Analyse jouw organisatie helpt om AI succesvol toe te passen? Neem gerust contact met ons op.

Over de auteur


Foto van Rik Hartog

Rik Hartog

Met ruim 20 jaar ervaring in IT, innovatie en SaaS helpt Rik organisaties complexe vraagstukken te vertalen naar praktische en toekomstbestendige digitale oplossingen. Vanuit zijn expertise in Business Analyse, en stakeholdermanagement werken verbindt hij strategie, technologie en de praktijk.


Mail

Lees ook dit artikel eens

Samen sterker verder: QRC Group neemt strategisch belang in Identify

Vat samen met AI



OpenAI
ChatGPT



Perplexity
Perplexity



Claude
Claude



Gemini
Gemini

Actueel

Samen sterker verder: QRC Group neemt strategisch belang in Identify

De volgende stap in onze ontwikkeling

Co-create to Accelerate is niet alleen onze belofte, maar iets wat we dagelijks in de praktijk brengen. Samen met elkaar én met toonaangevende opdrachtgevers. Vanaf vandaag doen we dat ook samen met QRC Group: een strategische samenwerking gericht op het versnellen van innovatie en het vergroten van impact binnen business en IT.

Samen blijvende impact creëren

Onze Agile-professionals begeleiden grote softwareontwikkelingen en implementaties. Tegelijkertijd zetten onze Business Analisten en Informatieanalisten zich dagelijks in om strategische kansen en oplossingen inzichtelijk te maken, terwijl onze test- en kwaliteitsprofessionals zorgen voor kwalitatieve en betrouwbare systemen. Zo creëren Identifyers een sterke wisselwerking tussen mens, proces en techniek.

“Met het strategische belang van QRC Group vergroten we onze impact. Door nauwe samenwerking versnellen we innovatie in business en IT, zonder onze identiteit en kernwaarden uit het oog te verliezen.” – Bart Watertor, Algemeen directeur Identify

Bart Watertor directeur van Identify IT-consultancy

Met het strategische belang van QRC Group vergroten we onze impact op het versnellen van innovatie binnen business en IT, zonder onze identiteit uit het oog te verliezen. Vanuit onze expertise verbreden we tegelijkertijd onze kennis en stimuleren we kennisdeling over disciplines heen. Iets wat we binnen Identify al jarenlang actief doen. Kennisdeling vormt immers de basis van onze expertise in consultancy.

Een gezamenlijke passie

De match tussen QRC Group en Identify was snel gemaakt. Door onze gezamenlijke passie voor business en IT én de overtuiging dat je alleen samen verder komt met de juiste professionals.

Een samenwerking waarin vertrouwen, eigenaarschap en ruimte voor persoonlijke ontwikkeling centraal staan. Zodat professionals zichzelf kunnen blijven ontwikkelen, zonder hun eigen identiteit te verliezen.

“De combinatie van vertrouwen, een gedeelde passie voor IT en business en een energiek team binnen een nicheorganisatie maakte dat de klik met QRC Group er meteen was.” – Shahrooz Safarghandi, CEO QRC Group

Na het behalen van de NEN-certificering markeert het strategische belang van QRC Group in Identify een logische volgende stap in onze ontwikkeling. Waar QRC Group zich richt op expertisegebieden zoals AI, Data-analyse, Finance, Functioneel- en technisch beheer, Modern Workplace en Security, focust Identify zich op het verder ontwikkelen op het snijvlak van mens, proces en techniek. Een veelzijdige samenwerking, met co-creatie als stevige basis.

Synergie in de praktijk: hoe we elkaar versterken

Vanaf het begin ontstond er direct synergie. Een mooi voorbeeld hiervan is de inzet van een Business Analist vanuit Identify binnen een opdracht van QRC Security bij de Dienst Justitiële Inrichtingen. Daarmee werd direct zichtbaar hoe onze expertisegebieden elkaar aanvullen en hoe we gezamenlijk meer waarde kunnen creëren voor opdrachtgevers.

Al snel bleek het verder reikt dan de inzet van professionals alleen. Door actief kennis en ervaringen uit te wisselen, versterken we elkaar ook als organisaties. Zo delen we expertise op het gebied van kwaliteit, certificering en organisatieontwikkeling, waaronder de voorbereiding en toetsing rondom de NEN 4400-certificering. Deze uitwisseling draagt bij aan verdere professionalisering en helpt ons de kwaliteit van onze dienstverlening structureel te borgen.

Daarnaast biedt het ruimte om gezamenlijk nieuwe kansen te verkennen. Vanuit de combinatie van expertise in AI, data-analyse, Business Analyse en Informatieanalyse werken we aan nieuwe proposities die organisaties helpen om beter onderbouwde keuzes te maken en veranderingen effectiever te realiseren. Door verschillende disciplines samen te brengen, ontstaat een bredere kijk op complexe vraagstukken en meer ruimte voor oplossingen die zowel technisch als organisatorisch impact maken.

Identify en QRC Group tekenen officieel een strategische samenwerking. Shahrooz Safarghandi (CEO QRC) en Bart Watertor en Marleen Kleijn van de directie van Identify vieren het samen op kantoor in Amersfoort.
Shahrooz Safarghandi (CEO QRC Group), Bart Watertor (Algemeen Directeur Identify) en Marleen Kleijn (HR-directeur en mede-eigenaar van Identify) vieren de samenwerking tussen Identify en QRC Group samen op kantoor in Amersfoort.

De toekomst

Het strategisch belang van QRC Group in Identify zorgt voor een totaaloplossing binnen complexe IT-verandertrajecten: van analyse en ontwikkeling tot testen en implementatie. Zo bieden we opdrachtgevers kwalitatieve professionals en maatwerkoplossingen waar organisaties écht behoefte aan hebben.

Na een sterke start kijken we samen uit naar een toekomst waarin Identify en QRC Group elkaar blijven versterken. Met nog meer samenwerking, kennisdeling en maatschappelijke impact.

Over QRC Group B.V.

QRC Group B.V. is een snelgroeiende Nederlandse dienstverlener in de detachering- en consultancybranche. De organisatie bouwt aan een groep gespecialiseerde bedrijven die samen de kracht en schaal van een middelgrote speler combineren met de wendbaarheid van kleinere ondernemingen.

Over Identify

Wij zijn Identify, een hecht team van betrokken consultants, van Business Analisten tot Testers en Scrum Masters, met Amersfoort als thuisbasis. Wij optimaliseren producten en processen binnen organisaties. Dat doen we niet vóór, maar mét onze opdrachtgevers. Voor duurzame verbeteringen die organisaties écht vooruithelpen.

Bij Identify draait alles om vooruitgang. Echte vooruitgang bereik je alleen samen, door verantwoordelijkheid te nemen, te doen wat nodig is en continu te blijven ontwikkelen. Samen zetten we onze kennis en energie in voor echte impact.

Co-create to Accelerate


Foto van Klaar om te sparren?

Klaar om te sparren?

Met een unieke aanpak op basis van co-creatie en onze expertise in Agile, Business Analyse en IT-Testen helpen we organisaties door heel Nederland écht vooruit. Heb jij een uitdaging? We denken graag met je mee!


Daag ons uit

Lees ook dit artikel eens

Stop met brandjes blussen, bouw aan kwaliteit vanaf dag één

Vat samen met AI



OpenAI
ChatGPT



Perplexity
Perplexity



Claude
Claude



Gemini
Gemini

Blog

Stop met brandjes blussen, bouw aan kwaliteit vanaf dag één

De ware kosten van een late bug en hoe Agile en AI dit kunnen voorkomen

Iedere tester kent het: de nachtmerrie van een bug die pas aan het licht komt vlak voordat de software live moet gaan. De druk is direct voelbaar, bij ontwikkelaars, testers, product owners en soms zelfs bij de klant. Releases worden uitgesteld, planningen schuiven en het vertrouwen krijgt een knauw.

Wat veel organisaties daarbij onderschatten, zijn niet alleen de zichtbare kosten van zo’n last-minute bug, maar juist de verborgen impact: teamstress, verlies aan geloofwaardigheid en gemiste leermomenten die in de hectiek van een releasecrisis verdwijnen.

Daarom neem ik, als test consultant bij Identify, je mee in wat deze verborgen kosten écht betekenen voor Agile teams. Ik laat zien hoe je ze kunt voorkomen, welke rol slimme teststrategieën daarbij spelen en hoe kunstmatige intelligentie (AI) helpt om risico’s eerder zichtbaar te maken.

De kosten van een late bug

Om te begrijpen waarom ‘laat ontdekte bugs’ zo duur zijn, hoeven we niet ver te zoeken. Het bekende principe van de “cost of defect curve” (of Boehm’s curve) laat zien dat hoe later een fout wordt gevonden in de software‑levenscyclus, hoe duurder het is om die te herstellen.

  • Tijdens ontwikkeling: Een fout kost alleen wat aan ontwikkeltijd.
  • Tijdens testfase: De kosten stijgen, de code moet worden aangepast, opnieuw getest, en mogelijk integratietests opnieuw uitgevoerd.
  • Tijdens acceptatie of vlak voor de release: Dan begint het echt duur te worden. Documentatie, planning, regressietests en validaties moeten opnieuw. Bovendien komt de bug vaak aan het licht op een moment dat de hele releaseketen stilvalt.
  • Na livegang: De ergste fase. Gebruikers ondervinden problemen, er ontstaat reputatieschade en er moet vaak ‘brand’ worden geblust in de productie.

Onderzoek van IBM liet ooit zien dat een bug die in de productieomgeving wordt gevonden, tot 100 keer zoveel kan kosten als dezelfde bug die tijdens ontwikkeling wordt ontdekt. Dat cijfer varieert per organisatie, maar de boodschap blijft: hoe later je hem vindt, hoe duurder het wordt.

 

Waarom gebeurt dit nog steeds?

In veel teams, zelfs in Agile omgevingen, zien we nog steeds dat de meeste testinspanningen aan het einde van een sprint of vlak voor de release plaatsvinden. “We zijn bijna klaar, nu nog even testen”, klinkt het vaak. Maar als testen pas daarna begint, ontstaat er een kettingreactie:

  1. Developers leveren laat code aan.
  2. Testers krijgen te weinig tijd om goed te valideren.
  3. Bugs worden laat gevonden.
  4. De reparatie- en hertestcycli overlappen de planning.

Kortom: testen wordt een bottleneck, in plaats van een continue kwaliteitsactiviteit.

Veel organisaties noemen dit dan ‘een Agile uitdaging’, maar vaak is het een cultuur- en procesprobleem. Agile betekent namelijk niet ‘sneller werken’, maar slimmer feedback verzamelen, vroeg en continu.

De Agile manier om bugs vroeg te vinden

Agile en Scrum bieden eigenlijk precies de kaders om late bugs te voorkomen. Het fundament ligt in:

  1. Kleine, iteratieve opleveringen
    Door software in korte cycli te bouwen en te testen, kun je snel feedback krijgen.
  2. ‘Shift‑left testing’
    Testactiviteiten verschuiven naar voren in het proces. Niet wachten tot de code ‘klaar’ is, maar eerder starten met testontwerp, review, en zelfs automatische checks in code‑repositories.
  3. ‘Definition of Done’ met kwaliteit ingebouwd
    Teams nemen testcriteria op in hun Definition of Done (DoD). Een user story is pas ‘done’ als deze getest, code‑gereviewd én gevalideerd is.
  4. Testautomatisering
    Als je vaak kleine releases doet, wil je regressietests niet steeds handmatig herhalen. Automatisering biedt snelheid en betrouwbaarheid.
  5. Communicatie en samenwerking
    De tester is niet de laatste verdedigingslinie, maar een kwaliteitsadviseur gedurende de hele cyclus. Pair testing tussen developer en tester, refinement‑sessies met concrete acceptatiecriteria en gezamenlijke demo’s verhogen de productkwaliteit enorm.

Kortom: kwaliteit is een teamsport. Zodra testers vanaf dag één deelnemen aan ontwerp en refinement, worden bugs vaak in gedachten al voorkomen nog voordat er code geschreven is.

Van ‘testen achteraf’ naar ‘kwaliteit vooraf’

Een van de grote misverstanden rond testen is dat het enkel gaat om het vinden van fouten. In werkelijkheid gaat het om het voorkómen van fouten.

In veel succesvolle Agile teams zie je dat testers betrokken worden bij:

  • Het meeschrijven aan user stories en acceptatiecriteria.
  • Het meedenken over edge cases al in de refinementfase.
  • Het reviewen van unit tests en integratietests samen met ontwikkelaars.

Door denken als een tester te integreren in alle fases, ontstaat een cultuur waarin bugs vaak niet eens de kans krijgen om te ontstaan.

Een mooi voorbeeld: een tester stelt tijdens refinement de vraag “Wat gebeurt er als de gebruiker zijn internetverbinding verliest tijdens het opslaan?” — misschien was dat scenario nooit in de code meegenomen. Die vraag voorkomt een toekomstige productiestoring.

De menskant van late bugs

Buiten de technische kosten is er ook de menselijke impact: de stress van een release‑eindspurt. Late bugs zorgen bijna altijd voor avonden overwerk, frustratie, en soms schuldgevoel tussen teamleden.

Die spanning tast niet alleen het moreel aan, maar ook de productiviteit op lange termijn. In extreme gevallen kan het leiden tot burn‑outklachten, vooral bij teams die structureel ‘crisis‑testen’ vlak voor livegang.

Agile wil net dát tegengaan: een duurzaam ritme waarin kwaliteit continu groeit. Dat lukt alleen wanneer het team fouten als leerkansen ziet, niet als brandjes om te blussen.

“Wat gebeurt er als de gebruiker zijn internetverbinding verliest tijdens het opslaan?”


– Stefan, Test consultant

Slimme test strategie met Agile, AI en automation zorgt voor kwaliteit en op tijd vinden van bugs

De rol van AI in vroegtijdige kwaliteitsborging

AI verandert softwaretesten ingrijpend. Waar testautomatisering jarenlang draaide om het herhalen van bekende checks, brengt AI voorspellend en lerend vermogen naar de tafel. Een paar belangrijke toepassingen:

  1. Risico‑analyse en testprioriteit
    AI‑modellen kunnen code‑wijzigingen analyseren, koppelen aan historische bugdata, en voorspellen waar nieuwe risico’s zitten. Zo testen teams niet alles blind, maar richten ze hun energie waar de kans op fouten het grootst is.
  1. Slimme testgeneratie
    AI kan testscripts genereren op basis van user stories of zelfs automatisch klikpaden ontdekken via exploratieve navigatie. Tools zoals mabl, Testim of Functionize gebruiken machine learning om UI‑veranderingen te herkennen en self‑healing scripts te maken.

    Dit maakt onderhoud van testautomatisering veel efficiënter, een vaak onderschatte kostenpost.

  1. Analyseren van log‑ en gebruikersdata
    AI kan productie‑ en testlogs doorzoeken op afwijkend gedrag of patronen die voor mensen moeilijk te zien zijn. Zo kun je al in de testfase signaleren dat een fout zich ‘aankondigt’ voordat gebruikers er last van krijgen.
  1. Virtuele testers en copilots
    Met de opkomst van generatieve AI’s (zoals ChatGPT, Copilot, TestGPT, etc.) kunnen testers nu sneller testgevallen ontwerpen, data genereren of acceptatiecriteria vertalen naar concrete tests.

    De menselijke rol verschuift daardoor van handmatige uitvoering naar inzicht en interpretatie.

 

Risico’s en realistische verwachtingen

AI is geen magische oplossing, en het kan ook fouten introduceren. Belangrijke nuances:

  • AI heeft training en context nodig; een onnauwkeurig model kan verkeerde prioriteiten stellen.
  • Menselijke controle blijft essentieel. AI ondersteunt, maar neemt het beoordelingsvermogen niet over.
  • Transparantie en reproduceerbaarheid van resultaten zijn belangrijk.

De beste resultaten ontstaan niet door alles te automatiseren, maar door menselijke expertise te combineren met AI‑ondersteuning.

Een ervaren tester die AI gebruikt als copiloot, kan sneller risico’s spotten en meer tijd besteden aan de diepere, creatieve testscenario’s, daar waar menselijke intuïtie onmisbaar blijft.

 

AI in de toekomst van Agile testen

De toekomst van kwaliteit in Agile ziet er collaboratief én intelligent uit:

  • AI‑middelen integreren vanzelf in CI/CD‑pijplijnen.
  • Testdata wordt automatisch gemaskeerd, gegenereerd en geanalyseerd.
  • Dashboards voorspellen productierisico’s nog vóór de release.
  • Teams gebruiken conversatie‑AI om testbevindingen te bespreken in natuurlijke taal.

In zo’n toekomst is ‘kwaliteit’ niet langer een afsluitende fase, maar een continu dialoog tussen mens, systeem en data.

 

 

Conclusie: bouw tijdig aan vertrouwen

Een bug die vlak voor de livegang wordt ontdekt, is meer dan alleen een technisch probleem, het is een signaal. Het vertelt iets over samenwerking, timing en cultuur binnen het team.

In een Agile organisatie is de sleutel tot succes niet ‘meer testen’, maar eerder leren. Door kwaliteit naar voren te schuiven, te investeren in automatisering, en AI bewust in te zetten, kun je niet alleen geld besparen, maar ook vertrouwen bouwen, bij je team én bij je gebruikers.

Zoals een wijs tester ooit zei: “kwaliteit is de verantwoordelijkheid van iedereen, maar testers zorgen dat niemand dat vergeet.”

Samen aan de slag?

AI verandert de toekomst van testen. Bij Identify helpen we organisaties om die stap te zetten. Klaar om samen te ontdekken wat AI voor jouw testaanpak kan betekenen? Neem contact met ons op.

Over de auteur


Foto van Stefan Brezina

Stefan Brezina

Als enthousiaste test engineer heb ik een passie voor nieuwe testtechnologieën en ben ik voortdurend op zoek naar ontwikkelingen en vaardigheden om me verder te verdiepen.


Mail

Lees ook dit artikel eens

Eén rol, twee petten: waarom Scrum Master én Product Owner combineren niet werkt

Vat samen met AI



OpenAI
ChatGPT



Perplexity
Perplexity



Claude
Claude



Gemini
Gemini

Blog

Eén rol, twee petten: waarom het combineren van Scrum Master en Product Owner niet werkt

Waarom het scheiden van verantwoordelijkheden cruciaal is voor een effectief Scrum-team

In veel organisaties, vooral die aan het begin staan van hun Agile-transformatie, wordt soms de verleidelijke beslissing genomen om de rol van Scrum Master en Product Owner bij één en dezelfde persoon te beleggen. Maar hoe goed bedoeld dit ook mag zijn, één persoon kan nooit tegelijk die kritische teamcoach én besluitvaardige eigenaar van het product zijn. Het plaatst één persoon in een constante spagaat tussen teambehoeften en productprioriteiten. En dat kan vergaande gevolgen hebben voor zowel het teamproces als het uiteindelijke product.

In dit artikel deel ik, Dennis Voorham Scrum Master bij Identify, waarom het combineren van de rollen Scrum Master en Product Owner in de praktijk vaak niet werkt en welke spanningen dit veroorzaakt in teamdynamiek, besluitvorming en productwaarde.

Als Agile Consultant bij Identify kom ik deze ‘dubbele pet’ nog altijd tegen in vacatureteksten of opdrachtbeschrijvingen. Een organisatie die op zoek is naar een Product Owner, die ‘wanneer het nodig is’ óók de rol van Scrum Master op kan pakken.

Het klinkt zo aantrekkelijk: één persoon die zowel de rol van Product Owner (PO) als Scrum Master vervult. Op papier bespaart dit tijd en moeite, maar in de praktijk zien we dat het maar al te vaak averechts werkt. De rollen hebben tegengestelde doelen, vragen andere vaardigheden, vergen allebei veel aandacht en daarmee ook veel tijd. Sterker nog, door deze rollen samen te voegen, worden de fundamentele Scrum-principes – of ‘spelregels’ zoals ik ze eigenlijk graag noem – ondermijnd.

Botsende verantwoordelijkheden

De Product Owner draagt de verantwoordelijkheid voor het product en de waarde die het oplevert. Hij/zij bepaalt wat er ontwikkeld wordt en houdt daarbij rekening met zowel gebruikers als Stakeholders.

In een steeds veranderende markt worden eisen en wensen continu bijgesteld. Het is de taak van de Product Owner om alert te zijn op deze schommelingen en zorgvuldig af te wegen welke aanpassingen direct klantwaarde opleveren. De Product Owner schat continu risico’s in, toetst requirements op haalbaarheid binnen de gestelde termijnen én moet ondertussen zorgen voor een goede balans tussen de verschillende en vaak tegengestelde belangen van de Stakeholders.

De Scrum Master richt zich juist op hoe het team werkt. Als onafhankelijk coach begeleidt hij/zij het proces, faciliteert samenwerking, coacht het team én de Product Owner, en ondersteunt hij/zij het management om een cultuur van vertrouwen en samenwerking bevorderen, waardoor teams effectief en onder zelforganisatie kunnen werken aan complexe projecten.

Wanneer één persoon beide rollen vervult, liggen conflictsituaties al snel op de loer.

Want wie grijpt in als de Product Owner te veel druk op het team legt, of het team er samen met de Product Owner niet in slaagt om overeenstemming te bereiken bij lastige beslissingen? Wie biedt ondersteuning wanneer er spanningen binnen het team ontstaan? En wat als het team geen ‘Impediments’ (belemmeringen / obstakels) durft te melden omdat die de Product Owner zelf betreffen?

De Scrum Master is er om vanuit een onbevooroordeelde positie niet alleen het team, maar óók de Product Owner te ondersteunen en te coachen. Wanneer één persoon alles bepaalt én begeleidt, doe je direct afbreuk aan het fundament van Scrum.

Intern conflict leidt tot extern verlies

Wanneer één persoon zowel Product Owner als Scrum Master wordt loopt diezelfde persoon het risico om met zichzelf in conflict te raken. De rollen hebben namelijk tegengestelde belangen: de Product Owner wil voortdurend meer waarde leveren en dus vaker op resultaten sturen, terwijl de Scrum Master juist moet waken over het proces, het team moet beschermen en soms op de rem moet trappen.

Dit interne conflict kan leiden tot:

  • Wankele prioriteiten, omdat de persoon niet meer weet vanuit welke pet hij of zij beslist;

  • Verminderd teamvertrouwen, omdat het team geen duidelijke richting of bescherming ervaart;

  • Ongezonde druk, doordat de “Product Owner-kant” deadlines blijft pushen terwijl de “Scrum Master-kant” ziet dat het team overbelast raakt;

  • Vervaging van verantwoordelijkheid, wat uiteindelijk de kwaliteit van zowel het product als het proces ondermijnt.

Kortom, door beide rollen te combineren kan één persoon in een voortdurende spagaat terechtkomen, met negatieve gevolgen voor zowel het team en het product

“Het samenvoegen van Scrum Master en Product Owner lijkt misschien slim, maar het knelt de rollen juist af.”

-Dennis Voorham, Agile consultant

Tijdgebrek als belemmering

De Product Owner is verantwoordelijk voor het uitzetten van strategie en visie, het begrijpen van markt en klanten, het prioriteren van werk en het managen van Stakeholders.

De Scrum Master richt zich echter op het optimaliseren van teamdynamiek, het verbeteren van processen, het begeleiden van de teamontwikkeling en het ondersteunen van het management.

Dit zijn allemaal taken waar beslist niet te licht over gedacht mag worden, want voor één persoon is het vrijwel onmogelijk om beide sets vaardigheden volledig te beheersen.

Het is dan ook duidelijk dat het samenvoegen van beide rollen een aanzienlijke druk op één persoon kan leggen. Hierdoor komt de kwaliteit van het werk bijna altijd onder druk te staan.

Conclusie

Het samenvoegen van Scrum Master en Product Owner lijkt misschien slim, maar het knelt de rollen juist af. We moeten ons realiseren dat Scrum Master en Product Owner bewust als afzonderlijke rollen zijn ontworpen en daarmee juist complementair aan elkaar moeten zijn. Een goede invulling van deze rollen begint bij een duidelijk begrip van taken en verantwoordelijkheden.

Door verantwoordelijkheden gescheiden te houden, voorkomen we de complexiteit en problemen die ontstaan wanneer één persoon beide rollen probeert te vervullen.

Hierdoor krijgt iedereen de ruimte om zijn of haar werk écht goed te doen en bevordert het de groei naar een sterk, high-performing team die aan de verwachtingen van de organisatie tegemoet komt – en zelfs keer op keer weet te overtreffen!

Klaar om te sparren?
Benieuwd wat Agile werken voor jouw organisatie kan betekenen? Bij Identify helpen we dagelijks toonaangevende organisaties om wendbaarder, efficiënter en succesvoller te worden. Neem contact met ons op of ontdek hoe je kan beginnen met Agile werken.

Over de auteur


Foto van Dennis Voorham

Dennis Voorham

Dennis Voorham is Agile Consultant bij Identify. Als ervaren Scrum Master ondersteunde hij teams bij onder andere het Nationaal Archief en de Belastingdienst en helpt organisaties hun samenwerking en resultaten te verbeteren. Zijn menselijke aanpak en focus op continu ontwikkelen brengen teams dagelijks naar een hoger niveau.


Mail

Lees ook dit artikel eens

Identify Consultancy Amersfoort voor Agile, Business Analyse en Scrum is NEN 4400-1 gecertificeerd

Identify Consultancy Amersfoort Great Place To Work 2025

Contact

  • Koningin Wilhelminalaan 1
  • 3818 HN Amersfoort
  • Nederland



Linkedin-in




Instagram




Facebook-f

Over ons

Direct naar

Ik wil up to date blijven

Blijf op de hoogte met onze gratis nieuwsbrief.




Hoe AI de toekomst van softwaretesten verandert

Vat samen met AI



OpenAI
ChatGPT



Perplexity
Perplexity



Claude
Claude



Gemini
Gemini

Blog

Hoe AI de toekomst van softwaretesten verandert

De toekomst van testen is slimmer en sneller dankzij AI

Heb je je ooit afgevraagd waarom je favoriete apps tegenwoordig zo soepel draaien? Grote kans dat kunstmatige intelligentie (AI) daar een belangrijke rol in speelt. AI zorgt stilletjes voor een revolutie in de manier waarop software wordt getest voordat die op jouw telefoon of computer belandt. Voor mij als testprofessional is die verandering bijzonder fascinerend! In deze blog neem ik je mee langs observaties uit de sector, recent onderzoek en opkomende trends in AI-gestuurde kwaliteitsborging. Zo ontdek je hoe deze technologie de toekomst van softwaretesten blijvend verandert.

De oude manier versus de nieuwe manier

Traditioneel leek softwaretesten op het afwerken van een checklist: klik op deze knop, voer die informatie in, controleer of de pagina correct laadt. Het werkte, maar het was traag, repetitief en elke keer dat ontwikkelaars iets aan de app veranderden, moesten testers hun checklists handmatig bijwerken.

AI verandert dit volledig.

Wat gebeurt er op dit moment?

De cijfers vertellen een boeiend verhaal: meer dan 72% van de testteams onderzoekt of implementeert inmiddels AI-gestuurde testworkflows. Een paar jaar geleden was dat nog minimaal. Het gebruik van AI-testen is gestegen van 7% in 2023 naar 16% in 2025, en het momentum neemt alleen maar toe.

Tests die zichzelf schrijven

Stel je voor dat software kan observeren hoe echte gebruikers met een app omgaan en vervolgens zelf een checklist maakt van wat getest moet worden. Dat is precies wat AI nu doet. Het analyseert patronen, bekijkt de code en genereert testscenario’s, inclusief ongewone situaties waar mensen misschien nooit aan zouden denken.

 

Tests die zichzelf repareren

Een veelvoorkomend probleem binnen het testen, je schrijft een test om op een knop ‘Verzenden’ te klikken, maar ontwerpers verplaatsen die knop of geven hem een andere naam.

Traditioneel moest iemand die test handmatig aanpassen. AI-tools herkennen nu automatisch veranderingen en passen de test aan om de nieuwe locatie van de knop te vinden.

Experts voorspellen dat tegen 2025 meer dan 80% van de testautomatiseringsframeworks deze zelfherstellende AI-functionaliteit zal bevatten. Dat maakt testen niet alleen veerkrachtiger maar ook responsiever.

 

Zien zoals een mens (maar dan beter)

AI kan naar het scherm van jouw app kijken en visuele problemen opsporen, een verkeerd uitgelijnd logo, verkeerde kleuren of kapotte lay-outs, op verschillende apparaten en browsers. Het vergelijkt hoe het scherm eruit zou moeten zien met hoe het er daadwerkelijk uitziet en maakt slim onderscheid tussen opzettelijke updates en echte bugs.

 

Voorspellen waar problemen zich verbergen

Door eerdere bugs en codewijzigingen te analyseren, kan AI voorspellen welke delen van een applicatie het meest waarschijnlijk falen. Het is alsof je een weersvoorspelling hebt voor softwareproblemen, waardoor teams hun testinspanningen kunnen richten op wat het belangrijkst is.

“Voor testers betekent het een evolutie van scriptschrijvers naar AI-trainers en strategische denkers.”


– Stefan, Test consultant

AI is de toekomst van IT-testen, slimmer en sneller.

Waar we naartoe gaan

 

Software die zichzelf test

De toekomst wijst naar AI-systemen die zelfstandig applicaties verkennen: rondklikken, combinaties uitproberen, leren hoe dingen werken en hun eigen testbereik uitbreiden zonder voortdurende menselijke begeleiding. Onderzoek voorspelt dat deze ‘agentic AI’-benadering in 2028 in 33% van de bedrijfssoftware zal zijn geïntegreerd, tegenover minder dan 1% in 2024.

 

Slimmere, snellere tests

In plaats van duizenden tests uit te voeren bij elke codewijziging, selecteert AI alleen de relevante tests. Dit betekent snellere feedback en releases, zonder kwaliteitsverlies.

 

Van bug-zoeker naar bug-oplosser

AI gaat verder dan alleen het opsporen van problemen: het doet ook suggesties voor oplossingen, gebaseerd op vergelijkbare issues die het eerder heeft gezien.

 

Het menselijke element blijft belangrijk

Voordat je denkt dat robots of computers ons overnemen, AI vervangt menselijke testers niet. Het wordt juist hun ‘superkracht’. AI doet het repetitieve werk, zoals dagelijks dezelfde 1.000 controles uitvoeren, terwijl testprofessionals zich richten op creatief denken, klantbehoeften begrijpen en strategische beslissingen nemen.

De toekomst draait niet om kiezen tussen menselijke of kunstmatige intelligentie, maar om het combineren van beide voor betere, betrouwbaardere software.

 

Conclusie: wat betekent dit voor jou?

Voor bedrijven betekent dit software van hogere kwaliteit die sneller wordt geleverd. De markt voor testautomatisering groeit van $25,4 miljard in 2024 naar $29,29 miljard in 2025. Voor testers betekent het een evolutie van scriptschrijvers naar AI-trainers en strategische denkers. En voor de gebruiker? Apps en websites die beter werken, minder crashen en sneller verbeteren.

 

De testrevolutie vindt achter de schermen plaats, maar jij merkt het elke keer dat software gewoon werkt – precies zoals het hoort.

Samen aan de slag?

AI verandert de toekomst van testen. Bij Identify helpen we organisaties om die stap te zetten. Klaar om samen te ontdekken wat AI voor jouw testaanpak kan betekenen? Neem contact met ons op.

Over de auteur


Foto van Stefan Brezina

Stefan Brezina

Als enthousiaste test engineer heb ik een passie voor nieuwe testtechnologieën en ben ik voortdurend op zoek naar ontwikkelingen en vaardigheden om me verder te verdiepen.


Mail

Lees ook dit artikel eens

De verschillen tussen Testautomatisering en Automatisering in Test

Vat samen met AI



OpenAI
ChatGPT



Perplexity
Perplexity



Claude
Claude



Gemini
Gemini

Blog

De verschillen tussen Testautomatisering en Automatisering in Test

Onmisbaar inzicht voor moderne QA-teams

De termen testautomatisering en automatisering in test worden in de praktijk vaak door elkaar gebruikt, maar betekenen zeker niet hetzelfde. Vaak zie ik dat zelfs ervaren professionals deze begrippen als synoniem inzetten, terwijl ze juist verschillende doelen en toepassingen hebben binnen het kwaliteitsdomein. Daarom leg ik, Test consultant bij Identify, graag uit waar het verschil precies zit en waarom dit onderscheid cruciaal is voor moderne QA-teams. Want alleen wanneer je de juiste aanpak kiest, haal je het maximale uit je teststrategie en draag je écht bij aan een hogere softwarekwaliteit.

Testautomatisering

  • Definitie: Testautomatisering is een breed vakgebied dat verwijst naar de automatisering van het volledige testproces binnen de softwareontwikkelingscyclus. Dit omvat niet alleen het uitvoeren van tests, maar ook het beheren, orkestreren en rapporteren van tests in verschillende stadia van ontwikkeling en implementatie. [1,3,4].
  • Scope: Omvat alles van het ontwerpen en scripten van tests, het integreren van tests in CI/CD-pijplijnen, het beheren van testgegevens, het bijhouden van resultaten en zelfs het automatisch opzetten van testomgevingen. [1,3,4].
  • Betrokken professionals: Dit is waar verschillende rollen, waaronder ontwikkelaars, testers en DevOps engineers, samenwerken om end-to-end automatisering van testcycli te bereiken. [1].
  • Voorbeelden: Automatische planning van nachtelijke regressietests, integratie van geautomatiseerde tests in een CI/CD-pijplijn en het maken van geautomatiseerde testrapporten.

Automatisering in Test (Geautomatiseerd Testen)

  • Definitie: Testautomatisering of geautomatiseerd testen is een onderdeel van testautomatisering. Het verwijst specifiek naar het automatiseren van de uitvoering van testgevallen met behulp van scripts en tools in plaats van ze handmatig uit te voeren. [1,3,4].
  • Toepassing: De focus ligt op het vervangen van handmatige testuitvoering door geautomatiseerde scripts, meestal voor repetitieve, regressie- of grootschalige tests. Het omvat meestal niet het bredere beheer, de orkestratie of integratie van het testproces. [1,3].
  • Betrokken professionals: Meestal testers of QA engineers met programmeervaardigheden die testscripts schrijven en onderhouden. [1].
  • Voorbeelden: Het schrijven van Selenium-scripts om browsergebaseerde UI-tests te automatiseren of het gebruik van JUnit om eenheidstests te automatiseren.

“Het onderscheid tussen testautomatisering en automatisering in test lijkt klein, maar is in de praktijk van groot belang.”
– Stefan

Belangrijkste verschillen in één oogopslag

Aspect

Testautomatisering

Automatisering in Test (Geautomatiseerd Testen)

Reikwijdte

Breed: hele testproces

Smal: alleen testuitvoering automatiseren

Activiteiten

Testontwerp, uitvoering, rapportage, integratie

Alleen testuitvoering

Betrokken rollen

Ontwikkelaars, testers, DevOps, QA

Testers, QA-engineers

Integratie

Inclusief CI/CD, omgevingsopzet, rapportage

Meestal geen orkestratie

Doel

End-to-end automatisering voor efficiëntie

Snelheid en herhaalbaarheid van tests

Conclusie

Het onderscheid tussen testautomatisering en automatisering in test lijkt klein, maar is in de praktijk van groot belang. Testautomatisering gaat over de bredere strategie: het opzetten, beheren en integreren van geautomatiseerde testactiviteiten in de hele ontwikkelketen.

Automatisering in test, ofwel geautomatiseerd testen, richt zich specifiek op de uitvoering van testgevallen met behulp van scripts en tools. Voor QA-professionals betekent dit dat geautomatiseerd testen slechts één bouwsteen vormt binnen een complete testautomatiseringsaanpak.

Door dit onderscheid scherp te maken, kun je betere keuzes maken in tooling, strategie en prioriteiten. En zo zorgen voor efficiëntere, betrouwbaardere en toekomstbestendige testprocessen.

Bronnen

  1. Hurix
  2. Perfecto
  3. Techtarget
  4. Uipath

Over de auteur


Foto van Stefan Brezina

Stefan Brezina

Als enthousiaste test engineer heb ik een passie voor nieuwe testtechnologieën en ben ik voortdurend op zoek naar ontwikkelingen en vaardigheden om me verder te verdiepen.


Mail


Lees ook dit artikel eens

De onmisbare rollen in een Scrum-team

Vat samen met AI



OpenAI
ChatGPT



Perplexity
Perplexity



Claude
Claude



Gemini
Gemini

Blog

De onmisbare rollen in een Scrum-team: Product Owner en Scrum Master

Verantwoordelijkheden en relatie van Scrum Master en Product Owner

Binnen het Scrum-framework zijn twee rollen absoluut essentieel: de Product Owner en de Scrum Master. Hun verantwoordelijkheden, focus en manier van werken verschillen sterk, maar juist doordat ze elkaar aanvullen, kan een Scrum-team optimaal presteren.

In dit artikel deel ik, David Korten, Scrum Master bij Identify, hoe deze rollen elkaar versterken en welke unieke bijdrage ze leveren aan het succes van agile teams.

Focus en verantwoordelijkheden?

Product Owner – Het ‘wat’ en ‘waarom’

De Product Owner bepaalt wat er wordt ontwikkeld en waarom dit waardevol is voor klant en organisatie. De verantwoordelijkheden zijn onder meer:

  • Het maximaliseren van de waarde van het product;
  • Het beheren en prioriteren van de Product Backlog;
  • Stakeholdermanagement en het uitdragen van de productvisie.

Als Product Owner vertegenwoordig je de klant en ben je de schakel tussen het Scrum-team en de stakeholders.

Scrum Master – Het ‘hoe’ 

Als Scrum Master richt ik mij op hoe het team zo effectief mogelijk kan samenwerken. Daarbij:

  • Faciliteer ik het Scrum-proces, inclusief Daily Scrums, Retrospectives en Sprint Planning;
  • Verwijder ik obstakels (impediments) die het team hinderen;
  • Coach ik het team in zelforganisatie en Agile-principes.

Relatie met het Scrum-team

Product Owner

  • Geeft duidelijke doelen en prioriteiten aan het team;
  • Zorgt dat het team begrijpt wat er nodig is, maar bemoeit zich niet met de technische uitvoering.

Scrum Master

  • Beschermt het team tegen verstoringen van buitenaf;
  • Stimuleert samenwerking en bewaakt de toepassing van Scrum;
  • Helpt teamleden obstakels te overwinnen en agile vaardigheden te ontwikkelen.

Stakeholdermanagement en planning

Product Owner

  • Onderhoudt intensief contact met stakeholders om wensen, eisen en feedback te verzamelen;
  • Zorgt voor alignment tussen klantbehoeften en de ontwikkeldoelen van het team;
  • Stelt prioriteiten in de Product Backlog;
  • Bepaalt samen met stakeholders welke items de meeste waarde toevoegen.

Scrum Master

  • Heeft een interne focus en beschermt het team tegen onrealistische verwachtingen of druk van stakeholders;
  • Ondersteunt de Product Owner bij het communiceren van voortgang en resultaten;
  • Faciliteert processen om backlog-items efficiënt en effectief te realiseren;
  • Bewaakt de sprintdoelen en helpt het team bij het behalen ervan.

“De Product Owner bepaalt wat belangrijk is, de Scrum Master zorgt voor hoe het team dat het beste kan bereiken.” – David Korten, Scrum Master

Product owern en scrum master schrijven scrum op whiteboard tijdens een sprint sessie

Hoe vullen de Product Owner en Scrum Master elkaar aan?

Hoewel hun rollen verschillend zijn, vormen de Product Owner en Scrum Master samen de motor van een effectief Scrum-team.

Gezamenlijke missie: waarde leveren

  • Product Owner: stelt prioriteiten en definieert waarde;
  • Scrum Master: optimaliseert de manier waarop het team deze waarde realiseert.

Efficiënte communicatie

  • Product Owner: vertaalt stakeholderinput naar heldere backlog-items;
  • Scrum Master: zorgt dat het team deze input efficiënt verwerkt.

Bouwen aan een succesvol team

  • Product Owner: profiteert van een betrouwbaar team dat waarde levert.
  • Scrum Master: coacht het team in samenwerking en zelforganisatie;

Verwijderen van obstakels

  • Product Owner: lost strategische uitdagingen op, zoals veranderende prioriteiten.
  • Scrum Master: pakt interne belemmeringen aan;

Visie en uitvoering

  • Product Owner: levert de productvisie en prioriteiten;
  • Scrum Master: zorgt dat het team optimaal functioneert om deze te realiseren.

Hebben ze elkaar nodig?

Ja. De Product Owner en Scrum Master zijn complementair. Samen zorgen ze voor:

  • Heldere focus: de Product Owner bepaalt waarde en prioriteiten, de Scrum Master bewaakt de focus binnen het team.
  • Efficiënt proces: de Scrum Master faciliteert het proces zodat de doelen van de Product Owner haalbaar zijn.
  • Balans tussen team en stakeholders: de Product Owner richt zich op externe behoeften, terwijl de Scrum Master op teamwelzijn en samenwerking focust.

Conclusie

De Product Owner is de stem van de klant: bepaalt prioriteiten en maximaliseert productwaarde. De Scrum Master is de facilitator en coach: zorgt dat het team optimaal kan presteren. 

Samen vormen ze het fundament van een succesvol Scrum-team. Of, zoals ik het altijd zeg: “De Product Owner bepaalt wat belangrijk is, de Scrum Master zorgt voor hoe het team dat het beste kan bereiken.”

Klaar om te sparren?
Benieuwd wat Agile werken voor jouw organisatie kan betekenen? Bij Identify helpen we dagelijks toonaangevende organisaties om wendbaarder, efficiënter en succesvoller te worden. Neem contact met ons op of ontdek Agile werken.

Over de auteur

Foto van David Korten

David Korten

David Korten is Agile consultant bij Identify. Als Scrum Master streeft hij, met zijn kritische houding, voortdurend naar verbetering. Dankzij zijn ervaring in onder andere de publieke sector en de financiële dienstverlening heeft hij met diverse teams impact gemaakt in uiteenlopende trajecten.


Mail

Lees ook dit artikel eens

Identify Consultancy Amersfoort voor Agile, Business Analyse en Scrum is NEN 4400-1 gecertificeerd

Identify Consultancy Amersfoort Great Place To Work 2025

Contact

  • Koningin Wilhelminalaan 1
  • 3818 HN Amersfoort
  • Nederland



Linkedin-in




Instagram




Facebook-f

Over ons

Direct naar

Ik wil up to date blijven

Blijf op de hoogte met onze gratis nieuwsbrief.




Autonoom testen vs Gescripte testautomatisering

Vat samen met AI



OpenAI
ChatGPT



Perplexity
Perplexity



Claude
Claude



Gemini
Gemini

Blog

Autonoom testen vs Gescripte testautomatisering

Een praktische gids voor moderne QA-teams

Heb je ooit uren besteed aan het bijwerken van testscripts na een kleine UI-wijziging of moeite gehad om gelijke tred te houden met snelle ontwikkelingscycli? Je bent niet de enige. De evolutie van gescripte testautomatisering naar autonoom testen verandert de manier waarop teams softwarekwaliteit waarborgen. Graag leg ik, als Testprofessional bij Identify, uit wat deze verschuiving betekent voor moderne QA-teams en hoe je in de praktijk het verschil kunt maken.

De basis: Twee benaderingen, één doel

1. Gescripte testautomatisering

De traditionele krachtpatser van QA, gescripte testautomatisering, is afhankelijk van vooraf gedefinieerde testcases die door mensen zijn geschreven. Denk aan een gedetailleerd recept:

  • Hoe werkt het: Testers schrijven scripts (bijv. met Selenium of Cypress) om gebruikersacties te simuleren, zoals klikken op knoppen of het valideren van formulieren.
  • Sterke punten: Ideaal voor stabiele applicaties met voorspelbare workflows (bijv. inlogstromen voor banken).
  • Beperkingen: Hoge onderhoudskosten (gebroken scripts na UI-updates), rigide structuur en beperkte flexibiliteit.

Voorbeeld: Het afrekenproces van een retail-app. Scripts valideren elke stap—artikelen toevoegen, kortingscodes toepassen, betaling—maar breken als de ID van de knop “Bestelling plaatsen” verandert.

 

2. Autonoom testen

Aangedreven door AI en machine learning, leren autonome testsystemen, passen zich aan en herstellen zichzelf zelfs. Stel je een zelfrijdende auto voor QA voor:

  • Hoe werkt het: AI analyseert gebruikersgedrag, genereert tests en past scripts dynamisch aan (bijv. het repareren van gebroken locators).
  • Sterke punten: Vermindert onderhoud met 60-80%, behandelt complexe scenario’s (bijv. fluctuerende voorraadsystemen) en schaalt mee met agile pijplijnen.
  • Beperkingen: Vereist initiële setup en vertrouwen in AI-beslissingen.

Voorbeeld: Een e-commerce site met een dynamische UI. Autonome tests passen zich aan lay-outwijzigingen aan (bijv. een opnieuw ontworpen productpagina) zonder handmatige scriptupdates.

Belangrijkste verschillen in één oogopslag

Aspect

Gescripte testautomatisering

Autonoom testen

Onderhoud

Hoog (handmatige updates)

Laag (zelfherstellend)

Aanpasbaarheid

Rigide

Dynamisch (AI-gestuurde aanpassingen)

Leervermogen

Geen

Verbetert na verloop van tijd

Beste toepassingen

Stabiele, repetitieve workflows

Agile projecten met frequente wijzigingen

“De toekomst ligt in een slimme combinatie van beide benaderingen. Zo houd je niet alleen grip op de technische details, maar blijf je ook wendbaar in een digitale wereld die nooit stilstaat.” – Stefan 

Praktische toepassingen

Waar gescripte automatisering uitblinkt:

  • Regressietesten: Validatie van kernfunctionaliteiten na updates (bijv. ervoor zorgen dat een API voor vluchtboekingen nog steeds tarieven correct berekent).
  • Compliancechecks: Validatie van HIPAA/GDPR-workflows in gezondheidsapps waar audit trails cruciaal zijn.

Waar autonoom testen excelleert:

  • Dynamische applicaties: Testen van een maaltijdbezorgingsapp met realtime menu-/prijswijzigingen (AI past tests aan als items uitverkocht raken).
  • Grootschalige systemen: Validatie van IoT-ecosystemen (bijv. slimme apparaten thuis) waar interacties onvoorspelbaar zijn.
  • CI/CD-pijplijnen: Het uitvoeren van 1.000+ tests per nacht in de implementatiecyclus van een fintech-startup zonder menselijke tussenkomst.

Waarom dit belangrijk is voor jouw team

  • Snelheid: Autonoom testen verkort de testuitvoeringstijd met 40% bij bedrijven zoals Walmart en Netflix.
  • Kostenbesparing: Minder onderhoud geeft QA-engineers de ruimte om zich te richten op exploratief testen en edge cases.
  • Kwaliteit: AI detecteert subtiele bugs (bijv. geheugenlekken in gaming-apps) die scripts mogelijk missen.

De toekomst van testen

De industrie verschuift naar hybride modellen, bijvoorbeeld:

  • Fase 3 autonomie: AI stelt testscenario’s voor, maar mensen keuren deze goed (gebruikelijk in automotive software).
  • Fase 5 autonomie: Volledig AI-gestuurd testen, zoals bij Netflix’s contentaanbevelingsalgoritmes.

Aan de slag gaan

  • Voor gescripte automatisering: Tools zoals Selenium of Testsigma werken goed voor stabiele apps.
  • Voor autonoom testen: Verken platforms zoals Testim of LambdaTest die AI/ML integreren.

Conclusie

Gescripte testautomatisering blijft een onmisbare basis voor stabiele workflow. Maar in een wereld waarin software voortdurend verandert en ontwikkelingscycli steeds korter worden, biedt autonoom testen de flexibiliteit en schaalbaarheid die moderne QA-teams nodig hebben.

De toekomst ligt in een slimme combinatie van beide benaderingen: gescripte automatisering als solide fundament, aangevuld met autonoom testen om snelheid, adaptiviteit en kwaliteit te waarborgen. Zo houd je niet alleen grip op de technische details, maar blijf je ook wendbaar in een digitale wereld die nooit stilstaat.

Of je nu aan het begin staat van testautomatisering of al werkt met AI-gestuurde tools: de keuze is niet óf-óf, maar hóe je beide het beste inzet om jouw team naar een hoger niveau te tillen.

Bronnen

Over de auteur


Foto van Stefan Brezina

Stefan Brezina

Als enthousiaste test engineer heb ik een passie voor nieuwe testtechnologieën en ben ik voortdurend op zoek naar ontwikkelingen en vaardigheden om me verder te verdiepen.


Mail

Lees ook dit artikel eens

Identify Consultancy Amersfoort voor Agile, Business Analyse en Scrum is NEN 4400-1 gecertificeerd

Identify Consultancy Amersfoort Great Place To Work 2025

Contact

  • Koningin Wilhelminalaan 1
  • 3818 HN Amersfoort
  • Nederland



Linkedin-in




Instagram




Facebook-f

Over ons

Direct naar

Ik wil up to date blijven

Blijf op de hoogte met onze gratis nieuwsbrief.




Identify is NEN 4400-gecertificeerd

Vat samen met AI



OpenAI
ChatGPT



Perplexity
Perplexity



Claude
Claude



Gemini
Gemini

Actueel

Identify is NEN 4400-gecertificeerd

De volgende stap in onze ontwikkeling

We zijn trots om te delen dat Identify officieel NEN 4400-gecertificeerd is. Deze certificering is een belangrijke mijlpaal in onze groei als organisatie, en onderstreept waar wij voor staan: transparantie, betrouwbaarheid en kwaliteit.  Met deze stap versterken we onze basis om verder te bouwen aan duurzame relaties met opdrachtgevers, partners en onze eigen professionals.

Wat is NEN 4400 certificering?

De NEN 4400-norm is een onafhankelijke kwaliteitsstandaard die opdrachtgevers beschermt tegen risico’s bij het inlenen van arbeid of het uitbesteden van werk.  Organisaties die dit keurmerk ontvangen, tonen aan dat zij hun (personeels)administratie op orde hebben, belasting en sociale premies correct en tijdig afdragen, voldoen aan geldende arbeidswetgeving, geen risico vormen op schijnconstructies of malafide praktijken.

De certificering wordt uitgevoerd door een onafhankelijke inspectie-instelling en jaarlijks opnieuw beoordeeld. Het is dus geen momentopname, maar een blijvende bevestiging van professioneel ondernemerschap.

“Deze certificering bevestigt wat we intern al jaren naleven: gewoon goed werk leveren, op een zorgvuldige en verantwoorde manier.”
– Marleen

Vincent en Marleen namen namens IT consultancy Identify in Amersfoort de NEN4400 certificering in ontvangst

Waarom wij kozen voor de NEN-certificering

Bij Identify geloven we in eigenaarschap, oprechte aandacht en continue groei; voor onze mensen, onze klanten en partners. De keuze voor de NEN 4400-certificering past dan ook bij de manier waarop wij werken en samenwerken.

“Onze propositie Co-create to Accelerate is niet zomaar een slogan, maar een belofte,” vertelt Marleen Kleijn, HR directeur van Identify. “Een belofte dat we samen met onze klanten duurzame oplossingen creëren én bouwen aan sterke, gelijkwaardige partnerships. We geloven in samenwerking waarin vertrouwen centraal staat.

Daar hoort ook vertrouwen in onze organisatie bij. Van opdracht en contractvorming tot verloning: wij willen dat alles klopt. Transparant, eerlijk en professioneel geregeld. Deze certificering bevestigt wat we intern al jaren naleven: gewoon goed werk leveren, op een zorgvuldige en verantwoorde manier,” vult ze aan.

Vertrouwen in de praktijk

Voor onze opdrachtgevers biedt deze certificering nóg meer zekerheid. Zeker in een tijd waarin flexibiliteit, wet- en regelgeving en risicobeheersing steeds belangrijker worden.  De NEN 4400-certificering laat zien dat wij onze verantwoordelijkheid nemen. Niet alleen in woorden, maar in de manier waarop we georganiseerd zijn. Zo kunnen onze klanten en partners vertrouwen op een solide samenwerking, gebaseerd op wederzijds respect en gedeeld eigenaarschap.

Wij zijn Identify

Al ruim vijftien jaar biedt Identify een sterke combinatie van diensten voor het optimaliseren van producten en processen binnen organisaties. Dat doen we niet vóór, maar samen mét onze opdrachtgevers.

Onze Agile consultants, Business Analisten en Test consultants zijn meer dan vak experts. Dankzij expertise-overschrijdende samenwerking en gedeeld eigenaarschap pakken we complexe vraagstukken integraal aan. Met Amersfoort als onze thuisbasis realiseren we duurzame verbeteringen voor organisaties in heel Nederland.

Co-create to accelerate


Foto van Klaar om te sparren?

Klaar om te sparren?

Met een unieke aanpak op basis van co-creatie en onze expertise in Agile, Business Analyse en IT-Testen helpen we organisaties door heel Nederland écht vooruit. Heb jij een uitdaging? We denken graag met je mee!


Daag ons uit

Lees ook dit artikel eens