Testdata management als al je klanten anders zijn

De testdata beschikbaar in de database is belangrijk. Zowel om je testen betrouwbaar, als om je testen reproduceerbaar te houden. Als je slechts 1 klant heb, kan je de data van deze klant eenvoudig als basis gebruiken. Als je klanten veel overeenkomsten hebben, kan je de deze overeenkomsten als basis gebruiken. Maar wat als al je klanten uniek zijn? Door een applicatie met een oneindig aantal mogelijkheden? Hoe kom je dan tot een basis?

Bepaal de datagroepen

De testdata is te verdelen in vier groepen. Elke groep vraagt een andere aanpak. Het is daarom van belang om eerst goed te beseffen welke data in welke groep hoort.

De gebruikersdata met regelmatig onderhoud
Het aanmaken van opdrachten of het opstellen van een planning. Het zijn werkzaamheden die regelmatig plaatsvinden. Aan de data van deze groep wordt minimaal een keer per week wel data toegevoegd, data gewijzigd en data verwijderd. Ze bevinden zich vaak in de hoofdprocessen van de applicatie, juist door hun regelmatige gebruik. En het is daarom ook van groot belang dat juist deze processen altijd goed blijven werken, ongeacht wat de gebruiker invoert.

De gebruikersdata met incidenteel onderhoud
Voor deze groep is het moeilijker om voorbeelden te geven. Waar het ene bedrijf een vaste groep klanten heeft, waardoor deze nauwelijks onderhouden worden, zal het andere bedrijf elke dag klanten toevoegen, wijzigen of verwijderen. Waar het ene bedrijf een vaste groep producten heeft, zal een ander bedrijf bijna elke week de producten moeten onderhouden. Maar het gaat hier om data die door de gebruikers van de applicatie zelden ingevoerd worden. Mocht er zich een probleem voordoen, is dat zeker lastig, maar een probleem in deze groep zal niet snel blokkerend zijn voor het gebruik van de applicatie.

De systeemmanagementdata met regelmatig onderhoud
Een systeembeheerder, applicatiebeheerder of iemand anders in een soortgelijke functie kan vaak data invoeren, waar andere gebruikers niet zomaar bij kunnen. Hierbij gaat het om zaken als modules, parameters, instellingen en gebruikersrechten. Hoewel ook hier het onderscheid tussen regelmatig en incidenteel van belang is, liggen de periodes wel anders. De data met regelmatig onderhoud in deze groep, kan rustig een keer in de paar maanden zijn. Het is data, die gebruikt wordt om de processen te optimaliseren. Of data die gebruikt wordt om een bedrijf te laten groeien of inkrimpen. Of misschien data, die gebruikt wordt om processen aan de wensen van klanten of andere belangrijke partijen aan de passen. Denk hierbij aan de velden, die je op je scherm ziet. Dit kan voor iedereen slechts eenmalig ingesteld worden. Maar er kan ook behoefte zijn om hierin flexibel te zijn, zodat het scherm niet het werkproces bepaald, maar het werkproces het scherm. En je regelmatig kan kijken of de huidige indeling nog naar tevredenheid is.

De systeemmanagementdata met incidenteel onderhoud
In de meeste gevallen is dit data die na installatie eenmaal wordt ingevoerd en daarna (bijna) nooit meer wordt aangepast. De ingevoerde data is de werkelijkheid en daar kan vaak ook niet van afgeweken worden. Bijvoorbeeld door regels, wetten of voorschriften. Of omdat aanpassingen niet alleen vraagt om een aanpassing in data, maar ook vraagt om een hele andere werkwijze of proces. Of men besluit natuurlijk gewoon dat de huidige situatie voldoet, waardoor er geen behoefte is aan aanpassing. Een typisch voorbeeld hiervan is de modules, die in een applicatie staan ingesteld. Dit wordt vooral bij installatie bepaald en zal daarna nauwelijks meer wijzigen.

Bepaal de data

De gebruikersdata met regelmatig onderhoud
Het onderhouden van deze data is zo belangrijk, dat het verstandig is weinig gebruik te maken van testdata in de database. Juist om zoveel mogelijk varianten in onderhoud te testen, maak je de data zoveel mogelijk keer op keer opnieuw aan. Gebruik makend van je kennis, ervaring of testtechnieken kan je bepalen wat er nodig is. Om tijd te besparen bij handmatig testen of om een automatische test niet te lang te maken, kan het toch verstandig zijn om wat data beschikbaar te hebben. Deze data is dan het gevolg van opgestelde testcases en kan dan ook volgens deze criteria in de database worden opgenomen.

De gebruikersdata met incidenteel onderhoud
Omdat het niet altijd belangrijk is dit in de test mee te nemen, is het wel verstandig hiervoor een goede set in je database te krijgen. Wat hiervoor van belang is, is dat je weet welke data effect heeft op de andere gebruikersdata of hun bijbehorende schermen. Een logische gedachte is een relatie waar instellingen ingevoerd kunnen worden hoe de factuur eruit moet zien. Maar denk ook aan verschillende varianten in namen, zoals wel of geen tussenvoegsels en de keuze tussen Dhr. of Mevr. Als deze belangrijke varianten in je database voorkomen, kan je snel en flexibel testen.

De systeemdata met regelmatig onderhoud
Deze data hoort eigenlijk niet te bepalen hoe de database bepaalt wordt, maar vooral hoeveel testdatabases je eigenlijk tot je beschikking wilt hebben. De redenering rond deze data is eigenlijk gelijk aan de redenering rond gebruikersdata met incidenteel onderhoud. Dus als dit mogelijk is, kies voor verschillende varianten. Maar systeemdata is vaak maar op 1 plek in te stellen, waardoor het niet mogelijk is deze varianten toe te voegen. De varianten zijn echter zo belangrijk, dat je ze uitgebreid mee wil testen, zonder steeds veel tijd aan voorbereiding kwijt te zijn. De meest verstandige keuze is daarom hiervoor meerdere databases te maken. B.v. per belangrijke groep klanten (overheid of particulier) of grootte van de klant (veel of weinig medewerkers). Mocht dit niet mogelijk zijn, zal je geen keus hebben om de voorbereiding toch in je testcases te doen.

De systeemdata met weinig onderhoud
Hier gaat het vooral om het neerzetten van een goede basis. Belangrijke variaties in deze instellingen, zoals de keuze of een veld wel of niet verplicht is, moeten worden opgevangen als aanpassingen/voorbereidingen in je testcases. Maar de basis moet zoveel mogelijk voldoen aan de instellingen van zoveel mogelijk klanten. Noem het de database van de "gemiddelde klant". De instellingen, die het meest gebruikt worden. De waardes, die het meest ingevoerd worden. Dit zorgt ervoor dat, als het werkt, de kans ook het grootste is dat het werkt voor het grootste deel van je klanten.

Het vervolg

Besef dat dit onderwerp altijd aandacht blijft vereisen. Je klanten veranderen, je applicatie verandert, je bedrijf verandert. Dit is dan ook geen eenmalige actie, waarna je er nooit meer bij stil hoeft te staan. Als je je testen uitvoert, blijf dan regelmatig stilstaan of je data nog voldoet. Als de applicatie wordt uitgebreid of aangepast, kijk of de data in de huidige database nog steeds alle groepen goed afdekt. En besef ook dat je de eerste keer vergissingen kan maken, hoe zeer je ook je best doet. Blijf hier aandacht aan besteden en blijf er goed over nadenken. Zodat jouw testdata in de database je optimaal blijven ondersteunen bij je testen.