Door René Hartman

In zijn artikel Bouw een Betere Testbibliotheek ¹, dat in het vorige nummer van BlueWell Magazine verscheen, beschrijft David Mount hoe met behulp van Query/400 en een paar eenvoudige OS/400 opdrachten een testbibliotheek kan worden opgezet. In het voorbeeld zet hij de te muteren data samen met het aangepaste of nieuw ontwikkelde programma in de testbibliotheek, waarna hij deze bibliotheek ten behoeve van de test boven de productiebibliothekenlijst plaatst. Dit laatste levert volgens mij echter onaanvaardbare risico's op, omdat op deze wijze heel gemakkelijk productiedata verminkt kunnen raken.


De Zaken lopen mis
Het gepresenteerde scenario zal bijna onvermijdelijk tot grote problemen leiden. Doordat David Mount een eenvoudig scenario schetst, ligt het voor de hand dat onervaren lezers dit als startpunt gaan gebruiken voor hun testprocedures. Maar zelfs ervaren testers, die testdata en testprogrammatuur bovenop productiedata plaatsen en die daarbij volledig vertrouwen op de juiste bibliotheeklijst, lopen een grote kans dat er uiteindelijk corruptie van de productiedata optreedt. Veel applicaties manipuleren hun bibliothekenlijst namelijk dynamisch door middel van data area's of werken zelfs met hardgecodeerde bibliotheeknamen. Hierdoor bestaat het risico dat de testbibliotheek op een bepaald moment niet langer bovenaan de lijst staat. Op dat moment lopen de zaken verschrikkelijk mis.

Als men een nieuw programma test, dat los van de applicatie kan draaien, is de kans op ongelukken waarschijnlijk minder groot. In deze situatie kan men echter beter een kopie maken van alle door het programma gebruikte bestanden en dat programma los van productiedata testen. Wat ik wil benadrukken is dat geen enkel programma getest zou moeten worden op een omgeving waarin zich productiedata bevinden. Daarbij maakt het niet uit, of het programma al dan niet geacht wordt alleen te lezen.


De Macht der Gewoonte
In mijn optiek bestaat een goede testomgeving uit een volledige kopie van de productieomgeving, zij het met een representatieve subset van de data om de omvang acceptabel te houden. Deze testomgeving beveiligt men vervolgens zodanig, dat een productiegebruiker niet bij de testomgeving kan, en een testgebruiker niet bij de productieomgeving.

Onlangs ervoer ik welke rampen er gebeuren wanneer deze richtlijnen niet in acht worden genomen. Een ervaren gebruikster specificeerde tijdens het testen van een nieuwe versie van een applicatie uit gewoonte een productiebibliotheek, en boekte daarmee ineens een productiebedrijf weg naar een testomgeving. Dit werd gelukkig bijtijds ontdekt, zodat gevolgschade uitbleef. Indien er gescheiden autorisaties waren geweest voor productie- en testomgevingen, zou deze gang van zaken evenwel uitgesloten zijn geweest.

Een andere vergissing die voor de hand ligt, betreft een programmeur die een verkeerd record format op een update regel zet, en zo onbedoeld een verkeerde file probeert bij te werken. Denk hierbij aan de CUS file in het voorbeeld van David Mount. Het feit dat men beoogt om CUS alleen te lezen is niet voldoende. Als we vooraf weten dat een programma zich zal gedragen zoals bedoeld, hoeven we immers niet meer te testen!

Hoewel het veel tijd en moeite kost om een goede, representatieve en consistente subset van een productieomgeving te maken, zijn we er daar niet mee. Men zal de testomgeving ook moeten onderhouden om het representatieve karakter voor productie te handhaven, en daarmee de kwaliteit van de testresultaten. Daarbovenop komen nog de change management aspecten van de te testen software: zorg dat je de correcte sources gebruikt, zorg dat je weet welke versie van het programma wordt getest, enzovoort. Dit lijkt gemakkelijker dan het is, zeker in een omgeving met verscheidene programmeurs die samen aan een project werken.

