April 2010
Hoe Model Based Testen het testvak gaat veranderen
Deel 2: Waar staat Model Based Testen vandaag
MBT vandaag: de stand van zaken
In deel 1 van de serie hebben wij gekeken naar de
positie van Model Based Testing (MBT) binnen de
huidige ontwikkelingen rondom moderne
applicatieontwikkeling.
In dit deel van de serie zullen wij ingaan op de huidige
ontwikkelingen en stand van MBT vandaag. Hierbij
zullen wij ook kijken naar verschillende initiatieven om
MBT verder te ontwikkelen en de resultaten, die zij tot
nu toe hebben bereikt.
Voordat wij dieper ingaan op Model Based Testen als
zodanig tippen wij een fundamentele discussie aan, die
rondom MBT speelt. Deze discussie komt voort uit de
veel diepere vraag hoe onafhankelijk of afhankelijk MBT
mag zijn van software ontwikkeling. Wij komen daarmee
op het terrein waar ook de discussie wordt gevoerd over
de onafhankelijke beoordeling van de productkwaliteit,
zoals die van ouds door de meer traditionele
ontwikkelmethoden (b.v. SDM) en traditionele
testmethoden (b.v. Tmap en TestFrame) wordt geleerd.
Daar tegen staat de Agile benadering en methodieken
(b.v. SCRUM, Spiral, Christal en XP), waarbij testen als
geïntegreerd element van software ontwikkeling wordt
beschouwd en de beoordeling van de productkwaliteit
een gezamenlijke teamverantwoordelijkheid is.
Deze twee fundamenteel verschillende benaderingen
hebben ook hun invloed op de modellering activiteiten
en op de aard van de modellen zelf. De toekomst zal
uitwijzen of er een keuze voor een van de twee
benaderingsrichtingen zal ontstaan, dan wel beide
benaderingsrichtingen voor specifieke project situaties
en/of product typen hun eigen bestaansecht hebben.
Ook sluit ik niet uit dat de toekomst ons hybride
benaderingen of zelfs nog heel andere benaderingen
laat zien. Deze zullen hoogst waarschijnlijk ontstaan
door het inzicht dat op verschillende niveaus (van het V-
model) andere behoeften spelen. Dit kan tot een
gedifferentieerde strategie en aanpak leiden.
Peter Kalmijn, Rijswijk
Traditioneel onafhankelijke modellen
Bij de traditionele en op waterral methodieken
gebaseerde aanpak gaat de traditionele
testvoorbereiding uit van de eerder opgestelde
requirements (requirements based testing). De
requirements liggen dan ook vast voor het verdere
verloop van het project en bieden een veilige basis om
dit te doen. Men ziet ook een sterke functionele
scheiding tussen ontwikkelen en testen, waarbij testen
de rol van poortwachter vervult zodat geen software met
fouten of van mindere kwaliteit wordt opgeleverd. Dit
impliceert onafhankelijkheid en een onafhankelijke
meningsvorming. Voor de hand ligt dan ook dat deze
benadering niet wil uitgaan van de implementatie
specificaties, die in het design model van de
implementatie zijn vastgelegd, maar een eigen
testmodel gaat opstellen op basis van de requirements,
die zijn afgesproken met de klant. Hierdoor komen
interpretatieverschillen, die tot een foute uitwerking in
het design model leiden aan het licht.
Een groot voordeel van een onafhankelijk model is juist
de onafhankelijkheid van de ontwikkeling van het
product. Een groot nadeel is de dubbele onderhoudslast
bij wijzigende requirements. Zo moet het testmodel na
elke release van bijgestelde specificaties opnieuw
handmatig worden gescreend en bijgesteld. Dit is een
foutgevoelige activiteit, al te snel wordt een aanpassing
over het hoofd gezien en niet verwerkt in het testmodel.
De benadering met onafhankelijke modellen komt het
beste tot zijn recht in situaties, waarbij de onafhankelijke
product kwaliteit beoordeling belangrijk is en de
requirements redelijk stabiel zijn en niet al te vaak
wijzigen.

