Op jouw to do lijstje van vandaag staat een wijziging aan te brengen in systeem X. Ergens in je achterhoofd gaat een lampje branden. Deze wijziging moet je eerst testen. Maar jouw to do lijstje is lang. En de dag te kort. Het is maar een kleine wijziging. Je drukt op 'update'. Dan komen de eerste meldingen binnen en staat er een collega aan je bureau. Kak! Die kleine wijziging had een grotere impact dan je dacht...
Testen doe je in een testomgeving. Klinkt logisch toch?
Toch zien we vaak dat wijzigingen getest worden in een productieomgeving of spannender: soms zien we dat wijzigingen helemaal niet getest worden, maar gewoon worden geïmplementeerd in de productieomgeving. "Het is maar een kleine wijziging, dus dat komt wel goed". Maar soms kan het testen van een kleine wijziging in de productieomgeving een grotere impact hebben dan we van tevoren hadden bedacht.
Productieomgeving vs. Testomgeving
De productieomgeving is de omgeving waar jouw eindgebruiker in werkt. Organisatieprocessen draaien hierin en gegevens stromen door deze productieomgeving heen. Aan het eind van de rit worden er waarschijnlijk ook acties uitgevoerd en beslissingen genomen op basis van de data die uit de processen rolt.
De testomgeving is een soort speeltuin. Je mag van alles proberen en uitproberen hoe dingen werken. Het is een plek om fouten te maken, te proberen en om te rommelen.
Je kan er ook ontdekken welke mogelijkheden er allemaal binnen je systeem zijn. Idealiter is de testomgeving een duplicaat van je productieomgeving. Zo kan je pas echt testen welke invloed de wijzigingen hebben. Hierbij mogen gerust fouten worden gemaakt, omdat de testomgeving in principe losstaat van alle productieprocessen.
Impact van het testen van een wijziging in de productieomgeving
Ken je het gezegde "garbage in, garbage out?" Daarmee bedoelen we dat alle gegevens die het proces of systeem in gaan, er aan het eind ook uit komen.
En als dat vervuilde gegevens zijn, levert dat ook onzuivere data op. Wanneer je gaat testen in je productieomgeving, kan het zijn dat je door jouw testsessie onjuiste gegevens in het proces stopt die er niet horen.
Stel je gaat aan de slag met het testen van een wijziging, waarbij kosten worden geregistreerd. Je test in je productieomgeving met het invoeren van kosten die niet bestaan (want het zijn testgegevens). Aan het eind van de rit wordt er door Finance een kostenrapportage gedraaid. Jouw testgegevens zijn daarin meegenomen. De kostenrapportage is dus vervuild met jouw testgegevens.
De test was klein, maar de impact groot. Soms hebben de testgegevens die je invoert in de productieomgeving meer impact op de uiteindelijke data dan je misschien verwacht had. Het kan zo gebeuren dat sturingsdata wordt vervuild door testgegevens. Daardoor kunnen er verkeerde beslissingen worden gemaakt.
Naast vervuilde data kan het testen van een wijziging in de productieomgeving ook invloed hebben op het proces. Misschien zelfs zonder dat je weet wat er allemaal gebeurt. Stel je maakt een testmelding aan en klikt op een knop om deze te versturen. Dan kan deze ‘versturen’ knop al een heel proces bevatten. Er vinden bijvoorbeeld statusovergangen plaats en misschien worden er wel nieuwe gegevens aangemaakt. Kan je het versturen dan nog wel verwijderen? En de gegevens die daarbij aangemaakt zijn, verwijder je die dan ook? Of blijven die gegevens nog ergens in het systeem hangen?
De testomgeving wordt niet gebruikt
We snappen natuurlijk dat het niet zo simpel is als "dus maak voortaan gebruik van een testomgeving". Er zijn veel redenen waarom er nog geen gebruik gemaakt wordt van een testomgeving. De testomgeving komt niet overeen met de productieomgeving. Als dat zo is, dan heeft testen geen zin. De testomgeving moet daarom regelmatig worden overschreven door de productieomgeving. Het vraagt aandacht om de testomgeving te onderhouden. Dat is vaak niet aan de functioneel beheerder, maar bijvoorbeeld aan een technisch beheerder of een systeembeheerder. Hoe meer de testomgeving afwijkt van de productieomgeving, hoe hoger de drempel om de testomgeving te gebruiken.
Het kan ook zijn dat niet de juiste mensen de juiste rechten hebben in de testomgeving of niet eens weten dat de omgeving er is. Of misschien is de testomgeving er wel helemaal niet. Je zou ervoor kunnen kiezen om een automatisch proces in te richten voor het overschrijven van de testomgeving met de productieomgeving. Dat zou eenmalig tijd kosten. Maar hier zitten risico’s aan voor je testproces. Soms wijkt de testomgeving bewust af van de productieomgeving.
Bijvoorbeeld omdat je een nieuw proces test of omdat je speelt met nieuwe functionaliteiten. Alle testelementen die jij in de testomgeving gebruikt (denk aan functionaliteiten, gegevens etc.) worden overschreven wanneer je testomgeving automatisch wordt overschreven. Dan ben je dus al je testdata kwijt en moet je weer opnieuw beginnen met inrichten én testen. In het beste geval heb je dus zelf grip op de updates van de testomgeving en richt je het proces rondom het updaten van de testomgeving zo eenvoudig mogelijk in.
In het geval van een SaaS-applicatie heb je als organisatie weinig te vertellen over het testproces, maar dan is het belangrijk dat de leverancier zorgt voor een zo eenvoudig mogelijk updateproces.
Workarounds om zuinig om te gaan met je productieomgeving
Een testomgeving goed inrichten en bijhouden vraagt aandacht. Iemand moet daar tijd (en prioriteit) voor maken en ook nog de juiste kennis hebben om dit goed te doen. De ideale situatie is natuurlijk een goed ingerichte testomgeving die een kopie is van de productieomgeving. We realiseren ons dat dit makkelijker gezegd is dan gedaan.
Wat kan je dan doen als er geen (goede) testomgeving beschikbaar is om wijzigingen in te testen en je toch zuinig om wil gaan met de productieomgeving?
Het vraagt enige creativiteit om te kunnen testen én toch voorzichtig te zijn met de productieomgeving. Wees je in elk geval extra bewust van wat je doet. Realiseer je goed welke processen er gaan lopen wanneer jij een bepaalde actie uitvoert. Daarnaast hebben we een aantal workarounds die je kunnen helpen.
- Kader je testomgeving
Het kan zijn dat je testomgeving niet overeenkomt met de productieomgeving. Richt dan een klein stukje van je testomgeving goed in, zodat dit stukje overeenkomt met de productieomgeving. Je kan zo toch het gekaderde stuk gebruiken om een wijziging te testen. Let wel op: deze workaround werkt alleen goed wanneer het te wijzigen proces zich volledig binnen dit kader bevindt. Daarom is het altijd belangrijk om eerst de impact van een wijziging in kaart te brengen. Bekijk eens onze impactmatrix. Deze matrix kan je helpen om in kaart brengen wat de impact van de wijziging op de organisatie is.
- Standaardiseren en labelen
Moet je toch testen in de productieomgeving? Zorg voor gegevens die je kan gebruiken om te testen. Gebruik testgegevens of speciale stamgegevens voor het testen. Als je dat doet is het wel heel belangrijk om deze gegevens te standaardiseren en te labelen. Door ze te labelen als testgegevens kan je ze achteraf ook weer uit de productieomgeving verwijderen. Zo houd je data zuiver.
Het standaardiseren van de gegevens zorgt ervoor dat er ook geen gegevens blijven hangen als je de testgegevens gaat verwijderen. De een voert ‘test’ in, de ander ‘testen’ enzovoort. Voor je het weet heb je toch stiekem een wildgroei aan testgegevens in de productieomgeving. Vergeet niet om gebruikers te laten weten welke de testgegevens of testfunctionaliteiten zij zouden kunnen zien. Het kan natuurlijk zijn dat zij ineens een extra keuze te zien krijgen of een extra knop. Zorg ervoor dat de gebruikers die invloed van jouw test ervaren, weten of kunnen zien dat het om een testfunctionaliteit gaat.
- Testgebruiker
De meeste applicaties bieden de mogelijkheid om een wijziging toe te passen op het niveau van de hele applicatie, een gebruikersgroep (rol) of een individuele gebruiker. Bij voorkeur zou je weg willen blijven van het gebruikersniveau, maar om een wijziging te testen kan dit juist heel handig zijn. Zorg ervoor dat je niet test met een bestaande gebruiker, maar maak een testgebruiker aan. Doe dat binnen de gebruikersgroep van de eindgebruiker, waar de wijziging invloed op heeft. Pas vervolgens de wijziging alleen toe op de testgebruiker.
Als de wijziging op applicatieniveau moet worden toegepast, dan is het belangrijk om vooraf in meerdere gebruikersgroepen te testen. Zo kan je testen zonder dat eindgebruikers hinder ondervinden van jouw test. Combineer dit zoveel mogelijk met het gebruiken van goed gelabelde testgegevens.
- Opschonen
Als je klaar bent met testen, is er nog één belangrijke stap: verwijder je testdata! Dit klinkt misschien als het intrappen van een open door, maar toch wordt het nog wel eens vergeten. En nu je je testdata goed hebt gelabeld en gestandaardiseerd, maakt dat het opschonen van deze gegevens een stuk makkelijker.
Zelf aan de slag
De workarounds uit dit artikel helpen je om toch te kunnen testen in de productieomgeving. Vergeet niet dat dit niet de ideale situatie is en dat het altijd beter is om in een testomgeving te werken. Breng het belang van een goede testomgeving dan ook onder de aandacht. Maak duidelijk welke risico's het testen in de productieomgeving met zich meebrengen en welke kansen een goede testomgeving biedt voor het innoveren en optimalisatie van de IV.
We hebben het nu nog niet eens gehad over de manier van testen. Want het goed testen van een wijziging is ook niet zomaar gedaan. En welke rol heb jij als functioneel beheerder in dat testproces? dat is iets voor een volgend artikel.
Deze blog is geschreven door Peter. Consultant bij IV experts. Ben je ook benieuwd of een baan als consultant iets voor jou is? We vertellen je meer!
Gepubliceerd in
