Test engineering

“Als deze factsheet beschrijft hoe je de communicatie tussen business en IT kunt verbeteren en efficiënter software kunt ontwikkelen zonder in te leveren op kwaliteit, dan ben ik bereid het te lezen!”

Door op deze manier een wens te beschrijven, is naast de wens ook duidelijk wanneer aan de wens voldaan wordt. Op deze manier kun je ook voorbeelden gebruiken om te beschrijven wat een softwareproduct moet doen. Deze techniek wordt ‘Specification by Example’ genoemd.  Uitgewerkte voorbeelden inclusief de acceptatiecriteria helpen business mensen, software ontwikkelaars en testers om helder met elkaar af te stemmen wat wordt verwacht.

Waarom voorbeelden?

Het is een gebruikelijke manier om complexe onderwerpen begrijpelijk te maken. Denk bijvoorbeeld aan de miljoenennota: een spaghetti van maatregelen. Het wordt pas duidelijk wat het daadwerkelijk inhoudt als men concrete voorbeelden uitwerkt:

“Door maatregel <x> gaat de koopkracht van een gezin met twee pubers, met twee inkomens en een gezamenlijk inkomen van 50.000 euro per jaar er <x> euro per maand op achteruit.”

Bij softwareontwikkeling kunnen business mensen dergelijke voorbeelden gebruiken om de software ontwikkelaars en testers meer context te geven. Als niet duidelijk is welke problematiek moet worden opgelost met de software, is de kans klein dat de juiste oplossing gerealiseerd wordt.

Business Alignment

Business vertegenwoordigers denken in bedrijfsprocessen en gebruiken vaak voorbeelden om de complexe bedrijfsregels en scenario’s toe te lichten. Een realistisch voorbeeld kan zijn:

“Als een particuliere klant een lening aanvraagt bij onze bank, en hij heeft een negatieve BKR registratie, dan kan deze persoon geen lening krijgen.”

Door dit soort voorbeelden te gebruiken om (een deel van) de gebouwde software te demonstreren, begrijpen de business vertegenwoordigers beter wat er gebouwd is. Uiteindelijk krijgen ze software waarin hun voorbeelden werken. De IT afdeling weet wat ze moeten opleveren en de business krijgt exact wat zij verwacht!

Efficiëntie

Door uitgewerkte voorbeelden te gebruiken, zijn de acceptatiecriteria van de business van tevoren bekend. Dat houdt in dat de software pas wordt opgeleverd als aan deze criteria is voldaan. Dit zal de tijd benodigd voor de acceptatietesten enorm verlagen.

De voorbeelden helpen de analisten, software ontwikkelaars en testers het business domein beter te leren begrijpen. Hierdoor kunnen ze beter meedenken, en begrijpen wat de business daadwerkelijk nodig heeft. Uiteindelijk is de business minder tijd kwijt aan het duidelijk maken van hun wensen, en het corrigeren van verkeerde aannames. Er zijn tools beschikbaar om deze voorbeelden geautomatiseerd te laten valideren. Door gebruik te maken van een geschikte tool (zoals Fitnesse), zouden deze voorbeelden zelfs als basis  in de testcases opgenomen kunnen worden. Zie daarvoor onderstaand figuur. Dit is een voorbeeld van hoe een tabel er in de tool Fitnesse uitziet, voor en na het uitvoeren van een test case. Een groene arcering na testuitvoering betekent dat software werkt zoals wordt verwacht.

Specification by Example

Als de Fitnesse componenten zijn ontwikkeld om met het ‘Systeem Onder Test’ te communiceren, dan kunnen testcases volledig geautomatiseerd worden. Uiteindelijk ontstaat op deze manier een set aan testgevallen die desgewenst gepromoveerd kunnen worden tot testgevallen in een regressietestset.

Tools, zoals Fitnesse, zijn heel goed te gebruiken als documentatie wiki. Hiermee vervalt het extra werk om een aparte set met MS Word documenten bij te houden en is de kans groter dat de documentatie synchroon loopt met de gebouwde software  (‘Single Source Of Truth’).

Documentatie

Elk IT project worstelt met de gewenste diepgang van de documentatie: veel documentatie neemt veel tijd in beslag om te lezen en up-to-date te houden. Weinig documentatie leidt tot veel interpretatieverschillen en onduidelijkheid wat daadwerkelijk opgeleverd is.

