Eind vorig jaar besloot de Eerste Kamer tot afschaffing van de omroepbijdrage. Al in januari van dit jaar vonden de eerste terugbetalingen plaats. Deze maand krijgen de laatste mensen hun geld terug. De snelheid van terugbetaling is te danken aan een goed uitgeruste testomgeving waarmee gestructureerd en herhaalbaar testen mogelijk is, aldus twee deskundigen.
Op 21 december 1999, omstreeks 14.30 uur, besloot de Eerste Kamer tot afschaffing van de omroepbijdrage, met als gevolg dat de Dienst Omroepbijdragen (DOB) per 1 januari 2000 zou ophouden te bestaan. Dezelfde dag, om 15.00 uur, draaide de programmatuur die voor alle geregistreerden (bijna 7 miljoen particulieren en bedrijven) uitrekende welk bedrag men terug zou krijgen of nog moest betalen.
Begin januari 2000 startte de DOB met de verzending van de eerste groep van 2,1 miljoen brieven aan particulieren. Geregistreerden die een bedrag tegoed hadden van de DOB ontvingen een restitutienota, geregistreerden die nog een bedrag moesten betalen ontvingen een slotnota.
Eind januari 2000 waren de eerste terugbetalingen gedaan die behoren bij de eerder deze maand verzonden restitutienota’s ter grootte van in totaal ongeveer 140 miljoen gulden. In februari en maart is deze actie herhaald voor de nog resterende terugbetalingen.
Voor de zakelijk geregistreerden is in januari 2000 aparte programmatuur gedraaid, die ervoor heeft gezorgd dat ook voor hen nota’s zijn verzonden en eventuele uitbetalingen zijn uitgevoerd.
Indien de Eerste Kamer de afschaffing van de omroepbijdrage op 21 december had afgestemd, dan was daarna het reguliere productieproces voortgezet, en waren de nota’s voor de maand januari 2000 alsnog gewoon verzonden. Tot op het allerlaatste moment is de programmatuur in staat geweest om zowel het scenario van ‘afschaffen’ als het scenario van ‘doorgaan’ uit te voeren en het daarbij behorende bedrijfsproces adequaat te ondersteunen. Dat het scenario ‘doorgaan’ reëel was, is gebleken uit de stemverhouding in de Eerste Kamer (39 stemmen voor, 30 stemmen tegen) en de berichtgeving in de kranten in de morgen van dinsdag 21 december, waarin werd aangegeven dat het wetsontwerp het vermoedelijk niet zou gaan halen.
De start
Vanwege de trage politieke besluitvorming (het Kabinetsbesluit tot opheffing dateert van 25 juni 1999, het besluit van de Tweede Kamer van 25 november 1999) gaat het project tot onderzoek en voorbereiding van de afschaffing van de omroepbijdrage op 1 juli 1999 van start, minder dan 6 maanden voor 21 december 1999 (de datum die later de deadline voor het project bleek te zijn).
De feitelijke technische voorbereiding start echter pas op 1 september 1999, als voldoende menscapaciteit op de softwareontwikkel en -testafdeling (in verband met het toen lopende millenniumproject) beschikbaar komt. De ‘afschaffingstrategie’ (op welke wijze moet de terugbetaling worden uitgevoerd?) is op dat moment grotendeels bekend en is uitgewerkt in een viertal mogelijke scenario’s.
De doorlooptijd van het ontwikkel-, bouw- en testtraject (in een mainframe-omgeving) is dan minder dan vier maanden, met alle risico’s van dien, mede versterkt door het feit dat een groot deel van de feitelijke uitvoering omstreeks de millenniumovergang moet plaatsvinden.
Toch is het vertrouwen groot. Testen hebben aangetoond dat het systeem, ondanks de millenniumovergang, vlekkeloos zou moeten kunnen blijven werken. Ook toonden ze aan dat de saldoberekeningen van zeven miljoen geregistreerden correct zijn en dat het systeem een volumevergroting van enkele van de processen met meer dan 2000 procent zonder haperen zou kunnen overleven. Gedurende de ‘normale’ productie (dat wil zeggen, vóór de afschaffing van de omroepbijdrage) was er namelijk sprake van ongeveer 750 restitutiebetalingen per maand. In februari 2000 waren dat er bijna 2,3 miljoen restitutiebetalingen (januari kende 1,9 miljoen restituties, maart ongeveer 1,3 miljoen).
Ruim een week voor het feitelijk draaien van de programmatuur op 21 december 1999 is reeds bekend:
- hoeveel tijd het systeem nodig heeft voor het maken van de slotberekeningen;
- hoe groot het aantal slotnota’s is en hoe hoog het bedrag aan vorderingen op deze nota’s zal worden;
- hoe groot het aantal terugbetalingen (restituties) is en welk bedrag in totaal moet worden terugbetaald;
- welke (typen) geregistreerden bij de berekening tot problemen zullen leiden;
- dat de geplande wijze van terugbetalen (in de maanden januari, februari en maart 2000) technisch en functioneel haalbaar is.
Historie DOB-testsysteem
Zo’n 2,5 jaar geleden, in het najaar van 1997, is een aanvang gemaakt met de ontwikkeling van het DOB-testsysteem. Aanleiding daarvoor was de geplande oplevering van een sterk vernieuwde versie van het bestaande systeem dat wordt gebruikt voor de registratie van kijkers en luisteraars, het opleggen en versturen van heffingen en het bewaken van de betalingen. Besloten is tot het opzetten en uitvoeren van een gestructureerde wijze van testen, mede omdat in de voorafgaande periode het testen niet goed uitgevoerd was, hetgeen leidde tot productieproblemen na de ingebruikname.
Met het oog op de komst van het millennium en de euro besloot men om te kiezen voor een herhaalbare wijze van testen. De keus viel op de testmethode van CMG:Cast (tegenwoordig Testframe), waarbij gebruik wordt gemaakt van de testtool Winrunner. Uitgaande van deze materialen en door toepassing van nieuwe concepten en structuren, is het testsysteem in 2,5 jaar uitgegroeid tot een vrijwel volledige schaduwomgeving van de productieomgeving. Inclusief relaties met de (test)buitenwereld (bijvoorbeeld de testomgeving van de Gemeenschappelijke Basis Administratie (GBA) en het betalingencircuit van Interpay).
Het principe van het testsysteem is eenvoudig van opzet. In MS Excel wordt met behulp van een beperkt aantal eenvoudige commando’s (‘actiewoorden’ in Testframe-termen) en bijbehorende waarden een testscript opgezet van een test die moet worden uitgevoerd. Dit testscript wordt via de testtool Winrunner aangeboden aan de te testen applicatie (op het mainframe). De testtool zorgt ervoor dat de test wordt uitgevoerd. Via een report wordt door de testtool aangegeven of de test correct is verlopen. Indien er fouten worden geconstateerd, dan geeft de tool hiervan een melding in het rapport. Dit rapport moet vervolgens worden beoordeeld door de testanalist.
Vertrekpunt voor de ontwikkeling van een testscript is bijvoorbeeld een fo (functioneel ontwerp), een rfc (request for change) of een pro (probleem). Uit deze documenten worden testcondities gedestilleerd. Testcondities zijn uitspraken in de vorm van stellingen (‘hypotheses’) waaraan het systeem (het te testen object) moet voldoen. Met behulp van bedrijfsregels wordt vervolgens een zogenaamd conceptcluster gemaakt. Dit is een testcluster, beschreven op een zodanig abstractieniveau dat een functioneel beheerder of procesdeskundige dit kan begrijpen en beoordelen op juistheid. Na goedkeuring wordt het conceptcluster verder uitgewerkt met behulp van de actiewoorden tot een testscript. Dit testscript (in MS Excel) wordt vervolgens direct aangeboden aan de testtool.
Door deze wijze van werken en structureren is er een logisch en sterk verband ontstaan tussen ontwerp en test, en wordt de kwaliteit van de test gewaarborgd door de controle van de beheerder of procesdeskundige. Het proces dat tot concrete testgevallen leidt, is inzichtelijk en controleerbaar.
De testen die in het begin van de testomgeving werden uitgevoerd, hadden een beperkte kracht en reikwijdte. Deze testen werkten op slechts één database met een beperkt aantal gevallen en slechts op één moment in de tijd (de systeemdatum), waren alleen gericht op on-line functies (schermen) en hadden geen verbindingen met de buitenwereld.
Latere ontwikkelingen hebben ervoor gezorgd dat het testsysteem in staat is om te werken met verschillende databases als basis voor de uit te voeren testen (via het actiewoord: ‘laad database’). Met grotere aantallen, op meerdere momenten in de tijd (actiewoord: ‘zet systeemdatum’) en naast online functies, ook gericht op batch-functies en externe functies (actiewoord: ‘runjcl’). Verder is de testomgeving in een later stadium zo gebouwd dat deze in staat is om lijstwerk te controleren (bijvoorbeeld de lijsten die door een afdeling Interne Controle worden gebruikt om productiecontroles uit te voeren).
Hierdoor is een testsysteem ontstaan dat de technische ondersteuning van het volledige primaire bedrijfsproces kan simuleren, indien gewenst over een periode van meerdere maanden. Door (gecontroleerd) de systeemdatum te wijzigen hoeft een test over een periode van enkele maanden in dit geval niet langer dan enkele uren te duren. Het testscript in MS Excel geeft aan de engine aan welke test, op welke wijze en met welke data uitgevoerd moet worden. Vervolgens verzorgt de engine de volledige afhandeling en sturing van de test, zowel op online-niveau als op het niveau van het opstarten van jobs. Job-logs worden bewaard, en de testtool beoordeelt of de jobs correct hebben gedraaid.
Automatisch gestuurde testomgeving
Door bovengenoemde ontwikkelingen werd het testsysteem steeds minder een systeem dat door eindgebruikers kon worden gebruikt voor het uitvoeren van acceptatietesten. Het testsysteem was oorspronkelijk wel bedoeld voor testen door eindgebruikers, maar de ontwikkelingen zorgden ervoor dat er steeds meer overall-kennis van de bedrijfsprocessen noodzakelijk was om de complexe testen uit te voeren. Deze kennis was beschikbaar bij de functioneel beheerders van het systeem en werd gaandeweg het project opgebouwd bij de leden van het testteam. Anderzijds bouwde juist het testsysteem vanuit de vele simulaties steeds meer functionele kennis op.
De nieuwe programmatuur, bestemd voor de afschaffing van de omroepbijdrage, werd geplaatst en getest binnen een mogelijk afschaffingscenario. Deze programmatuur was reeds technisch getest door medewerkers van het bouwteam.
Scenario twee, een van de vier scenario’s die was beschreven in het projectplan van augustus 1999 en dat uitgaat van een beslissing van de Eerste Kamer tussen 6 december en 31 december 1999, bleek gerealiseerd te worden. Dit scenario is (zowel in gedeelten als in het geheel) in de weken voorafgaand aan 21 december 1999 op het testsysteem getest, waarbij de werkelijke en relevante systeemdata (waaronder 21/12/99, 23/12/99, 31/12/99, 01/01/00, 07/01/00) zijn gebruikt.
De volledige besturing van de testomgeving is geautomatiseerd en wordt gestuurd door de testtool die daarin gebruik maakt van de informatie uit het testscript. Dat wil onder meer zeggen dat databases automatisch worden geladen, en er automatisch wordt geswitcht tussen online omgeving en batch-omgeving. Verder wordt de batchprogrammatuur opgestart vanuit de testtool en wordt de invoer van testdata op de schermen van het te testen systeem door de testtool uitgevoerd met behulp van de informatie uit het testscript. Een systeemdatum wordt vanuit de testscript gezet, en alle datumafhankelijke tabellen worden automatisch aangepast.
De controle van de reacties van het te testen systeem wordt geregistreerd en weggeschreven naar diverse rapporten (waarbij tevens gebruik wordt gemaakt van de informatie die het mainframe oplevert gedurende de uitvoering van de testen, zoals bijvoorbeeld job-logs)
Deze automatische opstart en uitvoering van testen biedt de mogelijkheid om testen gedurende 24 uur per dag uit te voeren (aangenomen dat het te testen systeem en de benodigde omgevingen continu beschikbaar zijn).
Voor de millenniumtesten van het registratie- en heffingensysteem zijn omstreeks 110 testscripts gemaakt, die alle onafhankelijk van elkaar kunnen draaien. Het draaien van al deze scripts kost ongeveer 450 uur. In verband met de afschaffing van de omroepbijdrage zijn ruim dertig testscripts gemaakt. Het draaien van deze testen kost in totaal ruim 100 uur.
Tijdens de nadere invulling van het afschaffingscenario met (operationele) acties is enkele malen gebruik gemaakt van de, uit testen en simulaties afkomstige informatie om bepaalde beslissingen te nemen. Het plannen van de batch-runs, het behandelen van de mislukte restitutiebetalingen en de planning van de uitbetaling van de teveel geïnde omroepbijdrage, zijn vooraf in het testsysteem gesimuleerd. Mede op basis van deze informatie is de uiteindelijke werkwijze vastgesteld.
Dankzij het uitvoeren van testen en simulaties bestond er reeds voor de definitieve afschaffing een goed beeld bestond over de verschillende stappen die tijdens de afschaffing genomen moesten worden. Het feit dat volledige productieprocessen over een langere periode gesimuleerd kunnen worden (online en batch in één en dezelfde test) betekent dat de reacties van het systeem tijdens de ‘echte’ afschaffing konden worden voorspeld en desnoods bijgestuurd. De kans op fouten tijdens de echte afschaffing werd daarmee geminimaliseerd.
Verbetering kwaliteit
Juist door een goed uitgeruste testomgeving met faciliteiten is de Dienst Omroepbijdragen in staat geweest om te voldoen aan de wensen van de Tweede Kamer, die onder andere stelde dat uitbetaling van de teveel geïnde omroepbijdrage in het eerste kwartaal van 2000 moest plaatsvinden. Dit ondanks het feit dat de uitvoering plaatsvond in de periode van de millenniumovergang en er zowel relatief als absoluut weinig voorbereidingstijd beschikbaar was om de computersystemen aan te passen.
De resultaten van de DOB-Testomgeving hebben aangetoond dat gestructureerd en herhaalbaar testen niet alleen mogelijk is, maar ook aanzienlijke kwaliteit- en efficiëntie- verbetering oplevert van zowel het testtraject op zich als het gebouwde systeem. Daarnaast zijn de structuur en inrichting van de testomgeving, inclusief de ontwikkelde procedures voor kwaliteitsborging, toepasbaar gebleken voor verschillende typen testen (bijvoorbeeld millennium, simulatie en functionele testen).
Karel de Bakker, projectleider Abkm Program Management, en Gert van Gijzen (ex-Dienst Omroep Bijdragen, tegenwoordig Belastingdienst)