Je zit in een sprint review. De product owner zucht. “Die bug had eerder gevonden moeten worden.” Je weet dat hij gelijk heeft. De feature werkte perfect in dev, maar in productie crashte hij meteen.
Drie dagen werk. Naar de prullenbak.
Dit scenario ken je waarschijnlijk. En als iemand dan roept “we moeten meer shift left doen!” knik je beleefd. Maar wat betekent dat eigenlijk? En nog belangrijker: hoe doe je het zonder je hele proces om te gooien?
Shift left in één zin (zonder de buzzwords)
Shift left betekent simpelweg: begin eerder met nadenken over kwaliteit.
Niet aan het eind, als de code al af is. Maar vanaf het begin, als je nog aan het praten bent over wat je gaat bouwen.
Stel je een tijdlijn voor van links naar rechts:
Requirements → Design → Code → Test → Deploy
De oude manier? Testing zit helemaal rechts. Pas als alles af is, ga je testen. En dan ontdek je dat de requirements onduidelijk waren. Of dat de architectuur niet testbaar is. Of dat niemand had nagedacht over wat er gebeurt als de database vol is.
Shift left betekent: schuif dat testdenken naar links. Naar het begin.
Waarom vroeger testen zoveel uitmaakt
Hier is iets dat we regelmatig zien bij teams. Een bug wordt gevonden in productie. Grote paniek. Hotfix. Stress. Achteraf blijkt het een miscommunicatie te zijn over een requirement. Iets dat in vijf minuten opgelost had kunnen worden. In de requirements fase.
Nu kostte het drie dagen. Plus de stress. Plus het vertrouwen van de klant.
Dit heeft een naam: de kromme van Boehm. IBM deed hier onderzoek naar. Hun conclusie? Simpel. Een bug in productie kost gemiddeld honderd keer zoveel als diezelfde bug in de requirements fase.
Honderd keer.
Dat is het verschil tussen “even de spec aanpassen” en “code herschrijven, opnieuw testen, deployen, excuses maken aan de klant, en hopen dat er geen andere bugs zijn binnengeslopen.”
Maar het gaat niet alleen om geld. Het gaat ook om frustratie. Developers die dezelfde bug drie keer moeten fixen omdat niemand het probleem écht begreep. Testers die zich afvragen waarom ze pas om input worden gevraagd als alles al gebouwd is. Product owners die niet begrijpen waarom “simpele” features zo lang duren.
Shift left lost dat op. Niet door meer te testen, maar door eerder de juiste vragen te stellen.
Klinkt logisch, maar hoe doe je dat concreet?
Hoe ziet shift left er in de praktijk uit?
Hier zijn vijf manieren die we teams succesvol hebben zien toepassen. Niet allemaal tegelijk – dat werkt niet. Maar begin met één, en bouw van daaruit.
Begin bij de acceptance criteria
Dit is waar we teams vaak mee laten starten. Omdat het weinig kost en veel oplevert.
De oude manier: een user story zegt “Als gebruiker wil ik kunnen inloggen zodat ik mijn account kan beheren.” Duidelijk, toch? Tot de developer vraagt: “Wat als iemand drie keer verkeerd inlogt? Blokkeren we het account? Hoe lang? Krijgt de gebruiker een melding?”
Niemand weet het. Dus de developer maakt een keuze. Die blijkt later verkeerd. En de bug wordt gevonden in productie.
De shift left manier: voordat je begint met bouwen, schrijf je testbare acceptance criteria. Samen met de tester én de product owner.
“Gegeven een gebruiker met een geldig account, wanneer hij correct inlogt, dan wordt hij binnen 2 seconden doorgestuurd naar het dashboard.”
“Gegeven een gebruiker die drie keer verkeerd inlogt, wanneer hij het vierde keer probeert, dan wordt zijn account 15 minuten geblokkeerd en krijgt hij een e-mail met uitleg.”
Nu is het duidelijk. De developer weet wat hij moet bouwen. De tester weet wat hij moet testen. En de product owner weet wat hij krijgt.
Tot zover acceptance criteria. Nu iets anders.
Developers schrijven tests
Dit voelt voor sommige teams als een grote stap. “Developers testen? Is dat niet de taak van testers?”
Ja en nee.
Testers zijn geweldig in het vinden van edge cases, het denken als een gebruiker, het doorbreken van systemen. Dat wil je niet verliezen.
Maar unit tests? Die horen bij de code. Als een developer code schrijft, schrijft hij ook de tests die bewijzen dat de code werkt. Dat is geen extra werk. Dat ís het werk.
Je zou denken dat dit meer werk is, maar eigenlijk voorkomt het gedoe later. Want nu vindt de developer zijn eigen bugs op het moment zelf, in plaats van drie dagen later als een tester door de feature heen loopt.
We kennen teams die dit invoerden. In het begin klaagden developers. “Kost te veel tijd.” Drie maanden later wilden ze niet meer terug. Hun bug count was gehalveerd, en ze hoefden veel minder code te herschrijven.
De volgende stap is minder voor de hand liggend.
Zet testers bij design meetings
Dit klinkt misschien als een klein detail, maar het effect is groot. Want in veel teams worden testers pas betrokken als de feature af is. “Hier, test dit even.” Alsof testen een stempel is dat je achteraf op iets drukt.
Maar testers denken anders dan developers. Ze zien risico’s. Edge cases. Scenario’s waar niemand aan dacht. “Wat als twee gebruikers tegelijk dezelfde order willen wijzigen?” “Wat als de externe API down is?” “Wat als iemand zijn browser halverwege sluit?”
Als je een tester bij een design meeting zet, komen deze vragen op tafel voordat er een regel code is geschreven. Scheelt je niet alleen uren. Het levert ook betere software op.
Laat je pipeline het zware werk doen
Nu wordt het even technisch. Dit is waar CI/CD testen om de hoek komt kijken.
Als een developer code commit, kan er automatisch van alles gebeuren. Tests draaien. Code quality checks. Security scans. En als iets faalt? De commit wordt geblokkeerd.
Streng? Misschien. Maar het zorgt er wel voor dat bugs nooit verder komen dan de developer’s machine. Direct gevangen. Direct opgelost. Geen tickets, geen escalaties, geen “dit moet met spoed naar productie.”
Het opzetten kost tijd. Maar daarna? Rust.
TDD als experiment (niet als verplichting)
Test Driven Development betekent: eerst de test schrijven, dan de code.
Dat went even, want je schrijft een test voor code die nog niet bestaat. De test faalt natuurlijk. En dan schrijf je precies genoeg code om de test te laten slagen.
Niet iedereen vindt dit prettig. Sommige developers ervaren het als bevrijdend, anderen als frustrerend. En dat is prima.
Een goede aanpak: bied het aan als optie. Laat mensen experimenteren. Wie het prettig vindt, blijft het gebruiken. Wie niet, hoeft niet.
Wat shift left niet betekent
Er zijn een paar misverstanden die we regelmatig tegenkomen.
“Shift left betekent dat we geen testers meer nodig hebben.”
Nee. Het betekent dat de rol van testers verandert. Van iemand die bugs vindt, naar iemand die bugs voorkomt. Van executor naar coach. Van gatekeeper naar enabler.
Testers worden niet overbodig. Ze worden belangrijker. Ze helpen developers beter testen. Ze focussen op de complexe dingen die automatisering niet kan. Ze denken mee over strategie.
“Shift left betekent dat alles geautomatiseerd moet worden.”
Ook niet. Sommige tests automatiseer je. Unit tests, integratie tests, regressie tests. Maar exploratory testing? Usability testing? Dat blijft mensenwerk. Shift left gaat niet over automatisering. Het gaat over timing.
“Shift left is iets dat je in een week implementeert.”
Dit is misschien het grootste misverstand. Shift left is geen tool die je installeert. Het is een cultuurverandering. Developers moeten ownership voelen over kwaliteit. Testers moeten loslaten dat zij de enige bewakers van kwaliteit zijn. Product owners moeten tijd vrijmaken voor goede acceptance criteria.
Dat kost tijd. Maanden, niet weken.
De valkuilen (en hoe je ze vermijdt)
We zien soms teams worstelen met shift left. Niet omdat het concept niet werkt, maar omdat de uitvoering mis ging. Dit zijn de dingen waar je op wilt letten.
Alles tegelijk willen veranderen. TDD invoeren én CI/CD opzetten én testers bij design meetings én acceptance criteria herschrijven. Tegelijk. Dat werkt niet. Teams raken overweldigd. Begin met één ding. Acceptance criteria bijvoorbeeld. Doe dat drie maanden. Dan het volgende.
Metrics als doel zien. “We moeten 80% test coverage halen!” En dan schrijven developers tests die technisch dekking geven maar niets testen. Coverage is een indicator, geen doel. Focus op het vinden van bugs vroeg, niet op het halen van een percentage.
Vergeten dat het een andere manier van denken is. Je kunt tools invoeren. Je kunt processen veranderen. Maar als developers nog steeds denken “testen is niet mijn probleem,” verandert er niets. Investeer in mindset, niet alleen in tooling.
Testers niet meenemen. Sommige testers voelen zich bedreigd door shift left. “Word ik overbodig?” Communiceer duidelijk dat hun rol verandert, niet verdwijnt. Investeer in hun ontwikkeling. Help ze automatisering leren. Coach zijn. Strategie ontwikkelen.
Hoe je morgen kunt beginnen
Je hoeft niet alles tegelijk te doen. Hier is een realistisch pad.
Deze week: pak je volgende user story. Voordat iemand begint met bouwen, schrijf testbare acceptance criteria. Met de product owner én de tester erbij. Kijk wat het oplevert.
Volgende maand: maak van “tests geschreven” onderdeel van je definition of done. Developers committen geen code zonder unit tests. Begin met nieuwe code, niet met legacy.
Over drie maanden: zet een CI/CD pipeline op die automatisch tests draait. Als tests falen, wordt de commit geblokkeerd. Het team went aan snelle feedback.
Over zes maanden: evalueer. Wat werkt? Wat niet? Waar zit weerstand? Pas aan. Shift left is geen eindbestemming, het is een richting.
Het complete plaatje
Shift left gaat over het voorkomen van problemen. Maar je kunt niet alles voorkomen. Sommige bugs ontdek je pas in productie, als echte gebruikers echte dingen doen.
Daarom bestaat ook “shift right.” Monitoring. Observability. Feature flags. A/B testing. Leren van wat er in productie gebeurt.
Een volwassen teststrategie doet beide. Shift left om bugs vroeg te vangen. Shift right om te leren van de praktijk.
Tot slot
Shift left is geen raketwetenschap. Het komt eigenlijk neer op één ding: begin eerder met nadenken over kwaliteit. Stel de juiste vragen voordat je begint met bouwen, laat developers verantwoordelijkheid nemen voor hun code, en betrek testers bij het denken – niet alleen bij het uitvoeren.
Ja, het kost tijd om te implementeren en het vraagt om een cultuurverandering. Maar de resultaten zijn het meer dan waard: minder bugs in productie, minder stress, minder rework, en meer vertrouwen in wat je oplevert.
Dus begin gewoon klein. Start met goede acceptance criteria, kijk wat je deze week nog kunt doen, en bouw van daaruit verder.
- Meer lezen over Shift left testing?
https://en.wikipedia.org/wiki/Shift-left_testing
