Het ‘jaar 2000’-probleem te lijf gaan met de methode van ‘achteraf testen’ is een dure oplossing. Michael Feord bepleit een structurele aanpak waarbij iedere toepassing al in de eerste fasen van het project wordt voorzien van een ’teststraat’. Hierdoor is enerzijds de investering in testen tijdens het totale ‘jaar 2000’-project terug te brengen en worden anderzijds opnieuw te gebruiken testsets ontwikkeld.
Ondanks het feit dat het ‘jaar 2000’-probleem in allerlei publikaties als uniek wordt voorgesteld, is er in feite sprake van een grootschalige vorm van een bekend vraagstuk. Denk bijvoorbeeld aan systeemconversies naar aanleiding van de invoering van de postcode, de recente wijziging van de telefoonnummers en de aanstaande invoering van de euro. Ook de bedrijfsspecifieke conversies horen in dit rijtje thuis. Vanwege de kosten en moeite die er mee gepaard gaan, hikken veel bedrijven al jaren aan tegen het vernieuwen van de oudste onderdelen van hun systemen. Dat geldt ook voor het jaar 2000-probleem. Met dit verschil dat déze conversie zich niet laat uitstellen en aan geen enkele organisatie ter wereld voorbijgaat.
Vijf voor twaalf
Op minstens één punt zijn alle publikaties het eens. Het is hoog tijd om maatregelen te treffen. De systemen die organisaties in gebruik hebben, zijn niet van vandaag op morgen aangepast. Bovendien openbaart het probleem zich voor veel organisaties niet pas op 1 januari 2000, maar al (veel) eerder. Natuurlijk zijn er bedrijven die de problemen al jaren geleden hebben zien aankomen en op tijd maatregelen hebben getroffen. Toch blijkt regelmatig dat er ook bij deze bedrijven in hoeken en gaten allerlei ‘vergeten’ systemen draaien, die nog niet op het jaar 2000 zijn toegesneden. Het merendeel van de organisaties – voorzichtige schattingen spreken van meer dan 85 procent – is echter nog nauwelijks in actie gekomen. Zij zullen massaal een beroep doen op een beperkte groep van deskundigen, die in staat worden geacht het probleem voor hen op te lossen.
Gebrek aan testtools
De systemen die onze samenleving ondersteunen zijn zo star geworden, dat zij veel duur maatwerk vereisen. Dit is met name te wijten aan het feit dat er doorgaans te weinig is geïnvesteerd in test- en implementatietechnologie. Vanaf het begin van het IT-tijdperk hebben de leveranciers zich vrijwel uitsluitend gericht op het verkopen van nieuwe toepassingsgerichte technologie. De hoge winsten uit de beginjaren, het beperkte aantal toepassingen en de stabiele aard daarvan betekenden geen stimulans voor de ontwikkeling van test- en implementatieprodukten. Tien à vijftien jaar geleden begonnen de winstmarges te dalen en groeide de aandacht voor kwaliteit. Toen was er echter al een cultuur ontstaan waarin kinderziekten in nieuwe toepassingen acceptabel waren. Men was blind voor de kosten die gebreken op de lange termijn met zich mee zouden brengen. Het gebrek aan testtools verklaart waarom de meeste tests handmatig en ongedocumenteerd worden uitgevoerd. Door het ontbreken van gestructureerde testtechnieken vinden de tests bovendien ongestructureerd en onbeheerst plaats, versnipperd over de gehele organisatie. Vanwege de hoge kosten worden kleine aanpassingen op systemen slechts ten dele getest, hetgeen leidt tot ongeveer de helft van alle produktie-storingen. Eén onderdeel van een systeem wordt aangepast en deels getest, terug in produktie gezet, en veroorzaakt een onverwachte fout in een ander onderdeel van het systeem.
Procedures
De meeste publikaties over het jaar 2000-probleem beperken zich tot het inschatten van de omvang van het probleem (aantal programma’s maal aantal regels code maal x dollar) en tot de constatering dat het vraagstuk procedureel moet worden aangepakt. De procedure die door de ‘2000-consultants’ veelal wordt voorgesteld, bestaat uit een aantal stappen. Allereerst dient men bewust te worden van de problematiek. Vervolgens krijgen alle belanghebbenden de kans om via enquêtes en interviews hun toepassingen te inventariseren, te rangschikken en reeds bekende datumgevoeligheid alvast aan te geven. Dit leidt tot een clustering van toepassingen en tot de beginfase van het plan van aanpak.
Daarna dient er een impactanalyse te worden uitgevoerd, die de datumvelden in broncode en databestanden inventariseert evenals het aantal regels broncode. Voor het uitvoeren van de analyse werken de consultants met software-tools die speciaal voor dit doel zijn ontwikkeld. Vervolgens vindt er een detail-analyse plaats om de aard van het probleem te achterhalen. Dan volgt de feitelijke update annex conversie, waarna de nieuwe programmatuur wordt getest. Na goedkeuring moeten de programma’s en de onderdelen opnieuw in de draaiende produktie- of onderhoud-omgevingen worden geïmplementeerd. Als laatste houden nuchtere planners rekening met een fase van ‘brand blussen en rampenbestrijding’.
Geldverslindend
Deze ‘procedurele wijsheid’, waarmee ogenschijnlijk weinig mis is, staat ver af van de realiteit en is mede daardoor zeer kostbaar. Het is een nieuwe versie van hetzelfde boerenverstand dat in de afgelopen jaren heeft geleid tot talloze begrotingsoverschrijdingen in nieuwbouwprojecten. Inhoudelijk zijn alle stappen van zo’n aanpak nodig en zinvol. De structuur van de oplossing en de bijbehorende produkten en diensten tonen aan dat er vooralsnog weinig rekening is gehouden met de oorzaken van dit merkwaardige probleem.
Kenmerkend voor de kortzichtigheid is de plaats van het testen in deze aanpak. Pas na begroting, analyse en conversie komen de applicaties in aanmerking om te worden getest. De toonaangevende testmethoden van dit moment stellen daarentegen voor om reeds in fase één van een project (de inventarisatie van gebruikersbehoeften en -wensen) te beginnen met de ontwikkeling van de test. Ook is al jaren bekend dat het huidige gedrag van systemen in een zogenaamde regressietest vastgelegd behoort te worden, voordat aan een conversie wordt begonnen. Laat men dit na, dan kan er bij de testen na de conversie veel verwarring ontstaan over fouten die niet door de conversie zijn veroorzaakt.
Helaas worden deze concepten niet op grote schaal toegepast met betrekking tot de ‘jaar 2000’-problematiek. Zelfs de grote servicebedrijven die de regressie-aanpak in elke andere situatie voorstellen, leggen in het kader van de ‘jaar 2000’-problematiek de verantwoordelijkheid voor het testen bij de klant.
Ten slotte betekent de ‘procedurele aanpak’ ook een ad-hoc aanpak: het probleem wordt als eenmalig incident opgevat met een eenmalige oplossing. Dit betekent dat andere conversies zoals de ‘Euroconversie’, op geen enkele wijze profiteren van deze operatie en dat de test- en implementatie-infrastructuur op verbetering zal moeten blijven wachten.
Reductie
Afnemers van ‘procedurele’ conversieprojecten hebben nog een reden om de begrotingen goed in de gaten te houden. Vaak wordt de systeemanalyse en -conversie aangeboden met een prijskaartje dat is gebaseerd op het aantal regels broncode (mloc: million lines of code). Het is vreemd om te constateren dat er weinig wordt gezegd over expliciete methoden om het aantal mloc terug te dringen. Programma’s waarvan de laatste tijd geen gebruik is gemaakt, mogen immers buitenspel worden gezet. Grofweg gaat het om zo’n 50 procent van de mloc, bestaande uit achterhaalde, eenmalig gebruikte of op andere wijze nutteloze regels codering. Slechts een minderheid van de organisaties heeft – dank zij een gedisciplineerde en consequente change control – zicht op haar actieve produktieprogramma’s en de bijbehorende broncode. Daarom dienen jaar-2000-projecten een expliciete reduction-functie te bevatten. Ongebruikte regels codering kunnen dan alsnog worden geïdentificeerd met gebruikmaking van de audit trails van het systeem. Geen van de speciaal voor het jaar-2000 ontworpen tools houdt hiermee echter rekening.
De tweede belangrijke manier om mloc in aantallen te verminderen is door na te gaan welke delen van de toepassingen wèl en welke niet voor de eeuwwisseling gevoelig zijn. Tevens dient men te bekijken vanaf welke tijd fouten zullen gaan optreden. Omdat het ‘dynamisch systeemtesten’ onder toekomstige simulaties de enige manier is om dit te weten te komen, zal het doorsnee jaar-2000-project dit nooit nagaan. Het algemeen geaccepteerde model roept pas op het eind om systeemtesten en dan slechts voor de reeds geconverteerde programma’s. Alle toepassingen en hun mlocs worden voor de zekerheid in de grove analyse meegenomen. Daarna kan het kleine aantal programma’s zonder enige verwijzing naar datumvelden opzij worden gezet. Overige programma’s worden, ongeacht hun jaar-2000-gedrag, meegenomen in de detailanalyse. Met behulp van herhaaldelijk handmatig testen op unit- en integratieniveau worden pogingen gedaan om het gedrag van iedere toepassing te voorspellen. Meestal zal er onvoldoende duidelijkheid over de toekomst zijn, zodat een kostbare-maar-zekere oplossing zal worden aangeraden die toch alle programma’s aanpast.
Twee vliegen in één klap
Ondanks het feit dat het kort dag is, betekent het kiezen voor de methode ‘achteraf testen’ een (te) dure oplossing. Het universele karakter maakt het jaar-2000-probleem uitstekend geschikt voor een structurele aanpak, waarbij twee vliegen in één klap worden geslagen. Door iedere toepassing al in de eerste fasen van het project te voorzien van een zogenaamde ’teststraat’, wordt enerzijds de investering in testen tijdens het totale jaar 2000-project teruggebracht en worden anderzijds opnieuw te gebruiken testsets ontwikkeld. Deze sets kunnen een grote bijdrage leveren aan de grove analyse- en detailanalyse-fasen. Door de geautomatiseerde tests te herhalen onder simulaties van toekomstige jaren (door de testen een ’tijdreis’ te laten maken) is vast te stellen welke functies in welke jaren zullen falen. Geen enkel impactanalyse-tool kan die informatie leveren. Bovendien kan iedere teststraat steeds opnieuw worden gebruikt voor test- en implementatietaken in dagelijks onderhoud en voor andere toekomstige conversies.
De tools die het testproces helpen automatiseren, kunnen breder worden ingezet bij het verder automatiseren van de detailanalyse en van de conversie-activiteiten. Door deze gecombineerde toepassing van meerdere soorten testtools wordt het concept van de ‘softwarefabriek’ over het gehele project gerealiseerd.
Als concept leeft de softwarefabriek al meer dan vijf jaar. In de ‘conventionele’ aanpak van het jaar 2000-probleem wordt dit concept alleen enigszins in de allereerste grove analysefase toegepast. Met testtools voor het inzien en beheren van alle aspecten van een testomgeving kan de softwarefabriek ook worden gerealiseerd voor testen, detailanalyse, conversie en implementatie. Het gaat dan om meerdere hoog produktieve interactieve tools voor data- en programmabeheer en tools voor het automatisch diagnostiseren van systeem- en toepassingsproblemen. Het gebruik van deze tools wordt in standaard scenario’s programmatisch bestuurd met behulp van de krachtigste programmeerbare capture/playback-tools.
Automatisch testen
In de IT-wereld wordt het begrip ’testen’ veelal te eng gedefinieerd; het begrip ‘automatisch testen’ sleept een geschiedenis van negatieve ervaringen met zich mee. Als er over testtools of cast-tools wordt gesproken, heeft men het vaak alleen over de ‘capture/playback’-tool. Met deze enge definitie van testtools zijn veel projecten, die het realiseren van automatisch herhaalbaar testen tot doel hadden, gestart en mislukt. In de meeste gevallen wordt een ‘capture/playback’-tool aangeschaft en – met minieme functionele training – aan een team testers gegeven. Valkuilen zijn voorts het feit dat men veel te veel in één keer probeert op te nemen, dat er geen initiële planning is en dat iedere tester hetzelfde leerproces moet doorlopen.
Voorzien van de juiste tools en de juiste begeleiding hoeft het herhaalbaar maken van tests slechts één à anderhalf maal de kosten van een initiële test te vergen. Daarbij zorgt een pragmatische testaanpak ervoor dat de geautomatiseerde testen te onderhouden zijn en dat een goed gestructureerd testsysteem uit vele kleine testbouwstenen wordt opgebouwd.
Te weinig kennis van testtools heeft bijgedragen aan het groeiende pessimisme ten aanzien van automatisch testen. Pas wanneer testers gemakkelijk inzicht hebben in alle verschillende soorten objecten van de testomgeving, kunnen zij gestructureerd te werk gaan. Een testomgeving bevat programma’s, data, één of meerdere besturingssystemen (met database en netwerk-subsystemen) en gebruikers. Voor deze vier onderdelen van een testomgeving zijn vier groepen test- en implementatietools ontworpen.
De tools in de groep foutendiagnose (zoals Abend-AID) zorgen voor het automatisch signaleren, classificeren, analyseren en rapporteren van alle problemen die door het besturingssysteem of zijn grote subsystemen (IMS, DB2, CICS, enzovoort) worden geconstateerd.
De tools die behoren tot bestands- en gegevensbeheer vereenvoudigen het beveiligd editen, selecteren, extraheren en kopiëren van alle databestanden en databases. In één toepassing is één stuk informatie (een verkooptransactie bijvoorbeeld) altijd het beginpunt van een complex netwerk van allerlei gerelateerde stukken informatie in aparte bestanden en databases (klantennummer, produktcode, rentetabel, leverancierscode, enzovoort). Bestands- en gegevensbeheertools (zoals File-AID) kunnen ook informatie omtrent deze onderlinge relaties onder beheer brengen. Zodoende kan het kiezen van één datarecord automatisch leiden tot het mede-lokaliseren van alle samenhangende datarecords uit meerdere bronnen.
Inzicht in draaiende programma’s is noodzakelijk om tenminste twee redenen. De eerste reden betreft de volledigheid: in hoeverre worden de broncodes van een programma tijdens de test getoetst? De tweede reden betreft fouten in de logica van de broncode die tot toepassingsfouten leiden. Interactive analyse- en debuggingtools (zoals Intertest) dienen deze ‘röntgenapparaat-functies’ te bieden, maar moeten ook interfaces met foutdiagnose- en gegevensbeheertools hebben (zoals een produkt als Xpediter). Een programma blijft afhankelijk van het besturingssysteem en de data die het verwerkt. Er kan geen goed beeld van het gedrag van een programma worden gevormd als deze invloeden niet zijn na te gaan.
Automatische testtools vormen de vierde groep test- en implementatie tools. ‘Capture/playback’-tools zoals Verify staan hierin centraal. Deze groep bevat ook tools voor het beheren van alle verschillende testobjecten, zoals testplannen, scripts voor het toetsen van online gegevens en voor het automatisch besturen van een gehele testcyclus, testresultaten, enzovoort. Deze tools kunnen het werk van veel mensen in een fractie van de tijd vlekkeloos herhalen. De tools moeten dan wel op onverwachte situaties kunnen reageren, gelijktijdig gebruik gesynchroniseerd kunnen opnemen en weer in dezelfde volgorde afspelen. Net zo belangrijk – maar vaak genegeerd – is het feit dat automatische testtools perfect documentatie kunnen opleveren van zowel geautomatiseerde als handmatige tests. Een derde – ondergewaardeerd – voordeel ligt in het vermogen van deze tools (zoals Hiperstation) om de gehele testcyclus te automatiseren, inclusief het opstellen en besturen van de andere soorten testtools.
De tijdreis
Een herhaalbare regressietest op de teststraat kan met de inzet van dezelfde testtools een reis door de tijd maken. Tools van de ‘interactive analyse- en debugginggroep’ bootsen een nieuwe systeemdatum na en vangen ook ‘andere’ systeemdatums op. ‘Bestands- en gegevensbeheertools’ passen gelijktijdig de datumvelden in de testdata aan. ‘Automatische testtools’ passen datumvelden in testscripts aan en besturen het geheel. Fouten worden door ‘foutendiagnosetools’ automatisch gedocumenteerd in gescheiden bestanden per testdatum. De resultaten van de tijdreis geven aan welke functies gaan falen en wanneer dat zal gebeuren. Door al vroeg in het project ‘op reis te gaan’, worden de kosten en de resources van de detailanalyse en conversie optimaal besteed. Als de toepassing geconverteerd is, ligt de teststraat (tijdmachine) klaar voor een gedegen regressietest.
Voornemens
Misschien moeten wij het jaar-2000 fenomeen beschouwen als een glas dat half vol en niet half leeg is. In plaats van vroeg aanpassen en laat testen kunnen wij vroeg gaan testen en aanpassingen maken waar en wanneer die nodig zijn. Tegelijkertijd laten wij onze slechtste gewoontes achter in de twintigste eeuw…
Michael Feord is account manager Application Testing Tools bij Compuware B.V.