Herken je dat? Je krijgt een enorme epic voorgeschoteld die zó vaag en complex is dat je denkt: “Hoe ga ik dit ooit testen?” Je bent niet de enige. In dit artikel ontdek je hoe jij als tester kunt helpen om zulke epics om te zetten in heldere, testbare user stories – en zo het hele proces een stuk beter en werkbaarder maakt.
Je leert niet alleen hoe je epics slim kunt opsplitsen, maar ook hoe jij als tester vanaf het begin écht het verschil kunt maken. Met de inzichten uit dit artikel ben je straks klaar om in je volgende refinement sessie direct waarde toe te voegen en scherpe vragen te stellen die er toe doen.
Wat zijn EPICS en waarom zijn ze vaak moeilijk te testen?
De hiërarchie in agile werk begrijpen
In agile projecten werk je vaak met verschillende niveaus van werk. Helemaal bovenaan staan de epics: grote brokken werk die je meestal nog moet opdelen voordat je er écht iets mee kunt. Die deel je op in kleinere, uitvoerbare user stories waar je als team direct mee aan de slag kunt.
De typische hiërarchie ziet er als volgt uit:
- Thema’s: strategische doelen die vaak meerdere EPICS omvatten
- EPICS: grote stukken werk die over meerdere sprints verdeeld worden
- Features: concrete functionaliteiten die een duidelijk doel dienen
- User stories: kleine, concrete taken die binnen een sprint afgerond kunnen worden
EPICS zijn vaak moeilijk te testen omdat ze:
- Te groot zijn om in één sprint af te ronden
- Meerdere functionaliteiten bevatten die elkaar kunnen beïnvloeden
- Vaak te vaag geformuleerd zijn omdat ze een groot geheel beschrijven
- Afhankelijkheden hebben die niet altijd duidelijk zijn
Deze problemen maken het essentieel om EPICS op te delen in kleinere, beter testbare user stories.
De kenmerken van een goede, testbare user story
Wat maakt een user story eigenlijk goed testbaar? Hiervoor kunnen we de INVEST-criteria gebruiken. INVEST staat voor: Independent (onafhankelijk), Negotiable (onderhandelbaar), Valuable (waardevol), Estimable (schatbaar), Small (klein) en Testable (testbaar).
Laten we focussen op de ‘T’ van Testable:
- Een testbare user story heeft duidelijke acceptatiecriteria
- Je kunt eenvoudig bepalen of de story geslaagd of gefaald is
- De criteria zijn concreet en niet voor meerdere interpretaties vatbaar
- Je kunt de functionaliteit isoleren en onafhankelijk testen
- De scope is klein genoeg om binnen één sprint te testen
Kleine, onafhankelijke stories hebben grote voordelen voor zowel development als testing:
- Ze kunnen sneller worden voltooid en getest
- Problemen worden eerder geïdentificeerd
- Het risico wordt verspreid over meerdere kleine stories in plaats van één grote
- De feedback-loop is korter, waardoor je sneller kunt bijsturen
Vijf effectieve technieken voor het splitsen van EPICS
Als tester kun je juist in dit stuk veel waarde toevoegen. Door actief mee te denken bij het opsplitsen van epics maak je echt het verschil. Hieronder vind je vijf praktische technieken die je direct kunt toepassen.
Techniek 1: Splitsen op basis van gebruikersrollen
Elke gebruiker kijkt anders naar je systeem. Wat een beheerder doet, is totaal anders dan wat een eindgebruiker nodig heeft. Juist daarom zijn gebruikersrollen een logische basis om een epic op te splitsen.
Voorbeeld:
Stel, je hebt een epic over gebruikersbeheer. Die kun je opdelen in verschillende stories, zoals:
- Een beheerder die gebruikers kan toevoegen en verwijderen
- Een teamleider die rechten kan instellen
- Een eindgebruiker die zijn eigen profiel kan aanpassen
Door per rol aparte stories te maken, kun je veel gerichter testen. Elke story heeft een duidelijk doel, afgestemd op één type gebruiker. Dat maakt je testcases niet alleen specifieker, maar ook overzichtelijker en effectiever.
Techniek 2: Splitsen op basis van processtappen
Een proces bestaat meestal uit meerdere stappen die de gebruiker doorloopt. Door je epic op te delen langs die stappen, maak je er logische, testbare stukjes van.
Voorbeeld:
Bij een aanvraagproces kun je denken aan stories zoals:
- Het invullen van een aanvraagformulier
- Het uploaden van documenten
- Het verifiëren van gegevens
- Het ontvangen van een bevestiging
Deze aanpak zorgt ervoor dat je elke stap afzonderlijk kunt testen. Dat maakt het niet alleen overzichtelijker, maar ook betrouwbaarder: fouten worden sneller gevonden én beter begrepen.
Techniek 3: Splitsen op basis van bedrijfsregels en beslismomenten
Sommige epics bevatten complexe logica of regels. Die kun je goed gebruiken als scheiding tussen stories, vooral als er verschillende beslissingen genomen moeten worden.
Voorbeeld:
Stel, je werkt aan een beoordelingsmodule. Dan kun je de epic opsplitsen in stories zoals:
- Beoordelen op basis van inkomen
- Beoordelen op basis van krediethistorie
- Beoordelen op basis van aanvraagbedrag
- Combinaties van beoordelingscriteria
Door elke regel of beslissing als aparte user story te benaderen, kun je veel specifieker testen. Je krijgt scherpere testcases én je ziet sneller waar de randgevallen zitten.
Techniek 4: Opdelen op basis van databronnen
Werk je met meerdere databronnen? Dan is dat vaak een logische manier om een epic op te splitsen — vooral als het gaat om integraties of rapportages.
Voorbeeld: Een EPIC voor een rapportagedashboard kan opgedeeld worden in stories voor:
- Klantgegevens uit het CRM-systeem weergeven
- Transactiegegevens uit het kernsysteem tonen
- Compliancedata uit het regelgevingssysteem integreren
- Gegevens combineren in samenvattende grafieken
Zo kun je als tester precies nagaan hoe elke databron wordt verwerkt. Dat helpt je om fouten in data-integriteit of bij de omzetting van gegevens vroegtijdig op te sporen.
Techniek 5: Voorkom technische versnippering: splits verticaal i.p.v. horizontaal.
Bij het opsplitsen van epics werkt verticaal splitsen meestal beter dan horizontaal. Als je horizontaal splitst – dus per technische laag, zoals frontend, backend of database – krijg je losse stukken die op zichzelf weinig waarde hebben én lastig te testen zijn.
Verticaal splitsen werkt anders: je maakt kleine stukjes functionele software die van begin tot eind werken, al is het in beperkte vorm. Zo snijdt elke story door alle lagen heen, maar levert het wel iets op wat je kunt gebruiken én testen.
Denk aan het verschil tussen “alle UI-elementen bouwen” of “alle backend-functionaliteit doen” (horizontaal) versus een story als “gebruiker kan inloggen” of “wachtwoord resetten” (verticaal). Die laatste zijn veel beter testbaar, omdat ze direct echte functionaliteit opleveren.
De rol van de tester bij het verfijnen van EPICS
Kritische vragen die je als tester kunt stellen
Als tester kun je al vroeg in het proces enorm veel waarde toevoegen – nog voordat er ook maar één regel code is geschreven. Tijdens refinement sessies is het jouw moment om scherpe vragen te stellen en zo te zorgen voor betere, testbare user stories. Denk aan vragen als:
- “Hoe kunnen we deze story testen?”
Als niemand daar een duidelijk antwoord op heeft, is dat een signaal dat de story nog niet testbaar genoeg is. - “Wat zijn de acceptatiecriteria?”
Zonder die criteria weet je niet wanneer iets ‘af’ is – laat staan of het goed werkt. - “Wat gebeurt er als…?”
Door edge cases en uitzonderingen naar boven te halen, help je het team om de story scherper te definiëren. - “Hoe past deze story in het grotere geheel?”
Hiermee breng je afhankelijkheden en integratiepunten in beeld, voordat ze voor problemen zorgen. - “Is deze story klein genoeg om binnen één sprint te testen?”
Zo niet? Dan moet hij waarschijnlijk nog verder opgesplitst worden.
Let in refinement ook goed op een paar veelvoorkomende valkuilen:
- Te grote stories goedkeuren om gedoe te vermijden
- Niet-functionele eisen (zoals performance of security) over het hoofd zien
- Denken dat iedereen dezelfde aannames heeft
- Onduidelijkheid over wie de eindgebruiker eigenlijk is – en wat die nodig heeft
Testbaarheid als reden om een story op te splitsen
Testbaarheid is een sterke reden om een epic of user story verder op te knippen. Twijfel je of iets te groot of te vaag is? Kijk dan eens naar deze signalen:
- Hoeveel testscenario’s zijn er nodig?
Heeft een story er tientallen? Dan is de kans groot dat hij te groot is voor één sprint. - Zijn de acceptatiecriteria duidelijk?
Als die lastig te formuleren zijn, is de story waarschijnlijk nog te vaag. - Zijn er veel afhankelijkheden?
Moet je wachten op andere onderdelen of teams voordat je kunt testen? Dan is de story niet zelfstandig genoeg. - Hoe complex zijn de testcases?
Als het testen heel ingewikkeld wordt, is dat vaak een teken dat de story te veel in zich heeft.
Zodra je één of meer van deze signalen ziet, heb je een goed argument om de story op te splitsen. Bijvoorbeeld:
“Deze story heeft meer dan 20 testscenario’s. Dat is eigenlijk niet werkbaar binnen één sprint. Kunnen we hier kleinere, beter testbare stories van maken?”
Stap voor stap: van een grote epic naar testbare user stories
Laten we samen kijken hoe je een grote, complexe epic omzet naar werkbare en testbare user stories. We gebruiken een voorbeeld uit de financiële sector.
Een praktijkvoorbeeld
Stel, je werkt met een team bij een bank en je krijgt de volgende epic voorgelegd:
“Als bank willen we een nieuw digitaal onboardingproces voor nieuwe klanten implementeren, zodat we het openen van rekeningen kunnen versnellen en de klanttevredenheid verhogen.”
Klinkt als een mooie ambitie, maar… deze epic is veel te groot en te vaag om direct mee aan de slag te gaan. Hij bevat allerlei losse onderdelen: meerdere processen, verschillende gebruikersrollen, integraties met interne én externe systemen (zoals identiteitsverificatie). Niet iets wat je zomaar in één sprint testbaar maakt.
Zo pak je het opdeelproces aan
Oké, hoe maak je van zo’n grote epic iets werkbaars? Door stap voor stap te kijken wat er allemaal in zit – en waar je logische snijpunten kunt maken.
1. Kijk eerst naar de verschillende gebruikers:
Wie gebruiken het systeem, en wat doen ze precies?
- Potentiële klanten – zij doorlopen het onboardingproces
- Bankmedewerkers – zij controleren en verwerken de aanvragen
- Compliance-afdeling – zij houden toezicht op de regels en processen
2. Breng daarna de belangrijkste processen in kaart:
Welke stappen zitten er allemaal in het digitale onboardingproces?
- Klantprofiel aanmaken
- Identiteit verifiëren
- Risico’s beoordelen
- Product (zoals een rekening) aanvragen
- Documenten ondertekenen en versturen
- Goedkeuring geven op de aanvraag
3. Bedenk vervolgens welke databronnen betrokken zijn:
Waar haalt het systeem z’n gegevens vandaan?
- Interne klantsystemen
- Externe verificatiepartijen
- Compliance-databases
- Productsystemen van de bank
4. En dan: maak verticale slices
De laatste stap is het opdelen van de epic in zogeheten verticale slices: kleine, functionele eenheden die op zichzelf waardevol zijn voor de gebruiker én direct te testen. Elke slice loopt van frontend tot backend en vormt één afgerond stukje van het proces.
Als je dat toepast op de onboarding-epic, krijg je bijvoorbeeld deze user stories:
- Als potentiële klant wil ik een profiel kunnen aanmaken met mijn basisgegevens, zodat ik het aanvraagproces kan starten.
- Als potentiële klant wil ik mijn identiteit kunnen verifiëren via DigiD, zodat ik niet fysiek naar een bankkantoor hoef.
- Als potentiële klant wil ik kunnen kiezen welk type rekening ik wil openen, zodat ik een product krijg dat past bij mijn behoeften.
- Als potentiële klant wil ik documenten digitaal kunnen ondertekenen, zodat ik het hele proces online kan afronden.
- Als bankmedewerker wil ik een dashboard zien met nieuwe aanvragen, zodat ik die kan controleren en goedkeuren.
- Als compliance officer wil ik dat er automatisch risicocontroles worden uitgevoerd, zodat we voldoen aan KYC- en AML-regelgeving.
Elke story is concreet, gekoppeld aan één gebruiker en één duidelijk doel. Daardoor zijn ze niet alleen overzichtelijk, maar ook goed af te bakenen en testbaar.
De testbaarheid beoordelen: voorbeelden uit de praktijk
Laten we eens kijken hoe je de testbaarheid van user stories kunt inschatten. We nemen twee voorbeelden uit het onboardingproces.
Story 2:
“Als potentiële klant wil ik mijn identiteit kunnen verifiëren via DigiD, zodat ik niet fysiek naar een kantoor hoef.”
Wat is er goed aan deze story?
- De functionaliteit is duidelijk en afgebakend
- Je kunt concrete acceptatiecriteria formuleren (zoals: “Het systeem maakt succesvol verbinding met DigiD”)
- De story is te testen met scenario’s zoals: succesvolle verificatie, mislukte poging, time-out
Wat kan beter?
- Wat moet er gebeuren bij een time-out of foutmelding?
- Is er een fallback-optie als DigiD niet werkt?
- Moet er logging plaatsvinden voor auditdoeleinden?
Door die vragen te beantwoorden, maak je de story nog testbaarder én voorkom je verrassingen tijdens de ontwikkeling.
Story 5:
“Als bankmedewerker wil ik een dashboard hebben van nieuwe aanvragen, zodat ik deze kan controleren en goedkeuren.”
Waarom is deze story minder testbaar?
- Het gaat om meerdere functionaliteiten in één: overzicht, details bekijken, acties uitvoeren
- Performance is niet benoemd (bijv. wat als er 100+ aanvragen zijn?)
- Toegangsrechten en beveiliging zijn niet uitgewerkt
Wat kun je doen?
Splits de story op in drie kleinere, gerichte stories:
- 5.1 Als bankmedewerker wil ik een overzicht zien van alle nieuwe aanvragen met status, zodat ik mijn werkvoorraad kan beheren.
- 5.2 Als bankmedewerker wil ik details van een aanvraag kunnen bekijken, zodat ik deze kan beoordelen.
- 5.3 Als bankmedewerker wil ik een aanvraag kunnen goedkeuren of afwijzen, zodat ik mijn beoordelingsresultaat kan vastleggen.
Zo wordt elke stap concreet, beter af te bakenen én makkelijker te testen.
Veelgemaakte fouten – en hoe je ze voorkomt
Het opsplitsen van epics is een krachtige techniek, maar ook iets waar je snel in kunt doorslaan. Hieronder twee veelvoorkomende valkuilen – en hoe je ermee omgaat.
Te kleine user stories zonder zelfstandige waarde
Soms wordt er zó fanatiek gesplitst dat je eindigt met stories die op zichzelf eigenlijk niks doen. Hoe herken je dat?
- De story levert op zichzelf geen bruikbare functionaliteit op voor de gebruiker
- Je kunt ‘m niet los testen, alleen in combinatie met andere stories
- Het voelt meer als een subtaak dan als een volwaardige user story
Voorbeeld: een story als “UI voor het klantonboardingformulier bouwen” klinkt concreet, maar zonder achterliggende logica kun je er nog niets mee. Die is dus niet zelfstandig testbaar.
Vuistregels voor te kleine stories:
- Levert de story geen gebruikerswaarde op?
- Voldoet de story niet zelfstandig aan de definitie van ‘klaar’?
- Is het eigenlijk gewoon een taak onder een grotere story?
- Kun je de story niet zinnig demonstreren aan stakeholders?
Dan is het waarschijnlijk beter om ‘m te bundelen met andere onderdelen.
Afhankelijkheden tussen user stories
Te veel afhankelijkheden maken je planning stroperig en het testen lastig. Het doel is om zoveel mogelijk zelfstandige stories te maken, maar soms ontkom je er niet aan.
Hoe bevorder je onafhankelijkheid?
- Splits stories verticaal (dus over alle lagen heen)
- Gebruik mocks of testinterfaces als er nog geen echte koppelingen zijn
- Plaats gerelateerde stories in dezelfde sprint als de afhankelijkheid klein is
- Breng afhankelijkheden altijd expliciet in kaart
Als afhankelijkheden onvermijdelijk zijn:
- Noteer ze in beide stories, zodat niemand verrast wordt
- Plan ze bewust in de juiste volgorde
- Combineer stories als ze niet los van elkaar te realiseren zijn
- Bedenk een teststrategie die hiermee rekening houdt
Voorbeeld: bij banken en verzekeraars kom je dit vaak tegen. Denk aan de story “rekeningtype kiezen” (story 3), die pas kan als de identiteit van de klant geverifieerd is (story 2). In zo’n geval is het cruciaal dat deze afhankelijkheid expliciet wordt meegenomen in de planning en testaanpak.
Testbare user stories in je dagelijkse praktijk
Tips om je team mee te krijgen
Werken met testbare user stories klinkt logisch, maar in de praktijk moet je soms je team overtuigen. Deze argumenten helpen daarbij:
- Kleinere risico’s: door grote epics op te splitsen, verspreid je het risico over meerdere kleinere stories
- Snellere feedback: kleine stories zijn sneller ontwikkeld en dus sneller te testen
- Betere schattingen: duidelijke, compacte stories zijn makkelijker in te schatten
- Flexibeler plannen: kleine stories kun je eenvoudiger schuiven of herprioriteren
- Hogere kwaliteit: gerichte stories zorgen voor betere testdekking en dus een beter eindproduct
Daarnaast is het cruciaal dat testers al vroeg in het proces worden betrokken. Zij brengen een ander perspectief mee dan developers of analisten:
- Ze denken in uitzonderingen, randgevallen en foutscenario’s
- Ze signaleren onduidelijkheden in requirements voordat die tot bugs leiden
- Ze helpen bij het scherp formuleren van acceptatiecriteria
- Ze zorgen dat stories testbaar zijn vóórdat de bouw begint
Door die rol actief te pakken, til je als tester niet alleen de kwaliteit van de user stories, maar ook van het hele ontwikkelproces naar een hoger niveau.
Checklist: is je user story testbaar?
Gebruik deze checklist tijdens refinement om te beoordelen of een user story klaar is voor ontwikkeling én goed testbaar is. Loop ‘m stap voor stap na:
Acceptatiecriteria
- Zijn ze duidelijk, specifiek en meetbaar?
- Dekken ze alle belangrijke aspecten van de functionaliteit?
Onafhankelijkheid
- Kan de story op zichzelf getest worden, zonder afhankelijk te zijn van andere stories?
- Zijn de afhankelijkheden minimaal en helder?
Omvang en haalbaarheid
- Is de story klein genoeg om binnen één sprint af te ronden én te testen?
- Is het aantal testscenario’s overzichtelijk?
Randvoorwaarden
- Zijn input en output goed gedefinieerd?
- Is duidelijk wat wel en niet binnen scope valt?
Niet-functionele eisen
- Zijn zaken als performance, beveiliging en gebruiksvriendelijkheid benoemd?
- Kunnen deze eisen ook daadwerkelijk getest worden?
Door deze punten systematisch na te lopen, voorkom je dat er vage of te grote stories de sprint in glippen. Zo werk je als team met meer grip, betere verwachtingen en hogere kwaliteit.
Conclusie en volgende stappen
Het opdelen van epics naar testbare user stories is geen trucje, maar een waardevolle vaardigheid die jouw team écht verder helpt. En als tester speel jij daarin een sleutelrol. Je kijkt met een ander perspectief, stelt de vragen die anderen soms overslaan en helpt om onduidelijkheden al vroeg boven tafel te krijgen.
Jouw bijdrage zorgt ervoor dat:
- stories testbaar zijn vóórdat ze in ontwikkeling gaan
- acceptatiecriteria concreet en duidelijk zijn
- de grootte van stories werkbaar blijft
- risico’s eerder worden gesignaleerd
Wat neem je mee uit dit artikel?
- Werk met de INVEST-criteria, en focus daarbij vooral op de T van testbaar
- Kies de splits-techniek die past bij je situatie (gebruikersrollen, processen, databronnen, enz.)
- Denk in verticale slices, niet in technische lagen
- Betrek testers vroeg in het proces
- Gebruik een checklist om stories tijdens refinement kritisch te beoordelen
Wat kun je direct doen?
- Stel in je volgende refinement sessie vragen die de testbaarheid toetsen
- Signaleer te grote stories en stel voor hoe ze beter op te splitsen zijn
- Help bij het formuleren van scherpe acceptatiecriteria
- Zorg dat je betrokken bent in de vroege fases van planning
Door je te ontwikkelen in het slim opdelen van epics en het scherp krijgen van user stories, vergroot je niet alleen je waarde als tester – je tilt ook de kwaliteit van het hele product naar een hoger niveau.
Aanbevolen artikel:
Wil je meer weten over hoe je als tester kunt bijdragen aan het agile ontwikkelproces? Bekijk dan ook onze andere artikelen over user stories en testbaarheid.
