MARCH 24, 2026 – FREE WEBIBAR: Future-Proofing SAP Cloud with AI & Automation
“Oh trouwens, we willen hier volgende dinsdag mee live gaan.” Het is een zin die elke ervaren tester weleens te horen kreeg, meestal op een moment dat het testwerk nog moet beginnen en de kalender allang tegen de deadline aanschuurt. Wat volgt is een vertrouwd scenario: een spannende nieuwe feature, een minder dan ideale voorbereiding, en een communicatie die op z’n zachtst gezegd stroef verloopt. Het resultaat is voorspelbaar, een overwerkte tester die onder zware druk moet presteren tegen een deadline die, met de beste wil van de wereld, niet anders dan utopisch te noemen is.
Dit artikel is gebaseerd op de ervaring van een M2Q-testconsultant die dit scenario aan den lijve ondervond binnen een langlopend project. Het is geen uitzondering, geen incident dat zich één keer voordoet en dan nooit meer. Het is een patroon dat in veel organisaties terugkeert, en de gevolgen ervan reiken verder dan één gestreste QA-engineer. In dit artikel gaan we dieper in op waarom dit gebeurt, wat het kost, en, belangrijker nog, hoe organisaties dit structureel kunnen voorkomen door QA vanaf de eerste dag een volwaardige stem te geven in de planning.
Het is geen onmogelijk scenario, maar het leidt wel vaak tot problemen achteraf. Zeker wanneer QA pas heel laat in het proces wordt ingeschakeld en dan te horen krijgt dat de livegang al over vier werkdagen gepland staat. Vier dagen om een feature van A tot Z te testen, met de impliciete boodschap: als je issues vindt, meld ze dan onmiddellijk, want er is geen ruimte om te wachten.
Voor een tester met acht jaar ervaring binnen hetzelfde project, en met de senioriteit om die druk enigszins te relativeren, is dat al behapbaar, al is “behapbaar” niet hetzelfde als “optimaal”. Het resultaat van zo’n sprint onder tijdsdruk is zelden het niveau dat je normaal aflevert. En dan komt de bittere nasmaak: wanneer later blijkt dat andere teams evenmin klaar waren, en de deadline alsnog zonder pardon wordt verschoven, dringt zich een onvermijdelijke vraag op. Waarom werd er niet van bij het begin een haalbare deadline vastgelegd?
Het antwoord ligt zelden bij onwil. Het ligt meestal bij een planningsproces waarin testen wordt gezien als een sluitpost, iets dat “er nog wel bij kan” nadat de ontwikkeling is afgerond, in plaats van een integraal onderdeel van het traject van bij de eerste sprint.
Onrealistische deadlines ontstaan zelden met opzet. Ze zijn meestal het resultaat van een optelsom van kleine beslissingen: een marketingteam dat al een lanceringsdatum communiceerde voordat de scope vaststond, een projectmanager die de complexiteit van de integraties onderschat, of een ontwikkelteam dat de “happy path” test maar de randgevallen over het hoofd ziet. Testen wordt in dat scenario behandeld als een stap die je aan het einde van de rit toevoegt, in plaats van een activiteit die van bij de analysefase meeloopt.
Het gevolg is een planning die op papier klopt, maar in de praktijk geen enkele marge laat voor tegenslag. Er wordt geen rekening gehouden met afhankelijkheden tussen teams, met de tijd die nodig is om testcases op te stellen op basis van functionele analyses, of met de mogelijkheid dat een eerste testronde net de kritieke bugs blootlegt die de meeste tijd vergen om op te lossen. Zodra die strak geplande deadline dan onder druk komt te staan, is er geen enkele veiligheidsmarge om op terug te vallen, en is QA meestal de eerste schakel die moet compenseren.
Dat is precies het patroon dat de consultant beschrijft: een team dat er niet klaar voor was, een deadline die uiteindelijk toch verschoof, en een testfase die vooraf al onder een onhoudbare tijdsdruk stond. De ironie is pijnlijk. Als de deadline toch verschuift, waarom werd ze dan niet realistischer ingeschat van bij de start?
De impact van een te krap geplande testfase is zelden meteen zichtbaar, maar wel voelbaar op langere termijn.
Kwaliteit lijdt eronder. Wanneer een tester slechts vier dagen krijgt om een complexe feature grondig te doorlopen, is de kans reëel dat niet elk scenario aan bod komt. Niet omdat de tester onvoldoende kennis of inzet heeft, maar omdat de tijd simpelweg ontbreekt om alle randgevallen, integraties en negatieve scenario’s te doorlopen. Het resultaat is minder grondig dan wat een tester normaal gesproken aflevert, een kwaliteitsniveau dat niemand in het team eigenlijk wil accepteren, maar dat de tijdsdruk afdwingt.
Testschuld stapelt zich op. Testen die onder tijdsdruk oppervlakkig worden uitgevoerd, laten vaak sporen na in de vorm van niet-uitgevoerde testcases, ontbrekende testdekking of testautomatisering die er later “nog bij moet komen”. Die schuld verdwijnt niet vanzelf; ze wordt meegesleept naar de volgende sprint, en de volgende, tot ze op een gegeven moment als een blok aan het been van het team hangt.
Burn-out ligt op de loer. Een tester die keer op keer tegen onhaalbare deadlines aanloopt, en daarbij telkens de druk moet opvangen die eigenlijk elders in het proces is ontstaan, loopt een reëel risico op overbelasting. Dat geldt des te meer voor minder ervaren testers, die niet over dezelfde senioriteit beschikken om die druk te relativeren.
Reputatieschade, intern en extern. Wanneer een livegang uiteindelijk toch niet haalbaar blijkt, en de deadline alsnog verschuift, ondermijnt dat het vertrouwen in de planning binnen het volledige team. Extern, richting klanten of eindgebruikers, is het effect nog scherper: een gehaaste release die achteraf toch bugs blijkt te bevatten, doet meer schade aan de geloofwaardigheid van een organisatie dan een release die enkele dagen later, maar wel foutloos, wordt opgeleverd.
Zoals de consultant het treffend samenvat: een planning die zo strak is opgesteld dat de kleinste tegenslag al voor problemen zorgt, komt uiteindelijk minder professioneel over dan een planning die iets meer ademruimte laat, maar wel stipt wordt gehaald.
De echte les uit dit verhaal is niet dat testers harder moeten werken onder druk, dat lukt namelijk altijd, tot het een keer niet meer lukt. De echte les is dat testers vanaf het begin een plaats aan tafel verdienen, en niet pas wanneer de scope al vastligt en de deadline al gecommuniceerd is.
Een QA-professional heeft namelijk een uniek overzicht dat weinig andere rollen binnen een project hebben. Hij of zij kent de meeste features van een applicatie door en door, begrijpt hoe de verschillende onderdelen met elkaar verweven zijn, en ziet als geen ander welke scenario’s, ook de minder voor de hand liggende, betrokken kunnen zijn bij een nieuwe functionaliteit. Die kennis is niet alleen waardevol tijdens het testen zelf, maar minstens even waardevol tijdens de analysefase en de planning.
Wie kan immers beter inschatten hoeveel tijd het testen van een nieuwe feature effectief in beslag zal nemen dan de persoon die dat testwerk zal uitvoeren? Wie kan beter aangeven welke integraties een extra testronde vereisen, of welke randgevallen over het hoofd worden gezien in een functionele analyse? Een tester die pas wordt betrokken nadat de deadline al vaststaat, kan alleen nog reageren op een beslissing die al genomen is. Een tester die van bij het begin mee aan tafel zit, kan mee vormgeven aan een planning die haalbaar is, en die dat ook blijft.
Durf tegendruk te geven, wees realistisch in je inschatting, en dwing je aanwezigheid af vanaf het prille begin van een project of sprint. Een nee heb je, een ja kun je krijgen. Die boodschap geldt niet alleen voor testers zelf, maar evengoed voor de organisaties die hen inzetten: geef die stem ook effectief de ruimte om gehoord te worden.
Het is één ding om te erkennen dat testers vroeger betrokken moeten worden, en iets anders om dat ook effectief in de praktijk te brengen. Een aantal concrete aanknopingspunten die daarbij helpen:
Betrek QA al bij de refinement- en analysefase van een feature, niet pas bij de sprint waarin ze wordt opgeleverd. Op die manier kunnen testers vroegtijdig signaleren welke scenario’s, afhankelijkheden of risico’s over het hoofd worden gezien in de functionele analyse, vaak nog voor er één regel code is geschreven.
Laat testinschattingen meetellen in de sprintplanning, net zoals ontwikkeltijd dat doet. Een feature is pas “klaar om te plannen” wanneer zowel de ontwikkeling als het testen realistisch is ingeschat, niet wanneer enkel de ontwikkeltijd is vastgelegd en testen wordt geacht “er wel bij te passen”.
Bouw bewust marge in de planning in. Een deadline die geen enkele ruimte laat voor onvoorziene issues is geen deadline, maar een gok. Een realistische buffer zorgt ervoor dat een gevonden bug niet meteen de hele planning doet ontsporen.
Zet in op shift-left testing en waar mogelijk testautomatisering, zodat testen zo vroeg mogelijk in het ontwikkelproces meeloopt in plaats van pas helemaal aan het einde. Dat verkleint de kans dat problemen pas worden ontdekt wanneer de deadline al akelig dichtbij is.
Communiceer transparant over risico’s zodra ze zich aandienen. Als een team niet klaar is, of als de testfase meer tijd vraagt dan initieel voorzien, is het beter dat vroeg en duidelijk te melden dan te hopen dat het zich vanzelf oplost tegen de deadline.
Deze aanpak vraagt om een cultuurverandering: testen als een gelijkwaardig onderdeel van softwareontwikkeling behandelen, in plaats van als een noodzakelijke, maar ondergeschikte laatste stap.
Bij M2Q zien we dit patroon terugkomen bij verschillende klanten en projecten, en net daarom geloven we sterk in de meerwaarde van ervaren testconsultants die vroeg in het proces worden ingezet, met voldoende senioriteit om mee te wegen in planningsgesprekken en om tegendruk te geven wanneer een deadline niet realistisch is. Of het nu gaat om complexe overheidsplatformen, financiële toepassingen of grootschalige digitale dienstverlening: de kwaliteit van een release wordt niet bepaald op de dag van de livegang, maar in de weken en maanden daarvoor, in de manier waarop testen een plaats krijgt binnen de planning.
Een testconsultant die vanaf dag één mee aan tafel zit, levert niet alleen betere testresultaten op. Die consultant helpt ook om deadlines realistischer te maken, om risico’s tijdig te signaleren, en om de druk op het volledige team te verlichten, in plaats van die druk pas op het einde bij de tester te leggen. Dat is uiteindelijk in het belang van iedereen: de ontwikkelaars, de projectmanagers, de eindgebruikers, en niet in het minst de tester zelf, die niet anders wil dan perfecte kwaliteit afleveren binnen een deadline die ook effectief haalbaar is.
Waarom worden testers vaak te laat betrokken bij een project? Testen wordt in veel planningsprocessen nog gezien als een activiteit die pas start nadat de ontwikkeling is afgerond, in plaats van als een onderdeel dat van bij de analysefase meeloopt. Daardoor wordt de tijd die testen vraagt vaak onderschat of pas laat zichtbaar in de planning.
Wat is het gevolg van een te krappe testfase? Een te krappe testfase verhoogt het risico op onvolledige testdekking, opstapelende testschuld, overbelasting van het testteam en uiteindelijk kwaliteitsproblemen die pas na de livegang aan het licht komen.
Hoe kan een organisatie QA eerder betrekken bij de planning? Door testers al te laten meedenken tijdens de refinement- en analysefase, testinschattingen mee te nemen in de sprintplanning, en voldoende marge in te bouwen voor onvoorziene issues.
Wat is shift-left testing? Shift-left testing is een aanpak waarbij testactiviteiten zo vroeg mogelijk in het ontwikkelproces starten, in plaats van pas op het einde. Zo worden problemen sneller ontdekt, wanneer ze nog eenvoudiger en goedkoper op te lossen zijn.
Waarom is de inbreng van een tester waardevol bij het opstellen van een planning? Een tester heeft doorgaans een breed overzicht van hoe features en systemen met elkaar samenhangen, en kan daardoor beter inschatten welke scenario’s getest moeten worden en hoeveel tijd dat realistisch in beslag neemt.
Een deadline die geen rekening houdt met de realiteit van testen, is geen ambitieuze planning, het is uitstel met een omweg. De echte oplossing ligt niet in nog harder werken tegen een onmogelijke klok, maar in het structureel betrekken van QA vanaf de eerste planningsgesprekken. Wie de stem van de tester serieus neemt, bouwt niet alleen betere software, maar ook een planning die staat als een huis, en die, wanneer het erop aankomt, ook effectief wordt gehaald.
Wil je weten hoe ervaren testconsultants van M2Q kwaliteit en realistische planning helpen verankeren in jouw softwareprojecten? Neem contact op met M2Q en ontdek hoe wij organisaties zoals de jouwe helpen om testen niet als sluitpost, maar als volwaardige partner in de planning te behandelen.
