In 1992 werd ik enigszins onvrijwillig het testvak ingetrokken. Als eerste kreeg ik een verzameling testontwerptechnieken te leren, variërend van de syntactische test techniek tot de elementaire vergelijkingentest. In het testproject waar ik terecht kwam, werden diverse van deze technieken gebruikt, evenals in de projecten daarna. Ook in mijn verdere testcarrière heb ik de testontwerptechnieken altijd als basisgereedschap van testen beschouwd. In opleidingen voor testers en in certificeringsprogramma’s als ISTQB en TMap komen de technieken gelukkig ook ruimschoots aan bod.
Toch krijg ik, als ik ernaar vraag, in veel minder dan de helft van de gevallen te horen dat er technieken in een test gebruikt worden. Meestal weet men het niet goed, of is in het testplan een uitgebreide lijst mogelijke technieken genoemd, waarvan niemand weet of die ook gebruikt worden. Vreemd eigenlijk, dat we onze basisgereedschappen zo weinig gebruiken. De kracht van technieken staat voor mij als een paal boven water: met een gestructureerde en effectieve werkwijze de software controleren op de aanwezigheid van bepaalde typen fouten, als invulling van de gekozen teststrategie. Er zijn nog andere voordelen (beter beheersbaar testproces, automatiseerbaar, efficiënter), maar dit is het belangrijkste argument vóór technieken. Natuurlijk hoor ik ook allerlei argumenten om geen technieken te gebruiken. Ik ben het echter lang niet altijd met deze argumenten eens, vandaar dat ik van deze gelegenheid gebruik maak om gelijk een aantal tegenargumenten te geven. De argumenten zijn ruwweg in te delen in een aantal groepen:
Groep: Testsoort of testvorm ongeschikt
Argumenten:
Niet elke test leent zich voor gebruik van technieken.
1) Gebruikersacceptatietests waarbij gebruikers het systeem beproeven, moeten vrijheid aan de gebruiker geven.
2) De ontwikkelaar verzint voor unittests zijn eigen testgevallen, voor die zaken die hij belangrijk vindt om te testen.
3) Voor testen van diverse non-functionals (beheerbaarheid, beveiliging, onderhoudbaarheid) zijn vaak geen technieken beschikbaar.
Tegen-argumenten:
Dit kan inderdaad het geval zijn. Maar om op de drie punten te reageren:
1) Vrijheid van testen (~“error guessing”?) is zeker nuttig en moet niet aan banden worden gelegd door een techniek. Maar een GAT is meer dan enkel error guessing. Als er meerdere gebruikers zijn en/of meerdere geraakte bedrijfsprocessen is een techniek als de procescyclustest toch wel erg handig om te zorgen dat elk proces geraakt wordt en om te zorgen dat het werk makkelijker verdeeld kan worden.
2) De kwaliteit van unittests is de laatste jaren flink omhoog gegaan met praktijken als continuous integration en test driven development. Niettemin denk ik dat een ontwikkelaar betere programmatuur kan afleveren met meer kennis van testtechnieken. Overigens zonder dat de testgevallen van tevoren moeten worden uitgeschreven!
3) Met wat zoeken zijn er wel technieken te vinden (voor usability en security testen zelfs een hoop), maar ook iets simpels als een checklist te controleren aspecten is als een eenvoudige techniek aan te merken en is veel beter dan niets.
Groep: Testbasis
Argumenten:
De systeemdocumentatie is onvoldoende van kwaliteit (onvolledig, verouderd, erg “dun”) om technieken toe te passen.
Tegen-argument:
Er zijn diverse technieken die weinig (gedetailleerde) systeemdocumentatie nodig hebben. Voorbeelden: data flow test, pairwise testing, syntactische test.
Voor testen van pakketimplementaties zijn vaak procesbeschrijvingen aanwezig, hierop is de procescyclustest goed toepasbaar.
Groep: Onderhoudssituatie
Argumenten:
Onderhoudstesten doe je door de individuele wijzigingen te testen, aangevuld met een regressietest. Beide tests zijn niet geschikt om technieken op los te laten.
Tegen-argument:
Het hangt ervan af hoe de wijzigingen gedocumenteerd zijn. Normaal gesproken als apart wijzigingsvoorstel, hopelijk (maar niet vaak, helaas) ook in de vorm van een aangepast systeemontwerp. Dit argument hangt daarmee samen met voorgaande argument.
Groep: Exploratory testing (ET)
Argumenten:
Met ET kan de tester zich focussen op die onderdelen waar hij/zij de fouten vermoedt. ET is veel efficiënter omdat de tester een veel groter deel van de tijd bezig is tests uit te voeren.
Tegen-argument:
Hier worden twee zaken door elkaar gehaald. Bij ET vindt wel degelijk testontwerp plaats, zij het dat de tests niet van tevoren uitgeschreven worden. Testontwerp vindt plaats “tussen de oren”. Dit impliceert wel dat een exploratory test wordt uitgevoerd door een tester met goede kennis van de testontwerptechnieken.
Groep: Tester
Argumenten:
De kennis van technieken ontbreekt bij de testers. De rol tester wordt vaak ingevuld door (functioneel of applicatie) beheerders, eindgebruikers of ontwikkelaars. Testen is geen full-time job.
Tegen-argument:
Niet elke techniek is moeilijk. “In the blind” zomaar gaan testen is ook niet makkelijk, als je tenminste een goede test wilt uitvoeren. Er zijn meer dan voldoende opleidingen beschikbaar. Daarnaast helpt coaching en ondersteuning door een professionele tester.
Groep: Testmanager
Argumenten:
Eigenlijk hetzelfde argument als bij testers. Testmanagers zijn vaak afkomstig uit zij-instroom (is dat een woord?) vanuit andere disciplines, zijn hopelijk geschoold in testmanagement, maar niet in de basistools van de tester, want die kennis heb je niet nodig, toch?
Tegen-argument:
De testmanager moet zorgen dat de teststrategie die hij (met de stakeholders) bepaalt, ook ingevuld en uitgevoerd wordt. Daarvoor is kennis van testontwerptechnieken nodig in het team. De testmanager kan leunen op een (senior) professionele tester in het team, of kan deze kennis zelf hebben. Hoewel een testmanager niet hoeft te weten hoe elke techniek werkt, moet hij wel een goed beeld hebben van de mogelijkheden van en benodigde inspanning voor de technieken.
Groep: Kosten/baten
Argumenten:
Het is teveel werk tegen te weinig opbrengsten. Het genereert veel documentatie terwijl je in diezelfde tijd echte tests had kunnen uitvoeren.
Tegen-argumenten:
Hier worden opnieuw twee zaken door elkaar gehaald. Testontwerp kan ook met weinig documentatie. Zo kan ervoor gekozen worden om enkel de logische testgevallen te documenteren. Dit hangt bijvoorbeeld af van de kwaliteit van de testers.
Om dit stukje positief af te sluiten: ik zie gelukkig ook dat er in veel gevallen wel degelijk simpele technieken worden toegepast, echter zonder dat de tester zich er bewust van is. “Decision coverage, wat is dat? Ik test gewoon altijd beide uitkomsten van een vergelijking”. Toch blijf ik mij sterk maken voor meer en beter gebruik van ons basisgereedschap.
Tim Koomen, co-auteur van TMapNext en TPI, zelfstandig testconsultant
