Inleiding

Laten we beginnen met een greep uit veelgehoorde uitspraken bij projectevaluaties:

Het probleem dat hieraan ten grondslag ligt is dat er bij systeemimplementaties onvoldoende aandacht is voor gedegen gebruikers- en acceptatietests. Hierdoor ontbreken belangrijke waarborgen voor het beheerst doorvoeren van veranderingen in een organisatie.

De risico’s, gerelateerd aan dit probleem, zijn eenvoudig uit te drukken in termen van tijd, geld en kwaliteit. Uitloop van projecten, budgetoverschrijdingen en weerstand tegen veranderingen in de interne organisatie zijn hierbij slechts voorbeelden van zaken die de oorspronkelijke business case voor een project ondermijnen.

Aan deze problematiek liggen tal van oorzaken ten grondslag. Het blijkt dat de testfase nog steeds wordt onderschat, zowel vanuit de project- als de lijnorganisatie. De projectleider ziet testen als de sluitpost van zijn project. Zo is testen vaak als één stap omschreven in het initiële projectplan. Daarnaast wordt deze fase vaak aangegrepen om een opgelopen vertraging in te lopen, bijvoorbeeld door het schrappen of drastisch inperken van de oorspronkelijk geplande testactiviteiten of door testwerkzaamheden te integreren in een andere fase (bijvoorbeeld de conversiefase of schaduwdraaien). Aan de andere kant onderschat de gebruikersorganisatie vaak de complexiteit van het specificeren en uitvoeren van testgevallen, en ontbreekt het overzicht van alle benodigde testactiviteiten. Daarnaast kan de onbekendheid met het testproces een rol spelen.

Het mag duidelijk zijn dat op dit terrein nog veel resultaat te behalen is.

Dit artikel beschrijft hoe een gestructureerde testaanpak eruitziet en hoe deze kan bijdragen aan het succes van het project zowel in kwalitatieve als in kwantitatieve zin. Deze testaanpak kan gezien worden als de start in het proces van ‘ongoing improvement’. Daarbij is kwaliteitsborging van systemen gedurende de gehele levenscyclus het doel. Bewustzijn en actieve betrokkenheid van de gebruikersorganisatie, management en projectleiders zijn daarbij belangrijke voorwaarden voor succes.

Voordat we ingaan op de gestructureerde testaanpak volgt eerst een terugblik op testen anno 1974: het jaar waarin Compact voor het eerst aandacht besteedde aan dit onderwerp.

Dertig jaar testen

Testen anno 1974

In 1974 beschreef J.H. Urbanus in een tweetal artikelen in Compact ([Urba74a], [Urba74b]) hoe een organisatie (lees rekencentrum) het testproces kan inrichten. Uit het feit dat de artikelen zich richtten op de programmeurs bleek het belang van rekencentra in de acceptatie van een systeem. Urbanus onderschreef het belang van het zoveel mogelijk betrekken van de gebruiker in het testproces. In die tijd kwam dit hoofdzakelijk neer op het door de gebruiker laten aanleveren van testgegevens (indien mogelijk). De verantwoordelijkheid voor de planning en uitvoering van de tests lag bij het rekencentrum.

Doel van het testen in 1974 was primair het ontdekken en het ‘debuggen’ (corrigeren) van fouten. Daarbij werden als testfasen benoemd het testen van:

• programmamodules;
• individuele programma’s;
• programmaseries;
• deelprojecten;
• het gehele project;
  
  en tot slot
• de gebruikersacceptatie.

Volgens Urbanus was de belangrijkste (en meest onderschatte) test de moduletest. Wat zoveel inhield als het logisch testen van subroutines in de programmatuur door de programmeur. Daarnaast werd stilgestaan bij een aantal richtlijnen voor het testen (zie kader 1).

Urbanus besteedde ook aandacht aan het onderwerp testmonitoring. Hierbij ging het met name om het bijhouden van het problemenlogboek en het sturen op openstaande bevindingen. Afsluitend stelde Urbanus een gebrek aan automatiseringskennis bij de gebruiker vast. Het was de taak van de automatiseringsafdeling de gebruiker op te leiden.

Testen anno 2004

Sinds 1974 is er veel veranderd op het gebied van testen. Dit is onder meer te verklaren door technologische ontwikkelingen, veranderingen in projectmethodieken en toegenomen affiniteit van gebruikers met ICT. Daarnaast is een belangrijke verandering de introductie van gestructureerd testen en bijbehorende methodieken, waarvan TMap ([Pol95]) in Nederland het bekendste voorbeeld is.

