Bepalen van testcases bij testautomatisering

Ik heb al aardig wat testautomatisering gedaan, maar ik blijf het een puzzel vinden: hoe bepaal je de indeling van de testcases bij testautomatisering? Hoe onafhankelijk van elkaar moeten ze zijn? Wat is de maximale tijdsduur van een testcase? En hoe uitgebreid wil je testen in een geautomatiseerde testcase? Wat is belangrijker: meer testen in 1 testcase of de tijdsduur van een testcase korter houden?

Als alle testcases na bouwen probleemloos zouden draaien, zou je ze zo lang kunnen maken als je wil. Maar dan zouden ze tegelijkertijd zinloos zijn. Geautomatiseerde testen zullen falen. Omdat er een fout is ontstaan of omdat de applicatie is aangepast. Daarom gaat het niet alleen om de ideale testcases voor je testuitvoering, maar ook om de onderhoudbaarheid van de geautomatiseerde testset.

Tegelijkertijd wil je meer doen dan alleen maar hele kleine testen uitvoeren. Je wil een keten van handelingen testen. Iets invoeren en daarna weer opvragen. Of weten of je applicatie goed werkt van stap A naar stap B naar stap C. Dat vraagt om langere testcases of misschien zelfs wel op testcases, die elkaar opvolgen.

Maar hoe kom je nu tot een goed evenwicht?

Tijdsduur

Voor de onderhoudbaarheid van een testcase, is het verstandig dat de tijdsduur niet te lang is. Als een testcase faalt, moet je hem opnieuw kunnen draaien en volledig kunnen volgen. En daarna weer opnieuw kunnen draaien en opnieuw en opnieuw en opnieuw. Om dit goed te ondersteunen, is mijn eerste streven altijd om elke testcase uiterlijk rond de 5 minuten te laten duren. Als hierin echt te weinig getest kan worden, heb ik wel de keuze gemaakt om uit te breiden naar 10 minuten. Maar langere testcases zijn niet goed onderhoudbaar, omdat dit te lang duurt om ook je aandacht er goed bij te houden.

Onafhankelijkheid

De ideale situatie is een test, die altijd kan draaien, onafhankelijk van welke testcase dan ook. Maar zeker als je een hele keten wil testen, ga je al snel over de 10 minuten heen. Toch moet het streven blijven om de testcases zo onafhankelijk mogelijk te laten draaien. Ik houd hierbij het volgende streven aan: als er voorbereidende testcases zijn, is het nodig om deze 1 keer uit te voeren. Hierna kan de testcase oneindig herhaalt worden, zonder nieuwe voorbereiding.

Als ik de tijdsduur niet in kan schatten, begin ik met mijn ideaal: alles in 1 testcase. Wanneer de test dan te lang blijkt, ga ik na welke onderdelen ik los kan testen. Zo kan, na het aanmaken van bijvoorbeeld een werknemer, de controle van de werknemer in een andere testcase geplaatst worden. Ook het gebruiken van de werknemer in andere schermen kan in andere, losse testcases.

Als er een keten is, dan kan deze vaak opgesplitst worden per menu-item. Dit klinkt misschien als een vreemde indeling, maar het openen van een ander scherm via een menu-item geeft vaak een duidelijke nieuwe stap in de keten aan. Terwijl de handelingen, die je uitvoert, voordat je het menu weer gebruikt, vaak sterk met elkaar gerelateerd zijn.

Testdekking

Het liefst test ik alle velden van alle schermen in 1 testcase. Maar hoe groter de schermen en hoe meer schermen, des te moeilijker dit wordt. Maar tegelijkertijd wil je niet een ongelofelijke hoeveelheid testcases, waarvan je niet meer weet welke testcases wat test. Daarom heb ik in de loop van de tijd bepaalde standaarden ontwikkeld:

Testen van een groep gegevens
Een testcase kan gericht worden op het opslaan en tonen van alle gegevens in een bepaalde groep op je scherm. Door alle gegevens van een groep in dezelfde testcase te testen, houd je de testcases beter onderhoudbaar.

