RT@WORK Hoe Ziet Model Based Testen Er Over 5 Jaar Uit

8/8/2019 RT@WORK Hoe Ziet Model Based Testen Er Over 5 Jaar Uit

1/8


2/8

Juni 2010

Hoe ziet Model Based Testen er over 5 jaar uitPeter Kalmijn, Rijswijk

Business domein modelBusiness domein modelBusiness domein modelBusiness domein model

Het eerste domein is het domein van de business. In dit

domein wordt het business domein model beschreven.

Dit domein wordt in de vakliteratuur ook vaak aangeduid

met Problem Space. Het model dat beschreven wordt

tracht duidelijk te maken WAT de doelstellingen zijn en

WAT de vereisten zijn (de business requirements). Dit

model is van huis uit IT en realisatie platform

onafhankelijk.

Model Based testen binnen dit domein kunnen we het

beste aanduiden met Business Model Based Testen

(BMBT).

Het business domein model de samenvatting van het

business process model en het busines decission model

- bevat belangrijk materiaal, dat prima als broninformatie

voor de testware voor de Business Acceptance Test

(BAT) kan dienen: Vanuit Use Case Maps (UCM) zijn

gemakkelijk business test scenarios af te leiden. Uit

business use cases zijn gemakkelijk business niveau

test cases af te leiden, en het business object model

geeft de input voor classification trees en voor business

object state transition test cases. Business niveau test

condities wederom kunnen afgeleid worden uit business

rules. En markering (tagging) van business rules

behorende bij een bepaalde compliancy wet &

regelgeving maakt het mogelijk om compliancy

specifieke testsets te genereren, die de daadwerkelijke

werking van de compliancy implementing controls

gericht aantonen. Dit schept geheel nieuwe

mogelijkheden voor bij voorbeeld SOX audits.

BusinessBusinessBusinessBusiness RulesRulesRulesRules ModelModelModelModel

Een zeer belangrijk model binnen de bedrijfsvoering vanorganisaties spelt het Business Rules Model. Business

Rules bepalen immers het gedrag van een organisatie of

applicatie en het Business Rules Model vormt daarmee

het gedragsmodel voor de organisatie en de IT

ondersteuning. Daarmee is het mogelijk het

belangrijkste model om model gebaseerd testen voor de

business (BMBT) op te baseren.

Interessant voor BMBTInteressant voor BMBTInteressant voor BMBTInteressant voor BMBT

Generieke Business Processen bieden handig houvast

voor het partitioneren van testen in bij voorbeeld

testclusters. Tevens bieden generieke business

processen de blueprint voor ketentesten.

Business Workflows de basis voor het testen van

afgebakende procesdelen met hun verschillende

varianten.

Business Rules afkomstig uit het business decission

model - bieden mits op de goede manier gespecificeerd

een ideaal uitgangspunt voor het ontwerpen van op de

business gente testcondities.

Business Use Case diagrammen - de klassieke basis die

een helikopter view geeft op de omvang van de vereiste

functionaliteit. De business use cases bevatten de

gedragsmatige beschrijving van vereisten, die

uitgangspunt vormen voor de vereisten van een te

implementeren IT oplossing. Samen met activiteiten

diagrammen bieden business use cases een ideaal

uitgangspunt voor het genereren van testcases, die degedragsmatige aspecten van de software toetsen.

Sequence diagrammen en state machine diagrammen -

geven dynamische aspecten zoals status transities en

interactie weer. In de problem space kunnen ze b.v.

toegestane transities van business objecten weergeven.

Deze diagrammen zijn een ideaal uitgangspunt voor

status transitie testen.

Package diagrammen - zijn het middel om systeem

vereisten te groeperen en te organiseren. Dat gebeurt

meestal op basis van domeinkennis van de organisatie,

die op natuurlijke wijze binnen het business domein

bestaat. Package diagrammen geven aan hoe testen

gegroepeerd of geclusterd zouden moeten worden.


3/8

Juni 2010


De magische lijnDe magische lijnDe magische lijnDe magische lijn

Een zeer belangrijke testactiviteit, die ik op het snijvlak

tussen de business en de IT realisatie zie, is het

valideren van het IT realisatie model ten opzichte van

het business domein model. In de toekomst zal dit

steeds belangrijker worden. Ook zal het valideren en

verifiren van een model in zich zelf tot een van de

nieuwe activiteiten en vaardigheden van een moderne

tester moeten gaan behoren.

Voor de toekomst zie ik de trend om consistent met 2

