Testen zonder testgevallen

Image

Door: Ed Hilkman

In mijn vorige blog ‘Waarom het testen van software beter moet‘ schreef ik over de voornaamste bottlenecks die ik in de praktijk ervaar met testgevallen. In dit blog licht ik een aanpak toe waarmee deze problematiek opgelost kan worden.

Om het geheugen wat op te frissen heb ik de bottlenecks nog een keer op een rijtje gezet:

  1. Testsnelheid neemt af;
  2. Niet overdraagbaar, niet onderhoudbaar, onvoldoende dekking;
  3. Pesticide paradox.

De bottlenecks worden veroorzaakt door de wijze waarop testgevallen in de praktijk tot stand komen. Om deze problematiek het hoofd te bieden, dient er op een geheel andere wijze naar testgevallen te worden gekeken. Een aanpak die hierbij kan helpen is het genereren van testgevallen op basis van een model: Model Based Testing (MBT).

Geen testgevallen meer, maar een model

Testgevallen beschrijven het gewenste gedrag van een System Under Test (SUT) onder bepaalde condities. Een testset die de zoekfunctionaliteit in een webshop afdekt bevat bijvoorbeeld de volgende testgevallen:

  • Op startscherm: vul een bestaande artikelnaam in, klik op zoeken, zoekresultaten worden getoond;
  • Op startscherm: vul een niet bestaande artikelnaam in, klik op zoeken, een foutmelding wordt getoond.

In MBT leggen we dit gedrag vast in een model. Vaak is dit model een eindigetoestandsautomaat. Bijgaand schema is een voorbeeld van zo’n automaat. Hierin corresponderen toestanden (de blokjes) met observeerbaar gedrag in de SUT en komen transities (de pijltjes) overeen met gebruikersinteracties.

Image

Een testset bevat veel redundantie (zie mijn vorige blog). Bij elke functionele wijziging, uitbreiding, etc. moet de tester bepalen op welke testgevallen dit impact heeft en welke testgevallen aanpassing behoeven. Redundantie kost dus tijd. Een model bevat per definitie geen redundantie. Daardoor is het goed te onderhouden en reviewen. Dit komt niet alleen de overdraagbaarheid en onderhoudbaarheid ten goede die ik in bottleneck 2 heb benoemd, ook lost het bottleneck 1 op. Het model behoeft namelijk maar op één plaats gewijzigd te worden. De modelgedreven aanpak is daarmee vergelijkbaar met hoe ontwikkelaars werken. De testers kunnen dus het tempo van de ontwikkelaars bijhouden!

Vanwege de overzichtelijkheid van een model, ontstaat ook duidelijk inzicht in de dekkingsgraad waar ook de business over mee kan praten! Wordt de dekkingsgraad bijvoorbeeld te laag bevonden, dan kan het model eenvoudig worden aangevuld tot de dekkingsgraad wél voldoet. Hiermee verandert het aspect ‘onvoldoende dekking’ in bottleneck 2 in een gecontroleerde dekking.

De structurering die ontstaat met modellen in plaats van testgevallen, zie je ook terug in de rapportages. Requirements zijn meestal te relateren aan een toestand of transitie. Na het uitvoeren van een test zorgt de MBT tool voor rapportages waarin staat hoe vaak en in welke volgorde transities en toestanden doorlopen zijn. Daarmee wordt per testrun de vraag aan welke requirements de applicatie voldoet automatisch beantwoord, wat een aanvulling is op het dekkingsaspect van bottleneck 2.

Geen testtechnieken meer, maar een algoritme

MBT tooling kent geen testtechnieken, maar werkt met algoritmen om de paden in een model te bepalen. Een model verandert niet als gekozen wordt voor een ander algoritme, het heeft alleen gevolgen voor de paden die doorlopen worden (of in traditionele termen: er worden andere tests uitgevoerd). Elk algoritme heeft bepaalde kenmerken. Een tweetal voorbeelden van mogelijke algoritmen licht dit nader toe:

  • De MBT tool genereert een minimale test waarbij alle toestanden en alle transities ten minste één keer worden geraakt. De dekking is dus maximaal bij een minimale testtijd. De variatie tussen de verschillende testruns is echter beperkt;
  • De MBT tool bepaalt random per toestand welke transitie uitgevoerd en/of welk pad gevolgd wordt. Er is dus een grote variëteit tussen de verschillende testruns. Dit algoritme heeft echter meer executietijd nodig om het gehele model te doorlopen.

Afhankelijk van het algoritme wordt er meer of minder variatie in de test aangebracht. De keuze voor een algoritme bepaalt dus in welke mate de pesticide paradox van bottleneck 3 wordt opgelost.

Een groot voordeel is dat de algoritmes samen met stakeholders van de business bepaald kunnen worden, waardoor men niet meer afhankelijk is van ongedocumenteerde inzichten van een individuele tester. Sterker nog. Je kunt experimenteren met verschillende algoritmen, of zelfs verschillende algoritmen naast elkaar laten bestaan! Bijvoorbeeld door overdag een snelle test per build uit te voeren en ‘s nacht een uitgebreide test. Nog een oplossing voor bottlenecks 1 en 3!

Conclusie

Met de ervaring die ik heb opgedaan, durf ik te stellen dat Model Based Testing de hardnekkige bottlenecks met testgevallen voor procesgestuurde front-end applicaties voor eens en voor altijd oplost.

In mijn volgende blog laat ik aan de hand van een eenvoudig voorbeeld zien hoe dit in de praktijk werkt.

Delen:

Ed Hilkman

Ed Hilkman is Testconsultant met ruim 20 jaar ervaring in het testen van software. Hij is gespecialiseerd in testautomatisering en technisch testen.
Bekijk de LinkedIn pagina van Ed Hilkman