Testen van onderlinge relaties van gegevens
Bij voorkeur test ik groepen van gegevens samen, als ze een onderlinge relatie hebben. Denk hierbij aan velden, die gevuld worden op basis van ingevoerde gegeven. Of denk aan velden, die verdwijnen en verschijnen n.a.v. bepaalde keuzen. Maar als dit teveel wordt, bijvoorbeeld omdat groepen teveel relaties hebben, splits ik ze op in verschillende testcases. De invoer kan dan beperkt worden tot de gegevens invoer, die effect heeft op een andere groep. Of de in te voeren groepen kunnen beperkt worden tot 2 en de test is volledig gericht op het testen van de relatie tussen deze twee groepen.

Testen gericht op specifieke controles
Bepaalde controles kunnen los getest worden. Neem bijvoorbeeld het wel of niet verschijnen van bepaalde velden. Of de aangeboden keuzes in een selectiedialoog. Als deze controles belangrijk zijn, maar in een scherm aardig wat tijd vragen om te testen, kan je ze lostrekken in een nieuwe testcase. Door deze testcase helemaal op deze controle te richten en ook in andere schermen deze controles in speciale testcases uit te voeren, houd je wel overzicht op je testcases. Je weet altijd wat er in een testcase getest wordt en wat niet, zonder uitgebreide documentatie na te kijken.

Tijdsbesparing

Er zijn twee keuzes, die je kan maken, om de testcases korter te maken. Deze hebben nadelen en daarom is het verstandig de voor- en nadelen goed te overwegen.

Gebruik van data in een database

Om een volledige keten te testen, maar tegelijkertijd je testen kort en onafhankelijk te houden, kan je ervoor kiezen de "tussenproducten" van een keten alvast beschikbaar te maken in een database. Dit heeft zelfs als extra voordeel, dat je test of de aanpassing ook met bestaande data werkt. Maar een belangrijk nadeel is: je test niet de volledige keten van het begin tot het eind in 1 keer.

Verschillende situaties in 1 test

Als je toch in 4 testcases de medewerkersgegevens invoert, kan je deze meteen gebruiken om wat verschillende situaties te testen: een naam met en een naam zonder tussenvoegsel; een man en een vrouw; een adres in het buitenland en een adres in Nederland. Dit heeft twee risico's: je moet goed weten welke situatie je in welke testcase toevoegt. Dit vraagt om documentatie, al of niet in de code. En daar moet je tijd voor vrijmaken. En als tweede nadeel: als de test faalt, weet je dan nog waardoor? Als een medewerker niet goed wordt opgeslagen en de melding "Het adres is niet correct" verschijnt, komt dit dan door het buitenlandse adres? Of komt dit doordat je een huisnummer toevoeging hebt ingevoerd? Meer situaties in een test kan meer analysetijd tot gevolg hebben, als je test faalt.

En nu van start

Testautomatisering testcases bepalen is een kwestie van oefenen, uitproberen en later aanpassen. Houd vooral de tijdsduur van een testcase in de gaten. Naar mijn mening gaat de tijdsduur boven de onafhankelijkheid. Maar houd bij voorkeur je testcase zo, dat deze achter elkaar meerdere keren uitgevoerd kan worden. Bepaal een goede indeling van je testcases qua testdekking. En houd deze over al je testen aan. Eventueel kan je je testcases gebruik laten maken van bestaande data in de database. En ook het testen van meerdere situaties in een testcase is een optie.

Maar ga vooral gerust aan de gang. Als je testcases te groot zijn, kan je ze kleiner maken. En als het er teveel zijn, kan je ze samenvoegen. Ook de indeling van je automatische test is niet gegoten in beton!

De kwaliteit van testen gemeten met de bugs van klanten

Een acceptatietest door een klant is een geaccepteerde en professionele stap in je testproces. Maar het wordt een ander verhaal als je de acceptatietest gaat gebruiken om de echte kwaliteit van het interne testproces te verbergen: "Dit soort fouten zijn aan onze klanten om te vinden". Hoe voorkom je dit? Beoordeel je testproces aan de hand van de bugs, die je klanten terug melden. En kijk zowel naar de bugs uit de acceptatietest, als naar de bugs, die gevonden worden in productie.

Basis indeling

Er zijn drie belangrijke factoren, waaraan je kan zien hoe goed je testproces is, als je naar bugs kijkt:

1. Waar is de bug gevonden?
   Is de bug in de schermen, die de gebruiker (bijna) dagelijks gebruikt? Of is de bug in de schermen, die minder vaak gebruikt worden?
