De Kijk van Kees, simpel is het moeilijkst

Auteur: Kees Blokland ● kees.blokland@polteq.com

Compacte testplannen en to-the-point testrapporten schrijven is een vak apart. In dit stuk sta ik stil bij een aantal do’s and don’ts bij het samenstellen van testplannen en testrapporten.
Testplannen
Testplannen worden vaak geassocieerd met watervalprojecten. Dat is best begrijpelijk. Voor het maken van een goed testplan is tijd nodig, wat niet goed past in het snelle ritme van de sprints bij Agile projecten. Toch kan een testplan ook in zulke projecten nut hebben. Bijvoorbeeld voor het verbinden van de testactiviteiten over meerdere sprints heen en tussen meerdere teams die samen aan een release werken. Ik bedoel maar zo: verwijs dit verhaal niet meteen naar het land van waterval…
Binnen een organisatie werd geklaagd over de tijd die het samenstellen van testplannen kostte; ‘Kan het niet wat minder?’ was de vraag. Het plaatje hiernaast laat het resultaat zien van een testplan-onderzoek binnen die organisatie. De bladzijden van ieder testplan werden geteld en in de volgende categorieën geplaatst:

• bladzijden die vooral procedures en (vaak stabiele) organisatorische informatie bevatten;
• bladzijden die over het feitelijke testen gaan (teststrategie, etcetera).

Bladzijden met meta-informatie (voorpagina, inhoud, akkoord, wijzigingsbeheer, …) werden buiten de telling gehouden. Iedere stip is een testplan en testplannen van dezelfde kleur zijn van één afdeling.
De twee belangrijkste observaties zijn:

• de helft van de testplannen hadden meer dan 20 bladzijden inhoud (met een uitschieter naar meer dan 70…);
• de meerderheid van de testplannen bevat meer procedurele dan direct testgerichte inhoud.

Nu staat er nergens hoe dik of dun een testplan mag zijn. Ik zou ook niet willen aanbevelen om dit als metriek bij te houden, maar we (een gelegenheidsgroepje met ervaren vakgenoten) vonden wel dat binnen de context van deze organisatie je het verhaal kwijt moet kunnen in maximaal 20 bladzijden. Daarnaast vonden we dat de nadruk in het testplan op de testinhoud moest liggen. Testplannen die aan die condities voldoen, liggen binnen de witte driehoek in het plaatje. Een nadere analyse van de testplannen leverde de volgende ideeën op om in het vervolg compactere documenten te maken.

• Neem zo weinig mogelijk generieke tekst op. Tekst die in ieder testplan hetzelfde is en niet verandert met opvolgende projecten kan beter in een apart, generiek document worden opgenomen.
• Kopieer geen informatie één op één uit andere documenten. Verwijzen levert besparing op en voorkomt bovendien dat meerdere versies van dezelfde informatie ontstaan bij wijzigingen aan de bron.
• Voorkom kopiëren van informatie binnen een testplan. Een compactere opzet voorkomt dat.
• Focus op hoe het testen succesvol wordt. Dek niet in waarom testen niet volgens plan zou kunnen worden uitgevoerd, maar beschrijf wat gedaan wordt om tot een goed testresultaat te komen.
• Voorkom te veel detail. Face-to-face werkt overdracht van details beter en bovendien zijn ervaren testers prima in staat om de details zelf in te vullen.

(Zie voor lean documentation ook een eerdere Kijk van Kees).
Testrapporten
Een soortgelijk onderzoek op testrapporten leverde het volgende plaatje op, waarin voor de vergelijkbaarheid met het andere onderzoek dezelfde schaal en categorieën zijn gebruikt. De belangrijkste observaties waren:

• de helft bevatte geen kwantitatieve informatie (de gele speldjes);
• vrij veel bevatten onvoldoende concrete informatie;
• een aantal bevatte erg veel details.

Hier speelde niet zozeer het probleem van de omvang van de documenten, maar meer de praktische bijdrage van de inhoud ervan. Welke aanbevelingen zijn op basis van het onderzoek te maken?
Die vraag laat ik het liefst beantwoorden met behulp van een citaat uit de blogs van Michael Bolton. Ik heb een aantal weken met hem (bij een andere organisatie dan die van de onderzoekjes) mogen optrekken en heb daar zijn stories about test reporting leren kennen. In diverse blogposts (waaronder Braiding the stories) geeft hij aan welk verhaal in een testrapport hoort.
Hieronder een samenvatting van een citaat. Het is meer dan aan te bevelen om de volledige blog van Michael te lezen!
Level 1: Tell the product story. The product story is a qualitative report on how the product can work, how it fails, and how it might fail in ways that matter to our clients.
Level 2: To make the product story credible, tell the testing story. The testing story is about how we configured, operated, observed, and evaluated the product; what we actually did and what we actually saw.
Level 3: To make the testing story credible, tell a story about the quality of the testing. The quality-of-testing story includes details on what made testing harder or slower, what made the product more or less testable, what the risks and costs of testing are, and what we might need or recommend in order to provide better, more accurate, more timely information.
Tot slot
Kort en to-the-point schrijven vergt oefening. Ik hoop dat ik daar in deze post in ben geslaagd…