by René Ceelen,
on november 26, 2020
Testen kost te veel tijd? Echt niet…
Hoe vaak horen we niet in de wandelgangen dat het testen toch wel allemaal veel tijd kost. Waarom moet dat eigenlijk zoveel tijd kosten? Je zet de schakelaar van de lamp toch gewoon aan of uit? En als dat eenmaal werkt, dan doet die schakelaar het toch altijd. Waarom dan toch zoveel testen?
Het antwoord op deze vraag is niet eenduidig. Het eerste probleem zit hem in het feit dat veel organisaties gebruik maken van grote softwarepakketten, met een hoge complexiteit. Het tweede probleem is dat organisaties ook complex zijn door alle onderlinge afspraken, verantwoordelijkheden en rollen van medewerkers in relatie tot klanten. De combinatie van beiden is dus dubbel complex!
Eerst even naar de basis: “als-dan-anders”
Om het eerste probleem een klein beetje uit te leggen, moet ik je meenemen naar de basis van informatica. Software bestaat namelijk uit broncode. En in deze broncode heb je honderden zo niet duizenden constructies waar beslissingen worden genomen. De zogenaamde “Als-Dan-Anders”-constructies. In de basis heb je bij elke constructie drie keuzes: Als A bijvoorbeeld groter is dan B doe dan C, als A kleiner is dan B doe dan D anders doe dan E. Alleen voor dit voorbeeld heb je al een test die drie paden moet doorlopen. Daarnaast moet je met het testen vaststellen dat de input variabelen A en B ook correct zijn, omdat anders de hele constructie ongeldig is. Je kunt je voorstellen dat als een stukje software vol staat met dit soort constructies het testen “wat lastig” maakt. Moderne ERP-software kent vele duizenden beslissingen, met nog veel meer testpaden. De complexiteit neemt daarbij razendsnel toe. De invloed van een kleine release kan hierdoor enorm zijn op je dagelijkse werk.
Complexer dan code: mensen!
Het tweede probleem is van hetzelfde soort (en misschien nog wel complexer), omdat we hier te maken hebben met mensen en afspraken. In mijn filosofie zijn organisaties ook systemen. Mensen hebben verschillende rollen met verantwoordelijkheden en daartussen “hangen” afspraken. Het geheel wordt bij elkaar gehouden met wat we noemen “processen”. Door de complexiteit van deze afspraken is het ook niet vreemd dat er vele tools zijn ontwikkeld om deze processen uit te tekenen en de verantwoordelijkheden hierin vast te leggen, de zogenaamde BPM-tools. Daarbij zijn deze tools veelal uitgebreid om niet alleen de menselijke afspraken vast te leggen, maar ook in welke informatiesystemen of meer gedetailleerd in welke modules binnen deze systemen de administratie van deze afspraken vastgelegd moeten worden.
Als we dan moeten gaan testen of iets werkt (vanuit de software) en of de medewerkers hun werk ermee kunnen doen (vanuit de organisatie), zul je begrijpen dat twee van deze complexe werelden het niet makkelijker en leuker maken om te gaan testen.
De oplossing? Slimmer en eenvoudiger testen
Ik zal de laatste zijn die betwist dat testen niet veel tijd kost. Goed testen en zeker vanuit de technische kant is een vak en doe je er niet even bij. Maar je kunt het testen wel slimmer en eenvoudiger maken, waardoor het ineens minder tijd kost. Belangrijk is om constant het doel van testen voor ogen te houden: zo efficiënt mogelijk tijd investeren aan de voorkant om aan de achterkant veel tijd te besparen, die we anders kwijt zouden zijn met het herstellen van fouten na live-gang.
Wij richten ons op functionele gebruikerstesten om met name vast te stellen of de organisatie hun werk ermee kan doen. En het zij-effect is dat indien de organisatie hun werk er niet mee kan doen, direct wordt gekeken of dit aan de software ligt of aan de organisatie zelf.
Ik hoor nog regelmatig stellingen, zoals “We hebben wel getest, maar niet zo gestructureerd!” of “Ik heb wel een paar medewerkers gevraagd ernaar te kijken, maar die hebben het zo druk!”.
Bij dit soort stellingen vraag ik me af wat nu precies de woorden betekenen. Wat zouden we bedoelen met “we hebben wel getest” en nog specifieker “niet gestructureerd” of de combinatie van beiden. Of “die hebben het zo druk!”…
Weinig tijd? Kies voor structuur én risico
Stel dat er wel getest is, hoe zien de testresultaten er dan uit of op basis waarvan is dan getest. Ook hier geldt dat investeringen aan de voorkant, zich terugbetalen aan de achterkant. En gestructureerd testen is niks meer en minder dan testen vanuit een ontwerp. En dit testontwerp hoeft geen 20 pagina’s dik te zijn. Als je niet gestructureerd test, kies je ervoor om een willekeurige greep in al die duizenden beslissingen van de software te testen. Een soort trial-and-error. De kwaliteit is nog onduidelijk en het besluit om in productie te gaan of niet zal gebaseerd zijn op onderbuikgevoel of yin-yang.
Het maken van een testontwerp kan weken in beslag nemen, maar als je weinig tijd hebt en toch enkele testgevallen wilt doorlopen, pak je die testgevallen die het hoogste afbreukrisico hebben. Het bepalen waar de hoogste risico’s zitten is eenvoudig te doen door langs enkele personen te lopen of bij het koffiezetapparaat te vragen waar voor hen de pijn het grootst is. Als we dan binnen het uur een risicogebaseerd testontwerp hebben gemaakt, heb je ook direct de basis voor structuur.
Testontwerp, testcases en resultaten in één dag!
Dan nu de testgevallen, waarvoor een ander blog op onze site 7 tips voor goede testgevallen bij ERP staat. Ook hier kun je verschillende niveaus hanteren van ontwerpen. Je kunt zoals hierboven omschreven alle paden langslopen of je begint aan een paar medewerkers te vragen wat in essentie zij zouden testen als ze maar 30 minuten mochten besteden. Gegarandeerd krijg je hier de belangrijkste teststappen benoemd en heb je een risico gebaseerd testontwerp met alleen de meest belangrijke testgevallen. Stel dat dit 5 testgevallen zijn met ieder 7 teststappen. Voor het uitvoeren van de test zouden we graag 5 medewerkers van de klantenservice laten testen en hiervoor hebben ze ieder 30 minuten de tijd gekregen.
Het inrichten van dit testtraject in de speciaal hiervoor ontwikkelde TestMonitor kost de coördinator 15 minuten en het daadwerkelijk uitvoeren van de test kost iedere medewerker in dit voorbeeld maximaal 30 minuten.
Het resultaat is verbluffend! Je hebt aan het einde van de dag dus 5 * 7 * 5 = 175 testresultaten. Deze testresultaten vertellen je veel over de kwaliteit. Afhankelijk van deze resultaten kun je enkele issues maken en in een hertest nog enkele testgevallen aanbieden aan een kleinere groep testers. De totale tijdsinvestering is maximaal 1 dag en heb je niet alle kwaliteit inzichtelijk, maar in ieder geval wel de meest cruciale onderdelen.
Conclusie: minimale voorbereiding bespaart tijd en frustratie na live-gang
Conclusie is dat testen veel tijd kost, omdat het testen complex is. Maar niet testen betekent meer tijd over aan de voorkant, die je met een beetje pech in een veelvoud kwijt bent aan de achterkant met het herstellen van fouten na live-gang. Met deze vorm van risico gebaseerd testen, maak je een eenvoudig begin en heb je ook daadwerkelijke resultaten tegen een minimale tijdsinvestering. Als je dan nog speciaal ontworpen software hiervoor gebruikt, kun je sneller analyses maken en heb je alles beschikbaar voor hergebruik.