2. Hoe uitzonderlijk is de invoer?
   Is de ingevoerde combinatie van gegevens om de bug te reproduceren iets wat nauwelijks voorkomt? Of is het een combinatie, die (bijna) elke dag opnieuw gebruikt wordt? Let hier wel op: als je 500 producten hebt en het product waarmee je reproduceert is product 371, blijf eerlijk. Als de bug inderdaad op slechts 1 product reproduceerbaar is, is de invoer misschien zeer uitzonderlijk. Maar als je dezelfde bug ook kan reproduceren met 99 andere producten, is de reproduceerbaarheid toch echt een stuk hoger.
3. Hoe eenvoudig is de bug te reproduceren?
   Is de bug reproduceerbaar door gewoon willekeurige gegevens in te voeren? Of moet je bepaalde keuzes maken, om de bug te kunnen reproduceren, zoals een "Ja" kiezen in een combobox of een instelling in een ander instellingen scherm wijzigen?

 Let wel op dat ik hierbij bewust van een bug spreek. Een bug is iets wat niet goed werkt, waarvan iedereen zal zeggen: "Dit is gewoon fout". Dus situaties als "Dit veld hoort eigenlijk voor dat veld" of "De tab volgorde klopt niet" wordt binnen deze blog niet als bug gezien. Natuurlijk verdient dit ook aandacht en zegt het ook wat over je testkwaliteit. Maar als dit de belangrijkste problemen zijn, dan ben je echt al vrij hoog in de testkwaliteit.

Komen tot een tussenoordeel

Op basis van deze drie factoren kan een kwaliteitsschema worden opgesteld. 

Komen tot een eindoordeel

Wat hieronder staat, is mijn voorstel. Maar voel je vrij je eigen indeling te maken.

Kwaliteitsniveau 1Bijna bij elke RFC of story heeft een klantbug, die valt in minimaal 2 categorieën "Laag".

Kwaliteitsniveau 2
Bijna bij elke RFC of story heeft een klantbug, die valt in 1 categorie "Laag".

Kwaliteitsniveau 3
Bijna elke RFC of story heeft een klantbug, die valt in minimaal twee categorieën "Matig".

Kwaliteitsniveau 4
Bijna elke RFC of story heeft een klantbug, die valt in 1 categorie "Matig".


Kwaliteitsniveau 5
Bijna geen RFC of story heeft een klantbug in de categorie "Laag"

Kwaliteitsnviveau 6Bijna geen RFC of story heeft een klantbug in de categorie "Matig"

De kritische punten

De overlap
Ik besef dat de categorieën soms overlap hebben. Als een gegevenscombinatie dagelijks wordt ingevoerd, zal dit bijna altijd zijn in een scherm dat dagelijks gebruikt wordt. Dit kan misschien niet eerlijk lijken. Maar juist de schermen, die zo vaak gebruikt worden en waarin steeds dezelfde gegevenscombinaties ingevoerd worden, moeten ook minimaal op deze wijze getest worden. Als je in de meest gebruikte schermen niet de meest gebruikte gegevenscombinaties test, dan heb je echt je testproces niet op orde. En dat geldt ook voor andere overlap, die je kan bedenken. Juist dit zijn testen, die gewoon standaard uitgevoerd moeten worden.

Dit is toch niet nodig?
Er zijn al zoveel manieren om het kwaliteitsniveau te meten. Waarom zou je zoveel tijd steken in het meten op basis van bugs van klanten? Het zou ook niet nodig moeten zijn. Maar ik heb te vaak meegemaakt dat de kwaliteit van het product afgeschoven wordt op de klanten: "Dat moet de klant testen" of nog erger "Had de klant maar beter moeten testen, voor we naar productie gingen". Meestal gaat dit gepaard met ontevreden klanten, een slechte samenwerking met de klant en weinig vertrouwen van de klant in het bedrijf en product. Tenzij dit is wat je wil, kan het zeer verstandig zijn om bij bovenstaande beweringen eens goed na te gaan of je van je klant niet teveel testwerk verwacht.

In het kort

Het belangrjjkste is goed te kijken naar de bugs, die klanten melden. Hoe simpel was het om deze in een test te vinden. De volgende criteria kunnen hierbij een houvast zijn:

1. Waar is de bug gevonden?
2. Hoe uitzonderlijk is de invoer?
3. Hoe eenvoudig is de bug te reproduceren?