Het ten behoeve van her-testen terugzetten van de originele dataset is een tamelijk simpele actie. Op het moment dat de testomgeving af is, dus inclusief autorisaties etcetera, zet men deze op tape of in een savefile, afhankelijk van de omvang en de beschikbare vrije ruimte. Wil men na softwaremodificaties opnieuw gaan testen, dan wist men simpelweg de bestaande testomgeving, waarna men de "schone" set van tape terugzet. Overigens ontstaan er wel problemen wanneer wijzigingen nodig zijn in de database lay-out als gevolg van nieuwe functionaliteit. Ook zullen de testdata langzaam verouderen. Dit is niet noodzakelijkerwijs slecht, maar men dient zich daarvan wel bewust zijn.


De Reactie van David Mount
In een e-mail aan David Mount maakte ik mijn bezwaren tegen zijn aanpak kenbaar. Ik gaf aan dat hij de consequenties heeft onderschat van een gemakkelijk te lezen artikel over een complex onderwerp. David Mount was zo vriendelijk om te reageren, maar zijn antwoord heeft een tweeslachtig karakter. Enerzijds geeft hij aan dat er omgevingen denkbaar zijn waarin het niet realistisch is om een complete testbibliotheek te bouwen vanwege de omvang van de bestanden. Tegelijkertijd bevestigt hij het nut van het bouwen van subsets van dat soort bestanden.

Volgens David Mount bepaalt de omgeving uiteindelijk hoever een tester moet gaan bij het opzetten van een testbibliotheek. Hij haalt een voorbeeld aan van een rapport dat geschreven wordt op basis van data uit twintig bestanden. In die situatie lijkt het hem nauwelijks zinvol om van deze bestanden eerst een testset samen te stellen, enkel en alleen om het rapport te testen. Inderdaad zou in een dergelijk geval het risico voor productiedata relatief klein zijn, maar dat is niet het voorbeeld uit het artikel. David Mount erkent dat veel systemen dermate complex zijn dat niet eenduidig valt vast te stellen, welke bestanden zullen worden aangepast, zodat de tester gedwongen wordt ook de twijfelgevallen te kopiëren. Het is dan echter weer de tester die bepaalt wat twijfelgevallen zijn, met het risico dat hij bestanden over het hoofd ziet. Echt veilig is dus alleen een complete, afgescheiden testomgeving.

Tenslotte schrijft David Mount dat hij vooral een discussie op gang wil brengen over de technieken die bij testen gebruikt dienen te worden. Een ervaren professional kan het artikel daarbij als startpunt gebruiken. Mijn punt is nu juist dat het gevaar bestaat dat een onervaren tester het artikel als startpunt gaat gebruiken, met alle gevaren van dien. Ervaren professionals zullen juist een andere aanpak kiezen, omdat zij weten welke gevaren er kleven aan de beschreven methodiek.

Automatisering is voor bedrijven slechts een stuk gereedschap om meer greep te krijgen op wat er gebeurt binnen het bedrijf en in de markt. Als de informatie in het systeem onbetrouwbaar wordt, wordt dit gereedschap onbetrouwbaar. En net zoals een beschadigde  cikelzaag dodelijk kan zijn, kan beschadigde informatie een bedrijf in grote problemen brengen.


De eerste Vrucht van een Discussie
Testen wordt veelal beschouwd als een noodzakelijk kwaad, dat uitsluitend kosten met zich meebrengt. De praktijk van alledag leert echter dat onvoldoende testen uiteindelijk tot hogere uitgaven leidt als gevolg van productieverlies door niet tijdig ontdekte fouten in de applicatie. Het vervelende is alleen dat men vooraf nauwelijks kan inschatten wat deze kosten zullen zijn, zodat men lastig een goede kosten/baten analyse kan maken met betrekking tot testen. De intentie van David Mount om een discussie over dit onderwerp op gang te brengen is dan ook lovenswaardig. Het heeft in ieder geval al tot een eerste resultaat geleid.


René Hartman heeft 22 jaar ervaring in de IT, onder andere als PC- en AS/400-programmeur en als systeemarchitect. Elf jaar geleden richtte hij R.H. Hartman Automatiserings Consultancy op, dat zich richt op ondersteuning van en advies aan AS/400- en iSeries-gebruikers. U kunt hem bereiken op rh.hartman@hac-maarssen.nl.