Blog

Elke sprint opnieuw dezelfde regressietesten handmatig uitvoeren. Het is niet alleen saai, het is ook risicovol. Terwijl jij die 47e testcase doorklikt, vraag je je

Je zit in de refinement. Een nieuwe story wordt uitgelegd. Iedereen knikt. Jij ook, maar ondertussen draait er van alles in je hoofd. Wat als

Stel je dit voor: je team heeft weken aan een nieuwe functionaliteit gewerkt. De load test draait, en de response time ziet er prima uit,

Je kent het vast: wekenlang getest, alles staat op groen, en dan… Je hebt alles getest. De load test draait perfect: 10.000 gelijktijdige gebruikers, responstijden

Het is maandagochtend, 9:15 uur. Je opent Slack en ziet alweer die gevreesde melding: “Test omgeving X is down, kan iemand kijken?” Drie teams staan

Je sprint review nadert. De demo gaat prima, stakeholders knikken goedkeurend. Dan vraagt de product owner: “Wanneer kunnen we UAT doen?” Stilte. De sprint is

Je hebt weken geïnvesteerd in uitgebreide performance tests. De resultaten zijn binnen, de bottlenecks geïdentificeerd. Maar dan komt de echte uitdaging: hoe presenteer je deze

Vrijdagmiddag, 16:00. De release staat gepland voor 17:00. En dan vraagt iemand: “Hebben we de regressietests al gedraaid?” Stilte. “Die duren 8 uur,” zegt de

Vrijdagochtend. Release staat gepland om 14:00. Het team draait de testsuite, maar na twee uur wachten staat de pipeline nog steeds op oranje. Uiteindelijk komt

Baseline testing en benchmark testing worden vaak door elkaar gehaald, maar hebben verschillende doelen en toepassingen. Baseline testing legt een intern referentiepunt vast om prestaties