zaterdag 2 september 2017

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.

Geen opmerkingen:

Een reactie posten

Opmerking: Alleen leden van deze blog kunnen een reactie posten.