Testen en toetsen, het zijn binnen de testwereld op dit moment veelgebruikte woorden. Toetsen kan iedereen en is letterlijk de eisen controleren. Maar bij testen gebruik je je eigen kennis en vaardigheden om meer te controleren, dan in de eisen vermeld staat. Zo ongeveer heb ik het altijd begrepen. De afgelopen weken kwam ik echter tot een ander kennisinzicht.
Hoe goed geschreven, een story zijn woorden. Het zijn geformuleerde zinnen, die meestal vrij letterlijk te controleren zijn. Daarmee wordt een story een checklist, die je afvinkt. Wat is in de story gebouwd en wat niet.
Een story probeert te omschrijven wat een klant wil, maar doet het vaak niet. Hoewel officieel bij zowel Scrum als Agile een directe communicatie met de klant wordt gepromoot, zijn er heel veel Scrum en Agile teams, die de klant bijna nooit spreken. Een story is te vaak een vertaling van een vertaling van een vertaling van de wens van de klant. Daarnaast is de klant vaak geen ervaren wensschrijver. Werkelijk stilstaan bij alle schermen, instellingen en invoervarianten kan je vaak niet van een klant vragen. Stilstaan bij alles wat met kwaliteit te maken heeft: foutafhandeling, leerbaarheid, consistentie, performance, enz. al helemaal niet.
Wat de klant wil is dan ook niet te vatten in een kort tekstje. Zelfs heel moeilijk in een document van 5 pagina's. Om te weten wat de klant wil, moet je weten hoe de klant nu met je applicatie werkt. En omdat dat vaak moeilijk is te achterhalen, moet je minimaal kennis hebben van de applicatie. Hoe werkt de functionaliteit nu? Wat is het gevolg van de wijziging op de huidige functionaliteit? Wat is het gevolg van de wijziging op vervolgstappen? Maar ook standaard vragen als: wat zijn de verplichte gegevens, wat is de foutafhandeling, welke gegevens worden gebruikt in vervolgstappen? Niet elke vraag is bij elke stap even belangrijk. Maar elke vraag is altijd voor de klant belangrijk, omdat het voldoende beantwoorden van deze vragen de applicatie werkbaar en betrouwbaar houdt. Als een klant vraagt om een wijziging, maar deze wijziging zou verkeerde bedragen op facturen opleveren, wil de klant de wijziging niet. Als een klant vraagt om een wijziging op scherm 1, maar scherm 2 kan hetzelfde en wordt ook veelgebruikt, wil de klant ook de wijziging op scherm 2. Als de klant vraagt om bij het adres straat en huisnummer op te slaan, wil hij ook postcode en plaats. Meestal tenminste.
Waar het als tester om gaat, is dat je niet blind geloofd dat als het niet in de story staat, de klant het ook niet wil. En dat als wat in de story staat de werking van de applicatie slechter maakt, de klant dat toch wil. Een klant wil een goed werkende, betrouwbare applicatie. Een goede tester probeert hiervoor te zorgen. Soms ondanks de beschreven story's, soms zelfs tegen de beschreven story's in. En dat is testen!
Geen opmerkingen:
Een reactie posten
Opmerking: Alleen leden van deze blog kunnen een reactie posten.