Tzal kort moeten, want zonet ontdekt dat me hier nog wat paperassen liggen aan te grijnzen.
Eigenlijk is het simpel.
Testen, zoals bijna alles, hoort een simpele cost/benefit proeve te doorstaan.
De (variabele) kost van testen is duidelijk: werkuren.
De opbrengst van testen? Reductie van risico. (Over dat risico kunnen we nog wel een paar boterhammen smeren, maar dat zal voor later zijn.)
Het probleem met testen? Er is nooit genoeg tijd om alles te testen.
Zodus... om te zorgen dat de benefit van testen effectief de cost overstijgt, kun je maar beter zorgen zo rap mogelijk zo veel mogelijk risico achter de rug te hebben.
Hoe? Alleszins niet door de simpelste dingen eerst te testen. Ook niet door de testen uit te voeren in de volgorde waarin ze in het leven zijn geroepen. Of alfabetisch. Of per categorie. Zelfs niet per se door de 'meest gebruikte' features te testen.
De enige vraag die er toe doet is: waar zit het grootste risico? Als je dat kunt bepalen, dan weet je waar je moet beginnen testen.
Boeiende ideeën in dezelfde lijn vind je in het artikel "The One-Hour Regression Test" in Better Software Magazine van Oktober 2008.
Nog drie praktische tips:
- Beperk jezelf in de tijd - maw. als je 5 tijdseenheden kunt testen, test dan zo dat je na één tijdseenheid al zo zeker mogelijk bent.
- Hou je eigen performance indexjes bij: na een uur, na twee uur,... schrijf op of je het zou aandurven dàn al te stoppen met testen - maw. je schat de kans dat er geen blocking bugs meer zullen opduiken hoger dan 90% of zo. Kijk achteraf of je gelijk had, en geef jezelf punten. En, telkens blijkt dat je na een uur gelijk had, trakteer jezelf een pintje ;-)
- Om te bepalen waar het grootste risico zit, denk aan Adam Smith. De onzichtbare hand. Eigenbelang. Watte? Simpel: stel jezelf de vraag welke features je je job zouden kunnen kosten als ze onopgemerkt blijven.
Hope that helps 8-)