Een gestructureerde testaanpak is niet een op zichzelf staand iets. Een gestructureerde testaanpak ontleent zijn toegevoegde waarde voor een groot deel aan een goede integratie met de diverse fasen in een systeemontwikkeltraject. Aspecten van testen komen op diverse plekken terug tijdens een ontwikkeltraject van een nieuw of te wijzigen systeem.

Daarnaast legt de gestructureerde testaanpak een belangrijke basis voor een efficiënt test- en acceptatieproces in het onderhoud en beheer van het systeem. Nadat eenmalig is bepaald hoe het systeem getest wordt, kan bij iedere wijziging van het systeem gebruik worden gemaakt van de beschikbare testmiddelen.

In dit artikel beschrijven we de testaanpak aan de hand van het ontwikkel- en implementatietraject van een nieuw informatiesysteem.

Fasering

Een ontwikkel- en implementatietraject bestaat doorgaans uit de in figuur 1 weergegeven fasen.

Figuur 1. Fasering ontwikkel- en implementatietrajecten en de relatie met testen.

De integratie van de testaanpak in het implementatietraject komt tot uitdrukking in het feit dat er in de projectfasen voorafgaande aan het moment van ‘live’ gaan expliciet aandacht is voor het testen. Dit verband komt enerzijds tot uitdrukking in een duidelijke relatie tussen projectdeliverables en testactiviteiten (denk aan een projectplanning waarin de testactiviteiten zijn opgenomen) en anderzijds in de ontwikkeling en het gebruik van specifieke testdeliverables.

In de nazorgfase van een implementatietraject zal de aandacht voornamelijk gericht zijn op de overdracht en de opvolging van openstaande bevindingen.

In de volgende paragrafen wordt ingegaan op deze fasen en de rol die het testproces daarin speelt, wanneer de integrale testaanpak wordt gevolgd.

Fase 1. Voorbereiding

De implementatie van een nieuw systeem is doorgaans een langdurig en complex traject. Nadat een organisatie heeft besloten tot invoering van een nieuw systeem, zijn er kortweg drie mogelijkheden:

• keuze voor een standaardpakket;
• keuze om het pakket van de grond af aan helemaal zelf te (laten) bouwen, of
• keuze voor een combinatie van de twee hiervoor genoemde.

Welke mogelijkheid men ook kiest, eerst dient men de vraag ‘Wat willen we eigenlijk hebben?’ te stellen. Kortom, de eisen en wensen moeten in kaart worden gebracht. Op basis van deze eisen en wensen kan (in geval van een standaardpakket) een pakketselectietraject worden gestart om een gedegen keuze voor het best passende pakket mogelijk te maken. In geval van maatwerk vormen de eisen en wensen de basis voor de functionele specificaties van het te bouwen systeem.

Onduidelijkheden en inefficiënties in het testproces moeten zoveel mogelijk worden vermeden. Daarom is het van belang om in een zo vroeg mogelijk stadium duidelijkheid te hebben welke aspecten van het informatiesysteem geaccepteerd moeten worden.

Het vastleggen van de eisen en wensen is dan ook feitelijk de start van het testtraject. In de praktijk worden eisen en wensen vaak vastgelegd in een zogenaamd scopingsdocument, waarin de grenzen van het project bepaald zijn, zowel op functioneel, organisatorisch als technisch gebied. Wat vaak in testtrajecten over het hoofd wordt gezien, is dat deze eisen de basis vormen voor de bepaling van de acceptatiecriteria waaraan het systeem moet voldoen.

Er zijn verschillende manieren om acceptatiecriteria vast te leggen. Daarbij kan gebruik worden gemaakt van beschikbare standaarden en kwaliteitsmodellen. De bekendste modellen hiervoor zijn het ISO 9126-model en het Extended ISO-model (SERC) ([Pill02]). Deze modellen richten zich primair op productkwaliteit. In kader 2 zijn de kwaliteitsaspecten waarop deze modellen zich baseren, opgenomen. Dergelijke modellen ontlenen hun toegevoegde waarde voornamelijk aan het feit dat ze aan requirements en acceptatiecriteria een plaats geven. Daarmee kunnen dergelijke modellen een belangrijk hulpmiddel zijn om een volledige set van acceptatiecriteria op te bouwen.