verschillende modellen te gaan werken: het Business

domein model en het IT realisatie domein.

Het eerste model is het eigendom van de business en in

beheer bij de business organisatie. De levenscyclus van

dit model volgt de levenscyclus business.

Het tweede model is het eigendom van de IT organisatie

(in huis of extern), en zal doorgaans dan ook in beheer

zijn bij die organisatie. Dit model volgt de levenscyclus

van de verandering en heeft daarmee een veel kortere

cyclus dan het business domein model.

Het vakgebied testen zal in toenemende mate te

maken krijgen met deze tweedeling in modellen.

De toekomstDe toekomstDe toekomstDe toekomst

In de toekomst zullen wij Model Based Testing Tools

gaan zien, die veel meer mogelijkheden bieden dan de

mogelijkheden, die we in hedendaagse testtool suites

kennen:

Genereren van testcases op basis van het model door

gebruik te maken van testcriteria, die eerder binnen een

teststrategie aan de hand van het product risico profiel

zijn gedefinieerd;

Geautomatiseerde ondersteuning bij de transformatie

van informatie uit modellen naar bruikbare testware,

zoals test cases en test scripts;

Geautomatiseerde en intelligente deductie van

foutsituaties door tooling

Geautomatiseerde transformatie en scripting voor

testuitvoering;

Tests, rekening houdend met de specifieke

eigenschappen van de systeem architectuur genereren;

Genereren van tests voor niet-functionele vereisten;

Volautomatische test orakels, die tevens

geautomatiseerde testen kunnen aansturen;

Automatische generatie van allerhande test producten;

Ondersteuning voor de beoordeling van de al dan niet

automatisch uitgevoerde tests;

Ondersteuning voor schattingen en voor planning van de

testuitvoering;

Ondersteuning voor onderhoud en systeem

aanpassingen;

Volautomatisch uitvoeren van allerhande tests;

Constructie van tests voor systeemgedrag;

Genereren van abstracte test cases;

Conversie van de abstracte (logische) test cases naar

concrete (fysieke) test cases in een formaat, dat bij de

test infrastructuur past.

BeloftesBeloftesBeloftesBeloftes

De voordelen, die MBT claimt zijn veelbelovend:

Verbeterde communicatie tussen testers en

ontwikkelaars;

Vroegtijdige detectie van dubbelzinnigheden in

specificaties en ontwerp;

Verkorte ontwikkelen testdoorlooptijd voor nieuwe

applicaties;

Grote besparingen op het ontwikkelen van test cases;

Vereenvoudiging van het bijwerken van testware ten

gevolge van veranderende systeemvereisten;

Desondanks een sterke verhoging van de kwaliteit van

de applicatie;

Snellere terugverdientijd op met MDD[2] en MBT

ontwikkelde IT investeringen.


4/8

Juni 2010


Groeifasen bij het testen op basis van modellenGroeifasen bij het testen op basis van modellenGroeifasen bij het testen op basis van modellenGroeifasen bij het testen op basis van modellen

De uiteindelijke droom is natuurlijk volledig

geautomatiseerd testware te genereren van op basis

van volledige UML modellen.

Om dit te bereiken zullen organisaties vier fasen moeten

doorlopen om tot de uiteindelijke verwezenlijking van de

droom te komen.

Fase 0 Geen gebruik van modellen

Fase 1 ModelModelModelModel AssistedAssistedAssistedAssisted

Het model wordt gezien als een van de hulpmiddelen

Fase 2 ModelModelModelModel BasedBasedBasedBased

Het model is nu de basis waarop systeemontwikkeling

steunt

Fase 3 ModelModelModelModel DrivenDrivenDrivenDriven

Het model is de drijvende kracht binnen

systeemontwikkeling

In de tabel Model Testing Maturity zijn de fasen met

hun kenmerken samengevat.

Fase 0Fase 0Fase 0Fase 0 Dit is de fase waar de meeste organisaties zich

nu in bevinden. Zij gebruiken nog geen modellering,

maar voornamelijk tekstuele vereisten en functionele

ontwerpen, die eventueel met flowcharts worden

verduidelijkt. Testware is op de tekstuele systeem

vereisten gebaseerd. Testers in deze organisaties

hebben doorgaans geen kennis van de modelleertaal

UML en de projecten worden veelal via het waterval

model uitgevoerd.

Fase 1Fase 1Fase 1Fase 1 ModelModelModelModel AssistedAssistedAssistedAssisted

