Testen is een belangrijk onderdeel in onze projecten om kwaliteit en resultaat te waarborgen. Er wordt vaak naar “de tester” gekeken om dit te doen. Logisch natuurlijk, hier ligt een groot deel van de verantwoordelijkheid. Maar een tester doet dit niet alleen en vaak is hier nog veel winst te halen. Bij testen denk je al gauw aan datgene controleren wat developers hebben gemaakt. Werkt het wel zoals bedoeld? Dit is een belangrijke stap maar zeker niet de eerste en ook niet de laatste.

Het begint al zo vroeg als bij het budgetteren van het project. Iedereen is enthousiast en wil zoveel mogelijk gaan maken. Vette dingen, baanbrekende functionaliteiten en coole designs. Belangrijk is om hier ook al na te denken over hoe je kwaliteit wilt gaan waarborgen. Hoe complex is het project dat je gaat doen? Hoe cruciaal is het voor de kernprocessen in je organisatie? Hoeveel bezoekers verwacht je? Welke devices gaan er voornamelijk gebruikt worden? Allemaal vragen die bepalen hoeveel capaciteit op welke rol je nodig hebt. Iedereen speelt namelijk een rol als het gaat om testen.

Tip 1: Ga al zo vroeg mogelijk bij een (potentieel) project het gesprek aan over testen. Dit kan vanuit verschillende rollen maar het liefst vanuit de tester. Dit is een mooi moment om zelf al een goed beeld te krijgen van hetgeen dat nodig is en de partner (klant) mee te nemen in alle facetten van het testen.


De ruggengraat van een project is de backlog. Een goed uitgewerkte en bijgehouden backlog draagt veel bij aan een overzichtelijk en goed lopend project. Hier ligt al gelijk een belangrijke taak met betrekking tot testen. Ik zeg bewust niet “voor de tester” omdat het een team effort is om hier scherp op te zijn. Het is namelijk erg belangrijk om te zorgen dat de “Acceptatie Criteria” bekend zijn (overall en per item) en dat daarmee de verwachting op een goede manier ‘gemanged’ kan worden. De wensen en verwachtingen van de klant kennen is cruciaal om te kunnen testen of functionaliteit werkt zoals bedoelt. Hoe concreter je dit kan maken, hoe hoger de kwaliteit, hoe sneller de doorlooptijd en hoe minder frustratie binnen alle rollen. Vaak is het efficiënt om vanuit 3 rollen te kijken naar PBI’s (Product backlog items). Bijvoorbeeld een Developer, Product Owner en Tester.

Wanneer developers uiteindelijk aan de gang gaan is het belangrijk om een goede OTAP straat te hebben. Hoe makkelijker het is om te releasen des te sneller kun je door het complete proces heen. Developers hebben binnen de code al verschillende mogelijkheden om testen in te bouwen. Of dit nodig is, heb je dan al bij het uitwerken van de PBI bepaald. Belangrijk is dat developers elkaars werk toetsen wat bij ons bekend is onder de naam ‘devtesten’. Hierdoor krijg je betere kwaliteit, leren ze van elkaar en hou je zelfs meer feeling met de codebase.

Vervolgens kan een tester er op de testomgeving mee aan de slag. Goede acceptatie criteria maken het makkelijker om een PBI functioneel af te tikken. Maar er zijn meer facetten waaraan aandacht besteed kan worden. Verschillende browsers, performance, minder gangbare karakters, combinaties van content en dat is zeker niet de hele lijst. In deze fase merk je dat het veel helpt als je korte lijnen kan houden met de andere projectleden. Check even bij de developer als het niet werkt zoals verwacht. Is het een setting, een bug, een verschil in omgeving of is het misschien niet goed gereleased? Snel schakelen kan veel tijd schelen. Tijdens het testen vind je vaak ook verbeterpunten of mogelijk nieuwe wensen. Snel contact met de Product Owner kan hier waardevol zijn. Zijn het nieuwe wensen, gaat dit wel werken voor de gebruikers of kunnen we hier misschien nog op door ontwikkelen?

Tip 2: Zorg dat je de voldoende informatie achterhaalt om concrete vragen aan developers en de product owner te stellen. Maak zelf al onderscheid tussen nieuwe functionaliteit en testbevindingen voordat je dit voorlegt bij een product owner. Schakel snel en met voorkeur via telefoon of videobellen. Focus op PBI’s naar done krijgen.


Als het goed is, heb je nadat de testbevindingen zijn verwerkt vertrouwen in de PBI die je oplevert naar de acceptatie omgeving. Tijd voor de product owner om deze te accepteren. Afhankelijk van de complexiteit van een PBI kun je ervoor kiezen om een stuk overdracht te doen. Is het heel technisch of vraagt het wat specifieke handelingen dan kan het waardevol zijn om die telefoon te pakken en er op voorhand even samen doorheen te lopen. Een product owner kan ook van andere mensen gebruik maken om een acceptatie test te doen. Vaak is het waardevol om content editors die er daadwerkelijk mee gaan werken mee te laten kijken tijdens de ontwikkelfase. Het is wel belangrijk dat de product owner of een gemachtigde een PBI uiteindelijk aanmerkt als “done”.

Voor de flow van het project helpt het als een product owner niet alleen in tijdsblokken beschikbaar is maar door de hele sprint heen. Je wilt zo snel mogelijk feedback op PBI’s zodat het afgerond kan worden en een developer hier niet meer op terug hoeft te komen. Zo krijg je ook een beter beeld in de voortgang van een sprint. Een tester kan ervoor zorgen dat hij veel contact heeft met de product owner. Zorg dat je beschikbaar bent als deze aan het testen is en direct in kan spelen op vragen die ontstaan. Je kan er zelfs voor kiezen om er dan gelijk een developer bij te halen, conclusies te trekken en af te ronden.

Tip 3: Gebruik content editors en het vullen van de productie omgeving als extra test. Je hebt hier relevante content in grotere hoeveelheden . Dit kan heel geschikt zijn om bugs te vinden die anders erg veel tijd zouden kosten om te achterhalen. Zorg ervoor dat er iemand korte lijnen heeft en benaderbaar is voor deze content editors. De product owner rol is vaak ideaal.


Dat je testen niet alleen doet is ondertussen wel duidelijk . Van begin tot eind zijn er acties die de kwaliteit en voorspelbaarheid van je project raken. Het is aan iedereen binnen een project om hierin mee te denken, te signaleren en het gesprek aan te gaan. Uiteindelijk zijn het continue keuzes om risico’s tot in zekere mate af te dekken.

Als tester heb je dus iedereen nodig. Jij bent diegene die alles bij elkaar brengt en zo het testen binnen je project tot een succes maakt. Ik denk dan ook dat een tester een goede toevoeging is binnen elk project om bijvoorbeeld deze 3 tips in de praktijk te brengen. Heb jij iets aan deze tips? Heb je zelf nog tips of wil je een keer sparren? Laat het ons weten!

Meer weten over onze visie op testen?

Laat je gegevens achter en we nemen zo snel mogelijk contact met je op!
LimeScape.Form.MandatoryFields