Een ander raamwerk voor het vastleggen van deze acceptatiecriteria is het groeimodel van Nolan Norton ([Nola74]). Het model is gebaseerd op vier fundamenten:

• processen en diensten;
• mensen en cultuur;
• infrastructuur;
• management en organisatie.

Processen en diensten

Onder dit deelgebied vallen alle functionele acceptatiecriteria, zoals algemene en specifieke functies, rapporten en interfaces.

Mensen en cultuur

Onder dit deelgebied vallen alle acceptatiecriteria rondom procedures, werkinstructies, handleidingen, systeemdocumentatie, trainingen en dergelijke.

Infrastructuur

Dit deelgebied omvat de technische acceptatiecriteria zoals systeemstabiliteit, performance, verbindingen met andere systemen, back-up en recovery.

Management en organisatie

Onder dit deelgebied vallen acceptatiecriteria zoals autorisaties, stamgegevens en managementrapportages.

Naast aandacht voor een goede afbakening van het project wordt in deze fase ook een projectplanning opgesteld. Het is zaak hier expliciet aandacht te besteden aan activiteiten die in het kader van test en acceptatie moeten worden uitgevoerd. Hoewel het moeilijk is om in deze fase de testinspanning in te schatten is het belangrijk dat er inzicht is in de te leveren deliverables (project- en testdeliverables) en de afhankelijkheden daartussen.

Door het adresseren van bovengenoemde aspecten wordt impliciet bewustzijn gecreëerd ten aanzien van het testen. Dergelijke bewustwording is cruciaal voor het verdere verloop van het project. In de praktijk blijkt namelijk maar al te vaak dat test- en acceptatieactiviteiten zwaar worden onderschat, wat in de testuitvoering kan leiden tot spanningen en frustraties.

Fase 2. Analyse

In de analysefase van het implementatietraject worden de functionele specificaties tot in detail uitgewerkt en vastgelegd in een functioneel ontwerp. Daarnaast wordt voor een groot deel duidelijk hoe de huidige procedures en werkinstructies aangepast moeten worden aan de nieuwe werkwijze, hoe de inbedding van het systeem in het rekencentrum gerealiseerd moet worden en welke autorisatiestructuur gehanteerd gaat worden. Kortom, tijdens de analysefase wordt een verdere invulling gegeven aan de vier pijlers van het Nolan Norton-model.

Figuur 2. Groeimodel van Nolan Norton.

In deze fase wordt duidelijk welke wijzigingen in de organisatie worden doorgevoerd. Wijzigingen vormen een bedreiging voor de betrouwbaarheid van de gegevensverwerking. Testen is een maatregel om het risico dat de organisatie loopt als gevolg van wijzigingen te beheersen. Om enige zekerheid te verkrijgen over de betrouwbaarheid van het nieuwe systeem en bijbehorende procesgang, zullen functionele, technische en organisatorische wijzigingen getest moeten worden.

In theorie wordt gestreefd naar een 100% volledige test. Dit betekent bijvoorbeeld voor het testen van de systeemfunctionaliteit, dat alle mogelijke combinaties van invoergegevens getest zouden moeten worden. In de praktijk is dit niet haalbaar vanwege het veelal exponentiële aantal te testen paden en mogelijkheden. Tijd en kosten zijn beperkende factoren. Om te voorkomen dat er ‘in het wilde weg’ getest wordt, dient de organisatie te bepalen waarop de nadruk bij het testen moet komen te liggen. Een hulpmiddel bij het maken van een gewogen afweging is het opstellen van een risicoprofiel aan de hand van een risicoanalyse.

Risicoanalyse

Risico wordt doorgaans gedefinieerd als het product van de kans (of waarschijnlijkheid) dat een bepaalde bedreiging optreedt, en de impact die de bedreiging veroorzaakt. Met behulp van beide factoren wordt het risicoprofiel vastgesteld.

Op hoofdniveau (bijvoorbeeld procesniveau) dient de organisatie per geïmplementeerd onderdeel te bepalen wat de kans is dat het betreffende onderdeel niet aan de gewenste situatie voldoet en wat de impact is op de organisatie mocht het onderdeel inderdaad niet goed zijn geïmplementeerd. De hoogte van de kans en impact wordt meestal kwalitatief bepaald; deze is bijvoorbeeld hoog, middel of laag.

