Blog
Context-driven testing is NIET nieuw
Geplaatst op 30/08/2013
Door: Gilbert Smulders, Consultant bij ViQiT
Eind oktober staat het TestNet najaarsevenement weer op de planning. Thema van dit evenement is “context-driven testing – a new hype or here to stay?”. Dat suggereert dat context-driven testing iets nieuws is. Maar als ik daar eens goed over nadenk, is dat onzin. Context-driven testing is helemaal niet nieuw. Goede testers hebben dit principe altijd al gehanteerd.
Voordat het Agile testen zijn intrede deed was er weinig contact met product-owners, key-users of andere business vertegenwoordigers. Jij moest als tester gewoon het functioneel ontwerp vergelijken met het test object. Niks meer en niks minder. Tegenwoordig noemt men dat verificatie en dat is toch anders dan validatie. Verificatie controleert of het systeem juist is gemaakt (zijn alle eisen verwerkt) en validatie controleert of het juiste systeem is gemaakt (doet het wat de klant wil). In de oude waterval projecten ging men er vanuit dat de eisen precies weergaven wat de klant wilde. Vanuit dat idee was het te billijken dat verificatie voldoende was om vast te stellen of het systeem was gemaakt zoals de klant dat wilde. Natuurlijk wisten we vanuit de praktijk dat de opgestelde eisen niet volledig aansloten bij de wens. Een goede tester hield hier al rekening mee.
In de waterval projecten waar ik in testte had ik ook regelmatig discussies met de opstellers van de testbasis. Zij namen in hun ontwerpen alleen maar op WAT er gebouwd moest worden. Ik wilde ook weten WAAROM er iets gebouwd moest worden. Wat is het probleem dat de business heeft waar men een oplossing voor wil? Daarbij was het niet mijn bedoeling om het ontwerp te valideren, wat sommige ontwerpers wel eens dachten. Als ik wist welk probleem opgelost moet worden kon ik namelijk beter inschatten waar ik mijn aandacht op moest leggen tijdens het testen. Dat hoefde niet per se het ingewikkeldste of grootste stuk functionaliteit te zijn. Dat kon wel eens een heel klein en eenvoudig stukje functionaliteit zijn waarmee het grootste probleem direct werd opgelost. Ook bij het beoordelen van de testresultaten en eventuele bevindingen kon ik dan een betere afweging maken. Resultaten die er voor zorgden dat het probleem van de business niet werd opgelost, moesten direct worden hersteld. Bevindingen die geen nadelige invloed hadden op de oplossing van het probleem konden best in een later stadium worden hersteld.
Met de intrede van Agile testen is het makkelijker geworden om die WAAROM vraag te stellen. Je zit als Agile tester namelijk met de business aan tafel tijdens het project. Zij kunnen je precies vertellen wat het probleem is dat moet worden opgelost. Zij kunnen direct aangeven waar je op moet letten tijdens het testen. Bovendien beoordelen zij tijdens het testen de resultaten en zorgen zij dat de juiste afwegingen gemaakt worden. Zodoende is aan het eind van het testtraject gevalideerd dat het systeem precies doet wat de klant wil.
Eigenlijk is dat dus niet heel anders dan wat ik vroeger ook al in mijn waterval projecten deed. Het is nu alleen een stuk makkelijker geworden. Om dan te stellen dat context-driven testing een nieuwe hype is, gaat toch echt te ver. Context-driven testing bestaat dus al heel lang. Het heeft nu alleen een officiële naam gekregen. Ik was dus eigenlijk de eerste context-driven tester in Nederland.