Testspecificatietechnieken helpen bij slimmer testen (Tom Langerhorst)

Testspecificatietechnieken helpen bij slimmer testen

Laatst had ik een overleg met een Testmanager van een van mijn voorgaande projecten. Ik vroeg hem naar zijn mening over de toegevoegde waarde van testspecificatietechnieken binnen moderne ontwikkelmethoden als Agile, Scrum of DevOps. Waarop ik van hem een wedervraag kreeg, wat mijn mening was op het onderwerp.

In mijn visie zijn testspecificatietechnieken nog steeds noodzakelijk, niet om heel dikke testontwerpen te schrijven, die niemand leest noch uitvoert. Maar meer als vorm van risicobeheersing, waar een risicoanalyse aangeeft waar risico gelopen wordt en er dus diepgaander getest moet worden. En andersom geldt eigenlijk hetzelfde. Daar waar minder of geen risico gelopen wordt, moet je dus minder diepgaand testen.
risico_matrix
Maar hoe doe je dat dan?
Iedere tester weet dat de beslissingstabellentesttechniek een zware en diepgaande testtechniek is, waarbij alle mogelijke samenstellingen van beslispunten geraakt worden. Dit is dus een testtechniek die je kunt positioneren in het hoge schade-hoge kans kwadrant van de risicomatrix (Het paarse vak in het plaatje hiernaast).

Een testtechniek die daar ook past is de elementaire vergelijkingentest, een testtechniek die daar minder past is de error-guessingtechniek. Deze past meer in het lage risico kwadrant (het groene vak in het plaatje hiernaast).

Natuurlijk zou je door te variëren met diepgang, vereenvoudiging, testmaat, etc. met een testspecificatietechniek alle kwadranten van de risicomatrix af kunnen dekken. Maar ten eerste ga je dan voorbij aan de gedachte van testen gebaseerd op risico en ten tweede mis je dan de variatie aan testspecificatietechnieken, waardoor je vanzelf al de spreiding aan testgevallen krijgt die je wilt en hoopt te verkrijgen. Elke testspecificatietechniek heeft immers zijn eigen kracht, waarmee ander gedrag van een systeem wordt aangetoond.

Bij nieuwe ontwikkelmethoden gaat het niet meer om het volledig en goed doortesten van alle mogelijke combinaties door het hele informatiesysteem heen, daar is immers de tijd niet meer voor. Nee, het gaat er veel meer om een werkend product op te leveren binnen de gestelde tijdframes. Je zult dus slimmer moeten testen en testspecificatietechnieken kunnen je daarbij helpen. Ze kunnen helpen inzicht te geven in mainstream testgevallen en exotische testgevallen en alle schakeringen daar tussenin. Dat is de reden dat ik het jammer vind, dat testspecificatietechnieken onder het mom van tijdsdruk en de afwezigheid van enige vorm van testbasis in diskrediet zijn geraakt. Het kost namelijk niet eens zoveel tijd om een testtechniek snel uit te werken en dat kan zelfs gebeuren op basis van een interview dat je houdt met de product- owner.

Mijn oproep aan alle testprofessionals in Nederland en daar ver buiten is dan ook: geef niet toe aan de druk van het project om Error Guessen te verkopen als Exploratory Testing. Met andere woorden maar wat rond te klikken in de applicatie. Pas te allen tijde waar zinvol testspecificatietechnieken toe, ze bestaan, dus gebruik ze. Het helpt je inzichtelijk te maken wat de belangrijke aspecten zijn van een systeem, het helpt je bij het beschrijven van het gedrag van het systeem en – last but not least – het helpt je zelfs bij het invullen van de op risico’s gebaseerde teststrategie. Daarmee kun je onderbouwen waarom je het één test met specificatietechniek A en het ander met testspecificatietechniek B.

Tom Langerhorst, juli 2016