In mijn werk heb ik geregeld te maken met veranderingen. Veranderingen in processen op de werkvloer, veranderingen met nieuwe systemen of veranderingen door updates van bestaande systemen. En op één of andere manier wordt het testen van deze veranderingen onderschat of niet nodig geacht. “Er zijn al verschillende gebruikers ons voor gegaan, als er nog kinderziektes in zitten dan hadden zij die allang ontdekt“. Maar eigenwijs als ik ben, stel ik altijd een test voorafgaand aan het werkelijk gebruik zeer op prijs. En elke keer ben ik weer opgelucht, dat ik toch weer heb aangestuurd op een test. Ik wil in deze blog stil staan over de vraag waarom testen goed is.
Waarom zou ik niet testen?
Ik zie in de praktijk verschillende redenen als motivatie om vooral niet te testen.
- Er is geen tijd om te testen;
- We zijn de laatste in de rij, dus het systeem werkt toch;
- Het wordt als gedoe bestempeld om een goede test omgeving beschikbaar te stellen;
- Het systeem is een standaard oplossing en het werkt probleemloos bij anderen;
- Men weet niet hoe en/of wat te testen;
- Testen kost tijd en dus geld;
En zo zullen er nog meer redenen zijn om niet te testen. Maar toch adviseer ik juist om altijd wel te testen.
Waarom is testen wel goed?
Er zijn dus verschillende redenen (excuses) te bedenken om niet te testen. Maar waarom is testen dan wel goed? Hier kun je verschillende redenen voor bedenken. Ik licht er een aantal toe:
“Technische medewerkers zijn lui”
Technische medewerkers denken nu eenmaal anders
Ten eerste omdat de technische medewerkers die de systemen maken en beheren een hele andere kijkwijze hebben op het gebruik van de systemen, dan de gebruikers op de werkvloer.
-
If, then, else
De technische medewerkers zitten graag met hun neus achter het computerscherm. Daar is hun comfortzone en daar voeren zij hun programmeerwerkzaamheden uit. Zij denken vaak in codetaal: “If, then, else“. Met andere woorden als een gebruiker hier een vinkje aanzet, dan heeft dat ergens anders in de systemen “iets” als gevolg. Wat ik regelmatig meemaak is dat het “iets” net iets anders moet zijn volgens de gebruiker. Als gebruiker probeer je uit te leggen wat je bedoelt, waarom je een ander resultaat verwacht. En welk resultaat je verwacht. De technische medewerkers bekijken dit verhaal in tabelvorm: welke velden in welke tabel wil de gebruiker zien? Probeer elkaar dan maar eens te begrijpen.
“Technische medewerkers weten of begrijpen veelal niet wat de echte behoefte is van gebruikers.”
-
Afwijkende processen
Wat ik ook zie, is dat de technische medewerkers de processen op de werkvloer niet altijd goed inschatten. De gebruikers vinden hun werkprocessen vanzelfsprekend, zij hebben er dagelijks mee te maken. Er zit een bepaalde routine, workflow, in de processen. De medewerkers op de werkvloer kunnen héél goed zelf aangeven wat er aan het systeem verbeterd zou kunnen worden. Het is voor technische medewerkers soms lastig te begrijpen, dat iedere organisatie weer zijn eigen processen heeft. Ook al leveren die organisaties op het oog gelijke diensten.
-
Technische medewerkers zijn lui
Tot slot om een hele beroepsgroep over één kam te scheren: over het algemeen zijn technische medewerkers lui. Dat vind ik persoonlijk een goede eigenschap. Technische medewerkers proberen met zo min mogelijke inspanning het maximale resultaat te bereiken. Niks mis mee! Maar soms wordt de bocht net iets te kort genomen. Het gevolg is dat een oplossing prima werkt voor de technische medewerkers, maar net niet aansluit bij de processen op de werkvloer. Zij verlaten niet snel de veilige werkomgeving voor een bezoek aan de werkvloer bij de gebruikers. Dit heeft als gevolg dat er letterlijk afstand is tussen de technische medewerkers die de systemen beheren en de gebruikers die de systemen gebruiken. Deze afstand kan er m.i. ook voor zorgen, dat de technische medewerkers veelal niet weten of begrijpen wat de echte behoefte is van de gebruikers.
“Het is altijd goed het programmeren en testen van elkaar te scheiden.”
Iedereen kan een foutje maken
Een gebruiker ziet de voorkant van de software: schermen waarin de gebruiker gegevens kan opvragen, wijzigen, invoeren en verwijderen. Aan de achterkant van de software zijn deze “simpele” handelingen vertaald in programmeertaal. Ik benader de systemen nog altijd vanuit tabellen: een simpel overzicht van adressen van de klanten bijvoorbeeld, is op te halen in de “klanttabel”. Als er tijd wordt geschreven op de klant, dan zorgt de programmeercode ervoor, dat je vanuit een bepaald scherm én de klant kunt benaderen én tijd kunt schrijven. Het zou ook nog mooi zijn, dat als die geschreven tijd ook nog wordt gefactureerd (na goedkeuring). Een simpel voorbeeld, maar achter de schermen worden er verschillende tabellen en processen aangestuurd. In al die programmeertaal kan altijd een foutje ontstaan. Het is dus altijd goed het programmeren en het testen van elkaar te scheiden en door verschillende partijen te laten uitvoeren.
“Test je niet, dan gaan de technische medewerkers voor jou bedenken hoe jij als gebruiker zou moeten werken.”
Je moet weten hoe het systeem werkt
Door goed te testen leer je het systeem ook beter kennen en kun je als gebruiker beter de vinger op de zere plek leggen. Wat gaat goed, wat gaat niet goed en wat kan beter? In de testomgeving loop je verder geen risico loopt om iets van waarde kapot te maken, dus je kunt daar ook wat makkelijker dingen uitproberen. Je vergroot je kennis van het systeem en je helpt de technische medewerkers om het systeem nog beter te programmeren. Test je niet, dan gaan de technische medewerkers voor jou bedenken hoe jij als gebruiker zou moeten werken.
Maar wat test je dan?
Door goed te testen beperk je het risico op grote teleurstellingen zodra het systeem in het echt in gebruik wordt genomen. Maar wat test je dan? Deze vraag is niet simpel te beantwoorden. Je hebt te maken met grote en kleine updates. Grote updates worden van te voren aangekondigd, kleine updates zijn meestal voor het herstellen van bugs in het systeem.
“En intussen blijft de gebruiker met de gebakken peren zitten.”
-
Nieuwe functionaliteiten
Grote updates/releases gaan meestal gepaard met nieuwe functionaliteiten. Test deze en stel jezelf de vraag of deze vernieuwingen aansluiten bij de werkprocessen in de organisatie. Doen de nieuwe functionaliteiten eigenlijk wel wat ze zouden moeten doen? Hoe zit het met autorisatie van deze functionaliteiten?
-
Releasenotes
Ik vind het altijd belangrijk om de releasenotes bij updates door te lezen. Dan weet je als gebruiker wat je kan verwachten. Op basis van die releasenotes kun je een inschatting maken wat je moet testen. Leg je bevindingen ook vast, werkt de geboden oplossing naar wens of niet?
-
Koppelingen
Zijn er koppelingen met andere systemen? Kun je als gebruiker in een testomgeving vaststellen dat een koppeling met een ander systeem in de nieuwe update nog werkt? Je kunt hiermee het spelletje enigszins voorkomen dat je als eindgebruiker van het kastje naar de muur wordt gestuurd. Koppelingen tussen verschillende systemen zijn leuk, maar als er een kink in de kabel zit, dan ligt de oorzaak van het probleem altijd bij de andere partij. En intussen blijft de gebruiker met de gebakken peren zitten.
-
Output
Het klinkt te simpel, maar klopt de output, de rapportage, nog wel na de update? Je hoeft natuurlijk niet alle rapportages testen. Bekijk de releasenotes, waar zitten de nieuwe of gewijzigde functionaliteiten. En focus je dan op de output. Het hoeft niet altijd om de inhoud te gaan, het kan natuurlijk ook om de opmaak gaan.
“Niet iedereen is handig met computers.”
-
Out of the box
Het leukste is ook om out of the box te testen. Wat doet het systeem als je onlogische waarden gaat vullen. Accepteert het systeem dat, of krijg je een signaal van “hé dat kan niet”. Door juist onlogische waarden te gaan testen, kun je zien of het systeem enigszins “dummyproof” is ingericht. De reden dat ik dit benoem, is juist omdat er rekening moet worden gehouden dat niet iedereen handig is met computers, maar andere kwaliteiten hebben.
-
Handleidingen
Werk je handleidingen bij met de wijzigingen die een update met zich meebrengt. Deel deze handleidingen ook met je collega’s en benoem de hoogtepunten. Wat gaat beter, wat is nieuw, wat is verder veranderd en welke gevolgen heeft dat. En benoem ook wat wel is beloofd, maar nog niet is opgeleverd of nog niet naar wens functioneert. Deel deze kennis, zodat kennis in de organisatie goed is ingebed.
“Geen tijd is geen geldig excuus meer om niet te testen, maak van zorgvuldig testen een prioriteit.”
Testen nieuwe software
Bij het in gebruik nemen van een nieuw softwarepakket adviseer ik altijd te testen. Klinkt logisch, maar ook hier maak ik mee, dat de eindgebruiker vaak te horen krijgt dat “de software wel werkt” en dat “andere gebruikers er probleemloos mee om kunnen gaan” en dat “de kinderziektes er nu wel uit zijn“. Sta erop, dat een testomgeving wordt ingericht en beschikbaar gesteld en neem de tijd om te testen. Misschien sluit het systeem helemaal niet aan op de interne procedures en processen. Door te testen kun je kijken hoe de software de processen het beste kan ondersteunen. Je zult daarnaast ook aandacht moeten schenken aan de rechten binnen een systeem: wie mag wat wel en wat niet zien/doen?
Een goede voorbereiding verdient zichzelf terug
Het lijkt soms weggegooid geld en er is nooit tijd voor, maar een goede voorbereiding verdient zichzelf uiteindelijk terug! Alles wat je in een testfase tackelt, komt in de productie omgeving niet meer terug. De kosten kunnen hoog oplopen als er problemen ontstaan in de productieomgeving. Er is meestal geen weg meer terug, bijsturen is lastig. Bij gebreken is er paniek in de tent, zowel bij de softwareleverancier als bij de eindgebruiker. Voorkomen is nog altijd beter dan genezen.
Applicatiebeheer on demand
Bij mijn opdrachtgevers heb ik verschillende keren geholpen bij het testen van nieuwe en bestaande systemen. Ook tegen adviezen in heb ik in verschillende situaties erop gestaan, dat er toch een actuele testomgeving beschikbaar wordt gesteld. Met als gevolg, dat door het zorgvuldig testen er toch nog bugs en verbeterpunten naar boven zijn gekomen. De daadwerkelijke live-gang (ingebruikname) is mede daardoor redelijk soepel verlopen. Als organisatie kun je gebruik maken van deze ervaring en expertise! Geen tijd is geen geldig excuus meer om niet te testen, maak van zorgvuldig testen een prioriteit. Wil je meer over dit onderwerp weten, neem dan gerust contact met mij op.
