Deze blog was ook te vinden op de site van TestNet!

Tegenwoordig wordt er binnen het testvak meer en meer geautomatiseerd en dan met name als het gaat om de testuitvoering. Maar hoe zit het met de ontwikkeling van de testgevallen die uiteindelijk geautomatiseerd worden uitgevoerd? Worden deze nog wel gestructureerd opgezet met een bepaalde testdekking gebaseerd op een wel afgewogen risico? En zijn de testgevallen die we gebruiken makkelijk te onderhouden bij eventuele wijzigingen in de testbasis? En hoe zit het met Shift-left testen als we ons voornamelijk bezig houden met het automatiseren van de testuitvoering? Ik denk dat we met de toepassing van Model Based Testen (MBT) al veel van deze vragen kunnen beantwoorden. In deze blog geef ik graag hierop mijn visie.

Model Based Testen

Het is bekend dat Model Based Testen (MBT) veel voordelen kent ten opzichte van andere testaanpakken en dat MBT een oplossing biedt om het opstellen van de testgevallen te automatiseren. Erg belangrijk omdat er tegenwoordig immers gewoonweg geen tijd meer is om de testgevallen handmatig op te stellen en uit te werken met behulp van traditionele testspecificatietechnieken. En ondanks de beperkte tijd, blijft het doel natuurlijk ongewijzigd; op een gestructureerde manier testgevallen met bepaalde testdekking opstellen ten behoeve van de testuitvoering. We zullen daarom ook het opstellen van de testgevallen in de voorbereidingsfase moeten automatiseren als we als testers de steeds snellere ontwikkelcycli willen kunnen bijbenen en dezelfde testkwaliteit willen leveren.

Hoe mooi is het dan, dat met behulp van MBT, de testgevallen automatisch gegenereerd kunnen worden vanuit een model. En bij eventuele wijzigingen in de testbasis is het onderhoud minimaal. Alleen het model behoeft dan nog maar aangepast te worden en de testgevallen kunnen keer op keer automatisch opnieuw worden gegenereerd.

Shift-left testaanpak

Verder past MBT binnen de Shift-left testaanpak, wat betekent dat de testactiviteiten eerder in de Software Development Lyfe Cycle (SDL) moeten starten. Door MBT toe te passen, stel je namelijk in de testvoorbereiding een model op, om vervolgens vanuit dat model de testgevallen af te leiden. Hiermee verschuif je dus al testactiviteit(en) naar links. En door eerder te starten met testen, zorgen we er uiteindelijk voor dat we eerder feedback kunnen geven en dat we eventuele bugs eerder in het proces ontdekken. En uiteindelijk is elke bug, die we eerder vinden, goedkoper om te fixen, zoals beschreven in de welbekende ‘Wet van Boehm’.
De vraag die we ons nu moeten stellen is, of we onze testactiviteiten wel vroeg genoeg starten, ook al maken we gebruik van een Shift-left testaanpak en/of MBT. Helemaal als we beseffen dat ongeveer 60% van alle bugs in productie op de één of andere manier zijn terug te herleiden naar de requirements. Om deze bugs te voorkomen, zullen we derhalve moeten starten met het testen van de requirements (statische test)! Uiteindelijk zijn de requirements ook de basis voor de bouw en het testen van de gewenste software. We moeten dus zorgen, dat deze basis compleet en duidelijk is en alle stakeholders er eenzelfde begrip over hebben, voordat we überhaupt starten met het schrijven van de eerste regels code en het testen daarvan. Anders weten we zeker, dat de eerste bugs in de code als snel geïntroduceerd zullen worden.

early Model Based Testen (eMBT)

Zoals hierboven beschreven, past MBT prima binnen de Shift-left testaanpak. Echter wordt hier vaak later in het traject mee gestart. Of het wordt op een manier gebruikt die er niet op is gericht om de requirements te testen, maar puur om geautomatiseerd (uitvoerbare) testgevallen te genereren. We zullen daarom MBT op een specifieke manier moeten toepassen, in een zo vroeg mogelijk stadium. Ik noem deze testaanpak early Model Based Testen, afgekort eMBT.