Hoe makkelijker en vaker de bugs voorkomen, hoe slechter de kwaliteit van je testproces. Gebeurt dit regelmatig, dan kan het zeer verstandig zijn een kwaliteitsschema op te stellen als hierboven, om de kwaliteit te controleren en te verbeteren. Maak gerust je eigen schema. Het belangrijkste doel is tenslotte: je interne testproces moet zo goed zijn, dat je klant tevreden is over de kwaliteit. Maar niet slechts de eindkwaliteit. Nee, ook de kwaliteit van het eerste product, dat de klant zal testen.

Het verschil tussen het testen van specificaties en het testen van kwaliteit

De software voldoet aan de vastgestelde specificaties. Maar toch zijn de klanten ontevreden. Niet omdat ze wat anders hadden gewenst, dat is een ander onderwerp. Nee, omdat de software gewoon niet goed werkt. De kwaliteit is niet voldoende. Misschien kent niet elke tester deze situatie, maar hij komt zeker voor. De situatie van een test die 100% slaagt, maar de werkelijke kwaliteit niet kan constateren.

Wat je hier tegenkomt is vaak het verschil tussen het testen van specificaties en het testen van de kwaliteit. Bij het testen van de specificaties is datgene wat letterlijk op papier is gezet ook getest. En dat werkt. De tester heeft het goedgekeurd en de klant heeft het goedgekeurd. Wat niet is getest, is datgene wat niet op papier is gezet. Maar wat achteraf toch van belang blijkt te zijn.

Nu kan je als tester zeggen: "Tja, dan had je het maar in de specificaties moeten opnemen". Maar een echte Agile tester weet dat dit niet terecht is. Het is juist de bedoeling om de hele grote, volledig uitgeschreven documenten terug te brengen. Juist omdat deze uitgebreide documenten misschien wel volledig waren, maar net zo min correct. En zeker niet geschikt om flexibel te wijzigen. Waar dit probleem nu veroorzaakt wordt door iets wat niet in de specificaties stond, werden dit soort problemen daarvoor veroorzaakt doordat informatie anders of zelfs tegenstrijdig in de specificaties stond. Of omdat mondelinge overleggen allang de officiële specificaties hadden gewijzigd, maar die informatie weer niet goed was vastgelegd.

Natuurlijk zijn er grenzen aan wat  je kan testen, als het niet is vastgelegd. Maar naar mijn mening moet je juist als Agile tester (waar iedereen verantwoordelijk is voor het volledige eindproduct) je verantwoordelijk voelen voor de kwaliteit, ongeacht of deze automatisch volgt uit de specificaties of niet.

Wat staat er dan niet in de specificaties?
Specificaties beschrijven meestal minimaal wat de klant of wat het bedrijf zelf wil, gedacht vanuit de verschillen tussen de huidige situatie en de nieuwe, gewenste situatie. Wat staat er dan niet altijd beschreven? Wat maakt het verschil tussen de specificaties en de kwaliteit?

1. Standaard functies
   Knoppen als Nieuw, Opslaan, Verwijderen en Annuleren hebben functionaliteit, die vaak als bekend wordt beschouwd. Ze kunnen dan ook in specificaties afgedaan worden met: De knop X is aanwezig. Als ze al genoemd worden. Maar elk van deze knoppen heeft zijn eigen specifieke testen, om na te gaan of ze goed werken. En dat moet ook getest worden, ongeacht of dit officieel vermeldt staat.
   
2. Foutafhandeling
   Hoe de wijziging moet werken staat meestal wel goed beschreven. Wat de applicatie moet doen, als de gebruiker iets fout doet, niet altijd. Dit is echter ook belangrijk. Het opvangen van foute invoer of verkeerde handelingen, inclusief testen op goede en duidelijke foutmeldingen, kan een heleboel problemen bij de gebruiker voorkomen.
   
3. Andere schermen met dezelfde functionaliteit
   De wijziging wordt vaak beschreven vanuit een bepaald scherm, namelijk het scherm waar de wijziging gewenst is. Maar met grote regelmaat komt dezelfde functionaliteit ook in andere schermen voor. Zo kan het aanmaken van een werknemer bij het invoeren van een contract beschreven worden. Tegelijkertijd wordt een werknemer ook aangemaakt in een algemeen onderhoudsscherm voor werknemers. Als voor het contract bij de werknemer extra gegevens worden toegevoegd, moeten deze ook in het algemene onderhoudsscherm worden toegevoegd. Dus is de vraag: heeft de beschreven wijziging effect op soortgelijke functionaliteit in andere schermen?
   
