De zin van ongestructureerd testen

Auteur: Rik Marselis ● Rik@Marselis.eu ● @rikmarselis

Redactie: Eric Spaargaren

Stel je voor dat je tester bent voor een systeem waarvan je al weet dat de kwaliteit heel belabberd is. En jij moet een oordeel geven over de kwaliteit en de kans dat het business value gaat opleveren. Dan is het heel makkelijk. Als ervaren tester probeer je eens wat en hop, daar heb je een bevinding. Je probeert wat anders en ploef, weer iets dat niet werkt. Daarna druk je eens een knop in de categorie ’dit zal toch echt wel werken, toch?’ en nee helaas, alweer een fout gevonden.

Voor je het weet, heb je al genoeg voorbeelden verzameld om te onderbouwen dat de kwaliteit ver beneden de maat is. In dit geval is ongestructureerd testen simpelweg de meest efficiënte aanpak. Waarom zou je tests voorbereiden als je zonder voorbereiding ook al genoeg informatie kunt verzamelen?

Kortom, ongestructureerd testen kan af en toe een goede keuze zijn. Mensen die mij een beetje kennen voelen echter de ‘maar’ al aankomen…Het komt gelukkig niet (meer) zo heel vaak voor dat IT-systemen zo slecht zijn dat alleen wat ongestructureerd testen genoeg is om je kwaliteitsoordeel te onderbouwen. Daarnaast weet je meestal niet vooraf dat de kwaliteit zo slecht is dat voorbereiding zonde van de tijd is.

Want neem nu eens het andere uiterste. Het systeem dat je mag testen is perfect. En jij gaat ongestructureerd testen. Je probeert eens ‘dit’ en het werkt. Je probeert eens ‘dat’ en het werkt ook prima. Je doet nog eens ‘zus’ en ‘zo’ en alles dat je probeert gaat goed. Na een middagje ongestructureerd (en ongedocumenteerd) testen heb je een probleem. Want is het systeem nu echt zo geweldig? (hoe vaak hebben we dat gezien?) Of ben je toch niet zo’n goede tester als je altijd dacht? (een goede tester vindt veel bevindingen, toch!?)

Gelijk maar even door met die laatste bewering: een goede tester vindt veel bevindingen… Hier ben ik het pertinent mee oneens. Een goede tester bereidt zich voor en doet de juiste experimenten om de kwaliteit van het testobject te onderzoeken. En een goed voorbereide test zal in geval van onvoldoende kwaliteit best wel de nodige bevindingen opleveren. Maar het aantal bevindingen zegt niets over de kwaliteit van de tester. En zeg nou zelf, als tester word je toch eigenlijk helemaal niet gelukkig van veel bevindingen? Eerder word je bedroeft dat IT niet aan de verwachtingen heeft kunnen voldoen en voel je plaatsvervangende schaamte voor de vakgenoten die het in elkaar geprutst hebben.

Tegenwoordig zijn steeds meer testers onderdeel van een cross-functional team. Zo’n team heeft als doel om samen de IT te leveren die voor de organisatie business value oplevert. Dus de juiste kwaliteit op het juiste moment. En dan ga je als tester niet aan het eind nog even kijken of het wel werkt. Nee, als tester (ik noem het tegenwoordig liever quality engineer) help je het hele team met de juiste kwaliteitsfocus zodat kwaliteit vanaf het begin wordt ingebouwd. En parallel zorgt het team er samen voor dat er op een gestructureerde manier testen worden voorbereid die tijdens het hele proces de informatie opleveren waarmee de stakeholders kunnen bepalen of ze genoeg vertrouwen hebben dat het systeem werkelijk business value oplevert.

Voor de duidelijkheid: bij mij valt Exploratory Testing onder ‘gestructureerd testen’. Als je vooraf charters met timeboxes voorbereidt en achteraf netjes vastlegt wat er getest is, dan heb je een keurig gestructureerde manier om te vertellen wat de conclusie is met betrekking tot kwaliteit, risico’s en de business value.

Dus: als je zeker weet dat de kwaliteit van je systeem slecht is, doe dan gerust iets ongestructureerds als Error Guessing (waarvan Glenford Myers in 1979 al schreef ‘it is largely an intuitive and ad hoc process’ ), maar in alle andere gevallen zorg alsjeblieft voor structuur in het kwaliteitswerk.

Veel succes en plezier met quality engineering!