In de risicogrid worden niet alleen de functionele (proces)aspecten uitgezet, maar ook organisatorische, gebruikers- en technische aspecten. Bijzondere aandacht moet worden besteed aan het aspect gegevens. Zeker als er grote hoeveelheden gegevens uit een oud systeem geconverteerd moeten worden naar het nieuwe systeem.

Nadat van alle aspecten het risico is bepaald en is uitgezet in de risicogrid, is het risicoprofiel compleet. Op basis van dit profiel bepaalt de organisatie welke aspecten wel en welke niet (of in mindere mate) worden meegenomen gedurende het testen. Logischerwijs zullen aspecten met een hoge kans en veel impact zonder meer moeten worden meegenomen en intensief worden getest. Het is aan de organisatie om te bepalen welk (rest)risico zij accepteert en welke aspecten derhalve niet of beperkt worden meegenomen tijdens het testen.

Kortom, de risicogrid kan worden gebruikt voor het bepalen van de scope van, de diepgang van en de prioriteit binnen het testen. Figuur 3 toont een voorbeeld van een gedeeltelijk ingevulde risicogrid. Uit de figuur blijkt bijvoorbeeld dat de orderinvoer-functionaliteit en de werkinstructies van het verkoopproces intensief getest moeten worden, gezien het grote risico dat de organisatie op deze twee gebieden loopt.

Figuur 3. Voorbeeld van een risicogrid.

Testplan

Aan de hand van de risicogrid worden de scope en de diepgang van het testtraject bepaald. Het ‘wat’ is nu bekend. De volgende stap is de bepaling van het ‘hoe’. Dit wordt vastgelegd in een testplan. Hierin wordt aangegeven:

• welke uitgangspunten en randvoorwaarden gelden;
• welke testmethodiek wordt toegepast;
• welke eisen gelden ten aanzien van de testomgeving;
• welke testprocedures van toepassing zijn;
• welke geautomatiseerde testtools worden ingezet;
• hoe de planning eruitziet.

Daarnaast moet worden vastgelegd hoe de testorganisatie en de te gebruiken testprocedures zijn ingericht. Van belang is het om duidelijkheid te scheppen waar het gaat om de vraag welke personen waarvoor verantwoordelijk zijn. Hierbij moet worden gedacht aan de activiteiten testvoorbereiding, omgevingenbeheer, testcoördinatie, testuitvoering en probleemafhandeling. Verder geeft het testplan inzicht in de belangrijkste testgevallen die als uitgangspunt dienen voor de te testen onderdelen.

Het testplan wordt geaccordeerd door de (project)organisatie en dient als uitgangspunt voor de voorbereidende testactiviteiten.

Fase 3. Bouw

Gedurende de bouwfase worden de specificaties uit de analysefase omgezet in modules, werkinstructies, procedures, etc. Eenmaal opgeleverd zullen al deze zaken moeten worden getest.

De bouwfase is, wat het testen betreft, de meest intensieve fase. Naast de feitelijke tests die hier plaatsvinden, vinden in deze fase diverse activiteiten plaats ter voorbereiding van de tests.

Voorbereiding van de gebruikerstests

Bepalen testgevallen

Op basis van het testplan en de beschikbare en goedgekeurde projectdeliverables (waaronder functionele specificaties) wordt in detail bepaald welke aspecten getest moeten worden. Kortom, de te testen situaties worden vastgesteld. Als kapstok voor het opstellen van de testgevallen kan gebruik worden gemaakt van een procesinsteek: per bedrijfsproces wordt vastgesteld welke functionaliteiten (modules en functies), welke interfaces met andere systemen en dergelijke getest moeten worden. Specifieke aandacht moet worden besteed aan maatwerk, interfaces, niet-standaardrapporten en, in geval van een standaardpakket, specifieke gaps. Bij een standaardpakket geldt over het algemeen dat de (standaard) basisfunctionaliteit al bij diverse implementaties getest is c.q. gebruikt wordt door diverse bedrijven. Zeker als een standaardpakket reeds langere tijd op de markt is en door veel bedrijven wordt gebruikt, kan gesproken worden van ‘proven technology’. Bij standaardpakketten liggen de risico’s niet zozeer op het gebied van de basisfunctionaliteit, maar meer op het gebied van de specifiek voor die organisatie gemaakte aanpassingen en toevoegingen (‘gaps’) op de standaard.

Bepalen uitgangsdatabase

