Testen is belangrijk

Daar is iedereen het wel over eens. Maar het kost tijd en moeite en dan blijken er bij het eerste gebruik toch nog fouten in de templates of (huisstijl)applicatie te zitten. Met alles wat daarbij hoort: ontevreden gebruikers, wachten op de oplossingen, opnieuw uitrollen. “De volgende keer moeten we beter testen” is dan een veelgehoorde uitspraak.

Maar kan dat wel? En is het de moeite waard, want testen kost tijd (en dus geld) wat wel terugverdiend moet worden. De komende blogs zal ik daarom ingaan op de manier om je testtraject zo efficiciënt mogelijk te organiseren, zodat je dubbel en overbodig werk vermijdt. En verder zal ik tips geven om je zogenaamde testcases (uitleg volgt) zo goed mogelijk te kiezen. Dat doe ik uitgaande van de situatie dat je een compleet Orange Pepper style systeem wilt testen, dus zowel templates als functionaliteit.

Voor een efficiënte aanpak is het belangrijk een goed beeld te hebben van wat testen nu eigenlijk precies inhoudt, zodat je rekening kunt houden met alle mogelijkheden en beperkingen. Daarom begin ik met het ontzenuwen van enkele wijdverspreide misvattingen over testen.

“Als alle testen lukken, hebben we een foutloos systeem”

Vergeet het maar! Als je een test uitvoert en je vindt een fout, dan weet je zeker dat er een fout in je systeem zit. Maar het omgekeerde is niet waar: als je geen fout vindt, wil dat niet zeggen dat er geen fouten meer in zitten. Je hebt ze alleen niet gevonden, bijvoorbeeld omdat een bepaalde situatie waarin een fout optreedt niet aan bod is geweest.

Met testen kun je WEL aantonen dat er een fout in je systeem zit, maar NIET dat er geen fouten inzitten.

“Als we maar genoeg zouden testen, zouden we een perfect systeem krijgen”

Met het bovenstaande in gedachten is het duidelijk dat je dus alle mogelijke situaties zou moeten testen om er zeker van te zijn dat er geen fouten meer in je systeem zitten. En dat is – praktisch gezien – onmogelijk, want er zijn te veel mogelijke situaties die voor kunnen komen.

Neem als voorbeeld dit scherm uit Orange Pepper style voor het invullen of wijzigen van de gegevens van een brief.  Wat je zou moeten testen:

• Het selecteren van een Company. Zie je alle bedrijven uit je Contactenlijst en kun je ze allemaal selecteren?
• Het selecteren van een Person. Zie je alle contactpersonen van het geselecteerde bedrijf (en dus ook geen enkele die daar niet bij hoort), kun je die allemaal selecteren en worden dan de juiste gegevens automatisch ingevuld in de velden bij To?
• Kun je handmatig de ingevulde waarden onder To wijzigen (in alle mogelijke combinaties, dus alleen Company, alleen Department alleen Attn enz, maar ook alleen waarden bij Company en Department, bij Company en Attn)?

• Worden handmatig ingevulde waarden weer overschreven als je een nieuwe selectie maakt bij Search in contacts?
• Wat gebeurt er als je hele lange teksten invult, of speciale lettertekens (ë, ô, enz.) gebruikt of letters invult in een veld waar alleen cijfers mogen staan?
• Kom je met de Tab-toets steeds in het volgende veld?
• Kun je het scherm sluiten zonder dat (tenminste) de verplichte velden zijn ingevuld?
• Enzovoort.

Dat zijn dus heel veel combinaties en zo’n scherm heb je bij elk documenttype. Maar dan ben je er nog lang niet, want bij elke combinatie moet je uiteraard testen of de ingevulde waarden op de juiste plaats in je document ingevuld worden en in de juiste opmaak.

Dat is niet te doen in de tijd die je beschikbaar hebt, dus je moet keuzes maken. Hiervoor zijn hele slimme tactieken en daar kom ik later op terug.

Tot slot: de kwaliteit van je systeem wordt niet bepaald door het testen, maar door te zorgen voor goede specificaties, een goed systeemontwerp en een goed ontwikkeltraject. Als je geen goede specificaties hebt, weet je niet of iets fout is of niet. En als je systeemontwerp of ontwikkeltraject niet deugt, kan elke wijziging nieuwe fouten introduceren. Dan blijf je dus eindeloos aan het testen.

De volgende keer ga ik in op testcases, de basis van het testen.