De probeerfase. In sommige projecten wordenmodellen gebruikt, maar dit is sterk afhankelijk van de

mensen, die de projecten uitvoeren. Het komt vaak voor,

dat de modellen uit een eerder project in een opvolgend

project aan de kant worden geschoven omdat het

projectteam de modellen niet kan interpreteren. De

organisatie voert projecten uit, maar gebruikt daarbij

voornamelijk diverse en informele vormen van modellen.

Voor de test modellen wordt nog geen gebruik gemaakt

van standaard modellering conventies. De modellen zijn

alleen begrijpbaar door diegenen, die het model hebben

opgesteld.

Doordat deze modellen niet goed overdraagbaar zijn is

het gebruik van deze modellen niet consistent en

persoon gebonden. Daarom zal dit voor been bedrijf op

langere termijn niet veel opleveren. We spreken in deze

fase nog over informeel MBT.

Wel hebben sommige vooruitstrevende testers UML

geleerd en kunnen daar binnen de projecten, die met

modellen werken goed gebruik van maken, al dan niet

ondersteund door tooling. Sommige projecten makenhandig gebruik van een incrementele projectaanpak en

benutten daarbij de kracht van modellen.

Fase 2Fase 2Fase 2Fase 2 ModelModelModelModel BasedBasedBasedBased

Het middel management ziet de voordelen van het

consequente gebruik van UML modellen voor analyse

en ontwerp. Het UML model is nu het contract tussen

het ontwerp en de bouw. Deze fase noemen wij daarom

Model Based. Met enig kunst en vliegwerk wordt nu

het resultaat bereikt.

Testers beheersen UML zodanig dat zij modellen

kunnen reviewen. Hierbij gebruiken zij nog geen formele

methoden. Test analyse maakt dankbaar gebruik van

het model om daar testware van af te leiden. Het

testmodel is inmiddels gebaseerd op formele methodes

en technieken. Hierdoor kunnen test cases gemakkelijk

automatisch worden gegenereerd. We spreken in deze

fase formeel over Model Based Testing.

Ontwikkelprocessen en testprocessen zijn weliswaar

nog steeds onafhankelijk, maar relatief goed op elkaar

afgestemd en er wordt tooling ingezet, die het genereren

van functionele test cases ondersteund.

Testers experimenteren ondertussen met het UML 2

Test Profiel[8].

Fase 3Fase 3Fase 3Fase 3 ModelModelModelModel DrivenDrivenDrivenDriven

Het hogere management steunt het gebruik van UML

modellen en stelt het gebruik er van verplicht. De

projecten zijn inmiddels op een iteratieve leest

geschoeid en het testproces is zowel in het

ontwikkelproces gentegreerd, als ook in het business

analyse proces.


5/8

Juni 2010


Testers zijn bij de toetsing van het model een sprong

voorwaarts gegaan en zijn nu ook in staat om het model

te verifiren op UML syntaxis en semantiek. Testers zijn

in deze fase ook goed in staat het model te valideren op

onder meer consistentie, compleetheid en de aansluiting

met de vereisten van de business. Dit levert grote

besparingen op doordat fouten al vroeg in het

ontwikkelproces worden opgespoord. Specifieke test

modellen op basis van het doorontwikkelde UML 2 Test

Profiel worden gebruikt om testware te genereren en de

software geautomatiseerd te testen.

Het Model (incluis het testmodel) is nu de drijvende

kracht achter de ontwikkeling van de software en het

model is nu de primaire vorm van expressie geworden.

Er is in deze fase duidelijk sprake van Model Driven

Engineering (MDE). Deze derde fase in volwassenheid

noemen wij daarom Model Driven.

MDE en MBT worden gezamenlijk gezien als de

volgende stap in de evolutie van software ontwikkeling,

voor zowel business oplossingen als ook voor de

ontwikkeling van de bedrijfsondersteunende systemen.

De gevolgen voor de testers en het vakDe gevolgen voor de testers en het vakDe gevolgen voor de testers en het vakDe gevolgen voor de testers en het vak

Toetsen van de modellenToetsen van de modellenToetsen van de modellenToetsen van de modellen

Een zeer belangrijke testactiviteit, die ik hier zie, is het

valideren van het IT realisatie model ten opzichte van

het Business domein model. Er zal een verschuiving

plaats gaan vinden van de vraagstelling klopt de

programmacode naar klopt het model. In de toekomst

zal dit steeds belangrijker worden. Ook zal het validerenen verifiren van een model op zich zelf tot een van de