Vervolgens dient bepaald te worden wat de exacte uitgangsdatabase is. De uitgangsdatabase bevat de populatie waarop de test wordt uitgevoerd. De uitgangsdatabase is op hoofdlijnen al gedefinieerd in het testplan, maar wordt in de voorbereidende testfase in detail uitgewerkt. Zaak is om de uitgangsdatabase zo compact, maar zo volledig mogelijk te houden. Concreet betekent dit dat de organisatie moet bepalen welke situaties representatief zijn voor de dagelijkse gang van zaken. Zo zou een leasebedrijf moeten bepalen welke typen leasecontracten representatief zijn en een WAO-administratiekantoor moeten bepalen welke WAO-gevallen representatief zijn.

In de praktijk is het handig om het opstellen van testgevallen en het bepalen van de uitgangsdatabase in één stap uit te voeren. Bij het opstellen van testgevallen wordt namelijk vaak al impliciet nagedacht over welke populatie kan worden gebruikt om een bepaalde situatie mee te testen. Door tijdens het opstellen van de testgevallen deze populatie meteen vast te leggen, wordt voorkomen dat de uitgangsdatabase achteraf niet goed aansluit op de uit te voeren tests.

Het is van groot belang om kerngebruikers te betrekken bij het opstellen van de testgevallen en de uitgangsdatabase. Een IT-auditor vervult vaak een ondersteunende rol bij het opstellen van de testgevallen en de uitgangsdatabase, maar mist doorgaans diepgaande materiekennis van de processen in de organisatie. Om een volledige set testgevallen en een representatieve uitgangsdatabase op te kunnen leveren is input van kerngebruikers van essentieel belang.

Bij het opstellen van de uitgangsdatabase is het van belang rekening te houden met de afhankelijkheid van testscripts. Bij het uitvoeren van een testscript worden doorgaans testdata gewijzigd. Dit kan tot ongewenste resultaten leiden in die gevallen dat er meerdere testscripts van hetzelfde testgeval gebruikmaken. Derhalve is het aan te raden om een individueel testgeval te gebruiken in maximaal één testscript.

Opstellen testscripts

Nadat bekend is welke gevallen getest gaan worden op basis van welke uitgangsdatabase, dienen de testscripts te worden opgesteld. Een testscript beschrijft de handelingen die de tester moet uitvoeren om het testgeval te kunnen testen. Daarbij is de functionaliteit afgebakend. Per testgeval wordt minimaal één testscript opgesteld. Indien gewenst kunnen meerdere testgevallen worden samengevoegd in één testscript. De testscripts kunnen vervolgens worden toegewezen aan de individuele testers.

Opstellen testmatrix

Een hulpmiddel voor het waarborgen van de volledigheid van de tests is het opstellen van een testmatrix. Afhankelijk van de doelgroep kan deze testmatrix op verschillende niveaus worden ingestoken. Zo zal het team dat de testscripts opstelt behoefte hebben aan een gedetailleerde matrix, waarin elk te testen onderdeel van een functie naar voren komt. In dat geval worden enerzijds alle te testen functionaliteiten vastgelegd en anderzijds de testscripts.

De matrix kan echter ook worden gebruikt als rapportage-instrument richting management. In dat geval dient de matrix op een hoger (geaggregeerd) niveau te worden ingestoken. Bijvoorbeeld de hoofdprocessen uitgezet tegen de belangrijkere functies/modules binnen het systeem.

Door het relateren van beide gegevens in de matrix ontstaat er een gestructureerd inzicht in welke aspecten geraakt worden in welke test. In één oogopslag kan worden vastgesteld welke aspecten niet of onvoldoende geraakt worden in de testscripts. De testmatrix is een middel om de volledigheid van de tests te waarborgen.

Bepalen proceslevenscyclus

Als laatste dient de procesgang in kaart gebracht te worden en vastgelegd te worden in een proceslevenscyclus. Per proces dat het systeem ondersteunt dient een onderscheid te worden gemaakt tussen de belangrijkste activiteiten binnen het proces. Vervolgens dienen de activiteiten zodanig vastgelegd te worden dat ze de logische procesgang in de tijd weergeven. Deze proceslevenscyclus is de basis van de hierna te bespreken integratietest.

Testen

Nadat de testvoorbereiding is afgerond, kan er begonnen worden met het daadwerkelijke testen. De tests kunnen grofweg worden ingedeeld in vier deelgebieden waarop wordt getest, en wel:

• testen van systeemfunctionaliteit;
• testen van organisatorische wijzigingen;
• testen van technische aspecten;
• testen van geconverteerde gegevens.

