Over het testen van systemen zijn dikke boeken met bijbehorende dure cursussen op de markt beschikbaar. Toch blijken veel bedrijven het testproces nog niet gestructureerd aan te pakken. Een projectmanager van Rocade schetst een op ervaring gebaseerde aanpak om snel, effectief en efficiënt millenniumtesten op te zetten en uit te voeren.
De millenniumproblematiek is bij een ieder genoegzaam bekend. Over het algemeen wordt de programmatuur gescand en vervolgens aangepast. Hierbij bestaat de keuze voor windowing of widening. Bij windowing wordt een breekjaar-constructie afgesproken zodat bijvoorbeeld jaartallen tot 15 gelden als 2000 en na 15 als 1900. Bij widening wordt het jaartal opgerekt naar vier posities. Voor de teststrategie maakt dit geen enkel verschil.
In de aard van de millenniumproblematiek ligt besloten dat op geen enkele wijze met 100 procent zekerheid de millenniumbestendigheid is vast te stellen. Dit heeft te maken met de volledigheid van de analyse enerzijds (vindt men alles?), de juistheid van de reparaties anderzijds (wordt het correct opgerekt of geïnterpreteerd) en de ketenproblematiek. Organisaties maken deel uit van grotere informatiehuishoudingen waardoor hun informatieverwerking met meerdere ketens is verweven. Het millenniumprobleem is dan ook vooral een ketenprobleem. Met het oog op de complexiteit van de ketens en de vele verbanden die er bestaan tussen de systemen is het onmogelijk te zeggen in hoeverre deze systemen of clusters van systemen millenniumbestendig zijn.
Het millenniumprobleem is in een aantal opzichten uniek. Tabel 1 geeft de belangrijkste verschillen weer tussen het reguliere onderhoud en de aanpak voor het millennium.
Gezien deze verschillen wordt voor millenniumtesten een andere organisatie voorgesteld dan gebruikelijk is na regulier onderhoud.
Doelstelling millenniumtesten
In tegenstelling tot testen na regulier onderhoud of nieuwbouw, zal men – ook als er in de scans niets gevonden wordt en er niets gerepareerd is – moeten aantonen dat het systeem zich in de toekomst naar behoren blijft gedragen.
De doelstelling van de millennium testen is slechts het vergroten van de zekerheid dat het systeem de eeuwwisseling aankan. Helaas is deze zekerheid om een aantal redenen niet objectief kwantificeerbaar.
Testen kunnen de aanwezigheid van een fout aantonen, maar niet de afwezigheid van andere fouten. Verder worden bij het testen van programmatuur niet alle combinaties getest, maar gaat het altijd om een steekproef uit de miljarden mogelijkheden. Tenslotte is het ook met tijdreizen niet geheel mogelijk een situatie te simuleren waarin het ‘volledig een moment na het jaar 2000 is’.
Toch zullen bedrijven om de risico’s met het millennium te verkleinen, aantoonbare resultaten willen hebben waaruit blijkt dat bepaalde cruciale functies tijdens en na de millennium-overgang correct blijven werken. Alleen door met het systeem tijdreizen naar de toekomst uit te voeren, is het mogelijk aan te tonen dat bepaalde gevallen binnen bepaalde functies op bepaalde data correct worden behandeld. Deze tijdreis dient zowel de systeemklok als de gegevens te betreffen. In feite omvat het tijdreizen een blackbox-test waarin op basis van vastgestelde prioriteiten naar fouten wordt gezocht. Het vinden en herstellen van deze millenniumbugs is het primaire doel.
Testmanagement
Om dit efficiënt en effectief te realiseren, zal veel aandacht geschonken moeten worden aan de organisatie en de besturing van het testproces.
Stel een team samen met een duidelijke opdracht en verantwoordelijkheid. In dit team moeten alle betrokkenen van een bepaald systeem breed vertegenwoordigd zijn, zowel gebruikers als technisch en functioneel beheerders. Heel belangrijk voor het welslagen van de missie is een goede samenwerking en werkhouding van de diverse leden. Kwalificaties zijn: actieve betrokkenheid, verantwoordelijkheidsgevoel, initiatiefrijk, directe communicatie, flexibiliteit, oog voor voortgang en resultaat, een goed besef dat de planning bindend is, enzovoort. Ook bij millenniumtesten geldt dat het resultaat – meer dan door de gebruikte methoden en technieken – wordt bepaald door de kwaliteit van de mensen die verantwoordelijk zijn en de testen uitvoeren.
In het geval van millenniumtesten geldt bovendien: een goede voorbereiding is niet het halve werk !
Een goede voorbereiding is noodzakelijk, maar kan onafhankelijk van andere activiteiten opgestart worden en moet zoveel mogelijk buiten het kritieke pad gehouden worden. Het is cruciaal om millenniumfouten snel te vinden, zodat deze tijdig hersteld kunnen worden. Aangezien de tijd dringt, moeten de testen zo snel mogelijk worden uitgevoerd zodat de te bereiken zekerheid over millenniumbestendigheid toeneemt. Bovendien kan de testinspanning bijna niet op voorhand worden gepland en zal er met time-boxing een doorlooptijd vastgesteld moeten worden. De doelstelling is om zoveel mogelijk te testen in de gegeven tijd. In feite heeft het team dus een inspanningsverplichting ten aanzien van de testen. Foutloze programmatuur bestaat immers niet en de ketenproblematiek maakt het onmogelijk te zeggen of een systeem of samenspel van systemen millenniumbestendig is.
Testkader
Om de voorbereidingsfase per systeem te verkorten moet het testmanagement richtlijnen opstellen die voor alle systemen gelden. Deze richtlijnen dienen als kader waarin duidelijk en expliciet wordt aangegeven wat de doelstelling is van de testen, welke verantwoordelijkheden er zijn, welke criteria gelden om de te testen functionaliteit te selecteren, en welke minimale eisen er gesteld worden. Het is belangrijk dat er een zo groot mogelijk draagvlak is voor het testkader. Voorkom dat de beste stuurlui aan wal blijven staan. Denk daarbij aan functioneel testers, kwaliteitsmedewerkers, management en stafafdelingen (auditors). Stel dit testkader vast, zodat een richtlijn ontstaat waarover iedereen het eens is en voorkomen wordt dat dezelfde discussies telkens opnieuw gevoerd worden. Trek er voldoende tijd voor uit maar beperk de doorlooptijd zoveel mogelijk (enkele weken). In dit kader staat wie wat, hoe en wanneer doet.
Wat. Baken duidelijk de kritische bedrijfsprocessen af en richt de testen uitsluitend op de functionaliteit (juistheid) van het systeem. Deze kennis is te achterhalen uit documentatie (functioneel ontwerp, gebruikershandleidingen, beschrijving van de administratieve organisatie) en uit de hoofden van experts. Criteria voor te testen functies zijn:
- Bedrijfskritisch
- Kans op falen na 2000: functies die gegevens opvoeren, wijzigen of verwijderen; functies die datums sorteren, berekenen, selecteren, interpreteren; functies die gegevens kunnen muteren in de toekomst of in het verleden.
- Mogelijkheden tot tijdig herstel bij falen van de functie
- Risico’s door complexiteit, interfaces
- Frequentie en verspreiding van het gebruik van de functie
- Beschikbare alternatieven, uitwijk, noodscenario’s bij uitval van de functie
- Relaties die de functie heeft met externe partijen (leveranciers, klanten, overheid)
- Eventuele aansprakelijkheid van/door derden
- Sociale acceptatie van fouten (imago, politieke/bestuurlijke consequenties).
Zinnige datums om op te testen zijn: 9-9-1999; 1-1-2000; 3-1-2000 (eerste werkdag); 29-2-2000 (schrikkeldag) en 1-3-2000.
Indien een functie op 1-3-2000 goed werkt, zijn er ook op andere datums na 2000 geen problemen te verwachten. Beperk daarom het aantal datums waarop getest wordt zoveel mogelijk. Per systeemdatum kan bovendien in sommige systemen de mutatiedatum gemanipuleerd worden naar het verleden of naar de toekomst.
Hoe. Bepaal de basis waarop de testen gedaan worden. Voor een initiële gegevensverzameling kan gebruik gemaakt worden van (delen van) productiegegevens, van bestaande testbestanden of van nieuwe opvoer. De testomgeving zelf moet:
- millenniumbestendig zijn (in verband met fout-analyse).
- zoveel mogelijk identiek zijn aan de productie omgeving.
- de beschikking hebben over een manipuleerbare systeemklok waarop tijdreizen met zowel systeemdatum als met gegevens mogelijk is.
- voldoende ruimte bevatten voor test-bestanden/databases (eventueel met productie hoeveelheden).
- een beschikbaarheid hebben van 7 x 24 uur per week.
- een goede ‘performance’ hebben.
- de mogelijkheid hebben snel aanpassingen in programma’s aan te brengen.
Wie: Vorm teams van techneuten en gebruikers die gezamenlijk verantwoordelijk zijn voor het vergroten van de kans op millenniumbestendigheid van het systeem. Onder leiding van een teamleider die zorgt dat de communicatie goed verloopt, wordt het testplan opgesteld. Binnen het team vindt de taakverdeling plaats voor de uitvoering van de activiteiten op basis van efficiëntie.
Schakel zo min mogelijk externe medewerkers in, tenzij zij het systeem goed kennen en beslissingen kunnen nemen of oplossingen vinden. De rol van project- of teamleider kan daarentegen uitstekend door externen worden ingevuld, omdat zij door gebrek aan inhoudelijke kennis boven de partijen staan en veel ervaring meebrengen.
Richt een beslisstructuur (bijvoorbeeld een stuurgroep) in zodat afwijkingen in aanpak of planning snel beoordeeld en geaccordeerd worden. De stuurgroep regelt snel de beschikbaarheid van resources, zowel mensen als middelen, en heeft voldoende zeggenschap om financiële beslissingen te nemen.
Wanneer. Maak een grove schatting per systeem van de testinspanning in doorlooptijd. Baseer dit op ervaringen bij regulier onderhoud; goede of betere kengetallen zijn er niet. Maak een ‘masterplanning’ waarin alle systemen een plaats krijgen. Geef per systeem een beperkte (en harde) tijdsperiode mee. Zorg dat de testomgeving tijdig gereed is, eventueel moet hardware (geheugen, processor, parallelle virtuele machines) besteld en ingericht worden.
Risico’s, voorwaarden, tips
Een aantal risico’s is te onderkennen met betrekking tot de millenniumtesten; specifieke maatregelen zijn hierbij mogelijk. Afhankelijk van de kans dat het risico optreedt en de ernst van de gevolgen, wordt besloten of en welke maatregelen genomen worden, zie tabel 2.
Gezien de risico’s en de urgentie van het millenniumprobleem is een aantal voorwaarden en tips van belang.
Het besef bij zowel management als medewerkers van het belang van het millenniumvraagstuk moet groot zijn, zodat de prioriteiten helder blijven. Houdt het doel voor ogen en geef niet toe aan allerlei argumenten om andere wegen of omwegen in te slaan.
Leg het reguliere onderhoud tijdens het project stil, zodat medewerking van alle betrokkenen gegarandeerd is.
Zorg dat de systemen millenniumbestendig blijven. Spreek bijvoorbeeld af dat na elke onderhoudsklus tot 2000 opnieuw tijdreizen uitgevoerd worden. Om de introductie van nieuwe fouten te voorkomen, is het aan te bevelen helemaal geen aanpassingen aan de systemen meer aan te brengen tussen augustus 1999 en maart 2000.
Gezien de ketenproblematiek zijn testen die over de grenzen van uw bedrijf heen gaan zinnig. Betrek zo mogelijk uw leveranciers en klanten.
Aangezien er geen 100 procent zekerheid ontstaat, moeten er ‘contingency’-plannen (noodscenario’s) zijn waarin voorzieningen voor uw bedrijf zijn opgenomen voor het feitelijk optreden van millenniumbugs ergens in de keten.
Kosten
Millenniumtesten zijn niet goedkoop. Voor een goede testomgeving kunnen hoge investeringen nodig zijn. Met name de behoefte om met meerdere systemen parallel de systeemklok te manipuleren, kan het noodzakelijk maken meerdere testmachines aan te schaffen. Mogelijk is dit te combineren met de upgrade van een omgeving of het millenniumbestendig maken van de infrastructuur.
Het vergt een enorme inspanning van uw automatiseringspersoneel en van gebruikers om de testen goed en tijdig uit te voeren. Door dit zoveel mogelijk door eigen mensen te laten uitvoeren en aan het millennium de hoogste prioriteit toe te kennen, komen andere activiteiten stil te liggen. Wanneer men accepteert dat het reguliere onderhoud aan de systemen bevroren wordt waardoor het inhuren van externe krachten niet nodig is, blijven extra personele kosten beperkt.
Drs. Marleen van Oirsouw-Aangenendt, projectmanager bij Roccade Atribit Managementservices
Tabel 1. De belangrijkste verschillen tussen het reguliere onderhoud en de aanpak voor het millennium.
Regulier Onderhoud | Millennium Probleem |
Aanpassingen beperkt tot enkele systemen. Hierdoor zijn er nauwelijks logistieke problemen; de verschillende onderhoudsreleases kunnen goed op elkaar afgestemd worden. | Alle systemen moeten gecontroleerd en aangepast worden. Grote logistieke problemen, zeker als er ook nog een onderhoudstraject loopt. |
Wijzigingen kunnen in de luwte uitgevoerd worden;controle of vragen van buiten het bedrijf met betrekking tot de voortgang zijn afwezig. | Wijzigingen worden onder grote druk uitgevoerd. Bedrijven worden door derden geconfronteerd met vragen. |
Bij niet goed functioneren van de gehanteerde strategie en werkwijze vallen er hooguit een aantal systemen uit. | Bij niet goed functioneren van de gehanteerde strategie en werkwijze vallen alle systemen uit. |
Functionaliteit van een systeem wordt aangepast; gewijzigde functionaliteit wordt getest. | Functionaliteit van een systeem blijft ongewijzigd; het functioneren van een systeem wordt getest. |
Bij het testen moet gecontroleerd worden of het systeem nu functioneert volgens de specificaties. | Bij testen moet gecontroleerd worden of het systeem rond en na 01-01-2000 goed functioneert. |
Uitloop van de planning is ongewenst maar zelden fataal. | Heeft een absolute deadline van 31-12-1999; voor die tijd moeten alle problemen opgelost zijn. In een aantal gevallen zal de deadline al ver voor die tijd liggen. |
Tabel 2. Risico’s bij millenniumtesten en de te nemen maatregelen.
Risico | Maatregel |
Er worden fouten gevonden die niets met het millennium te maken hebben. | Deze worden in het kader van dit millenniumproject niet opgelost, maar gesignaleerd in het testrapport. |
Het vinden van de oorzaak van een fout kost (te) veel tijd. | Optimale inzetting van resources met veel kennis van het systeem. Nauwkeurigheid van werken nastreven. 7 x 24 uur beschikbaarheid testmachine. Weekend/overwerk procedures. |
Beschikbaarheid resources (waaronder verwerkings- en opslagcapaciteit). | Absolute prioriteit voor millenniumproject bij betrokkenen. Instelling stuurgroep op directie niveau. |
Afhankelijkheden tussen systemen. | Begrenzingen scherp stellen Eventueel enkele integrale testen uitvoeren. |
Trage besluitvorming. | Verantwoordelijkheid zoveel mogelijk binnen teams. Duidelijke eisen en randvoorwaarden meegeven. Snelle beslisstructuur voor afwijkingen. |
Onvoldoende kennis van een systeem aanwezig. | Inzet eigen personeel, zodat kennis niet verloren gaat. |
Niet goed functionerend configuratie- en versiebeheer (software en hardware componenten). | Regulier onderhoud aan software en hardware bevriezen. |