‘Dat ziet er mooi uit en het werkt ook nog eens prima. Maar sorry, het is niet wat we bedoelden’
opgeleverd dat er misschien mooi uitziet en prima werkt, maar waar niet om is gevraagd en daarom niet voldoet aan de gestelde verwachtingen of eisen van de business (business requirements).
Nog steeds is 35% van alle bugs in de productie op de een of andere manier terug te herleiden naar de requirements[1]. En deze bugs zijn bijna altijd gerelateerd aan slechte requirements en/of een gebrek aan gezamenlijk begrip over de requirements. Om deze bugs te voorkomen en om ervoor te zorgen dat we voldoen aan de verwachtingen van de business kunnen we niet zonder duidelijke en volledige requirements waarover we allemaal een gezamenlijk begrip hebben. We zullen daarom al veel eerder moeten starten met testen, al bij de requirements.
early Model Based Testing’ (eMBT)
Early Model Based Testing’ (eMBT), waaraan ik in een (eerder) blog aandacht heb besteed, is een gestructureerde aanpak voor het testen van software die ervoor zorgt dat de testcase design fase wordt geoptimaliseerd en versneld. Maar nog veel belangrijker, eMBT stimuleert de communicatie en samenwerking tussen alle stakeholders (business en technische stakeholders) met als doel het verkrijgen van een gezamenlijk begrip over de requirements in een zo vroeg mogelijk vroeg stadium van de SDLC.
Graag geef ik wat meer inzicht in de vier fasen van eMBT aan de hand van een representatief voorbeeld van de app ‘Price calculator hardware store’.
eMBT bestaat uit de volgende vier fasen:
- Explore;
- Feedback;
- Coverage;
- Execute.
Requirements app ‘Price calculator hardware store’:
Fase Explore
In deze eerste fase is het belangrijk om de business requirements te bestuderen. Het doel is om ervoor te zorgen dat er geen open einden, onduidelijkheden, tegenstrijdigheden et cetera zijn en dat er binnen het gehele team een gezamenlijk begrip is over de requirements. Alleen dan is het immers voor iedereen duidelijk wat er verwacht wordt door de business en dus gebouwd moet worden.
Op basis van de requirements en alle verzamelde relevante informatie over de requirements gaan we aan de slag met het opzetten van een eerste versie van een testmodel. Idealiter start deze fase zodra de business (Product Owner) de requirements definieert en waarbij ook het ontwikkelteam betrokken is. In de praktijk komt het echter ook voor dat deze fase later start in de refinement sessie of pas wanneer het betreffende requirements daadwerkelijk door het ontwikkelteam wordt opgepakt.
Binnen eMBT is het testmodel een grafisch model, gebaseerd op de principes van een flowchart maar met enkele specifieke condities. Eén van de kenmerken van het eMBT-model is dat deze een hoog abstractieniveau heeft en hierdoor leesbaar is voor alle teamleden. Dit bevordert in een zeer vroeg stadium de samenwerking binnen het team en heldere communicatie over de requirements.
Flowcharts worden op veel verschillende manieren gebruikt in software-engineering en ze zijn er in allerlei soorten en smaken. Maar uiteindelijk bestaan ze allemaal uit een verzameling symbolen (getekend als cirkels, diamanten of rechthoeken) en relaties daartussen (connecties genoemd en getekend als lijnen of pijlen).
Voor het eMBT-model gebruiken we de volgende vijf symbolen:
Verder gebruiken we nog een commentaar symbool. In dit symbool kunnen we al onze vragen, onduidelijkheden, tegenstrijdigheden, onvolledigheden, open einden et cetera kwijt.
Laten we naar een eerste versie van het eMBT-model kijken, gebaseerd op het voorbeeld van de app ‘Price calculator hardware store’:
Een voordeel bij het tekenen van een eMBT-model is dat je gedwongen wordt op een bepaalde manier na te denken over de juistheid en volledigheid van de requirements. In dit voorbeeld zie je dat bij het tekenen van het eMBT-model je direct al stuit op een aantal onduidelijkheden in de requirements. Deze kun je dan direct opnemen in het eMBT-model door gebruik te maken van het speciale commentaar symbool.
Ook zal je merken dat je door de opzet van het eMBT-model gaat nadenken over alle mogelijke beslissingen die in de requirements voorkomen. En zodra je deze beslissingen gaat opnemen in het eMBT-model door middel van het beslissingssymbool (met de Ja-tak naar rechts en de Nee-tak naar beneden), je gedwongen wordt na te denken over zowel de happy als niet-happy testpaden. En daardoor stuit je ook automatisch op de eventuele grenswaarden en de mogelijk aanwezige ‘open einden’. Het eMBT-model met daarin alle vragen, opmerkingen et cetera ziet er nu als volgt uit:
Fase Feedback
Om het eMBT-model nu verder te kunnen uitwerken zullen we nu eerst al onze vragen beantwoord moeten krijgen. We willen immers geen enkele aanname doen!
Het voordeel van eMBT is dat deze aanpak zeer flexibel is en we daardoor op meerdere manieren en momenten feedback kunnen geven en op meerdere manieren en momenten om feedback kunnen vragen. Soms wordt er een speciale eMBT-bijeenkomst georganiseerd, vergeleken met de 3- of 4-amigo’s bijeenkomst uit het BDD-proces. Hier kunnen dan meerdere eMBT-modellen tegelijk worden besproken. Maar in weer andere situaties vindt de feedback/review van het eMBT-model plaats in de refinement sessie of in een minder formele setting. Het is heel gebruikelijk dat voor hetzelfde eMBT-model meerdere eMBT-bijeenkomsten of feedback-/review momenten nodig zijn. Het is een iteratief en exploratory proces, met name ook door eventuele wijzigingen in de requirements tijdens het ontwikkelproces. Want een wijziging in de requirements betekent een wijziging in het eMBT-model en dan is er uiteraard weer feedback/review nodig.
In het volgende eMBT-model zijn alle antwoorden op onze vragen, opmerkingen et cetera geïntegreerd door middel van het groene commentaar symbool. Dit is natuurlijk optioneel en hangt af van hoe de feedback/review wordt uitgevoerd. Soms kan het handiger zijn om de antwoorden en opmerkingen gewoon te noteren en later in het testmodel op te nemen, waarna het opnieuw kan worden beoordeeld.
Maar….tijdens de fase Feedback, heeft de productowner nog een wijziging in een kortingspercentage aangekondigd. De korting bij een aankoop van > 200 euro moet geen 4% maar 5% zijn. Deze wijziging is dan ook opgenomen in testmodel in een groen commentaar symbool:
Nadat al onze vragen zijn beantwoord en eventuele wijzigingen, opmerkingen, onduidelijkheden et cetera zijn besproken en verwerkt in de requirements, kunnen we het eMBT-model nu updaten en verder uitwerken.
De aangepaste requirements zien er nu als volgt uit:
Het volledige eMBT-model zou er dan als volgt uit moeten zien:
We kunnen het eMBT-model nog controleren om te checken of we in ieder geval alle business rules en beslissingen uit de requirements hebben overgenomen. In de requirements van de Hardware store staan drie business rules en kun je drie beslissingen afleiden.
Business rules:
- Discount of 5% over total when buy is more than 200 euro;
- Discount of 20% over total when buy is more than 1000 euro;
- Additional discount of 10% when client buys more than 30 screw drives.
Beslissingen:
- Buy > 200 euro?
- Buy > 1000 euro?
- In buy > 30 screw drivers?
Omdat we tijdens de uitvoering (fase Execute) ook alle verschillende grenswaarden willen checken, moeten er in totaal negen verschillende condities in het eMBT-model zijn opgenomen.
Nu we hebben gecontroleerd of we alle business rules en beslissingen hebben opgenomen, kunnen we het eMBT-model opnieuw voorleggen binnen het team om er zeker van te zijn dat het eMBT-model nu correct en volledig is én om er zeker van te zijn dat nu iedereen binnen het team er eenzelfde begrip over heeft.
Fase Coverage
Nadat het eMBT-model door het hele team is beoordeeld en goedgekeurd, kunnen vanuit dit eMBT-model de testgevallen automatisch worden afgeleid op basis van een overeengekomen testdekking. De overeengekomen testdekking kan het resultaat zijn van een eerder uitgevoerde productrisicoanalyse waarbij de verschillende functionaliteiten naar prioriteit zijn gecategoriseerd. Of naar aanleiding van een ad hoc uitgevoerde risicoanalyse.
Binnen eMBT kunnen de volgende, op de requirements gebaseerde, testdekkingen worden gehanteerd (van lage naar hoge testdekking).
- Node coverage
Alle symbolen in het eMBT-model worden minimaal één keer geraakt. De symbolen Actie/Status, Beslissing en Resultaat worden geclassificeerd als symbolen. - Edge coverage
Alle uitgangen van een beslissing in het eMBT-model worden minimaal één keer geraakt. De Ja- en Nee-paden vanuit het Beslissingssymbool worden geclassificeerd als uitgangen. - Multiple condition coverage
Alle meervoudige condities worden minimaal één keer getest. Een meervoudige conditie is een combinatie van twee opeenvolgende testpaden (Ja- en Nee-pad uit een beslissing). Als een enkel pad niet onder een meervoudige conditie valt, wordt dit enkele pad ook geclassificeerd als een meervoudige conditie. - Path coverage
Alle mogelijke paden in het eMBT-model van Start naar Eind worden geraakt.
Zoals bekend wijzigen requirements voortdurend en daarom is het belangrijk om deze wijzigingen effectief te managen. Niet in de laatste plaats om zogeheten false positives en false negatives te vermijden en om de eventuele impact op testgevallen na een wijziging in de requirements, vast te kunnen stellen. Eén van de voordelen van eMBT is dat bij een wijziging in de requirements, alleen het eMBT-model hoeft te worden aangepast en dat daarna ook inzichtelijk kan worden gemaakt welke testgevallen invloed hebben gehad op de wijziging(en) en welke niet.
Fase Execute
De laatste fase is de fase waarin we de testgevallen daadwerkelijk gaan uitvoeren in het SUT en checken of het verwachte testresultaat zoals we die ook hebben opgenomen in het eMBT-model gelijk is aan het resultaat in het SUT. Afhankelijk van de eigenschappen van het testgeval, bijvoorbeeld tijdrovende test, herhalende test (regressie), moeilijk uit te voeren test, smoke-test en risicogerelateerde test, kun je de testgevallen handmatig uitvoeren of geautomatiseerde testscripts schrijven om ze geheel automatisch uit te voeren en eventueel op te nemen in de CI/CD pipeline:
Samenvatting
Nog steeds is 35% van alle bugs in de productie te herleiden tot de business requirements en deze bugs zijn bijna altijd gerelateerd aan slechte requirements of een gebrek aan eenzelfde begrip over de requirements. Om ervoor te zorgen dat we voldoen aan de wensen en verwachtingen van de klant (business value) hebben we duidelijke en volledige requirements nodig waar we allemaal een gezamenlijk begrip over hebben. Daarnaast veranderen requirements continu en het is dan ook belangrijk om deze wijzigingen goed te managen.
‘Early Model Based Testing’ (eMBT) is een gestructureerde aanpak voor het testen van software die ervoor zorgt dat de test design fase wordt geoptimaliseerd en versneld. Maar nog belangrijker, eMBT stimuleert de communicatie en samenwerking tussen alle stakeholders (business en technische stakeholders) met als doel om in een vroeg stadium van de SDLC feedback te geven en een gezamenlijk begrip te krijgen over de requirements.
Als je meer wilt weten over de aanpak van eMBT of over tooling die deze aanpak ondersteunt, hoor ik dat graag.