4. Andere varianten van dezelfde businessrules
   Je businessrules kunnen soms heel ingewikkeld worden. Een beroemd en berucht voorbeeld hiervan is de berekening van een totaalbedrag in de factuur. Er kunnen heel veel varianten zijn om tot een bepaald bedrag te komen, afhankelijk van instellingen en ingevoerde gegevens. Als hier een wijziging wordt voorgesteld, kan dit effect hebben op de andere varianten. Het kan zijn dat een situatie een uitzondering moet zijn op de nieuwe regel. Het kan zelfs zijn dat een andere variant niet meer mogelijk is, door de nieuwe wijziging. En je kan gewoon per ongeluk iets kapot maken in de bestaande situaties, door je huidige aanpassing.
   
5. De wijziging in het gehele bedrijfsproces
   Stel je wijzigt het adres door het adres veld op te splitsen in straat en huisnummer. Dit kan een niet zo'n grote wijziging lijken, totdat je verder het gehele bedrijfsproces bekijkt. Dit adres wordt getoond op heel veel rapporten en vaak ook op andere schermen. Bij elke wijziging is het daarom van belang, zeker als je gegevens wijzigt, na te gaan of deze wijziging ook effect heeft op stappen verderop in het proces.

Ervaren testers kunnen waarschijnlijk nog meer groepen noemen. Maar op basis van mijn ervaring zijn dit de meest belangrijke.

Test kwaliteit, niet specificaties

Probeer altijd als een testers te helpen bij het opleveren van een goed product en kijk daarom niet alleen naar de specificaties. Kijk of de wijziging effect heeft of zou moeten hebben op niet genoemde onderdelen in de applicatie. En kijk of je meer moet testen, dan er letterlijk beschreven staat. Dit zal niet altijd makkelijk zijn, maar enkel al het streven kan een hele grote verbetering zijn.

Testen van een "Kopieer data" functie, niet zo simpel als het lijkt

Snel data invoeren. Met grote regelmaat wordt hier een kopieer functie voor gebruikt. Kopieer een al eerder ingevoerd record. Waarom is dit niet simpel te testen? Technisch blijkt dit vaak vrij ingewikkeld, door alle verschillende koppelingen en tabellen. Maar in de specificaties is het regelmatig 1 zin: "Kopieer alle data in een nieuw record". Zo wordt het vaak niet gebouwd. Door technische beperkingen of door slechte controle door de ontwikkelaar (oh ja, dat veld moet ook). En dat maakt het zo'n lastige functie om te testen. De beschrijving klopt bijna nooit, maar de gevolgen van fouten kunnen wel heel groot zijn.

De basistest

De basis voor het testen van een "Kopieer data" functie is heel simpel: Vul alle velden met een andere waarde, dan de waarde die standaard gekozen wordt. En vul alle tabellen met minimaal twee records. Controleer vervolgens of al deze gegevens goed overkomen bij het kopiëren.

De kwaliteit van de kopie

Hoewel bijna elke "Kopieer data" wordt omschreven als het kopiëren van alle data, maak je hier een gebruiker bijna nooit blij mee. Als je hiermee al niet een onwerkbaar record creëert. En daarnaast geeft het niet goed aan waar je als tester op moet letten. Om dit uit te leggen, val ik in de titels een beetje terug op database termen, maar ik zal elke onderdeel toelichten aan de hand van een voorbeeld gebaseerd op een werknemer.

Primary key

Bijna altijd als je data kopieert, is er sprake van een unieke waarde per record. Bij een werknemer is dit vaak een werknemersnummer. Deze unieke waarde mag NOOIT letterlijk gekopieerd worden. Het mag leeg zijn, tot het moment van opslaan. Het mag opnieuw bepaald zijn. Maar controleer of de waarde in dit veld nog steeds een unieke waarde is en niet gelijk aan de oorspronkelijke kopie. Zeker als het veld ook nog eens niet gewijzigd mag worden, wat vaak het geval zal zijn.

N:N relatie

In bijna elk datarecord kan je data invoeren, die terugkomt in andere soortgelijke datarecords. Denk bijvoorbeeld aan de bedrijfsmiddelen, die een werknemer tot zijn beschikking krijgt. Dit kan een tabel in je scherm zijn, waarin je kan zien dat de betreffende werknemer een telefoon, een laptop en een sleutel tot het kantoorpand heeft gekregen. Maar deze keuzes zullen bij veel andere werknemers ook terugkomen. Ga goed na of deze gekopieerd worden (altijd minimaal 2 rijen in een tabel). En als dit niet het geval is, ga na of dit een bewuste, goed doordachte keuze is.