nieuwe activiteiten en vaardigheden van een moderne

tester moeten gaan behoren.

TestpatronenTestpatronenTestpatronenTestpatronen

Ook voorzie ik een toenemende ontwikkeling van

testpatronen (test-patterns), die dan binnen het kader

MBT worden geplaatst. Buiten het kader MBT zijn er al

verschillende ontwikkelingen, die binnen het IT

implementatiedomein gepositioneerd zouden moeten

worden; een voorbeeld: xUnit Test Patterns,

Refactoring Test Code [6]. Het wachten is op eensoortgelijke ontwikkeling van testpatronen, die specifiek

geschikt zijn voor het business domein model.

Een generiek MBT procesEen generiek MBT procesEen generiek MBT procesEen generiek MBT proces

Het ontstaan van een Generiek MBT proces zal een

natuurlijk proces zijn.

Het is waarschijnlijk dat een dergelijk proces de

volgende stappen kent:

Verificatie van het model op syntaxis en semantiek;

Validatie van het model ten opzichte van upstream

model;

Corrigeren en aanvullen van het model;

De guality gate: nu is het model pas geschikt voor de

MBT uitvoering;

Aan hand van productrisicos instellen van de MBT tool

voor de generatie van testware;

Geautomatiseerd uitvoeren van de gegenereerde

testware;

Monitoren en evalueren van de resultaten.

GarbageGarbageGarbageGarbage inininin GarbageGarbageGarbageGarbage outoutoutoutNet als voor veel andere dingen geldt ook bij MBT dat

het principe net zo sterk is als de zwakste schakel. En

daarbij speelt zeker de kwaliteit van het model waarop

MBT zich baseert een essentile rol. Hier geldt heel

sterk: Garbage in Garbage Out.


6/8

Juni 2010


Naast de bekende problemen met de volledigheid van

een (UML) model zijn er meestal ook problemen met de

interne consistentie, de accuraatheid en veelal ook met

de begrijpbaarheid van het model. Soms speelt die

begrijpbaarheid zelfs voor UML specialisten een rol,

bijvoorbeeld omdat een diagram onoverzichtelijk en met

een onlogische vlakverdeling is opgezet. De bedoelde

ideen en concepten worden dan niet goed

overgebracht. Inconsistente modellen kunnen

bijvoorbeeld tegenstrijdige informatie in twee

verschillende diagrammen bevatten. Helemaal lastig

wordt het als een model onvolledig is en hiaten in de

weergave van bij voorbeeld hoog niveau systeem

vereisten laat. Voordat een model wordt gebruikt voor

input voor MBT moet het getoetst worden op deze

punten. Het een model moet daarnaast ook getoetst

worden op syntactische en semantische correctheid. De

competenties en vaardigheden daarvoor zullen moderne

testers zich dan ook moeten eigen maken.

Bedolven onder testwareBedolven onder testwareBedolven onder testwareBedolven onder testware

Men moet met geautomatiseerde MBT rekening houden,dat er al snel een zeer grote hoeveelheid testen

gegenereerd kunnen worden. En dat er ook tijd nodig is

om deze testen veelal geautomatiseerd uit te voeren.

En nadat de tests zijn uitgevoerd moeten de

opgespoorde fouten en bevindingen ook worden

geanalyseerd en verholpen.

Een goede instelling van het MBT tool is belangrijk om

niet te worden overstelpt met relevante en minder

relevante testware. De juiste instellingen moeten in

overeenstemming zijn met het risicoprofiel van het te

testen product. Hier ligt dan ook de link met Risk and

Requirement Based Testing [7]. Men moet bij voorbeeldgaan nadenken hoe ver men wil gaan bij het genereren

van Bad Cases en equivalentieklassen. Worden alle

grenswaarden voldoende of juist overdreven

afgedekt? Of test je alle mogelijke waarden? Er zijn veel

opties, waar mee men tactisch en strategisch kan

variren.

Een ander soort werkEen ander soort werkEen ander soort werkEen ander soort werk

Het inhoudelijk toetsen, valideren en verifiren van de

modellen en ook het instellen van de te genereren

testware gaat steeds meer een deel van het werk voor

de moderne testers uitmaken. Zij zijn degenen, die alsgeen ander geschoold zijn en beschikken over het

vermogen om fouten en onvolkomenheden te vinden.

Moderne testers zullen dan ook steeds eerder in het

ontwikkelproces worden betrokken, zodat zij bij uitstek

diegenen zijn, die goed op de hoogte zijn van de

