Ik kijk met een ontwikkelaar mee, hij heeft zojuist een scherm gebouwd en is net bezig met een test daarop. Hij voert wat gegevens in, klikt op Opslaan en controleert zijn werk in de database. Hij is tevreden en sluit zijn werk af. Dit is klaar voor de tester, hij gaat verder met een volgend onderdeel.
Herkenbaar?
Hieronder een uiteenzetting over het gebruik van testdata en de extra informatie die je krijgt door andere, betere testdata te gebruiken.
Voor het gemak vervang ik in dit verhaal het desbetreffende scherm even door een fictief NAW-gegevensscherm. (Naam, Adres, Postcode, Woonplaats). Vier velden, waarvan het postcodeveld eigenlijk al een verhaal op zich verdient, maar dat is wellicht voor later, ik richt me in dit verhaal vooral even op velden 1, 2 en 4.
De ontwikkelaar doet een controle en voert wat gegevens in. Hij drukt op Opslaan en controleert in de database de opgeslagen gegevens.
Zijn conclusie: Het programma werkt, klaar!
Kan ik beweren dat deze conclusie verkeerd is? It depends. Oftewel, dat hangt er vanaf. Als het zijn insteek is om te testen of er connectie gemaakt is met de achterliggende database, dan is zijn conclusie waarschijnlijk terecht. Het feit dat zijn testdate in de database geschreven is, lijkt me een goede indicatie dat er inderdaad connectie was.
Maar als het de bedoeling was om te testen dat de data correct was opgeslagen, dan was dit waarschijnlijk iets te kort door de bocht.
De ontwikkelaar heeft 2 van de 4 velden ingevoerd en op basis daarvan geconcludeerd dat de opslag juist was.
Maar wat als hij 4 van de 4 velden ingevuld had, en dit zou zien in de database?
Door de extra tijd te nemen door alle velden in te vullen, is in de database te zien dat niet alle invoer opgeslagen is. Zo lijkt Woonplaats niet opgeslagen te worden en verdere analyse voordat dit programma opgeleverd wordt, lijkt op z’n plaats.
TIP: Voer elk invoerveld een keer in.
Gaan we een stapje verder, stel dat hij inderdaad elk veld ingevuld zou hebben en dat dit te zien zou zijn:
Zou je nu wel kunnen concluderen dat de test geslaagd is?
Als je denkt van wel, kijk dan eens naar de volgende afbeelding. Deze ontwikkelaar voert in een test elk veld in, maar geeft daarbij elke invoer ook nog eens een uniek kenmerk:
In de database is elke invoer terug te vinden, maar door het unieke kenmerk wordt nu zichtbaar dat bij het veld Adres juist de invoer van de woonplaats staat en omgekeerd. Een bevinding die niet opgevallen was met het 4 keer invoeren van de tekst ‘Test’.
Tip: Gebruik in elk veld een uniek kenmerk waardoor de opslag sneller te beoordelen is.
Zijn we er nu? Nee hoor, er is nog veel meer mogelijk met slimme(re) testdata.
Ik ga er voor het gemak even vanuit dat de invoervelden 30 posities lang zijn en dat het in het scherm niet mogelijk is om er 31 in te voeren (Het veld Postcode zal uiteraard een ander formaat hebben, maar die hou ik zoals gezegd even buiten beschouwing).
Stel dat je in plaats van het woord ‘Test’, of ‘Testnaam’, het veld helemaal vol zou tikken met bijvoorbeeld ‘a’.
En stel dat dit dan het resultaat is:
Wat zou je oordeel in dit geval zijn?
Lastig te beoordelen waarschijnlijk? Zit je nu met je pen op het scherm, of met je vinger de a-tjes te tellen?
Ik maak het wat makkelijker voor je, ik tik nog steeds allemaal a’tjes, maar ik zet op positie 30 geen ‘a’, maar een ‘Z’.
En nu? Wat is nu je oordeel?
Als je nog scherp bent, dan zie je meteen dat er iets niet klopt. De ‘Z’ ontbreekt bij Woonplaats.
Hoeveel letters ‘a’ er staan is nog steeds lastig te beoordelen (zeker bij een nog langere tekst), maar het is, door de ontbrekende 'Z', in 1 oogopslag duidelijk dat blijkbaar niet de hele tekst is opgeslagen. Deze staan er wel bij Naam en Adres, daar is de maximale invoer dus ook echt opgeslagen. Reden om nog even wat analyse te doen voordat dit programma opgeleverd wordt.
TIP: Voer overal de maximale waarde in en wijzig het laatste karakter door een vaste herkenbare waarde zoals een ‘Z’.
Maar die fout opgeslagen woonplaats, hoe lang was die tekst nu? Toch alles gaan tellen? In dit geval misschien nog wel te doen, maar wat als het nou een veel langere tekst zou zijn? Kunnen we daar niet nog wat handigs mee doen? Ja, dat kan.
Je ziet nog wel eens ‘12345678901234567890’ ingevoerd worden. Als die laatste ‘0’ ontbreekt, dan is het duidelijk dat het er dus 19 zijn. Maar bij een heel lange tekst wordt het lastiger. Staan er nu 119 of 109?
Dat kan je oplossen door de volgende tekenreeks te gebruiken:
.3.5.7.9.12.15.18.21.24.27.30. (en zo verder).
Wat houdt dit in:
Het getal dat er staat, geeft de positie aan van het teken dat erachter staat.
De punt achter de 18 staat dus op de 18e plek en de punt achter de 30 dus op de 30e plek.
Zou je deze tekenreeks gebruiken en dit zou opgeslagen worden:
Dan zie je hier dus al snel dat er bij naam 30 posities zijn opgeslagen, bij Adres ook, maar bij woonplaats niet. Het teken, wat blijkbaar op de 30e positie zou moeten staan, ontbreekt. Er zijn programma’s die deze tekenreeks automatisch kunnen genereren (van elke gewenste lengte).
TIP: Maak gebruik van de kennis van anderen!
Zo, dit was een klein stukje (want er is nog veel meer) informatie over Testdata. Dus als je nog eens een testgeval uitvoert, en je betrapt jezelf erop dat je overal ‘Test’ invoert en daar je conclusie op baseert…
Denk hier dan nog eens aan, en bedenk, de data die je gebruikt kan je zoveel vertellen als je die slim kiest! En misschien heb je zelf ook nog wel aanvullingen die ik had moeten noemen?
Ik ben benieuwd!
Reacties kan je hieronder kwijt, of onder dit facebookbericht.
Ben benieuwd naar de reacties.
Fred Steenbergen is beroepsmatig Testspecialist. Zijn vrije tijd gaat grotendeels op aan het vrijwilligerswerk voor Stichting Dierenopvang Bosnië Hiermee gaat hij meerdere keren per jaar naar Bosnië om daar te helpen met het steriliseren van zwerfhonden. |
Wilt u ook helpen? Helpen kan gratis!
U kunt bijvoorbeeld een verschil maken met Douwe Egberts Punten.
En wanneer deed u voor het laatst iets met uw Air Miles?
“Ik flikker hem nog liever in de sloot!!!” Waar dat op slaat? Dat leest u hier.
|
San Francisco Depot Het ezelsbruggetje |
Agile, deel 1 Het teamoverleg |
De bug van de week |
Reacties (3)
Is absoluut interessant. En ga het zeker ook zelf uitproberen.
Het is in ieder geval de verklaring voor die rare tekenreeks van gisteren ;-)