Reading time: 3 minutes
Author:
Vorige maand was een Engelse collega van me een paar dagen in Nederland. We hadden afgesproken in Café Americain. Onder het genot van een goede kop koffie wisselden we onze projectervaringen uit en vertelden we elkaar enthousiast over onze bezigheden. Als snel kwamen tot de kern: agile versus methodisch testen.
Praktische invullingen voor effectieve teststrategieën: het is een terugkerend thema. Als ik een testaanpak opstel volgens het boekje, dan voer ik een risicoanalyse uit en bepaal ik welke kwaliteitsattributen ik wil testen. Ik definieer testsoorten en ken misschien zelfs wel testontwerptechnieken toe aan de verschillende systeemonderdelen.
Common practice bij ons bedrijf is dat we een interactieve Prima-workshop houden. Het resultaat is een risicoanalyse die alle belanghebbenden betrekt en zorgt voor een collectief draagvlak voor die punten die belangrijk zijn om te testen. Maar werkt dit wel? Levert dit echt de resultaten op die we als tester najagen? Ik denk: vaak wel, maar zeker niet altijd.
Er zijn twee belangrijke bottlenecks. Zo moeten we de resultaten van de risicoworkshop wel vertalen naar testactiviteiten. Als we dit niet goed doen, snappen de belanghebbenden onvoldoende hoe de tests bijdragen aan het mitigeren van de risico’s die ze zelf hebben aangedragen. Daarnaast blijven de kwaliteitsattributen en functies voor de stakeholders vaak abstracte begrippen. ‘Ik wil dat het snel is’, heb ik een businessmanager ooit horen roepen. ‘Begin nou niet weer over query’s.’
Bij de tweede kop koffie raakten we op dreef. Zowel mijn collega als ik herkende de bovenstaande situatie, en we bedachten een meer gebruikersgerichte aanpak. Zou die beter werken? De requirements waren snel duidelijk: de strategie moet identificeerbaar zijn voor de stakeholders, passen binnen een agile context, de tester richting geven in wat hij moet testen, maar hem wel vrijheid geven zodat hij op basis van zijn test-, systeem- en domeinkennis zelf adequate tests kan opstellen.
We definieerden drie stappen. Stap 1: gebruikersanalyse. Ga na wie het systeem gebruiken. Definieer gebruikersprofielen. Maak deze samen met de business en creëer personages. De gebruikers opdelen in verschillende groepen zorgt voor inzicht en discussie en door de gebruikers te koppelen aan een fictief personage met representatieve eigenschappen zijn die eigenschappen ook te benoemen. Hiermee komen we echt op het terrein van de business, dus misschien is deze informatie daar reeds beschikbaar.
Stap 2: qualifiers. Organiseer een workshop om duidelijk te krijgen wat de te testen oplossing moet kunnen om het wow-effect op te wekken bij de gebruiker. Dit kun je bijvoorbeeld doen in een brainstorm, brown paper-sessie of door samen een mindmap te tekenen. In principe raakt dit het terrein van de businessanalisten, dus deze kunnen we hierbij uitnodigen. Misschien stellen ze dat alles al is verwerkt in het ontwerp. Toch geven dergelijke sessies veel inzicht bij de testers en de belanghebbenden. En vergeet niet dat er vaak voortschrijdend inzicht is. Ook als er geen ontwerp is, hebben deze sessies nut. Op basis van de geïdentificeerde qualifiers kunnen we de positieve of hygiënetests afleiden waarmee we kunnen testen of de applicatie doet wat die moet doen.
Stap 3: disqualifiers. Hierbij gaan we juist op zoek gaan naar de eigenschappen, omissies of fouten die leiden tot een negatieve ervaring. Deze informatie definieert de agressieve tests. Het is aan de tester om effectieve aanvallen te definiëren en zo te bewijzen dat de applicatie inderdaad geen negatief gedrag vertoont.
Deze stappen zijn op zeer verschillende wijzen in te vullen. Je zou interviews of werksessies kunnen houden met gebruikers of bijvoorbeeld projectmanagers of afdelingshoofden erbij betrekken. Wil je het proberen, google dan eens op de vergelijkbare Kano-analysetechniek.
De aanpak zet de tester op scherp, want uiteindelijk moet er natuurlijk gewoon grondig worden getest. Dat blijft. Maar, concludeerden mijn Engelse collega en ik bij de derde kop koffie, het gebeurt nu wel in een context die heel dicht aanligt tegen de beleving van de business.