eigenschappen en functionaliteiten van het systeem.

Een andere manier van denkenEen andere manier van denkenEen andere manier van denkenEen andere manier van denken

Vergelijk het met het opkomen van het object

georinteerde paradigma. Dat bracht een fundamenteel

andere manier van denken en ontwerpen met zich mee.

Bij veel klassieke testers, zeker diegenen, die al langer

in het vak zitten, zal MBT door de andere manier van

denken op weerstand gaan stuiten. Dat is menselijk.

UML vaardighedenUML vaardighedenUML vaardighedenUML vaardigheden

Of testers van deze generatie UML in voldoende mate

beheersen is zeker te betwijfelen. Maar we moeten ook

bedenken dat 10 jaar geleden er nog niet zo veel

ontwikkelaars waren die UML beheersten.

Tegenwoordig is een goede beheersing van UML voor

een software engineer de standaard.

Een moderne tester moet niet alleen UML kunnen lezen,

hij moet UML zelfs zo diep beheersen, dat hij in staat is

om het model ook statisch te kunnen testen en te

beoordelen of het model in eenduidig en verifieerbaar

correcte UML notatie is uitgedrukt; semantisch,

syntactisch en esthetisch. Zo moet een moderne tester

ook kunnen beoordelen of het juiste UML diagram is

gebruikt en of de juiste UML notatie is gebruikt.


7/8

Juni 2010


De achterblijversDe achterblijversDe achterblijversDe achterblijvers

Een deel van de huidige testers zal de verandering naar

een moderne tester niet kunnen maken. Net zoals

COBOL ontwikkelaars een uitstervend ras zijn geworden,

zal ook de klassieke tester op gegeven moment niet

meer in staat zijn om zijn vak uit te oefenen. Gewoon

omdat de vereisten, die als testbasis dienen niet meer in

tekstuele vorm worden aangeboden, maar in steeds

toenemende mate als UML model. De klassieke tester isveelal niet voldoende opgeleid om deze vorm van

systeem vereisten te kunnen hanteren.

Mentaliteit van de moderne testerMentaliteit van de moderne testerMentaliteit van de moderne testerMentaliteit van de moderne tester

Model Based Testing vereist van testers een grotere en

directere betrokkenheid bij het vaststellen van de

vereisten voor het systeem. Tevens vereist het dat

testware (test cases, test scripts etc) binnen het team

vrij beschikbaar gesteld moeten worden. De tester

wordt hierdoor medeplichtige en verliest een deel van

zijn vaak zo gekoesterde positie als onafhankelijke en

niet betrokken waarnemer of zelfs onafhankelijke

beoordelaar.

Testers moeten gaan leren het test case ontwerp proces

duidelijker te scheiden van de daadwerkelijke codering

(bv. scripting) en van de uitvoering van de testen.

Traditioneel worden deze drie activiteiten vaak

vermengd.

De MarktDe MarktDe MarktDe Markt

Op dit moment is de vraag naar MBT langzaam aan het

opkomen. De opkomst wordt wat afgeremd omdat het

de opkomst van het gebruik van modellen binnen de

andere disciplines van software ontwikkelingen volgt.Het is een zekere factor dat er over een aantal jaren een

vrij grote markt voor MBT zal gaan ontstaan. Visionaire

spelers, die nu al aan de inbedding van MBT in hun

testportfolio werken, zullen zeker een aanzienlijke

voorsprong gaan opbouwen ten opzichte van hun

concurrenten.

De IT opleidingenDe IT opleidingenDe IT opleidingenDe IT opleidingen

Ook de IT opleidingen staan voor aanzienlijke

uitdagingen. Terwijl IT opleidingen nu vaak nog

worstelen om het testvak in de lesstof en de

opleidingsdoelen adequaat onder te brengen, staat de

uitdaging voor de deur om ook MBT onder te brengen.

Opleidingsinstituten kunnen veel winnen als zij de

dialoog met het bedrijfsleven opzoeken en gezamenlijk

met het bedrijfsleven aan testopleidingen en specifiekeopleidingen voor MBT werken.

[1] Stub: tijdelijke versie van een functie, die wel de

naam en basisfunctionaliteit bevat, maar nog geen of

slechts zeer beperkte functionaliteit.

[2] MDD: Model Driven Development


8/8

Juni 2010

Testen bij Fortis Bank Nederland Hypotheken GroepMichael van der Brugh, Utrecht

x x

Documents

RT@WORK Hoe Ziet Model Based Testen Er Over 5 Jaar Uit