Hoe Model Based Testen het testvak gaat veranderen
Deel 2: Waar staat Model Based Testen vandaag
Geintegreerd model
Bij een Agile aanpak staat teamwork voorop. Dat
betekend dat naast de testrol ook alle andere rollen in
het team mede verantwoordelijk zijn voor de
beoordeling van de productkwaliteit. Het ligt dan ook
voor de hand dat testen een volledig geïntegreerde
aangelegenheid is. Stromingen als test driven
development [10] (TDD) stellen zelfs dat testen een
leidende discipline is. Een onafhankelijk model zou in
deze situaties enorm remmend werken doordat
veranderingen zowel in het testmodel als ook in het
designmodel – en synchroon - moeten worden
doorgevoerd. Doordat nagenoeg alle teamleden geacht
worden om aan het design model bij te dragen zou dit
ook voor het testmodel gelden. Dit pleit dan ook om
efficiëntie en effectiviteit redenen voor een geïntegreerd
ontwikkel- en testmodel. Doordat een werkelijk Agile
projectteam doorgaans uit ervaren en gedisciplineerde
professionals bestaat is dit geen bezwaar.
Een groot voordeel van het geïntegreerde model zijn de
collaboratieve aspecten en de invloed, die de
testtoevoegingen in het model hebben op het vroegtijdig
ontdekken van afwijkingen en interpretatieverschillen.
Immers het verband tussen het design en de manier
waarop het getest gaat worden is impliciet gegeven. Het
eerder in deel 1 genoemde UML 2.0 Testing Profile[8]
past.
dan ook goed in de methodische ondersteuning van
deze benadering.
Een nadeel is dat de functiescheiding tussen
ontwikkelen en testen niet volledig is. Maar dat is ook
een natuurlijke zaak bij Agile aangevlogen projecten.
Wat wordt getest?
Het is belangrijk te realiseren wat het doel is van een
bepaalde vorm van MBT. De zin van het testmodel is
daarbij zowel gelegen in de validatie en verificatie van
requirements, als ook in de mogelijkheid om snel en
efficiënt test cases te kunnen genereren voor bepaalde
testdoelen.
April 2010
Peter Kalmijn, Rijswijk
Genereren of programmeren
Wordt met behulp van het model de applicatie
gegenereerd, dan is het natuurlijk zinloos om te
verifiëren dat de applicatie juist is gegenereerd. Immers
de applicatie generator is een commercieel product en
daarvan mag worden uitgegaan dat het de
gespecificeerde applicatie correct genereert of
geinstantieerd. De vraag verschuift van ‘wordt de
applicatie juist gegenereerd’ naar ‘wordt de juiste
applicatie gegenereerd’. En dat heeft zeker invloed op
de manier waarop MBT moet ingezet worden.
Bij offshoring zullen door MBT beide de vragen
beantwoord moeten worden: ‘is de applicatie juist
geprogrammeerd’ en ook de vraag ‘is de juiste
applicatie geprogrammeerd’? Dit betekend natuurlijk
ook meer testwerk dan nodig zou zijn bij code generatie
of instancieren van applicaties.
Waar staan de spelers?
Model Based Testing is op dit moment bij vele
ondernemingen een hot thema. Niet onterecht gezien de
geclaimde voordelen en reeds gerealiseerde resultaten.
Zo wordt door Atos Origin een hoge besparing op
testkosten genoemd van 50 tot 75% en een besparing
op projecten van meer dan 15% door meer in -een-
keer-goed bouwen. Dat is zeer interessant in het licht
van de huidige financiële crisis, waarin alle bedrijven
goed naar hun kosten moeten kijken. Wellicht geldt dit
nog niet voor elk project en in elke situatie, maar de
indicaties zijn zeer veelbelovend.
In dit gedeelte maken wij een ronde om te zien waar de
ontwikkelingen plaats vinden en wie in Nederland op
welke wijze actief aan het onderwerp bijdragen.
 April 2010

Hoe Model Based Testen het testvak gaat veranderen

Deel 2: Waar staat Model Based Testen vandaag Peter Kalmijn, Rijswijk

Case studie
In samenwerking met Smartesting®, Borland en HP
heeft Atos Origin een Case studie gedaan. Hierover is
door Elise Greveraars een whitepaper[9] gepubliceerd.
De case studie was gericht op de testniveaus ‘system
testing’ en Íntegration testing’. Ook is er uitgegaan van
traditioneel onafhankelijke modellen. Een apart design
model en een afzonderlijk testmodel. In de case studie is
gebleken dat de totale ontwikkeltijd flink wordt
teruggebracht omdat door MBT veel fouten in een vroeg
stadium werden gevonden. Ook bleek MBT op dit
niveau betrouwbaar en tijdbesparend, mede doordat
menselijke fouten werden uitgesloten bij het maken van
test cases en tevens een veel groter aantal testcases in
kortere tijd gegenereerd kon worden. Deze testcases In het volgende en laatste deel zullen wij onze
konden tevens met HP Quick Test Pro automatisch ontdekkingsreis rondom MBT voortzetten met een blik
worden uitgevoerd. Ook dit leverde aanzienlijke tijdwinst op de toekomst en de invloed, die MBT zal uitoefenen
op en droeg bij aan de algemene kwaliteitsstijging op de bedrijven en de mensen, die met MBT gaan
omdat een veel hogere test dekkingsgraad bereikt kon werken.
worden met inzet van de zelfde resources. De winst
neemt verder toe naar mate regressietesten deel
uitmaakt van de teststrategie.
De eerste concrete resultaten uit de POC’s leverden de
volgende resultaten op:
-Er is een inwerktijd nodig van 2 -8 weken
-MBT geeft een goede en bewijsbare testdekking
-Het levert een bruikbaar simulatiemodel op zodat
validatie door simulatie mogelijk is
-MBT bleek geschikt voor een scala aan systemen (SOA,
workflow, scherm applicatie, mainframe, ..)
-Er kon een hoge besparingen op testkosten ten
opzichte van manueel testen worden bereikt (50 tot
75%)
-Er bleek goede detectie van ontwerp- en requirement
fouten (verificatie tijdens modellering) mogelijk
-De POC leverde een goede indicatie dat besparing bij
projecten op meer dan 15% bereikt kan worden door in-
een-keer-goed bouwen.
-MBT bleek goed toepasbaar bij verschillende ontwikkel
methoden