voor de bedrijfsvoering. Het toepassen van
gestructureerd testen is hierbij onontbeer
lijk en een vereiste om op een efficiënte en
verantwoorde wijze tot een hoogwaardig
systeem te komen. Belangrijke fouten
dienen in een zo vroeg mogelijk stadium
binnen een implementatietraject te worden
gevonden. Kosten van een project kunnen
hierdoor worden gereduceerd, risico's wor
den beperkten kwalitatief hoogwaardige
producten worden opgeleverd. Binnen het
vakgebied'testen'zijn enkele methodieken
beschreven om dit doel te bereiken. Voor
beelden hiervan zijn TMap en TestFrame.
Die trachten een volledige methodiek te
beschrijven van het testmanagement tot de
daadwerkelijke uitvoering van een testaan-
pak binnen een projectorganisatie.
Binnen de GIS-wereld staat gestructureerd
testen van Geo-ICT-projecten nog in de
kinderschoenen. Deels komt dit door
onbekendheid met het vakgebied, daar
naast lenen bestaande testtechnieken en
methodieken zich niet voor GIS-applicaties.
Binnen het'Netwerk Registratie GIS'(NRG)
Gebruikers -
Wens
Productie Acc.
Test
Requirements
Acceptatie Test
Functioneel
Ontwerp
Systeem Test
Technisch
Ontwerp
Integratie Test
Ontwikkeling
Unit Test
Fig. 2. Het V-model.
programma van het netwerkbedrijf Alliander
(zie kader op pagina 6) worden vier GIS-
applicaties vervangen door één GIS. In dit
programma is door de betrokken functioneel
beheerpartijen een professionaliseringsslag
gemaakt en wordt het gestructureerd testen
van GIS-applicaties toegepast.
Een GIS-impiementatietraject verloopt
niet anders dan een gewoon iT-project.
Een release doorloopt diverse gescheiden
omgevingen binnen een OTAP-straat
(Ontwikkeling Test Applicatie Productie)
om gecontroleerd een release in gebruikte
nemen. Het begint bij een ontwikkelomge
ving waarin de software wordt geprogram
meerd gevolgd door een aparte testomge
ving waar uitgebreide testen plaatsvinden,
en een acceptatieomgeving die een
afspiegeling is van de productieomgeving
en waar de levering op wordt geaccepteerd.
Uiteindelijk wordt in de productieomge
ving de software daadwerkelijk in gebruik
genomen. De fasering van het testen vindt
plaats conform het V-model (fig. 2). Aan de
verschillende ontwerp- en ontwikkelfasen
worden testfasen gerelateerd. Gedurende
de ontwerp- en ontwikkelfase vindt de
testvoorbereiding plaats en worden test
gevallen gedefinieerd.Testiteraties starten
wanneer de eerste release is opgeleverd.
Het gestructureerd testen verloopt
volgens een'Risk and Requirement Based
Testing (RRBT)'-methode. Op basis van
requirements worden ontwerpen gemaakt
waarmee de gewenste oplossing voor een
applicatie kan worden ontwikkeld en zo
aan de wens van de gebruiker kan worden
voldaan. RRBT koppelt risico's aan require
ments zodat hierop een prioriteitstelling
kan worden gebaseerd. Het komen tot
risico's gebeurt in overleg met verschil
lende betrokken partijen en heeft in ieder
geval een technische en functionele com
ponent. De technische component heeft
bijvoorbeeld betrekking op hoe complex
de code is waardoor het risico op fouten
in de code kan toenemen. De functionele
component kijkt vanuit het perspectief van
de business. Hoe groot zijn de gevolgen
voor de business als een bepaalde functio
naliteit niet goed werkt? Op basis van deze
prioriteitstelling kan een project bewust
keuzes maken waar wel of niet extra capa
citeit nodig is en kan aan de hand van RRBT
continu de kwaliteit en voortgang van een
implementatietraject worden gemonitord.
Met de RRBT prioriteitstelling kan voor de
testfasen het MoSCoW-principe worden
toegepast. Dit is een classificatiemethode
van testprioriteiten op basis van product
risico's. Per testgeval wordt aangegeven
of dit een'must test','should test','could
test'of'won't test'is. Met behulp van de
risicoanalyse en de prioriteitstelling kan de
testdiepgang worden bepaald.
Hoewel het stellen van deze risico's bin
nen RRBT van een GIS niet veel anders zal
Geo-lnfo 2010-11/12 5