In figuur 5 worden verschillende soorten tests weergegeven. Het doel van de functionele test is zekerheid te krijgen over het correct functioneren van afzonderlijke applicatieonderdelen. Bij de integratietest staat de integratie tussen deze onderdelen centraal, evenals relaties met andere systemen. De technische test is vergelijkbaar met de functionele test, maar richt zich in het bijzonder op de technische aspecten van de applicatie. De organisatorische veranderingen worden ook onderworpen aan een ‘test’. Hierbij moet onder andere gedacht worden aan de kwaliteit van nieuwe of aangepaste procedures en werkinstructies, het opleidingsniveau van betrokken medewerkers en de inrichting van de beheerorganisatie. De finale acceptatietest is een afsluitende test, met als doel het vaststellen van het correct functioneren van het geaccepteerde systeem met de geconverteerde data.

Figuur 4. Voorbeeld testmatrix. [Klik hier voor een grotere afbeelding]

Figuur 5. Soorten tests.

In deze paragraaf gaan we specifieker in op de tests die direct betrekking hebben op de juiste werking van het systeem, te weten de functionele test, de integratietest, de technische test en de finale acceptatietest. Derhalve blijven in dit artikel het testen van conversieprogrammatuur en het controleren van de conversie verder buiten beschouwing.

Functionele test

De nieuwe software dient uitgebreid getest te worden voordat deze geaccepteerd wordt. De daadwerkelijke testactiviteiten richten zich in het begin voornamelijk op het testen van de functionaliteit van het nieuwe systeem.

Een voorwaarde voor het uitvoeren van een functionele test is dat vóór vrijgave ten behoeve van de gebruikerstest, door de programmeur een systeemtest is uitgevoerd. In de systeemtest controleert de programmeur of de betreffende functie werkt. Dit houdt bijvoorbeeld in dat vastgesteld moet zijn dat de functie gestart kan worden zonder dat het systeem vastloopt, dat er inderdaad een rapport uit de printer komt, etc. De systeemtest geeft inzicht in de technische werking van een functie op programmaniveau. Een systeemtest is echter geen waarborg voor de juistheid van de door de functie opgeleverde gegevens. Daarvoor dient de functionele test.

Het verschil tussen een systeemtest en een functionele test is gelegen in het feit dat de systeemtest wordt uitgevoerd door en vanuit het oogpunt van de ontwikkelaar en de functionele test door en vanuit het oogpunt van de gebruiker. Daarnaast zullen in de praktijk de bij de functionele test gebruikte testgegevens de werkelijkheid beter benaderen dan de gebruikte gegevens bij de systeemtest.

Tijdens de functionele test (ook wel unittest genoemd) wordt op basis van de testscripts en testpopulatie de individuele functionaliteit van het systeem getest op het niveau van modules en functies. Hierbij kan worden gedacht aan het testen van een individuele berekening, rapport, scherm of interface.

Een functionaliteit moet één of meer keren getest worden, afhankelijk van het bijbehorende risicoprofiel en het feit of een test al dan niet succesvol wordt afgerond.

Integratietest

Het doel van de integratietest is zekerheid te krijgen over de juiste werking van de programmatuur gedurende de gehele procesgang. De nadruk ligt bij deze test op de toetsing van de programmatuur en niet van de data. Belangrijkste eindproduct van deze test is een door de gebruikersorganisatie geaccepteerde applicatie.

Tijdens de integratietest wordt de samenhang tussen de functies en de relatie met systemen in de omgeving getest. Hierbij wordt als uitgangspunt de totale keten van processen gehanteerd. Bijvoorbeeld het verwerken van een inkooporder dat moet leiden tot de juiste mutaties in geld- en goederenstromen in zowel het inkoopsysteem als het voorraadsysteem en in de boekhouding. Om dit te bereiken kunnen de scripts van de functionele test eenvoudig worden hergebruikt door deze aan de hand van de procesgang in de juiste volgorde uit te voeren.

Technische test

Het doel van de technische test is het testen van de technische infrastructuur (hardware, netwerk, middleware, DBMS) en performance van de applicatie. Deze test wordt door zowel eindgebruikers als de lokale ICT-organisatie uitgevoerd. Eindgebruikers richten zich met name op aspecten als performance (bijvoorbeeld opbouw van schermen en snelheid van uitvoeren van complexe berekeningen) en stabiliteit van het systeem (‘monkey test’). De lokale ICT-organisatie is enerzijds bij deze test betrokken als leverancier van de technische infrastructuur en heeft anderzijds ook een accepterende rol met betrekking tot de beheerfuncties in het systeem. Hierbij kan bijvoorbeeld gedacht worden aan de productieaansturing (het opstarten van batch jobs) en databasemanagementfuncties (schoning en archivering van gegevens).

