Handbook Tester PDF 1v1

SYSQA B.V.
Handboek testen
SYSQA B.V. Almere

Organisatie SYSQA B.V. Pagina 2 van 170
Titel Handboek Testen Versie 1.0
Onderwerp Inleiding Datum 05-01-2001
Inhoudsopgave
INHOUDSOPGAVE.................................................................................................................... 2
VERSIEBEHEER......................................................................................................................... 4
1. INLEIDING .......................................................................................................................... 5
2. GESTRUCTUREERD TESTEN.......................................................................................... 6
2.1 W AT IS TESTEN?............................................................................................................ 6
2.2 W AT IS TESTEN NIET? .................................................................................................... 7
2.3 BELANG VAN TESTEN ..................................................................................................... 7
2.4 TESTEN EN KWALITEIT ................................................................................................... 8
2.5 TESTVORMEN .............................................................................................................. 10
2.6 TESTSOORTEN ............................................................................................................ 11
2.7 W ELKE TESTAANPAK ?.................................................................................................. 13
3. FASERING TESTTRAJECT............................................................................................. 17
3.1 FASE: PLANNING ......................................................................................................... 17
3.2 FASE: VOORBEREIDING ............................................................................................... 18
3.3 FASE: SPECIFICATIE .................................................................................................... 19
3.4 FASE: UITVOERING ...................................................................................................... 20
3.5 FASE: AFRONDING....................................................................................................... 21
4. ORGANISATIE.............................................................................................................. 23
4.1 TESTFUNCTIES ............................................................................................................ 23
4.2 BETROKKEN DISCIPLINES ............................................................................................. 24
4.3 ORGANISATORISCHE INBEDDING .................................................................................. 25
4.4 COMMUNICATIE ........................................................................................................... 26
4.5 KENNIS EN VAARDIGHEDEN VAN EEN TESTER ............................................................... 27
5. INFRASTRUCTUUR ..................................................................................................... 29
5.1 TESTOMGEVING ........................................................................................................... 29
5.2 INITIËLE GEGEVENSVERZAMELING ................................................................................ 32
6. TECHNIEKEN ............................................................................................................... 34
6.1 FASE PLANNING........................................................................................................... 34
6.2 FASE VOORBEREIDING ................................................................................................ 34
6.3 FASE SPECIFICATIE ..................................................................................................... 34
6.4 FASE UITVOERING ....................................................................................................... 35
6.5 FASE AFRONDING ........................................................................................................ 35
7. FASE PLANNING............................................................................................................. 36
7.1 OPDRACHT FORMULERING ........................................................................................... 36
7.2 GLOBALE STUDIE EN INTAKE ........................................................................................ 37
7.3 VASTSTELLEN TESTBASIS ............................................................................................ 38
7.4 BEPALEN TESTSTRATEGIE ............................................................................................ 39
7.5 INRICHTEN TESTORGANISATIE ...................................................................................... 39
7.6 DEFINIËREN TESTPRODUCTEN ..................................................................................... 41
7.7 DEFINIËREN TESTINFRASTRUCTUUR............................................................................. 42
7.8 INRICHTEN BEHEER...................................................................................................... 44
7.9 OPSTELLEN BEGROTING .............................................................................................. 46
7.10 BEPALING PLANNING ................................................................................................ 47
Almere © 2001 Quality Assurance in ICT

7.11 FIXATIE TESTPLAN .................................................................................................... 48

8. FASE VOORBEREIDING ............................................................................................. 50
8.1 OPLEIDEN TESTMEDEWERKERS ................................................................................... 50
8.2 DETAIL INTAKE TESTBASIS ........................................................................................... 51
8.3 DEFINIËREN TESTEENHEDEN........................................................................................ 52
8.4 TOEWIJZEN TESTTECHNIEKEN ...................................................................................... 53
8.5 SPECIFICEREN INFRASTRUCTUUR ................................................................................ 54
9. FASE SPECIFICATIE................................................................................................... 56
9.1 OPSTELLEN TESTSPECIFICATIES .................................................................................. 56
9.2 DEFINIËREN UITGANGSBESTANDEN .............................................................................. 57
9.3 OPSTELLEN TESTSCRIPTS............................................................................................ 58
9.4 OPSTELLEN TESTDRAAIBOEK ....................................................................................... 59
9.5 REALISATIE TESTINFRASTRUCTUUR ............................................................................. 61
9.6 DETAILPLANNING FASE UITVOERING ............................................................................ 61
10. FASE UITVOERING ..................................................................................................... 63
10.1 INTAKE TESTOBJECT / INTAKE TESTOMGEVING.......................................................... 63
10.2 INSTALLATIE TESTOBJECT ........................................................................................ 65
10.3 UITVOEREN PRÉ-TEST .............................................................................................. 65
10.4 OPBOUW UITGANGSBESTANDEN ............................................................................... 66
10.5 (HER-) TESTUITVOERING .......................................................................................... 68
10.6 CONTROLEREN EN BEOORDELEN TESTRESULTATEN ................................................. 69
10.7 ONDERHOUDEN TESTDRAAIBOEK ............................................................................. 70
10.8 VOORTGANGSRAPPORTAGE ..................................................................................... 71
11. FASE AFRONDING ...................................................................................................... 72
11.1 EVALUATIE TESTOBJECT........................................................................................... 72
11.2 EVALUATIE TESTPROCES .......................................................................................... 72
11.3 OPSTELLEN EINDRAPPORT ....................................................................................... 74
11.4 CONSERVEREN TESTWARE ....................................................................................... 75
11.5 DÉCHARGE PROJECTGROEP ACCEPTATIE ................................................................. 76
11.6 VOORBEELD INHOUD EINDRAPPORT.......................................................................... 77
12. TECHNIEKEN VOOR TEST SPECIFICATIE................................................................ 79
12.1 ALGEMEEN ............................................................................................................... 79
12.2 GLOBALE WERKWIJZE ............................................................................................... 80
12.3 OVERZICHT TESTTECHNIEKEN .................................................................................. 82
12.4 BESCHRIJVING TECHNIEKEN ..................................................................................... 84
12.5 KEUZE VAN EEN TECHNIEK ..................................................................................... 109
BIJLAGE 1. OPSTELLEN TESTSTRATEGIE...................................................................... 115
BIJLAGE 2. DEFINITIES EN AFKORTINGEN..................................................................... 122
BIJLAGE 3 TESTTOOLS...................................................................................................... 128
BIJLAGE 4. ARTIKEL EISEN AAN INZET TESTTOOLS.................................................... 132
BIJLAGE 5. CHECKLIST S.................................................................................................... 137
BIJLAGE 6. SJABLOON TESTPLAN .................................................................................. 146
BIJLAGE 7 SJABLOON T ESTSPECIFICATIE.................................................................... 159

BIJLAGE 8 VRIJGAVE ADVIES ........................................................................................... 164
BIJLAGE 9. SJABLOON BEVINDINGENFORMULIER ...................................................... 170
Versiebeheer
Versie Status Datum Auteur Opmerkingen
0.1 Concept 05-10-2000 H.J.J. Cannegieter Initiële opzet
1.0 Defintief 08-01-2000 B. Dekkers Aanpassen aan opmerkingen van diverse medewerkers.
P. Molenkamp
H.J.J. Cannegieter

1. Inleiding
Voor u ligt het handboek gestructureerd testen van SYSQA B.V.. Dit handboek is bedoeld
om de medewerkers van SYSQA te ondersteunen bij het uitvoeren van (test-)opdrachten.
Het handboek dient te worden gezien als naslagwerk en als aanvulling op de basistraining.
Het handboek bestaat uit drie delen met een aantal bijlagen.
Deel 1 dient te worden gezien als algemene inleiding en leesstuk. Na een algemeen
hoofdstuk over de positionering van testen in ICT-projecten en kwaliteitszorg in ICT wordt in
een viertal hoofdstukken een overzicht gegeven van gestructureerd testen.
Deel 2 gaat gedetailleerd in op de fases en activiteiten van gestructureerd testen. Gekozen is
voor een standaard indeling van de activiteiten die worden behandeld. Dit vergroot de
toegankelijkheid van het handboek, maar gaat soms ten koste van de leesbaarheid.
Deel 3 gaat in op de verschillende testtechnieken die gehanteerd kunnen worden. De
testtechnieken worden toegelicht aan de hand van voorbeelden.
Het handboek gestructureerd testen dient een document te zijn dat continue wordt
aangepast en uitgebreid aan de hand van ervaringen van medewerkers van SYSQA in het
veld. Daarom verzoeken wij u onjuistheden, onnauwkeurigheden en aanvullingen actief aan
te dragen bij het productmanagement.
Overal waar in het handboek over “hij” wordt gesproken kunt u ook “zij” lezen.
Medewerkers van SYSQA kunnen het handboek gebruiken bij het uitvoeren van hun
opdrachten, het handboek mag niet ter beschikking aan derden gesteld worden.
Indien u vragen of opmerkingen heeft over het handboek wordt u verzocht deze voor te
leggen aan het productmanagement.

Onderwerp Hoofdstuk 2 Gestructureerd testen Datum 05-01-2001
2. Gestructureerd testen
Bij testen wordt beoordeeld in hoeverre een informatiesysteem voldoet aan van tevoren
vastgestelde functionele specificaties en kwalitatieve eisen. Daarnaast wordt ook de
bruikbaarheid beoordeeld.
Testen lijkt een activiteit die gericht is op het vinden van mogelijke fouten in een
informatiesysteem. Dit is slechts één van de onderdelen van het totale testtraject. Een
volledig testtraject omvat veel meer aspecten en is zelf onderdeel van de totale
ontwikkelingscyclus van een informatiesysteem. Dit handboek beschrijft alle aspecten die
van belang kunnen zijn bij een testtraject. Ieder testtraject kent z’n eigen specifieke
aandachtspunten en problemen. Voorop staat derhalve een verantwoord en doordacht
testproces, niet onderbelicht maar ook niet overdreven.
2.1 Wat is testen?

Testen komt altijd neer op het vergelijken van verwachting met de werkelijkheid. Om een
informatiesysteem te kunnen testen zal men eerst moeten weten wat van het
informatiesysteem wordt verwacht. Enerzijds is die verwachting tijdens de informatieanalyse
fase reeds geformaliseerd en vertaald in het systeemontwerp. Anderzijds zijn voor
gebruikers vanzelfsprekende doelstellingen en eisen, welke meestal niet ‘op papier’ zijn
gezet. Bij testen wordt vastgesteld of de werkelijkheid overeenkomt met deze verwachting.
Feitelijk is de verwachting de vereiste status. Met testen wordt aangetoond dat de actuele
status van het systeem overeenkomt met de vereiste status (of dat die niet overeenkomen).
De vereiste status bestaat uit een aantal eisen, zowel voor wat betreft functionaliteit als voor
wat betreft werking. Met testen wordt vastgesteld of het product werkt conform de eisen die
aan het systeem gesteld worden.
Testen heeft altijd betrekking op een eindproduct. Het systeem is, volgens de bouwer, af. Dit
in tegenstelling tot toetsen. Bij toetsen wordt vastgesteld of een tussenproduct aan de eisen
voldoet. Hierdoor ontstaat de mogelijkheid het gebruik van het systeem te simuleren. Met
testen wordt vastgesteld of het eindproduct van voldoende kwaliteit is om de functie die het
moet gaan vervullen, ook daadwerkelijk te vervullen.
Een definitie van testen is:

Testen is een proces van plannen, voorbereiden en meten dat tot doel heeft de
kenmerken van een informatiesysteem vast te stellen en het verschil tussen de
actuele en de vereiste status aan te tonen. (Pol, Theunissen en Van Veenendaal,
2000)
Een eenvoudige “werkdefinitie” van testen is:

Testen is het proces dat inzicht geeft in de kwaliteit van een informatiesysteem en de
risico’s van implementatie op dat moment.
Acceptatietesten is een specifieke vorm van testen. De definitie van acceptatietesten is:
De door de (toekomstige) gebruikers en beheerders in een zoveel mogelijk ‘als-het-ware-
productie’ omgeving uitgevoerde test, die moet aantonen dat het ontwikkelde
informatiesysteem aan de functionele en kwalitatieve eisen voldoet.

2.2 Wat is testen niet?

Naast het bepalen wat testen is, is het ook heel belangrijk aan te geven wat testen
ABSOLUUT NIET is:
• Testen is meer dan het uitvoeren van een aantal (willekeurige) testgevallen. Een goed,
gestructureerd testproces behelst ook het plannen, voorbereiden en afronden van het
testtraject. De planning en voorbereiding van het testtraject begint reeds tijdens het
ontwerpen van het informatiesysteem. De uitvoering beslaat slechts 35% van het totale
testtraject;
• Testen is iets anders dan het vrijgeven of accepteren van het informatiesysteem. De test
levert een advies over de kwaliteit van het informatiesysteem ook wel risicorapportage
genoemd. De vrijgavebeslissing kan mede op basis daarvan door anderen worden
genomen;
• Testen is iets anders dan foutherstel. Foutherstel wordt uitgevoerd door het
ontwikkelteam naar aanleiding van de bevindingrapportage;
• Testen is geen fase ná systeemontwerp en realisatie. Testen behelst binnen een
gestructureerde aanpak activiteiten uitvoeren vanaf een vroeg stadium in het
ontwikkeltraject van een informatiesysteem. Parallel aan de fase systeemontwerp moet
een testplan worden opgesteld waarin wordt gepland en met de diverse betrokkenen
wordt afgestemd;
• Testen is iets anders dan het invoeren van een informatiesysteem. Testen en invoeren
zijn deels parallelle activiteiten. Testresultaten beïnvloeden de invoering nogal eens. Met
name ten gevolge van de testresultaten verschuift het invoeringsmoment vaak naar een
latere datum;
• Testen doet een uitspraak in hoeverre het informatiesysteem overeenkomt met het
systeemontwerp. Testen is echter geen activiteit gericht op het vaststellen van de
volledigheid en juistheid van het systeemontwerp. Hier zijn andere activiteiten in het
kader van kwaliteitszorg in ICT-projecten op gericht;
• Testen is niet het opleiden van medewerkers om met het nieuwe systeem te leren
werken. Het is wel mogelijk gebruikers die nog geen ervaring hebben met het systeem
testgevallen uit te laten voeren. De testgevallen dienen echter wel gespecificeerd te zijn.
Daarnaast verloopt de uitvoering van de test over het algemeen langzamer als opleiden
en testuitvoering wordt gecombineerd;
• Behalve programmatuur worden in de test ook beheersprocedures, handleidingen,
beveiliging, AO-procedures, conversieprogrammatuur, interfaces met andere
informatiesystemen, etc. getoetst en getest.
2.3 Belang van testen

Een opdrachtgever wil, voordat hij/zij de beslissing kan nemen het informatiesysteem in
gebruik te nemen, antwoord hebben op de vragen:
• Kan de bedrijfsvoering van het informatiesysteem afhankelijk worden gemaakt?
• Voldoet het informatiesysteem aan de vooraf opgestelde functionele eisen?
• Biedt het informatiesysteem een oplossing voor het informatieprobleem waarvoor het is
ontworpen?
Met betrekking tot de test bestaan de vragen:

• Zijn alle systeemdelen met voldoende diepgang getest?
• Is behalve op de functionaliteit ook op o.a. bruikbaarheids-, prestatie-,
beveiligingsaspecten, consistentie en integriteit getest?
• Zijn alle gevonden fouten hersteld en zijn bij dat herstel geen nieuwe fouten
geïntroduceerd?

Als er op deze vragen geen betrouwbare antwoorden verkregen worden, is de test niet
compleet of niet goed uitgevoerd. Als zo'n informatiesysteem in productie wordt genomen,
kunnen de genomen risico's leiden tot kostbare productiestoringen. Een fictief voorbeeld:
Met behulp van een informatiesysteem worden maandelijks facturen verzonden naar klanten.
Het aantal verzonden facturen ligt maandelijks op ca. 8000. Omdat het (nieuwe)
informatiesysteem een fout in de berekening van het totaalbedrag op de factuur bevat, wordt
aan de klant teveel doorberekend. Gevolg van deze fout is: veel klanten reclameren, de
software moet worden aangepast, alle 8000 facturen moeten opnieuw worden afgedrukt,
gefrankeerd en verzonden. De teveel ontvangen bedragen moeten worden teruggeboekt.
Bovendien is er een groot verlies van good-will bij de klanten.
De grote risico's en de kostbare gevolgen rechtvaardigen een gestructureerde aanpak van

de test. De karakteristieken van deze gestructureerde aanpak zijn de volgende:
• Projectbeheersing door aandacht voor planning en besturing van het testproject;
• Een infrastructuur voor het uitvoeren en registreren van alle projectactiviteiten;
• Beheersing van tegengestelde belangen door een goede organisatie;
• Aandacht voor versiebeheer;
• Het aanreiken van testtechnieken en -hulpmiddelen;
• Risico-analyse;
• Het op ieder moment in het testuitvoering kunnen uitbrengen van een risicorapportage;
• Kostenminimalisatie door vroegtijdige fout detectie;
• Statistieken voor inzicht in de kwaliteit, kosten en baten.
In de afgelopen jaren is een groeiende bewustwording ontstaan over het nut van testen.
Ondanks deze constatering wordt met het testen vaak onvoldoende rekening gehouden bij
een ontwikkeltraject van een informatiesysteem. Eén van de oorzaken hiervan is het te laat
starten van het testtraject waardoor problemen ontstaan die een tijdige invoering van het
informatiesysteem in de weg staan (De fase ‘Planning’ van testen begint al tijdens de SDM-
fase systeemontwerp). Verder is er onbekendheid met de testen (en de hiervoor benodigde
tijdsduur, inspanning en kosten) bij betrokkenen en management. Testen wordt, bij de
ontwikkeling van een informatiesysteem, nog te weinig gezien als onderdeel van het totale
kwaliteitsysteem(organisatiebreed) maar meer als een separate activiteit na de fase
realisatie.
Verbetering van testen kan o.a. plaatsvinden door reductie van de tijdsdruk. Dit kan bereikt
worden door een tijdige en realistische planning, voortgangsbewaking, een tijdige start,
voldoende en goed opgeleid personeel en sluitende afspraken met alle betrokken partijen.
Testen verdient als kwaliteitsinstrument meer aandacht. Dit kan worden bewerkstelligd indien
in alle fasen van ontwikkeling van een informatiesysteem aandacht is voor de gewenste
kwaliteitseisen, deze eenduidig worden vastgelegd, deze zo vroeg mogelijk tijdens de
ontwikkeling worden getoetst en indien nodig gecorrigeerd.
2.4 Testen en kwaliteit

Testen dient geen doel op zich te zijn. Testen is slechts een instrument om een bijdrage te
leveren aan het realiseren en borgen van de kwaliteit van het te ontwikkelen
informatiesysteem. Testen dient te worden ingebed in een systeem van maatregelen om tot
kwaliteit te komen: testen dient te worden ingebed in de kwaliteitszorg van de organisatie.
2.4.1 Soorten kwaliteitsmaatregelen

In het kader van kwaliteitszorg kunnen drie soorten maatregelen worden genomen:

1. Preventieve maatregelen.
2. Detectieve maatregelen.
3. Correctieve maatregelen.
Ad 1. Preventieve maatregelen.
Dit zijn maatregelen die genomen worden voordat het product gemaakt wordt. Met
preventieve maatregelen wordt beoogd het maken van fouten te voorkomen. Voorbeelden
van preventieve maatregelen zijn:
• Toepassen van methoden;
• Gebruik maken van technieken;
• Gebruik maken van hulpmiddelen;
• Opstellen en implementeren van standaards;
• Beheren van proces en producten;
• Verzamelen van metrics;
• Motiveren van medewerkers;
• Coachen van medewerkers.
Ad 2. Detectieve maatregelen.
Dit zijn maatregelen die geëffectueerd worden nadat het product is gebouwd, maar nog niet
gebruikt wordt. De detectieve maatregelen zijn erop gericht in een zo vroeg mogelijk stadium
fouten op te sporen en te herstellen.
Het meest bekende detectieve maatregel is het testen. Andere detectieve maatregelen zijn:
• Walktrough: Tijdens een bijeenkomst wordt een product onder begeleiding van de
ontwikkelaar stap voor stap doorlopen met als doel mogelijke knelpunten op te sporen;
• Inspectie: Een object wordt door één of meerdere personen (niet de maker) nauwkeurig
nagelopen met het doel fouten te vinden en deze, waar mogelijk, te analyseren;
• Review: Het toetsen van een product aan normen, standaards en richtlijnen met als
resultaat een onderbouwde beoordeling van het betreffende product;
• Audit: Een, door een onafhankelijke instantie uit te voeren, formeel onderzoek van een
product of project t.a.v. eisen, specificaties, uitgangspunten, standaards, procedures,
contracten en eigendomsrechten, met als doel de status van het product of project vast
te stellen;
• Certificatie: Een, door een onafhankelijke instantie uit te voeren, formeel onderzoek naar
opgeleverde producten en werkwijzen, met als doel aan een object (product of
organisatie) een schriftelijk certificaat (kwaliteitscertificaat) af te geven als een soort
garantie.
Ad 3. Correctieve maatregelen.
Correctieve maatregelen worden uitgevoerd nadat het product in productie is genomen. De
gebruikersorganisatie werkt dus al met het systeem. Wijzigingen worden dan doorgevoerd;
programmatuur wordt aangepast, processen worden heringericht, de organisatie veranderd
of de procedures gewijzigd.
2.4.2 Kosten van kwaliteitszorg

De herstelkosten van fouten die geconstateerd worden nemen toe naar mate ze later
gevonden worden in het automatiseringsproject. Met andere woorden een vroeg gevonden
fout is goedkoper dan een laat gevonden fout (B.W. Boehm). Ditzelfde geldt voor de kosten
van kwaliteitsmaatregelen. Preventieve maatregelen brengen minder kosten met zich mee
dan detectieve maatregelen. Correctieve maatregelen brengen de meeste kosten met zich
mee. Hieruit volgt dat testen een relatief dure activiteit is. Echter, een fout gevonden in de
exploitatiefase is vele malen hoger zijn dan wanneer dezelfde fout geconstateerd wordt voor
of tijdens de testfase. De volgende grafiek toont de herstelkosten die exponentieel toenemen
naarmate fouten later worden geconstateerd in het ontwikkeltraject.

300 Herstelkosten
250
200
150
100
Wet van B.W. Boehm
50
0
IA SO RE INV EXP
Aan het acceptatietesten zijn kosten en baten verbonden. De kosten van het
acceptatietesten schommelen afhankelijk van het systeemtype, tussen de 20% en 50% van
de kosten van de fase systeemontwerp en realisatie samen. Daarentegen zijn de baten van
het acceptatietesten niet direct uit te drukken in een percentage van de ontwikkelingskosten.
Desondanks is het zo dat acceptatietesten bijdraagt aan een kwaliteitsverbetering van het
ontwikkelde informatiesysteem, waardoor tijdens de SDM-fases invoering en exploitatie
minder problemen zullen optreden.
De baten van gestructureerd testen zijn:

• Vroege(re) detectie; Door kwalitatief goed te testen worden de belangrijkste fouten
vroeger gevonden dan wanneer men niet gestructureerd test.
• Preventie; fouten worden niet meer in productie gevonden, maar voor de implementatie
worden de fouten gevonden en mogelijk ook verholpen.
• Testware voor onderhoud; tijdens het testproces ontstaat testware die goed
geconserveerd wordt en op die manier herbruikbaar is bij volgende testtrajecten
(regressietesten).
• Minder wachttijd bouwers; door een goede voorbereiding worden de eerste bevindingen
relatief snel na oplevering gedaan.
• Kortere doorlooptijd; de time-to-market is tegenwoordig een belangrijk aspect bij het
ontwikkelen van informatiesystemen. Een lange testuitvoering vergroot deze time-to-
market. Bij het goed voorbereiden van de testuitvoering wordt bewerkstelligd dat testen
zo kort mogelijk op het kritieke pad zit.
• Andere voordelen van acceptatietesten zijn dat gebruikers die hebben deelgenomen aan
het acceptatietest-traject beter bekend zijn met het informatiesysteem. Daarnaast geeft
acceptatietesten (meer) zekerheid ten aanzien van risico’s wanneer het
informatiesysteem wordt ingevoerd.
De kosten/baten en risico’s worden door de opdrachtgever bepaald, geoptimaliseerd en

beperkt. De projectleider acceptatie kan hierbij ondersteuning bieden.
2.5 Testvormen
Het beoordelen van een informatiesysteem vindt plaats door de eigenschappen ervan te
meten. Dit meten kan op verschillende manieren.
2.5.1 Dynamisch expliciet testen

Dynamisch expliciet testen is het uitvoeren van gerichte testgevallen ofwel het uitvoeren van
programma’s. Daarbij wordt het actuele resultaat vergeleken met het verwachte resultaat om
zo te bepalen of het informatiesysteem zich gedraagt zoals verwacht. Dit is de meest
gangbare vorm van testen.

2.5.2 Dynamisch impliciet testen

Tegelijkertijd met het uitvoeren van dynamisch expliciet testen kunnen gegevens over het
verloop van dat testproces worden verzameld. Uit deze gegevens kan informatie worden
afgeleid over het informatiesysteem. De resultaten van deze meetmethode worden vaak in
de vorm van statistieken weergegeven. Op deze wijze zijn trends te ontdekken in het gedrag
van het informatiesysteem tijdens de testperiode. Bijvoorbeeld door het registreren van
storingen tijdens de testperiode kan een schatting worden gegeven van de te verwachten
storingen tijdens de productie.
2.5.3 Statisch testen

Een informatiesysteem bestaat uit meer dan alleen programmatuur. Een informatiesysteem
is het totaal van structuren en middelen die gebruikt worden om een organisatie van
informatie te voorzien. Naast de applicatie(programmatuur) bestaat bijvoorbeeld ook de AO-
procedure, de technische infrastructuur, de bijbehorende documentatie, de beveiliging en het
conversieplan.
Voor een aantal van de bovenstaande aspecten kan niet door middel van dynamisch testen
worden gecontroleerd of deze voldoen aan de gestelde eisen. Dit maakt het noodzakelijk
andere vormen van testen aan te wenden.
Zo’n andere vorm is het controleren en onderzoeken van producten, zonder dat er sprake is
van het uitvoeren van programma’s. Hierbij kan gedacht worden aan het beoordelen van
beveiligingsprocedures, handleidingen, opleidingen, etc. Dit heet statisch testen.
Vaak wordt de term direct gebruikt voor dynamische testen. Hierbij heeft direct betrekking op
het testobject zelf. Daarnaast wordt indirect gebruikt voor statische testen. Hierbij duidt
indirect op de omgeving van een testobject.
2.6 Testsoorten
Een algemeen bekende en geaccepteerde tweedeling van testsoorten op grond van
eigenschappen is:
White-box test;
Black-box test.
White-box testen zijn gebaseerd op de programmacode, de programmabeschrijving of het

technisch ontwerp. Nadrukkelijk wordt gebruik gemaakt van kennis van de interne opbouw
van het systeem. Ze worden uitgevoerd door het ontwikkelteam of reviewers. Als white-box
testen worden in zijn algemeenheid aangemerkt de unit-, module- of ook wel programmatest
en de integratietest.
Black-box testen zijn gebaseerd op de functionele specificaties en kwaliteitseisen. Er wordt

zowel gekeken naar de functies als de prestaties. Het informatiesysteem wordt als een
zogenaamde 'Black box' bekeken: levert het informatiesysteem bij invoer A inderdaad de
gespecificeerde uitvoer B op, binnen de gestelde tijd C, in omgeving D. Hierbij wordt het
uiteindelijke gebruik van het informatiesysteem zo goed mogelijk benaderd.
Een en ander is te vergelijken met het testen van een auto. Hierbij kan men door een
proefrit, eventueel met de specificaties in de hand, beoordelen of de auto aan de
(gespecificeerde) verwachtingen voldoet: rijdt de auto echt 150 Km/h en trekt de auto
inderdaad binnen 10 seconden op van 0 tot 100 Km/h? Werkt de stuurbekrachtiging en zit er
een make-up spiegeltje achter de zonneklep? Dit is black-box testen.

Men kan natuurlijk ook de motor(kap) openen en controleren of de cilinderinhoud klopt met
de opgave, of de nokkenas inderdaad ‘boven ligt’ en of de ruitenwissermotor voldoende
tegen vocht is beschermd. Dit is white-box testen.
De verschillende testsoorten worden nader uiteengezet aan de hand van het zogenaamde V-
model van systeemontwikkeling:
Gebruik en
beheer Verwachting
Wens
Functioneel Acceptatie
ontwerp test
Technisch Systeem
ontwerp test
Realisatie Programma- en
integratie test
Het V-model is een schematische weergave van een systeemontwikkelingstraject volgens

SDM-I. Tegenover de ontwikkelfases staan de testsoorten. Het V-model begint met de wens
een systeem te ontwikkelen. Deze wens is vaak algemeen en wollig geformuleerd. De wens
bestaat vaak uit een visie en een aantal doelstellingen. Om dit concreet te maken wordt een
functioneel ontwerp van een bepaald systeem gemaakt. In dit functioneel ontwerp staat
beschreven hoe het systeem invulling gaat geven aan de geformuleerde wens. Het
functioneel ontwerp is op zodanige wijze opgesteld dat het voor zowel de
gebruikersorganisatie als de ICT organisatie begrijpelijk is. De systeemontwikkelaar vertaalt
het functioneel ontwerp in een technisch ontwerp. Met het technisch ontwerp in de hand kan
de systeemontwikkelaar het systeem realiseren. Met behulp van de tests wordt vastgesteld
of het eindproduct voldoet aan de vooraf gestelde eisen.
De programmatest wordt uitgevoerd door de systeemontwikkelaar en richt zich erop vast te

stellen of het programma onderdeel (technisch gezien) werkt conform de specificaties
opgenomen in het technisch ontwerp. De programmatest is een white-box test.
De integratietest richt zich erop vast te stellen of de of de verschillende systeemonderdelen

(technisch gezien) werken zoals beschreven in het technisch ontwerp. De integratietest
wordt in principe ook uitgevoerd door de systeemontwikkelaar. Ook de integratietest is een
white-box test.

De systeemtest is een black-box test en wordt uitgevoerd door testers in opdracht van en
namens het projectteam dat verantwoordelijk is voor de bouw van het systeem. De
systeemtest richt zich erop vast te stellen of het systeem dat het projectteam, de
opdrachtnemer, heeft ontwikkeld voldoet aan de opdracht die is gegeven. Het functioneel
ontwerp is feitelijk de opdracht. Daarom is de testbasis van de systeemtest het functioneel
ontwerp.
De acceptatietest wordt uitgevoerd namens de opdrachtgever; de gebruikersorganisatie. De

acceptatietest heeft meerdere doelen. Ten eerst wordt met behulp van de acceptatietest
vastgesteld of de opdrachtnemer naar behoren de haar gegeven opdracht heeft volbracht.
Daarnaast wil de gebruikersorganisatie zekerheid hebben dat het processen van de
gebruikersorganisatie na implementatie van het nieuwe systeem ongestoord voortgang
kunnen vinden. Als gevolg van de diverse doelstellingen heeft de acceptatietest meerdere
bronnen waarop deze gebaseerd is; het functioneel ontwerp, de wens en het (toekomstig)
gebruik en beheer. De acceptatietest is een black-box test.
De acceptatietest wordt in sommige gevallen gesplitst in de functionele acceptatietest en de
productie acceptatietest. Met behulp van de functionele acceptatietest wordt vastgesteld of
het systeem werkt conform het functioneel ontwerp. Met de productie acceptatietest wordt
vastgesteld of het systeem technisch werkt en of gegeven de exploitatie-eisen in productie
kan worden genomen.
De systeemtest en functionele acceptatietest richt zich allebei op het vaststellen of het

informatiesysteem is gebouwd conform het functioneel ontwerp. Op basis hiervan zijn er
organisaties die de systeemtest en functionele acceptatietest samenvoegen. Dit wordt
geïntegreerd testen genoemd. Het testteam test dan namens twee opdrachtgevers. Dit kan
een risico zijn; in hoeverre kan het testteam een onafhankelijk oordeel geven over de
applicatie als het ook namens de opdrachtnemer werkt. Ten tweede is de invalshoek van de
systeemtest en de functionele acceptatietest toch anders; de systeemtest beperkt zich toch
meer op het vaststellen dat aan de eisen in het functioneel ontwerp is voldaan. Bij de
acceptatietest wordt ook de aanvankelijke wens en de verwachtingen ten aanzien van
toekomstig gebruik in ogenschouw genomen. Blijft overeind staan dat systeemtest en
functionele acceptatietest veel gemeen hebben.
In dit handboek wordt met testen zowel de systeemtest als de functionele acceptatietest
bedoeld, tenzij anders vermeld.
2.7 Welke testaanpak?

Als men een testproject gaat uitvoeren moet men altijd voor ogen houden dat het niet
mogelijk en noodzakelijk is altijd alles (100%) te willen testen. Een gestructureerde
testaanpak zoals in dit handboek is beschreven biedt de mogelijkheid verantwoorde keuzen
te maken over wat wel en wat niet getest moet worden. Bij de testaanpak wordt in feite
bepaald hoe er getest gaat worden.
Voor een testproject bestaat geen universele testaanpak met garantie op een succesvol
verloop. Dit handboek kan beschouwd worden als een ‘gereedschapskist’ waarbij voor ieder
testproject alleen de benodigde onderdelen worden gebruikt. Het is dus niet zo dat dit deel
van voor tot achter moet worden doorlopen. Voorop staat een verantwoord testtraject, niet
onderbelicht maar ook weer niet overdreven.
Er is een verzameling universele onderdelen die bij elke (acceptatie)test aan de orde komen
namelijk:
• Het acceptatietestplan;

• De risico-analyse en strategiebepaling;
• De testbasis;
• De testtechnieken;
• De acceptatiecriteria;
• De testinfrastructuur en de testtools;
• Het versiebeheer;
• Het (her)testen;
• De organisatie en het personeel;
• De opleidingen;
• De planning;
• De voortgangsbewaking;
• De risicorapportage;
Daarnaast bestaan er nogal wat afwegingen voor de selectie van een toereikende
testaanpak zoals:
• Omvang van het informatiesysteem

Naarmate een informatiesysteem omvangrijker is, wordt de vereiste inspanning die
noodzakelijk is om het totale systeem te testen groter.Teneindedeze inspanning zo efficiënt
mogelijk te laten zijn, kan bij het bepalen van de teststrategie een afweging worden gemaakt
m.b.t. het belang van de verschillende deelsystemen. Bij omvangrijke informatiesystemen
moet de acceptatietest worden opgesplitst in deelprojecten voor de verschillende
deelsystemen. Deze opsplitsing vindt plaats op basis van de functionaliteit van de
deelsystemen en is een methode om het totale testproject beheersbaar te houden.
• Belang van het informatiesysteem voor de organisatie

Naarmate het belang en de afhankelijkheid van een informatiesysteem voor een organisatie
groter zijn, zal ook de testinspanning groter zijn. Een informatiesysteem dat het primaire
proces van een organisatie ondersteunt zal uitgebreider en grondiger getest moeten worden
dan een informatiesysteem dat voor een organisatie van secundair belang is.
• Gebruik van CASE tools

Indien bij de ontwikkelingscyclus van een informatiesysteem gebruik is gemaakt van een
CASE (Computer Aided Software Engineering) tool zal het accent van de acceptatietest
verschuiven van het testobject naar het systeemontwerp en het verifiëren van de
specificaties (detail intake testbasis). Een gedeelte van de acceptatietest vindt in feite in een
eerder stadium van de ontwikkelingscyclus plaats.
Bij een goed uitgevoerde verificatie van het systeemontwerp zal het aantal fouten in de
verdere ontwikkelingscyclus drastisch afnemen.
• De complexiteit van het informatiesysteem

Indien de complexiteit van een informatiesysteem groot is, d.w.z. er zijn veel verschillende
condities en onderlinge afhankelijkheden, zal het aantal benodigde testen en de daarbij
behorende testinspanning groter zijn. Bij de testaanpak kan op deze complexiteit
geanticipeerd worden door onderdelen op te splitsen en voor deze onderdelen afzonderlijk
de diepgang te bepalen waarmee getest gaat worden. Ook kan in de testaanpak getracht
worden de onderlinge afhankelijkheden te beperken, waardoor tijdens de testuitvoering
meerdere testscripts onafhankelijk van elkaar kunnen worden uitgevoerd. Een goede
testaanpak kan bij complexe systemen de testinspanning beperken, zonder dat afbreuk
wordt gedaan aan de kwaliteit van de acceptatietest.
• Applicatiepakket ,standaardapplicatie of Maatwerkapplicatie,

Het testen van applicatiepakketten of standaardapplicaties vereist meestal een andere

testaanpak dan het testen van maatwerkapplicaties.
De testinspanning houdt bij pakketten rechtstreeks verband met de beïnvloedbaarheid van

de functionaliteit c.q. de flexibiliteit. Pakketten waarbij de gebruiker vrijwel geen invloed heeft
op de functionaliteit zoals bijvoorbeeld tekstverwerkers, vragen in principe weinig tot geen
testinspanning. Pakketten die naar behoefte kunnen worden ‘gecustomized’, vragen
doorgaans eenzelfde hoeveelheid testinspanning als een maatwerkapplicatie. Customizing
van een pakket behelst meestal het parameteriseren van de diverse mogelijkheden en soms
het aanbouwen van nieuwe functionaliteit. Bij uitgebreidere pakketten wordt soms zelfs een
eigen ontwikkelomgeving aangeboden. Die moet dan op haar beurt weer passen, enz. Er is
dus een sterke relatie tussen de mate waarin een pakket aanpassing behoeft en de
benodigde testinspanning.
• Nieuwbouw of onderhoud
Bij onderhoud van een informatiesysteem worden meestal niet alle modules aangepast. In dit
geval worden alleen de aangepaste modules getest en wordt gecontroleerd (getest) of de
aanpassingen geen invloed hebben op de overige (niet gewijzigde) systeemdelen. Deze test
wordt de zogenaamde regressietest genoemd. Indien testware aanwezig is kan hiervan
gebruik worden gemaakt. Hierbij wordt opgemerkt dat vaak blijkt dat de functionele
specificaties en bijbehorende testware onvoldoende zijn, of dusdanig gewijzigd zijn dat
hierop alsnog een inhaalslag moet worden gepleegd.
Het accent bij onderhoudstesten ligt vaak meer op functioneel en technisch correct
functioneren dan op de overige kwaliteitsattributen, zoals bijvoorbeeld beveiliging,
performance en gebruikersvriendelijkheid, omdat aan deze kwaliteitsattributen bij onderhoud
meestal niets wordt gewijzigd. Bij nieuwbouw zijn de overige kwaliteitsattributen wel van
belang. Om te bepalen of aan de acceptatiecriteria met betrekking tot deze
kwaliteitsattributen wordt voldaan zal, ten opzichte van onderhoudstesten, extra
testinspanning moeten worden gepleegd.
Daarnaast is testen in onderhoudssituaties vaak een activiteit van de lijnorganisatie. Dit in

tegenstelling tot de projectmatige aanpak bij nieuwbouw van informatiesystemen. Hierdoor
moeten testactiviteiten vaak concurreren met andere lijnactiviteiten. Dit heeft vaak tot gevolg
dat het testen op een lager plan staat. Vanwege o.a. tijdsdruk worden testen soms niet of
met verminderde kwaliteit uitgevoerd.
• Kwaliteitseisen
De kwaliteitseisen die aan een informatiesysteem worden gesteld komen pas goed tot hun
recht, indien in alle fasen van ontwikkeling van een informatiesysteem aandacht is voor de
gewenste kwaliteitseisen, deze eenduidig worden vastgelegd, deze zo vroeg mogelijk tijdens
de ontwikkeling worden getoetst en indien nodig gecorrigeerd.
De wijze waarop bij acceptatietesten met kwaliteitseisen wordt omgegaan, wordt bepaald in
de testaanpak. Kwaliteit is een integraal onderdeel van een ontwikkelingscyclus van een
informatiesysteem. Testen op zich leidt niet tot een kwaliteitsverbetering van een
informatiesysteem.
Welke kwaliteitseisen tijdens de acceptatietest worden getest, wordt bepaald in de

teststrategie. Dus de testaanpak bepaalt hoe en de teststrategie bepaalt wat getest gaat
worden.
• Kwaliteit van de testbasis

Naarmate de kwaliteit van de testbasis beter is, kan de testinspanning gereduceerd worden.
De testaanpak kan hierop anticiperen. Het is dan eenvoudiger vanuit de testbasis eenduidige
testspecificaties te maken. Indien de testbasis onduidelijk of niet actueel is, moet meer
inspanning worden verricht om de testspecificaties te maken of te actualiseren.
• Beschikbare mensen en middelen, inclusief de tijd

Als de mensen en middelen voor een acceptatietesttraject beperkt zijn, of de einddatum
waarop het informatiesysteem in gebruik wordt genomen ligt vast, dan vergt dit een andere
testaanpak dan bij acceptatietesttrajecten waarvoor de resources ruimer zijn. De beperking
van resources kan ertoe leiden dat de diepgang waarmee getest wordt voor bepaalde
deelsystemen geringer is. Ook de afspraken die gemaakt zijn voor de beschikbaarheid van
mensen en middelen moeten scherper worden afgedwongen.
• Productie-omgeving
Als de productie-omgeving sterk afwijkt van de testomgeving of zeer specifieke
eigenschappen heeft, kan hiermee in de testaanpak rekening worden gehouden. Er kunnen
in de testaanpak aanvullende maatregelen worden genomen om risico’s m.b.t. de productie-
omgeving te beperken. Hierbij valt bijvoorbeeld te denken aan het inzetten van tools voor het
simuleren van grote aantallen gebruikers.
• Testtools
Testen is een arbeidsintensieve bezigheid. Om het testen te vergemakkelijken wordt soms
veel verwacht van testtools. Het gevaar bestaat, dat testtools een doel op zich worden en dat
de hele testaanpak op het gebruik van bepaalde testtools wordt toegesneden. Dit leidt
helaas te vaak tot teleurstellingen. Allereerst is een goede testomgeving nodig, waarin
vervolgens eventueel een testtool nuttige diensten kan bewijzen. Daarnaast is voor het
gebruik van testtools opleiding noodzakelijk. Het gaan gebruiken van testtools is in vele
opzichten te vergelijken met een automatiseringsproces. In feite wordt het testproces
geautomatiseerd.
Het is een uitdaging voor de projectleider acceptatie om op basis van o.a. de bovenstaande
overwegingen een toereikende testaanpak te kiezen als maatregel om de risico’s beperken.

Onderwerp Hoofdstuk 3. Fasering testtraject Datum 05-01-2001
3. Fasering testtraject
In dit hoofdstuk volgt een samenvatting van de fases in het testtraject. Van iedere fase wordt
kort beschreven wat het doel is, een algemene beschrijving gegeven, aangegeven welke
randvoorwaarden en uitgangspunten gelden, wat de uit te voeren fases zijn en welke
producten ontstaan. Tevens is er een netwerkdiagram opgenomen van de verschillende
subfases in een fase. Deze fases zijn:
1. Planning
2. Voorbereiding
3. Specificatie
4. Uitvoering
5. Afronding
De relaties tussen de verschillende fases zijn in onderstaand schema weergegeven.
AT.1
Planning
AT.2 AT.3 AT.4 AT.5

Voorbereiding Specificatie Uitvoering Afronding
3.1 Fase: Planning

Het doel van de fase Planning is het in een testplan vastleggen hoe, door wie, waarmee,
wanneer, waar en tegen welke kosten de testactiviteiten uitgevoerd zullen gaan worden.
Tevens moet instemming worden verkregen van de stuurgroep voor de uitvoering van het
testtraject. De test wordt hiermee tot een onderdeel van de gehele ontwikkelingscyclus
gemaakt, waarmee formeel en daadwerkelijk rekening dient te worden gehouden.
5. inrichten
1. opdracht-
testorganisat ie
formulering
9. bepalen
begroting
2. globalest udie 3. vaststellen 4. bepalen 6. inrichten 8. inrichting 11. f ixatie

en int ake testbasis testst rategie testprodukten t est beheer acceptatietest-
plan
10. bepalen
planning
7. globaal ontwerp
testinfrast ruct uur

De fase planning start reeds tijdens de SDM-fase systeemontwerp. Door het testplan wordt
de basis gelegd voor een beheersbaar testtraject. Nadat de testopdracht gefixeerd is, moet
globaal kennis gemaakt worden met de beschikbare systeem- en projectdocumentatie, de
richtlijnen en de aan het systeem gestelde eisen m.b.t. functionaliteit en kwaliteit.
Voorbeelden van systeem- en projectdocumentatie zijn het Informatieplan, het Ontwerp
Administratieve Organisatie, het Systeemontwerp, de automatiseringsverwachting en het
overall projectplan. Vervolgens wordt, via een proces van risicoanalyse, de teststrategie
bepaald. Hierin wordt vastgesteld welke eigenschappen van het informatiesysteem worden
getest en met welke diepgang zal worden getest. Daarnaast worden in deze fase ook de
acceptatiecriteria vastgesteld en wordt een aanzet gegeven tot de inrichting van de
testorganisatie en de testinfrastructuur. Tenslotte wordt een globale planning opgesteld. Op
basis van de voorgaande activiteiten wordt het testplan samengesteld en gefixeerd.
Om te kunnen starten met deze fase dient reeds een start gemaakt te zijn met de fase
systeemontwerp. Tevens heeft de stuurgroep aan de projectgroep acceptatie opdracht
gegeven voor het uitvoeren van een test voor het betreffende informatiesysteem.
Het product van de fase Planning is het testplan. Voor de inhoud van een testplan wordt
verwezen naar hoofdstuk 7 Planning.
3.2 Fase: Voorbereiding

De fase Voorbereiding bevat alle activiteiten die benodigd zijn om vast te stellen, of de
testbasis van voldoende kwaliteit is voor het specificeren en uitvoeren van de testgevallen.
Dit wordt ook wel testbaarheid genoemd.
Op grond van een meer gedetailleerd inzicht in de testbasis is het eventueel noodzakelijk om
het testplan bij te stellen. Daarnaast vindt in deze fase het opleiden van de testmedewerkers
plaats.
2. detai l intake 3. defi ni r en 4. toew ij zen

test basi s t esteenheden testt echni eken
6. det ail pl anni ng

taak speci fi cati e
1. oplei den
testm edew erker s
5. specifi cer en
infr astruct uur
De fase Voorbereiding start zo vroeg mogelijk met het opleiden van de testmedewerkers die
betrokken zijn bij het testproces.
De daadwerkelijke werkzaamheden beginnen nadat de testbasis gefixeerd is en beschikbaar

is gesteld aan de projectgroep acceptatie. Fixatie houdt in dat de testbasis alleen nog via
formele versiebeleid procedures gewijzigd kan worden. Deze procedures zijn vastgelegd in
het testplan.

Als eerste activiteit vindt een detail intake plaats van de testbasis. Hierbij moet inzicht
verkregen worden in de testbaarheid, door de testbasis te onderzoeken op bijvoorbeeld
uniforme notatie, duidelijkheid, consistentie en volledigheid. Daarnaast wordt bij deze intake
getoetst op verwachtingen ten aanzien van de functionaliteit.
Na de intake wordt het informatiesysteem verdeeld in testbare eenheden (testeenheden) en

worden aan de onderkende testeenheden testtechnieken toegewezen. Dit alles, met de
teststrategie als uitgangspunt, die reeds eerder in het testplan is gedefinieerd.
Indien het systeem niet in zijn geheel, maar in delen ter acceptatie wordt aangeboden, is het
verstandig om de testbasis, in samenspraak met de begeleidingsgroep, onder te verdelen in
onafhankelijk op te leveren testeenheden. In dit geval is het raadzaam, op het moment dat
alle modules beschikbaar zijn, de integratie van de verschillende modules nog afzonderlijk te
testen.
Parallel aan deze subfases wordt de definitie van de testinfrastructuur, zoals vastgelegd in
het testplan, indien noodzakelijk omgezet in een detailspecificatie. Tenslotte wordt een
detailplanning gemaakt voor de fase Specificatie.
Alvorens met de fase Voorbereiding te kunnen starten moet de stuurgroep het testplan
hebben vastgesteld en moet de testbasis gefixeerd zijn.
De producten van de fase Voorbereiding zijn: behalve het opgeleiden van

testmedewerkers, een rapport met daarin de bevindingen m.b.t. de testbasis en een
testeenhedenmatrix met bijbehorende testtechnieken. Daarnaast is een detailspecificatie van
de testinfrastructuur gemaakt.
3.3 Fase: Specificatie

De fase Specificatie bevat alle activiteiten die benodigd zijn om de testgevallen te
specificeren en de bijbehorende testinfrastructuur te realiseren, teneinde een efficiënte en
effectieve uitvoering van de test te kunnen bewerkstelligen.
1. o p st el len 2 . d e f in i ër e n 3. o p st e ll en 4. o p st el le n
t est sp ecif ica t ie s u i t ga n g ssi t u at i es t est scr i p t s t est d r a ai b o ek
{XG " t est in f r a-
st r u ct u u r " }
6. d et a ilp l an n i n g
ta a k u i t vo e r in g
{X G " t e sti n f r a -
st r u ct u u r " }
5. r e al isat ie
t est in f r a st r u ct u u r
De creatie van testgevallen vindt plaats per testeenheid op basis van de gespecificeerde
testtechnieken. Nadat de testbasisbevindingen door de betreffende eigenaar verwerkt zijn,
worden de testgevallen afgeleid en vastgelegd in testspecificaties. Hierbij worden ook de
benodigde uitgangssituaties (van tabellen, databases of bestanden) bepaald. Bijvoorbeeld:
indien bij een bepaald testgeval een selectie plaatsvindt op de naam van een woonplaats
dan moet de bijbehorende tabel woonplaats gevuld zijn met één of meerdere plaatsnamen.

Vervolgens worden de logische testgevallen vertaald naar fysieke testgevallen in de vorm

van testscripts. Een testgeval moet beschouwd worden als de beschrijving van de
uitgangssituatie, het veranderingsproces en het voorspelde resultaat.
Tenslotte worden de, in de testspecificaties onderkende, testgevallen vertaald in concreet

uitvoerbare testacties en in een uitvoerbare volgorde in testscripts geplaatst. Ten behoeve
van de testuitvoering wordt een testdraaiboek opgesteld, waarin de testscripts in onderlinge
samenhang zijn weergegeven. Om de belangrijkste fouten als eerste op te sporen worden de
testscripts die betrekking hebben op de meest cruciale delen van het systeem in de
beginfase van de testuitvoering uitgevoerd. Welke de meest cruciale delen van het systeem
zijn is reeds eerder vastgelegd in de teststrategie.
Tijdens deze fase wordt ook de testinfrastructuur gerealiseerd. Daarnaast wordt een
detailplanning van de uitvoering opgesteld.
Alvorens met de fase Specificatie te kunnen starten moet de fase Voorbereiding zijn
afgerond en moeten de producten van deze fase beschikbaar zijn. Tevens moeten de
testbasisbevindingen uit de fase Voorbereiding verwerkt zijn.
De volgende producten zijn het resultaat van de fase Specificatie:

• Testbasisbevindingen;
• Testspecificaties;
• Testscripts;
• Testdraaiboek;
• Operationele testinfrastructuur.
3.4 Fase: Uitvoering

De fase Uitvoering bevat alle activiteiten die benodigd zijn om de in het testdraaiboek
gespecificeerde testen te confronteren met het testobject. De bedoeling is op deze wijze
inzicht te krijgen in de kwaliteit van het testobject.
1 . i n t ak e t es t - 2. o p b o u w 3 . ( h e r -) t e st - 4 . c o n t r o le r e n 5 . o n d e rh o u d e n
o b j e c t / i n t ak e u it g a n g s - u i t v o er i n g e n b e o o r d el e n t e st d r a a i b o e k
t e st i n f r a st r u c tu u r b e st a n d e n t e st r e s u l ta t e n
6 . vo o rt g a n g s-
ra p p o rt a g e
De daadwerkelijke uitvoering begint op het moment dat de eerste testbare systeemdelen van
het testobject wordt opgeleverd. Eerst worden (de opgeleverde systeemdelen van) het
testobject en de testomgeving gecontroleerd op volledigheid. Vervolgens worden de
opgeleverde systeemdelen van het testobject in de testomgeving geïnstalleerd.
De eerste test die wordt uitgevoerd, is de zogenaamde pré-test. In deze test worden alle
aanwezige systeemdelen globaal getest, met als doel te onderzoeken of het testobject in
samenhang met de testomgeving van voldoende kwaliteit is, om uitgebreid getest te kunnen
worden.

Bijvoorbeeld: Zijn (vanuit het menu) alle modules op te starten, loopt het systeem niet vast,
hebben de gebruikers voldoende rechten, etc.?
Als het geheel van afgesproken kwaliteit is, worden de initiële gegevensverzamelingen met
hun initiële waarden gevuld. Vervolgens worden de testscripts uit het testdraaiboek
uitgevoerd.
Tijdens de activiteit controleren en beoordelen testresultaten wordt onderzocht wat de

oorzaak is van de eventuele verschillen tussen de verwachte en daadwerkelijke resultaten.
De oorzaak kan een programmafout zijn, maar ook onduidelijkheden in de testbasis, fouten
in de testomgeving of foute testgevallen. De verschillen die veroorzaakt worden door
onduidelijkheden in de testbasis of functionele wijzigingen worden voorgelegd aan de
begeleidingsgroep en kunnen eventueel resulteren in een wijziging.
Bevindingen rapportage
Gedurende de testuitvoering, maar in sommige gevallen reeds tijdens de testvoorbereiding,
zullen diverse bevindingen worden gedaan. Een bevinding kan gedefinieerd worden als een
resultaat dat niet voldoet aan het verwachtte resultaat. Dit houdt overigens niet direct in dat
een bevinding altijd een probleem is. De bevinding wordt geregistreerd en geprioriteerd in
een “bevindingen database”. In een daartoe aangewezen overleg, ad-hoc dan wel
gestructureerd, worden de bevindingen besproken en de vervolgacties bepaald. Dit zal
kunnen leiden tot aanpassen van SO-product, hetgeen een hertest tot gevolg heeft.
Na herstel van de fouten worden de betreffende testen opnieuw uitgevoerd. Hierbij is een
goed versiebeheer van groot belang. In de procedure voor het beheer van het testobject,
wordt per versie beschreven, op welke wijze het ontwikkelteam de problemen heeft opgelost.
Deze procedure ligt vast in het testplan. Hoe vaak de cyclus van hertesten wordt herhaald
staat beschreven in het testdraaiboek. Dit om te voorkomen dat hertesten eindeloos worden
uitgevoerd en de planning daardoor niet wordt gehaald.
Opgemerkt wordt dat de fase Uitvoering de eerste activiteit is, die ligt op het kritieke pad van
de totale ontwikkelingscyclus van een informatiesysteem. Derhalve heeft de fase Uitvoering
invloed op de totale tijdsduur van de ontwikkelingscyclus.
Alvorens te kunnen starten met de fase Uitvoering moet de infrastructuur beschikbaar zijn
en één of meerdere systeemdelen zijn opgeleverd.
Het resultaat van de fase Uitvoering bestaat uit een rapportage van de testobjectbevindingen
en een aangepast testdraaiboek.
3.5 Fase: Afronding

De fase Afronding bevat een aantal verschillende activiteiten, namelijk:
• Het opstellen van een eindrapport met daarin een evaluatie van het testproces, evaluatie
van de kwaliteit van het testobject en een vrijgaveadvies aan de stuurgroep. De
stuurgroep kan op basis van dit eindrapport het (acceptatie)testeam en uiteindelijk ook de
projectgroep decharge verlenen en een beslissing nemen m.b.t. de acceptatie van het
informatiesysteem.
• Het verkrijgen van ervaringsgegevens ten behoeve van een betere planning en
beheersing van toekomstige testtrajecten. Deze ervaringsgegevens zijn een afspiegeling
van de resultaten van de test en geven daarmee inzicht in de kwaliteit van het testobject.

• Het conserveren van testware, welke gebruikt kan worden bij toekomstige
(onderhouds)testen van het betreffende informatiesysteem.
1. eva lu at ie 2 .ev a l u at i e 3 . o p s te l l en
t e st o b j e c t t e st p r o ce s e in d r ap p o r t
5 . d e ch ar g e
p r o j e ct g r o e p
a cc e p t a t i e
4 . co n se r v e r e n
t e st w a r e
Tijdens de fase Afronding wordt het testtraject geëvalueerd. Onderwerp van de evaluatie is
zowel de kwaliteit van het informatiesysteem als het testproces zelf.
Het doel van de evaluatie van de kwaliteit van het informatiesysteem is het leveren van
informatie die van belang is bij de beslissing of het informatiesysteem in z’n huidige vorm
wordt geaccepteerd. Het is raadzaam (lastig maar leerzaam), om hierbij ook een
kosten/baten analyse te maken.
Doel van de evaluatie van het testproces is om toekomstige testtrajecten beter te kunnen
plannen en beheersen. De evaluatie wordt besloten met een vrijgaveadvies en vastgelegd in
een eindrapport t.b.v. de stuurgroep.
Conservering vindt plaats indien de wens/behoefte bestaat om de tijdens de test gebruikte

testware in de toekomst te gaan hergebruiken. Bij conservering wordt uit de grote
hoeveelheid testware, zoals testgevallen, uitgangsbestanden, testresultaten en
beschrijvingen van de infrastructuur een selectie gemaakt. Het doel van de conservering van
de testware is, dat hier bij toekomstig onderhoud aan het informatiesysteem gebruik kan
worden gemaakt zonder dat compleet nieuwe testen dienen te worden ontworpen. Het
vereist een sterke discipline om tijdens het testtraject (en ook bij het onderhoud), de
testgevallen in overeenstemming te houden met de specificaties van het informatiesysteem.
Op het moment dat men erin slaagt om representatieve en overdraagbare testware te
ontwikkelen en te onderhouden, kan men spreken van de zogenaamde regressieve
testware.
Na evaluatie, opstellen van het eindrapport en eventuele conservering van de testware kan
de stuurgroep decharge verlenen aan de projectgroep acceptatie.
Alvorens met de fase Afronding te kunnen starten moet de fase Uitvoering volledig zijn
afgerond, waarbij besloten is om geen (her)testen meer uit te voeren.
Het belangrijkste product van de fase Afronding is het eindrapport met daarin een
risicorapportage, een vrijgaveadvies m.b.t. het informatiesysteem en een evaluatie van het
testtraject. Daarnaast kan testware zijn geselecteerd, gedocumenteerd en vastgelegd. Op
basis van deze producten zal de stuurgroep aan de projectgroep acceptatie décharge
verlenen.

Onderwerp Hoofdstuk 4 Organisatie Datum 05-01-2001
4. Organisatie
In dit hoofdstuk wordt de organisatie van het testen besproken. Achtereenvolgens komen
testfuncties, andere projectfunctionarissen, organisatiestructuur en communicatie aan de
orde.
4.1 Testfuncties
In een testproject worden de volgende functies onderkend:
Tester
De tester is verantwoordelijk voor de intake van de testbasis, het maken van de
testspecificaties en –scripts, uitvoeren van de testgevallen en conserveren van testware.
Testcoördinator
De testcoördinator is verantwoordelijk voor het goed afstemmen van de testwerkzaamheden
op de overige werkzaamheden in het project en geeft leiding aan het testteam. Hij verzorgt
de planning, voortgangs- en kwaliteitsbewaking en rapportage.
Testmanagement
Het testmanagement is vaak ingebed in de lijnorganisatie en verantwoordelijk voor het
beheersen van de kwaliteit van diverse testprojecten en voorziet deze van advies over de
uitvoering van de testwerkzaamheden.
Methodische ondersteuning
Deze functionaris ondersteunt testmanagement, testcoördinator en testers met betrekking tot
testtechnieken, testmethode en opleiding.
Technische ondersteuning
De testinfrastructuur wordt beheerd door de technische ondersteuning. Deze functionaris
ondersteunt de testers voor wat betreft de testinfrastructuur.
Functionele ondersteuning
Deze functionaris, vaak afkomstig uit de gebruikersorganisatie, ondersteunt de testers met
betrekking tot de functionaliteit van het testobject.
Beheerder bevindingen
Verantwoordelijkheden van deze functionaris zijn het registreren, beoordelen en routing van
ingaande en uitgaande bevindingen en oplossingen. Deze taken liggen soms bij de problem-
en changemanager.
Testbeheerder
Deze functionaris voert het beheer uit over het testproject (soms is dit belegd bij de
testcoördinator), de testinfrastructuur (soms belegd bij de technische ondersteuning) of de
testware (soms belegd bij de testcoördinator)
Testtoolbeheerder.
Deze functionaris is verantwoordelijk voor het realiseren, gebruik, beheer en opleiding van
het testtool.

Testprocedures
Hier liggen de verantwoordelijkheden voor het tot stand brengen, het vaststellen,
implementeren en beheren van de testvoorschriften. Deze taak is soms van de
testcoördinator of testmanager.
Controle
Hier vindt de toetsing plaats op naleving van de testvoorschriften. Dit kan een functionaris
buiten of van binnen het testproject zijn.
4.2 Betrokken disciplines

Testen vormt vaak een onderdeel van een project of is ingebed in de beheerorganisatie. Het
testteam kan met de volgende functionarissen in aanraking komen:
Opdrachtgever
De functionaris of het organisatieonderdeel dat opdracht heeft gegeven voor het uitvoeren
van het testtraject. De opdrachtgever formuleert de opdracht aan het testteam en is degene
aan wie gerapporteerd wordt over voortgang en uitkomsten van het testtraject.
Bij de systeemtest is de projectleider van het realisatietraject vaak de opdrachtgever, bij de
acceptatietest is het management van de gebruikersorganisatie vaak de opdrachtgever.
Stuurgroep
De stuurgroep bestaat vaak uit management gebruikersorganisatie, beheerorganisatie en de
projectleiding van het realisatietraject. De stuurgroep is vaak functioneel verantwoordelijk en
staat boven de verschillende partijen die bij een project betrokken zijn. Het komt voor dat de
stuurgroep opdrachtgever is. In sommige gevallen zit de testmanager of –coördinator ook in
de stuurgroep.
Gebruikersorganisatie
De gebruikersorganisatie zijn de medewerkers en management die uiteindelijk met het
systeem gaan werken. Hun primaire proces wordt ondersteund door het systeem. Vaak
hebben deze medewerkers een bijdrage in het expliciet maken van de functionaliteit. Bij
sommige testtrajecten wordt de gebruikersorganisatie ingezet om het testen uit te voeren. In
dat geval dienen de testscripts wel uitgewerkt te zijn.
Projectmanagement
De leiding van het realisatietraject. In sommige organisaties heeft het projectmanagement de
leiding over zowel opdrachtgevers- als opdrachtnemers kant van het project. Het kan ook dat
bij de opdrachtgever en bij de opdrachtnemer een afzonderlijk projectmanagement zit.
Het projectmanagement kan opdrachtgever zijn; bij de systeemtest het projectmanagement
van de opdrachtnemer, bij de acceptatietest van de opdrachtgever. Het projectmanagement
is altijd bijzonder geïnteresseerd in de resultaten van de test. Hierbij is het van belang dat de
kwaliteit (juistheid en volledigheid) van de rapportage van hoog niveau is. Indien de realisatie
van de doelstellingen van het testteam in gevaar komen (bijvoorbeeld als niet iedereen
meewerkt) zijn de opdrachtgever en het projectmanagement de organisatieonderdelen die
hierover ingelicht dienen te worden.
DBA
Database-administration is verantwoordelijk voor het opzetten, onderhouden en beheren van
de databases. Omdat het testteam over minimaal 1 omgeving (database plus
programmatuur) dient te beschikken om de test uit te kunnen voeren. DBA stelt deze
omgeving over het algemeen beschikbaar en is daarom een belangrijke partner van het
testteam.

DBA is over het algemeen ook de eerste partij waarmee problemen in de testomgeving
worden besproken.
Implementatie
Het implementatieteam is het eerste team dat na het testteam met het ontwikkelde of
aangepaste systeem aan de slag gaat. De werkzaamheden van het implementatieteam
starten al tijdens de testvoorbereiding.
Daar de exacte functionaliteit en werking van het systeem helder dienen te zijn bij het
implementatieteam, is zij over het algemeen geïnteresseerd in de uitkomsten van de test.
Het beschikbaar stellen van deze uitkomsten, dient wel met toestemming van de
opdrachtgever te gebeuren.
Het komt voor dat het implementatieteam gebruik wil maken van de kennis van het systeem
opgebouwd bij het testteam of van de producten die gemaakt zijn door het testteam.
Voorbeeld van dit laatste zijn testscripts ten behoeve van opleiding. Geef hier in
samenspraak met de opdrachtgever invulling aan, zeker als het tijd kost van het testteam.
Functioneel ontwerper
De functioneel ontwerper heeft, over het algemeen samen met de gebruikersorganisatie, in
detail bepaald hoe de functionaliteit eruit gaat zien en gaat werken. Indien er onduidelijkheid
is over de werking of de verschijningsvorm van het systeem, is de functioneel ontwerper de
eerste aan wie deze vragen gesteld kunnen worden.
Het kan ook nuttig zijn om de functioneel ontwerper de nieuwe onderdelen dan wel
aanpassingen te demonstreren.
Bouwer / ontwikkelaar
De bouwer / ontwikkelaar realiseert het systeem. Hij vertaalt het ontwerp in het systeem.
Feitelijk wordt door de tester vastgesteld of dit correct is gebeurd, daar het functioneel
ontwerp over het algemeen als testbasis wordt gebruikt.
Bevindingen worden in eerste instantie met de ontwikkelaar besproken, daar hij/zij de
meeste zicht heeft op de mogelijke oorzaken.
Ontwikkelaars kunnen minder positief reageren op testers, omdat zij hun product
beoordelen. Het is raadzaam duidelijk te maken dat je gezamenlijk aan hetzelfde doel werkt;
de totstandkoming van een kwalitatief goed product. Daarnaast is het beter dat de tester de
bevinding doet dan dat deze bij in productie name nog in het systeem zit (zie hoofdstuk
2.4.2).
4.3 Organisatorische inbedding

Acceptatietestteams zijn over het algemeen niet ingebed in de organisatie. Het is een apart
team dat als een projectteam tijdelijk naast de normale lijn functioneert.
Het systeemtestteam maakt vaak onderdeel uit van het projectteam dat verantwoordelijk is
voor de realisatie van het systeem.

De organisatie van het realisatietraject ziet er over het algemeen als volgt uit:
Stuurgroep
Project-
management
Functioneel Realisatie Database Testen Implementatie

ontwerp administration
De organisatie van het testteam ziet er alsvolgt uit:
Test-
coördinator
Technische Methodische
ondersteuning ondersteuning
Tester
Tester
Tester
Het kan voorkomen dat de methodische ondersteuning niet ingevuld is of geen onderdeel
uitmaakt van het testteam maar in de lijnorganisatie is ingebed. De methodisch
ondersteuner, soms de testmanager, verleent dan diensten aan het testteam.
Het komt ook voor dat de technische ondersteuning niet in het testteam opgenomen is, maar
dat een ander team zoals het DBA dit verzorgt. Het is dan van belang dat goede afspraken
worden gemaakt over de ondersteuning.
4.4 Communicatie
Testen is geen op zichzelf staande activiteit. Communicatie en afstemming met de andere
participanten (zie 4.2) is van groot belang. De volgende overlegvormen kennen we rond het
testteam:

Testteamoverleg
Overleg onder voorzitterschap van de testcoördinator met de testers over voortgang,
problemen bij de voortgang, werkverdeling en dergelijke.
Projectteamoverleg
Overleg tussen de verschillende teamleiders binnen het realisatieteam, soms ook met
(vertegenwoordigers van) de opdrachtgever erbij. Onderwerpen zijn voortgang van het
project, problemen bij de voortgang, aansluiting van de werkzaamheden van de
verschillende team en dergelijke. Vaak is dit het eerste escalatieniveau bij problemen binnen
het project.
Bevindingenoverleg
Overleg met tester(s), functioneel ontwerpers, bouwers en eventueel gebruikers over de
nieuwe bevindingen en de status van de oude bevindingen.
Stuurgroepoverleg
Overleg van de stuurgroep, waarin de testcoördinator soms ook voor uitgenodigd wordt.
Over het algemeen gaat het in die gevallen over de voortgang en status van het systeem.
Testmanagementoverleg
Overleg tussen de testmanager en de verschillende testcoördinatoren binnen een
organisatie. Doel is vaak van elkaars activiteiten op de hoogte te zijn en van elkaar te leren.
4.5 Kennis en vaardigheden van een tester
1. Kennis van gestructureerd testen.

Een tester dient kennis van en bij voorkeur ervaring met gestructureerd testen te hebben. Hij
is in staat met behulp van de testtechnieken gestructureerde testspecificaties en testscripts
op te stellen. Daarnaast heeft een tester inzicht in het testproces. Een testcoördinator dient
in staat te zijn een testproces gestructureerd in te kunnen richten en leiding te kunnen geven
aan een testteam.
2. Kennis van de gebruikte technische omgeving.

De tester dient in staat te zijn om met de technische omgeving te kunnen werken. Hierbij kan
gedacht worden aan het vullen van de testdatabase, opstarten van jobs, lezen van logfiles
en dergelijke.
3. Algemene automatiseringskennis
De tester heeft kennis van diverse automatiseringsprocessen, zoals systeemontwikkelings-
processen, beheersprocessen, kwaliteitszorgprocessen en projectmanagementprocessen.
Daarnaast kan hij/zij overweg met de tussenproducten die bij automatiseringstrajecten
worden gecreëerd.
4. Goede communicatieve vaardigheden.

Omdat een tester met diverse partijen samenwerkt en omdat het vinden van fouten en
confronteren van de maker met de fouten soms moeilijk ligt, dient de tester over goede
communicatieve vaardigheden te beschikken.
5. Materiekennis.

De tester dient ook inzicht te hebben van het onderliggende systeem en hetgeen met het
systeem gedaan wordt. Gebruikers hebben deze kennis in hoge mate, externe testers
dienen deze kennis op te doen door het bestuderen van de organisatie, de werkwijze en het
functioneel ontwerp.

Onderwerp Hoofdstuk 5. Infrastructuur Datum 05-01-2001
5. Infrastructuur
De infrastructuur omvat alle middelen en faciliteiten die nodig zijn om het testtraject uit te
kunnen voeren. De infrastructuur wordt onderverdeeld in:
• Testomgeving;
• Initiële gegevensverzameling;
• Testtools;
• Kantoorinrichting.
De testomgeving en de initiële gegevensverzameling worden in dit hoofdstuk verder

uitgewerkt, testtools wordt verder uitgewerkt in hoofdstuk 13 van dit handboek.
5.1 Testomgeving
De testomgeving omvat alle technische benodigdheden om te kunnen testen. Dit omvat dus
de hardware, software, communicatiemiddelen en procedures. De software is onder te
verdelen in systeemsoftware, applicatiesoftware en database.
Over het algemeen zijn er bij automatiseringsprojecten de volgende omgevingen:
• Ontwikkelomgeving;
• Systeemtestomgeving;
• Acceptatietestomgeving;
• Productieomgeving.
Daarnaast is er een aantal belangrijke procedures ten behoeve van het beheer van de
omgevingen.
5.1.1 Omgevingen
Ontwikkelomgeving
In de ontwikkelomgeving realiseren de ontwikkelaars de programmatuur en voeren de
ontwikkelaars de programmatest en integratietest uit. Deze omgeving is over het algemeen
een zogenaamde laboratoriumomgeving; de ontwikkelaars hebben alle vrijheid deze
omgeving naar eigen inzicht in te richten en zij mogen ook alles hierin doen.
Systeemtestomgeving
De systeemtestomgeving wordt gebruikt om de systeemtest uit te voeren en is dus de
verantwoordelijkheid van de systeemtestcoördinator. De systeemtestomgeving is over het
algemeen de eerste omgeving waar het complete systeem met alles erop en eraan
functioneert. Als gevolg hiervan ontstaan wellicht integratieproblemen.
Acceptatietestomgeving
De acceptatietestomgeving dient (zo veel mogelijk) gelijk te zijn aan de productieomgeving.
Het komt voor dat een applicatie in de acceptatietestomgeving foutloos werkt, maar in de
productieomgeving wel fouten vertoont. Dan zijn deze omgevingen dus niet aan elkaar gelijk.
Feitelijk dient de acceptatietestomgeving een “als-ware-het-productie” te zijn.
Het acceptatietestteam is eigenaar van de acceptatietestomgeving en is dus
verantwoordelijk voor het beheer.
Productieomgeving
In de productieomgeving draait het systeem werkelijk en werken de gebruikers ermee. Deze
omgeving wordt beheerd door de beheerorganisatie. Om redenen van privacy en
bedrijfszekerheid dient deze omgeving geheel afgeschermd te zijn van de programmeurs en
testers.

5.1.2 Eisen aan testomgevingen
• Representatief
De testomgeving dient zoveel mogelijk overeen te komen met de productieomgeving.
Dit geldt voor zowel de systeem- als de acceptatietest. Indien er verschillen zijn tussen
de testomgeving en de productieomgeving, kan de situatie zich voordoen dat in de
testomgeving de applicatie foutloos werkt maar in productie toch storingen optreden.
De representativiteit heeft betrekking op alles ten aanzien van de omgeving (zoals
systeemsoftware, middleware, databasetechnologie, beveiligingsmaatregelen en
communicatiemiddelen).
• Stabiel
Indien de testomgeving niet stabiel is, kan dit de werkzaamheden van het testteam
verstoren. Vooral in de beginfase van de bouw van nieuwe applicaties kan het zich
voordoen. Bij storingen in de testomgeving worden de werkzaamheden van het
testteam bovendien verstoord (in de uitvoeringsfase), waardoor de planning onder
druk komt te staan.
• Aanpasbaar
Het kan voorkomen dat bepaalde onderdelen van de applicatie verstorend werken
omdat zij fouten bevatten. Ook kan het zijn dat andere onderdelen van de
testomgeving, zoals beveiligingsmaatregelen of autorisaties, het testen verstoren. Het
dient dan mogelijk te zijn om de testomgeving, eventueel tijdelijk, zo aan te passen
dat de test optimaal voortgang kan vinden. Ook dient het mogelijk te zijn dat delen
van de applicatie snel maar beheerst kunnen worden geïnstalleerd, verwijderd en
vervangen.
• Meerdere omgevingen
Als er meerdere testers zijn, kan het efficiënt zijn dat er meerdere testomgevingen
zijn, zodat de werkzaamheden van de ene tester de werkzaamheden van de andere
tester niet verstoren. Denk hierbij aan het gebruik van gegevens, het veroorzaken van
een “system-hang” door een tester en dergelijke.
• Manipuleerbare systeemdatum
Het kunnen manipuleren van de systeemdatum kan relevant zijn als berekeningen of
manipulaties afhankelijk daarvan zijn. Als bijvoorbeeld de leeftijd van een persoon
invloed heeft op de uitkering en de leeftijd wordt berekend aan de hand van het
verschil tussen geboortedatum en systeemdatum, veranderd de leeftijd als de
systeemdatum niet manipuleerbaar is. Als gevolg hiervan kan de uitkering dus ook in
de tijd veranderen.
De manipuleerbare systeemdatum kan ook handig zijn om snel een situatie voor en na
een bepaalde datum te kunnen testen.
• Backup / recovery
Als een tester bevindingen doet, is het van belang dat hij de situatie van voor de
bevinding kan reconstrueren. Dit kan door het backup-en van de beginsituatie en later
het herstellen van deze situatie. Ook kan het voorkomen dat een nieuwe release van
de programmatuur meer fouten bevat of dat oude onderdelen van de programmuur
beter samenwerken dan aangepaste. Dan is het handig als de oude programmatuur
geïnstalleerd kan worden
• Uitwijkmogelijkheden

Het kan zich voordoen dat de complete testomgeving uitvalt. Dit vertraagt de voortgang
van het testtraject. Als er dan uitwijkmogelijkheden zijn, kan deze vertraging
geminimaliseerd worden.
5.1.3 Procedures
Opleverprocedures
Verschillende project- of organisatieonderdelen zijn eigenaar van omgevingen. Deze
omgevingen worden beheerd door verschillende functionarissen. Daarom is het van belang
dat alleen de daartoe geautoriseerde personen werkzaamheden in hun omgevingen
verrichten, niemand zomaar de database kan wijzigen of programmatuur kan installeren of
weghalen.
Om dit proces goed te beheersen zijn er zogenaamde opleverprocedures. In deze
procedures staan hoe onderdelen van de applicatie door wie beschikbaar wordt gesteld, hoe
de overdracht en installatie plaatsvindt en wat welke functionaris in de overdrachtprocedures
voor activiteiten onderneemt.
De inhoud van de overdrachtprocedures zijn sterk afhankelijk van het ontwikkelplatform en
de organisatie.
Versiebeheer
Het komt vaak voor dat de programmeurs aan een nieuwe versie bezig zijn, terwijl er nog
bevindingen liggen met betrekking tot eerdere versies. De systeemtesters zijn die eerdere
versies aan het testen en de acceptatietesters mogelijk nog een andere versie. De versie in
productie is de laatste goedgekeurde versie, dus die is zeker niet in ontwikkeling of test.
Het is voor alle betrokkenen van belang te weten welke functionaliteiten in welke versie op
welke manier werkt, welke bevindingen in welke versie zijn opgelost, op welke versie welke
bevindingen betrekking heeft en dergelijke.
Om dit proces goed te beheersen dient versiebeheer ingericht te zijn. Binnen het
versiebeheer is opgenomen welke versies van de software er zijn, wat de inhoud en de
status van de versie is, is bijvoorbeeld aangegeven welke bevindingen in welke versie zijn
opgelost et cetera.
Het ontbreken of slecht functioneren van versiebeheer is vaak een bron van problemen in
projecten.
De inhoud van de versiebeheer is sterk afhankelijk van het ontwikkelplatform en de
organisatie.
Bevindingenprocedure
Deze procedure lijkt misschien op het eerste oog niet zo veel met testomgevingen te maken
hebben. De handeling van bevindingen heeft echter zeer veel impact op versiebeheer en
overdrachtsprocedures.
De overdrachtsprocedure geeft in ieder geval antwoord op de volgende vragen:
• Wie mag bevindingen vastleggen;
• Hoe worden de bevindingen vastgelegd;
• Wie beoordeelt de bevindingen;
• Hoe gaat de bevinding door de organisatie en wie mag er wat mee doen;
• Wie beheerst de loop van bevindingen.

De samenhang tussen de verschillende omgevingen en de procedures kan als volgt worden

weergegeven:
Versiebeheer
Systeem- Acceptatie
Ontwikkel Productie
test test
omgeving omgeving
omgeving omgeving
Opleverprocedures
Bevindingenprocedure
5.2 Initiële gegevensverzameling

De initiële gegevensverzameling omvat alle gegevens die in de database aanwezig dienen te
zijn om de test uit te kunnen voeren. Deze gegevens dienen exact aan te sluiten op de
testscripts. Als bijvoorbeeld getest wordt of meneer Jansen een uitkering krijgt, dienen de
gegevens van meneer Jansen, geheel conform de testspecificatie, in de database te zitten.
Naast dynamische gegevens, zoals klantgegevens, kunnen er ook vaste gegevens zoals
codetabellen of prijstabellen zijn. Deze gegevens behoren ook tot de initiële
gegevensverzameling.
In de testspecificaties wordt vastgesteld welke fysieke gegevens in de database dienen te
zitten om het betreffende testscript uit te kunnen voeren. De initiële gegevensverzameling
omvat alle gegevens uit alle testspecificaties.
De initiële gegevensverzameling kan op meerdere manieren worden opgebouwd:

• Opbouw met behulp van reguliere systeemfuncties;
• Opbouw met behulp van laadprogrammatuur;
• Conversie van productiegegevens.
5.2.1 Opbouw met behulp van reguliere systeemfuncties

Bij deze methode wordt de te testen applicatie zelf gebruikt om de database op te bouwen.
Met behulp van de invoer functie worden de gegevens stuk voor stuk ingevoerd.
Voordelen:
• De invoerfunctie is direct getest;
• De integriteit van de gegevens is gewaarborgd (mits de applicatie goed functioneert).
Nadelen:
• Langzaam;
• Arbeidsintensief. Bij een groot aantal gegevens kost het veel inspanning, zeker als er
sprake is van meerdere testrondes en meerdere malen terug gekeerd moet worden
naar de situatie van voor dat een fout optrad.

5.2.2 Opbouw met behulp van laadprogramma’s

Laadprogramma’s zijn programma’s waarmee vooraf gedefinieerde gegevens geladen
kunnen worden in een database. In sommige gevallen worden dit soort programma’s
meegeleverd bij de databaseprogrammatuur of zijn deze eenvoudig te programmeren in de
betreffende database- of ontwikkelsoftware. Met behulp van dit programma wordt een
bestand gemaakt dat geladen kan worden in de database. Bestaat dit bestand eenmaal, dan
kan dit meerdere keren worden gebruikt.
Het is soms ook mogelijk om gegevens te “uploaden”. In dat geval worden de gegevens in
een editor of een ander programma, zoals Excel of Access, ingebracht en deze kunnen dan
worden geconverteerd naar de database.
Het kan ook voorkomen dat de gegevens direct via commando’s in de database ingebracht
worden zodat een kopie van de database bewaard blijft.
Voordelen:
• Eén keer definiëren, meerdere keren gebruiken.
• Het arbeidsintensieve deel kan in de specificatiefase plaatsvinden, waardoor tijdens de
testuitvoering minder tijd nodig is voor het creëren van de testdatabase.
Nadelen:
• Een extra programma of handeling, met de bijbehorende kennis, is nodig.
• Door het gebruik van laadprogramma’s kunnen fouten zitten in de databasevulling. De
databasevulling zal daarom eerst gecontroleerd dienen te worden voordat de test
uitgevoerd kan worden. Fouten in de testdatabase leiden namelijk over het algemeen
tot fouten in de test.
5.2.3 Conversie van productiegegevens
De productiegegevens kunnen gebruikt worden als vulling van de testdatabase door (een
deel van) de productiegegevens te kopiëren. Het kopiëren (ook wel maken van een extract
genoemd) kan overigens wel het nodige werk met zich meebrengen.
Voordelen:
• Geen fictieve maar waarheidsgetrouwe gegevens;
• Kan leiden tot een snelle en juiste vulling van de database.
Nadelen:
• De databasevulling sluit soms niet aan op de testgevallen. Er moet maar afgewacht
worden of net dat geval dat als testgeval is gedefinieerd ook is de testdatabase zit. Bij
een nieuwe vulling van de database zitten er ook weer andere gegevens in en kan het
dus voorkomen dat het zoeken van het juiste geval weer opnieuw plaats moet vinden;
• Er is geen zekerheid over de dekkingsgraad;
• Productiegegevens zijn dynamisch en dus aan verandering onderhevig. Het kan dus
zijn dat een bepaald testgeval vroeger goed bruikbaar was, maar nu niet meer;
• Het kan in strijd zijn met de privacy wetgeving.
Het testen van een batchprogramma door middel van het laden van (een deel van) de
productiegegevens kan een zeer goede aanvulling zijn op de functionele test, het geeft
echter geen zekerheid over de dekkingsgraad; zijn alle mogelijke verwerkingen getest?

Onderwerp Hoofdstuk 6. Technieken Datum 05-01-2001
6. Technieken
Tijdens het de verschillende fases van het gestructureerd testen wordt gebruik gemaakt van
diverse technieken. In dit hoofdstuk worden de technieken opgesomd en kort toegelicht.
Indien de techniek later in het handboek wordt besproken, wordt dit aangegeven.
6.1 Fase Planning
• Strategiebepaling
Tijdens de fase planning wordt de teststrategie bepaald. De teststrategie geeft aan
welke onderdelen van de applicatie met welke technieken in welke tijd getest gaat
worden. De teststrategie mondt uit in de testbegroting, dit is de basis voor de
beheersing van het testproces. Deze techniek wordt verder uitgewerkt in bijlage 1.
• Functiepuntanalyse
Functiepuntanalyse geeft inzicht in de grootte van het systeem. De functiepunttelling
kan gebruikt worden bij het opstellen van de teststrategie en –begroting.
• Diverse checklists
- Checklist globale bestudering informatiesysteem;
- Checklists kwaliteitsattributen;
- Checklist randvoorwaarden en uitgangspunten;
- Checklist risico’s testproject;
- Checklist structurering;
- Checklist testfaciliteiten.
6.2 Fase Voorbereiding
• Detailintake testbasis
Tijdens de detailintake wordt een oordeel gevormd over de testbaarheid van de
specificaties en de overige documentatie. Deze techniek wordt verder uitgewerkt in
paragraaf 8.2.
• Inspectie
De inspectie is een formele gestructureerde methode om met een aantal betrokkenen
onder begeleiding van een procesbegeleider producten te beoordelen en
verbetersuggesties aan te dragen. De inspectie kan worden ingezet ten behoeve van
de detailintake van de testbasis.
- Checklist testbaarheid;
- Checklists testspecificatietechnieken (algoritmetest, beslissingstabellentest,
dataflowtest, elementaire vergelijkingentest, error guessing,
gegevenscyclustest, programmainterfacetest, procescyclustest, real-life test,
semantische test, syntactische test);
- Checklist black-box test;
- Checklist white-box test.
6.3 Fase Specificatie
• Testspecificatietechnieken

Onderwerp Hoofdstuk 6. Technieken Datum 05-01-2001
Een testspecificatietechniek is een gestandaardiseerde manier om vanuit

uitgangsinformatie testgevallen af te leiden. Er zijn diverse technieken met allemaal
hun eigen doel aan kwaliteitsattribuut. Deze techniek wordt verder uitgewerkt in
hoofdstuk 13.
6.4 Fase Uitvoering

- Checklists kwaliteitsattributen;
- Checklist vrijgave productie.
6.5 Fase Afronding

- Checklist evaluatie testproject.

Onderwerp Hoofdstuk 7. Fase Planning Datum 05-01-2001
7. Fase Planning
5. inrichten
1. opdracht-
testorganisat ie
formulering
9. bepalen
begroting
2. globalest udie 3. vaststellen 4. bepalen 6. inrichten 8. inrichting 11. f ixatie

en int ake testbasis testst rategie testprodukten t est beheer acceptatietest-
plan
10. bepalen
planning
7. globaal ontwerp
testinfrast ruct uur
Een samenvatting van deze taak staat in hoofdstuk 3.
7.1 Opdracht formulering
Doelstellingen
• Vastleggen wie opdrachtgever én opdrachtnemer is;
• Bepalen wat het beschouwingsgebied is;
• Bepalen wat het doel van het testtraject is;
• Inventariseren van de randvoorwaarden en uitgangspunten.
Basismateriaal
• Opdrachtverstrekking;
• Informatieplan (indien aanwezig);
• Informatie-analyse rapport;
• Plan van aanpak systeemontwerp;
• Systeemontwerp rapport;
• Plan van aanpak realisatie (indien aanwezig).
Producten
• De opdrachtformulering vastgelegd in het testplan.
Subtaken
De onderstaande zaken worden bepaald en vastgelegd:
• Wie is opdrachtgever;
• Wie is opdrachtnemer;
• Wat is het beschouwingsgebied;
• Wat is het doel van de test;
• Wat zijn de randvoorwaarden en uitgangspunten.
Technieken
• Geen specifieke technieken.
Toelichting
Randvoorwaarden zijn voorwaarden waaraan voldaan moet zijn, wil het beoogde doel ooit
bereikt kunnen worden. Zij liggen over het algemeen op het terrein van limieten en
voorwaarden met betrekking tot benodigde middelen, mensen, budget en tijd.

Uitgangspunten zijn beginpunten waarmee de testproject van start gaat. Uitgangspunten

worden door het testproject aan derden opgelegd. Uitgangspunten worden door de
projectgroep acceptatie zelf bepaald.
7.2 Globale studie en intake
Doelstellingen
• Verkrijgen van inzicht in:
- De beschikbare systeem- en projectdocumentatie;
- De aan het informatiesysteem gestelde eisen met betrekking tot functionaliteit en
kwaliteit;
- De organisatie van het ontwikkeltraject;
- De kennis en de ervaring van de organisatie m.b.t. testen;
• Het leggen van een basis voor het testplan.
Basismateriaal
• Systeem- en projectdocumentatie;
• Informatie van betrokken medewerkers.
Producten
• Informatiemap.
Subtaken
Bij de onderstaande subtaken zijn de volgende aspecten van belang:
• De bedrijfsdoelstelling van de dienst of directie;
• De kennis en de ervaring m.b.t. testen binnen de dienst of directie;
• De eventuele problemen die van invloed kunnen zijn op het testtraject;
• De formele en informele doelstellingen zoals bijvoorbeeld opdracht of strategisch belang;
• Informatie betreffende de projectorganisatie zoals bijvoorbeeld structuur, bevoegdheden,
verantwoordelijkheden, rapportage lijnen, versiebeleid en -beheer, personele bezetting,
planning of budgetten;
• Project risico-analyse;
• Historie: hoe is het project tot op dit moment verlopen?
Subtaak 1: Bestudeer beschikbare documentatie

De relevante documentatie die beschikbaar is, wordt bestudeerd. Hierbij valt te denken aan:
• Producten uit de fasen informatie-analyse en systeemontwerp;
• Projectdocumentatie zoals de plannen van aanpak systeemontwerp en realisatie,
organisatieschemas en functiepunttellingen;
• Eventuele relaties en koppelingen met andere informatiesystemen;
• Het contract c.q. de afspraken met het (externe) ontwikkelteam betreffende de fase
systeemontwerp en, indien al aanwezig, voor de fase realisatie;
• Standaards en richtlijnen;
• Het testdossier (bij een onderhoudstest);
• Resultaten en ervaringsgegevens uit andere testtrajecten binnen de organisatie,
bijvoorbeeld vastgelegd in eindrapporten.
Subtaak 2: Interview betrokkenen

Degenen die bij het ontwikkelingstraject betrokkenen zijn, worden geïnterviewd. Denk hierbij
aan:
• De opdrachtgever;

• Materiedeskundigen uit de gebruikersorganisatie;

• De projectleider van het ontwikkelteam;
• De (toekomstige) verwerkingsorganisatie.
Technieken
Toelichting
De resultaten van de studie en de interviews worden samengevat en vastgelegd in de
informatiemap. Deze informatiemap kan door de leden van de projectgroep acceptatie
gebruikt worden om een globale indruk van het informatiesysteem en het project te krijgen.
Dit is vooral van belang, omdat tijdens het testtraject de samenstelling van de projectgroep
acceptatie aan veranderingen onderhevig kan zijn. Verder is de informatiemap een basis
voor het testplan. De informatiemap is geen onderdeel van het testplan maar een
afzonderlijk document.
De hoofdstuk indeling van de informatiemap is als volgt:

1. Organisatie en materie
2. Project
3. Informatiesysteem
7.3 Vaststellen testbasis
Doelstellingen
• Het eenduidig definiëren van de testbasis en de uitgangsdocumentatie.
Basismateriaal
• Systeem- en projectdocumentatie.
Producten
• Een beschrijving van de testbasis en uitgangsdocumentatie vastgelegd in het testplan.
Subtaken
Subtaak 1: Bepalen relevante documentatie

Om een test goed te kunnen uitvoeren en te kunnen voldoen aan de opdracht, moet bekend
zijn, aan welke eisen met betrekking tot functionaliteit en kwaliteit het informatiesysteem
dient te voldoen. Alle documentatie, waarin deze eisen zijn beschreven, wordt opgenomen in
de testbasis. Alle overige documentatie die met name gebruikt wordt voor het
planningsproces, vormt de uitgangsdocumentatie. Hierbij valt te denken aan:
• Planningen van de leveranciers van de testbasis, het testobject en de infrastructuur;
• De beschikbaar gestelde en bestudeerde documentatie.
Subtaak 2: Identificeren documentatie

De identificatie van de relevante documentatie wordt vastgesteld. Hierbij wordt gedacht aan
identificatie, versie nummers, data, documenteigenaar en status.
Technieken

Toelichting
De testbasis wordt gevormd door de producten waaruit eisen zijn af te leiden die aan het
informatiesysteem worden gesteld. De identificatie van deze producten dient op voorhand
eenduidig te worden vastgelegd. Dit om te voorkomen dat gedurende het testen telkens
nieuwe documenten aan de testbasis worden toegevoegd, waarmee ook de testinspanning
doorlopend wordt vergroot, zodat een niet beheersbare situatie ontstaat.
Als het testproject betrekking heeft op een onderhoudstest moet een onderzoek uitgevoerd
worden naar de eventuele aanwezigheid van bestaande testware voor het betreffende
testobject. Onder testware moet men o.a. verstaan:
• Testspecificaties, -scripts, en testdraaiboek;
• Beschrijving testinfrastructuur, tools, organisatie;
• Statistieken.
Gebruik alleen testware die actueel en bruikbaar is !
N.B. Alvorens bovengenoemd onderzoek naar testware uit te voeren, moet men een
inschatting maken van de voor dit onderzoek benodigde tijd en zich afvragen of de
inspanning opweegt tegen het verwachte resultaat. Of dat men beter opnieuw testware kan
gaan ontwikkelen.
Beschrijf in de testbasis alleen documenten die van belang zijn voor het testtraject !
Het is raadzaam dat de beheerder alle onderdelen van de testbasis afdrukt en op één
centrale plaats beheert en archiveert. Op deze wijze is de testbasis op eenvoudige wijze
toegankelijk voor alle leden van de projectgroep acceptatie. Tevens wordt voorkomen dat
verschillende versies van de testbasis in omloop zijn.
7.4 Bepalen teststrategie
Doelstellingen
• Bepalen wat, op welke wijze en met welke diepgang getest gaat worden. In feite vindt
optimalisatie plaats, met het doel de beschikbare resources op de juiste wijze te verdelen
over de uit te voeren testactiviteiten.
Basismateriaal
• Testtechnieken.
Producten
• De teststrategie vastgelegd in het testplan.
Subtaken
Voor de stappen die gezet worden voor het opstellen van een teststrategie wordt verwezen
naar bijlage 1.
7.5 Inrichten testorganisatie
Doelstellingen
• Vaststellen van de wijze waarop de testorganisatie wordt ingericht: functies, taken,
bevoegdheden, verantwoordelijkheden, overlegstructuren en rapportagelijnen;

• Bepalen of opleidingen noodzakelijk zijn.
Basismateriaal
• Inzicht in de (project)organisatie.
Producten
• Beschrijving van de testorganisatie vastgelegd in het testplan.
Subtaken
Subtaak 1: Bepalen benodigde testfuncties

Bepaal welke mogelijke testfuncties dienen te worden ingevuld om de test naar behoren te
kunnen uitvoeren. Onderstaande testfuncties zijn veelal van belang bij het inrichten van een
testproces:
• Projectleider (testmanagement);
• Testers;
• Testdeskundige;
• Technische ondersteuning;
• Beheer.
Subtaak 2: Toewijzen taken, bevoegdheden en verantwoordelijkheden

Aan de testfuncties worden de specifieke taken, bevoegdheden en verantwoordelijkheden
toegewezen en beschreven. De taken zijn uiteraard gerelateerd aan de (sub)taken in het
testtraject. De bevoegdheden en verantwoordelijkheden hebben betrekking op de te nemen
beslissingen binnen het testproces. Bijvoorbeeld:
• Het onderhouden van het testplan;
• Het opstellen, respectievelijk bijstellen, van (detail)planningen;
• Het opstellen van een voortgangsrapportage;
• Goedkeuren van testspecificaties, testscripts en het testdraaiboek;
• Starten en stoppen van testactiviteiten;
• Inzet van (extern) personeel;
• Categoriseren van testbevindingen.
Subtaak 3: Beschrijven organisatie

Beschrijf de organisatiestructuur van het testproces en neem hiervan een organisatieschema
op. Ook relevante relaties met andere partijen die bij het ontwikkeltraject betrokken zijn,
kunnen worden beschreven.
Subtaak 4: Toewijzen personeel

Nadat is vastgesteld welke testfuncties benodigd zijn voor de test, worden de medewerkers
toegewezen. Hierbij dient rekening te worden gehouden met materiedeskundigheid, kennis
en vaardigheden m.b.t. testen en de bijbehorende technieken van de betreffende
medewerkers. Overigens kan hierbij één persoon meerdere functies vervullen.
Subtaak 5: Bepalen opleidingen

Beschrijf de opleidingen, die voor de deelnemers aan het testtraject noodzakelijk zijn. Voor
de testers kan op basis van de strategiebepaling worden bepaald of deze voldoende
geschoold zijn m.b.t. de voorgestelde testaanpak en testtechnieken (zie paragraaf 8.1
Opleiden testmedewerkers).
Subtaak 6: Vaststellen overlegstructuren

Beschrijf de overlegstructuren die van belang zijn voor het goed functioneren van de
testorganisatie. Geef voor iedere vorm van overleg aan:
• Wat het doel van het overleg is;
• Wie de betrokken partijen/deelnemers zijn;
• Wat de frequentie van het overleg is;
• Eventueel de onderwerpen die zullen worden besproken.
Denk hierbij zowel aan intern overleg, zoals bijvoorbeeld overleg van de projectgroep
acceptatie, als extern overleg, zoals bijvoorbeeld projectgroep acceptatie - stuurgroep,
projectgroep acceptatie - begeleidingsgroep.
Subtaak 7: Vaststellen rapportagelijnen

Beschrijf aan wie, op welke wijze en met welke frequentie gerapporteerd zal gaan worden
over het testtraject. Dit met als doel het verschaffen van inzicht in zowel het testproces als de
kwaliteit van het testobject. Hierover kan periodiek en op verzoek ad-hoc worden
gerapporteerd.
Technieken
Geen specifieke technieken.
Toelichting
Voor een snelle afhandeling van technische problemen tijdens de testuitvoering wordt
geadviseerd om de technische ondersteuning een onderdeel te laten uitmaken van de
projectgroep acceptatie. Geadviseerd wordt de betreffende medewerker(s) tijdens de
testuitvoering een aantal uren per week vrij te maken om adequate ondersteuning te kunnen
bieden.
7.6 Definiëren testproducten
Doelstellingen
• Het eenduidig definiëren van de testproducten.
Basismateriaal
• Handboek systeemontwikkeling;
• Testtemplates.
Producten
• Beschrijving van de op te leveren testproducten vastgelegd in het testplan;
• (Aangepaste) templates voor de diverse documenten.
Subtaken
Subtaak 1: Inventariseren testproducten

Aan de hand van de opdrachtformulering en de strategiebepaling wordt vastgesteld welke
testproducten zullen worden opgeleverd tijdens het testtraject. Mogelijk op te leveren
testproducten zijn:
• Projectdocumentatie
Onder projectdocumentatie wordt verstaan: alle relevante documenten die tijdens het
testtraject worden vervaardigd. Bijvoorbeeld:
- Testplan;

- Bevindingrapportages;
- Overlegverslagen;
- Rapportages over voortgang en kwaliteit, waaronder het eindrapport.
• Testware
Onder testware wordt verstaan: alle testdocumentatie die tijdens de test wordt
geproduceerd en welke voor (toekomstige) onderhoudstesten gebruikt kan worden. Het
is daarom van belang dat de testware overdraagbaar en onderhoudbaar is. Indien dit niet
het geval of bedoeling is, kan beter geen testware worden geconserveerd vanwege de
extra inspanning die conservering met zich meebrengt. Testware omvat o.a.:
- Testspecificaties;
- Testscripts;
- Testdraaiboek;
- Uitgangsdatabases en -bestanden en testuitvoer;
- Beschrijving van de testinfrastructuur, tools en organisatie;
- Het testdossier.
Door middel van een korte beschrijving worden inhoud en doel van de diverse producten c.q.
documenten beschreven.
Subtaak 2: Opstellen normen, standaards en templates

Voor de testproducten wordt, waar mogelijk, gebruik gemaakt van bestaande normen,
standaards en templates. Indien deze niet geschikt zijn, worden deze voor het testproject
gedefinieerd.
Technieken
Toelichting
Uiteraard wordt ernaar gestreefd om op bestaande normen, standaards, richtlijnen en
templates van de opdrachtgever aan te sluiten.
7.7 Definiëren testinfrastructuur
Doelstellingen
• Het in een vroegtijdig stadium vaststellen van de voor het testproces benodigde
infrastructuur. De infrastructuur bestaat uit de testomgeving, de testtools en de
kantoorinrichting.
Basismateriaal
Producten
• Beschrijving van de benodigde infrastructuur, inclusief planning, vastgelegd in het
testplan.
Subtaken
Subtaak 1: Definiëren testomgeving

Ten behoeve van testwerkzaamheden dient een afzonderlijke testomgeving gecreëerd te
worden. De testomgeving bestaat uit die faciliteiten die nodig zijn om de test uit te kunnen
voeren. In deze subtaak wordt de noodzakelijke testomgeving gedefinieerd.

De inrichting van de testomgeving is afhankelijk van de systeemontwikkelomgeving

(ontwikkeltools) en de toekomstige productie-omgeving. Voor de test is het van belang om
specifieke eisen vast te leggen. Denk hierbij aan bijvoorbeeld een manipuleerbare
systeemdatum, afhankelijkheden of afwijkingen t.o.v. de toekomstige productie-omgeving.
Bij nieuwbouw van een informatiesysteem zijn vrijwel altijd verschillen met de toekomstige
productie-omgeving. De risicos, die daardoor worden geïntroduceerd, worden aangegeven
en de eventueel genomen maatregelen worden beschreven. Bijvoorbeeld een afzonderlijke
productie-test plannen en uitvoeren. In deze productie-test kunnen bijvoorbeeld
performance, beheersprocedures, foutafhandeling, etc. worden getest.
Eventuele relaties/koppelingen met andere informatiesystemen worden ook beschreven.

Verder worden beheersfuncties beschreven om in de database gegevens te kunnen
manipuleren. Hierbij valt te denken aan het creëren, wijzigen, raadplegen, verwijderen,
afdrukken en kopiëren van gegevens, het (ont)laden van de database(s), etc.
Subtaak 2: Definiëren testtools

De benodigde testtools worden gedefinieerd. Testtools kunnen ondersteuning bieden bij de
testactiviteiten m.b.t. planning en beheer, voorbereiding, testspecificatie, testuitvoering en
beoordeling van de testresultaten.
Subtaak 3: Definiëren kantoorinrichting

De benodigde kantoorinrichting wordt gedefinieerd. Voor een adequate uitvoering van de test
is het verstandig een afzonderlijke ruimte te claimen waarvan de projectgroep acceptatie
gebruik kan maken voor de uitvoering van hun werkzaamheden. Het verdient grote voorkeur
dat deze ruimte gescheiden is van de reguliere werkplek van de betrokken medewerkers,
zodat ongestoord gewerkt kan worden. Deze ruimte bevat voldoende voorzieningen, zoals
bijvoorbeeld meubilair, telefoons, fax, de benodigde apparatuur, email faciliteiten,
netwerkaansluitingen o.a. naar bijvoorbeeld de testomgeving, etc.
Subtaak 4: Vaststellen infrastructuurplanning

Voor alle benodigde onderdelen van de infrastructuur wordt vastgesteld, wie verantwoordelijk
is voor de selectie, verwerving en installatie. De gemaakte afspraken worden vastgelegd.
Tevens wordt de planning opgesteld met daarin de datums van beschikbaarstelling van de
diverse onderdelen.
Technieken
Toelichting
Technische ondersteuning kan adviseren bij de inrichting van de testomgeving.
De testcoördinator is eigenaar van de testomgeving. Met nadruk wordt erop gewezen dat de
projectleider verantwoordelijk is voor de testomgeving en dat derhalve zijn/haar toestemming
noodzakelijk is voor aanpassingen aan de testomgeving, zoals bijvoorbeeld installatie van
nieuwe programmatuur.
Geadviseerd wordt, om de ontwikkelomgeving en testomgeving strikt van elkaar te scheiden.

Dit voorkomt het risico dat het ontwikkelteam ongevraagd, of zonder de projectgroep
acceptatie hiervan op de hoogte te stellen, wijzigingen kan aanbrengen in de programmatuur
of de onderliggende databases.

7.8 Inrichten beheer
Doelstellingen
• Vastleggen van de wijze waarop het beheer van het testproces, de infrastructuur, de
testproducten en de bevindingen wordt geregeld.
Basismateriaal
• Informatie over de inrichting van de testen projectorganisatie;
• Inrichting van de testinfrastructuur.
Producten
• Beschrijving van de diverse beheersprocessen vastgelegd in het testplan.
Subtaken
Subtaak 1: Definiëren testprocesbeheer

Testprocesbeheer richt zich op het beheersen van het testproces en de kwaliteit van het
testobject. Binnen het testprocesbeheer worden dan ook de onderstaande beheersobjecten
c.q. beheersaspecten onderkend:
• Voortgang;
• Kwaliteit;
• Statistieken;
• Rapportage.
De volgende hoofdtaken moeten worden gedefinieerd:

• Registratie, administratie, opslag en interpretatie van voortgang, de besteding van het
budget en de tijd en de kwaliteitsindicatoren;
• Rapportage.
Subtaak 2: Definiëren infrastructuurbeheer

De infrastructuur kan eventueel worden opgesplitst in drie groepen faciliteiten namelijk:
• De testomgeving;
• De testtools;
• De kantoorinrichting (meestal alleen een éénmalige activiteit voordat de test begint).
Het beheer van de testomgeving zijn die maatregelen die moeten worden genomen om te
allen tijde te kunnen achterhalen hoe de testomgeving eruit ziet. Deze moeten worden
beschreven en vastgesteld. Dit wordt ook wel configuratiemanagement genoemd. Er kunnen
in de testomgeving door verschillende redenen wijzigingen ontstaan:
• Nieuwe versies van het testobject;
• Nieuwe versies van de belendende systemen;
• Nieuwe versies van systeemsoftware;
• Etc.
Er dient duidelijk beschreven te worden hoe wijzigingen verlopen en wie, waarvoor welke
verantwoordelijkheid heeft. Vaak wordt voor het beheer van de testomgeving gebruik
gemaakt van de diensten van de verwerkingsorganisatie.
Subtaak 3: Definiëren testproductbeheer

Het is van groot belang de diverse testproducten goed te onderscheiden en op een

eenduidige manier te beheren. Beschrijf door wie en op welke wijze de testproducten
beheerd zullen gaan worden. Onderscheid daarbij zowel externe als interne producten.
Externe producten:
• Testbasis;
• Testobject.
Het beheer van externe producten is een externe verantwoordelijkheid. Hiermee wordt
bedoeld dat het beheer buiten de verantwoordelijkheid van de projectgroep acceptatie valt.
Het testproces heeft derhalve op dit beheer relatief weinig invloed. Wel moeten
binnenkomende producten duidelijk identificeerbaar zijn (inclusief de versie) en moet het
testproces invloed hebben op de prioriteitsstelling bij het doorvoeren van wijzigingen. Ook
wordt per versie beschreven, op welke wijze het ontwikkelteam de problemen heeft opgelost.
Belangrijk is om twee beschrijvingen op te nemen namelijk:

• De criteria voor installatie van een nieuwe versie van het testobject;
• De installatieprocedure.
Interne producten:
• Testplan;
• Testware;
• Bevindingrapporten;
• Testdocumentatie.
Het beheer van de interne producten valt wel onder de verantwoordelijkheid van de
projectgroep acceptatie. Vaak wordt hiervoor een specifieke beheerder aangesteld. De
producten kunnen bestaan uit documenten, fysieke bestanden alsook andere materialen. De
beheerder is verantwoordelijk voor het registreren en archiveren van de producten, die
aangeleverd worden door de projectgroepleden, of externe producten. Vervolgens kunnen
projectgroepleden of derden de producten raadplegen.
Beschrijf op welke wijze het versiebeheer van de diverse producten is geregeld. D.w.z. hoe
worden de verschillende versies van de producten onderscheiden. Hoe worden relaties
tussen testware en het te testen informatiesysteem onderhouden.
Beschrijf de wijzigingsprocedure voor de diverse producten. In deze procedures worden

zowel de criteria als de bevoegdheden voor het wijzigen van producten vastgelegd. Een
voorbeeld van een wijzigingsprocedure is:
Indien het testplan is goedgekeurd door de stuurgroep, mag alleen de projectleider

acceptatie dit document wijzigen, na overleg met de stuurgroep en de overige leden
van de projectgroep acceptatie. Op moment dat de wijzigingen zijn doorgevoerd
wordt het versienummer verhoogd. De projectleider geeft het gewijzigde testplan aan
de beheerder van de documentatie. De beheerder archiveert het plan en meldt dit
aan de leden van de projectgroep acceptatie.
Subtaak 4: Definiëren bevindingenprocedure

Tijdens het testtraject worden bij de beoordeling van de testbasis en met name tijdens de
uitvoering van de test bevindingen gedaan. Een bevinding is de waarneming van een
mogelijk probleem naar aanleiding van een toets of test. Er zijn twee soorten bevindingen
namelijk, interne bevindingen, bijvoorbeeld een testfout, en externe bevindingen bijvoorbeeld
een programmeerfout. Interne bevindingen kunnen door de projectgroep acceptatie zelf
worden opgelost terwijl externe bevindingen door derden moeten worden opgelost. Er dient
een bevindingenprocedure te worden opgesteld waarin alle bevindingen kunnen worden
beheerd en afgehandeld. Met name dient aandacht te worden besteed aan bevoegdheden
en verantwoordelijkheden binnen de procedure. Een belangrijk onderdeel van de
bevindingenprocedure is de bevindingrapportage. Bevindingrapportages hebben een
eenduidig doel namelijk het vastleggen en uiteindelijk oplossen van de gesignaleerde
problemen.
Technieken
Toelichting
Wanneer het testresultaat niet in overeenstemming is met de voorspelling kan dat duiden op
een fout in het testobject. Eerst wordt bepaald of de test goed is voorbereid c.q. goed is
uitgevoerd. Daarbij wordt ook bepaald of de test met de juiste testdata is uitgevoerd. Indien
dit niet het geval is vindt testherstel plaats. Als indicatie kan worden aangeven dat doorgaans
circa 20% van de bevindingen testherstel vragen. Wanneer er geen duidelijkheid is over een
bevinding maar het geen testfout betreft wordt de bevinding door middel van het
bevindingrapport volgens de bevindingenprocedure verder afgehandeld.
7.9 Opstellen begroting
Doelstellingen
• Het vertalen van de financiële consequenties van de gemaakte keuzen naar een
begroting.
Basismateriaal
• Teststrategie;
• Planning voor het totale testtraject.
Producten
• De begroting vastgelegd in het testplan.
Subtaken
Bij het maken van de begroting kan de volgende verdeling gehanteerd worden:
• Personeel.
De kosten voor het personeel. Hierbij wordt meestal een onderscheid gemaakt tussen
personeel uit de eigen organisatie en personeel dat wordt ingehuurd t.b.v. het testtraject.
• Infrastructuur.
Een inschatting van de kosten van de totale infrastructuur die noodzakelijk is voor het
testtraject.
De begroting is uiteraard sterk gerelateerd aan de gemaakte planning en de teststrategie.
Technieken

Toelichting
Het belang van een financiële begroting is de stuurgroep inzicht te geven in de kosten van
het testtraject . Naast de kosten kunnen ook de verwachte baten worden opgenomen. Op
deze wijze draagt het testplan, met daarin de financiële begroting, bij aan een betere
communicatie tussen de betrokkenen bij het testtraject.
7.10 Bepaling planning
Doelstellingen
• Het opstellen van een globale planning voor het testtraject.
• Het opstellen van een detailplanning voor de fase Voorbereiding.
Basismateriaal
• Teststrategie;
• Plan van aanpak realisatie.
Producten
De planning voor het totale testtraject, vastgelegd in het testplan;
Detailplanning voor de fase 2 Voorbereiding.
Subtaken
Subtaak 1: Opstellen globale planning

Aan de hand van de opgestelde begroting, de beschikbare personen, de middelen en de
planning van de oplevering van de overige relevante producten, zoals testbasis en
programmatuur, wordt een globale planning voor het gehele testtraject opgesteld. De wijze
waarop de planning wordt weergegeven is afhankelijk van de in de organisatie gehanteerde
technieken of hulpmiddelen. Wat minimaal dient te worden gespecificeerd zijn de startdatum,
einddatum en te besteden tijd per taak.
Subtaak 2: Opstellen detailplanning taak fase Voorbereiding

Voor de taak fase Voorbereiding wordt een detailplanning opgesteld. Deze detailplanning is
geen onderdeel van het testplan. In deze planning worden (minimaal) de volgende aspecten
opgenomen:
• Uit te voeren activiteiten (per deelsysteem);
• Relaties met en afhankelijkheden van andere activiteiten (zowel binnen als buiten het
testproject);
• De te besteden tijd per activiteit;
• Benodigde en beschikbare doorlooptijd;
• Op te leveren producten;
• Betrokken medewerkers.
Technieken
Toelichting
Voor het verdelen van de inspanning over de verschillende taken wordt de volgende
vuistregel gebruikt:
• Planning: 10 %
• Voorbereiding 10 %

• Specificatie 40 %
• Uitvoering 35 %
• Afronding 5%
Er kan op een informatiesysteem ook een zogenaamde testpuntanalyse worden uitgevoerd.

Deze testpuntanalyse is een rekenmethode die inzicht geeft in de noodzakelijke
testinspanning. Het uitvoeren van deze analyse wordt meestal uitbesteed aan externe
partijen die op dit onderwerp gespecialiseerd zijn.
Omdat het niet bij iedere opdrachtgever testpuntanalyse wordt toegepast kunnen als
alternatief de volgende vuistregels worden gehanteerd:
• Per functiepunt bedraagt de benodigde testinspanning ca. 2 uur;
• De testinspanning = (factor * realisatie inspanning). Deze factor is minimaal 0,5 en
maximaal 1;
• SYSQA beschikt over benodigde testinspanning per gehanteerde testtechniek;
• Op basis van ervaringscijfers uit de evaluatie van eerdere testtrajecten bij de betreffende
dienst of directie.
7.11 Fixatie testplan
Doelstellingen
• Het vastleggen van resultaten van de tot nu toe uitgevoerde (sub)taken.
• Het verkrijgen van de goedkeuring van de gekozen aanpak door de stuurgroep.
Basismateriaal
• Alle producten uit voorgaande (sub)taken.
Producten
• Vastgesteld en goedgekeurd testplan.
Subtaken
Subtaak 1: Vaststellen bedreigingen, risicos en maatregelen

Het is noodzakelijk, om in het testplan mogelijke bedreigingen en risicos voor het testtraject
in een afzonderlijke paragraaf op te nemen. Een bedreiging is een negatieve externe invloed
en een risico is de inschatting van het gevaar van zo een bedreiging. Deze kunnen
ondermeer betrekking hebben op:
• Haalbaarheid
Zijn de gemaakte planningen van het realisatietraject en het testtraject haalbaar en
reëel?
• Testbaarheid
Verwacht men dat de verwachte kwaliteit van de testbasis voldoende is voor het
uitvoeren van de test?
• Stabiliteit
In welke mate zal de testbasis gedurende het testtraject aan wijzigingen onderhevig zijn?
• Ervaring
Zijn ervaring en opleiding van zowel projectleider als overige leden van de projectgroep
acceptatie voldoende om het testtraject tot een goed einde te kunnen brengen?

Van de bedreigingen die daadwerkelijk een risico vormen, wordt in het testplan per risico
aangegeven welke maatregelen zijn genomen. Denk hierbij aan preventieve maatregelen om
risicos te vermijden, maar ook aan detectieve maatregelen om problemen tijdig te kunnen
signaleren.
Subtaak 2: Vaststellen testplan

De resultaten en de laatste aanpassingen uit de diverse onderdelen van het testplan worden
verwerkt tot een definitieve versie. Eventueel wordt er een managementsamenvatting
opgenomen waarin in grote lijnen de strategie, de planning. de begroting en de risicos met
bijbehorende maatregelen worden weergegeven. Dit laatste is zinvol als het testplan erg
omvangrijk is geworden.
Subtaak 3: Vaststellen wijzigingsprocedure testplan

Er wordt een wijzigingsprocedure vastgesteld, ten aanzien van het te fixeren testplan. In
deze procedure worden zowel de criteria, als de bevoegdheden voor het wijzigen van het
testplan, uitgewerkt.
Subtaak 4: Fixeren testplan

Nadat de wijzigingsprocedure is vastgesteld, wordt het testplan ter goedkeuring voorgelegd
aan de stuurgroep. Het is raadzaam de goedkeuring formeel te bekrachtigen door het laten
ondertekenen van het testplan door de stuurgroep. Daarnaast kan een presentatie,
bijvoorbeeld aan de stuurgroep en de diverse betrokken partijen, bijdragen tot het verkrijgen
van goedkeuring én, minstens zo belangrijk, draagvlak binnen de organisatie.
Technieken
• Checklist testplan
Toelichting
Op het testplan kan een kwaliteitreview worden uitgevoerd door productmanagement.

Onderwerp Hoofdstuk 8. Fase Voorbereiding Datum 05-01-2001
8. Fase Voorbereiding
2. detai l intake 3. defi ni r en 4. toew ij zen
test basi s t esteenheden testt echni eken
6. det ail pl anni ng

taak speci fi cati e
1. oplei den
testm edew erker s
5. specifi cer en
infr astruct uur
8.1 Opleiden testmedewerkers
Doelstellingen
• Het verzorgen van een tijdige en adequate opleiding voor testmedewerkers1.
Basismateriaal
• Cursusmateriaal.
Producten
• Opgeleide testmedewerkers.
Subtaken
In het testplan is geïnventariseerd en beschreven welke opleidingen voor de
testmedewerkers noodzakelijk zijn. Door de projectleider acceptatie worden de benodigde
opleidingen georganiseerd. Dit gebeurt vaak in overleg met de afdeling personeelszaken. De
opleidingen worden meestal verzorgd door opleidingsinstituten of consultants van externe
bedrijven. Soms kan ook het ontwikkelteam een opleiding verzorgen m.b.t. het gebruik van
het informatiesysteem.
Technieken
Toelichting
Geen specifieke toelichting.
1
SysQa B.V. heeft een opleiding Gestructureerd Testen beschikbaar. Tijdens deze training krijgen de
deelnemers inzicht in het testproces en leren zij testspecificaties en testscripts maken.

8.2 Detail intake testbasis
Doelstellingen
• Het verkrijgen van inzicht in de testbaarheid van de testbasis, om een goede
uitgangssituatie voor de test te creëren en vervolgens de gefixeerde testbasis formeel
over te nemen. Met testbaarheid wordt hier bedoeld de uniformiteit, consistentie,
volledigheid en toegankelijkheid van de testbasis;
• Het signaleren van fouten c.q. problemen in de testbasis.
Basismateriaal
• Testbasis.
Producten
• Testbasisbevindingen;
• Rapport testbaarheid.
Subtaken
Subtaak 1: Bepalen relevante documentatie

De relevante documentatie (testbasis) voor het uitvoeren van de test is in principe reeds
vastgelegd in het testplan. Het is echter mogelijk dat er ten aanzien van de testbasis
wijzigingen hebben plaatsgevonden. Het testplan wordt dan, via de in het testplan
vastgelegde procedure, aangepast en de identificatie van de documentatie moet worden
vastgesteld. De projectgroep acceptatie dient te beschikken over de juiste c.q. actuele versie
van de testbasis.
Subtaak 2: Opstellen checklists

Aan de hand van de in het testplan vastgestelde teststrategie worden checklists opgesteld.
Deze checklists vormen de leidraad voor het beoordelen van de testbasis. De onderstaande
criteria kunnen hierin worden meegenomen:
• Inleefbaarheid m.b.t. beeldvorming, uniforme notatie;
• Scheidbaarheid in processen en functies;
• Herkenbaarheid van condities, acties, interfaces, gegevens- en tijdscycli;
• Voorspelbaarheid van het resultaat;
• Volledigheid.
Subtaak 3: Beoordelen testbasis

De testbasis wordt beoordeeld aan de hand van de opgestelde checklists, om inzicht te
krijgen in de uitvoerbaarheid van de vastgestelde teststrategie en de daaraan gerelateerde
testtechnieken. Daarnaast wordt er getoetst op de verwachtingen ten aanzien van de
functionaliteit. De registratie, rapportage en afhandeling van bevindingen vindt plaats op
basis van de in het testplan vastgelegde procedures. Problemen en onduidelijkheden worden
teruggekoppeld met de beheerder(s) van de testbasis.
Subtaak 4: Opstellen rapport testbaarheid

Op basis van de resultaten van de bevindingen wordt het Rapport testbaarheid opgesteld.
Hierin worden de conclusies ten aanzien van de kwaliteit c.q. testbaarheid van de testbasis
vastgelegd. Eventuele consequenties van onvoldoende kwaliteit dienen eveneens te worden
beschreven. Ook aanbevelingen m.b.t. de testbasis richting begeleidingsgroep en de
stuurgroep kunnen van belang zijn.

Technieken
• Detail intake testbasis;
• Inspectie (bijvoorbeeld FAGAN inspection).
Toelichting
Het Rapport testbaarheid hoeft niet zeer omvangrijk te zijn. De algemene bevindingen en
aanbevelingen m.b.t. de testbasis worden hierin vastgelegd. Dit rapport beslaat normaliter
één tot enkele paginas.
Verwijzingen
Voor aanvullende informatie wordt verwezen naar:
Subtaak 4 Definiëren bevindingenprocedure van paragraaf 7.8 Inrichten Beheer.
8.3 Definiëren testeenheden
Doelstellingen
Het opdelen van deelsystemen in onafhankelijk te testen eenheden, de zogenaamde
testeenheden. Dit om het testen beheersbaar en controleerbaar te maken. Deze
testeenheden dienen onafhankelijk van elkaar te kunnen worden getest.
Basismateriaal
• Stategiematrix uit het testplan;
• Systeemontwerp rapport.
Producten
• Testeenhedenmatrix.
Subtaken
Subtaak 1: Bepalen testeenheden

In deze subtaak wordt per deelsysteem beoordeeld, welke transacties binnen het
informatiesysteem een logische samenhang hebben en/of sterk afhankelijk van elkaar zijn.
Hierbij valt te denken aan een wijzigingstransactie in combinatie met een invoertransactie.
Het kan dan zinvol zijn beide transacties tegelijk te testen. Immers, om de gegevens te
kunnen wijzigen, moeten ze eerst ingevoerd worden. Er zijn echter beperkingen aan het
samenvoegen. In het geval de onderling samenhangende transacties een zeer grote omvang
hebben, kan het samenvoegen tot gevolg hebben, dat het testobject te omvangrijk wordt.
Hierdoor wordt het specificeren van testgevallen een moeilijk proces waarbij het overzicht
verloren gaat.
Subtaak 2: Opstellen testeenhedenmatrix

Per deelsysteem wordt aangegeven uit welke testeenheden dat deelsysteem bestaat. Deze
onderverdeling wordt vastgelegd in een testeenhedenmatrix.
Technieken
Toelichting
Een voorbeeld van een testeenhedenmatrix:

Deelsysteem Testeenheden
Deelsysteem 1 Testeenheid 1
Testeenheid 2
enz.
Deelsysteem 2 Testeenheid 1
Testeenheid 2
Verwijzingen
Paragraaf 7.4 Bepalen teststrategie.
8.4 Toewijzen testtechnieken
Doelstellingen
Op basis van de vastgestelde teststrategie en de onderverdeling in testeenheden, wordt een
detaillering van de teststrategie uitgevoerd die resulteert in de toewijzing van testtechnieken
aan testeenheden.
Basismateriaal
• Testeenhedenmatrix.
Producten
• Testeenhedenmatrix met testtechnieken.
Subtaken
Op basis van de in voorgaande subtaak geselecteerde testeenheden en de kenmerken van
de in de teststrategie geselecteerde testtechnieken (zie subtaak 5 Bepalen te gebruiken
testtechnieken van paragraaf 7.4 Bepalen teststrategie), vindt detaillering van de
teststrategie plaats. De testeenhedenmatrix uit de voorgaande subtaak wordt uitgebreid met
een kolom testtechnieken. Per testeenheid worden de toe te passen testtechnieken
opgenomen. Het is uiteraard mogelijk om per testeenheid meerdere testtechnieken te
gebruiken.
Technieken
Toelichting
Een voorbeeld van een testeenhedenmatrix met testtechnieken staat hieronder:
Informatiesysteem Testeenheden Testtechnieken

Deelsysteem 1 Testeenheid 1 Dataflowtest
Procescyclustest
Testeenheid 2 Elementaire vergelijkingentest
enz.
Deelsysteem 2 Testeenheid 1 Procescyclustest
Testeenheid 2 Procescyclustest
Dataflowtest
Verwijzingen
• Paragraaf 7.4 Bepalen teststrategie;

• Hoofdstuk 12 Technieken voor testspecificatie.
8.5 Specificeren infrastructuur
Doelstellingen
De definitie van de infrastructuur, welke in het testplan is beschreven, wordt, indien
noodzakelijk, verder uitgewerkt in een detailspecificatie.
Basismateriaal
• Specificatie infrastructuur uit testplan;
Producten
• Detailspecificatie infrastructuur.
Subtaken
Aan de hand van de in het testplan opgenomen definitie van de infrastructuur wordt bekeken,
of nadere specificatie en detaillering noodzakelijk is. Het betreft met name de testomgeving
en eventueel het gebruik van testtools. Op basis van gesprekken met de (toekomstige)
verwerkingsorganisatie en, indien nodig, adviseurs van de Facilitaire Dienst wordt
vastgesteld of de in het testplan gemaakte definitie aanpassing of detaillering behoeft.
Technieken
Niet van toepassing.
Toelichting
Verwijzingen
Paragraaf 7.7 Definiëren testinfrastructuur.
8.6 Detailplanning fase Specificatie
Doelstellingen
Het maken van een detailplanning voor de fase Specificatie.
Basismateriaal
• Testplan;
• Opleverplanning ontwikkelteam;
• Systeemontwerp rapport.
Producten
Detailplanning voor de fase Specificatie met de volgende onderdelen:
• Uit te voeren (sub)taken (per deelsysteem);
• Relaties met en afhankelijkheden van andere activiteiten (zowel binnen als buiten het
testproject);
• De te besteden tijd per (sub)taak;
• Benodigde en beschikbare doorlooptijd;
• Op te leveren producten;
• Betrokken medewerkers.

Subtaken
Stel de volgorde vast, waarin testen de testeenheden zullen worden gespecificeerd en
uitgevoerd. Hierbij wordt rekening gehouden met:
• De teststrategie;
• Opleverdatums van de verschillende deelsystemen van het informatiesysteem;
• Het moment waarop de testomgeving beschikbaar komt;
• De logische samenhang van de verschillende testeenheden;
• Testeenheden die dezelfde gegevens muteren. Deze moeten bij voorkeur niet gelijktijdig
worden uitgevoerd om het versiebeheer van de uitgangsbestanden niet te compliceren;
• Door allerlei beperkingen op het organisatorische of technische vlak kan het mogelijk zijn,
dat binnen een redelijke doorlooptijd niet iedere testeenheid in een eigen onafhankelijke
testomgeving getest kan worden. Als dat gelijktijdig de testeenheden in één testomgeving
met één gemeenschappelijke gegevensverzameling moeten worden getest, is het zaak er
voor te zorgen, dat:
o De te muteren gegevens van elkaar verschillend zijn;
o De te hanteren testtechnieken elkaar bij uitvoering niet hinderen;
o De testeenheden op grond van de vastgestelde volgorde van aanpak zodanig
gegroepeerd worden, dat deze aan één tester kunnen worden toegewezen.
Bij het groeperen is de logische samenhang het belangrijkste criterium.
Technieken
• Planningstechnieken.
Toelichting
Verwijzingen
Niet van toepassing.

Onderwerp Hoofdstuk 9. Fase Specificatie Datum 05-01-2001
9. Fase Specificatie
1. o p st el len 2 . d e f in i ër e n 3. o p st e ll en 4. o p st el le n
t est sp ecif ica t ie s u i t ga n g ssi t u at i es t est scr i p t s t est d r a ai b o ek
{XG " t est in f r a-
st r u ct u u r " }
6. d et a ilp l an n i n g
ta a k u i t vo e r in g
{X G " t e sti n f r a -
st r u ct u u r " }
5. r e al isat ie
t est in f r a st r u ct u u r
9.1 Opstellen testspecificaties
Doelstellingen
Het vaststellen en beschrijven van de logische testgevallen en het te verwachten resultaat.
Basismateriaal
• Testbasis;
• Testspecificatietechnieken;
• De Gebruikershandleiding testtemplates;
• Het Template testspecificatie.
Producten
• Testspecificaties;
• Testbasisbevindingen.
Subtaken
Per testtechniek die toegepast wordt, dient een testspecificatie vervaardigd te worden: dus
per testeenheid/testtechniek één testspecificatie. Een testspecificatie is een beschrijving van
de wijze waarop logische testgevallen zijn geselecteerd, alsmede een beschrijving van de
logische testgevallen. Dus een beschrijving van wat getest gaat worden. Met deze logische
testgevallen zou ook het systeemontwerp gevalideerd kunnen worden.
Een testgeval bestaat uit:

• Een beschrijving van de uitgangssituatie;
• Het veranderingsproces;
• Een voorspelling van het resultaat.
Het is mogelijk dat gedurende deze activiteit tekortkomingen en/of onduidelijkheden worden
geconstateerd in de testbasis. Het is uiteraard van belang deze zo snel mogelijk te
signaleren zodat deze kunnen worden verbeterd of verduidelijkt. De registratie, rapportage
en afhandeling van bevindingen vindt plaats op basis van de in het testplan vastgelegde
procedures.

Technieken
• Testspecificatietechnieken.
Toelichting
Hieronder staat een voorbeeld van een testgeval dat betrekking heeft op een
informatiesysteem voor het afhandelen van offertes.
Aan een bestaande offerte moet een artikel worden toegevoegd.
Uitgangssituatie: Veranderingsproces Verwacht resultaat

de offerte bestaat, het toe te selecteer de offerte en voeg melding mutatie succesvol
voegen artikel bestaat een artikel toe
Verwijzingen
• De Gebruikershandleiding testtemplates;
• De Template testspecificatie;
• Paragraaf 12.2 Globale werkwijze;
• Subtaak 4 Definiëren bevindingenprocedure van paragraaf 7.8 Inrichten Beheer
9.2 Definiëren uitgangsbestanden
Doelstellingen
Het verzamelen van de in de testspecificaties beschreven uitgangssituaties en het centraal
definiëren van de benodigde uitgangsdatabases en/of -bestanden.
Basismateriaal
• Testspecificaties.
Producten
• Een beschrijving van de initiële gegevensverzamelingen;
Subtaken
In de testspecificaties worden per testeenheid de benodigde uitgangssituaties
gespecificeerd. Deze uitgangssituaties zijn opgebouwd uit één of meerdere soorten
gegevensverzamelingen.
Om redundantie te voorkomen en het aantal benodigde databases, records en/of fysieke

bestanden te beperken, worden deze gegevensverzamelingen samengevoegd tot één
centrale beschrijving van initiële gegevensverzamelingen. Deze initiële
gegevensverzamelingen worden uiteindelijk in één uitgangsdatabase of - bestand gezet.
Het is mogelijk dat gedurende deze activiteit tekortkomingen en/of onduidelijkheden worden
geconstateerd in de testbasis. Het is uiteraard van belang deze zo snel mogelijk te
signaleren zodat deze kunnen worden verbeterd of verduidelijkt. De registratie, rapportage
en afhandeling van bevindingen vindt plaats op basis van de in het testplan vastgelegde
procedures.
Technieken

Toelichting
Het, in de vorige paragraaf beschreven, voorbeeld van de uitgangssituaties (de offerte
bestaat, het toe te voegen artikel bestaat) resulteren in de gegevensverzamelingen offerte en
artikel. Als dit in een database wordt geïmplementeerd, dan moet in de tabel OFFERTE een
record voorkomen en in tabel ARTIKEL moet een record voorkomen. Bijvoorbeeld:
Uitgangsdatabase:
Test100.dmp
Artikel:
Schoenen bruin maat 45 25,- 100
Regenjassen 75,- 25
Offerte:
10057 Firma J. de Vries, 10 januari 1999
10901 Janssen B.V. 15 maart 1999
Verwijzingen
• Paragraaf 12.2 Globale werkwijze;
9.3 Opstellen testscripts
Doelstellingen
• De in de testspecificaties beschreven testgevallen omzetten naar uitvoerbare, concrete
testacties;
• Het in testscripts vastleggen van de volgorde van de uit te voeren handelingen en de
voorwaarden voor uitvoering.
Basismateriaal
• Testbasis;
• De gebruikershandleiding testtemplates;
• De templates testspecificatie.
Producten
• Testscripts;
Subtaken
Subtaak 1: Opstellen testscripts

Om het te testen informatiesysteem, in een praktisch uitvoerbare volgorde, te kunnen
confronteren met de in de testspecificaties beschreven (logische) testgevallen, worden
testscripts opgesteld. Tijdens het opstellen van de testscripts worden de testgevallen
vertaald naar uitvoerbare en controleerbare (fysieke) testacties en in een uitvoerbare
volgorde gezet.
Er dient rekening te worden gehouden met het feit dat een testactie verkeerd kan gaan.
Probeer daarom onderlinge afhankelijkheid tussen de testacties zo beperkt mogelijk te
houden. D.w.z. dat indien één testactie faalt, de rest van het testscript nog steeds uitgevoerd
zou kunnen worden. Dit zal in een aantal gevallen resulteren in meerdere scripts per
testspecificatie.

In het testscript wordt tevens beschreven welke initiële gegevens noodzakelijk zijn om de
beschreven testacties te kunnen uitvoeren. Deze worden opgenomen als startvoorwaarde
(pré-conditie) voor de uitvoering van het testscript. Daarnaast zijn er post-condities welke het
resultaat zijn van de uitvoering van het testscript. Deze post-condities komen meestal in de
database of in een resultaatbestand te staan. De post-conditie van het ene testscript is soms
de pré-conditie voor het volgende testscript, alhoewel dit zoveel mogelijk moet worden
beperkt.
Als vuistregel geldt, dat het aantal pré-condities geminimaliseerd moet worden. Op die
manier kunnen testscripts onafhankelijker van elkaar worden uitgevoerd.
Vaak wordt het openen of opslaan van bepaalde gegevensverzamelingen, databases en/of
bestanden als een afzonderlijke actie opgenomen in het testscript.
Subtaak 2: Opstellen testscript pré-test
Het is raadzaam om altijd een testscript te maken voor de pré-test. De pré-test is een test om
vast te stellen of alle benodigde onderdelen in het (deelsysteem van het) testobject aanwezig
zijn en van een dusdanige kwaliteit zijn dat het zinvol is om de overige testen uit te voeren.
Leg in het testscript vast op welke wijze dit bepaald wordt.
Technieken
Toelichting
Een voorbeeld van het testscript voor een pré-test is:
Aan de hand van het systeemontwerp wordt nagegaan of alle benodigde modules zijn
opgeleverd. Op het moment dat modules worden onderkend die (nog) niet zijn opgeleverd
moet hiervan een bevinding worden gemaakt;
Alle menu-onderdelen worden geselecteerd en het resultaat moet zijn dat de juiste
bijbehorende schermen of overzichten verschijnen;
Controleer steekproefsgewijs of afdrukken van overzichten mogelijk is.
In de module Invoer aanvraag moet het mogelijk zijn om een aanvraagformulier volledig in te
voeren.
Verwijzingen
• Het template testspecificatie;
• Subtaak 4 Definiëren bevindingenprocedure van paragraaf 7.8 Inrichten Beheer.
9.4 Opstellen testdraaiboek
Doelstellingen
Het in een testdraaiboek vastleggen van de volgorde waarin de testscripts zullen worden
uitgevoerd.
Basismateriaal
• Testscripts;
• Opleverplanning modules;
• Het template testdraaiboek.

Producten
• Testdraaiboek.
Subtaken
Het testdraaiboek vormt de basis voor een gestructureerde aanpak van de taak uitvoering.
De volgorde waarin testscripts worden uitgevoerd, wordt vastgelegd. Ook hierbij dient
rekening te worden gehouden met het feit dat een testscript of testactie verkeerd kan gaan.
Gestreefd moet worden naar een zo gering mogelijke onderlinge afhankelijkheid van
testscripts. Dit kan bijvoorbeeld worden bereikt door voor het uitvoeren van een testscript
eerst de uitgangsdatabase of -bestanden opnieuw te laden en niet verder te werken met het
resultaat van een voorafgaand testscript. Eventueel kan ook gebruik worden gemaakt van
andere data in de uitgangsdatabase. Om de belangrijkste fouten/problemen als eerste op te
sporen, worden de testscripts die betrekking hebben op de meest cruciale deelsystemen van
het informatiesysteem als eerste getest.
Voer goedpad testen als eerste uit na de pré-test. Deze testen tonen de inpasbaarheid van
het systeem aan binnen de AO-procedures. D.w.z. of het informatiesysteem goed aansluit bij
de handmatige procedures. Bijvoorbeeld:
Controleer of een aanvraagformulier volledig en zonder problemen ingevoerd kan worden.
Indien de goedpad testen fundamentele problemen aan het licht brengen kan het raadzaam
zijn om de uitvoering van de overige testscripts uit te stellen totdat deze problemen zijn
opgelost.
Houdt bij het opstellen van het testdraaiboek in de gaten dat het doel is om de grootste
problemen in de belangrijkste deelsystemen als eerste te vinden. Het gaat hierbij dus met
name om testverstorende en productieverstorende bevindingen. De volgende detaillering
kan hierbij gehanteerd worden:
• Pré-test;
• Goedpad testen;
• Functionaliteit/ inpasbaarheid (Procescyclustest);
• Cruciale deelsystemen/testeenheden;
• Overige deelsystemen/testeenheden.
Uiteraard is bij het opstellen van het testdraaiboek de teststrategie het uitgangspunt.
Zeker bij de goedpad testen kan, indien voorhanden, gebruik worden gemaakt van gegevens
uit de dagelijkse praktijk zoals bijvoorbeeld bestaande dossiers, aanvraagformulieren, etc.
Technieken
Toelichting
De belangrijkste voorwaarde die gesteld wordt aan het testdraaiboek is flexibiliteit. Als
verstorende fouten optreden in delen van het informatiesysteem moet het testdraaiboek,
indien mogelijk, de ruimte bieden om hierop in te spelen. De uitvoering van de overige
testscripts kan zo ongehinderd voortgezet worden.
Beschrijf ook hoe vaak de cyclus van hertesten wordt herhaald in het testdraaiboek. Dit om
te voorkomen dat hertesten eindeloos worden uitgevoerd en de planning daardoor niet wordt
gehaald. Een schatting van het aantal hertesten kan worden gedaan op basis van
ervaringsgegevens uit andere testtrajecten binnen de organisatie.

Verwijzingen
• Het template testdraaiboek;
• Paragraaf 8.6 Detailplanning fase Specificatie.
9.5 Realisatie testinfrastructuur
Doelstellingen
Het realiseren van de infrastructuur conform de opgestelde specificaties.
Basismateriaal
• Detailspecificatie infrastructuur.
Producten
• Operationele testomgeving (en testtools).
Subtaken
Parallel aan de overige subtaken van de fase 3 Specificatie wordt de infrastructuur
gerealiseerd. Het uitvoeren van deze activiteit bestaat o.a. uit de volgende elementen:
• Het controleren af alle gemaakte afspraken m.b.t. de infrastructuur nog gelden;
• Het oplossen van knelpunten, problemen en vastleggen van de eventueel genomen
maatregelen in afspraken;
• Installatie van de testomgeving ;
• Controle van de installatie;
• Proefdraaien met de testomgeving;
• Het testen van de back-up en recovery procedures.
Technieken
Toelichting
De afhankelijkheid van personen of afdelingen, die niet direct bij het testproject betrokken
zijn, is meestal groot. Deze taak is daardoor soms moeilijk beheersbaar.
Verwijzingen
• Paragraaf 7.7 Definiëren testinfrastructuur;
• Paragraaf 8.5 Specificeren infrastructuur.
9.6 Detailplanning fase Uitvoering
Doelstellingen
Het maken van een definitieve planning voor de fase Uitvoering.
Basismateriaal
• Testplan;
• Opleverplanning ontwikkelteam;

• Testdraaiboek.
Producten
• Detailplanning fase Uitvoering vastgelegd in het testdraaiboek.
Subtaken
Er wordt een planning gemaakt voor het uitvoeren van de verschillende testscripts. In het
testdraaiboek wordt aangegeven welke testscripts wanneer en door wie uitgevoerd gaan
worden. Hierbij wordt rekening gehouden met de opleverdatum van het testobject en de
testinfrastructuur. Ook bij planning van hertesten wordt het testdraaiboek aangepast.
De testscripts worden als het ware gekoppeld aan datums en personen.
Technieken
• Planningstechnieken.
Toelichting
Verwijzingen
• 9.4 Opstellen testdraaiboek.

Onderwerp Hoofdstuk 10. Fase Uitvoering Datum 05-01-2001
10. Fase Uitvoering
1 . i n t ak e t es t - 2. o p b o u w 3. ( h er -) t e st - 4 . c o n t r o le r e n 5. o n d e r h o u d en
o b je c t / i n t ak e u it g a n g s - u it v o e r i n g e n b e o o r d e le n t es t d r a a ib o e k
t e st i n f r as t r u c tu u r b es t a n d e n t e st r es u lt a t e n
6 . vo o rt g a n g s-
ra p p o rt a g e
10.1 Intake testobject / Intake testomgeving
Doelstellingen
• Het vaststellen of (de opgeleverde delen van) het testobject en de testomgeving volledig
zijn opgeleverd;
• Het inrichten van het testdossier.
Basismateriaal
• Testobject;
• Testomgeving;
• Detailspecificatie infrastructuur;
• Begeleidende documentatie.
Producten
• Testobjectbevindingen;
• Testdossier.
Subtaken
Subtaak 1: Intake van het testobject

Intake van het testobject bestaat uit drie activiteiten, namelijk:
• Intake begeleidende documentatie;
• Fysieke overdracht van (een deel van) het testobject;
• Aanleggen van het testdossier.
De begeleidende documentatie bestaat uit een, door het ontwikkelteam gemaakte, paklijst
met daarop welke producten worden overgedragen, een versie identificatie en de
bijgevoegde documentatie. Op basis van de paklijst wordt gecontroleerd op volledigheid. Op
de paklijst moet in ieder geval staan om welke producten het gaat:
• Deelsyste(e)m(en);
• Procedures;
• Programmas;

• Database beschrijving;
• Help files;
• etc.
•
De bijgevoegde documentatie kan bestaan uit:
• Installatie handleiding;
• Gebruikershandleiding;
• Testresultaten van vorige testen;
• Relaties met andere producten.
De fysieke overdracht van de producten gebeurt aan de beheerder van de testomgeving. De

beheerder controleert of alle producten die op de paklijst staan ook daadwerkelijk aanwezig
zijn.
Subtaak 2: Intake van de testomgeving

Bij intake van de testomgeving wordt door beheerder van de testomgeving allereerst
gecontroleerd of alle gespecificeerde onderdelen aanwezig zijn. Deze controle vindt plaats
op basis van de specificatie van de infrastructuur. Het is mogelijk dat gedurende deze
activiteit problemen en/of ontbrekende delen worden geconstateerd in de testomgeving. De
registratie, rapportage en afhandeling van bevindingen vindt plaats op basis van de in het
testplan vastgelegde procedures. Uiteraard moeten problemen die een verdere testuitvoering
in de weg staan zo spoedig mogelijk worden opgelost.
Subtaak 3: Inrichten testdossier

In deze subtaak wordt voor het testobject een testdossier ingericht met:
• Bijbehorend(e) testobject(en) en hun status;
• Het testdraaiboek.
Hieraan kunnen te zijner tijd worden toegevoegd:

• Testresultaten;
• Bevindingrapportages;
• Kopieën van schermafdrukken;
• Relevante overzichten.
Een dergelijk dossier zal van onschatbare waarde zijn bij toekomstig onderhoud. Integratie
met een eventueel overeenkomstig dossier uit de SDM-fase Systeemontwerp is
aanbevelenswaardig.
Technieken
Toelichting
Verwijzingen

10.2 Installatie testobject
Doelstellingen
Een succesvolle Installatie van het testobject.
Basismateriaal
• Testobject;
• Testomgeving;
• Installatiehandleiding.
Producten
• Operationeel testobject;
• Testdossier.
Subtaken
De beheerder van de testomgeving maakt, de opgeleverde delen van, het testobject aan de
hand van de installatiehandleiding operationeel. In de praktijk kan hierbij veel mis gaan en
daarom moet de installatie van de nieuwe programmatuur met veel zorg van zowel de
technisch applicatiebeheerder als de projectgroep acceptatie worden omgeven.
De registratie, rapportage en afhandeling van bevindingen vindt plaats op basis van de in het
testplan vastgelegde procedures. Uiteraard moeten problemen die een verdere testuitvoering
in de weg staan zo spoedig mogelijk worden opgelost.
Technieken
Toelichting
Om veel problemen op dit gebied te voorkomen kan het raadzaam zijn om de installatie van
de programmatuur te laten uitvoeren door de beheerder van de testomgeving en/of de
technisch applicatiebeheerder, in samenwerking met het ontwikkelteam. Ook kan het
ontwikkelteam een demonstratie geven van de programmatuur. Afspraken hieromtrent
moeten bij voorkeur reeds bij uitbesteding van de realisatie worden vastgelegd.
Het testen van de installatieprocedure is een wezenlijk onderdeel van de test!
Verwijzingen
10.3 Uitvoeren pré-test
Doelstellingen
Het vaststellen of de geïnstalleerde delen van het testobject en de testinfrastructuur zodanig
functioneren, dat het zinvol is om verder te testen.
Basismateriaal
• Testobject;
• Testomgeving;
• Testscript pré-test.

Producten
• Testbaar testobject;
• Testdossier.
Subtaken
Nadat zowel de testomgeving als het testobject volledig zijn geïnstalleerd wordt de pré-test
uitgevoerd op basis van het beschreven testscript.
Ook hier geldt dat de registratie, rapportage aan het ontwikkelteam en afhandeling van
bevindingen, plaatsvindt op basis van de in het testplan vastgelegde procedures. Uiteraard
moeten problemen die een verdere testuitvoering in de weg staan zo spoedig mogelijk
worden opgelost.
Technieken
Toelichting
De activiteit uitvoeren pré-test verloopt in sommige gevallen deels parallel aan de activiteit
Opbouw uitgangsbestanden. Het kan namelijk zijn dat voor het succesvol uitvoeren van de
pré-test een aantal uitgangsbestanden aanwezig moeten zijn. Als uitgangsbestanden worden
opgebouwd met reguliere systeemfuncties kan uit de pré-test blijken dat dit onmogelijk is en
verdere testuitvoering in de weg staat.
Een goed verloop van de pré-test is een voorwaarde voor het starten van de volgende
subtaken in de fase Uitvoering.
Verwijzingen
• Subtaak 4 Definiëren bevindingenprocedure van paragraaf 7.8 Inrichten Beheer.
10.4 Opbouw uitgangsbestanden
Doelstellingen
Het opbouwen van de uitgangsdatabase of -bestanden, die nodig zijn voor de uitvoering van
de in de testscripts beschreven testen.
Basismateriaal
• Testobject;
• Laadprogrammatuur;
• Conversieprogrammatuur;
• Controleprogrammatuur.
Producten
• Uitgangsdatabases en/of -bestanden;
• Testobjectbevindingen.

Subtaken
De uitgangsbestanden moeten worden opgebouwd conform de betreffende beschrijving uit
de taak specificatie. Er is een aantal mogelijkheden om uitgangsbestanden te vullen
namelijk:
Opbouw met reguliere systeemfuncties

Als bij de opbouw reguliere systeemfuncties worden gebruikt, moet men beseffen dat die
functies vaak nog niet uitputtend zijn getest. Grondige controle van de ingevoerde gegevens
is onontbeerlijk. Voordeel van deze methode is dat reguliere systeemfuncties gelijktijdig
(impliciet) worden getest.
Opbouw met aparte laadprogrammatuur

Grondige controle van de ingevoerde gegevens geldt in nog sterkere mate, als voor de
opbouw aparte laadprogrammatuur wordt gebruikt. Omdat screening van de invoer
hoegenaamd geheel zal ontbreken zijn allerlei in werkelijkheid onmogelijke situaties nu
mogelijk geworden. De opbouw en de controle kunnen vaak niet zonder hulp van de
technisch applicatiebeheerder (TAB) of database administrator (DBA) gebeuren. Dit komt
doordat de fysieke realisatie van het gegevensmodel kan verschillen van het logische model.
Laadprogrammatuur wordt in principe ontwikkeld c.q. gebruikt ten behoeve van de

testuitvoering. Dit houdt in dat laadprogrammatuur geen onderdeel uitmaakt van de
applicatieprogrammatuur. De projectgroep acceptatie is verantwoordelijk voor de,
ontwikkeling van, laadprogrammatuur. De projectgroep acceptatie kan de ontwikkeling van
laadprogrammatuur uitbesteden aan bijvoorbeeld de TAB, DBA of ontwikkelaar. Kennis van
de applicatie is hierbij van groot belang.
Converteren van productiegegevens

Indien productiegegevens beschikbaar zijn, is het soms een snelle methode om
uitgangsbestanden op te bouwen, waarbij soms impliciet bepaalde conversieprogrammatuur
kan worden getest. Met het gebruik van productiegegevens wordt voornamelijk het
zogenaamde goedpad getest. Aan het gebruik van productiegegevens kleeft echter een
aantal nadelen namelijk:
• Vaak is onbekend welke testsituaties de gegevens dekken;
• Het is niet altijd toegestaan om met productiegegevens te testen bijvoorbeeld i.v.m.
privacy wetgeving;
• Het schijfruimtebeslag kan erg groot zijn.
testplan vastgelegde procedures.
Zodra de uitgangsbestanden zijn opgebouwd en gecontroleerd, wordt een back-up gemaakt

zodat de beginstand op ieder moment weer kan worden teruggezet. Voor controle van
uitgangsbestanden kunnen specifieke tools worden ingezet, bijvoorbeeld Querytalen.
Ondanks alle voorzorgen, is het vaak nodig dat eenmaal opgebouwde uitgangsbestanden
nog worden gewijzigd. Met dit versiebeheer moet nu al rekening gehouden worden. Met
name als de gegevens met het te testen informatiesysteem zijn ingevoerd kan het beheer
problemen opleveren.
Technieken

Toelichting
In praktijk blijkt het handig om wijzigingen op de uitgangssituatie te documenteren. Bij de
eerstvolgende gelegenheid waarbij de back-ups van de gegevensbestanden worden
teruggezet kunnen de wijzigingen worden doorgevoerd. Vervolgens kan een nieuwe back-up
worden gemaakt.
Verwijzingen
• Paragraaf 9.2 Definiëren uitgangsbestanden;
• Paragraaf 13.4.6 Testdata generator.
10.5 (Her-) testuitvoering
Doelstellingen
Het verkrijgen van testresultaten op basis waarvan de beoordeling van het testobject kan
plaatsvinden.
Basismateriaal
• Testdraaiboek;
• Testobject;
• Uitgangsdatabases en/of -bestanden.
Producten
• Testobjectbevindingen.
Subtaken
Subtaak 1: Uitvoeren testscripts

De testen dienen te worden uitgevoerd zoals is vastgelegd in het testdraaiboek en in de
testscripts. Indien hiervan wordt afgeweken dient dit duidelijk te worden aangegeven en
onderbouwd, omdat anders de in het testplan vastgelegde strategie wordt ondergraven en
men in feite ongestructureerd aan het testen is. Indien extra tijd beschikbaar is, kunnen
bepaalde testtechnieken worden aangevuld met de error guessing techniek.
Subtaak 2: Uitvoeren statische c.q. indirecte tests

In de teststrategie is vastgelegd of indirect meetbare kwaliteitsattributen, zoals bijvoorbeeld
gebruikersvriendelijkheid, tot het beschouwingsgebied van de uit te voeren testen behoren.
Indien hiervan sprake is, worden deze statische c.q. indirecte testen uitgevoerd aan de hand
van checklists. Op basis hiervan wordt getracht inzicht te krijgen in het betreffende
kwaliteitsaspect.
testplan vastgelegde procedures.
Technieken
• Checklists.
Toelichting
Uiteraard moeten problemen die een verdere testuitvoering in de weg staan, de zogenaamde
testverstorende bevindingen, zo spoedig mogelijk worden opgelost.

Verwijzingen
• De checklists testen, waaronder:
o De Checklist Beveiliging;
o De Checklist Controleerbaarheid;
o De Checklist Gebruikersvriendelijkheid.
10.6 Controleren en beoordelen testresultaten
Doelstellingen
Het analyseren van de verschillen tussen de verkregen testresultaten en de voorspelde
testresultaten.
Basismateriaal
• Testscripts;
• Bevindingen.
Producten
• Testrapportage.
Subtaken
De bevindingen worden in deze subtaak nader geanalyseerd. Waarin ligt de oorzaak van de
afwijking? Bij het bepalen van wat de oorzaken van de eventuele verschillen zijn kan
onderscheid worden gemaakt tussen de volgende typen bevindingen:
Interne bevindingen
Interne bevindingen kunnen door de projectgroep acceptatie zelf worden opgelost. Dit zijn
onder andere:
• Een testuitvoeringsfout: de betreffende test wordt opnieuw uitgevoerd;
• Een testspecificatiefout; de testspecificatie wordt aangepast of zelfs opnieuw opgesteld.
Vervolgens wordt de betreffende test opnieuw uitgevoerd;
• Een beoordelingsfout; de bevinding is onterecht.
Externe bevindingen
Externe bevindingen moeten door derden worden beoordeeld en opgelost. Dit zijn onder
andere:
• Een fout in de testomgeving: na aanpassing door de beheerder van de testomgeving,
wordt de test opnieuw uitgevoerd;
• Een fout of onduidelijkheid in de testbasis: afhankelijk van het belang van de fout wordt
door de begeleidingsgroep beslist of, en zo ja wanneer, de testbasis aangepast zal
worden;
• Een aanvullende wens of eis: naar aanleiding van de testen zijn aanvullende wensen en
eisen ontstaan die niet in de testbasis beschreven staan. Deze wensen en eisen hebben
vaak betrekking op de functionaliteit en inpasbaarheid van het informatiesysteem. De
begeleidingsgroep beslist of, en zo ja wanneer, de testbasis aangepast zal worden op
basis van de wens of eis;

• Een fout in de programmatuur: in principe moeten fouten in de programmatuur vóór het

invoeringsmoment worden opgelost door het ontwikkelteam. De projectgroep acceptatie
kan beslissen van dit uitgangspunt afwijken;
Overige bevindingen
Overige bevindingen bestaan uit fouten of problemen die niet in een van voorgaande
categorieën vallen. Deze zullen door de projectgroep acceptatie, eventueel met de hulp van
derden, moeten worden opgelost.
De testscripts, de testobjectbevindingen en de testresultaten worden uiteindelijk
samengevoegd tot een testrapportage.
Technieken
Toelichting
Verwijzingen
• Subtaak 7 Vaststellen rapportagelijnen van paragraaf 7.5 inrichten organisatie.
10.7 Onderhouden testdraaiboek
Doelstellingen
Het actueel houden van het testdraaiboek zodat te allen tijde duidelijk is welke testscripts en
testen in welke volgorde (nog) moeten worden uitgevoerd.
Basismateriaal
• Testdraaiboek.
Producten
• Geactualiseerd testdraaiboek.
Subtaken
Gedurende de uitvoering van de testen kunnen problemen worden geconstateerd die
gevolgen hebben voor de uitvoering van de testen. Indien een hertest dient te worden
uitgevoerd, dan wordt dit opgenomen in het testdraaiboek. Het is van belang om vast te
stellen op welke wijze de hertest uitgevoerd moet worden. Of het opnieuw uitvoeren van het
testscript geheel of gedeeltelijk moet plaatsvinden is onder meer afhankelijk van:
De ernst van de bevinding(en);
Het aantal bevindingen bij een testscript;
De mate waarin de eerdere uitvoering van het testscript is verstoord door de bevindingen;
Het belang van de module of functie waarop het testscript betrekking heeft.
Het onderhouden van het testdraaiboek is van groot belang. Niet alleen geeft het inzicht in
de nog uit te voeren testscripts en testen. Het vormt tevens de basis voor wijzigingen in de
planning van de taak uitvoering en eventueel de globale planning van het totale testtraject.
Technieken

Toelichting
Verwijzingen
• Paragraaf 9.4 Opstellen testdraaiboek.
10.8 Voortgangsrapportage
Doelstellingen
Het omschrijven van het resultaat van de testen in dusdanige vorm, dat hieruit snel en
gemakkelijk inzicht ontstaat in de voortgang van de testuitvoering.
Basismateriaal
• Testdraaiboek;
• Testresultaten;
• Urenbesteding testers.
Producten
• Voortgangsrapportage.
Subtaken
In het algemeen moeten in de voortgangsrapportage gegevens vermeld worden over de
meest recente rapportageperiode (meestal een week) en gecumuleerd over het hele
testtraject. Tevens moet aangegeven worden of de gegevens betrekking hebben op een
concreet aanwijsbare testeenheid, of op het testproject in het algemeen. Voor de invulling
van deze activiteit wordt verwezen naar de voortgangsrapportage zoals die in het testplan is
vastgelegd bij de projectdocumentatie.
De projectleider acceptatie moet er op anticiperen dat, op verzoek (van de stuurgroep),

binnen 24 uur een voortgangsrapportage gegeven moet kunnen worden met als inhoud:
• Wat is getest van hetgeen in de planning is vastgelegd;
• Wat moet nog getest worden;
• Wat zijn de trends (statistieken);
• Advies over eventuele in productiename in termen van alternatieven, bijvoorbeeld:
• Uitstel;
• Beschikbaar stellen van minder functionaliteit;
• Work-arounds;
• Stoppen met testen.
Technieken
Toelichting
Verwijzingen
Paragraaf 7.6 Definiëren testproducten;
Subtaak 7 Vaststellen rapportagelijnen van paragraaf 7.5 Inrichten testorganisatie.

Onderwerp Hoofdstuk 11. Afronding Datum 05-01-2001
11. Fase Afronding

1. eva lu at ie 2 .ev a l u at i e 3 . o p s te l l en
t e st o b j e c t t e st p r o ce s e in d r ap p o r t
5 . d e ch ar g e
p r o j e ct g r o e p
a cc e p t a t i e
4 . co n se r v e r e n
t e st w a r e
11.1 Evaluatie testobject
Doelstellingen
Het evalueren van de kwaliteit van het testobject en het opstellen van het definitieve vrijgave-
advies.
Basismateriaal
• Bevindingrapportages.
Producten
• Vrijgave-advies.
Subtaken
Op basis van de uitgevoerde testen, de status van de geregistreerde bevindingen en de
testrapportage wordt door de projectgroep acceptatie het definitieve vrijgave-advies
opgesteld. Van belang is om daarbij aan te geven welke testobjectbevindingen, op het
moment van opstellen van het vrijgave-advies, nog niet zijn opgelost en welke risicos daarbij
worden gelopen. Derhalve is een risicorapportage onderdeel van het vrijgave advies. Voor
deze evaluatie kan gebruik gemaakt worden van de Checklist Vrijgave productie.
Technieken
• Checklist Vrijgave productie.
Toelichting
Verwijzingen
• De Checklist Vrijgave productie.
11.2 Evaluatie testproces
Doelstellingen
Het verkrijgen van inzicht in de wijze waarop het testproces is verlopen;

Het verzamelen van ervaringsgegevens ten behoeve van een betere planning en beheersing
van toekomstige testtrajecten.
Basismateriaal
• Testplan;
• Overige planningen;
• Voortgangsrapportages;
• Bevindingrapportages.
Producten
• Evaluatie testproces;
• Ervaringsgegevens statistieken;
• Kosten/baten analyse.
Subtaken
Subtaak 1: Evalueren testproces

Aan het einde van de taak uitvoering kan worden vastgesteld hoe het testproces is verlopen
en wat de kwaliteit van het testobject is. Van belang hierbij is de evaluatie van het testplan,
de teststrategie en de gehanteerde methoden en technieken. Voor deze evaluatie kan
gebruik worden gemaakt van de Checklist Evaluatie testproject.
Subtaak 2: Verzamelen ervaringsgegevens

Op basis van de uitgevoerde testen worden ervaringsgegevens verzameld en
samengevoegd. In het kader van deze deelactiviteit zijn o.a. de volgende gegevens van
belang:
• Aantal geconstateerde fouten;
• Tijdsduur per activiteit;
• Aantal hertesten.
Voor een uitgebreide opsomming van de mogelijk te verzamelen ervaringsgegevens kan
gebruik worden gemaakt van de Checklist Testmetrieken.
Subtaak 3: Verzamelen statistische informatie

Op basis van de voortgangsrapportages, testrapportages etc. kunnen statistieken worden
vervaardigd, zodat m.b.v. statistische methoden inzicht wordt verkregen in de kwaliteit van
het informatiesysteem. Een voorbeeld van statistische informatie is:
• Totaal gevonden problemen;
• Totaal openstaande problemen;
• Totaal geplande en uitgevoerde testen.
Subtaak 4: Opstellen kosten/baten analyse

Het opstellen van een kosten/baten analyse is een lastige maar leerzame activiteit.
De kosten van een testtraject zijn relatief eenvoudig vast te stellen. Het is namelijk een
optelsom van de kosten van de gebruikte resources en de kosten van de inzet van mensen
en middelen.

De baten zijn veel lastiger te bepalen. Denk bijvoorbeeld aan de kosten van het niet kunnen
gebruiken van een informatiesysteem of de kosten van herstel van zowel programmatuur als
gegevens. Ook het voorkomen van een slechtere functionele ondersteuning, waardoor door
gebruikers meer (kostbaar) handwerk moet worden verricht om hetzelfde eindresultaat te
bereiken, draagt bij aan de baten. Sommige baten zijn moeilijk in geld uit te drukken maar
kunnen desondanks zeer waardevol zijn.
Technieken
• Checklist Evaluatie testproject;
• Checklist Testmetrieken.
Toelichting
Verwijzingen
• Subtaak 7: Vaststellen rapportagelijnen van paragraaf 7.5 Inrichten testorganisatie
• Paragraaf 7.9 Opstellen begroting;
• De Checklist Evaluatie testproject;
• De Checklist Testmetrieken.
11.3 Opstellen eindrapport
Doelstellingen
Het opstellen van het eindrapport en de eventuele presentatie daarvan aan de stuurgroep;
Het informeren van de stuurgroep over de kwaliteit van het testobject;
Het geven van een evaluatie m.b.t. het testtraject.
Basismateriaal
• Evaluatie testproces;
• Ervaringsgegevens statistieken;
• Kosten/baten analyse;
• Vrijgave-advies.
Producten
• Eindrapport.
Subtaken
Subtaak 1: Opstellen eindrapport

Het eindrapport dient een beeld te geven van het verloop van de test en een risicoschatting
van de projectgroep acceptatie met betrekking tot het in productie nemen van het
informatiesysteem. De eindrapportage wordt vastgelegd in een eindrapport.
De hoofdstuk indeling van het eindrapport is als volgt:
• Algemeen
• Vrijgave-advies
• Evaluatie testobject
• Evaluatie testproces
• Resultaten
• Bijlagen.

Subtaak 2: Verspreiding eindrapport

Stel het eindrapport beschikbaar aan de stuurgroep en andere direct en indirect betrokkenen
bij het testproject om hen bekend te maken met de resultaten. Geef eventueel een
presentatie van de resultaten aan de stuurgroep.
Technieken
Toelichting
Het is van groot belang dat voldoende tijd wordt uitgetrokken om deze activiteit uit te voeren
anders worden de volgende risicos gelopen:
• De investering die gedaan is tijdens het testtraject, kan bij toekomstig onderhoud niet
volledig en efficiënt benut worden;
• De invoering kan, ondanks de test, dusdanige problemen met zich meebrengen, dat
uitvoering van deze taak in de knel komt als er niet goed gepland is.
Verwijzingen
Paragraaf 11.6 Voorbeeld inhoud eindrapport.
11.4 Conserveren testware
Doelstellingen
Het selecteren en completeren van de testware welke als regressieve testware gaat
functioneren bij toekomstige (onderhouds)testen van het betreffende informatiesysteem.
Basismateriaal
• Testspecificaties en testscripts;
• Testdraaiboek;
• Testresultaten;
• Uitgangsdatabases- en bestanden;
• Testdossier.
Producten
• Paklijst testware;
• Gearchiveerde testware.
Subtaken
Subtaak 1: Opstellen paklijst testware

In overleg met de functioneel applicatiebeheerder (FAB) van het informatiesysteem wordt
geïnventariseerd welke testware moet worden geconserveerd. De op te leveren
testproducten worden vastgelegd in een zogenaamde paklijst. Deze lijst is een
deelverzameling van de testproducten, zoals vastgelegd in de paragraaf Testproducten van
het testplan. Het is van belang aan te geven op welke wijze deze testproducten tot stand zijn
gekomen, om toekomstig onderhoud op de juiste wijze uit te kunnen voeren. Hierbij moet
met name gedacht worden aan de gehanteerde testspecificatietechnieken en testtools.
Subtaak 2: Verzamelen en bijwerken testware

De over te dragen testware moet daar waar nodig worden gecompleteerd en aangepast. Met
name gedurende de laatste spannende fase van de uitvoering, komt het voor dat
aanpassingen ten aanzien van de testware worden uitgesteld. Voor overdracht aan de
toekomstige FAB dient te worden gezorgd voor het alsnog verwerken van de gewenste
aanpassingen.
Subtaak 3: Archiveren en overdracht testware

Tenslotte vindt de daadwerkelijke overdracht van de testware plaats. Conform de paklijst
worden alle geselecteerde producten zowel fysiek (in digitale vorm en op papier) als logisch
(met betrekking tot het beheer) gearchiveerd en overgedragen aan de toekomstig
beheerder(s). Dit kan de technisch of functioneel applicatiebeheerder zijn, maar ook de
verwerkings- of lijnorganisatie.
Technieken
Toelichting
Verwijzingen
Paragraaf 7.6 Definiëren testproducten
11.5 Décharge projectgroep acceptatie
Doelstellingen
Het formeel beëindigen van het testtraject.
Het verlenen van décharge aan de projectgroep acceptatie.
Basismateriaal
• Eindrapport.
Producten
• Décharge verklaring.
Subtaken
Op basis van het eindrapport en de overgedragen testware wordt aan de stuurgroep
gevraagd het testtraject officieel te beëindigen en aan de projectgroep acceptatie décharge
te verlenen. Na het verkrijgen van décharge wordt de projectgroep acceptatie ontbonden.
Technieken
Toelichting
Verwijzingen
Geen specifieke verwijzingen.

11.6 Voorbeeld inhoud eindrapport

In de hierna volgende onderdelen wordt in het kort aangegeven wat in de verschillende
hoofdstukken van het eindrapport moet worden beschreven.
1. Algemeen
In dit hoofdstuk wordt de identificatie van de test en een korte samenvatting van de
resultaten beschreven.
De identificatie van de test moet een referentie naar het testplan en de projectidentificatie
geven. De korte samenvatting moet in enkele zinnen weergeven wat het verloop van de test
is geweest en welke resultaten geboekt zijn.
2. Afwijkingen ten opzichte van het testplan

Alle afwijkingen ten opzichte van het voorgenomen testplan worden in dit hoofdstuk
gespecificeerd. Het gaat hierbij om:
• De testen die wel gespecificeerd zijn maar niet zijn uitgevoerd;
• De testen die wel uitgevoerd zijn maar niet zijn gespecificeerd;
• Afwijkingen in de testinfrastructuur.
Daarnaast worden de redenen omschreven waarom is afgeweken van het testplan.
3. Kwaliteit van het testplan

In dit hoofdstuk worden de bevindingen beschreven ten aanzien van het testplan. De
volgende aspecten moeten hierbij o.a. aan de orde komen:
• Is de juiste strategie gekozen;
• In welke mate is de planning gerealiseerd;
• In welke mate is de begroting in overeenstemming met de uitgaven;
• Welke systeemdelen zijn te veel dan wel te weinig getest.
Tevens kunnen in dit hoofdstuk aanbevelingen worden opgenomen hoe de testspecificaties
opgewaardeerd kunnen worden.
4. Resultaten
In dit hoofdstuk worden (objectief) de resultaten van de testen beschreven aan de hand van
de diverse aantallen zoals:
• Totaal gevonden problemen, eventueel gesplitst per foutsoort;
• Totaal openstaande problemen, gesplitst per foutsoort;
• Totaal geplande en uitgevoerde testen;
• Schatting niet gevonden problemen.
Het bepalen van de hiervoor aangegeven aantallen geschiedt op basis van de
voortgangsrapportages.
Geef van de openstaande problemen de daaraan gerelateerde risicos aan.
Overigens mogen in dit hoofdstuk geen conclusies getrokken worden ten aanzien van de
kwaliteit van de uitgevoerde testen.
5. Evaluatie testobject
Dit hoofdstuk bevat (subjectief) de conclusies met betrekking tot het testobject. Hierbij moet
gebruik gemaakt worden van de acceptatiecriteria zoals deze zijn opgenomen het testplan.
Het is met name van belang de openstaande bevindingen en de daaraan gerelateerde
risicos op te nemen.
De projectgroep acceptatie heeft op basis van deze gegevens het vrijgave-advies opgesteld.
Daarnaast worden aanbevelingen gegeven ten aanzien van toekomstig onderhoud van het
informatiesysteem.

6. Bijlagen
Als bijlagen worden tenslotte nog de volgende gegevens bij het eindrapport gevoegd:
• Lijst van openstaande bevindingen;
• Performance gegevens;
• Etc.

Onderwerp Hoofdstuk 12. Technieken voor testspecificatie Datum 05-01-2001
12. Technieken voor testspecificatie

Dit hoofdstuk geeft een overzicht van de testspecificatietechnieken die toegepast kunnen
worden binnen een test. Met nadruk wordt er op gewezen dat dit hoofdstuk dient voor
referentie en naslag. In de praktijk blijkt dat voor het succesvol toepassen van
testspecificatietechnieken een gedegen opleiding noodzakelijk is.
12.1 Algemeen
12.1.1 Definitie
Een testspecificatietechniek is een gestandaardiseerde manier om vanuit uitgangsinformatie
testgevallen af te leiden.
Deze definitie bevat een drietal delen die belangrijk zijn voor de definitie van een
testspecificatietechniek. Allereerst moet de techniek een gestandaardiseerde manier van
werken vormen. Dit houdt in dat de werkwijze eenduidig bepaald moet zijn en door derden
overgenomen en gecontroleerd kan worden. Een testspecificatietechniek wordt losgelaten op
een bepaalde vorm van uitgangsinformatie, bijvoorbeeld een systeemontwerp of AO-
procedures.
Een testspecificatietechniek heeft als doel testgevallen af te leiden. Afhankelijk van het
uitgangsmateriaal hebben deze testgevallen een technisch, functioneel dan wel procedureel
karakter. De beschrijving en mate van detail kunnen zeer verschillen, maar de structuur van
de testgevallen is steeds gelijk.
Een (elementair) testgeval is opgebouwd uit een drietal delen:
• Een beschrijving van de uitgangssituatie;
• Een beschrijving van de actie (verandering);
• Een beschrijving van het te verwachten resultaat.
Binnen de in dit handboek beschreven testspecificatietechnieken komt deze driedeling

duidelijk naar voren. De uitgangssituatie wordt binnen het testscript vastgelegd in de initiële
gegevensverzameling. De initiële gegevensverzameling bevat een overzicht van die
gegevens die wel en die zeker niet in het uitgangsbestand aanwezig moeten zijn bij het
uitvoeren van deze test.
De door te voeren verandering wordt in het testscript weergegeven als de uit te voeren actie.
Afhankelijk van het kennisniveau van de testers, kan de beschrijving van deze actie meer of
minder gedetailleerd zijn; van het invoeren van een nieuwe klant tot het invoeren van Piet,
Jansen, Straat 1, Plaats, druk hierna op <F10>.
De omvang van een testspecificatie en testscript kan zeer sterk variëren. De doelstelling van
het vastleggen is enerzijds het kunnen overdragen van deze informatie aan een andere
tester. Anderzijds moet de mate van detail zodanig zijn dat het mogelijk wordt onderhoud op
deze testdocumenten uit te voeren.
Het verwachte resultaat wordt in een testscript weergegeven als een uit te voeren controle.
De controle kan in dit geval bestaan uit: Melding: M034: Nieuwe klant ingevoerd. Verschijnt
deze melding dan is het uiteindelijk resultaat gelijk aan de verwachting en is de test
geslaagd.
Bij de testuitvoering worden de acties en controles uitgevoerd in de volgorde zoals ze in het
testscript zijn weergegeven. In theorie voert de tester enkel de vooraf gedefinieerde
testgevallen uit zoals die zijn vastgelegd in de testscripts en het testdraaiboek.

Natuurlijk kan de tester vanuit zijn kennis aanvullende testgevallen definiëren en uitvoeren.
Deze testgevallen kunnen dan worden toegevoegd aan het testscript. De resultaten uit deze
testen worden opgenomen in de reguliere bevindingenprocedure. Met name bevindingen die
voortvloeien uit aanvullende testgevallen moet de projectleider acceptatie zorgvuldig
controleren. Bij deze controle wordt bekeken of de bevinding een fout ten opzichte van de
testbasis is en niet alleen een fout ten opzichte van de verwachting van de tester is.
12.2 Globale werkwijze
12.2.1 Inleiding
Gezien de definitie van een testspecificatietechniek hebben alle testspecificatietechnieken
hetzelfde vertrekpunt en hebben ze het zelfde doel: het bepalen van testgevallen. De wijze
waarop deze testgevallen uit de specifieke uitgangsinformatie wordt afgeleid, is specifiek
voor elke testspecificatietechniek.
Toch is er een globale werkwijze te beschrijven, die een aantal stappen weergeeft, die
binnen alle testspecificatietechnieken terugkomen.
De volgende globale stappen zijn binnen de werkwijze van een testspecificatietechniek te
onderkennen:
1. Bepalen testsituaties;
2. Bepalen logische testgevallen;
3. Fysiek maken logische testgevallen;
4. Bepalen testacties;
5. Bepalen controles;
6. Vaststellen initiële gegevensverzameling;
7. Opstellen testscript.
De testspecificatietechniek levert altijd een tweetal producten op: een testspecificatie en een
testscript.
Een testspecificatie is: een beschrijving van de wijze waarop de logische testgevallen zijn
geselecteerd, alsmede een beschrijving van de logische testgevallen. Een beschrijving van
wat er getest gaat worden.
Een testscript is : opeenvolging van samenhangende acties en controles, gerelateerd aan

fysieke testgevallen, waarvan de volgorde van uitvoering is aangegeven. Een beschrijving
hoe er getest gaat worden.
12.2.2 Bepalen testsituaties

Het doel van deze stap is om de uitgangsinformatie te analyseren en de te testen situaties te
bepalen. De te testen situaties kunnen bijvoorbeeld controles of beslispunten zijn.
De specifieke testspecificatietechniek geeft aan op welke wijze de testsituaties
geïdentificeerd kunnen worden.
12.2.3 Bepalen logische testgevallen

Op basis van de bepaalde testsituaties worden de logische testgevallen bepaald. Een
logisch testgeval is een beschrijving op logisch niveau van een elementair testgeval voor een
specifieke testsituatie. Een voorbeeld van een logisch testgeval is een persoon waarbij de
leeftijd > 18 is en die niet in Amsterdam woont.
De logisch testgevallen worden opgenomen in de testspecificatie zodat latere wijzigingen in
de uitgangsinformatie te herleiden zijn tot wijzigingen in de logische en fysieke testgevallen.

12.2.4 Fysiek maken logische testgevallen

De logische testgevallen kunnen veelal niet direct worden uitgevoerd. De logische
testgevallen zullen hiervoor fysiek gemaakt moeten worden. Bij het bepalen van de fysieke
testgevallen kunnen meerdere logische testgevallen worden gecombineerd tot een fysiek
testgeval. Een logisch testgeval 1: persoon waarbij leeftijd > 18 en woont niet in Amsterdam
en logisch testgeval 2: persoon in het bezit van een auto kunnen worden gecombineerd tot
een fysiek testgeval:
Naam: Jan
Leeftijd 25
Woonplaats Wageningen
Getrouwd Nee
Auto Ja
12.2.5 Bepalen testacties

Op basis van de uitgangsinformatie en de testgevallen worden de acties vastgesteld. Welke
acties moeten worden uitgevoerd en met welke testgevallen. Is het een batch-proces,
kunnen de testgevallen op één scherm worden uitgevoerd of moeten hiervoor tien schermen
worden doorlopen.
De kennis en expertise van de testuitvoerders bepaalt het niveau waarop de acties moeten
worden gedefinieerd. Het uitvoeren van de testen ligt op het kritieke pad van het
ontwikkeltraject. Het uitzoeken en bepalen van informatie moet dus zoveel mogelijk
gebeuren tijdens de fase Specificatie.
12.2.6 Bepalen controles

Na de acties wordt ook vastgesteld wat het te verwachten resultaat zal zijn. Welke controles
moeten bij een actie worden uitgevoerd om vast te stellen of de test succesvol is verlopen.
De controles worden zo specifiek mogelijk gedefinieerd, niet alleen het feit dat een
foutmelding moet volgen, maar indien mogelijk ook de volledige tekst van de foutmelding.
12.2.7 Vaststellen initiële gegevensverzameling

Om de fysieke testgevallen te kunnen uitvoeren zijn bepaalde gegevens nodig. Van een
aantal van deze gegevens is dit reeds expliciet aangegeven door de fysieke invulling van de
determinanten. Determinanten zijn gegevens die van invloed zijn op de verwerking van het
proces. Vaak echter, is het nodig om bepaalde stamgegevens te definiëren naast de
gegevens die primair voor de test noodzakelijk zijn. Vanwege beheer- en hergebruik-
argumenten is het verstandig om deze gegevens vooraf reeds eenmalig te definiëren en
klaar te zetten. Dit in plaats van deze tijdens de test te creëren. Tijdens deze stap wordt de
zogenaamde initiële gegevensverzameling beschreven. Als er gegevens zijn die
tijdafhankelijk zijn, moet dit expliciet worden vermeld zodat daar bij hertesten rekening mee
kan worden gehouden.
De initiële gegevensverzameling wordt zoveel mogelijk met eigenlijke systeemfuncties

binnen het informatiesysteem ingevoerd. Hierdoor vindt een impliciete test plaats op de
werking van deze functies. Door in het testdraaiboek rekening te houden met de initiële
gegevensverzameling, kan het eindresultaat van functie 1 de initiële gegevensverzameling
vormen van functie 2. Hierdoor wordt wel een afhankelijkheid gecreëerd voor het uitvoeren
van deze functies. Bij het opstellen van het testdraaiboek zal een optimale afweging gemaakt
moeten worden.

12.2.8 Opstellen testscript

In het testscript moet worden vastgelegd in welke volgorde de fysieke testgevallen moeten
worden uitgevoerd. Hierbij moet worden gestreefd naar optimale efficiency. Dit betekent dat
er binnen de ruimte die daarvoor beschikbaar is, moet worden gekozen voor de volgorde die
de minste omstellingen ten gevolge heeft. Bijvoorbeeld in- en uitloggen onder verschillende
user-ids of terugzetten van uitgangsdatabases, aangezien dit vaak tijdrovende activiteiten
zijn. Algemene regels zijn hiervoor niet te geven. De aanwezigheid van expliciete
testdeskundigheid is bij deze stap derhalve onontbeerlijk.
Als resultaat van deze stap dient een testscript te worden opgeleverd. Hierin worden de
testacties en controles die dienen te worden uitgevoerd tijdens bij de daadwerkelijke
testuitvoering beschreven. De testspecificaties met daarin een beschrijving van de
testgevallen vormen de basis voor het te vervaardigen testscript.
Het samenstellen van het testscript is relatief eenvoudig. Het is met name het in de goede
volgorde zetten van de tot nu toe verzamelde informatie. Hierbij moet er wel voor worden
gezorgd dat alle testacties en alle controles minstens één keer worden uitgevoerd.
Tevens worden in het testscript de eventuele pré-condities vermeld. De pré-condities van
een testscript zijn de voorwaarden waaraan in de initiële gegevensverzameling voldaan moet
worden voordat het testscript kan worden uitgevoerd. Bijvoorbeeld het bestaan van een
bepaalde offerte. Meestal worden deze condities ingevuld door een voorgaand testscript. De
resultaten van de ene test zijn vaak een pré-conditie voor een andere test.
Als vuistregel geldt dat het aantal pré-condities geminimaliseerd moet worden; op die manier
kunnen testen onafhankelijker van elkaar worden uitgevoerd. Aan de hand van de pré-
condities kan de volgorde waarin de testen uitgevoerd moeten worden, worden vastgesteld.
12.3 Overzicht testtechnieken

Bij een test is een aantal testspecificatietechnieken beschikbaar waaruit gekozen kan
worden. In de strategiebepaling worden de te gebruiken technieken bepaald op grond van de
gedefinieerde kwaliteitsattributen. Later wordt in de fase Voorbereiding de testbasis
beoordeeld, om de bruikbaarheid van de technieken vast te stellen. Zodoende kan daarna
aan de testeenheden, waarin het informatiesysteem is onderverdeeld, één of meerdere
testtechnieken worden toegewezen.
Voor de test zijn de onderstaande testtechnieken te gebruiken:
• Dataflowtest;
• Elementaire vergelijkingentest;
• Gegevenscyclustest;
• Procescyclustest;
• Real-life test;
• Semantische test;
• Syntactische test;
• Error guessing.
De onderverdeling van testtechnieken kan het beste geïllustreerd worden aan de hand van
het drielagenmodel van informatiessystemen
12.3.1 Drielagen model van informatiesystemen

Het drielagenmodel van informatiesystemen gaat ervan uit dat ieder informatiesysteem
bestaat uit drie lagen, te weten de gebruikersinterfase, de functionaliteit en de gegevens.

Gebruiker
De gebruikersinterface is de buitenkant van het systeem, dat deel

Gebruikersinterface van het informatiesysteem wat de gebruiker ziet. Voorbeelden zijn
het scherm en overzichten.
De functionaliteitslaag verwerkt de aangeboden gegevens of haald
Functionaliteit gegevens uit de database op en bewerkt deze. Voorbeelden zijn
berekening en manipulaties
De gegevenslaag bevat de gegevens (database) van het
Gegevens informatiesysteem
Gebruikersinterface
De testtechnieken syntactische test en semantische test richten zich op de
gebruikersinterface. De syntactische test richt zich op de lay-out van schermen en
overzichten, invoercontroles, veldlengte, veldsoort, functietoetsen, knoppen keuzelijsten en
dergelijke. De semantische test richt zich op relaties tussen velden, relaties tussen gegevens
en schermen, relaties tussen schermen en logica op schermen bij het invoeren van
gegevens.
Functionaliteit
De testtechnieken elementaire vergelijkingentest en dataflowtest richten zich op de
functionaliteit. De elementaire vergelijkingentest richt zich op verwerking in detail, functionele
paden, berekeningen en verwerking van gegevens. De dataflowtest richt zich op
gegevensstromen, aansluiting van de functies en relaties tussen functies.
Gegevens
De testtechniek gegevenscyclustest richt zich op de gegevens. De gegevenscyclustest richt
zich op de levensloop van gegevens (creëren, lezen, wijzigen en verwijderen).
Totale systeem
De procescyclustest, real-life test en error-guessing richten zich op het totale systeem. De
procescyclustest richt zich op de inpasbaarheid van het systeem in de administratieve
organisatie, de raakvlakken van het systeem met de handmatige procedures en de
aansluiting van het systeem op de organisatie. Bij de real-lifetest worden werkelijke
productiegegevens gebruikt om de test uit te voeren. De real-lifetest is dus een vorm van
schaduwdraaien en richt zich op load, performance, geschiktheid van de infrastructuur en de
continuïteit van het systeem. Error-guessing is een vorm van ongestructureerd testen waarbij
gegist wordt naar fouten. Er wordt gefocust op de plaats waar de tester verwacht dat het mis
gaat.
De technieken zijn dus als volgt in te delen:
Gebruikersinterface Syntactische test

Semantische test
Functionaliteit Elementaire vergelijkingen test
Dataflowtest
Gegevens Gegevenscyclustest
Totale systeem Procescyclustest
Real-lifetest
Error-guessing

12.4 Beschrijving technieken

De technieken worden in het kort toegelicht met vermelding van het doel, het geschikte
toepassingsgebied, een korte uitleg van het principe en de te meten kwaliteitsattributen met
het soort fouten waar specifiek op gezocht kan worden. Vervolgens worden de verschillende
stappen beschreven om een techniek uit te werken.
12.4.1 Dataflowtest (DFT)
Doel
Uitgangspunt van de dataflowtest wordt gevormd door de gegevensstromen en de
verwerking daarvan. Het is een test waarbij de verwerking door functies en de relaties tussen
functies worden getest.
Kwalificatie
De dataflowtest is een informele testspecificatietechniek, die zowel geschikt is voor on-line
als voor batch-processen. Hoewel er duidelijke richtlijnen zijn hoe testgevallen geselecteerd
worden, is de intuïtie van de tester en zijn begrip van het testobject de basis voor het
selecteren van de testgevallen. Dit heeft als voordeel dat:
• Gebruikers vanuit hun begrip van het informatiesysteem gemakkelijk een goede test
kunnen samenstellen;
• De kwaliteit van de testbasis minder van belang is;
• Met relatief weinig inspanning goede testspecificaties kunnen worden gemaakt.
Nadeel is echter de relatieve onvolledigheid van de test. Voor een meer volledige test is de
Elementaire vergelijkingentest beschikbaar.
Principe
Voor het maken van testgevallen wordt bij de dataflowtest gestart met een inventarisatie van
de relevante begrippen. Per begrip wordt vervolgens bepaald welke waarden de procesgang
beïnvloeden. Op basis hiervan wordt een aantal testgegevens samengesteld. Hiermee is de
basis voor de test gelegd. Door de testgevallen in een uitvoerbare volgorde te zetten en
eventuele voorbereidende acties eraan toe te voegen wordt het testscript verkregen.
Coverage
De dataflowtest geeft een goede dekking voor wat betreft het gebruik van de functionaliteit,
zoals die in de praktijk verwacht wordt, door direct expliciet te meten. Daarbij kan impliciet de
controleerbaarheid gemeten worden door, de in het kader van de controleerbaarheid
genomen maatregelen, met behulp van de aanwezige functionele specificaties vast te
stellen.
Het soort fouten dat met de dataflowtest worden gevonden zijn met name fouten in de
verwerking: worden de gegevens goed gemanipuleerd, worden berekeningen goed
uitgevoerd en sluiten de verschillende functies goed op elkaar aan.
Stappen
De stappen die ondernomen moeten worden om tot een specificatie voor een dataflowtest te
komen zijn:
1. Analyse functiebeschrijving
2. Bepalen testsituaties
3. Bepalen testgevallen
4. Bepalen testacties

7. Opstellen testscript;
Stap 1: Analyse functiebeschrijving
Ter verduidelijking wordt een voorbeeld gebruikt waarbij sprake is van een proces (taak) dat
zich bezighoudt met het uitbrengen en afhandelen van offertes.
Een offerte wordt door een vertegenwoordiger ingebracht, waarbij per artikel een offerteregel
wordt gemaakt. Allerhande variaties met kortingen, leverings- en betalingscondities etc. zijn
mogelijk. De chef van de vertegenwoordiger kan de offerte goedkeuren. Er is dus sprake van
functiescheiding. Zodra de offerte is goedgekeurd, kan hij worden afgedrukt om verstuurd te
worden. Als de offerte is afgedrukt, kan deze niet meer worden gewijzigd. Een
goedgekeurde, dus nog niet afgedrukte, offerte die wordt gewijzigd, krijgt automatisch weer
de status voorlopig. Na verloop van tijd komt er een antwoord van de klant op de verstuurde
offerte, waarbij de offerte de status krijgt gegund of afgewezen.
Stap 2: Bepalen testsituaties

Het bepalen van de te testen situaties begint met een inventarisatie van de gegevens die van
belang zijn bij de uitvoering van de taak. Iedere taak heeft doorgaans een centraal begrip, in
het voorbeeld vanzelfsprekend de offerte. Voor iedere taak moeten de relaties van het
centrale begrip met andere van belang zijnde begrippen, de zogenaamde randbegrippen,
worden vastgelegd.
Het bepalen van de centrale- en randbegrippen is de bron voor de uit te voeren dataflowtest
en moet daarom zorgvuldig gebeuren. Het centrale begrip ligt doorgaans redelijk voor de
hand. Als dat niet het geval is, dan zijn de taken waarschijnlijk niet goed uitgesplitst. Alvorens
de randbegrippen te bepalen moet eerst worden bekeken of het centrale begrip verder
uitgesplitst dient te worden. Vervolgens kan worden geïnventariseerd welke randbegrippen
het gedrag van het systeem beïnvloeden. Voor de te testen taak zijn nu het centrale begrip
en de daarbij behorende randbegrippen bekend.
De te onderscheiden waarden per begrip moeten worden vastgesteld in relatie tot het
centrale begrip. Hierbij is het niet zo belangrijk naar verschillende mogelijke waarden te
zoeken (bijvoorbeeld voor valuta fl. en $), maar moet veel meer naar verschillende
statuswaarden worden gezocht (bijvoorbeeld wel/niet default, wel/niet bekend in het
systeem). Denk hierbij ook aan de illegale waarden!
Soms kan het voorkomen dat een randbegrip zo belangrijk is, dat het verder uitgewerkt moet
worden. Dit is te zien in het onderstaande voorbeeld met testsituaties waarin offerteregel
nader is uitgewerkt:
Begrip Relatie met Waarden

Offerte - Voorlopig, goedgekeurd, afgedrukt, gegund,
afgewezen
afnemer wel of niet bekend in systeem
offerte-adres wel/niet aanwezig
offerteregel aantal: 0, 1, >2 schermen
verkoopkorting wel/niet invullen
betalingscondities wel/niet default uit afnemersgegevens
leveringscondities wel/niet default uit afnemersgegevens
Offerteregel -
prijs wel/niet default
regelkorting wel/niet aanwezig
regeltekst wel/niet invoeren

Stap 3: Bepalen testgevallen

Op basis van de hiervoor beschreven testsituaties worden vervolgens testgevallen bepaald.
Bij het bepalen van de testgevallen moet er voor worden gezorgd, dat alle testsituaties
(waarden) minstens eenmaal voorkomen. Een belangrijke beperking is gelegen in het feit dat
de verschillende testsituaties elkaar vaak uitsluiten. Bij twijfel is het vaak zinvol om extra
testgevallen te maken, om te voorkomen dat dit gedurende de uitvoering van de test nog
moet gebeuren.
Testgeval Offerte-1 Offerte-2 Offerte-3

Offerte:
Afnemer AFN_1 nieuw AFN_2
Offerte-adres aanwezig invoeren invoeren
Verkoopkorting invoeren invoeren niet
Betalingscondities default invoeren default overschrijven
Leveringscondities default invoeren default overschrijven
Offerteregel:
Artikel aantal 0 1 >2 schermen
prijs - wel wel/niet default
regelkorting - wel wel/niet aanwezig
regeltekst - niet wel/niet invoeren
Stap 4: Bepalen testacties

Als de testgevallen bepaald zijn kunnen, mede op basis daarvan, de testacties worden
beschreven. Een testactie is een vooraf gedefinieerde actie die goed of fout kan verlopen (de
feitelijke test). Per begrip moet worden bekeken welke functies hierop van toepassing zijn.
Hierbij moet gedacht worden aan zaken zoals invoeren, wijzigen, verwijderen, raadplegen,
afdrukken en het wijzigen van de status. Ook moeten de functies die verband houden met
een tijdscyclus (dag/week/maand/jaarafsluiting) niet worden vergeten.
Vanuit de begrippen, in combinatie met de mogelijke functies, moeten de testacties worden
bepaald. Dit leidt tot:
1. Invoeren
001 Voer in offerte-1
2. Wijzigen
003 Status voorlopig
004 Status goedgekeurd (niet afgedrukt)
005 * Status afgedrukt
006 * Status gegund
007 * Status afgewezen
3. Afbeelden offerte
008 Afbeelden offerte
4. Afdrukken offerte
009 * Status voorlopig
010 Status goedgekeurd
011 * Status afgedrukt
012 * Status gegund
5. Overzicht offerte
013 Overzicht offertes na invoeren
014 Overzicht offertes met gemengde status
6. Fiatteren offerte

van status naar status

015 Voorlopig goedgekeurd
016 ……..
Een * geeft aan dat er na de betreffende actie een foutboodschap dient te volgen
Stap 5: Bepalen controles

Per actie dient aangegeven te worden op welke wijze gecontroleerd kan worden of de
verwerking correct is verlopen. De diverse resultaten kunnen eventueel in deze stap worden
berekend. Dit leidt tot de volgende controles:
C01 Totaal bedrag offerte op scherm bij regelinvoer, wijziging en verwijdering

C02 Volledigheid bij afdrukken
C03 Offertenummer ophogen in stuurgegevens
C04 ……...
Stap 6: Vaststellen initiële gegevensverzameling

Op basis van het voorbeeld leidt dit tot de volgende initiële gegevensverzameling:
Afnemers :
• AFN_1 t.b.v. testgeval Offerte-1
• AFN_2 t.b.v. testgeval Offerte-2
Artikelen :
• ……........
Stap 7: Opstellen testscript

Zie paragraaf 12.2.8 Opstellen testscript.
Testuitvoering en beoordeling
De uitvoering van de test gebeurt aan de hand van de testscripts die in de juiste volgorde
dienen te worden uitgevoerd. De volgorde van uitvoering is vastgelegd in het testdraaiboek.
Eventuele tekortkomingen met betrekking tot de testspecificatie, het testscript of de initiële
gegevensverzameling moeten worden vastgelegd. Voor de volgende testcyclus moet de
initiële gegevensverzameling worden ge-restored, aangepast en weer ge-saved.
Het beoordelen van de dataflowtest is niet altijd triviaal ondanks de controles die expliciet zijn
gemaakt. Vaak treden onverwachte fouten op, die onderzocht moeten worden. Hierbij is de
herhaalbaarheid van de test en dus de reproduceerbaarheid van de testresultaten van groot
belang.
De rapportage kan gebeuren door middel van het testdraaiboek. In het kader hiervan wordt
een tweetal kolommen opgenomen: Ok en Bevindingnummer. In de kolom Ok wordt met J
(geen fout bevonden) of N (wel een fout gevonden) het testresultaat aangegeven, terwijl
onder de kolom Bevindingnummer het nummer van de bevinding wordt vermeld.
Een overall beoordeling met betrekking tot het uitgevoerde testscript kan eveneens worden
opgenomen in het testscript.
12.4.2 Elementaire vergelijkingentest (EVT)
Doel
De Elementaire vergelijkingentest is een testspecificatietechniek waarbij de verwerking
gedetailleerd wordt getest. De test verifieert alle functionele paden van een functie.

Kwalificatie
De Elementaire vergelijkingentest is een formele testspecificatietechniek, die een goede
mate van volledigheid garandeert, maar daardoor juist zeer tijdsintensief is. Daarom moet
deze testspecificatietechniek vooral worden gebruikt bij het testen van functies en/of
complexe berekeningen waaraan een groot belang is toegekend. De methode kan zowel in
een batch als in een on line omgeving worden toegepast.
Principe
De Elementaire vergelijkingentest stelt hoge eisen aan de gedetailleerdheid van de
uitgangsdocumentatie. De specificaties worden namelijk opgesteld door eerst alle functionele
condities te inventariseren en te ontleden tot vergelijkingen in pseudo-code. Indien de te
ontleden documentatie wollige teksten bevat of erg versnipperd is, is dit bepaald geen
sinecure. Vervolgens kunnen voor de verschillende functionele paden, welke worden
onderscheiden binnen de vergelijkingen, testgevallen gedefinieerd worden.
Coverage
De functionaliteit zoals die in de documentatie verwoord is wordt direct expliciet gemeten.
Net als bij de dataflowtest geldt dat de controleerbaarheid impliciet gemeten kan worden
door de juistheid en volledigheid van de opzet te beoordelen op grond van de gemaakte
testspecificaties.
Het soort fouten dat met de Elementaire vergelijkingentest kunnen worden gevonden zijn
met name fouten in de verwerking, de gegevens manipulatie en in (complexe) berekeningen.
Stappen
De stappen die ondernomen moeten worden om een Elementaire vergelijkingentest uit te
kunnen voeren zijn:
1. Analyse functiebeschrijvingen;
3. Bepalen testgevallen;
4. Opstellen matrix testsituaties - testgevallen
5. Bepalen testacties;
In het navolgende zijn de hiervoor genoemde stappen nader uitgewerkt. Op basis van de
resultaten van de stappen 1 t/m 7 ontstaat een testspecificatie.
Ter verduidelijking wordt in deze paragraaf het volgende contributie voorbeeld gebruikt:
De jaarlijkse contributie van een club bestaat uit drie onderdelen: de basis contributie, de
competitiebijdrage en de opslag voor zaaltraining.
Voor leden jonger dan 18 jaar is de basiscontributie fl. 200,=. Andere leden betalen fl. 250,=.
Als een speler ingedeeld is in een competitieteam of hij / zij mee wil doen aan toernooien
betaald hij/zij bijdrage aan de bond van fl. 75,=.
Als het lid ook zaaltraining volgt of als hij / zij in het eerste team zitten betalen een opslag
van fl. 100,=. De spelers van het eerste betalen de opslag overigens alleen als ze meer dan
fl 50.000
per jaar verdienen.
Stap 1: Analyse functiebeschrijvingen

Bij de functiebeschrijving is een paragraaf verwerking opgenomen, welke op een eenduidige

wijze de beslispaden e.d. dient te beschrijven. Dit kan bijvoorbeeld hebben plaatsgevonden
middels pseudo-code, zoals in het onderhavige voorbeeld. Indien de beschrijving middels
een andere testspecificatietechniek heeft plaatsgevonden, bijvoorbeeld de beslissingstabel,
is de EVT eveneens toepasbaar. Het belangrijkste is de aanwezigheid van een eenduidige
beschrijving van de verwerkingspaden.
Alvorens bepaald kan worden welke situaties uiteindelijk getest dienen te worden, moet een
analyse van de verwerking, in het voorbeeld beschreven in pseudo-code, plaatsvinden. Bij
pseudo-code worden de condities aangegeven met behulp van ALS, DAN en ANDERS Deze
worden er één voor één uitgelicht en voorzien van een unieke identificatie waarna de te
testen situaties worden bepaald.
C1 ALS leeftijd < 18

DAN contributie = fl 200
ANDERS contributie = fl 250
C2 ALS speler = competitie of toernooi = J

DAN bondsbijdrage = fl 75
ANDERS = 0
C3 ALS training = zaal of (team = eerste en inkomen > fl 50.000)

DAN opslag = fl 100
ANDERS opslag = 0
Stap 2: Bepalen testsituaties

Nadat de condities zijn geïdentificeerd (hierboven in het voorbeeld aangegeven met C1, C2
en C3) moet per conditie worden bepaald welke situaties moeten worden uitgetest. Hiervoor
is het van belang een onderscheid te maken tussen enkelvoudige en samengestelde
condities. Enkelvoudige condities bestaan uit slechts één vergelijking, de zogenaamde
elementaire vergelijking. Een voorbeeld hiervan is de conditie C1. Samengestelde condities
zijn condities die uit meerdere vergelijkingen bestaan waartussen een EN- of een OF-relatie
aanwezig is. Een voorbeeld hiervan is de conditie C2.
Enkelvoudige condities leiden tot twee testsituaties, namelijk de situatie waarin de

vergelijking waar is en de situatie waarin de vergelijking onwaar is. In het voorbeeld leidt dit
tot de volgende testsituaties voor conditie C1:
Testsituatie testsituatie 1.1 testsituatie 1.2

waar Onwaar
Leeftijd < 18 jaar ≥ 18 jaar
Bij samengestelde condities worden bij een EVT de testsituaties zodanig gekozen dat
aangetoond wordt dat veranderen van waarde van iedere afzonderlijke vergelijking, de
uitkomst van de samengestelde conditie van waarde doet veranderen.
Hiermee is het aantal testsituaties geminimaliseerd tot het aantal afzonderlijke vergelijkingen
plus één (= geen verandering).
Dit betekent dat bij een OF-relatie de situatie waar-waar en bij de EN-relatie de situatie
onwaar-onwaar niet wordt getest. De kans dat hierin een fout wordt gevonden die nog niet is
geconstateerd bij de situaties waar-onwaar of onwaar-waar is minimaal. Schrijven we nu
voor onwaar een 0 en voor waar een 1 dan kunnen we als volgt samenvatten:

A of B C en D
0 0 0 0 0 0
1 0 1 1 0 0
0 1 1 0 1 0
1 1 1 1 1 1
De onderstreepte waarde zijn de zogenaamde kritieke waarde, als die veranderen,

veranderd de uitkomst. Bij de OF-situatie heeft de 1 1 geen kritieke waarde, bij de EN-
situatie de 0 0. Daarom testen we deze situatie niet
Conditie C2 van het voorbeeld levert zo de volgende testsituaties op:
Testsituatie testsituatie 2.1 testsituatie 2.2 testsituatie 2.3

Speler ≠ competitie = competitie ≠ competitie
Toernooi ≠J ≠J =J
Bij samengestelde condities met uitsluitend EN- of OF-relaties zijn de testsituaties eenvoudig
te vinden. Lastiger wordt het als de samengestelde conditie bestaat uit een combinatie van
een of meerdere EN- én OF-relaties, zoals in het voorbeeld bij C3. In zulke gevallen maken
we gebruik
Van substitutie. De conditie wordt in twee of meer condities onderverdeeld, deze worden
apart opgelost en weer samengevoegd:
A of (B en C)
A of D B en C = D
0 0 0 0 0 0
1 0 1 1 0 0
0 1 1 0 1 0
1 1 1 1 1 1
D is de uitkomst voor B en C, D wordt dus vervangen door de waarde van B en C. Daar waar
D in de vergelijking kritiek is worden alle mogelijke waarde ingevuld.
A of (B en C)
0 1 0 0
0 0 1 0
1 1 0 1
0 1 1 1
Voor C3 uit het voorbeeld dan krijgen we het volgende:
Testsituatie testsituatie 3.1 testsituatie 3.2 testsituatie 3.3 testsituatie 3.4

Training ≠ zaal ≠ zaal = zaal ≠ zaal
Team = eerste ≠ eerste = eerste = eerste
Inkomen = 50.000 > 50.000 = 50.000 > 50.000
Stap 3: Bepalen testgevallen

Bij het bepalen van de testgevallen moet gezocht worden naar die functionele paden door de
functie, waarbij elke situatie van iedere conditie minimaal één keer doorlopen wordt.

Testgeval 1 2 3 4
Leeftijd 17 18 1 100
Speler Recreant Competitie Recreant Recreant
Toernooien N N J J
Training Veld Veld Zaal Veld
Team Eerste Tweede Eerste Eerste
Inkomen 50.000 50.001 49.999 51.000
De testsituaties waren nog in logische termen (met =, ≠, < en dergelijke) aangegeven. Dit
vereenvoudigd het onderhoud. De testgevallen zijn feitelijk combinaties van de testsituaties.
Deze kunnen eerst als logische testsituaties worden opgezet en dan fysiek (met werkelijke
waarden) worden gemaakt. In het voorbeeld zijn ze direct fysiek gemaakt.
Alle testsituaties moeten minimaal 1 keer voorkomen. Omdat een testgeval alle items van
vergelijkingen (leeftijd, speler enzovoort) moeten sommige waarden “opgevuld” worden.
Deze zijn cursief gedrukt.
Stap 4: Opstellen matrix testsituaties – testgevallen.

Een hulpmiddel bij het vinden van de testgevallen en een controlemiddel of alle situaties in
de testgevallen zijn opgenomen is het gebruik van een matrix. Hierin worden in de eerste
kolom alle gedefinieerde testsituaties opgenomen. Vervolgens worden de testgevallen
vermeld. Als de testgevallen goed zijn gedefinieerd zullen alle te testen situaties minimaal
een keer aangekruist zijn.
De matrix van het contributie voorbeeld ziet er als volgt uit:
Testgeval: 1 2 3 4
Testsituatie
C1.1 X X
C1.2 X X
C2.1 X
C2.2 X
C2.3 X X
C3.1 X
C3.2 X
C3.3 X
C3.4 X
Bij grote matrices kan voor het overzicht nog een kolom toegevoegd worden waarin een
totaaltelling van het aantal kruisjes opgenomen wordt. Deze mag dan niet nul zijn.
Sommige situaties zullen meerdere malen worden getest. Dit is vaak onvermijdelijk en
uiteraard niet bezwaarlijk.
Stap 5: Bepalen testacties

Als de testgevallen bepaald zijn kunnen, mede op basis daarvan, de testacties worden
bepaald. Een testactie is een vooraf gedefinieerde actie die goed of fout kan verlopen (de
feitelijke test). Hiertoe worden allereerst de deeltaken (functies) geïnventariseerd die van
belang zijn. Doorgaans zijn dit zaken als creëren, wijzigen, accorderen, afbeelden,
verwijderen, etc.

De vraag is echter of in dit voorbeeld sprake is van testacties. Dit is afhankelijk van de vraag
hoe de contributie berekend wordt. Dit kan plaatsvinden na het invoeren van een persoon:
m.a.w. persoonsgegevens worden ingevoerd en het systeem berekent aan de hand van de
ingevulde gegevens de contributie. Een tweede mogelijkheid is echter dat een batchproces
de contributie voor alle personen ineens berekent.
Als er sprake is van de eerste optie zullen voor het invoeren van de personen testacties
opgevoerd moeten worden. Immers de controles kunnen alleen plaatsvinden nadat een
persoon is ingevoerd. In de tweede situatie kan worden volstaan met het vervaardigen van
een initiële gegevensverzameling. De personen worden éénmalig ingevoerd waarna de
gegevensverzameling wordt bewaard als testset. Iedere keer dat de batch opnieuw getest
moet worden, wordt de testset geladen en wordt de batch gedraaid. De resultaten hiervan
worden vervolgens gecontroleerd.
Bij dit voorbeeld wordt er vanuit gegaan dat er sprake is van een batch die de contributie
voor alle personen ineens berekent.
Er is sprake van een batch-job, zie Stap 7: Vaststellen initiële gegevensverzameling.
Stap 6: Bepalen controles

Er moet beschreven worden wat gecontroleerd dient te worden en hoe, opdat er kan worden
vastgesteld of de verwerking correct is verlopen. De diverse resultaten worden in deze stap
van tevoren berekend.
Dit leidt tot de volgende controles:
C01 Testgeval 1 contributie: = 200


De vulling van de database is afhankelijk van de entiteiten en attributen die in de database
zijn gedefinieerd. In het voorbeeld ziet de vulling van de database er als volgt uit:
Entiteit Leden
Lid_id 1 2 3 4
Naam Eerste Tweede Derde Vierde
Geboortedatum 1-1-1983 1-1-1982 1-1-1999 1-1-1900
Srt_speler R C R R
Toernooi N N J J
Zaaltraining N N J N
Inkomen 50000 50.001 49.999 51.000
Entiteit Teams
Team_id 1 2
Team Eerste Tweede
Entiteit Teamindeling
Team_id 1 2 1 1
Lid_id 1 2 3 4

Op basis van de testgevallen wordt een testscript opgesteld waarin de volgordelijk uit te
voeren testacties en de controles dienen te zijn beschreven. Tevens worden in het testscript
de eventuele pre- en postcondities vermeld. Een preconditie bij testscript X kan bijvoorbeeld
zijn dat testscript Y volledig is uitgevoerd of dat de systeemdatum(zoals in dit voorbeeld) op
een bepaalde waarde staat.
Aangezien er in dit voorbeeld sprake is van een batchverwerking, blijft het testscript relatief
simpel. Alleen het opstarten van de betreffende batch staat er in vermeld en de controles die
daarop moeten worden uitgevoerd.
12.4.3 Gegevenscyclustest (GCT)
Doel
Met de Gegevenscyclustest wordt de volledigheid en de logica van de gegevens getest.
Gegevens ontstaan, worden gelezen, worden gewijzigd en verdwijnen uiteindelijk weer, in
het Engels: Create, Retrieve, Update, Delete (CRUD). Deze levenscyclus van gegevens
wordt vaak vastgelegd in een zogenaamde CRUD-Matrix.
Kwalificatie
De Gegevenscyclustest is een informele testspecificatietechniek die zowel geschikt is voor
batch als on-line functies. Door de CRUD-matrix uit te breiden van functie niveau naar
systeembreed, kan de integratie tussen de verschillende functies getest worden.
Principe
Door per proces te inventariseren welke gegevens op wat voor manier worden gebruikt en
vervolgens per gegeven te sorteren kan eenvoudig inzicht worden verkregen in de
levensloop van de gegevens. Op basis hiervan kunnen testgevallen worden gecreëerd om te
verifiëren dat de verschillende processen de gegevens correct gebruiken.
Coverage
Het soort fouten dat wordt gevonden zijn voornamelijk de ontbrekende stappen in de CRUD-
matrix en fouten in de referentiële integriteit. De functionaliteit van de levensloop van
gegevens wordt direct expliciet gemeten.
Stappen
De stappen die moeten worden ondernomen om tot een Gegevenscyclustest te komen zijn:
Inventariseren CRUD-matrix en relatiecontroles;
1. Vervaardigen testgevallen per entiteit;
2. Vaststellen testacties en controles;
In het navolgende zijn de hierboven genoemde stappen nader uitgewerkt.
Stap 1: Inventariseren CRUD-matrix en relatiecontroles

De testbasis wordt bestudeerd, met als doel vast te stellen welke beheerfuncties aanwezig
zijn. Per onderkende functie wordt bepaald welke acties (invoeren, raadplegen, wijzigen en
verwijderen) door de betreffende functie worden uitgevoerd en met betrekking tot welke
entiteiten. De aanwezigheid van een CRUD-matrix maakt de uitvoering van deze activiteit
uiteraard een stuk eenvoudiger. In principe levert het eerste deel van deze activiteit een
CRUD-matrix op.

Het opstellen van een CRUD-matrix is overigens, ook zonder een eventueel gebruik door de
projectgroep acceptatie, een zinvolle bezigheid. Bij het ontwerpen van een
informatiesysteem wordt veelal vanuit de functies geredeneerd; per functie is beschreven
welke gegevens worden gebruikt. Bij het opstellen van een CRUD-matrix wordt vanuit de
gegevens geredeneerd; per entiteit wordt beschreven welke functies op welke wijze de
betreffende entiteit gebruiken. Door het opstellen van een dergelijke cross-reference tabel
(CRUD-matrix) komen soms onduidelijkheden en/of onvolledigheden aan het licht die bij een
functie gerichte benadering waarschijnlijk niet worden gevonden en nu reeds in een
vroegtijdig stadium worden ontdekt!
Entiteit 1 Entiteit 2 Entiteit n

Functie 1 Read Create, Update, Delete -
Functie 2 Create Read -
Functie 2 Create, Update, Delete - -
In het algemeen zal er door één beheerfunctie een zeer beperkt aantal entiteiten tegelijk
worden onderhouden. De CRUD-matrix heeft voor deze functies een zeer eenvoudige
weergave. Bij het uitvoeren van de Gegevenscyclustest met betrekking tot de primaire
gegevens van het informatiesysteem is een uitgebreidere CRUD-matrix noodzakelijk, hierin
komen namelijk meer functies voor.
Nadat de CRUD-matrix is opgesteld, wordt de testbasis opnieuw bestudeerd. Nu met als

doel de plaatsen binnen het informatiesysteem te bepalen waar de referentiële
relatiecontroles plaatsvinden. Referentiële relatiecontroles zijn controles tussen meerdere
entiteiten. Bijvoorbeeld als een KLANT wordt verwijderd moeten ook de betreffende
KLANT_ADRESSEN worden verwijderd of de geldigheidsperiode van een KLANT_ADRES
mag geen overlap hebben met de geldigheidsperiode van een ander KLANT_ADRES.
Stap 2: Vervaardigen testgevallen per entiteit

Voor elke entiteit worden testgevallen vervaardigd. De acties worden in principe in de
navolgende basisvolgorde geplaatst:
• Create, Read;
• Update, Read;
• Delete, Read.
Een testgeval bestaat uit derhalve:

• Het invoeren van gegevens (per creëermogelijkheid één testgeval);
• Het wijzigen (per wijzigingsmogelijkheid één testgeval);
• Het verwijderen (met elke verwijderfunctie) van gegevens;
• Na elke actie met de raadpleegfunctie de gegevens controleren.
Uit de geïnventariseerde relatiecontroles komen uiteraard nadere aanvullingen en varianten.
Stap 3: Vaststellen testacties en controles

De controle van de verwerking is in elk testgeval geïntegreerd, doordat na elke
onderhoudsactie een raadpleegactie is vermeld. De gegevens worden met elke
creëermogelijkheid dus eerst gecreëerd, vervolgens met elke raadpleegfunctie gelezen om
te controleren of de gegevens juist en volledig zijn gecreëerd. Nadat de gegevens met elke
wijzigingsmogelijkheid een keer zijn gewijzigd, worden de gegevens met een functie die met
Read in de CRUD-matrix is aangegeven geraadpleegd, om te controleren of de wijziging juist
heeft plaatsgevonden. Tenslotte worden de gegevens met elke mogelijke verwijderfunctie
verwijderd en wordt ook hier, met behulp van een raadpleegfunctie, een controle uitgevoerd.

Bij het testen van de entiteiten met betrekking tot beheerfunctie(s) wordt ook met minimaal
één andere functie gecontroleerd of de gegevens elders in het informatiesysteem bruikbaar
zijn. Met betrekking tot deze functies wordt een korte test uitgevoerd. Vaak betreft het slechts
het uitvoeren van raadpleeg acties.
Het is belangrijk dat bij het raadplegen niet slechts wordt gecontroleerd of de gegevens
correct zijn verwerkt, maar ook wordt gecontroleerd dat:
• alle beperkingen (consistentiecontroles van het gegevensmodel) op het invoeren,
wijzigen en/of verwijderen zijn opgespoord, beschreven en getest. Bijvoorbeeld een
landcode mag pas worden verwijderd als er geen crediteuren of debiteuren van die
landcode (meer) gebruik maken.
• met betrekking tot alle functies die volgens de CRUD-matrix van de entiteit gebruik
maken (dus ook de batch-functies) een testactie is gedefinieerd.

Zie paragraaf 12.2.7 Vaststellen initiële gegevensverzameling.

12.4.4 Procescyclustest (PCT)
Doel
De Procescyclustest heeft tot doel de inpasbaarheid van het geautomatiseerde deel van het
informatiesysteem binnen de AO-procedures te controleren.
Kwalificatie
De Procescyclustest kijkt met name naar de raakvlakken (interfaces) tussen de
geautomatiseerde processen en de handmatige procedures. De aanname hierbij is dat de
geautomatiseerde processen op zich conform de specificaties werken. De PCT is een
formele structuurtest: de testgevallen komen voort uit de structuur van de procedure flow (net
zoals in een programmatest de testgevallen voortkomen uit de structuur van het algoritme)
en niet uit de (bewerkingen binnen de) specificaties. Dit kan zowel voor on-line als batch-
processen worden gehanteerd.
Principe
Doordat tijdens de PCT geverifieerd wordt of de geautomatiseerde processen aansluiten op
de handmatige procedures en vice versa, wordt antwoord verkregen op de volgende vragen:
• Geven de geautomatiseerde processen voldoende informatie om alle handmatige
procedures te kunnen uitvoeren?
• Levert de uitvoer van de handmatige procedures voldoende gegevens op om alle
geautomatiseerde processen te kunnen starten?
• Beschikken de uitvoerenden over voldoende autorisatie om de procedures te kunnen
uitvoeren?
Ieder testgeval bestaat derhalve uit een groep opeenvolgende acties, die tezamen precies
een pad door de procedure flow bepalen. Bij deze acties horen, in tegenstelling tot de
testgevallen die met behulp van andere testspecificatietechnieken worden vervaardigd, geen
(expliciete) controles. De (impliciete) controle van een bepaalde actie is namelijk dat de
volgende actie uitvoerbaar is. Het is dus voldoende om te controleren dat de rij acties
inderdaad achtereenvolgens uitvoerbaar is.

Nog een verschil met de overige testspecificatietechnieken is dat bij de testuitvoering meer
nodig is dan alleen de technische infrastructuur waar het geautomatiseerde deel van het
informatiesysteem op draait. De handmatige procedures worden namelijk uitgevoerd door
mensen, hetgeen betekent dat er bij de testuitvoering meerdere testers nodig zijn die ieder
een bepaalde rol spelen.
Tenslotte zitten de benodigde gegevens slechts voor een deel in de database van het
geautomatiseerde deel van het informatiesysteem. De overige gegevens bevinden zich niet
in de database maar daarbuiten, bijvoorbeeld in de vorm van ingevulde formulieren. Ook dat
is een verschil met de overige testspecificatietechnieken.
Coverage
De mate waarin het informatiesysteem past in de organisatie (incl. de reeds aanwezige
informatiesystemen) wordt direct expliciet gemeten. Ofwel de inpasbaarheid van het
geautomatiseerde deel van het informatiesysteem op de handmatige procedures en de
overige informatiesystemen, alsmede de tijdigheid van de informatieverstrekking. Ook wordt
de werking van de autorisaties op de uit te voeren procedures (beveiliging) expliciet getest.
Over het gemak waarmee de eindgebruiker kan leren omgaan met het informatiesysteem en
het bedieningsgemak van het informatiesysteem voor geoefende gebruikers, ofwel de
gebruikersvriendelijkheid, wordt tijdens de uitvoering meer duidelijkheid verkregen zodat er
sprake is van een direct impliciete meting.
Stappen
De stappen die ondernomen moeten worden om tot een specificatie voor een
Procescyclustest te komen zijn:
1. Inventariseren beslispunten;
2. Bepalen padcombinaties + paden;
3. Specificeren testgevallen;
Stap 1: Inventariseren beslispunten

De testbasis voor de betreffende test wordt doorgelezen. Dit is voor de Procescyclustest een
beschrijving van de AO-procedures. Binnen deze AO-procedures moeten de beslispunten
(beslisprocessen of beslisprocedures) worden opgespoord. In de ideale situatie, als de AO-
procedures zijn weergegeven in de vorm van een procedure-flow, is dit een zeer eenvoudige
activiteit. Het betreft dan namelijk slechts het zoeken naar wyber-symbolen.
Stap 2: Bepalen padcombinaties + paden

Bij ieder gevonden beslispunt moeten padcombinaties worden gemaakt. Een padcombinatie
is een koppeling van een actie vóór een beslispunt met acties na datzelfde beslispunt. Bij de
vervaardiging van padcombinaties is het verstandig om de acties eerst te nummeren.
Sequentiële acties tussen twee beslispunten krijgen hierbij één gezamenlijk nummer. Alle
padcombinaties, dus alle combinaties van twee opvolgende acties met daartussen een
beslispunt, moeten worden uitgeschreven. In volgend voorbeeld is dit uitgewerkt.
Gegeven de volgende procedure-flow met bijbehorende beschrijving:

2 3 4
8 5 6
Bij de afdeling klantenregistratie komen mutatieformulieren binnen betreffende de NAW -

gegevens van een klant. De mutatieformulieren komen binnen bij het afdelingshoofd die
deze formulieren vervolgens doorgeeft aan een medewerker van de afdeling. Afhankelijk van
de soort mutatie (wijzigen, invoeren of verwijderen) wordt een onderhoudsfunctie met
betrekking tot de NAW -gegevens opgestart. Indien het een nieuwe klant betreft (mutatiesoort
= invoeren) moet afhankelijk van de landcode een bepaald vervolgscherm worden ingevuld.
Nadat de betreffende mutatie is doorgevoerd geeft de medewerker schriftelijk een

gereedmelding aan het afdelingshoofd, deze controleert met behulp van de functie fiatteren
NAW-gegevens de aangebrachte mutatie. Indien akkoord, wordt de mutatie gefiatteerd en is
de procedure beëindigd. Indien echter een fout wordt aangetroffen, wordt de mutatie
opnieuw aangeboden aan de betreffende medewerker.
De padcombinaties bij beslispunt A: (1,2); (1,3); (1,4); (8,2); (8,3); (8,4);

bij beslispunt B: (3,5) en (3,6);
bij beslispunt C: (2,7); (4,7); (5,7); (6,7); (2,8); (4,8); (5,8) en (6,8).
Vervolgens moeten deze padcombinaties aan elkaar worden geknoopt tot paden die van het
begin van de procedure-flow tot aan het eind van de procedure-flow lopen. In het voorbeeld
begint ieder pad met actie 1 en eindigt ieder pad met actie 7. Iedere padcombinatie moet
minstens één maal worden ondergebracht in een pad. In het voorbeeld gaat dit als volgt:
De padcombinaties zijn: (1,2); (1,3); (1,4); (2,7); (2,8); (3,5); (3,6); (4,7); (4,8); (5,7); (5,8);
(6,7); (6,8); (8,2); (8,3); (8,4).
Begonnen wordt met de eerste padcombinatie die nog niet in een pad is ondergebracht. In
dit geval is dat (1,2). Vervolgens wordt daar de eerste padcombinatie achter geknoopt die
begint met een 2 en die nog niet in een pad is ondergebracht. In dit geval (2,7). Hierdoor is
het pad (1,2,7) ontstaan en kan worden begonnen met het volgende pad.
Overgebleven padcombinaties zijn: (1,2); (1,3); (1,4); (2,7); (2,8); (3,5); (3,6); (4,7); (4,8);
(5,7); (5,8); (6,7); (6,8); (8,2); (8,3); (8,4).

Met de overgebleven padcombinaties wordt verder gegaan. De eerste padcombinatie die

nog niet in een pad is ondergebracht is (1,3). De eerste padcombinatie die met een 3 begint
en nog niet in een pad is ondergebracht is (3,5). De eerste padcombinatie die met een 5
begint en nog niet in een pad is ondergebracht is (5,7) en er is weer een pad ontstaan,
namelijk (1,3,5,7).
Overgebleven padcombinaties zijn: (1,2); (1,3); (1,4); (2,7); (2,8); (3,5); (3,6); (4,7); (4,8);
(5,7); (5,8); (6,7); (6,8); (8,2); (8,3); (8,4).
Hiermee wordt verder gegaan totdat alle padcombinaties zijn ondergebracht in de volgende
paden:
Pad 1: (1,2,7)
Pad 2: (1,3,5,7)
Pad 3: (1,4,7)
Pad 4: (1,2,8,2,7)
Pad 5: (1,3,6,7)
Pad 6: (1,4,8,3,5,8,4,7)
Pad 7: (1,3,6,8,2,7)
In onderstaande cross reference staan de padcombinaties uitgezet tegen de paden. Het is
verstandig om zon cross reference te maken. Hierdoor is het zichtbaar dat iedere
padcombinatie inderdaad minstens één keer in een pad is ondergebracht.
Pad\comb. 12 13 14 27 28 35 36 47 48 57 58 67 68 82 83 84
127 X X
1357 X X X
147 X X
12827 X X X X
1367 X X X
14835847 X X X X X X X
136827 X X X X X
Stap 3: Specificeren testgevallen

De paden door de procedure-flow moeten in deze stap van een concrete invulling worden
voorzien. Zoals reeds eerder opgemerkt betekent dit dat er voor ieder pad een rij opvolgende
acties moet worden beschreven. En wel zodanig dat door het uitvoeren van die acties
precies het goede pad wordt bewandeld. Dit is een activiteit die de nodige inventiviteit vereist
en is derhalve vrij moeilijk in algemene termen te beschrijven. Derhalve wordt volstaan met
de beschrijving van een voorbeeld:
Een fysieke invulling van pad 4 = (1,2,8,2,7) ziet er bijvoorbeeld als volgt uit:
P4-1 Laat het hoofd een mutatieformulier verstrekken aan een medewerker met daarin
een wijzigingsopdracht voor klantgegevens (actie 1)
P4-2 Laat de medewerker het soort mutatie bepalen op basis van het mutatieformulier in
beslisproces A (mutatiesoort is wijzigen)
P4-3 Laat de medewerker de wijziging uitvoeren op de klant waarbij bewust een fout
wordt gemaakt en laat hem vervolgens een schriftelijke gereedmelding aan het
hoofd geven (actie 2)
P4-4 Laat het hoofd van de afdeling controleren of de wijziging correct is doorgevoerd in
beslisproces C (hoofd moet dus de bewust gemaakte fout kunnen ontdekken)
P4-5 Laat het hoofd het mutatieformulier opnieuw aan de medewerker verstrekken
waarin de medewerker wordt verzocht om de wijziging op de klant nogmaals door
te voeren (actie 8)
P4-6 Laat de medewerker het soort mutatie bepalen op basis van het opdrachtformulier
in beslisproces A (mutatiesoort is dus opnieuw wijzigen)

P4-7 Laat de medewerker de wijziging uitvoeren op de klant, dit keer correct (actie 2)
P4-8 Laat het hoofd van de afdeling controleren of de wijziging correct is doorgevoerd in
beslisproces C (hoofd ontdekt nu dus geen fout)
P4-9 Laat het hoofd de gewijzigde klant fiatteren (actie 7)

Er moet worden vastgesteld of ten behoeve van de testuitvoering een initiële
gegevensverzameling aanwezig dient te zijn. Zoals reeds eerder opgemerkt, gaat het hierbij
niet alleen om gegevens in de database van het geautomatiseerde deel van het
informatiesysteem, maar bijvoorbeeld ook om ingevulde formulieren.
In het voorbeeld van pad 4 moet minstens één klant in de database van het
informatiesysteem aanwezig zijn en moet er reeds een ingevuld formulier zijn, waarin de
oorspronkelijke opdracht tot wijzigen staat.

Als resultaat van deze stap dient een testscript te worden opgeleverd. Met behulp van dit
testscript worden de testen daadwerkelijk uitgevoerd. Hiertoe moeten de acties uit de paden
worden onderverdeeld naar tester. Ook moeten de acties fysiek worden gemaakt (dus niet:
voer een wijziging uit maar: wijzig het adres van de klant met klantnummer 827 van
takkestraat 37 in takkebijstraat 47).
Bij iedere uit te voeren actie wordt een korte beschrijving gegeven van de wijze waarop de
actie wordt uitgevoerd. Indien een werkinstructie of een gebruikershandleiding beschikbaar
is, wordt een verwijzing hiernaar opgenomen. Op deze wijze kan bij het testen de actie
worden uitgevoerd aan de hand van de beschrijvingen in de handleiding of werkinstructie.
Eventuele fouten of onduidelijkheden hierin kunnen hierdoor worden opgespoord. Door deze
documenten onderdeel te laten uitmaken van de Procescyclustest wordt het
kwaliteitsattribuut gebruikersvriendelijkheid een aspect van deze test.
In het testscript worden veelal ook de acties gekoppeld aan een user-id van een functionaris
die bevoegd is tot het uitvoeren van de betreffende activiteit. Door de user-ids te definiëren
per functiegroep, inclusief de toekomstige autorisatie, kan dus door gebruik te maken van
deze user-ids tevens de beveiliging worden getest.
Door een uitbreiding van de testscripts met user-ids en de koppeling met de
gebruikershandleiding of de werkinstructies kan de scope van de Procescyclustest derhalve
op een relatief eenvoudige wijze worden uitgebreid met de kwaliteitsattributen
gebruikersvriendelijkheid en beveiliging.
12.4.5 Real-life Test (RLT)
Doel
De real-life test is niet een specifieke testmethode zoals de dataflowtest of de Syntactische
test maar is een verzamelnaam van allerlei soorten testen om het gedrag van het systeem te
kunnen voorspellen. Daarbij wordt real-life gesimuleerd. De bekendste testsoort is de real-life
test. Deze wordt uitgevoerd om de verwerkingssnelheid van het systeem, desgewenst onder
verschillende belastingen, te meten. Testen van dit soort treft men vaak aan als test voor de
verwerkingsorganisatie.

Kwalificatie
De real-life test kan gebruikt worden voor het testen van batch en on-line systemen. Een
real-life test wordt uitgevoerd onder de aanname dat het systeem technisch en functioneel
correct is. De wijze van specificeren is informeel en hangt bij de real-life test af van de kennis
die bekend is over het toekomstig gebruik van het systeem om een zo representatief
mogelijk testdraaiboek op te stellen met een zo getrouw mogelijke database.
Principe
Voor de real-life test wordt eerst een profielschets van het systeemgebruik gemaakt. Deze
bestaat uit een aantal scenarios. De scenarios beschrijven de achtergrondbelasting (ruis) die
aanwezig moet zijn tijdens de metingen. Achtergrondbelasting is de voor een dagdeel
representatieve belasting van het systeem, bijvoorbeeld in termen van de frequentie van
aanroepen van bepaalde systeemfuncties. Een scenario kan op twee manieren worden
uitgevoerd:
• Met behulp van een testtool (test is reproduceerbaar);
• Met behulp van een (grote) groep gebruikers.
Na het samenstellen van de draaiboeken worden de meetgevallen gespecificeerd en direct

fysiek gemaakt. Een meetgeval is een uit te voeren test waaraan prestatie-eisen zijn gesteld.
Alle meetgevallen bij elkaar vormen het meetscript. Per scenario (dus bij verschillende
achtergrondbelastingen) wordt het meetscript uitgevoerd. Tijdens de uitvoering meten
meelopende instrumenten (monitoring tools) het systeem. Deze meetinstrumenten
registreren allerlei gegevens, die voor de performance interessant zijn (o.a. Elapse-tijden,
CPU-tijden, aantallen I/Os, memory gebruik). Uit de analyse van deze gegevens kan na
afloop informatie worden gegeven over de behaalde performance van het systeem tijdens de
verschillende scenarios.
Coverage
De real-life test meet direct expliciet de snelheid waarmee het informatiesysteem interactieve
en batch-transacties afhandelt ofwel de tijd die verloopt tussen het moment waarop men het
informatiesysteem een bewerking opdraagt en het moment waarop het resultaat ter
beschikking komt. Impliciet worden meetgegevens verzameld om het gebruik van resources
(communicatiebeslag, intern geheugenbeslag, extern geheugenbeslag en/of
processorbeslag) te beoordelen.
Als de real-life test door een groep gebruikers wordt uitgevoerd in een als het ware productie
omgeving wordt expliciet ook de mate van beveiliging gemeten.
Stappen
De stappen die ondernomen moeten worden om een real-life test uit te kunnen voeren zijn:
• Bepalen profielschets systeemgebruik;
• Specificeren en realiseren testgevallen;
• Testuitvoering en beoordeling.
Stap 1: Bepalen profielschets systeemgebruik

Tijdens de specificatietaak dient ten behoeve van de real-life test een profielschets van het
systeemgebruik te worden bepaald. Deze profielschets dient aan te geven welke acties hoe
vaak gedurende een bepaalde periode worden uitgevoerd. Men moet hierbij denken aan een
aantal dagcycli, bijvoorbeeld een minimale, nominale en een maximale. Een dagcyclus
bestaat dan gewoonlijk uit inloggen, intensief gebruik, lunch, intensief gebruik, uitloggen,
back-up en dagelijkse batches. Daarnaast kunnen er ook vergelijkbare week-, maand- en
jaarcycli zijn. De waarde die aan de resultaten van de real-life testen kan worden gegeven is
sterk afhankelijk van de resultaten van deze activiteit. De uit te voeren test dient
representatief te zijn voor de real-life situatie. Het bepalen van deze representativiteit moet
door de verwerkingsorganisatie in samenwerking met de gebruikersorganisatie plaatsvinden.
Er moet voor gezorgd worden dat alle systeem-resources realistisch worden gebruikt. Het is
zinloos een significant zwaarder gebruik te simuleren dan in realiteit gebruikelijk is, omdat de
uitslag een dergelijke test niets zegt. Als het systeem bijvoorbeeld te traag is onder die
omstandigheden wil het niet zeggen dat het systeem niet zal voldoen. Als het systeem niet te
traag is, zegt dat alleen dat het systeem overgeconfigureerd is, zonder dat duidelijk wordt
hoeveel.
Stap 2: Specificeren en realiseren testgevallen

Voor real-life testen is de inhoud van de testgevallen minder relevant dan voor de meeste
andere testspecificatietechnieken. Het enige criterium is dat de realiteit zo dicht mogelijk
benaderd moet worden. Daarom is het heel nuttig als er een operationeel systeem is,
waarvan een representatieve omgeving kan afgetapt.
De specificatie kan gerealiseerd worden door een dagproductie als real-life invoer klaar te
zetten. Alle brondocumenten en acties die op een dag verwerkt worden, moeten zo
realistisch mogelijk, worden verdeeld over de mensen die meewerken aan de real-life test.
Hierbij dient overigens wel te worden gedacht aan de privacy-aspecten!
Tevens moet tijdens deze stap de benodigde initiële gegevensverzameling worden

gespecificeerd.
Indien er reeds een operationeel systeem voor dezelfde toepassing bestaat, is de
eenvoudigste oplossing de initiële gegevensverzameling hiervan af te leiden.
Stap 3: Testuitvoering en beoordeling

Het uitvoeren van de real-life test is doorgaans een groter probleem dan bij andere testen. In
een omgeving waarin het aantal eindgebruikers niet al te groot is, kan men gedurende een
weekeinde iedereen over laten werken en een van tevoren vastgelegd testdraaiboek laten
uitvoeren. Als het aantal eindgebruikers te groot is kan simulatie met behulp van tools een
oplossing bieden. Bij dit soort tools moet wel goed gekeken worden welke
systeemcomponenten niet gebruikt worden. Vaak worden bijvoorbeeld communicatielijnen
niet of anders gebruikt dan in de uiteindelijke productie-omgeving. Een andere beperking van
simulatie is gelegen in het feit dat het vaak niet mogelijk is bepaalde functies parallel uit te
voeren.
Er moet van tevoren goed worden bepaald wat en hoe men gedurende de real-life test gaat
meten. Soms belast het meten op zich ook het systeem, hetgeen tot vervorming van de
resultaten kan leiden. Anderzijds moet men voldoende gegevens hebben om achteraf een
goede analyse uit te kunnen voeren.
Het beoordelen van een real-life test is erg moeilijk. Met name door het parallel uitvoeren van
de testen kan het aan herhaalbaarheid schorten. Daarom moet er voor worden gewaakt, dat
de test niet op instabiele software wordt uitgevoerd. Indien het systeem beschikt over logging
en monitoring faciliteiten, kan daarvan gebruik worden gemaakt, om de oorzaken van
eventuele fouten op te sporen.

12.4.6 Semantische test (SEM)
Doel
De Semantische test heeft tot doel de relaties tussen gegevens bij het invoeren te verifiëren.
Dit zijn de zogenaamde relatiecontroles. Deze relaties kunnen aanwezig zijn tussen de
gegevens binnen één scherm, tussen gegevens op verschillende schermen en tussen
(invoer)gegevens en reeds in de database aanwezige gegevens.
Kwalificatie
Het is een formele testspecificatietechniek, die met name wordt gebruikt bij het testen van
on-line systemen. Semantische testen kunnen parallel met de Syntactische testen worden
uitgevoerd. Het verdient aanbeveling ook de testscripts van beide testspecificatietechnieken
te combineren.
Principe
Semantisch testen start met het inventariseren van de relatiecontroles. Deze relatiecontroles
worden ontleed in condities en paden: onder welke omstandigheden gebeurt wat. Deze
condities worden middels testacties één voor één (per scherm) uitgetest.
Coverage
De Semantische test kan worden gebruikt als een directe, expliciete testspecificatietechniek
in het kader van functionaliteit, maar ook bij het testen van de beveiliging. De controle op de
logische toegangsbeveiliging kan worden gezien als een relatiecontrole op de in het systeem
aanwezige beveiligingsdefinities (o.a. autorisaties) en de invoer van bijvoorbeeld user-id en
wachtwoord. Impliciet worden de gebruikersvriendelijkheid van de schermcontroles met de
bijbehorende foutmeldingen en het autorisatie mechanisme gemeten.
Stappen
De stappen die ondernomen moeten worden om tot een Semantische test te komen zijn:
1. Inventariseren relatiecontroles;
2. Uitwerken relatiecontroles;
3. Vaststellen testacties en controles;
Stap 1: Inventariseren relatiecontroles

De geselecteerde testbasis voor de betreffende test wordt doorgelezen. Tijdens deze stap
worden de plaatsen binnen het systeem bepaald, waar relatiecontroles (op schermniveau)
plaatsvinden. Alle controles moeten een unieke identificatie krijgen, voor zover dat niet al is
gedaan in de systeemdocumentatie.
Stap 2: Uitwerken relatiecontroles

De geïnventariseerde relatiecontroles kunnen worden uitgeschreven in de vorm van een
enkelvoudige vergelijking (per relatiecontrole een vergelijking). In enkelvoudige
vergelijkingen komen slechts de termen ALS, DAN en ANDERS voor, dit in tegenstelling tot
een samengestelde vergelijking waarbij tevens de termen EN en OF kunnen voorkomen.
Een relatiecontrole in de vorm van A EN B wordt uitgeschreven als:
ALS A
DAN ALS B

DAN correcte invoer c.q. actie

ANDERS foutboodschap
Een relatiecontrole in de vorm van A OF B wordt uitgeschreven als:

ALS A
ANDERS ALS B
Het wel of niet uitschrijven van de controles in de vorm van vergelijkingen, zal afhangen van
de complexiteit van de relatiecontroles en de eenduidigheid van de testbasis. Per
relatiecontrole worden tevens de te onderscheiden testgevallen aangegeven.
Bij eventuele onduidelijkheden in de testbasis is het van belang dat afstemming plaatsvindt
met het ontwikkelteam.
Bijvoorbeeld is de volgende tekst vermeld bij een functiebeschrijving:
De ingangsdatum van de ingevoerde adreswijziging moet liggen na de einddatum, welke is

aangegeven bij het vorige adres van de pensioengerechtigde. Is dit niet het geval dan volgt
een foutboodschap.
Dit levert in het kader van het testen de navolgende vergelijking:
ALS einddatum oude adres = ingangsdatum nieuwe adres (a)
DAN foutboodschap (testpad 1)
ANDERS correcte invoer (testpad 2)
In dit voorbeeld wordt een tweetal testpaden onderkend namelijk testpad 1 waarin de
bewering a waar is (einddatum = begindatum) en het testpad 2 waarin de bewering a onwaar
is (einddatum < begindatum).
Een voorbeeld met meerdere paden is de navolgende controle:

ALS minimum voorraad code gelijk is aan S(ignaal) (a)
DAN ALS aantal minimum voorraad gelijk is aan nul (b)
DAN foutboodschap 103 (testpad 1)
Indien de minimum voorraadcode ongelijk aan S is, vindt geen verdere controle plaats
(testpad 3). Indien de minimum voorraadcode gelijk aan S is, en het aantal minimum
voorraad is nul volgt een foutboodschap (testpad 1). Als het aantal minimum voorraad
ongelijk aan nul is, de bewering a is waar en de bewering b is onwaar, volgt geen
foutboodschap (testpad 2).
Stap 3: Vaststellen testacties en controles

Door het uitschrijven van de diverse relatiecontroles in (enkelvoudige) vergelijkingen worden

de testgevallen, op basis van de testpaden, als het ware automatisch onderkend. Het testen
van de testpaden gebeurt door het uitvoeren van testacties. In principe genereert ieder
testpad een bijbehorende testactie en eventueel een controle. Bij de beschrijving van de
testactie dienen de concrete waarden te worden gebruikt, die worden toegepast bij het
uitvoeren van de test. Bij rubrieken die niet van belang zijn voor de test dient, indien
noodzakelijk, een correcte waarde te worden ingevuld. Een controle wordt beschreven als er
meer gecontroleerd dient te worden dan de vaststelling of een actie goed (legaal) of fout
(illegaal) verloopt.
Een uitgebreide en gedetailleerde beschrijving van de testacties is met name van belang bij
het testen van relatiecontroles tussen rubrieken (gegevens) op verschillende schermen. Er
wordt dan aangegeven welke gegevens op eerdere schermen ingevuld dienen te worden,
opdat de test kan worden uitgevoerd. Het testen van relatiecontroles tussen rubrieken
(gegevens) binnen een scherm is veelal eenvoudiger.
Na deze stap is in principe de testspecificatie gereed. De testspecificatie omvat in ieder
geval de relatiecontroles (inclusief de bijbehorende testpaden). Bij voorkeur in de vorm van
vergelijkingen en een beschrijving van de testacties en controles. Bij een groot aantal
relatiecontroles is het aan te bevelen een cross-reference tabel op te nemen van
relatiecontroles, testpaden en testacties.Hiermee kan worden vastgesteld of voor alle
relatiecontroles, en de daarmee samenhangende testpaden, testacties aanwezig zijn.
M.b.t. het voorbeeld van het voorraadsysteem kunnen de navolgende testacties worden
onderkend:
A01 Invoeren min. Voorraadcode S en aantal minimum voorraad 0
A02 Invoeren min. Voorraadcode S en aantal minimum voorraad 250
A03 Invoeren minimumvoorraadcode B
Bij het uitvoeren van actie A01 wordt gecontroleerd of de juiste foutboodschap verschijnt:
C01 FB 103: bij voorraadcode S minimum voorraadaantal invullen

Zie paragraaf 12.2.7 Vaststellen initiële gegevensverzameling.

12.4.7 Syntactische test (SYN)
Doel
De Syntactische test heeft tot doel fouten te ontdekken in de lay-out van schermen en
overzichten, alsmede in de primaire invoercontroles met betrekking tot de schermrubrieken.
Kwalificatie
Dit testtype wordt met name gebruikt bij het testen van on-line systemen. Echter ook bij
batch-systemen kan een Syntactische test worden toegepast voor een lay-out-controle op de
geproduceerde overzichten. Als toetscriteria worden de geldende standaards gebruikt,
alsmede de specifieke beschrijvingen van schermen en overzichten in de functionele
specificaties. Afhankelijk van de wijze waarop deze test wordt uitgevoerd (bijvoorbeeld aan
de hand van een checklist) is de testspecificatietechniek meer of minder formeel.

Principe
Het grootste deel van de primaire invoercontroles kan worden bepaald door schermrubrieken
te relateren aan de attributen uit het gegevensmodel en van deze attributen vervolgens
bijvoorbeeld de toegestane veldlengte en het domein te bepalen. Ook worden de
beschikbare opties geïnventariseerd en gerelateerd aan de schermen c.q. schermrubrieken.
De controle op de presentatie van gegevens beperkt zich overigens niet alleen tot de
schermen. Ook de uitvoer op papier wordt qua lay-out gecontroleerd. Als resultaat kunnen er
twee toetslijsten (één voor schermen en één voor de overzichten) worden opgesteld. De
testuitvoering is vervolgens relatief rechtlijnig.
Voor het opstellen van deze toetslijsten kan gebruik worden gemaakt van het Template
checklist overzicht- /schermtest welke een onderdeel is van de testtemplates.
Coverage
Het soort fouten dat met deze testspecificatietechniek kan worden gevonden op schermen
en overzichten zijn ontbrekende of verkeerde velden, foutieve veldlengtes, foutieve
domeinwaarden, velden op een foutieve plaats en foutieve controles. Op deze wijze wordt de
functionaliteit van de schermen en overzichten direct expliciet gemeten. Daarbij komt dat de
gebruikersvriendelijkheid van de schermen en overzichten impliciet wordt gemeten.
Stappen
De stappen die ondernomen moeten worden om tot een Syntactische test te komen zijn:
1. Opstellen checklist m.b.t. schermen en overzichten;
2. Vaststellen te testen schermen en overzichten;
3. a. Opstellen testscripts. of b. Een alternatieve werkwijze
Stap 1: Opstellen checklist m.b.t. schermen en overzichten

Deze stap dient te worden uitgevoerd tijdens de testspecificatiefase. Als resultaat hiervan
wordt een tweetal checklists (één voor schermen en één voor overzichten) opgeleverd.
Vastgesteld dient te worden welke syntactische controles men wil uitvoeren ten aanzien van
de verschillende schermen (inclusief rubrieken) en overzichten. Deze controles worden in
algemene bewoordingen beschreven in de twee checklists .
Allereerst wordt de testbasis bestudeerd. Uit de testbasis moet het navolgende worden
gedestilleerd:
• Welke soorten rubrieken er zijn: numeriek, alfanumeriek, datum;
• Welke opties zijn per scherm en/of per rubriek mogelijk: vraagtekenselectie,
functietoetsen, help-functies, etc.
Vervolgens moet per rubrieksoort worden bepaald welke controles uitgevoerd dienen te
worden. Hierbij moet men oppassen niet te veel te willen. Door het grote aantal rubrieken
explodeert het aantal controles heel snel. Bovendien is de ernst van de fouten die men met
Syntactische testen vindt doorgaans niet erg zwaar, hoewel de gebruikers er vaak last van
zullen hebben. De onderkende (standaard-)controles ten aanzien van rubrieken maken
onderdeel uit van de checklist ten behoeve van de schermtest.
Op identieke wijze kunnen de overige syntactische controles die men wil uitvoeren worden
onderkend. Deze controles vormen tezamen de twee checklists (één voor de schermen en
één voor de overzichten). Aan het einde van de beschrijving van deze
testspecificatietechniek zijn voorbeelden toegevoegd van mogelijk uit te voeren syntactische
controles.

Men kan de manier waarop het informatiesysteem is gebouwd mee laten wegen bij het
opstellen van de checklist. Als bijvoorbeeld een standaard datumroutine wordt gebruikt is het
zinloos op iedere datum-rubriek weer te controleren op een illegale datum. De kans hiermee
fouten te vinden is zo gering dat het niet opweegt tegen de inspanning die het testen vereist.
Hierbij wordt ervan uitgegaan dat deze datumroutine ook daadwerkelijk wordt aangeroepen.
Stap 2: Vaststellen te testen schermen en overzichten

Nadat de betreffende checklists zijn opgesteld dient een aantal schermen en overzichten te
worden geselecteerd waarop de controles worden uitgevoerd. Het is zinvol de checklist
slechts steekproefsgewijs toe te passen, aangezien de zwaarte van de fouten die worden
gevonden bij de Syntactische test over het algemeen vrij laag is.
Indien tijdens het uitvoeren van de test blijkt dat een groot aantal fouten wordt gevonden, kan
worden overwogen het aantal schermen en/of overzichten waarop de checklists worden
toegepast uit te breiden.
Stap 3a: Opstellen testscripts

Als resultaat van deze stap wordt een testscript opgeleverd. Zoals reeds eerder is
aangegeven, kan een testscript betreffende een Syntactische test vaak worden
gecombineerd met een testscript betreffende een Semantische test.
Indien de vorige twee stappen, opstellen checklist met betrekking tot schermen en
overzichten en vaststellen te testen schermen en overzichten, volledig zijn uitgevoerd kan
het eventueel reeds aanwezige testscript van de Semantische test eenvoudig worden
uitgebreid. Aan het betreffende testscript wordt een actie toegevoegd waarin staat
beschreven dat de controles zoals vermeld in de checklist dienen te worden uitgevoerd met
betrekking tot het betreffende scherm of overzicht. Bijvoorbeeld:
A0X Uitvoeren controles scherm xxx conform syntactische scherm-checklist
Stap 3b: Een alternatieve werkwijze

Een andere werkwijze, die wat pragmatischer is, is de navolgende: Stap 1: opstellen
checklist m.b.t. schermen en overzichten zoals hiervoor beschreven, wordt overgeslagen.
Aan het testscript van de geselecteerde schermen en overzichten wordt een paragraaf
toegevoegd waarin een aantal syntactische controles worden beschreven die specifiek voor
het betreffende scherm of overzicht worden uitgevoerd. In feite betekent dit dat men na het
opstellen van het testscript voor de Semantische test in een korte brainstormsessie een
beperkt aantal syntactische controles bedenkt, die kunnen worden uitgevoerd ten aanzien
van het specifieke scherm of overzicht. Deze controles worden beschreven en aan het
testscript toegevoegd.
Syntactische controles
In deze paragraaf worden de mogelijk uit te voeren controles bij een syntactische
(scherm)test gedetailleerd beschreven. Een drietal categorieën is hierbij te onderscheiden:
• Layoutcontrole;
• Functiegebruik-controle;
• Rubriekcontrole.
Per controle-categorie zal worden aangegeven wat getest kan worden en waar de controle
betrekking op heeft: een scherm of een overzicht.
Layoutcontrole
De layoutcontrole kan voor ieder scherm en/of overzicht plaats vinden. Het scherm wordt
gecontroleerd aan de hand van de schermlayout uit de functionele specificaties. De
overzichten aan de hand van de overzichtlayout.

Met betrekking tot de layout kunnen de volgende controles uitgevoerd worden:
Kopregels
Er kan gecontroleerd worden of aan de standaard kopregels wordt voldaan. Voor alle
schermen en overzichten kan bijvoorbeeld gelden dat de volgende rubrieken aanwezig
moeten zijn:
• Schermnaam of overzichtnaam;
• Systeemdatum;
• Paginanummer;
• Eventuele parameters;
• Versienummer.
De eisen ten aanzien van de kopregel zullen vaak zijn beschreven bij de
(sub)systeemstandaards met betrekking tot de mens-machine interface. Voor de rubrieken in
de kopregels kan de onderstaande controle op rubrieken worden toegepast.
Rubrieken
Ten aanzien van de op het scherm of het overzicht aanwezige rubrieken kunnen o.a. de
navolgende controles te worden uitgevoerd:
• Aanwezigheid (ontbreken er rubrieken en/of staan er rubrieken op het scherm die er niet
horen te staan);
• Is de naamgeving van de rubrieken correct;
• Is de plaats van de rubrieken op het scherm of het overzicht correct.
Functiegebruikcontrole
De controles met betrekking tot het functiegebruik zijn vanzelfsprekend alleen van
toepassing op de schermen. De controle kan worden uitgevoerd aan de hand van een
testscript. Daarin dient vermeld te staan wat voor de betreffende functietoets (inclusief
mogelijke opties, selectie-mogelijkheden e.d.) getest moet worden. Een mogelijke
notatiewijze hierbij is de navolgende:
Fxx: Conditie1[Actie1], Conditie2[Actie2], ….
Hierin is:
• Fxx: de functietoetsnaam;
• Conditie1: de conditie waaronder de actie wordt uitgevoerd, bijvoorbeeld de positie van
de cursor in een bepaalde rubriek;
• Actie1: de uit te voeren actie.
Rubriekcontrole
Deze controle kan zowel voor de schermen als voor de overzichten worden uitgevoerd aan
de hand van scherm- respectievelijk overzichtbeschrijvingen uit het systeemdocumentatie.
Schermrubriekcontrole
Voor iedere rubriek op het scherm kunnen o.a. de navolgende controles uitgevoerd worden:
Input/output (I/O) controle:

• Voor alle mogelijke invoerrubrieken (I) dient getest te worden of invoer mogelijk is in
de betreffende rubriek;
• Voor alle mogelijke uitvoerrubrieken (O) dient gecontroleerd te worden of
daadwerkelijk uitvoer plaatsvindt naar het scherm en of dit de juiste uitvoer is. Tevens
dient gecontroleerd te worden of invoeren niet mogelijk is;

• Voor alle invoer/uitvoerrubrieken (I/O) dient zowel de invoercontrole alsmede de

uitvoercontrole plaats te vinden zoals hierboven is vermeld. Daarnaast dient
gecontroleerd te worden of de juiste defaultwaardes worden gepresenteerd indien
daar sprake van is bij de betreffende rubriek.
Controle velddefinities:
• Bij numerieke velden: cijfers invoeren en controleren dat er geen letters ingevoerd
kunnen worden;
• Bij alfanumerieke velden: letters invoeren en/of cijfers invoeren;
• Bij alfa-non-numerieke: velden letters invoeren en controleren dat er geen cijfers
ingevoerd kunnen worden;
• Bij datumvelden: een legale datum invoeren, een illegale datum invoeren, ontbreken
van de eeuwaanduiding en controleren dat er geen letters ingevoerd kunnen worden;
• Indien domeinen zijn gespecificeerd, kan controle ten aanzien hiervan plaatsvinden.
Bij het vaststellen van de uit te voeren controles in het kader van de velddefinities, kan
gebruik worden gemaakt van equivalentieklassen. Een equivalentieklasse is een
deelverzameling van een domein met daarin de attribuutwaarden die voor de test
gelijkwaardig (equivalent) zijn. Uiteraard kan een attribuutwaarde tot slechts één
equivalentieklasse behoren. De opdeling van velddefinities en attribuutdomeinen in
equivalentieklassen is met name afhankelijk van het formaat (numeriek, alfanumeriek of
datum) van het attribuut. Voor ieder formaat gelden andere regels.
Controle verplichte rubrieken:

Bij ieder scherm <commit> geven zonder dat een rubriek is ingevuld. Als er sprake is van
verplichte rubrieken zal dit op het scherm gesignaleerd moeten worden. Vervolgens de
eerste rubriek invullen en het scherm weer gereed melden. De eventueel volgende
verplichte rubriek invullen en gereedmelden, etc..
Help controle:
Indien helpteksten voor een bepaalde rubriek aanwezig dienen te zijn controleren of de
weergave daarvan juist geschiedt, dat er daadwerkelijk een helptekst verschijnt en dat de
helptekst de juiste is voor de betreffende rubriek.
Overzichtrubriekcontrole
Met betrekking tot de overzichten kan de controle op rubriekniveau beperkt worden tot de
constatering dat de uitvoer correct op het overzicht komt. Aan de hand van de
overzichtbeschrijvingen dient gecontroleerd te worden of de daarin beschreven herkomst ook
daadwerkelijk op het overzicht wordt gezet.
12.4.8 Error guessing (EG)
Doel
Error guessing is in wezen ongestructureerd testen. De waarde ervan ligt in het
onverwachte: er worden testen uitgevoerd die anders met gestructureerd testen niet aan bod
komen.
Kwalificatie
De testen zullen voornamelijk worden uitgevoerd op de systeemdelen, batch en/of on-line,
die kwetsbaar of onduidelijk in kwaliteit zijn. Hiervoor worden geen formele en te beheren
testspecificaties opgesteld. Wel moet achteraf gerapporteerd worden dat EG is uitgevoerd
met aanduiding van de geteste situaties.

Principe
Error guessing gaat uit van de neus van de tester en deze heeft dan ook de volledige vrijheid
ter plekke testgevallen te verzinnen en uit te proberen. De tester moet dan ook op basis van
een combinatie van testervaring, materiedeskundigheid en intuïtie de test uitvoeren. Op het
moment dat er uit testen op basis van EG bevindingen komen wordt geadviseerd de
testgevallen te noteren en toe te voegen aan het testdraaiboek. Uiteraard dienen deze
testgevallen herhaalbaar te zijn, zodat de testresultaten reproduceerbaar zijn.
Coverage
Het soort fouten dat door error guessing gevonden kan worden is zeer verschillend. Op bijna
alle kwaliteitsattributen, uitgezonderd continuïteit, flexibiliteit, onderhoudbaarheid en
testbaarheid kan gemeten worden. Bedacht moet worden dat deze testspecificatietechniek
niets anders is dan met kennis van zaken ongestructureerd testen. Het is daarom slechts
bedoeld als aanvulling op de geselecteerde, gestructureerde testspecificatietechnieken.
Stappen
Omdat bij error guessing ongestructureerd wordt getest zijn geen stappen aan te geven.
12.5 Keuze van een techniek
12.5.1 Bepalen van de keuze

Zoals eerder aangegeven speelt binnen testen de strategiebepaling een centrale rol. De
keuze van een specifieke testspecificatietechniek is gekoppeld aan het risicogebied dat
afgedekt dient te worden. Voor elke organisatie en voor elk project moeten deze
risicogebieden opnieuw worden bepaald. Alle risicogebieden die worden verkleind door
andere kwaliteitsmaatregelen kunnen resulteren in een beperktere testinspanning.
Door het gebruik van een CASE tool kan in een vroeg stadium van het ontwikkeltraject al
een groot aantal functionele risicos worden afgedekt. Syntactische controles, veldlengtes,
domeincontroles en schermlay-outs kunnen reeds in het systeemontwerp worden
gecontroleerd. Bij de test hoeven hiervoor dus geen expliciete testgevallen te worden
opgesteld. Wel dient een controle uitgevoerd te worden dat de gedefinieerde domeinen en
formaten 1:1 worden overgenomen in de database definitie.
Binnen de scope van de test biedt de vertaling van de functionele beschrijving naar het
daadwerkelijke informatiesysteem de meeste ruimte voor interpretatie verschillen. Bij de test
zal het testen van de juistheid van de functionaliteit veel aandacht krijgen. Daarnaast wordt
in de test vastgesteld in welke mate het informatiesysteem aansluit bij de handmatige
procedures.
Naast de gedefinieerde teststrategie is de keuze voor een specifieke testspecificatietechniek

ook sterk afhankelijk van de kennis van de leden van de projectgroep acceptatie en de
kwaliteit van de testbasis.
Onder kwaliteit van de testbasis wordt hier verstaan de wijze waarop de functionele
beschrijving is weergegeven. De wijze van weergeven kan de keuze van een
testspecificatietechniek beïnvloeden.
Het volgende voorbeeld geeft weer hoe een functionele beschrijving uit een SO gebruikt
wordt binnen meerdere testspecificatietechnieken.
In het SO is de volgende functionele beschrijving opgenomen:

Het Object mag slechts verwijderd worden indien bij dit product geen:
• Object A hoort.

• Object B hoort.
• Object C hoort.
Voor het kunnen toepassen van testspecificatietechnieken is het zinvol dat de bovenstaande
functionele beschrijving wordt omgezet naar een gestructureerde vergelijking. Voor zowel het
ontwikkelteam als de projectgroep acceptatie heeft het de voorkeur deze notatiewijze ook al
te hanteren in het systeemontwerp.
ALS bij object geen Object A hoort

DAN ALS bij object geen Object B hoort
DAN ALS bij object geen Object C hoort
DAN verwijderen toegestaan
ANDERS verwijderen niet toegestaan
De structuur zoals hierboven beschreven sluit sterk aan bij de werkwijze van de
Semantische testtechniek (zie paragraaf 12.4.6 Semantische test (SEM)) .
Bij het uitwerken van deze functionele beschrijving komen vrij eenvoudig de volgende
testpaden naar voren.
ALS bij object geen Object A hoort

DAN ALS bij object geen Object B hoort
DAN ALS bij object geen Object C hoort
DAN verwijderen toegestaan testpad 1
ANDERS verwijderen niet toegestaan testpad 2
In het voorbeeld komen in dat geval dus vier te testen paden naar voren.
Testpad 1: Voor het te verwijderen object is geen Object A, Object B en Object C aanwezig.
Testpad 2: Voor het te verwijderen object is geen Object A en Object B, maar wel een
Object C aanwezig.
Testpad 3: Voor het te verwijderen object is geen Object A, maar wel een Object B
aanwezig. Object C doet niet meer ter zake.
Testpad 4: Voor het te verwijderen object is een Object A aanwezig. Object B en Object C
doen niet meer ter zake.
Voor het zelfde functionele voorbeeld kunnen we ook testgevallen afleiden met behulp van
de Elementaire vergelijkingentest (EVT). We gaan hierbij uit van de oorspronkelijk
functionele beschrijving.
Het Object mag slechts verwijderd worden indien bij dit product geen:
• Object A hoort.
• Object B hoort.
• Object C hoort.
De functionele beschrijving wordt dan als volgt weergegeven in de vorm van een vergelijking.
Het kunnen maken van de vertaalslag naar deze vergelijking vereist specifieke expertise van
de testers.
Vergelijking:

Als (Bij Object hoort Object A)

OF (Bij Object hoort Object B)
OF (Bij Object hoort Object C)
Dan is verwijderen van object niet toegestaan.
Met behulp van de Elementaire vergelijkingentest (zie paragraaf 12.4.2 Elementaire

vergelijkingentest (EVT)) zijn de testgevallen bepaald voor deze functie. In de onderstaande
tabel zijn de testsituaties bepaald voor de functionele beschrijving uit het voorbeeld.
1 (verwijderen niet toegestaan) 0 (verwijderen toegestaan)

Bij Object hoort Object A 1.0.0. 0.0.0.
Bij Object hoort Object B 0.1.0. 0.0.0.
Bij Object hoort Object C 0.0.1. 0.0.0.
Strepen we nu de zich herhalende waarden weg, dan blijven de volgende testsituaties over.
1 (verwijderen niet toegestaan) 0 (verwijderen toegestaan)

Bij Object hoort Object A 1.0.0. 0.0.0.
Bij Object hoort Object B 0.1.0. 0.0.0.
Bij Object hoort Object C 0.0.1. 0.0.0.
De volgende vier testsituaties blijven over.

Testsituatie 1: Voor het te verwijderen object is een Object A aanwezig. Object B en Object
C zijn niet aanwezig.
Testsituatie 2: Voor het te verwijderen object is een Object B aanwezig. Object A en Object
C zijn niet aanwezig.
Testsituatie 3: Voor het te verwijderen object is een Object C aanwezig. Object A en Object
B zijn niet aanwezig.
Testsituatie 4: Voor het te verwijderen object zijn Object A, Object B en Object C niet
aanwezig.
In deze situatie komen beide technieken tot hetzelfde aantal testsituaties. De invulling van de
testsituaties is enigszins anders, maar in principe leiden beide technieken tot dezelfde
resultaten. Dit komt doordat de condities vrij snel weer te geven zijn in de structuur voor de
Semantische test (zie paragraaf 12.4.6 Semantische test (SEM)). Bij dit type condities is het
resultaat sterk afhankelijk van de ervaring van de tester en de wijze waarop de functionele
beschrijving is opgesteld. De toepassing van de Elementaire vergelijkingentest zal bij minder
ervaren testers meer tijd vergen. Na enige ervaring wordt veelal de voorkeur gegeven aan de
Elementaire vergelijkingentest, omdat deze test ook voor complexere functionele
beschrijvingen toepasbaar is.
Bij complexere functiebeschrijvingen is het gebruik van de Semantische test niet zinvol. Het
opzetten van de structuur neemt te veel tijd in beslag. Het gebruik van de Semantische test
beperkt zich dan tot de semantische controles en eenvoudige functiebeschrijvingen.
Voor de complexere functies zijn andere technieken beter geschikt. De volgende functionele
beschrijving is een voorbeeld van een complexere functiebeschrijving.
Overzicht: Afdrukken lopende opdrachten met een omvang van meer dan 20K
Selecteer alle opdrachten waarvoor geldt:
• opdrachten vallen binnen district van de gebruiker;
• laatste geboekte activiteit niet langer dan 2 weken geleden;

• opdrachten moeten status A, C, D of K hebben;

• opdrachten met status D moeten incasso-indicatie op J hebben
of
• alle opdrachten >20K.
Als we voor het bepalen van de testgevallen voor deze functionele beschrijving de Data flow
test (DFT) (zie paragraaf 12.4.1 Dataflowtest (DFT)) gebruiken, komen we tot de volgende
testgevallen.
Centrale begrip Relatie met Waarden

Opdracht District binnen, buiten
Laatste transactie <= 2 wk, > 2 wk
Status A, C, D, K
Incasso indicatie J, N (alleen voor D)
Omvang <=20K, >20K
Bij het bepalen van de testgevallen met behulp van de DFT dienen alle statuswaarden
minimaal een keer getest te worden. Voor het bovenstaande voorbeeld leidt dit tot 5
testgevallen. (Testgeval 4 is nodig omdat de Incasso indicatie alleen van toepassing is voor
status D).
1 2 3 4 5
District binnen buiten buiten buiten buiten
Laatste transactie >2 <=2 >2 >2 >2
Status A C D D K
Incasso indicatie N N J N J
Omvang <=20K >20K <=20K >20K >20K
De vijf hierboven beschreven testgevallen zijn niet volledig. Het is duidelijk dat voor een
volledige test van de werking van deze functie meer testgevallen noodzakelijk zijn. Binnen de
DFT bestaat ruimte om deze testgevallen toe te voegen op basis van de expertise van de
testdeskundige.
De Elementaire vergelijkingentest is een test die de testdeskundige aangeeft hoe deze
testgevallen kunnen worden bepaald. Voor de EVT zullen we de functionele beschrijving iets
anders weergeven. De bovenstaande functionele beschrijving kunnen we weergeven als een
vergelijking. Met behulp van haakjes wordt de relatie tussen de verschillende vergelijkingen
weergegeven.
((district opdracht = district gebruiker) EN

(datum opdracht > systeemdatum - 2 weken) EN
(( opdrachtstatus = A) OF (opdrachtstatus = C) OF (opdrachtstatus = D EN incasso
indicatie= J) OF (opdrachtstatus = K))) OF
(opdracht bedrag >20K))
Als we de individuele vergelijkingen vervangen door letters blijft een vereenvoudigde

vergelijking over. Deze vergelijking vormt het uitgangspunt voor de afleiding van de te testen
situaties.
((A) EN (B) EN (( C) OF (D) OF (E EN F) OF (G))) OF H
Op basis van de vergelijking worden in de onderstaande tabel de testsituaties weergegeven

op basis van de Elementaire vergelijkingentest.

1 (komt voor in 0 (komt niet voor in

selectie) selectie)
A district opdracht = district gebruiker 1.1.1.0.0.1.0.0 0.1.1.0.0.1.0.0
B datum opdracht > systeemdatum - 2 1.1.1.0.0.1.0.0 1.0.1.0.0.1.0.0
weken
C opdrachtstatus = A 1.1.1.0.0.1.0.0 1.1.0.0.0.1.0.0
D opdrachtstatus = C 1.1.0.1.0.1.0.0 1.1.0.0.0.1.0.0
E opdrachtstatus = D 1.1.0.0.1.1.0.0 1.1.0.0.0.1.0.0
F incasso indicatie= J 1.1.0.0.1.1.0.0 1.1.0.0.1.0.0.0
G opdrachtstatus = K 1.1.0.0.0.1.1.0 1.1.0.0.0.1.0.0
H opdracht bedrag >20K 1.1.0.0.0.1.1.1 1.1.0.0.0.1.1.0
1 (komt voor in 0 (komt niet voor in

selectie) selectie)
A district opdracht = district gebruiker 1.1.1.0.0.1.0.0 0.1.1.0.0.1.0.0
B datum opdracht > systeemdatum - 2 1.1.1.0.0.1.0.0 1.0.1.0.0.1.0.0
weken
C opdrachtstatus = A 1.1.1.0.0.1.0.0 1.1.0.0.0.1.0.0
D opdrachtstatus = C 1.1.0.1.0.1.0.0 1.1.0.0.0.1.0.0
E opdrachtstatus = D 1.1.0.0.1.1.0.0 1.1.0.0.0.1.0.0
F incasso indicatie= J 1.1.0.0.1.1.0.0 1.1.0.0.1.0.0.0
G opdrachtstatus = K 1.1.0.0.0.1.1.0 1.1.0.0.0.1.0.0
H opdracht bedrag >20K 1.1.0.0.0.1.1.1 1.1.0.0.0.1.1.0
In dit voorbeeld blijven acht testsituaties over. De Elementaire vergelijkingentest biedt

mogelijkheden voor dit type complexe functies.
Bij eenvoudige functies waar het mogelijk is een eenvoudige functionele structuur op te
zetten, wordt veel gebruik gemaakt van de Semantische test.
Bij complexere functiebeschrijvingen wordt gebruik gemaakt van de DFT of EVT. Het belang
van de functie en de inzichtelijkheid van de functionaliteit bepalen de keuze voor de DFT of
EVT. Met name voor de uitgebreide complexere functies biedt de EVT de benodigde houvast
om alle zinvolle combinaties te bepalen.
12.5.2 Combinatie inpasbaarheid en functionaliteit

Soms is het mogelijk om testgevallen van meerdere testspecificatietechnieken te
combineren.
Bij de testuitvoering wordt vaak gestart met het testen van de inpasbaarheid. Met behulp van
de Procescyclustest (PCT) worden de te testen testpaden bepaald. Deze worden bepaald
door het analyseren van de beslispunten in de AO-procedures. Binnen de PCT wordt voor
elk resultaat van het beslispunt een test gedefinieerd. Het beslispunt waarbij de invoer van
een formulier wordt beoordeeld heeft twee resultaten namelijk het formulier is goed of het
formulier is fout. Conform de PCT test leidt dit dus tot twee testsituaties.
Bij het analyseren van de functionaliteit blijkt echter dat het formulier is fout binnen dit
beslispunt bepaald kan worden door verschillende situaties. De naam van de persoon kan
reeds bestaan, het adres van de persoon is ongeldig, zijn saldo is niet toereikend, etc.
Met behulp van een functionele test (bijvoorbeeld EVT of DFT) worden de testgevallen van
deze functionele beschrijving bepaald. Zo kunnen er bijvoorbeeld zes verschillende
testgevallen worden bepaald voor deze fout situaties.

Het foutpad uit de PCT afleiding wordt zes keer herhaald, waarbij in elke herhaling één van
de functionele testgevallen wordt opgenomen. Hierdoor ontstaan combinaties van
testgevallen van de Procescyclustest en Dataflowtest/Elementaire
vergelijkingentest/Semantische test.
Primair staat inpasbaarheid centraal, maar de testen voor het kwaliteitsattribuut functionaliteit
worden daarmee gecombineerd.

Onderwerp Bijlage 1. Opstellen teststrategie Datum 05-01-2001
Bijlage 1. Opstellen teststrategie

De activiteiten die uitgevoerd moeten worden om te komen tot een verdeling van de
testinspanning over de verschillende kwaliteitsattributen en deelsystemen zijn de volgende:
Activiteit 1: Bepalen kwaliteitsattributen

In overleg met de stuurgroep en eventueel andere betrokkenen, worden de
kwaliteitsattributen vastgesteld, waarop de test dient te zijn gericht.
Hierbij zijn de risicos die de stuurgroep voorziet m.b.t. het informatiesysteem van cruciaal
belang. Tijdens de test wordt getracht de risicos te beperken met behulp van de
kwaliteitsattributen.
Bij het selecteren van de kwaliteitsattributen wordt rekening gehouden met aspecten zoals
gespecificeerde systeemeisen, bedrijfsdoelstellingen met betrekking tot het
informatiesysteem en normen en standaards.
Men dient zich te realiseren dat sommige kwaliteitsattributen (zoals bijvoorbeeld de statische
kwaliteitsattributen) moeilijk te testen zijn. Het is niet zinvol keuzen te bieden die achteraf niet
waargemaakt kunnen worden. Men zal dus vooraf moeten bepalen wat de minimale
inspanning is die nodig is indien een bepaalde keuze wordt gemaakt.
Bij het vaststellen van de strategie moet inzicht worden verkregen in de manier van
ontwikkeling. Vooral de gebruikte tools en werking daarvan. Dit kan invloed hebben op de te
testen kwaliteitsattributen. In hoeverre zijn bijvoorbeeld CASE tools gebruikt en welke
controles zijn daarin impliciet aanwezig. Een globale controle van de eventuele impliciete
controles moet wel aangetoond kunnen worden. Tevens is hier de volgende waarschuwing
op zijn plaats: voorkom dat de test te afhankelijk wordt van het ontwikkelteam of dat het een
white-box test wordt.
De specificaties zoals die in het systeemontwerp zijn vastgelegd moeten te allen tijde het
uitgangspunt zijn en blijven bij de test. Dit om ervoor te zorgen dat getest wordt op basis van
de specificaties waarmee het ontwikkelteam het informatiesysteem ontwikkelt (harde feiten)
i.p.v. verwachtingen (van de gebruikersorganisatie).
Over de geselecteerde kwaliteitsattributen moet tijdens de uitvoering en afronding van de

test worden gerapporteerd aan de stuurgroep.
Activiteit 2: Bepalen relatief belang kwaliteitsattributen

Op basis van de resultaten uit activiteit 1 dient te worden aangegeven hoe de testinspanning
zou moeten worden verdeeld over de geselecteerde kwaliteitsattributen met als uitgangspunt
dat het testen van ieder kwaliteitsattribuut even arbeidsintensief is. Dit gebeurt door in de
gewichtenmatrix het relatieve belang (in procenten) aan te geven met betrekking tot de
geselecteerde kwaliteitsattributen.
Per geselecteerd kwaliteitsattribuut wordt bepaald wat het relatieve belang is. Dit wordt in de
gewichtenmatrix aangegeven door middel van een percentage in de kolom relatief belang.
Om de stuurgroep te dwingen keuzen te maken geldt als richtlijn dat het percentage
minimaal 5% dient te zijn. De som van alle percentages dient uiteraard 100% te zijn.
Bij de selectie van kwaliteitsattributen betekent het niet dat overige kwaliteitsattributen niet
worden getest. Deze kwaliteitsattributen zullen echter meer impliciet worden getest.

Activiteit 3: Onderverdeling in deelsystemen

Het informatiesysteem wordt tijdens deze activiteit onderverdeeld in deelsystemen, met als
doel het belang van de verschillende deelsystemen te kunnen vaststellen. Meestal wordt
dezelfde onderverdeling gebruikt als in het systeemontwerp. Het is niet vereist alle
deelsystemen met dezelfde diepgang te testen. Als van deze onderverdeling wordt
afgeweken dient dit te worden beargumenteerd en beschreven. Indien sprake is van
conversieprogrammatuur dan wordt dit vaak als een afzonderlijk deelsysteem beschouwd.
Tevens wordt vaak ook het deelsysteem totaal systeem onderkend, om aan te kunnen geven
wat het relatieve belang is van een integrale test. Tijdens de integrale test wordt bijvoorbeeld
met behulp van een Gegevenscyclustest, de samenhang tussen de diverse deelsystemen
getest.
Activiteit 4: Bepalen relatief belang deelsystemen

Op basis van het resultaat van activiteit 3 moet nu worden aangegeven, hoe de
testinspanning verdeeld wordt over de deelsystemen. Dit gebeurt door in de gewichtenmatrix
het relatieve belang aan te geven met betrekking tot de onderkende deelsystemen. Het gaat
er hierbij niet om de percentages exact vast te stellen, maar om in samenspraak met de
stuurgroep en andere betrokkenen een algemeen beeld te krijgen van het belang van de
diverse deelsystemen. Op deze wijze is men gedwongen hierover na te denken. Per
deelsysteem wordt bepaald wat het relatieve belang is binnen het informatiesysteem. Dit
wordt in de gewichtenmatrix aangegeven door middel van een percentage in de rij Relatief
belang deelsysteem.
Tenslotte wordt door middel van een + teken aangegeven of een bepaald kwaliteitsattribuut
van toepassing is voor een bepaald deelsysteem. Met ++ wordt aangegeven dat relatief veel
aandacht dient te worden gegeven aan de combinatie kwaliteitsattribuut/deelsysteem.
Voorbeeld van een gewichtenmatrix:
Deelsysteem Deelsyst. 1 Deelsyst. 2 Conversie Totaal Relatief

Kwaliteitsattribuut systeem Belang
Functionaliteit + + ++ 50%
Performance ++ ++ 20%
Beveiliging + 5%
Controleerbaarheid ++ ++ 10%
Beheerbaarheid + 10%
Gebruikersvriendelijkheid ++ + 5%
Relatief belang 20 30 10 40 100%
deelsysteem
Nogmaals wordt er op gewezen dat het bepalen van de teststrategie geen mathematische
aangelegenheid is, maar bedoeld om het beeld van de stuurgroep te krijgen van het relatieve
belang van de diverse deelsysteem/kwaliteitsattribuut combinaties.
Activiteit 5: Bepalen te gebruiken testtechnieken

Hier worden testtechnieken geselecteerd, waarmee de geselecteerde kwaliteitsattributen in
de onderkende deelsystemen getest gaan worden. Veelal zal het testen gebeuren met
behulp van gerichte invoer (testgevallen), dynamisch expliciet testen. Hiervoor zijn diverse
testtechnieken beschikbaar. Het testen kan ook plaatsvinden door middel van het opbouwen
van statistieken tijdens het ontwikkeltraject en uitvoering van de test (dynamisch impliciet
testen) en/of door middel van een beoordeling van de genomen maatregelen op basis van
een checklist (statisch testen).

Het is van belang reeds in een vroegtijdig stadium van het testproces een selectie te maken
met betrekking tot de testtechnieken. Het acceptatieteam kan dan, indien noodzakelijk,
worden opgeleid in de testtechnieken en desgewenst kunnen de benodigde checklists
worden aangepast aan de specifieke situatie.
In de matrix is aangegeven welke technieken in aanmerking komen om een test met
betrekking tot een kwaliteitsattribuut uit te voeren. Getracht moet worden om met een
minimale verzameling technieken alle geselecteerde kwaliteitsattributen af te dekken. Bij het
selecteren moet tevens rekening worden gehouden met de ervaring van de projectgroep
acceptatie en de beschikbare testbasis.
CKL DIT DFT EVT EG PCT RLT SEM SYN

Beheerbaarheid x
Beveiliging x x x x x
Bruikbaarheid x
Connectiviteit x
Continuïteit x x
Controleerbaarheid x x x x
Flexibiliteit x
Functionaliteit x x x x x
Gebruikersvriendelijkh. x x x x x
Herbruikbaarheid x
Infrastructuur x x
Inpasbaarheid x x
Onderhoudbaarheid x
Performance x x
Portabiliteit x
Testbaarheid x x
Zuinigheid x x
Toelichting gebruikte afkortingen (zie hoofdstuk 10 Testspecificatietechnieken voor een

beschrijving van de testspecificatietechnieken) :
CKL : Beoordelen m.b.v. een Checklist
DIT : Detail Intake Testbasis
DFT : Dataflowtest
EVT : Elementaire vergelijkingentest
EG : Error guessing
PCT : Procescyclustest
RLT : Real-life test
SEM : Semantische test
SYN : Syntactische test
De testtechniek error guessing lijkt volgens bovenstaande tabel een erg aantrekkelijke
techniek, omdat deze op bijna alle kwaliteitsattributen toepasbaar is. Bedacht moet worden
dat deze techniek niets anders is dan met kennis van zaken ongestructureerd testen. Error
guessing is daarom slechts een waardevolle aanvulling op de gestructureerde
testtechnieken.
Naast een aantal testspecificatietechnieken worden ook checklist gehanteerd bij het
beoordelen van de kwaliteit van het testobject. Met name voor kwaliteitsattributen waarbij het
definiëren van concrete testgevallen niet eenvoudig is, zijn checklists een waardevolle
aanvulling.

Activiteit 6: Bepalen acceptatiecriteria

Als laatste Activiteit binnen de teststrategie wordt, in samenspraak met de stuurgroep en de
begeleidingsgroep, bepaald onder welke voorwaarden het informatiesysteem aan een
bepaald kwaliteitsattribuut voldoet. De voorwaarden voor de verschillende kwaliteitsattributen
vormen de zogenaamde acceptatiecriteria.
Toelichting
Het bepalen van een teststrategie is een instrument om met de stuurgroep/opdrachtgever
van de test te communiceren over de organisatie en de strategische keuzen van de test.
Er is een aantal redenen waarom de strategiebepaling van belang is:

• De stuurgroep/opdrachtgever verwacht een bepaald kwaliteitsniveau van het op te
leveren informatiesysteem. Dit kwaliteitsniveau uit zich in een aantal eigenschappen van
het informatiesysteem, kwaliteitsattributen genaamd. Bij het bepalen van de
kwaliteitsattributen, wordt rekening gehouden met aspecten als normen en standaards,
gespecificeerde systeemeisen, bedrijfsdoelstellingen, etc. Kwaliteitsattributen kunnen per
informatiesysteem verschillend zijn. Van deze kwaliteitsattributen worden de
voorwaarden bepaald waaraan het informatiesysteem minimaal moeten voldoen, de
zogenaamde acceptatiecriteria. Tevens verwacht de opdrachtgever een relatief belang
tussen de verschillende kwaliteitsattributen.
• De beschikbare periode om de test uit te voeren is per definitie altijd beperkt. Als gevolg
hiervan kan niet alles worden getest, er zullen dus keuzen gemaakt moeten worden. Het
streven moet zijn:
- De belangrijkste fouten te vinden. Dit zijn fouten die de meeste invloed hebben op het
goed functioneren van het informatiesysteem;
- De fouten zo vroeg mogelijk te vinden;
- Er op te anticiperen dat het informatiesysteem nooit voor de volle 100% kan worden
getest;
- Van de kwaliteitsattributen te bepalen in hoeverre aan de bijbehorende
voorwaarde(n) wordt voldaan.
Op basis van de teststrategie kan een begroting worden opgesteld voor het testtraject.
Overzicht kwaliteitsattributen
Om tot de bepaling van de gewenste kwaliteitseisen te komen, dient eerst bepaald te worden
welke kwaliteitsattributen daarbij überhaupt aan de orde komen. Met een kwaliteitsattribuut
wordt een eigenschap van een informatiesysteem bedoeld. Er wordt onderscheid gemaakt
tussen dynamische en statische kwaliteitsattributen.
De hieronder beschreven kwaliteitsattributen zijn moeilijk hanteerbaar voor personen die een
beperkte automatiseringsachtergrond hebben. De betreffende begrippen zullen derhalve
verlevendigd moeten worden: vertaald naar de begripsomgeving van de gesprekspartner. Dit
kan bijvoorbeeld geschieden, door bij de verschillende kwaliteitsattributen ter illustratie
treffende voorbeelden te zoeken van fouten.
Dynamische kwaliteitsattributen
Bij de dynamische kwaliteitsattributen gaat het om het functioneren van het
informatiesysteem gezien vanuit gebruikersoogpunt ofwel aspecten die van belang zijn voor
de eindgebruiker. Deze worden meestal dynamisch getest (zie paragraaf 1.7
Testmeetmethoden).

Van elk kwaliteitsattribuut staat een definitie weergegeven. Het belang van deze definities is,
dat zowel voor stuurgroep/opdrachtgever en opdrachtnemer, als andere betrokkenen
duidelijk is wat er wordt bedoeld.
• Beveiliging
De zekerheid dat raadpleging of mutatie van de gegevens, beschikbaarheid van menu-
opties etc. uitsluitend mogelijk is door de personen die daartoe bevoegd zijn.
• Bruikbaarheid
De mate waarin het informatiesysteem is toegesneden op de organisatie en de
eindgebruikers voor wie het bedoeld is alsmede de mate waarin het informatiesysteem
bijdraagt aan het bereiken van bedrijfsdoelstellingen.
• Continuïteit
De zekerheid dat het gebruik van het informatiesysteem ongestoord voortgang zal
kunnen vinden. Dit houdt ook in dat, na ernstige storingen, binnen redelijke termijn het
gebruik weer kan worden hervat. Het kwaliteitsattribuut continuïteit kan eventueel worden
uitgesplitst in kwaliteitsattributen die achtereenvolgens van toepassing zijn bij een
toenemende verstoring van het informatiesysteem.
- Bedrijfszekerheid: de mate waarin de gegevensverwerking vrij blijft van storingen;
- Robuustheid: de mate waarin de informatievoorziening ook na een storing gewoon
kan doorgaan;
- Herstelbaarheid: het gemak en de snelheid waarmee de informatievoorziening na een
storing hersteld kan worden;
- Degradatiemogelijkheid: het gemak waarmee de kern van de informatievoorziening
kan worden voortgezet nadat een deel is uitgevallen;
- Uitwijkmogelijkheid: het gemak waarmee (een deel van) de informatievoorziening op
een andere locatie of computersysteem kan worden voortgezet.
• Controleerbaarheid
Het gemak waarmee de juistheid en volledigheid van de informatie (in het verloop van de
tijd) gecontroleerd kunnen worden.
• Functionaliteit
De zekerheid dat de verwerking van de gegevens juist en volledig geschiedt, conform de
beschrijving in de functionele specificaties. Het kwaliteitsattribuut functionaliteit kan
worden uitgesplitst in:
- Juistheid: de mate waarin het informatiesysteem de aangeboden invoer en mutaties
correct volgens de specificatie verwerkt tot consistente gegevensverzamelingen;
- Volledigheid: de zekerheid dat alle invoer en mutaties verwerkt worden door het
informatiesysteem;
- Tijdigheid: de zekerheid dat de informatie binnen de gestelde tijd beschikbaar komt
voor andere processen.
• Gebruikersvriendelijkheid
Het gemak waarmee eindgebruikers het informatiesysteem kunnen gebruiken. Het
kwaliteitsattribuut gebruikersvriendelijkheid kan worden uitgesplitst in:
- Leerbaarheid: het gemak waarmee de eindgebruiker leert om te gaan met het
informatiesysteem;
- Bedieningsgemak: het gemak waarmee geoefende eindgebruikers het
informatiesysteem bedienen.

• Inpasbaarheid
De mate waarin de handmatige procedures aansluiten op het informatiesysteem en de
werkbaarheid van deze handmatige procedures voor de administratieve organisatie.
• Performance
De snelheid waarmee het informatiesysteem de batch en on-line transacties afhandelt en
de snelheid van de totale handmatige en geautomatiseerde informatieverwerking bij on-
line transacties.
• Zuinigheid
De verhouding tussen het prestatieniveau van de gehele informatievoorziening
(handmatig en geautomatiseerd) en de totale hoeveelheid middelen die daarvoor worden
gebruikt.
Statische kwaliteitsattributen
Bij de statische kwaliteitsattributen gaat het om de intrinsieke (innerlijke) eigenschappen van
een informatiesysteem en de bijbehorende documentatie gezien vanuit het standpunt van de
ontwikkelaars, reviewers, de (toekomstige) systeembeheerders en technisch- en functioneel
applicatiebeheerders. De hierna opgesomde kwaliteitsattributen worden meestal statisch
getest.
• Beheerbaarheid
Het gemak waarmee het informatiesysteem in operationele staat kan worden gebracht en
gehouden. Installeerbaarheid is een onderdeel van beheerbaarheid.
• Connectiviteit
Het gemak waarmee koppelingen tussen deelsystemen en andere informatiesystemen
tot stand gebracht en aangepast kunnen worden.
• Geschiktheid infrastructuur
De geschiktheid van de apparatuur, het netwerk, de systeemsoftware, de RDBMS etc.
voor het betreffende informatiesysteem en de mate waarin deze onderdelen op elkaar
aansluiten.
• Flexibiliteit
De mate waarin en het gemak waarmee de gebruiker zelf in staat is variaties op het
informatiesysteem aan te brengen zonder dat de programmatuur daarvoor moet worden
aangepast.
• Herbruikbaarheid
De mate waarin delen van het informatiesysteem, of van het ontwerp, opnieuw gebruikt
kunnen worden in of voor de ontwikkeling van andere toepassingen.
• Onderhoudbaarheid
Het gemak waarmee correctief, adaptief, en functioneel onderhoud kan worden
uitgevoerd op het informatiesysteem.
• Portabiliteit
De mogelijkheid om het informatiesysteem op verschillende technische infrastructuren te
laten draaien en het gemak waarmee van de ene naar de andere infrastructuur kan
worden overgegaan.

• Testbaarheid
Het gemak en de snelheid waarmee de functionaliteit en de kwaliteit van het
informatiesysteem (na onderhoud) getest kunnen worden.
Verwijzingen
• Hoofdstuk 12 Testspecificatietechnieken
Naast de in dit handboek gehanteerde kwaliteitsattributen kan ook gebruik worden gemaakt
van het (extended) ISO-9126 model. Zie hiervoor het boek Kwaliteit van softwareprodukten
van Van Zeist e.a.

Onderwerp Bijlage 2. Definities en afkortingen Datum 05-01-2000
Bijlage 2. Definities en afkortingen

Acceptatiecriteria De voorwaarden waaraan de geselecteerde kwaliteitsattributen van een
informatiesysteem moeten voldoen.
Acceptatietest De door de (toekomstige) gebruikers en beheerders in een zoveel
mogelijk als-het-ware-productie omgeving uitgevoerde test, die moet
aantonen dat het ontwikkelde informatiesysteem aan de functionele en
kwalitatieve eisen voldoet.
Testproject Project waarin de planning, voorbereiding, specificatie, uitvoering en
afronding van een test worden uitgevoerd.
Testtraject Zie testproject.
Adaptief Onderhoud dat voortkomt uit wijzigingen in de omgeving waarin een
onderhoud informatiesysteem functioneert.
AO Administratieve Organisatie.
Applicatie Een toepassingsprogramma dat voor een groep van gebruikers c.q.
organisatie is geschreven en dat betrekking heeft op de activiteiten van
deze gebruikers/organisatie.
AT Acceptatietest.
Attribuut Een karakteriserend kenmerk van een entiteit dat correspondeert met
een eigenschap van een object dat door de entiteit wordt
gerepresenteerd. Bijvoorbeeld de achternaam van een lid van de
tennisclub.
Audit Een door een onafhankelijke instantie uitgevoerd formeel onderzoek op
een product of een project t.a.v. eisen, specificaties, uitgangspunten,
standaards, procedures en contracten met als doel de status vast te
stellen.
Automatiserings- Beschrijving van de verwachting die gebruikers hebben van een
verwachting informatiesysteem.
Back-up Het veiligstellen van één of meer bestanden naar een ander
opslagmedium als voorzorg voor het geval dat de oorspronkelijke
bestanden beschadigd raken of verloren gaan.
Batch Groepsgewijze verwerking van gegevens.
Bedienings- Het gemak waarmee geoefende eindgebruikers het informatiesysteem
gemak bedienen.
Bedrijfszekerheid De mate waarin de gegevensverwerking vrij blijft van storingen.
Beheerbaarheid Het gemak waarmee het informatiesysteem in operationele staat kan
worden gebracht en gehouden. Ook de installeerbaarheid is een
onderdeel van de beheerbaarheid.
Beveiliging De zekerheid dat raadpleging of mutatie van de gegevens,
beschikbaarheid van menu-opties etc. uitsluitend mogelijk is door die
personen die daartoe bevoegd zijn.
Bevinding Waarneming van een mogelijk probleem naar aanleiding van een toets of
test. Zie ook testbasisbevinding en testobjectbevinding.
Black-box test Test op extern zichtbare eigenschappen van het object, zonder kennis
van de interne opzet van het object.
Bruikbaarheid De mate waarin het informatiesysteem is toegesneden op de organisatie
en de eindgebruikers voor wie het bedoeld is alsmede de mate waarin
het informatiesysteem bijdraagt aan het bereiken van
bedrijfsdoelstellingen.
CASE Computer Aided Software Engineering.
Connectiviteit Het gemak waarmee koppelingen tussen deelsystemen en andere
informatiesystemen tot stand gebracht en aangepast kunnen worden.

Conserveren Het bewaren van testware op dusdanige wijze dat deze geschikt is voor
hergebruik.
Continuïteit De zekerheid dat het gebruik van het informatiesysteem ongestoord
voortgang zal kunnen vinden.
Controleerbaar- Het gemak waarmee de juistheid en volledigheid van de informatie (in het
heid verloop van de tijd) gecontroleerd kunnen worden.
Correctief Het corrigeren van fouten in programmatuur.
onderhoud
Coverage Zie dekkingsgraad.
Database Een, in een computerbestand, opgeslagen verzameling van aan elkaar
gerelateerde gegevens, zodanig geordend, dat meerdere
benaderingswijzen en toepassingen voor het gebruik van deze gegevens
mogelijk zijn.
DBA Database Administrator. Zie gegevensbankbeheerder.
Debugger Een programma dat is ontworpen is om fouten in programmatuur op te
sporen.
Deelsysteem Een onderdeel van een informatiesysteem bestaande uit één of meer
logisch bij elkaar horende objecten.
Degradatiemoge- Het gemak waarmee de kern van de informatievoorziening kan worden
lijkheid voortgezet nadat een deel is uitgevallen.
Dekkingsgraad De verhouding tussen datgene wat getest kan worden en datgene wat
getest is/wordt.
DFT Dataflowtest.
Dynamisch Testen, op basis van gerichte testgevallen, door executie van het
testen testobject c.q. het uitvoeren van programmas.
Dynamische Het geheel van gebruikseigenschappen van het informatiesysteem
kwaliteits- gezien vanuit gebruikersoogpunt, ofwel de kwaliteit die wordt ervaren
attributen door de eindgebruiker.
EG Error guessing.
Entiteit Een object (ding, persoon, plaats, concept of gebeurtenis) van belang
voor een persoon of organisatie waarover informatie wordt onderhouden.
EVT Elementaire vergelijkingentest.
EXP Exploitatie.
FAB Functioneel applicatiebeheerder.
FAGAN-inspectie Vorm van inspectie, ontwikkeld door de heer M. Fagan bij IBM. De
FAGAN-inspectie is erop gericht in een zo vroeg mogelijk stadium fouten
in producten te vinden, te herstellen en indien mogelijk de fout-oorzaak
weg te nemen. Bij een FAGAN-inspectie beoordelen meerdere
functionarissen onder begeleiding van een procesbegeleider het product.
Iedere functionaris bekijkt het product vanuit zijn eigen invlashoek.
Flexibiliteit De mate waarin en het gemak waarmee de gebruiker zelf in staat is
variaties op het informatiesysteem aan te brengen zonder dat de
programmatuur daarvoor moet worden aangepast.
Functiepunt Een objectieve (meet)eenheid waarin de omvang en complexiteit van een
functie worden uitgedrukt.
Functionaliteit De zekerheid dat de verwerking van de gegevens juist en volledig
geschiedt, conform de beschrijving in de functionele specificaties.
Functioneel Onderhoud op programmatuur als gevolg van nieuwe wensen van de
onderhoud gebruiker t.a.v. de functionaliteit.
Functionele Alle specificaties die aangeven welke gegevens verwerkt en verstrekt
specificaties moeten worden.
GCT Gegevenscyclustest.

Gebruikershand- Een handleiding die het informatiesysteem beschrijft ten behoeve van de
leiding eindgebruiker.
Gebruikersinter- Interface dat een eindgebruiker in staat stelt om met een
face informatiesysteem te communiceren.
Gebruikers- Het gemak waarmee de eindgebruiker kan leren omgaan met het
vriendelijkheid informatiesysteem en het bedieningsgemak van het informatiesysteem
voor geoefende gebruikers
Gegevensbank- De beheerder van een gegevensbank, ook wel DBA genoemd.
beheerder
Geschiktheid De geschiktheid van de apparatuur, het netwerk, de systeemsoftware, de
infrastructuur RDBMS etc. voor het betreffende informatiesysteem en de mate waarin
deze onderdelen op elkaar aansluiten.
Goedpad De reactie van het testobject op correcte invoer.
Hardware De vaste elektronische en mechanische delen van een
computersysteem.
Herbruikbaarheid De mate waarin delen van het informatiesysteem, of van het ontwerp,
opnieuw gebruikt kunnen worden in of voor de ontwikkeling van andere
toepassingen.
Herstelbaarheid Het gemak en de snelheid waarmee de informatievoorziening na een
storing hersteld kan worden
Hertest Het opnieuw uitvoeren van een test nadat het testobject is aangepast of
nadat aanpassingen zijn uitgevoerd in de testdata.
Importeren Het laden van gegevens in een database.
Informatiemap Document waarin de organisatie en materie, het project en het
informatiesysteem worden beschreven teneinde leden van de
projectgroep acceptatie snel een indruk te geven van het
informatiesysteem en zn omgeving.
Informatie- Het totaal van structuren en middelen die gebruikt worden om een
systeem organisatie van informatie te voorzien. Naast de
applicatie(programmatuur) is er bijvoorbeeld ook de AO-procedure, de
technische infrastructuur, de bijbehorende documentatie en de
beveiliging.
Infrastructuur Het geheel van faciliteiten en procedures waarin de beheersing en
uitvoering van de informatievoorziening en de richtlijnen voor de
automatisering zijn opgenomen.
Inpasbaarheid De mate waarin de handmatige procedures aansluiten op het
informatiesysteem en de werkbaarheid van deze handmatige procedures
voor de administratieve organisatie.
Installatiehand- Een handleiding die beschrijft hoe de installatie van het
leiding informatiesysteem moet worden uitgevoerd.
Intake testbasis Het beoordelen van de betreffende specificaties op testbaarheid.
Integratietest Een door de ontwikkelaar uitgevoerde test, die moet aantonen dat een
logische combinatie van modules, die samen een functie vormen, voldoet
aan de technische specificaties.
Interface Koppeling, raakvlak, verbinding, een gemeenschappelijke begrenzing.
Een interface kan een onderdeel van de apparatuur zijn, waardoor twee
eenheden met elkaar verbonden worden. Interfaces zijn er ook tussen
programmasystemen.
Invoerings- Het moment waarop (een nieuwe versie) van een applicatie
moment daadwerkelijk wordt geoperationaliseerd.
Juistheid De mate waarin het informatiesysteem de aangeboden invoer en
mutaties correct volgens de specificatie verwerkt tot consistente
gegevensverzamelingen.

Kwaliteit Mate waarin een product (in dit geval een informatiesysteem) voldoet aan
de gestelde functionele specificaties en prestatie-eisen.
Kwaliteit (ISO) Het geheel van eigenschappen en kenmerken van een product of dienst
dat van belang is voor het voldoen aan vastgestelde of vanzelfsprekende
behoeften.
Kwaliteitsattribuut Eigenschap van een informatiesysteem.
Leerbaarheid Het gemak waarmee de eindgebruiker leert om te gaan met het
informatiesysteem.
Netwerk Het geheel van faciliteiten benodigd om gegevens over te dragen tussen
computers onderling en tussen computers en randapparatuur.
Onderhoudbaar- Het gemak waarmee correctief, adaptief, en functioneel onderhoud kan
heid worden uitgevoerd op het informatiesysteem.
Onderhoudstest Test naar aanleiding van onderhoud dat op een informatiesysteem is
uitgevoerd. Zie ook regressietest.
On-line Wijze van functioneren van een systeem waarbij het systeem opdrachten
direct uitvoert en het antwoord (de uitvoer) direct op het scherm of
anderszins toont.
Ontwikkelteam Groep van mensen die de programmatuur van een informatiesysteem
ontwikkelt.
PCT Procescyclustest.
Perfectief Onderhoud op programmatuur als gevolg van een verhoging van de
onderhoud kwaliteitseisen van de gebruiker (prestatieverbetering).
Performance De snelheid waarmee het informatiesysteem de batch en on-line
transacties afhandelt en de snelheid van de totale handmatige en
geautomatiseerde informatieverwerking bij on-line transacties.
Portabiliteit De mogelijkheid om het informatiesysteem op verschillende technische
infrastructuren te laten draaien en het gemak waarmee van de ene naar
de andere infrastructuur kan worden overgegaan.
Post-conditie Het gewenste c.q. vereiste resultaat van de uitvoering van een test.
Pré-conditie De voorwaarden waaraan voldoen moet zijn voordat een test kan worden
uitgevoerd. Een pré-conditie staat beschreven in het testscript.
Pré-test Het zodanig testen van de opgeleverde producten, dat bepaald wordt of
het zinvol is een gestructureerde test met betrekking tot het testobject uit
te voeren.
Procedure Handelwijze die men moet volgen om iets te bereiken.
Programmatest De door de ontwikkelaar uitgevoerde test die moet aantonen dat een
individueel programma aan de in het SO gestelde eisen voldoet (white-
box test).
RDBMS Relational Database Management System. Zie ook database.
Regressietest Test die (opnieuw) wordt uitgevoerd om de gevolgen van een
doorgevoerde wijziging te controleren. Regressie is de zekerheid dat de
kwaliteit van een informatiesysteem niet terugloopt.
Responsetijd De tijd, die verloopt tussen het moment, waarop men een
computersysteem een bewerking opdraagt en het moment, waarop het
resultaat beschikbaar komt
Review Het toetsen van een product aan normen, standaards en richtlijnen met
als resultaat een onderbouwde beoordeling van het betreffende product.
RLT Real-life test.
Robuustheid De mate waarin de informatievoorziening ook na een storing gewoon kan
doorgaan.
SEM Semantische test;
Software Totaal van computerprogrammas en gegevens waarmee de computer

bewerkingen uitvoert.
Statische Het geheel van beheerseigenschappen van een informatiesysteem, ofwel
kwaliteitsattri- de kwaliteit die wordt ervaren door de onderhoudsorganisatie,
buten verwerkingsorganisatie en reviewers.
Statische test Test d.m.v. controle en onderzoek van producten, zonder dat er sprake is
van het uitvoeren van programmas.
Strategiebepaling Het proces om te komen tot een (test)strategie.
SYN Syntactische test.
Systeem Een combinatie van mensen, machines en methoden om bepaalde
functies te verrichten.
Systeemtest Een door de ontwikkelaar uitgevoerde test, die moet aantonen dat het
ontwikkelde systeem of delen daarvan aan de in het SO gestelde eisen
voldoet.
Testaanpak Aanpak die beschrijft hoe een test uitgevoerd zal worden.
Testactie Een handeling in een van te voren gedefinieerde uitgangssituatie die
goed of fout kan verlopen.
Testbaarheid Het gemak en de snelheid waarmee de functionaliteit en de kwaliteit van
het informatiesysteem (na onderhoud) getest kunnen worden.
Testbasis Alle documenten, waaruit de eisen zijn af te leiden, die aan een
informatiesysteem worden gesteld.
Testbasisbevin- Melding van een incorrecte specificatie die geconstateerd wordt in de
ding testbasis.
Testdossier Een dossier met daarin de informatie over het verloop en de resultaten
van een test zoals:Bijbehorend(e) testobject(en) en hun status;Het
testdraaiboek;Testresultaten;Bevindingrapportages.
Testdraaiboek Een planning van de uit te voeren testscripts; de testscripts zijn in het
testdraaiboek in onderlinge samenhang en uit te voeren volgorde
aangegeven.
Testeenheid Een verzameling processen, transacties en/of functies die gezamenlijk
worden getest.
Testen Het proces van plannen, voorbereiden en meten dat tot doel heeft
kenmerken van een informatiesysteem vast te stellen en het verschil
tussen de actuele en de vereiste status aan te tonen.
Testgeval Een logische of fysieke omschrijving van een uit te voeren test, gericht op
een specifiek testdoel en gerelateerd aan een bepaalde testeenheid.
Testinfrastructuur De omgeving waarin de test wordt uitgevoerd, bestaande uit apparatuur,
systeemsoftware, testtools, procedures, kantoorruimte, etc.
Testobject Het te testen (deel van het) informatiesysteem.
Testobjectbevin- Een verschil dat geconstateerd is tijdens het confronteren van de
ding testgevallen met het testobject.
Testomgeving Alle faciliteiten die nodig zijn om de daadwerkelijke testen uit te kunnen
voeren. De testomgeving is een onderdeel van de testinfrastructuur.
Testproduct Eindproduct dat tijdens het testproces is geproduceerd.
Testpuntanalyse Analyse waarmee de omvang van een uit te voeren test kan worden
gemeten.
Testrun De uitvoering van een test.
Testscript Opeenvolging van samenhangende acties en controles, gerelateerd aan
fysieke testgevallen, waarvan de volgorde van uitvoering is aangegeven.
Een beschrijving van hoe er getest gaat worden.
Testset Een verzameling testgevallen specifiek gericht op één of meer
kwaliteitsattributen en één of meer testeenheden.
Testsoort Een groep testactiviteiten die gezamenlijk wordt uitgevoerd en

aangestuurd.
Testspecificatie Een beschrijving van de wijze waarop de logische testgevallen zijn
geselecteerd, alsmede een beschrijving van de logische testgevallen.
Een beschrijving van wat er getest gaat worden.
Testspecificatie- Een gestandaardiseerde manier om vanuit uitgangsinformatie
techniek testgevallen af te leiden.
Teststrategie De uitgangspunten en randvoorwaarden die vastgesteld zijn teneinde met
minimale middelen een maximaal rendement uit de test te behalen.
Testtechniek Samenstel van acties om op universele wijze een testproduct te
produceren.
Testtool Een programma dat ondersteuning biedt bij de testactiviteiten m.b.t.
planning en beheer, specificatie, testuitvoering en beoordeling van de
testresultaten
Testware Alle testdocumentatie, zoals o.a. testspecificaties, testscripts en een
beschrijving van de testinfrastructuur, die tijdens het testproces wordt
geproduceerd. Als eis geldt dat de testware voor toekomstig onderhoud
gebruikt moet kunnen worden en daarom overdraagbaar en
onderhoudbaar moet zijn.
Tijdigheid De zekerheid dat de informatie binnen de gestelde tijd beschikbaar komt
voor andere processen.
Toetsen Het controleren en inspecteren van de diverse tussenproducten en/of
processen tijdens het ontwikkeltraject.
Tracer Een verslag van het uitvoeren van een programma; het toont de
volgorde, waarin de instructies zijn uitgevoerd.
Transactie Een gebeurtenis, die het noodzakelijk maakt de bestaande
bestandsgegevens te wijzigen.
Uitgangsdata- Database waarin zich initiële gegevens van een test bevinden.
base
Uitwijkmogelijk- Het gemak waarmee (een deel van) de informatievoorziening op een
heid andere locatie of computersysteem kan worden voortgezet.
Vergelijker Een tool waarmee het verwachte en werkelijke resultaat van een test
automatisch kunnen worden vergeleken.
Verwerkings- De organisatie die verantwoordelijk is voor de productie-omgeving in al
organisatie haar facetten. Ook wel systeembeheer of rekencentrum genoemd.
Volledigheid De zekerheid dat alle invoer en mutaties verwerkt worden door het
informatiesysteem.
White-box test Test op intern aanwezige eigenschappen van een object, met kennis van
de interne opzet van het object.
Zuinigheid De verhouding tussen het prestatieniveau van de gehele
informatievoorziening (handmatig en geautomatiseerd) en de totale
hoeveelheid middelen die daarvoor worden gebruikt.

Onderwerp Bijlage 3. Testtools Datum 05-01-2000
Bijlage 3 Testtools
Een testtool is een geautomatiseerd hulpmiddel dat specifiek het testproces ondersteunt. Bij
testen worden diverse geautomatiseerde hulpmiddelen gebruikt. Per taak binnen de fase
testen kunnen verschillende soorten testtools worden onderscheiden. Testtools kunnen
worden ingedeeld naar de onderstaande functionaliteit:
• Planning en beheer;
• Voorbereiding;
• Testspecificatie;
• Testuitvoering en analyse.
Standaardpakketten zoals Word en Excel worden niet gezien als testtool (hoewel ze vaak
wel onmisbaar zijn voor testtrajecten). Als met behulp van macro’s en dergelijke er specifieke
zaken zijn gemaakt in deze standaardpakketten kunnen dit weer wel als testtools worden
gezien.
Er bestaan een groot aantal standaard testtools die gebruikt kunnen worden gekocht en
ingezet. Niet in alle gevallen voldoen deze pakketten aan de eisen die eraan gesteld worden.
Naast het inzetten van standaard tools kunnen organisaties ook zelf tools ontwikkelen.
Hieronder wordt een overzicht gegeven van de diverse soorten testtools die het testtraject
kunnen ondersteunen. Met nadruk wordt er op gewezen dat dit overzicht niet uitputtend is.
Waarschuwing:
Testen is een arbeidsintensieve bezigheid. Om het testen te vergemakkelijken wordt
soms veel verwacht van testtools. Het gevaar bestaat, dat testtools een doel op
zichzelf worden en dat de hele testaanpak op het gebruik van bepaalde testtools
wordt toegesneden. Dit leidt helaas te vaak tot teleurstellingen. Allereerst is een
goede testomgeving nodig, waarin vervolgens eventueel een testtool nuttige diensten
kan bewijzen. Daarnaast is voor het gebruik van testtools opleiding noodzakelijk. Het
gaan gebruiken van testtools is in vele opzichten te vergelijken met een
automatiseringsproces. In feite wordt het testproces geautomatiseerd.
1 Planning en beheer
1.1 Planning
Voor het plannen en beheersen van projecten zijn allerlei tools te gebruiken. Hoewel deze
niet specifiek voor het testtraject zijn ontworpen, kunnen ze heel goede diensten bewijzen.
Het testproject is immers een project waar hoge eisen worden gesteld voor wat betreft de
actualiteit en kwaliteit van de voortgangsrapportage en -bewaking.
1.2 Voortgangsbewaking
Voor de bewaking van de voortgang bij omvangrijke projecten is een hulpmiddel erg handig.
Voortgangsbewakingspakketten dienen de functionaliteiten te bieden die nodig zijn om:
• Kennis te verkrijgen over de gemaakte voortgang in relatie tot budget, tijd en producten,
alsmede om hierover te kunnen rapporteren;
• Een nauwkeurige voorspelling te kunnen maken van de nog benodigde tijd en resources
om het testproces af te ronden.
Een voortgangsbewakingspakket is een hulpmiddel voor het meten en beheersen van de
voortgang van een testproject.

In de meeste pakketten zijn planning en voortgangsbewaking geïntegreerd. Hiermee is het

dus mogelijk om behalve de planning, met bijbehorende berekeningen en diagrammen, ook
de voortgang te bewaken en managementinformatie op te leveren zoals informatie m.b.t.
uitputting van de geplande tijd, resources en kosten. De voortgang wordt als het ware
getoetst aan de planning.
1.3 Bevindingenbeheer
Tijdens een testtraject wordt een aantal bevindingen gedaan. Tijdens de taken planning,
voorbereiding en specificatie hebben deze met name betrekking op de testbasis, terwijl bij de
taak uitvoering dit betrekking heeft op het testobject. Het aantal bevindingen kan zelfs bij een
klein informatiesysteem al aanzienlijk zijn. Het beheer van bevindingen is derhalve een
belangrijke, maar omvangrijke en complexe activiteit. Ter ondersteuning van deze activiteit
zijn er tools waarmee bevindingen kunnen worden vastgelegd en eventueel gedurende de
levenscyclus worden gevolgd en bewaakt (het zogenaamde problem-tracking). Sommige
tools voorzien tevens in de mogelijkheid van overzichten en statistieken. Deze functionaliteit
is erg handig en kan worden gebruikt bij de voortgangs- en eindrapportage.
1.4 Configuratiemanagement
Gedurende het testtraject is per definitie sprake van wijzigingen in zowel de testomgeving,
testware als het testobject (programmatuur) en de testbasis (alhoewel de laatste twee niet
onder de verantwoordelijkheid vallen van de projectgroep acceptatie).
Zeker indien veel wijzigingen op de verschillende objecten worden doorgevoerd kan een
configuratiemanagementtool (met name voor testobject en testware) een uitkomst bieden bij
het vastleggen, volgen en actueel houden van de verschillende versies. Een dergelijk tool
ondersteunt het beheer van de in de tijd ontstane versies van objecten.
1.5 Testmanagement
Deze tools zijn feitelijk een verzameling van de al genoemde soorten testtools, waarbij veel
nadruk is gelegd op de integratie tussen deze tools. Gebruik van het tool stuurt als het ware
het testproces, van het maken van het testplan tot en met het rapporteren over de resultaten.
2 Voorbereiding
2.1 Case tool analyser

Als de testbasis in een CASE tool is vastgelegd kunnen dergelijke tools diverse controles op
volledigheid en consistentie van de testbasis uitvoeren. Overigens worden veel van deze
(technische) controles tijdens de reviews door de Facilitaire Dienst uitgevoerd.
3 Testspecificatie
Bij het specificeren van testen worden aan de hand van beschreven
testspecificatietechnieken voor de verschillende testscripts initiële gegevens en acties
gespecificeerd. Deze testspecificaties kunnen in een tool worden vastgelegd. Ook kan vaak
de volgorde van uitvoering van de diverse testscripts worden vastgelegd. Meestal wordt op
basis van deze tools de testuitvoering aangestuurd.
3.1 Input generator

Op basis van de eerder vastgelegde testspecificaties kan een input generator testgevallen
genereren. Deze testspecificaties dienen daarvoor wel een formele specificatie te bevatten
van de mogelijke invoer.
4 Testuitvoering en analyse
Bij de testuitvoering en analyse kunnen verschillende typen tools gebruikt worden:

4.1 Capture & Playback

Tijdens het uitvoeren van een test kunnen zowel de acties (toetsaanslagen, muisklikken) als
de invoer van bijbehorende gegevens geautomatiseerd worden opgenomen (capture), door
middel van een soort van recorder. Op een later tijdstip kan de uitvoering van de test dan
herhaald worden (playback). Meestal worden deze tools gecombineerd met zogenaamde
vergelijkers (of comparators) om de resultaten van de test te vergelijken met de verwachte
resultaten.
Tijdens de eerste fase van de testuitvoering heeft het gebruik van deze tools vaak niet
zoveel zin, omdat testomgeving en testobject vaak nog sterk in beweging zijn. Het opnieuw
afspelen is dan vaak niet zinvol of zelfs onmogelijk. Wanneer voor een bepaalde test alle
problemen lijken te zijn opgelost, kan het gebruik nuttig zijn. Soms wordt alleen de laatste
testrun opgenomen, om deze te conserveren voor onderhoudstesten tijdens de exploitatie.
Vaak blijken deze tools meer te beloven dan ze kunnen waarmaken. Een goed ingericht
beheer met betrekking tot de opgenomen testruns is essentieel voor een vruchtbaar gebruik
van dergelijke tools. Als vuistregel geldt dat het gebruik van deze tools pas zinvol is, als
bepaalde testen meer dan tien keer dienen te worden uitgevoerd. Hierbij wordt ook
uitvoering bij toekomstige (onderhouds)testen meegeteld. Daarnaast geldt voor alle tools, en
met name voor Capture & Playback, dat ook deze tools onderhoud vereisen en dat er
derhalve regelmatig nieuwe versies verschijnen. Hierdoor kan conversie van de opgenomen
testruns noodzakelijk zijn.
4.2 Load & stress

Doel van dit soort tools is te testen of het systeem correct en snel genoeg blijft functioneren
bij zwaardere belasting. Met behulp van deze tools kan een applicatie belasten worden door
(grote aantallen) gebruikers te simuleren.
4.3 Debuggers en tracers

Debuggers en tracers vergemakkelijken het vinden van de oorzaak van een fout, wanneer
deze is opgetreden. Ze worden voornamelijk in het ontwikkeltraject gebruikt, maar kunnen
eventueel ook worden ingezet t.b.v. de test. Strikt genomen zijn debuggers en tracers geen
hulpmiddelen ten behoeve van testen.
4.4 Stubs en drivers

Een testdriver maakt het mogelijk om geautomatiseerd een aantal achtereenvolgende testen
uit te voeren. De testdriver verzorgt als het ware de aansturing van de test. In volgorde wordt
testinvoer aan het testobject aangeleverd en wordt de uitvoer óf opgeslagen voor latere
vergelijking óf door een comparator vergeleken met de verwachte uitvoer.
4.5 Simulator
Een simulator bootst de werking van de omgeving van het te testen (deel van het)
informatiesysteem na. Een simulator wordt gebruikt indien het onmogelijk of te kostbaar is
om de programmatuur in de werkelijke omgeving te testen. Bijvoorbeeld het testen van
besturingssoftware van een vliegtuig of het testen van een kerncentrale. De simulator levert
invoer aan het testobject, waarbij het testobject de betreffende invoer behandelt alsof het
echte invoer is. De uitvoer van het testobject wordt vervolgens afgevangen door de
simulator, voordat daadwerkelijk acties worden uitgevoerd. Een simulator kan worden gezien
als een speciaal soort testdriver die de omgeving van het testobject nabootst.

4.6 Testdata generator

Tools voor het bouwen van fysieke testsets of testbestanden noemt men testdata
generatoren. Er is een aantal methoden op basis waarvan testdata gegenereerd kunnen
worden:
• Op basis van random invulling. Gegevens worden willekeurig gevarieerd aan de hand
van een database- of bestandsspecificatie;
• Op basis van parameters. Met een standaard testgeval als uitgangspunt, kunnen
gegevens gegenereerd worden, door allerlei gegevens (parameters) te variëren;
• Op basis van extractie uit een bestaande (productie) database worden gegevens
gegenereerd.
Een bezwaar van het genereren van testgegevens kan zijn, dat niet altijd duidelijk wordt, wat
er getest wordt. Gegenereerde testgegevens kunnen echter goed worden gebruikt voor het
testen van de performance van een informatiesysteem.
4.7 Vergelijkers
Bij de beoordeling wordt het resultaat vergeleken met een verwachting. Dit kan gebeuren
met vergelijkers, ook wel comparators genaamd. Het gebruik van deze tools betekent wel dat
de verwachting eenduidig en volledig beschreven zal moeten worden. In de meeste gevallen
is dit meer werk dan het bij de beoordeling zal besparen. Vergelijkers zijn vaak een
onderdeel van Capture & playback tools, maar zelfs een tekstverwerker of zeer eenvoudige
file-compare utilities zijn hiervoor te gebruiken.
4.8 Querytalen
Niet altijd kan het resultaat van een test direct met standaardfuncties uit het
informatiesysteem gecontroleerd worden. Tools, die op een flexibele manier in de
gegevensverzameling kunnen kijken (SQL of soortgelijke talen), kunnen dan uitkomst
bieden. Bedacht dient te worden dat de intern opgeslagen gegevens niet volledig hoeven
aan te sluiten bij de beleving van een tester. Daarnaast is voor het gebruik van querytalen
opleiding onontbeerlijk.
4.9 Dekkingsgraad-analyse
In principe behoren alle onderdelen van een informatiesysteem te worden getest.
Dekkingsgraad-tools leveren informatie over de mate waarin door de uitgevoerde testen het
informatiesysteem is getest dan wel afgedekt. Deze tools meten hoe het testproces de
structuur van de programmatuur afdekt. In plaats van dekkingsgraad wordt ook vaak de
Engelse term coverage gebruikt.
4.10 Monitor
Om inzicht te krijgen in aspecten als geheugenbeslag, CPU-gebruik, netwerkbelasting en
performance kan tijdens het testproces gebruik worden gemaakt van monitoring tools.
Allerlei gegevens betreffende het gebruik van resources worden gemeten en opgeslagen.
Vaak zijn deze tools onderdeel van het besturingssysteem.
4.11 Statistieken
In het testtraject worden hoge eisen gesteld aan de rapportage en de daarin opgenomen
statistieken. Tools om statistieken te kunnen maken uit de ruwe gegevens kunnen zeer
arbeidsbesparend werken, bijvoorbeeld een spread-sheet programma.

Onderwerp Bijlage 4. Artikel eisen aan inzet testtools Datum 05-01-2000
Bijlage 4. Artikel eisen aan inzet testtools
Kwaliteit hét argument om testtools in te zetten

Gepubliceerd in de Computable 25-02-2000
Doelstellingen bij de inzet van testtools lang niet altijd gerealiseerd
De laatste tijd zijn er steeds meer organisaties die overgaan tot het implementeren van
een testtool. Hie rmee verwachten deze organisaties voordelen te behalen in termen
van (doorloop)tijd, geld of kwaliteit. Helaas worden deze doelstellingen lang niet altijd
gehaald. Een ervaren testconsultant en accountmanager van KZA Kwaliteitszorg B.V.
geeft inzicht in de succes- en faalfactoren met betrekking tot de inzet van testtools.
Bij veel organisaties ziet men het “automatiseren van het testen” als oplossing voor het
tijdrovende en dure testen. Vooral de zogenaamde record- en playbacktools, tools waarmee
je testgevallen kunt opnemen en later weer afspelen, hebben een hoge vlucht genomen.
De inzet van een record- en playbacktool kan voordelen met zich meebrengen. Niet in alle
gevallen leidt de inzet van testtools echter tot het gewenste resultaat. Dit artikel gaat in op de
eisen die gesteld worden aan de inzet van record- en playbacktools. Daarnaast wordt
ingegaan op de vraag wanneer welke voordelen te realiseren zijn.
Eisen aan de inzet van testtools.

Om de introductie van een testtool succesvol te laten zijn moet er, enkele uitzonderlijke
situaties daargelaten, aan vier eisen worden voldaan, te weten:
§ een gestructureerd en volwassen testproces;
§ een stabiel product;
§ het product dient lang mee te gaan;
§ de implementatie en organisatorische inbedding moeten goed geregeld zijn.
Deze eisen worden hieronder uitgewerkt.
Allereerst dient het testproces gestructureerd en volwassen te zijn. Hoewel sommige tool-
verkopers anders doen geloven blijft het handmatige deel van het testproces aanvankelijk
grotendeels overeind staan. Het creatieve proces dat daaraan vooraf gaat kan tot op heden
niet geautomatiseerd worden, het kan hoogstens gestructureerd gedocumenteerd worden.
Zo hebben we een keer meegemaakt dat bij een project vanaf dag 1 met onervaren testers
geautomatiseerd getest MOEST gaan worden. Dit heeft geleid tot een aantal willekeurige,
niet op elkaar aansluitende testgevallen. Er was echter geen inzicht in dekkingsgraad, er kon
geen enkele garantie worden gegeven over de werking van processen en de testset was niet
gebaseerd op een teststrategie. De gevolgen laten zich raden. In dit kader laat het
automatiserings-gezegde “het automatiseren van chaos leidt tot geautomatiseerde (of
snellere) chaos” zich gelden. Remedie: eerst het proces structureren, dan pas
automatiseren.
Een collega van mij gebruikt een simpele, maar zeer treffende vergelijking: je moet eerst
kunnen rekenen voordat je een rekenmachine kan gebruiken. Ditzelfde gaat op voor
testtools: je moet eerst (gestructureerd) kunnen testen voordat je testtools kan gebruiken.

Een andere belangrijke eis is dat het te testen product stabiel is. Met stabiliteit wordt in dit
kader bedoeld dat het product niet te veel (grote) wijzigingen meer ondergaat. Indien het
product of zijn omgeving namelijk vaak wijzigt zijn de opgenomen testgevallen niet meer
goed bruikbaar. Het gebruik van deze testgevallen leidt dan tot onbedoelde meldingen,
terwijl het bedoelde wijzigingen kan betreffen. Het afspelen van de testsets geeft
onvoldoende indicatie van de kwaliteit van het nieuwe product en het opnieuw opnemen van
de testgevallen kost wel weer tijd. Zo hebben wij bij een grote bank een advies gegeven een
testtool in te zetten. Het betrof een systeem voor thuis-bankieren. Bij in gebruikname van
een nieuwe versie was het niet alleen belangrijk vast te stellen of de wijzigingen goed waren
doorgevoerd. Het was minstens zo belangrijk vast te stellen of de ongewijzigde delen nog
goed functioneerden. De uitrol van de nieuwe versies was bijzonder kostbaar. Het pakket
moest naar de klanten worden opgestuurd, die dan in de korte tijd daarna veel meer gebruik
gingen maken van de (gratis) helpdesk dan in andere perioden. Bij eventuele fouten waren
de herstelkosten dus erg hoog. Vandaar het belang van een kwalitatief bijzonder goede
regressietest. Deze regressietest werd echter nog steeds handmatig, iedere keer door
andere testers, uitgevoerd. Zeker gezien de hoeveelheid testwerk was het risico van
menselijke fouten groot, hetgeen de kosten nog hoger maakte. Met de inzet van een record-
en playbacktool werd de situatie bereikt dat in relatief korte tijd met hoge mate van zekerheid
kon worden vastgesteld dat alle ongewijzigde functionaliteit nog correct werkte. Aan
genoemde voorwaarde, een stabiel product, werd in dit geval voldaan.
De derde eis die gesteld kan worden aan de inzet van een testtool is dat het dient te gaan
om een product dat lang mee moet gaan. Hierbij dient de verwachting te zijn dat er meerdere
(toekomstige) releases moeten zijn. Op de vraag in hoeveel releases een testtool zich
terugverdient wordt later ingegaan.
Achterliggende gedachte is dat het gebruik van een testtool aanvankelijk een extra
investering met zich meebrengt, zowel in tijd als in geld. Om de inzet van een testtool
verantwoord te maken dienen er dus meerdere hertests uitgevoerd te worden op een stabiel
product. Indien het gaat om een product dat relatief kort gebruikt gaat worden, is de kans
hierop bijzonder klein. Hoewel soms niet te voorzien is hoeveel nieuwe releases gemaakt
gaan worden, is het toch goed van tevoren bij deze vraag stil te staan. Bij één van de
projecten waar we bij betrokken waren, werden na een bewuste keuze testscripts
opgenomen in een testtool. Dit uitgangspunt gold voor alle programmatuur, dus ook van
conversieprogrammatuur. Voor eenmalig gebruikte programmatuur lijkt het niet mogelijk dat
de investering in een record- en playbacktool wordt terugverdiend omdat hergebruik van de
testscripts niet aan de orde is.
De laatste eis die in dit kader aan de inzet van een testtool wordt gesteld is dat
implementatie en organisatorische inbedding van groot belang is. Immers: een goed begin is
het halve werk. Het inzetten van een testtool is echter geen sinecure, diverse organisaties
hebben dit aan den lijve ondervonden. Ook het beheren en onderhouden vraagt het nodige
van een organisatie. De pakketten waar we het in deze over hebben zijn technisch vaak
redelijk complex. Zowel de installatie als het beheer vragen veel aandacht. Als dit in één keer
goed geregeld is, kan veel frustratie en dubbel werk worden voorkomen.
Daarnaast is het ook belangrijk dat de gebruikers opgeleid worden. Wat dat betreft verschilt
het implementeren van een testtool niet veel van de implementatie van een standaardpakket;
als de opleiding tekortschiet benutten de gebruikers niet alle mogelijkheden en zijn zij in
hoge mate afhankelijk van externe deskundigen. In dit kader dient ook de dienstverlening
geregeld te worden. Is er een interne vraagbaak? Wat gebeurt met vragen die niet direct
beantwoord kunnen worden? Hoe is de ondersteuning van de leverancier?
Ook communicatie is een belangrijk aandachtsgebied. Vooral het menselijke aspect van
automatisering van processen werd vroeger nogal eens uit het oog verloren. Voor de
implementatie van testtools gaat dit ook op. Duidelijkheid over de doelstellingen en
consequenties kan de acceptatie verhogen.

Vaak wordt een testtool bij een (pilot)project geïntroduceerd. Het kan zich in sommige
gevallen niet goed verhouden met de overige projectdoelstellingen. Een projectleider heeft
over het algemeen als primair doel een product op te leveren wat voldoet aan de
kwaliteitseisen binnen een bepaalde tijd en hoeveelheid budget. Het aantonen dat een
testtool meerwaarde heeft kan hiermee in strijd zijn. Het verdient derhalve aanbeveling de
introductie van een testtool ten laste van een extern budget plaats te laten vinden en het
project te compenseren voor de gemaakte kosten.
Aspecten die van belang zijn ten aanzien van de variabele kosten, tijd en
kwaliteit
Er zijn specifieke aspecten die bepalen of aan de eisen wordt voldaan. Deze aspecten
kunnen samenhangen. Een testtool wordt over het algemeen ingezet om de kosten te
verlagen, de doorlooptijd te beperken of de kwaliteit te verhogen dan wel te handhaven.
In eerste aanleg is met de inzet van een testtool een aanzienlijke investering gemoeid, zowel
in geld als in tijd. Hierbij moet niet alleen gedacht worden aan de aanschafkosten. Ook de
opleidingskosten en inleertijd kunnen aardig oplopen. Daarnaast kan er ook sprake zijn van
organisatorische kosten. Zo kan het nodig zijn het testproces aan te passen en moet het tool
beheerd worden. In sommige gevallen is het inhuren van externe expertise noodzakelijk.
Deze investering dient later terugverdiend te worden.
Een leverancier van testtools gaf desgevraagd aan dat het zeer twijfelachtig is of de
investering ooit wordt terugverdiend: “kosten mogen niet de overweging zijn om een testtool
in te zetten”.
In dit kader wordt met kwaliteit zowel de kwaliteit van de test in termen van dekkingsgraad,
als kwaliteit van het proces in termen van betrouwbaarheid, herhaalbaarheid en
traceerbaarheid bedoeld.
Om één van deze drie doelstellingen te kunnen bereiken is een aantal aspecten van belang.
Kennis en ervaring ten aanzien van testtools.

Naarmate er binnen de organisatie minder kennis en ervaring is ten aanzien van testtools en
de onderliggende programmeertaal, zijn de initiële kosten hoger. Hierbij moet niet alleen
gedacht worden aan opleiding, maar ook de inleertijd is langer. Ook dienen de medewerkers
programmeer kennis en ervaring te hebben om het tool optimaal te kunnen gebruiken,
beheren en onderhouden. Zelf hebben we bij de introductie van een testtool het
opleidingstraject doorlopen en leren werken met het betreffende tool. Het duurde inderdaad
geruime tijd, minimaal een half jaar, voordat we als team goed met het tool konden werken.
Aantal hertests
Het aantal hertests dat het systeem ondergaat is een belangrijk aspect in hoeverre een
testtool voordelen in termen van tijd en geld met zich meebrengt. Het aantal hertests is vaak
af te leiden uit het aantal (geplande) releases.
Op de vraag hoeveel hertests er nodig zijn om “positief” uit te komen hebben we hele
verschillende antwoorden gekregen. De eerste tool-leverancier zei dat na 1 iteratie de
investering terugverdiend is, enkele van mijn collega’s schatten tussen 3 en 7 testiteraties,
een opdrachtgever van KZA gaat uit van 20 hertests, een andere toolleverancier denkt aan
enkele tientallen iteraties. Zo heeft KZA meegewerkt aan een millenniumtest waar de
projectleider besloot een testtool in te zetten “om de testinspanning te beperken”. Er werd
een oudtest (ongewijzigde applicatie), nieuwtest (gewijzigde applicatie, getest op datum voor
de eeuwwisseling) en toekomsttest (gewijzigde applicatie, getest op datum na de
eeuwwisseling) uitgevoerd. Na afloop van het traject kwam men tot de conclusie dat het
testtool eerder een blok aan het been was geweest en dat het erg veel tijd had gekost. Het
aantal iteraties was te laag om de voordelen van het testtool te benutten.

Hoeveelheid testwerk
Indien er een groot aantal testgevallen moet worden uitgevoerd om een applicatie te testen
is een testtool eerder kostenneutraal of voordelig dan wanneer er af en toe eens wat
testwerk ligt. Indien er een grote hoeveelheid testdata moeten worden getest met hetzelfde
testscript is de inzet van een testtool mogelijk zelfs de enige oplossing. Bij het eerder
gegeven voorbeeld van het thuis-bankierpakket was er duidelijk sprake van een grote
hoeveelheden testwerk. Hierbij was het evident dat er een complete hertest moest worden
uitgevoerd als er een kleine wijziging werd doorgevoerd.
Herbruikbaarheid van de testscripts

Hoewel dit een open deur is, hebben we een keer waargenomen dat hier geen rekening mee
werd gehouden. Bij een millenniumtraject werd voor alle applicaties gebruik gemaakt van het
testtool. Er waren echter ook specifieke datum-tests die na de millenniumovergang niet meer
gebruikt zouden gaan worden. Ook deze testgevallen werden opgenomen.
Doorlooptijd project
Vaak wordt in projectmatig verband overwogen testtools in te zetten. Doordat er bij projecten
vaak weinig iteraties gemaakt wordt op hetzelfde product, is het dus vaak voor projecten
duurder om te werken met een testtool dan zonder. De eventuele voordelen in termen van
tijd kunnen pas worden geëffectueerd in de onderhoudsfase. Het is van groot belang dat de
kennis, kunde en de producten, inclusief documentatie, goed worden overgedragen aan de
lijn wanneer het project beëindigd wordt. De lijnorganisatie kan dan optimaal gebruik maken
van het verzette werk en daarmee de opgedane ervaring en de voordelen benutten. Helaas
zien we maar al te vaak dat aan het einde van een project ook diverse bruikbare zaken niet
overgedragen, dan wel niet geaccepteerd worden. Bij eerder genoemd millenniumtraject
waar gebruik werd gemaakt van testtools gebeurde dit ook. Één van de argumenten van de
lijnorganisatie was dat er geen geld was voor opleiding van de lijnfunctionarissen. De
geautomatiseerde scripts staan op dit moment op een fileserver te verouderen.
Beleid ten aanzien van regressietests

Worden bij nieuwe releases alle onderdelen volledig doorgetest of alleen die delen die
aangepast zijn? Dit soort vragen zijn van belang bij de overweging wel of niet een testtool in
te zetten.
Bij één van de grootste softwarehuizen van Nederland heeft men als beleid ten aanzien van
nieuwe releases dat de nacht voor de geplande uitlevering alle schermen automatisch
geopend worden en weer afgesloten. Op deze manier weet men zeker dat alle onderdelen
op de tape staan; volledigheid is gedekt. Om ook de juiste werking van het pakket integraal
te testen zou een veelvoud van die tijd nodig zijn. Om marketing-technische redenen kiest
men ervoor dit niet te doen.
Gewenste dekkingsgraad
Een ander aspect dat met de gewenste kwaliteit samenhangt is de vraag welke
dekkingsgraad gewenst is. Is men met een lage dekkingsgraad tevreden, dan is een testtool
niet altijd aan te bevelen omdat men dan vaak kan volstaan met een beperkt aantal
testgevallen. Zeer hoge dekkinggraden zijn vaak alleen haalbaar als er zeer veel
testgevallen zijn. De complexiteit van systemen kan in sommige gevallen zo hoog zijn in
termen van variaties en links, dat het gebruik van een testtool de enige mogelijkheid is een
hoge dekkingsgraad, en daarmee een kwalitatief goede test, mogelijk te maken.
Conclusie

Uit het voorgaande kunnen we afleiden dat het moeilijk kan zijn om in termen van kosten en
tijd voordelen te behalen door middel van de inzet van testtools. Een lange adem en goede
organisatie zijn van groot belang. Daarom is kwaliteit hét argument om testtools in te zetten.
Indien er een situatie bereikt is dat de scripts er liggen, het testproces goed beheerst wordt
en het onderliggende systeem stabiel is, is het mogelijk snel en foutloos tests te herhalen.
Zoals we in het voorbeeld van het thuisbankier-pakket hebben gezien, was het eenvoudig
om de hele applicatie integraal door te testen. Ander voordeel in die situatie was dat de
geautomatiseerde test foutloos werd uitgevoerd. Handmatig werk is nu eenmaal onderhevig
aan fouten. Geautomatiseerd testen kan de betrouwbaarheid en reproduceerbaarheid van de
test aanzienlijk verbeteren.
Aanpak
Het is van belang dat men, voorafgaande aan de selectie en implementatie van een testtool,
zich bezint welke doelstellingen men heeft. Vervolgens dient de organisatie, eventueel met
hulp van een deskundige onafhankelijke partij, te onderzoeken of de doelstellingen
realiseerbaar zijn. De aspecten die in dit artikel staan kunnen hier handvatten voor bieden.
Daarnaast dient vastgesteld te worden in hoeverre aan de eisen voldaan wordt. Door vooraf
te analyseren of de organisatie klaar is voor een testtool en of alle randvoorwaarden zijn
ingevuld kunnen teleurstellingen worden voorkomen. Vervolgens kan, eventueel nadat
risico’s zijn aangegeven, een onderbouwde beslissing worden genomen.
Er is geen standaard antwoord mogelijk. De materie is dermate complex dat het maken van
een eenvoudige beslissingsboom met een simpel ja of nee niet mogelijk is. Het formuleren
van haalbare doelstellingen en het maken van een zorgvuldige afweging na grondig
onderzoek is het belangrijkste.
Jan Jaap Cannegieter

Onderwerp Bijlage 5. Checklists Datum 07-05-2003
Bijlage 5. Checklists
SYSQA beschikt over de volgende checklists:
• Beheerbaarheid
• Beveiliging
• Black-box test
• Connectiviteit
• Continuïteit
• Controleerbaarheid
• Evaluatie testproject
• Flexibiliteit
• Gebruikersvriendelijkheid
• Geschiktheid infrastructuur
• Globale bestudering informatiesysteem
• Handboek testen
• Herbruikbaarheid
• Mastertestplan
• Metrics ten behoeve van testproces
• Metrics testobject
• Onderhoudbaarheid
• Portabiliteit
• Procedurebeschrijvingen
• Randvoorwaarden en uitgangspunten
• Rapport detailintake
• Risico’s testproject
• Risicorapportage
• Sjablonen en modellen
• Structurering
• Testaspecten projectplan
• Testbaarheid
• Testdossier
• Testdraaiboek
• Testfaciliteiten
• Testplan
• Testscripts
• Testspecificatie
• Testspecificatietechnieken
• Voortgangsrapportage
• Vrijgave productie
• White-box test
Niet alle checklists zijn opgenomen in het handboek. Alleen de checklists testdraaiboek,
testspecificatie, testscripts en testspecificatietechnieken zijn hierin opgenomen. De overige
checklists kunt u opvragen via het secretariaat.

Testdraaiboek
• Zijn in het draaiboek verwijzingen naar testscripts opgenomen
• Is aangegeven wanneer, welke tester, welk testscript uit gaat voeren
• Zijn eventuele verbanden tussen testscripts aangegeven
• Is een overall-planning van de tests opgenomen
• Is per testscript aangegeven welke infrastructurele hulpmiddelen en welke databases
benodigd zijn
• Is de prioriteit van de verschillen testscripts weergegeven
• Voldoet het draaiboek voor wat betreft uiterlijk aan de standaards en sjablonen uit het
handboek
• Is per testscript aangegeven op welk systeem(onderdeel) de specificatie betrekking heeft
• Is het testdraaiboek overzichtelijk
• Kan de status van de testuitvoering per testscript worden bijgehouden

Testplan
• Is de opdrachtformulering beschreven
• Is een afbakening van het te testen object opgenomen, inclusief onderverdeling in
deelsystemen en koppelingen
• Is het doel van de test beschreven
• Zijn uitgangspunten en randvoorwaarden beschreven
• Is de testbasis beschreven
• Is de teststrategie beschreven
• Bevat de teststrategie systeemeisen
• Bevat de teststrategie acceptatiecriteria
• Bevat de teststrategie testtechnieken
• Zijn risico’s en maatregelen beschreven
• Is de organisatie inclusief testfuncties, organisatiestructuur en personele invulling
beschreven
• Zijn taken, verantwoordelijkheden en bevoegdheden van de betrokken personen
beschreven
• Zijn eisen die gesteld worden aan testers beschreven
• Zijn overlegstructuren beschreven
• Zijn mijlpalen beschreven
• Zijn mijlpaalproducten beschreven
• Is de testinfrastructuur beschreven
• Is opgenomen of testtools gebruikt gaan worden
• Is het beheer van het testproces beschreven
• Is het beheer van de infrastructuur beschreven
• Is het beheer van de testproducten beschreven
• Zijn de uit te voeren activiteiten opgenomen
• Is de tijds- en capaciteitsplanning opgenomen
• Zijn de rapportagevormen beschreven
• Zijn raakvlakken met andere projecten beschreven
• Zijn de afhankelijkheden met andere projecten, testteams en projectteams beschreven
• Is versiebeheer ingericht voor het testplan
• Is het testplan conform het sjabloon gemaakt

Testscripts
• Voldoen de testscripts voor wat betreft het uiterlijk aan de standaards en sjablonen uit het
handboek
• Is bij het testscript aangegeven op welk systeem(onderdeel) de specificatie betrekking
heeft
• Zijn precondities aangegeven
• Zijn postcondities aangegeven
• Zijn testgevallen uniek genummerd
• Zijn de scripts overdraagbaar en onderhoudbaar
• Is de referentie naar het testplan opgenomen
• Is aangegeven wat het testobject is
• Zijn de acties en controles éénduidig (op maar één manier uit te leggen)
• Is het document toegankelijk (inhoudsopgaves, kopjes en dergelijke)
• Is het mogelijk de uitkomsten van de tests aan te geven
• Zijn acties en controles duidelijk aangegeven en te onderscheiden
• Kunnen vanuit het testscript verwijzingen worden gemaakt naar bevindingen
• Kan worden aangegeven bij welke testronde de scripts zijn uitgevoerd
• Kan worden aangegeven op welke versie van de programmatuur de testscripts betrekking
hebben

Testspecificatie
• Is aangegeven wat de testbasis is, inclusief versienummer en datum
• Zijn de testsituaties opgenomen
• Zijn de logische testgevallen opgenomen
• Zijn de fysieke testgevallen opgenomen
• Zijn de testacties en controles benoemd
• Is de initiële gegevensverzameling opgenomen inclusief locatie
• Is het testscript opgenomen of een verwijzing naar de locatie van de testscripts opgenomen
• Voldoen de testspecificaties voor wat betreft uiterlijk aan de standaards en sjablonen uit het
handboek
• Is bij de testspecificatie aangegeven op welk systeem(onderdeel) de specificatie betrekking
heeft
• Is, daar waar mogelijk, gebruik gemaakt van tekeningen of tabellen om de analyse te
vereenvoudigen
• Bevinden zich geen technische termen in de specificaties
• Zijn de specificaties overdraagbaar en onderhoudbaar
• Is de referentie naar het testplan opgenomen
• Is een dekkingsmatrix opgenomen
• Is aangegeven wat het testobject is
• Zijn de specificaties éénduidig (op maar één manier uit te leggen)
• Is aangegeven onder welke voorwaarden aan de test kan worden begonnen
• Is het document toegankelijk (inhoudsopgaves, kopjes en dergelijke)
• Is de afhankelijkheid van andere testspecificaties aangegeven

Testspecificatietechnieken
Algoritmetest
Bij een algoritmetest wordt de structuur van een algoritme getest. De gewenste testbasis is een
stroomschema, beslissingstabel of een Nassi-Shneiderman diagram aangevuld met een
beschrijving. De volgende checklist kan worden gehanteerd bij het controleren van de
documentatie:
• Zijn de (programma)algoritmen beschreven in vorm van een stroomschema, beslissingstabel of
Nassi-Shneiderman diagram?
• Is de “trigger” duidelijk aangegeven? (Met andere woorden: wanneer moet het algoritme
worden opgestart?)
• Is aangegeven welke gegevens worden gebruikt en uit welke bron deze komen?
• Is het resultaat van het algoritme duidelijk?
• Zijn de diverse beslispunten eenduidig en volledig beschreven met de daatbij behorende
condities?
Beslissingstabellentest
Met behulp van de beslissingstabelllentest wordt op een uiterst formele wijze de verwerking van
een programma of functie getest. Deze testspecificatietechniek stelt zeer hoge eisen aan de
kwaliteit van de testbasis. Bij het toepassen van deze techniek dient derhalve ruim aandacht te
worden geschonken aan de detail intake testbasis. Bij de detail intake testbasis kan de volgende
checklist worden gehanteerd voor het controleren van de aanwezige ontwerpspecificaties:
• Zijn de “triggers” van het proces duidelijk aangegeven (het gaat hierbij zowel om “triggers”
vanuit de gebruiker, een extern systeem of een interne functie c.q. programma)?
• Is de verwerking zodanig beschreven dat hierin de diverse “verwerkingspaden” zijn te
onderkennen?
• Zijn de determinanten (factoren) die het proces beïnvloeden duidelijk te onderkennen en
eenduidig beschreven?
• Is de uitvoer van het proces duidelijk en is het mogelijk resultaten van te voren te voorspellen?
Dataflowtest
Aangezien de dataflowtest een minder formele methode is, stelt deze methode ook minder
stringente eisen aan de testbasis. Bij de detail intake testbasis kan de volgende checklist worden
gehanteerd bij het controleren van de aanwezige specificaties:
• Zijn de diverse scherm –en printlay-outs beschreven?
• Is de verwerking van de functies eenduidig beschreven inclusief beslispaden?
• Is de samenhang tussen de diverse functies beschreven?
• Is een dialoogontwerp (schermverloopschema’s e.d.) aanwezig?
Elementaire vergelijkingentest
Het gaat bij de elementaire vergelijkingentest om de beschrijving van de (logische) verwerking van
gegevens. Bij de beschrijving van de verwerking kan bijvoorbeeld gebruik zijn gemaakt van
pseudo-code en/of beslissingstabellen. Met betrekking tot de elementaire vergelijkingentest kan bij
de detail intake testbasis de volgende checklist worden gehanteerd bij het controleren van de
aanwezige specificaties:
• Is de verwerking zodanig beschreven dat hierin de diverse “verwerkingspaden” zijn te
onderkennen?
• Is duidelijk onder welke condities (voorwaarden) een bepaald “verwerkingspad” wordt
doorlopen?
• Is de verwerking eenduidig beschreven inclusief invoer en uitvoer?

• Is voor alle ingevoerde rubrieken de verwerking beschreven?
Error Guessing
Een specifieke beoordeling op bepaalde aspecten van de documentatie is niet noodzakelijk voor
het kunnen uitvoeren van de Error Guessing test. Van belang is dat men op basis van de
documentatie een goed begrip kan krijgen van het te testen (sub)systeem. Dit inzicht kan
overigens ook worden bereikt door het uitvoeren van gestructureerd tests in samenhang met Error
Guessing.
Gegevenscyclustest
De gegevenscyclustest richt zich op de levensloop van gegevens. Een essentieel onderdeel van
de testbasis wordt dan ook gevormd door de CRUD-matrix. Indien deze niet aanwezig is, moet
deze worden opgesteld zodat de testspecificatie in het kader van de gegevenscyclustest kan
worden uitgevoerd. De volgende checklist kan worden gehanteerd bij het controleren van de
testbasis voor de gegevenscyclustest:
• Is er in de documentatie een CRUD-matrix aanwezig?
• Is het duidelijk in welke functie(s) een entiteit kan worden ingevoerd, geraadpleegd gewijzigd
en verwijderd?
• Kan elke entiteit worden ingevoerd, gewijzigd en verwijderd?
• Is er een beschrijving van de entiteiten aanwezig?
• Is er een entiteitenschema (Entity Relation Diagram, ERD) aanwezig?
• Zijn de relaties tussen de diverse entiteiten volledig en eenduidig beschreven?
• Zijn bij de relaties ook de referentiële relatiecontroles beschreven?
Programma interfacetest
De programma interfacetest richt zich op de interactie tussen twee programma’s c.q. modules. Als
uitgangspunt geldt dat de te integreren programma’s los van elkaar goed functioneren. Bij een
programma interfacetest worden de gesimuleerde gegevensstromen vervangen door echte
gegevensstromen. De volgende controles kunnen worden uitgevoerd op de testbasis in het kader
van deze testspecificatietechniek:
• Is de verwerking van de individuele programma’s eenduidig beschreven, inclusief invoer en
uitvoer?
• Is aangegeven waar interfaces aanwezig zijn?
• Is de samenhang tussen de diverse programma’s beschreven?
• Is voor alle ingevoerde rubrieken de verwerking beschreven?
• Is van alle bij de interfaces betrokken entiteiten aangegeven welke attributen ertoe behoren?
• Zijn van de attributen de objectklasse, de definitie (range, toegestane waarden) en eventuele
bijzondere geldigheidsregels beschreven?
Procescyclustest (inpasbaarheid)
De testbasis voor de procescyclustest bestaat veelal uit procedurebeschrijvingen en bijbehorende
formulieren. Bij voorkeur zijn bij de procedurebeschrijvingen zogenaamde flowcharts toegevoegd.
Bij de detail intake testbasis kan de volgende checklist worden gehanteerd bij het controleren van
de aanwezige procedurebeschrijvingen:
• Zijn alle handmatige procedures, die door gebruikers gevolgd dienen te worden om tot een
goed gebruik van het systeem te komen, weergeven in een procedureschema?
• Is een gedetailleerde beschrijving gemaakt van de handmatige procedures?
• Zijn de belangrijkste taakomschrijvingen beschreven, inclusief de verantwoordelijkheden en
bevoegdheden?
• Is een beschrijving gegeven van de individuele taken?
• Zijn de beveiligingsaspecten van deze procedure beschreven?

• Is de “trigger” duidelijk aangegeven? (Met andere woorden: wanneer moet de procedure

worden opgestart.)
• Is aangegeven welke gegevens (formulieren) moeten worden gebruikt en uit welke bron deze
komen?
• Zijn de uit te voeren handelingen volledig beschreven inclusief uitzonderingen en controles?
• Is het resultaat van de procedure duidelijk?
• Zijn de diverse beslispunten beschreven met de daarbij behorende condities?
• Is een onderscheid gemaakt tussen gebruikers –en beheerprocedures?
• Zijn de relaties tussen het geautomatiseerde en het niet-geautomatiseerde deel van het
informatiesysteem beschreven?
• Is de gebruikershandleiding beschikbaar?
Real-life test (o.a. performance en zuinigheid)

Alle documentatie met betrekking tot het operationeel gebruik van het systeem wordt verzameld,
onder andere de tijdens de diverse systeemontwikkelingsfasen gespecificeerde systeemeisen. Met
betrekking tot de real-life test dient bij de detail intake testbasis te worden beoordeeld of de
aanwezige systeemdocumentatie in voldoende mate inzicht geeft in het toekomstige
systeemgebruik. Hiervoor zijn onder andere van belang het aantal gebruikers, de intensiteit van
gebruik en de dag-, week- en maandcycli. De volgende vragen kunnen expliciet onderdeel zijn van
de intake in het kader van real-life test:
• Is de verwachte frequentie van gebruik op functieniveau beschreven?
• Is voor elk type gebruiker beschreven welke functies uitgevoerd mogelijk worden?
• Is per functie beschreven wanneer deze gebruikt wordt (dagelijks, wekelijks, jaarlijks, overdag,
’s avonds)?
• Is er inzicht in de samenhang tussen de verschillende batch-procedures over de
(deel)systemen heen?
• Is de configuratie voor de productieomgeving beschreven (hardware, netwerk,
systeemsoftware, DBMS, enzovoort)?
• Zijn er specifieke eisen vastgelegd ten aanzien van de performance van on-line functionaliteit?
• Wordt er een onderscheid gemaakt tussen de responsetijd bij het opstarten van een functie en
bij schermwisseling binnen een functie?
• Zijn er specifieke eisen vastgesteld ten aanzien van de performance van
gegevensbenadering?
• Zijn er specifieke eisen vastgesteld ten aanzien van de performance van batch functionaliteit?
• Zijn er specifieke eisen vastgesteld aan het geheugenbeslag?
• Zijn er normen van toepassing ten aanzien van het aantal database-call’s per transactie?
• Zijn er normen van toepassing ten aanzien van maximale pagina –en buffergrootte?
• Zijn specifieke eisen aan de omvang van applicatie en/of de database?
Semantische test (o.a. beveiliging)

Het gaat bij de semantische test met name om documentatie waarin invoercontroles op
functieniveau, standaards ten aanzien van foutafhandeling op (sub)systeemniveau en eisen ten
aanzien van de toegangsbeveiliging voor functies en/of gegevens zijn beschreven. Bij de detail
intake testbasis kan de volgende checklist worden gehanteerd bij het controleren van de
aanwezige specificaties:
• Zijn er standaards met betrekking tot foutafhandeling beschreven op (sub)systeemniveau?
• Zijn de invoercontroles (met name de relatiecontroles) inclusief bijbehorende foutboodschap
beschreven als onderdeel van de functiebeschrijving en zijn deze uitvoerbaar?
• Zijn er specifieke eisen vastgelegd voor toegangsbeveiliging van functies en/of gegevens?
• Zijn er gebruikersprofielen beschreven met betrekking tot beveiliging?

• Is beschreven welke eisen gesteld worden aan identificatie (user-id) en authenticatie

(wachtwoord)?
Syntactische test
Tijdens de detail intake testbasis wordt de documentatie geselecteerd en beoordeeld die nodig is
om de syntactische test ten aanzien van het systeem uit te kunnen voeren. Het gaat hierbij om
schermlay-outs, schermbeschrijvingen, overzichtlay-outs, overzichtbeschrijvingen, aanwezige
standaards op (sub)systeemniveau en het gegevensmodel. Voor de syntactische test kan bij de
detail intake testbasis de volgende checklist worden gehanteerd:
• Zijn er van toepassing zijnde standaards beschreven op systeemniveau?
• Zijn er van toepassing zijnde standaards beschreven op subsystemenniveau?
• Zijn de lay-outs van de schermen beschreven?
• Is hierbij aandacht gegeven aan de volgende aspecten:
- Veldlengte van de rubrieken op het scherm;
- Plaats van de rubriek op het scherm;
- Onderscheid invoer en uitvoer rubrieken;
- Primaire invoercontroles (niet het gevolg van domein definitie);
- Foutafhandeling;
- Verplichte en niet-verplichte rubrieken;
- Mogelijke functietoetsen, helpschermen en selecties.
• Zijn de “schermrubrieken” c.q. attributen opgenomen in het gegevensmodel?
• Zijn van de gebruikte attributen de definities (numeriek, alfanumeriek, datum) en de domeinen
beschreven?
• Zijn de gespecificeerde verplichte en niet-verplichte rubrieken consistent met de optionaliteit uit
het gegevensmodel?
• Voldoen de beschreven schermlay-outs aan de standaards?
• Zijn de lay-outs van de overzichten beschreven?
• Is hierbij aandacht gegeven aan de volgende aspecten:
- Veldlengte van de rubrieken;
- Plaats van de rubriek op het overzicht?
• Zijn de “overzichtrubrieken” c.q. attributen opgenomen in het gegevensmodel?

Onderwerp Bijlage 6. Sjabloon testplan Datum 05-01-2000
Handboek testen
Bijlage 6. Sjabloon testplan
SYSQA B.V. Almere
Manager
Akkoord:
Datum:
Status: Datum:
Opgesteld door: Naam auteur

Inhoudsopgave
1. INLEIDING................................................................................................................................ 148
1.1 ALGEMEEN .......................................................................................................................... 148
1.2 VERSIEBEHEER ................................................................................................................... 148
2. OPDRACHTFORMULERING .................................................................................................. 149
2.1 OPDRACHTOMSCHRIJVING................................................................................................... 149
2.2 OPDRACHTGEVER ............................................................................................................... 149
2.3 OPDRACHTNEMER............................................................................................................... 149
2.4 DOELSTELLING.................................................................................................................... 149
2.5 RISICO’S EN MAATREGELEN TER BEHEERSING VAN DE RISICO’S ........................................... 149
2.6 RANDVOORWAARDEN EN UITGANGSPUNTEN ........................................................................ 149
2.7 TESTBASIS .......................................................................................................................... 149
3. TESTSTRATEGIE.................................................................................................................... 151
3.1 KWALITEITSATTRIBUTEN EN ACCEPTATIECRITERIA ............................................................... 151
3.2 TESTTECHNIEKEN ............................................................................................................... 151
3.3 TESTBEGROTING ................................................................................................................. 151
4. TESTAANPAK ...................................................................................................................... 152
5. INFRASTRUCTUUR............................................................................................................. 154
6. COMMUNICATIE.................................................................................................................. 155
6.1 TESTBEOORDELING............................................................................................................. 155
6.2 VOORTGANGSRAPPORTAGE ................................................................................................ 155
6.3 VRIJGAVEADVIES EN EINDRAPPORTAGE ............................................................................... 155
7. ORGANISATIE EN PLANNING........................................................................................... 157
7.1 TESTORGANISATIE .............................................................................................................. 157
7.2 PLANNING ........................................................................................................................... 157

1. Inleiding
1.1 Algemeen
Er wordt een korte algemene inleiding gegeven over de organisatie, het project en de opdracht.
1.2 Versiebeheer
1.3 Verzendlijst
Dit document wordt ter beschikking gesteld aan:
• [naam en functie]

2. Opdrachtformulering
2.1 Opdrachtomschrijving
Formele en nauwkeurige omschrijving van de opdracht.
Voor het project is de volgende testopdracht opgesteld:
SYSQA BV,hierna te noemen SYSQA, voert in opdracht van het …., hierna te noemen het … de
acceptatietest van het uit ….. (Deze formulering wordt alleen gehanteerd als SYSQA resultaat
verantwoordelijkheid draagt.)
Een onderdeel van de opdrachtomschrijving is de afbakening; wat hoort wel en wat hoort niet tot
de opdracht.
2.2 Opdrachtgever
Organisatie,
Project,
Vertegenwoordigd door naam contactpersoon.
2.3 Opdrachtnemer
Organisatie,
Project,
Vertegenwoordigd door naam contactpersoon.
De naam van SYSQA wordt alleen genoemd als het gaat om een opdracht waar SYSQA resultaat
verantwoordelijk is.
2.4 Doelstelling
De doelstelling van het testtraject wordt hier omschreven. Deze worden opgesteld in samenspraak
met de opdrachtgever. Eventueel wordt de doelstelling beschreven in kwaliteitsattributen.
2.5 Risico’s en maatregelen ter beheersing van de risico’s

Naar aanleiding van een voorlopige studie worden hierin risico’s gedurende het traject vermeld.
Per risico worden eventuele maatregelen ter beheersing van het risico opgenomen
Men kan hier denken: consitentie testbasis (geleverde documentatie), kennis en vaardigheden
van medewerkers in het project, tijdsplanning, etc.
2.6 Randvoorwaarden en uitgangspunten

Om het testtraject tot een succes te laten verlopen bestaan een aantal randvoorwaarden en
uitgangspunten waar aan voldaan dient te worden.
Bijvoorbeeld:
- Producten (testplan, testvoorbereiding, uitvoering, database en eindrapportage);
- Faciliteiten (aparte testruimte, werkplekken, autorisatie, het inrichten van een testomgeving);
- Versiebeheer (release procedures);
- Beschikbaarheid medewerkers;
- Beschikbaarheid ontwikkelteam.
Randvoorwaarden zijn voorwaarden die het testproject oplegt aan haar omgeving, uitgangspunten
zijn voorwaarden die de omgeving oplegt aan het testproject.
2.7 Testbasis
De testbasis is het referentiekader voor het te testen object. Hier wordt specifiek geformuleerd
welk referentiekader gedurende het plan geldig is.

De testbasis is een opsomming van documenten die de basis vormen waarmee het testontwerp en
de testsituaties en testgevallen worden gecreëerd. De documenten van de testbasis worden
geïdentificeerd op basis van versienummer en datum.

3. Teststrategie
3.1 Kwaliteitsattributen en acceptatiecriteria

In de doelstelling (2.4) van het testplan is verwoord, welke kwaliteitsattributen worden
meegenomen. Detailleer en geef per kwaliteitsattribuut een omschrijving over de diepgang. Per
kwaliteitsattribuut worden de bijbehorende acceptatiecriteria opgenomen.
3.2 Testtechnieken
Benoem hier de gebruikte testtechnieken en omschrijf de techniek.
3.3 Testbegroting en kosten

Specificeer welke testeenheid met welke techniek wordt getest en hoeveel tijd hiervoor begroot
wordt. Dit overzicht wordt aangevuld met de verwachte kosten per testeenheid en totaaltellingen
van inspanning en kosten.

4. Testaanpak
[Hieronder staat de SYSQA standaard, indien de klant een eigen standaard heeft dient deze
gevolgd te worden.]
Teneinde deze testopdracht naar voldoening van [opdrachtgever] te kunnen uitvoeren, wordt
tewerk gegaan conform het volgende faseringsmodel:
Testplan
Testuitvoering
Testafronding
Testvoorbereiding
De in het faseringsmodel genoemde fasen en bijbehorende activiteiten worden hierna volgend

toegelicht.
Fase 1. Testplan
Het opstellen van het plan van aanpak, het uiteindelijke testplan, wordt op basis van de
opdrachtformulering als eerste activiteit na de opdrachtverstrekking uitgevoerd in de fase Testplan.
Het testplan, waarin in detail wordt aangegeven hoe deze opdracht wordt uitgevoerd, dient na
goedkeuring door [opdrachtgever] als uitgangspunt voor de verder te verrichten werkzaamheden.
Een van de mijlpalen producten van deze fase is het testplan voor het project. Het beheer
(voortgangsbewaking) loopt gedurende het gehele project door.
Fase 2. Testvoorbereiding
In de fase testvoorbereiding wordt een tweetal activiteiten uitgevoerd, te weten:
Detail-intake;
De testspecificatie
De eerste activiteit welke wordt gedaan in de voorbereiding is de detail-intake. Het doel van de
detail-intake is het beoordelen van de testbaarheid van de testbasis. Met de testbaarheid wordt
hier de volledigheid en consistentie van de documentatie (de testbasis) bedoeld, zover die
benodigd is voor het voorbereiden en uitvoeren van de tests. In hoofdstuk 2.7 is de testbasis voor
[opdrachtgever] nader gedefinieerd.
In deze fase worden eveneens per testeenheid testspecificaties, testscripts en steekproeven

gespecificeerd met behulp van in de teststrategie bepaalde testtechnieken. Deze testgevallen
worden primair gebaseerd op de functionele specificaties van [naam programmatuur].
In het testdraaiboek worden de testscripts, testbestanden en steekproeven zodanig samengesteld

dat de verschillende tests een minimale onderlinge afhankelijkheid hebben en dat het draaiboek
helder en eenduidig door acceptatietesters kan worden uitgevoerd. Hergebruik van de ontwikkelde
testware bij nieuwe releases van [naam programmatuur] wordt hierdoor gemakkelijk gemaakt.
Parallel hieraan wordt de algemene beschrijving van de testinfrastructuur uit het testplan verder in
detail uitgewerkt opdat in de volgende fase direct met testen kan worden begonnen.

De in de vorige activiteiten ontwikkelde testware (testplan, -specificaties, -scripts, -bestanden en

testdraaiboeken) wordt conform de in het testplan genoemde rapportagestructuur en planning ter
afstemming aangeboden aan de [naam projectleid(st)er].
Fase 3. Testuitvoering
Na alle voorgaande activiteiten volgt nu de uitvoering van de acceptatietest bestaande uit
testgevallen en steekproeven. Deze worden conform het draaiboek uitgevoerd. Naast het uitvoeren
van de testcases worden de resultaten van de testen geanalyseerd en de verschillen worden
vastgelegd in rapportages en gemeld aan de [naam opdrachtgever].
Besprekingen met de bouwer van [naam programmatuur] over de gevonden resultaten worden
uitgevoerd door middel van een projectvergadering. Indien nodig vindt na oplevering van
verbeterde programmatuur een hertest plaats.
Fase 4. Testafronding
Na uitvoering van de voorgenomen tests en nadat het [naam opdrachtgever] in staat is gesteld om
tot een vrijgavebeslissing te komen op basis van de (eind)rapportage(s) en advies van de
testcoördinator, wordt het testproject afgerond.
Met behulp van de opgeleverde testware kunnen, gepaard gaande met kennis van het systeem en
kennis overdracht, de relevante tests door derden worden herhaald.
De resultaten van de procesevaluatie kunnen worden gebruikt bij het aanscherpen van de in
ontwikkeling zijnde [naam opdrachtgever]methodiek.

5. Infrastructuur
In dit hoofdstuk wordt beschreven welke faciliteiten het testteam nodig heeft om de test uit te
kunnen voeren. Hierbij dient gedacht te worden aan:
- Testomgeving;
- Initiële gegevensverzameling;
- Testtools;
- Kantoorinrichting.
Er wordt ook aangegeven wie verantwoordelijk is voor het tot stand brengen en onderhouden van
de infrastructuur.

6. Communicatie
6.1 Testbeoordeling
[Hieronder vindt u een voorbeeld]
De resultaten van het testtraject worden vastgelegd in de testrapportages. Afwijkingen in de
respons van het systeem ten opzichte van de verwachting wordt vastgelegd in een bevindingen-
rapport. In het bevindingen-rapport wordt onder meer de urgentie vastgelegd.
Om deze urgentie per bevinding te kunnen prioriteren is een verdeling gemaakt namelijk:
1) Blokkerende bevinding (= testwerkzaamheden kunnen niet worden gecontinueerd,b
bijvoorbeeld de database functioneert niet naar behoren)
Ernstige bevinding (= testwerkzaamheden kunnen worden gecontinueerd maar bevinding
leidt tot vertraging in het testproces, bijvoorbeeld een deel is
specificatie)
2) Kleine bevinding (= testwerkzaamheden kunnen worden gecontinueerd zonder
vertraging)
Per bevinding wordt een duidelijke omschrijving van de afwijking gegeven. Hierin wordt gemeld
in welke situatie de fout optreedt, wat de fout exact is en wat de verwachte respons van het
systeem is.
Bevindingen kunnen van allerlei aard zijn en kunnen betrekking hebben op:
1) de testbasis;
2) het testobject (verschillen tussen specificaties en testresultaten);
3) de testomgeving (netwerkstoringen, computerstoringen, verkeerde versie software staat klaar,
databestanden kloppen niet );
4) de testspecificaties zelf (de eigen testgevallen zijn niet correct).
De bevindingen worden naar aanleiding van hun urgentie regelmatig gerapporteerd aan de
projectleider van het [naam] project.
6.2 Voortgangsrapportage
[Hieronder een voorbeeld]
Twee wekelijks wordt de voortgang van het testtraject gerapporteerd middels een
voortgangsrapportage. In deze rapportage wordt onder meer de verrichte activiteiten van het
testteam beschreven. Bovendien wordt een planning van activiteiten van de komende periode
gemaakt en eventuele risico’s voor het testtraject worden in de rapportage opgenomen. De
rapportage vindt plaats aan de projectleider van het [naam] project.
Indien in tussenliggende periodes zich zaken voordoen, waardoor de voortgang van het project
wordt bedreigd, wordt met de testcoördinator afgestemd welke maatregelen worden genomen om
vertraging te voorkomen c.q. tot het minimum te beperken.
6.3 Vrijgaveadvies en eindrapportage

[Hieronder vindt u een voorbeeld]
Aan het eind van het testtraject wordt een vrijgaveadvies opgesteld waarin de resultaten van het
testtraject worden beschreven. In het vrijgaveadvies is een advies over het al dan niet in productie
nemen van de applicatie opgenomen. Dit advies wordt onderbouwd met een overzicht van de
openstaande bevindingen en weergave van het testtraject. De risico’s van een eventuele
implementatie worden benoemd.
Een positief advies voor het accepteren van de programmatuur zal gegeven worden als:
1) De programmatuur na de testronde geen blokkerende bevindingen bevat.

2) De programmatuur na de testronde geen ernstige bevindingen bevat.

3) De programmatuur na de testronde geen kleine bevindingen bevat.
De eindrapportage is een acceptatiedocument waarmee opdracht officieel wordt afgesloten en

door ondertekening van het document wordt de inhoud en beschreven bevindingen van
het testresultaat geaccepteerd en het testteam decharge verleent.

7. Organisatie en planning
7.1 Testorganisatie
Hier wordt de organisatiestructuur toegelicht met de diverse taken en verantwoordelijkheden van
de medewerkers in het testteam. De verschillende rollen (testcoördinator, testers, technische
ondersteuning, functionele ondersteuning en methodische ondersteuning) worden benoemd en per
rol wordt aangegeven wat de taken, verantwoordelijkheden en bevoegdheden zijn.
Indien van testers van de gebruikersorganisatie gebruikt wordt gemaakt wordt beschreven wat de
eisen zijn die aan testers worden gesteld, alsmede worden eventuele opleidingen die de testers
dienen te volgen beschreven.
7.2 Planning
[Hieronder een voorbeeld]
Voor het uitvoeren van de test is zoals aangegeven in hoofdstuk 3 een inspanning nodig
van 560 uur exclusief het inrichten van de testomgeving. Deze planning is gebaseerd op
de inzet van ervaren testers.
Op basis van ervaringscijfers van SYSQA wordt van [x –tal] uur als volgt ingepland:
Fase Tijdsplanning
Testplan 10% uur
Testvoorbereiding 50% uur
Testuitvoering 35% uur
Testafronding 5 % uur
100 % uur
Voor het uitvoeren van het complete testprotocol worden de volgende functionarissen
ingezet: [opsomming medewerkers en functies].
Bovenstaande uitgangspunten resulteren tot de volgende verdeling van testfases en

functionarissen:
Functionaris Functienaam Functienaam Functienaam doorlooptijd

Fase
Testplan … Dagen/Uur …Dagen\Uur …Dagen\Uur …Dagen\Uur
Testvoorbereiding … Dagen/Uur …Dagen\Uur …Dagen\Uur …Dagen\Uur
Testuitvoering … Dagen/Uur …Dagen\Uur …Dagen\Uur …Dagen\Uur
Testafronding … Dagen/Uur …Dagen\Uur …Dagen\Uur …Dagen\Uur
De bovengenoemde inspanning- en doorlooptijd planning geeft nog geen indruk over de feitelijke
doorlooptijd van het traject welke van een aantal variabele (bijv.: testomgeving) afhankelijk is.
In week [x] wordt een start genomen voor de testvoorbereiding en kan het volgende tijdschema als
planning worden gebruikt:
Week xx xx xx xx xx xx xx xx xx Mijlpaal
Fase
Testplan Datum
Testvoorbereiding Datum
Testuitvoering Datum
Testafronding Datum

Bij bovengenoemde planning gaan we uit van een testomgeving welke wordt opgeleverd in week
[x] zodat pre-test uitgevoerd kunnen worden.
Om de voortgang van het project te kunnen beoordelen zijn in de planning mijlpalen opgenomen.
De vermelde mijlpalen zijn gebaseerd op inzichten welke op het moment van vervaardigen van het
testplan aanwezig waren.
Toekomstige veranderingen kunnen invloed hebben op de bovenstaande planning en mijlpalen.
Indien noodzakelijk zal in overleg met de projectleider de gevolgen worden besproken en de
mijlpaal worden aangepast.

Handboek testen
Bijlage 7 Sjabloon testspecificatie
SYSQA B.V. Almere
Hieronder treft u een sjabloon aan welke kan worden gehanteerd als een standaard SYSQA
sjabloon. Het sjabloon kunt u gebruiken als in het kwaliteitssyteem van uw opdrachtgever
geen testspecificatie sjablonen worden voorgeschreven
De specificatie bestaat uit een fasering van 8 stappen welke uiteindelijk leiden tot het
opstellen van een gestructureerd testscript.
De volgende stappen worden onderkend:

1. Inleiding;
2. Analyse functiebeschrijving;
4. Bepalen testgevallen;
5. Opstellen matrix testsituaties – testgevallen;
Deze stappen kunt u bij alle in cursus behandelde technieken toepassen voor de stappen 1,3
t/m 7. Bij stap 2 moet een nuance worden aanbracht en per testtechniek worden bekeken of
deze stap een toegevoegde waarde heef en zo ja hoe deze stap ingevuld wordt. In de
navolgende hoofdstukken wordt per stap summier ingegaan op inhoudelijke kant van de
stappen.
In het navolgende zijn de hiervoor genoemde stappen nader uitgewerkt. Op basis van de
resultaten van de stappen 1 t/m 7 ontstaat een testspecificatie en uiteindelijk een testscript.
Het sjabloon kunt U electronisch verkrijgen bij het secretariaat.

Onderwerp Bijlage 7. Sjabloon testspecificatie en testscript Datum 05-01-2000
Inhoudsopgave
1. INLEIDING ....................................................................................................................161
1.1 ALGEMEEN ..................................................................................................................161
1.2 VERSIEBEHEER............................................................................................................161
2. ANALYSE FUNCTIEBESCHRIJVING.........................................................................161
3. BEPALEN TESTSITUATIES........................................................................................161
4. BEPALEN TESTGEVALLEN.......................................................................................161
5. OPSTELLEN DEKKINGSMATRIX..............................................................................162
6. BEPALEN CONTROLES .............................................................................................162
7. VASTSTELLEN INITIËLE GEGEVENSVERZAMELING............................................162
8. OPSTELLEN TESTSCRIPT S ......................................................................................163

1. Inleiding
1.1 Algemeen
In het kort wordt hier de scope en het doel van deze specificatie bepaald.
Beschrijf de uitgangssituatie c.q. testbasis waaruit onderliggende specificatie is geformuleerd.
1.2 Versiebeheer
2. Analyse functiebeschrijving
Bij de analyse van de functiebeschrijving wordt op een eenduidige wijze de testbasis beschreven
zodat de testsituaties hieruit af te leiden zijn. Per testtechniek verschilt de wijze waarop de analyse
van de functiebeschrijving wordt uitgevoerd.
3. Bepalen testsituaties
Uit de analyse van de functiebeschrijving wordt afgeleidt welke situaties getest dienen te worden.
De testsituaties worden opgenomen per variabele (b.v. leeftijd, woonplaats etc.)
Variabele 1
Testsituatie 1.1 Situatie 1
… …
Variabele 2
… …
4. Bepalen testgevallen
De testsituaties worden in deze stap gecombineerd tot testgevallen waarbij elke situatie minimaal
één keer doorlopen wordt.
Bijvoorbeeld:
Testgeval 1 Testgeval 2 …
Variabele 1 Testsituatie 1.1 Testsituatie 1.2 …
Variabele 2 Testsituatie 2.1 Testsituatie 2.2 …
… … … …
De testsituaties waren nog in logische termen (met =, ≠, < en dergelijke) aangegeven. Dit
vereenvoudigd het onderhoud. De testgevallen zijn feitelijk combinaties van de testsituaties.
Deze kunnen eerst als logische testsituaties worden opgezet en dan fysiek (met werkelijke
waarden) worden gemaakt.

5. Opstellen dekkingsmatrix
Een controlemiddel of alle situaties in de testgevallen zijn opgenomen is het gebruik van een
dekkingsmatrix. Hierin worden in de eerste kolom alle gedefinieerde testsituaties opgenomen.
Vervolgens worden de testgevallen vermeld. Als de testgevallen goed zijn gedefinieerd zijn alle te
testen situaties minimaal een keer aangekruist.
De matrix ziet er als volgt uit:
Testgeval 1 2 …
Testsituatie
C1.1 X
C1.2 X
… …
Bij grote matrices kan voor het overzicht nog een kolom toegevoegd worden waarin een
totaaltelling van het aantal kruisjes opgenomen wordt. Deze mag dan niet nul zijn.
6. Bepalen controles
Beschreven moet worden wat gecontroleerd dient te worden en hoe, opdat kan worden
vastgesteld of de verwerking correct is verlopen. De diverse resultaten worden in deze stap van
tevoren berekend.
Dit leidt tot de volgende controles:
C01 Testgeval 1 Verwachte waarde

C02 Testgeval 2 Verwachte waarde
… … …
7. Vaststellen initiële gegevensverzameling

De vulling van de database is afhankelijk van de entiteiten en attributen die in de database zijn
gedefinieerd. In het voorbeeld ziet de vulling van de database er als volgt uit:
Entiteit
Testgeval 1 2
Attribuut 1 Waarde Waarde
Attribuut 2 Waarde Waarde
… … …

8. Opstellen testscripts
Op basis van de testgevallen wordt een testscript opgesteld waarin de volgordelijk uit te voeren
testacties en de controles dienen te zijn beschreven. Tevens worden in het testscript de eventuele
pre- en postcondities vermeld. Precondities zijn acties die uitgevoerd dient te worden voordat het
testscript kan worden uitgevoerd. Postcondities zijn acties die uitgevoerd dienen te worden na
afloop van de uitvoering van het testscript.
Preconditie 1
Preconditie 2
…
Nr. Beschrijving actie Verwacht resultaat Opmerkingen
A01 … …
A02 … …
C01 … …
Postconditie 1
Postconditie 2

Onderwerp Bijlage 9. Sjabloon vrijgaveadvies Datum 05-01-2000
Handboek testen
Bijlage 8 Vrijgave advies
SYSQA B.V. Almere
Manager [naam]
Akkoord:
Datum:
Status: [versie] Datum:
Opgesteld door: [naam auteur]

Inhoudsopgave
1. INLEIDING 166
1.1 ALGEMEEN ........................................................................................................................166
1.2 VERSIEBEHEER .................................................................................................................166
1.3 VERZENDLIJST ..................................................................................................................166
2. MANAGEMENT SAMENVATTING 167
2.1 ONDERWERP.....................................................................................................................167
2.2 ADVIES .............................................................................................................................167
2.3 ONDERBOUWING VAN HET ADVIES .....................................................................................167
2.4 RISICO’S VAN IMPLEMENTATIE ...........................................................................................167
3. GEVOLGDE STRATEGIE EN AANPAK 168
3.1 GEVOLGDE TESTSTRATEGIE ..............................................................................................168
3.2 UITGEVOERDE TESTACTIVITEITEN ......................................................................................168
3.3 OPGELEVERDE TESTPRODUCTEN ......................................................................................168
3.4 ACTUALITEIT T. O. V. TESTPLAN ...........................................................................................168
4. TESTRESULTATEN 169

1. Inleiding
1.1 Algemeen
Allereerst wordt kort beschreven op welke organisatie en welk project, inclusief eventueel
releasenummer, dit vrijgaveadvies betrekking heeft. Vervolgens worden de doelstellingen van het
testtraject opgenomen.
1.2 Versiebeheer
1.3 Verzendlijst
Dit document wordt ter beschikking gesteld aan:
• [naam en functie]

2. Management samenvatting
2.1 Onderwerp
Omschrijving van de opdrachtformulering, afbakening, randvoorwaarden en en uitgangspunten.
2.2 Advies
Beschrijving van het acceptatieadvies.
2.3 Onderbouwing van het advies

Onderbouwing van hierboven gegeven advies.
2.4 Risico’s van implementatie

Hier worden de risico’s opgenomen die gelopen worden en de aandachtspunten die gelden als
overgegaan wordt op implementatie

3. Gevolgde strategie en aanpak
3.1 Gevolgde teststrategie

Beschrijf de teststrategie die gevolgt is.
3.2 Uitgevoerde testactiviteiten

Beschrijf van de uitgevoerde testactiviteiten.
3.3 Opgeleverde testproducten

Beschrijf de opgeleverde mijlpaalproducten.
3.4 Actualiteit t.o.v. testplan

Beschrijf de afwijkingen t.o.v. het testplan.

4. Testresultaten
4.1 Bevindingen
Hier wordt een overzichtelijke samenvatting gegeven van de testresultaten. De testresultaten
kunnen gegroepeerd worden naar ernst, testeenheid, systeemmodule en dergelijke Doel is dat de
lezer in een kort bestek inzicht krijgt in de testresultaten.
4.2 Overige resultaten

Tijdens het testtraject kunnen andere resultaten aan het licht zijn gekomen zoals uitkomsten van
een enquete over gebruikersvriendelijkheid, metingen met behulp van steekproeven of inspecties.
4.3 Risico’s en aandachtspunten bij implementatie

In deze paragraaf wordt dieper ingegaan op de risico’s van implementatie en aandachtpunten bij
implementatie.

Onderwerp Bijlage 9. Sjabloon bevindingen formulier Datum 05-01-2000
Bijlage 9. Sjabloon bevindingenformulier

Nummer: Prioriteit:
Bevindingenrapport [naam testtraject]

Systeem:
Naam aanmelder:
Testgeval-identificatie: 1e test Hertest
Omschrijving testgeval:
[ruimte voor tekst]
Verwacht testresultaat:
[ruimte voor tekst]
Verkregen testresultaat:
[ruimte voor tekst]
Aktie:
[ruimte voor tekst]
Bijlagen: Ja/Nee
Prioriteit Status Datum

1 = [laag ] Geconstateerd
2 = [middel] Aangemeld
3 = [hoog] Hersteld
4 = [blokkerend] Hertest uitgevoerd

Handbook Tester PDF 1v1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Handbook Tester PDF 1v1

Uploaded by

Copyright:

Available Formats

SYSQA B.V.

SYSQA B.V. Almere

Almere © 2001 Quality Assurance in ICT

7.11 FIXATIE TESTPLAN .................................................................................................... 48

BIJLAGE 2. DEFINITIES EN AFKORTINGEN..................................................................... 122

BIJLAGE 3 TESTTOOLS...................................................................................................... 128

BIJLAGE 4. ARTIKEL EISEN AAN INZET TESTTOOLS.................................................... 132

BIJLAGE 5. CHECKLIST S.................................................................................................... 137

BIJLAGE 6. SJABLOON TESTPLAN .................................................................................. 146

BIJLAGE 7 SJABLOON T ESTSPECIFICATIE.................................................................... 159

Almere © 2001 Quality Assurance in ICT

BIJLAGE 8 VRIJGAVE ADVIES ........................................................................................... 164

BIJLAGE 9. SJABLOON BEVINDINGENFORMULIER ...................................................... 170

Almere © 2001 Quality Assurance in ICT

Almere © 2001 Quality Assurance in ICT

2.1 Wat is testen?

Een definitie van testen is:

Een eenvoudige “werkdefinitie” van testen is:

Almere © 2001 Quality Assurance in ICT

2.2 Wat is testen niet?

2.3 Belang van testen

Met betrekking tot de test bestaan de vragen:

Almere © 2001 Quality Assurance in ICT

De grote risico's en de kostbare gevolgen rechtvaardigen een gestructureerde aanpak van

2.4 Testen en kwaliteit

2.4.1 Soorten kwaliteitsmaatregelen

Almere © 2001 Quality Assurance in ICT

2.4.2 Kosten van kwaliteitszorg

Almere © 2001 Quality Assurance in ICT

De baten van gestructureerd testen zijn:

De kosten/baten en risico’s worden door de opdrachtgever bepaald, geoptimaliseerd en

2.5.1 Dynamisch expliciet testen

Almere © 2001 Quality Assurance in ICT

2.5.2 Dynamisch impliciet testen

2.5.3 Statisch testen

White-box testen zijn gebaseerd op de programmacode, de programmabeschrijving of het

Black-box testen zijn gebaseerd op de functionele specificaties en kwaliteitseisen. Er wordt

Almere © 2001 Quality Assurance in ICT

Het V-model is een schematische weergave van een systeemontwikkelingstraject volgens

De programmatest wordt uitgevoerd door de systeemontwikkelaar en richt zich erop vast te

De integratietest richt zich erop vast te stellen of de of de verschillende systeemonderdelen

Almere © 2001 Quality Assurance in ICT

De acceptatietest wordt uitgevoerd namens de opdrachtgever; de gebruikersorganisatie. De

De systeemtest en functionele acceptatietest richt zich allebei op het vaststellen of het

2.7 Welke testaanpak?

Almere © 2001 Quality Assurance in ICT

• Omvang van het informatiesysteem

• Belang van het informatiesysteem voor de organisatie

• Gebruik van CASE tools

• De complexiteit van het informatiesysteem

• Applicatiepakket ,standaardapplicatie of Maatwerkapplicatie,

Almere © 2001 Quality Assurance in ICT

Het testen van applicatiepakketten of standaardapplicaties vereist meestal een andere

De testinspanning houdt bij pakketten rechtstreeks verband met de beïnvloedbaarheid van

Daarnaast is testen in onderhoudssituaties vaak een activiteit van de lijnorganisatie. Dit in

Welke kwaliteitseisen tijdens de acceptatietest worden getest, wordt bepaald in de

• Kwaliteit van de testbasis

Almere © 2001 Quality Assurance in ICT

• Beschikbare mensen en middelen, inclusief de tijd

Almere © 2001 Quality Assurance in ICT

De relaties tussen de verschillende fases zijn in onderstaand schema weergegeven.

AT.2 AT.3 AT.4 AT.5

3.1 Fase: Planning

2. globalest udie 3. vaststellen 4. bepalen 6. inrichten 8. inrichting 11. f ixatie