Misschien ken je de situatie. Berekeningen zijn binnen veel applicaties heel belangrijk. Maar als je vraagt: "Hoe werkt het? Dan kan ik het testen." is het antwoord "Deze berekening is te ingewikkeld. Die testen we niet." Het zou een zeer unieke situatie moeten zijn. Maar ik ben hem verschillende keren bij verschillende bedrijven tegengekomen.
Het probleem is, dat veel uitgebreide berekeningen bestaan uit vele schermen, velden, condities, enz. Velen hebben een deel gebouwd, met als gevolg dat niemand meer alles weet. En als er zoveel mogelijkheden zijn, hoe kan je dan ooit een goede, volledige test doen? Zeker als een groot deel van de kennis niet meer te vinden is?
Misschien zijn er mensen, die nu hopen op een magische formule, die dit mogelijk gaat maken. Om alvast die teleurstelling te voorkomen: die formule heb ik niet. Wat ik wel heb, is een methode, die het testen van dit soort berekeningen kan starten. En ervoor kan zorgen dat, elke keer als je de berekening test, je beter test dan de vorige keer. Testen van dit soort berekeningen is als met vele onderwerpen: je moet gewoon starten met wat je kan. Alles testen is nu een onbereikbaar doel. Maar elke keer meer weten en daardoor beter testen, is zeker de moeite waard. Alles wat je kan testen aan een zeer belangrijk onderdeel van je applicatie is altijd de moeite waard.
Achterhaal wat nog wel bekend is
In veel gevallen is er nog aardig wat bekend van de berekening. Denk hierbij niet alleen aan de berekening zelf. Denk ook aan de schermen, waar gegevens voor de berekening worden ingevoerd. Zelfs als men de berekening niet meer weet, weet men vaak nog vrij goed in welke schermen gegevens voor de berekening ingevoerd worden. Zelfs vaak ook welke gegevens gebruikt worden. Dat scheelt al erg.
Oude documentatie, zelfs al is deze niet meer actueel, kan ook helpen te achterhalen welke gegevens gebruikt worden. Natuurlijk: als iemand een deel van de berekening kent of als deze ergens gedocumenteerd is, gebruiken! Maar anders: zo veel mogelijk achterhalen welke gegevens gebruikt worden en waar deze ingevoerd worden, is een hele belangrijke start.
Creëer een lege basissituatie
Wanneer je niet meer informatie over de berekening kan achterhalen, kan de applicatie zelf je de berekening gaan leren. Hiervoor creëer je eerst een lege basissituatie. Wat houdt dit in? Je voert de gegevens zo in, dat de berekening uitkomt op 0. Om van een factuurberekening uit te gaan: aantallen zet je op "0" en bedragen zet je ook op "0". Hier is geen kennis van de berekening van nodig.
Mocht dit je niet lukken, omdat je te weinig gegevens hebt kunnen achterhalen, die de berekening beïnvloeden, start dan zoveel mogelijk vanaf "installatie". Voer alle gegevens in alsof je een nieuwe klant bent, maar voer bij alle getallen de waarde "0" in.
Test de berekeningsonderdelen 1 voor 1
Een uitgebreide berekeningen is vaak onderverdeeld in heel veel verschillende onderdelen. Dit zijn delen van de berekening, die zijn gescheiden door een "+" of een "-" teken. Of methodes, die bepalen of getal A of getal B gekozen wordt. Denk bij dit laatste bijvoorbeeld aan het BTW percentage. Deze is afhankelijk van het gekozen artikel.
In veel gevallen zijn deze onderdelen uit de user-interface te halen. Als je verschillende artikelen aan een factuur kan toevoegen, is de berekening van het artikel waarschijnlijk een lost onderdeel. Wanneer je een onderhoudstabel hebt voor verschillende BTW-percentages, wordt waarschijnlijk ergens bepaalt welke gekozen moet worden.
Ongeacht of je de onderdelen al gedeeltelijk kan raden of niet, de aanpak blijft gelijk. Voer bij een veld, waarvan je weet dat deze voor de berekening gebruikt wordt, een waarde in. Kies voor een waarde, die het eenvoudig maakt te achterhalen hoe de berekening werkt. Bijvoorbeeld "1" voor aantallen of "50" voor percentages. Voer daarna een ander veld in, dat voor de berekening gebruikt wordt. Als je een berekeningsonderdeel weet, kies een ander veld voor dat onderdeel. Als je dit niet weet, kies bij voorkeur een veld op hetzelfde scherm, zo dicht mogelijk in de buurt.
Controleer de berekening en ga net zo lang door, totdat je berekening geen "0" meer als antwoord geeft. Zorg er wel voor, dat elk ingevoerd veld een unieke waarde heeft. Meestal zal je nu vrij eenvoudig kunnen zien, wat er berekend is. Een optelling of vermenigvuldiging van twee ingevoerde getallen is het meest voorkomend. Anders moet je nog even doorpuzzelen, door weer invoer op "0" te zetten. Als het resultaat van de berekening groter blijft dat 0, blijft dat gegeven "0". Anders voer je weer een waarde in. Waar het om gaat, is dat je een situatie probeert te creëren, waarin zo min mogelijk gegevens de berekening beïnvloeden. Zodat je eenvoudig kan zien, wat de berekening is.
Weet je een berekeningonderdeel, ga dan door tot je alle bekende velden van de deelberekening gehad hebt. Weet je niets, voer de gegevens verder 1 voor 1 in, tot het bedrag wijzigt. En herhaal bovenstaande stappen. Blijf elk veld een unieke waarde geven. Geef desnoods velden weer de waarde "0", om waardes beschikbaar te maken.
Sta tijdens dit hele proces ook bij het volgende stil: "1" is een ideale waarde om de test te starten, maar als je vermenigvuldigd met 1, blijft het antwoord gelijk. Hetzelfde geldt voor "100%" en "1:1". Dit kan dus een goede start zijn, maar wijzig deze waardes op een bepaald moment naar een andere waarde. Mogelijk mis je anders een deel van de berekening.
Niet ideaal, maar beter dan niets
Elke informatie, die je weet te achterhalen, maakt het mogelijk een deel van de berekening te testen. Dus elk gesprek of elk document kan helpen. En door steeds wat meer gegevens in te voeren, kan de applicatie zelf je ook veel leren van de berekening. Besef dat voor zo'n belangrijk onderdeel, als een berekening, betrouwbaarheid vaak zo belangrijk is, dat alle beetjes automatisch waardevol zijn.