In de praktijk krijgt deze test vaak onvoldoende prioriteit.

Acceptatietest

Feitelijk is hier sprake van het finale acceptatiemoment van het systeem.

Het doel van de acceptatietest is vast te stellen dat het totale systeem ook op de geconverteerde gegevens correct functioneert. In feite vindt hier een herhaling plaats van de integratietest. Echter, de basis voor deze test zijn de geconverteerde productiegegevens. Er wordt derhalve niet getest op basis van specifieke testgevallen, maar nu geldt het principe dat alle functies (minimaal) één keer geraakt moeten worden. Hierbij kan net als bij de integratietest gebruik worden gemaakt van reeds ontwikkelde testscripts.

Als de fasen zoals deze hiervoor zijn beschreven goed doorlopen zijn, dan volstaat het om bij de acceptatietest vast te stellen dat elke functie na uitvoering van de conversie nog werkt. Het is in principe niet de bedoeling om vergelijkbare uitgebreide controles uit te voeren, zoals deze bij de functionele en integratietest zijn uitgevoerd.

Echter, afhankelijk van de mate van zekerheid die men wenst kan ervoor gekozen worden om extra detailcontroles uit te voeren. Een overweging kan bijvoorbeeld zijn om functies die op grond van de risicoanalyse een hoog risico hebben, extra aan de tand te voelen.

Een veelgebruikte vorm van acceptatietesten is het ‘schaduwdraaien’. Hierbij draaien twee verschillende omgevingen (i.c. het oude systeem en het nieuwe systeem) in productie naast elkaar, waarbij het oude systeem leidend is. De uitvoer van het nieuwe systeem wordt één op één vergeleken met de uitvoer van het oude systeem. Deze methode geeft een hoge mate van zekerheid, maar vereist veel inspanning.

Testmanagement

Een integraal onderdeel van een testtraject is testmanagement. Testmanagement is in feite niet meer dan het monitoren en het beheersbaar houden van een testtraject. In de praktijk is dit echter vaak een onderbelicht aspect. In tegenstelling tot wat gedacht wordt, spelen het belang en de noodzaak van adequaat testmanagement niet alleen een rol bij omvangrijke testtrajecten.

Ook bij kleinere testtrajecten is adequaat testmanagement van groot belang. In de praktijk blijkt dat binnen kleine en middelgrote testtrajecten meer dan honderd testscripts zijn gedefinieerd en dat bij de uitvoering van de feitelijke tests honderden bevindingen naar voren komen.

In zulke situaties is het van belang dat bevindingen gestructureerd worden opgepakt. Daarnaast is het zaak om inzicht te hebben (en te houden) in de voortgang van een testtraject. Vragen als ‘Hoeveel procent van het testscript is afgerond?’, ‘Hoeveel showstoppers moeten er nog worden opgelost om een positieve ‘go/no go’-beslissing te nemen?’ zijn legitieme vragen, die vaak à la minute moeten kunnen worden beantwoord. Van belang is te focussen op die issues die een ‘go/no go’-beslissing beïnvloeden.

De basis van adequaat testmanagement is dan ook een gestructureerde registratie van testscripts en bevindingen. Daarnaast is het van belang om bevindingen naar zwaarte of belang te categoriseren, zodat prioriteiten kunnen worden gesteld. Een veelgebruikte indeling in de praktijk is het onderscheid tussen showstoppers, ernstige fouten en kleine fouten, waarbij geldt dat in ieder geval alle showstoppers moeten worden opgelost alvorens de finale acceptatie van het systeem kan plaatsvinden.

Ter ondersteuning van testmanagement zijn diverse geautomatiseerde tools beschikbaar in de markt. De kracht van dergelijke tools is gelegen in de (grafische) rapportages die inzicht geven in de status en voortgang van het testen.

Een gestructureerde vastlegging van de testresultaten is een essentieel onderdeel van testmanagement. Het gaat hierbij niet alleen om het verzamelen van bewijsmateriaal met betrekking tot gemelde problemen, maar ook bewijslast van een correcte werking van de functionaliteit.