Door voorbeelden als brokken functionaliteit te gebruiken, krijgt het IT team de juiste hoeveelheid informatie op het juiste moment. Niet te veel en niet te weinig. Ook leidt het 1-op-1 overnemen van de voorbeelden in de specificatie tot minder vertaalfouten en interpretatieverschillen.

Als alle voorbeelden vanuit een business optiek aan elkaar gekoppeld worden en gestructureerd bij elkaar worden geplaatst, is direct de basis voor je systeemdocumentatie gerealiseerd.

Hoe kunnen we helpen?

Ben je geïnteresseerd in Specification by example? Of in testautomatisering? Of in een combinatie van beiden? Dan kunnen wij je helpen met de volgende aanpak.

 

Quick Scan

Binnen een dag kunnen we de requirements- en testaanpak doornemen. Op basis van de huidige situatie en de behoeftes van de organisatie kunnen we een advies en een concreet voorstel aanbieden.

Vervolgtraject

Specification by Example heeft een aantal practices gedefinieerd. Practices die elkaar versterken en aanvullen als ze gecombineerd worden. Afhankelijk van de uitkomst van de Quick Scan kunnen we één of meerdere practices inclusief testautomatisering bij jouw organisatie implementeren.

  • Specification by Example

Het specificeren met voorbeelden is één van de eerste practices die geïmplementeerd kan worden. Het beschrijven van de zogenaamde ‘Key Examples’ binnen de specificaties is een quick win en kan prima complementair werken aan een bestaande aanpak zoals use cases. Specification by Example is bij uitstek het domein van onze partner Divetro.

  •     Executable Specifications

Om deze Key Examples optimaal te gebruiken, bestaan er open source tools (e.g. Fitnesse eventueel in combinatie met Selenium) om ze geautomatiseerd te valideren. Dan kan een specificatie direct als een geautomatiseerde functionele test dienen, een zogenaamde ‘Executable Specification’.

  •     Living Documentation

Deze ‘Key Examples’ kunnen worden opgenomen in de systeemdocumentatie. Alleen vormen deze losse voorbeelden niet een voor iedereen te begrijpen verhaal.  Ze moeten daarom in een framework worden geplaatst. Use-Case 2.0TM zou zo’n framework kunnen bieden. Dit is een volgende generatie use cases, gericht op agile werken. Gezamenlijk kan dit resulteren in een overzichtelijke en een voor iedereen te begrijpen set van systeemdocumentatie.

In combinatie met het gebruik van ‘Executable Specifications’ ontstaat een weergave van de functionaliteit, die direct als geautomatiseerde regressietest kan dienen. Dit wordt ook wel ‘Living Documentation’ genoemd.

  •     Testautomatisering

Geautomatiseerd testen is bij veel (agile) IT projecten de standaard geworden. De investering in testautomatisering resulteert in  het sneller en op een reproduceerbare wijze kunnen valideren van software. Test tools zoals Fitnesse en Selenium kunnen uiteraard ook los ingezet worden om geautomatiseerd testen te bewerkstelligen.

Wil je ons nieuwste Paarsz magazine per post ontvangen? Laat dan je gegevens achter.

Bartosz_Header_004

Werken bij Bartosz?

Vincent Verhelst

Geïnteresseerd in Bartosz? Dan ga ik graag met jou in gesprek. We kunnen elkaar ontmoeten met een kop koffie bij ons op kantoor. Of tijdens ontbijt, lunch, borrel of diner op een plek die jou het beste uitkomt. Jij mag het zeggen.

Bijtanken bij Bartosz

Gamification

Jan25

Software testen is geen handwerk maar keihard denkwerk. We maken een mentaal model van hetgeen we aan het testen zijn en aan de hand daarvan gaan we op zoek naar hoe we dat model kunnen kraken. Belangrijke skills die je hierbij nodig hebt zoals Critical Thinking en Problem Solving kun je ontwikkelen.

Ben je in staat om je analytische vaardigheden in te zetten om een puzzel op te lossen of een algoritme te kraken? Kun je onder woorden brengen wat de oplossing was? En wat was je aanpak was om de uitdaging aan te gaan?

Zo kennen we verschillende vormen van Gamification binnen het testvak. De eerste Bijtanken bij Bartosz van 2019 laat zien welke spelvormen we daarbij inzetten en waarom we daar zoveel waarde aan hechten. Maar we gaan vooral ook doen!

Mijn Paarsz