Shift-left met early Model Based Testen (eMBT)

Auteur: Silvio Cacace ● Silvio.Cacace@hotmail.com

Redactie: Eric Spaargaren

Tegenwoordig wordt er binnen het testvak meer en meer geautomatiseerd en dan met name als het gaat om de testuitvoering. Maar hoe zit het dan 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 wel makkelijk te onderhouden bij eventuele wijzigingen in de testbasis? En hoe zit het dan met Shift-left testen als we ons voornamelijk bezighouden 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 de traditionele testspecificatietechnieken. 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 willen we als testers de steeds snellere ontwikkelcycli kunnen bijbenen en dezelfde testkwaliteit kunnen 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 Life 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. 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. Uiteindelijk is elke bug die we eerder vinden goedkoper om te fixen, zoals ook 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 te herleiden tot 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 er dus voor 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, er wordt hier vaak later in het traject mee gestart of 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 zogeheten 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 et cetera 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 nu 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 (figuur 1).

Zoals je kunt zien in onderstaande figuur 2 is het e-MBT 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 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 et cetera 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 geautomatiseerd ten behoeve van de geautomatiseerde test.

Conclusie

Steeds meer en 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 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. Zijn de requirements helder en compleet voor alle stakeholders, dan kun je met één druk op de knop de testgevallen geautomatiseerd genereren.

In figuur 3 hiernaast (met een knipoog) nog een aanvulling op de welbekende testpiramide 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.