Voor gestructureerd testen is gee n alternatief denkbaar

Mijlpalen in Pols carrière waren de ontwikkeling van de testmethode TMap (Test Management Approach) en de methode voor het verbeteren van het testproces TPI (Test Process Improvement). Over beide methoden verschenen boeken in diverse talen (Duits, Engels, Japans, Chinees). TMap zou volgens tellingen van Polteq inmiddels in meer dan vierhonderd organisaties wereldwijd worden toegepast. In 1997 richtte Pol de Nederlandse vereniging voor testers binnen de informatietechnologie, TestNet, op.

Pol ontwikkelde zijn testmethodiek begin jaren tachtig als projectleider bij de Belastingdienst. Eigenlijk in opdracht van de Tweede Kamer, die naar aanleiding van kritiek van de Algemene Rekenkamer een gestructureerdere aanpak eiste bij het testen van software bij de Belastingdienst. Pol: “In die tijd werd er over testen nauwelijks nagedacht. Iedereen moest voor zich het ‘testwiel uitvinden’. Bij technischere organisaties, zoals Philips Medical Systems, Fokker en het Waterloopkundig Lab was men nog het meest gevorderd in het denken over testen, maar hun aanpak was niet een-op-een te vertalen naar meer administratief georiënteerde informatiesystemen.” Uiteindelijk kwam Pol, onder meer op basis van bezoeken aan de IT-afdeling van de Amerikaanse marine, tot de kerninzichten van de aanpak die nu als TMap zo’n beetje de hele wereld overgaat:

• Testen voer je uit als aparte discipline, naast de ontwikkelaars.
• Testen doe je planmatig, op grond van bedrijfsdoelen en risicoanalyse.
• Testgevallen ontwikkel je op basis van de ontwerpspecificaties.

U haalde het fundament voor TMap dus op uit Amerika? Hoe kan het dan zijn dat u nadien toch ook in Amerika een veelgevraagd spreker werd?

“Bij de US Marine leerde ik wat testen moest inhouden, maar hoe je dat bedrijfsmatig kon aanpakken, hoe je testdoelen vertaalt in testgevallen en een plan van aanpak, dat was daar ook nog niet echt duidelijk. En dat is wat TMap beschrijft.”

Hoe staat het nu met de adoptie van TMap?

In het Nederlandse taalgebied is het de de facto standaard en ook elders in West-Europa en Scandinavië wordt het veel gebruikt. Er is ook eigenlijk geen alternatief. Het is net als met autorijden: je kunt het – behoudens details – eigenlijk maar op één manier goed doen, en die manier heb ik beschreven. Wel is er de laatste tijd een ontwikkeling gaande in de vorm van de International Software Testing Quality Board, waar zo’n veertig landen samenwerken aan één omvattende standaard van testen. TMap is daar zo’n beetje de basis van.”

Wat is – in het algemeen – de businesscase voor het invoeren van gestructureerd testen?

“Het principe dat voorkomen beter is dan genezen. Hoe later je een fout signaleert, des te groter zijn de gevolgen. Leken denken dan in de eerste plaats aan het vermijden van fouten die na de ingebruikname aan het licht treden. Terecht, want de imagoschade kan enorm zijn. Maar als testengineer richt je je op veel vroegere fasen in de systeemontwikkeling, waarbij het erom gaat herstelkosten en planningsoverschrijding zo te beperken. Dat naar voren halen van het moment waarop je fouten signaleert, gaat zelfs zover dat je in feite de specificaties ‘test’. Ik bedoel daarmee dat je als je op basis van de systeemspecificaties testcases probeert te ontwikkelen, regelmatig ontdekt dat dat niet lukt. Doordat de specs incompleet of intern tegenstrijdig zijn.”

Wat wordt de volgende uitdaging voor IT-testdiscipline?

“Contextgedreven-ketentesten. Eigenlijk moeten we naar een situatie waarbij bedrijven over een permanente testinfrastructuur beschikken, waarin je ad hoc webservices en sourcingcontracten kan aanbieden en laten testen op hun geschiktheid voor de functionaliteitsketen waarvan ze deel uit moeten maken.”