Figuur 6. Voorbeeld van rapportage door een testmanagementtool. [Klik hier voor een grotere afbeelding]

Fasen 4 en 5. Go Live en Nazorg

Acceptatiedocument

De basis voor een verantwoorde besluitvorming omtrent het in productie nemen van het systeem ligt vast in het acceptatiedocument, dat een afgeleide is van het in de voorbereidingsfase opgestelde scopingsdocument. In het acceptatiedocument worden alle onderkende deelaspecten (denk aan functionaliteit, gebruikershandleidingen, etc.) van het project benoemd, van een prioriteit voorzien en toegekend aan een verantwoordelijke binnen de organisatie. Deze functionaris is verantwoordelijk voor het formeel accorderen van het betreffende deelaspect. Het is daarom ook zaak deze verantwoordelijke in de voorbereidingsfase van het project al te betrekken.

Een goed acceptatiedocument bevat naast de handtekening van de verantwoordelijke ook een verwijzing naar het testbewijs aan de hand waarvan het akkoord gegeven is. In die gevallen waarin dergelijk bewijs niet voorhanden is of het akkoord niet gegeven wordt, moet de consequentie vóór het in productie nemen van het systeem worden onderkend en vastgelegd. Concreet betekent dit dat inzichtelijk moet zijn welke risico’s de organisatie hierdoor loopt en welke maatregelen en vervolgacties moeten worden genomen. Op basis van deze gegevens dient de organisatie te bepalen of het verantwoord is om in productie te gaan.

Nadat het systeem in productie is genomen, start de nazorgfase. Uit oogpunt van testen dient er in de nazorgfase aandacht te worden besteed aan een aantal belangrijke aspecten.

Monitoring

Het eerste aspect is het controleren van de juiste werking en het juiste gebruik van het systeem. Dit zal doorgaans gebeuren door het aanmaken van signaleringslijsten door het systeem (indien beschikbaar) of het uitvoeren van ad hoc-queries op de database. Indien mogelijk kan hierbij gebruik worden gemaakt van controles die bij de conversie zijn uitgewerkt.

Daarnaast brengt het gebruik van het systeem doorgaans de nodige kinderziekten aan het licht. Om uitloop van de nazorgfase te voorkomen is het van belang dat over de afhandeling van dergelijke problemen duidelijke afspraken worden gemaakt tussen de lijn- en projectorganisatie. Bijvoorbeeld met betrekking tot het moment waarop dergelijke problemen door het project nog worden afgehandeld.

Overdracht

Als laatste zullen de herbruikbare testdeliverables, zoals testscripts en het testmanagementtool, moeten worden overgedragen aan de lijnorganisatie. Ook de vervolgacties, die in het acceptatiedocument zijn beschreven, worden belegd bij de lijnorganisatie.

De belangrijkste verschillen: testen anno 1974 versus 2004

In het begin van dit artikel is kort stilgestaan bij de visie op testen anno 1974. Het is interessant deze visie te projecteren op de beschreven gestructureerde testaanpak. Daarbij vallen de in tabel 1 genoemde zaken op.

Tabel 1. Testaspecten 1974 versus 2004.

Het overzicht laat zien dat er de afgelopen dertig jaar veel veranderd is op het gebied van testen. Echter, in de praktijk zien we nog al te vaak voorbeelden van een testaanpak die dichter aanligt tegen de benadering van 1974 dan tegen de geïntegreerde aanpak anno 2004.

Conclusie

In dit artikel zijn het nut en de toegevoegde waarde van een gestructureerde testaanpak uiteengezet aan de hand van ervaringen uit de praktijk anno 2004. Daarnaast is kort stilgestaan bij de ontwikkelingen die zich de afgelopen dertig jaar op dit terrein hebben voltrokken.

Testen is een activiteit die niet onderschat moet worden. De integratie van deze activiteiten binnen de projectfasen is van cruciaal belang voor de uiteindelijke kwaliteit van het systeem. Maar ook factoren als tijd en kosten worden door deze integratie beter beheerst.

Een belangrijk aspect van het hedendaagse testen is het maken van verantwoorde keuzen. Keuzen met betrekking tot de scope en diepgang van de tests, maar ook keuzen met betrekking tot de risico’s die de organisatie bereid is te nemen bij het in productie nemen van het systeem. Een gestructureerde testaanpak biedt bij het maken van deze keuzen een belangrijk houvast.