Menno Pot:    18-06-2024

Zoals eerder besproken in een blog op onze site, is Early Model Based Testing (eMBT) een vorm van shift left in testing.
Het mooie aan eMBT is wat mij betreft, dat je al heel snel kunt achterhalen welke requirements er mogelijk missen of niet correct zijn. Ik heb zelf vaak genoeg tijdens refinements gevraagd: “En wat moet het systeem doen in situatie X?” Waarna ik een antwoord kreeg zoals: “Goede vraag ja, nog niet over nagedacht.”
Als ik niet bij de refinements ben geweest, waardoor ik deze vraag pas stel tijdens het bouwen, dan ben ik vooral ook benieuwd: “Hoe heeft de developer dit dan gebouwd als het antwoord op deze vraag nog niet duidelijk is?”

Er zijn meerdere onderzoeken gedaan naar de root cause van issues in productie. O.a. Scopemaster heeft dit onderzocht en deconcludeerd dat 16,9% van de issues te herleiden is naar issues in de requirements. Verder verwijzen ze naar een onderzoek van Accenture die zelfs spreek over 35%.
Oftewel, als we zorgen dat alle requirements perfect zijn, kunnen we tot 17% of misschien zelfs to 35% van de bugs in productie voorkomen.
Productie bugs zijn, afgezien van de naamschade welke veel geld kost, erg duur om te repareren. Als je ze vindt tijdens het ontwikkelen, dan is de oplostijd korter en zijn dus de kosten al veel lager. En als je ze niet eens ontwikkelt omdat de requirements wel echt goed zijn, dan ben je alleen de kosten kwijt van het beter maken van de requirements. En die kosten zijn doorgaans nog vele malen lager.

Onze collega Silvio Cacace heeft zijn ervaring met, en liefde voor, eMBT gebruikt om TestCompass te ontwikkelen. Een tool die je helpt om de requirements te modelleren. Door dit modelleren, en daarmee het opzetten van de testen hiervoor, kom je doorgaans al tot een stel goede vragen. Middels deze vragen kunnen de requirements een heel stuk beter gemaakt worden, en voorkom je dus dat bepaalde issues überhaupt ontwikkeld worden.
Ik ben persoonlijk ook altijd voorstander van het INVEST principe, waarbij de T staat voor Testable. Als we een story niet kunnen testen, kunnen we ook niet aantonen dat hij goed is opgeleverd. En dan vraag ik me ook af of de V van Valuable wel gehaald wordt. Als je voor een story, middel eMBT, alle testen op orde hebt, dan is de story blijkbaar Testable. Mocht het niet goed lukken om eMBT toe te passen, dan is de story waarschijnlijk ook niet goed Testable, en goed mogelijk ook niet Valuable.
Zodra je het model in TestCompass helemaal gemaakt hebt, kan Testcompass alle gewenste testcases uitdraaien. Dit mede op basis van de gewenste dekkingsgraad. Dus door het model uit te schrijven/tekenen, werk je al gelijk toe naar een goede testset.

Wil je zien hoe TestCompass werkt en hoe je een userstory daarmee kunt testen, check dan deze video.

Happy testing, en op naar die 17% minder productie issues, of zelfs meer.