Binnen de testwereld van Nederland is TMap een veelgebruikte methodiek om te testen. TMap heeft als doel om het testen gestructureerder te laten plaatsvinden. Hiervoor biedt het middelen om het testen een plaats te geven in het software ontwikkel proces en daarnaast middelen om het testen op zich te verbeteren. Maar wat heb je nou aan TMap als je niet test? En kan TMap ook problemen geven? Om deze vragen te beantwoorden, zal ik twee basisprincipes van TMap bespreken, waar ik ook het effect voor developers zal noemen.

1. TMap is business driven
TMap wil het testen afstemmen op de risico’s bij de applicatie. Dit houdt in dat de meeste testtijd moet worden besteed aan die delen waarin de meeste kans is op fouten. Daarbij wordt wel rekening gehouden met de delen die voor de organisatie het belangrijkste zijn. Dit afstemmen op risico’s met behulp van de klant wordt bij TMap “business driven” genoemd.

Ik heb in de praktijk vaak gemerkt dat dit principe bij developers gemengde gevoelens oproept. Want wanneer voor het eerst op deze wijze wordt getest, worden er vaak in kortere tijd meer fouten gemeld dan ze gewend zijn. En dit vaak op een moment dat de deadline duidelijk dichterbij komt. Maar aan de andere kant ben ik nog nooit een developer tegengekomen die niet graag een applicatie oplevert met minder fouten.

2. TMap biedt een gestructureerd testproces
TMap verdeelt het testproces in verschillende fases. Tijdens het software ontwikkel proces zijn de volgende fases het meest opvallend: voorbereiding, specificatie en uitvoering.

Bij de fase voorbereiding wordt het materiaal waar de testers hun test op gaan baseren verzameld en beoordeeld. Meestal zijn dit de functionele en technische ontwerpen. Maar dit kan bijvoorbeeld ook een prototype zijn of de applicatie die op dit moment in gebruik is.

Op basis van dit materiaal wordt in de fase specificatie zo uitgebreid mogelijk vastleggen hoe er getest gaat worden. Dit wordt vastgelegd in een testscript. Hoe gedetailleerder het testscript, hoe meer er meestal getest kan worden in de volgende fase.

Zodra de bouw is afgerond, kan begonnen worden met de fase uitvoering. De test, zoals vastgelegd in de fase specificatie, wordt uitgevoerd.

Om deze fases zo goed mogelijk te doorlopen, heeft de tester zo veel mogelijk informatie nodig over wat er gebouwd gaat worden. Deze informatie moet bij voorkeur niet wijzigen. En als die wijzigt, moet de tester dit te weten komen. Dit zorgt vaak voor aanpassingen in of aanvullingen op functionele ontwerpen, omdat de informatie niet voldoende is of met elkaar in tegenspraak is. Maar daarnaast moeten developers de testers tijdens de bouwfase op de hoogte houden van wijzigingen in de functionaliteit. Want een tester moet zijn testscript misschien aanpassen. Bij de positieve insteek streef je zo samen naar betere ontwerp-documenten. Bij een negatieve insteek is een tester een veeleisende lastpost op momenten dat je geen tijd hebt.

Ten slotte
TMap is een flexibele methodiek. Juist deze methodiek is uitstekend geschikt om aan te passen aan de praktijk van het bedrijf waar je werkt. Of TMap voordelen of nadelen oplevert hangt daarom vooral af hoe het toegepast wordt en hoe je ertegenaan kijkt. Maar het kan ook voor een developer wel degelijk voordelen bieden.

Voor meer informatie:
Officiele TMap website
Wikipedia samenvatting van TMap