Door het toepassen van eMBT ga je als het ware in een zo vroeg mogelijk stadium de requirements breken door deze te modelleren door middel van een zogenaamd eMBT-model. Zo’n eMBT-model heeft een hoog abstractieniveau en door deze op te stellen, stuit je snel op onduidelijkheden, tegenstrijdigheden, open einden, vragen, etc., die je vervolgens kunt voorleggen aan de stakeholders. Bij het opstellen van een eMBT-model ga je als tester anders nadenken over de requirements en zal je je meer verplaatsen in de uiteindelijke klant. Je bent op dit moment de requirements aan het testen op een exploratory achtige manier en geeft al zinvolle feedback, namelijk feedback over de basis.

Daarnaast is een eMBT-model een gebruikersvriendelijke visuele representatie van de gewenste situatie en voor alle stakeholders leesbaar. Dus geen technisch en moeilijk leesbaar model, zoals we dat binnen MBT vaak tegenkomen. De gebruikersvriendelijke visuele representatie van een eMT-model stimuleert de communicatie tussen alle stakeholders, met als doel te komen tot een gezamenlijk begrip over hetgeen gebouwd en dus ook getest moet worden.

Tooling

De eMBT aanpak vergt wel een tool, die deze aanpak ondersteunt. Zo moet de tool bijvoorbeeld de mogelijkheid bieden om een model te tekenen met een hoog abstractieniveau, het eMBT-model. Dit verhoogt niet alleen de leesbaarheid van het model, maar door het eMBT-model te tekenen word je als tester ook gedwongen om na te denken over zowel de happy als niet-happy flow. Verder zou de tool de mogelijkheid moeten bieden om de vragen en opmerkingen die je hebt, op te kunnen nemen in het model zelf.

Voorbeeld

Hieronder een voorbeeld van een type eMBT-model gebaseerd op de volgende requirements.

Zoals je kunt zien, is dit type eMBT model gebaseerd op de principes van een flowchart maar dan met enkele specifieke condities. Dit eMBT-model is niet alleen makkelijk op te stellen maar is ook voor iedereen duidelijk leesbaar. Er worden maar drie relevante nodes (actie/status, beslissing en resultaat) gebruikt en verder kunnen in het eMBT-model direct ook alle vragen/onduidelijkheden, etc. worden opgenomen via een aparte node. Zodra alle vragen zijn beantwoord, alle onduidelijkheden zijn weggenomen en alle stakeholders hetzelfde begrip hebben over hetgeen gebouwd moet gaan worden, is het eMBT-model in principe klaar en kunnen derhalve de testgevallen automatisch worden gegenereerd. Deze kunnen vervolgens handmatig worden uitgevoerd of worden geautomatiseerd ten behoeve van de geautomatiseerde test.

Conclusie

Steeds meer wordt er binnen het testvak geautomatiseerd en dan met name als het gaat om de testuitvoering. Maar hoe zit het dan met het opstellen van de testgevallen? Doen we dit nog wel op een gestructureerde manier en moeten we dit dan ook niet automatiseren om de korte ontwikkelcycli bij te kunnen houden? Met Model Based Testen (MBT) is dit mogelijk. MBT is inmiddels een bekende en bewezen testaanpak, die vele voordelen biedt ten opzichte van andere testaanpakken. Daarnaast past MBT binnen de Shift-left testaanpak omdat je MBT vroeg in het traject kunt inzetten. Echter, we zien vaak dat er technische modellen worden gebruikt om de testgevallen uit af te leiden. En er wordt vaak te laat gestart met het opstellen van het model en dus niet gebruikt als statische test op de requirements. Het technische model stimuleert ook de communicatie niet tussen de stakeholders, hetgeen nu juist zo belangrijk is in het begin van het traject. Hiervoor kan early Model Based Testen (eMBT) de oplossing zijn. Door met de juiste eMBT aanpak en tooling, op het juiste moment te starten met het testen van de requirements, worden onnodige bugs al in een heel vroeg stadium ontdekt, die anders pas veel later in het proces aan het licht zouden komen. Daarnaast bereiken we met deze eMBT aanpak snel een gezamenlijk begrip over hetgeen gebouwd en getest moet worden, nog voordat er een regel code is geschreven. De requirements zijn helder en compleet voor alle stakeholders, zodat je met één druk op de knop de testgevallen geautomatiseerd kunt genereren.

Hieronder (met een knipoog) nog een aanvulling op de welbekende test Pyramide met de eMBT aanpak, waarbij het testen start met het (geautomatiseerd) testen van de requirements, de onderste laag.

Als je meer wilt weten over de aanpak van early Model Based Testen (eMBT) of over tooling die deze aanpak ondersteunt, hoor ik dat graag.

Silvio Cacace