Testen terwijl het systeem in productie is

In vrijwel alle projecten en onderhoudssituaties vormt het testen van de opgeleverde programmatuur een probleem. De applicatie is al in gebruik en nu komt er een wijziging die de werking zal veranderen. De verandering wordt doorgevoerd terwijl het systeem in gebruik is. Slecht korte tijd (maximaal een weekend) zal het systeem zijn afgesloten om de wijziging door te voeren. Om dit te kunnen doen zetten we gescheiden omgevingen op. Minimaal 3. Een ontwikkelomgeving, een testomgeving en een productieomgeving. In veel gevallen kent men ook een vierde omgeving, de acceptatie omgeving. Dit staat bekend als de OTAP (Ontwikkel, Test, Acceptatie, Productie) straat. De aanpassing komt pas in de productieomgeving als alle wijzigingen in de andere omgevingen akkoord zijn bevonden.

De echte feedback op het systeem komt later

Bij de nieuwbouw van een informatiesysteem is het voor de gebruikersorganisatie de eerste keer dat men de schermen en lijsten van het informa­tiesysteem ziet. Hoewel de schermindelingen al via het ontwerp duidelijk waren is het daadwerkelijk omgaan met de schermen vaak nog onwennig. Dit geldt zeker voor die gebruikers die met de opgeleverde producten ook voor het eerst met een nieuwe interface moeten omgaan.

Pas na enige tijd begint de gebruiker feeling te krijgen voor de schermen en is dan pas in staat om een goede feedback op de opgele­ver­de producten te geven. Deze situatie kunnen we zien als testen met de eigen verwachting en beleving als enige referentiepunten. Pas nadat een applicatie langere tijd in gebruik is weet de gebruiker vaak goed wat hij precies wil. Bij de acceptatietesten wordt vanaf dan ook serieuzer naar het systeem gekeken. Tijdens deze testen komen vaak nog andere problemen aan het licht.

Testen en Testtypes voor het systeem

In alle gevallen blijft de gebruiker het informatiesysteem echter als blackbox benaderen. Vooruitlopend op de acceptatietest door de gebruikers moet het ontwikkelteam nog een tweetal eigen testen uitvoeren. Dit zijn de programmamoduletest (ook unittest genoemd) en de integratietest (systeemtest). Dit zijn geen blackbox testen en worden door de ontwikkelaars zelf uitgevoerd. De ontwikkelaar voert de moduletest uit en controleert of de module de juiste output geeft naar aanleiding van de input. Hierbij forceert hij vaak bewust enkele testgevallen in zijn eigen omgeving om zo alle vertakkingen in zijn module af te lopen. De ontwerper test de door de programmeur opgeleverde module in samenhang met de rest van de modules in het systeem in een eigen testomgeving. Hoewel deze omgeving minder data zal bevatten dan de productieomgeving zal er vaak een grotere verscheidenheid aan gegevens zijn. Zodoende kunnen we een groter aantal vertakkingen in de modules afgelopen.

Testplanning

Gevolg van deze grondige opzet van het testtraject is dat het aanpassen van één regel programmacode in een module van circa 2 minuten werk vele uren testwerk kan opleveren. En dan nog maar te zwijgen van de tijd die nodig is om de modules via changemanage­ment procedures naar de diverse omgevingen over te zetten.

Op deze inspanningen verkijkt men zich meestal zodat de planning een onjuist beeld te zien geeft.

Acceptatietest

Voor de oplevering van verschillende systeemaanpassingen vindt eerst een acceptatie­test door de opdrachtgever (eindgebruikers) plaats. Het testteam heeft als taak vast te stellen of de opgeleverde programmatuur werkt zoals verwacht en voldoet aan de eisen die vooraf waren gesteld. De resultaten van deze testen dienen we aan de belanghebbende afdelingen te melden. Pas na een akkoord wordt de overdracht naar de productieomgeving ingepland.

Voor een kleine aanpassing al met al een hele operatie. Het is daarom dat men meerdere aanpassingen meestal samenvoegt tot een release.

Discussieer mee op LinkedIn.