1:N relatie
Bepaalde data in tabellen is uniek voor dat betreffende datarecord. Er is echt wel meer van deze invoer, maar elke invoer is uniek voor dat datarecord. Denk hierbij aan een contract. Je kan als werknemer aansluitend meerdere contracten hebben. Maar dat contract zal slechts gekoppeld zijn aan 1 werknemer. Over het algemeen is dit data die je niet wil mee kopiëren. De gegevens zijn per werknemer zo verschillend, dat de invoer toch overnieuw moet.

Maar als het toch meegekopieerd wordt, controleer dan zeer goed of er echt sprake is van nieuw aangemaakte data. En controleer deze extra data op precies dezelfde manier als je het datarecord zelf controleert. Controleer op de primary keys en op de verschillende relaties. En vul ook hier alle velden in en vul alle tabellen met minimaal twee rijen. Als dit soort data meegekopieerd wordt, is dit een plaats waar het vaak misgaat. Omdat juist aan dit deel vaak minder aandacht wordt besteed, dan aan het oorspronkelijke datarecord.

N:1 relaties
Bovenstaande twee relatie beschrijvingen gingen over tabellen. Maar je hebt ook regelmatig comboboxen of andere manieren van selecteren, waarbij je kiest uit een standaard lijst met keuzes. Denk aan de functie van een werknemer of een manager van een werknemer. Het testen hiervan is niet zo moeilijk. Maar bij het testen zal je merken, dat hier regelmatig een veld zal missen. Al of niet om de kopie technischer makkelijk te bouwen. Besteed hier dus wel aandacht aan en vraag na waarom een veld niet gekopieerd wordt.

Speciale situaties

Bij elkaar horende gegevens

Om het kopiëren technisch eenvoudiger te maken, worden vaak besluiten genomen om bepaalde data niet in de kopie op te nemen. Dit kan, maar let wel of het eindresultaat nog genoeg kwaliteit heeft. Het gebeurt regelmatig dat gegevens eigenlijk bij elkaar horen. Als een deel hiervan wel en een deel hiervan niet gekopieerd wordt, kunnen vreemde situaties ontstaan.

Denk bij een werknemer aan de bankgegevens. Het rekeningnummer is eenvoudig gekopieerd en gaat vaak mee. Terwijl elke werknemer eigenlijk een uniek rekeningnummer heeft, dus kopiëren heeft geen waarde. De bank kan echter een combobox zijn, die is overgeslagen. Je krijgt dan de situatie waarin wel het banknummer staat, maar de bank niet wordt ingevoerd. In deze situatie is het verstandiger om alle bankgegevens leeg te laten en niet alleen de bank.

Relatie met zichzelf
Het komt zelden voor, maar het gebeurt wel: bij een van de velden kan je het ingevoerde datarecord zelf invoeren. Een voorbeeld hiervan kan zijn bij de urencontrole. Sommige werknemers mogen hun eigen uren invoeren en bevestigen, anderen moeten hun uren door een ander laten bevestigen. Bij de eerste groep kan dan in het veld "Controleur uren" de werknemer zelf worden ingevoerd.

Hoe weinig dit ook voorkomt, dit zijn heel gevaarlijke velden bij een kopieer test. Want de waarde, die hier staat, is te vaak de waarde van het oorspronkelijke datarecord, waar de kopie op gebaseerd is. Test dit daarom goed. Zo'n veld moet bij het kopiëren leeg zijn of moet al bij het aanmaken naar zichzelf verwijzen. Hier zal je speciaal op moeten testen. Doe dat ook!

Samenvatting

Dus hoe test je een "Kopieer data" functie?

• Voer alle gegevens in en vul alle tabellen met twee rijen
• Controleer goed of de primary key niet wordt gekopieerd en of de gekopieerde relaties de juiste kwaliteit hebben
• Controleer of bij elkaar horende gegevens allemaal wel of allemaal niet gekopieerd worden
• Controleer extra op velden waarin het datarecord zelf als keuze kan worden ingevoerd

Waar het op neer komt, is dat je juist bij een functie als deze niet zozeer controleert of het volgens specificaties is. Maar controleer of de kwaliteit van de gebouwde functie goed is.