Testen door vergelijken van website resultatenlijsten

Misschien ken je de situatie: je moet een website (her)bouwen. De site heeft een zoek- of vergelijkmechanisme. Het resultaat van dit zoeken of vergelijken komt van een externe leverancier en je hebt geen idee hoe ze dit zoeken of vergelijken doen. Je hebt ook geen controle over de gegevens die gebruikt worden in de testomgeving. Of het zoeken of vergelijken is ingeregeld via een tool, op een manier die niemand meer snapt. Misschien is het zelfs wel de situatie dat de code zo ingewikkeld is geworden (en niet gedocumenteerd), dat de ontwikkelaars de code niet meer volledig kunnen doorgronden. Is ook niet nodig, want het mechanisme wordt volledig hergebruikt. Hoe ga dan je testen?

Kiezen van de testmethode

De beste manier is eerst een goede beschrijving maken van de wijze waarop gezocht of vergeleken wordt. Aangevuld met een goede testdatabase. Dit kost alleen heel veel tijd. En bij een externe leverancier is dit vaak niet haalbaar, omdat je hun medewerking niet (voldoende) krijg. Zelfs als je het lukt, zal je nooit helemaal zeker weten of je alles hebt gehad.

De daarop volgende keuze is via webservices of query's, waarmee je direct de data op kan vragen. Deze kan je dan vergelijken met de resultaten die je met de website gekregen hebt. Dit vraagt veel kennis van de technische kant van de applicatie, maar is mogelijk. Probleem is alleen het volgende: hoe weet je of je de webservice juist gebruikt en of je query correct is.

De snelste oplossing wordt vaak als meest onbetrouwbaar gezien: vergelijk je resultaat met een resultaat van een ander website. Dit kan bij een herbouw project de huidige versie van de website zijn. Maar bij externe leveranciers zijn er vaak meer klanten die dezelfde leverancier gebruiken. En in heel veel gevallen ga jij op een soortgelijke manier zoeken als de andere klanten. Dus als je op de huidige versie of op de website van de andere klant gegevens invoert en daarna precies dezelfde gegevens invoert op de nieuwe website, dan kan je deze twee resultaten met elkaar vergelijken.

Dit lijkt allemaal testregels en principes te overtreden. Want hoe weet je nu zeker dat je bij dit testen geen fouten overneemt in je nieuwe applicatie? Nu, dat weet je niet zeker. Net zo min als je zeker weet dat je in je geschreven documentatie geen zoekcriterium bent vergeten. Of een vergelijkingsbereking hebt gemist. En net zo min als je zeker weet dat je de webservice foutloos hebt gebruikt. Of je query naar precies de juiste tabellen kijkt op precies de juiste wijze. Want de business zal niet in staat zijn om je documentatie of je technische implementatie goed te controleren. En als de ontwikkelaars dit echt goed konden, had jij nu niet een testprobleem.

Staat bij een van de twee de betrouwbaarheid vast, omdat de kennis wel aanwezig is, ga dan voor die methode. Maar is dit niet zo, waarom zou je dan niet kiezen voor de snelle methode? Waar het wel om gaat: als je een van beide andere methodes tot je beschikking hebt, probeer het te gebruiken om je bevindingen te controleren. Steek meer tijd in de verschillen en probeer te achterhalen waardoor het komt. Kijk of er sprake is van een fout in de nieuwe site of in de huidige site. Het uitzoeken van verschillen kost vaak minder tijd dan het uitzoeken van het totale zoek- of vergelijkingsmechanisme.

Maar bedenk ook hierbij: als een site al minimaal een jaar in gebruik is, dan is vaak de klant tevreden en het bedrijf tevreden. Dus als de nieuwe site gelijk gaat werken, hoe groot is dan de kans dat ze ontevreden zullen zijn?

Aanpak

Wat wel van belang is, is dat je de test zo betrouwbaar mogelijk maakt. Voor het gemak hou ik het vanaf hier even op een zoekmechanisme. Stel je hebt een evenementen database, die op basis van ingevoerde criteria bepaalt welk evenement voor jou interessant kan zijn. Je kan invoeren of je het evenement met kinderen gaat bezoeken, in of rond welke stad het evenement plaatsvindt, hoeveel kilometer rond deze stad het evenement mag plaatsvinden en op welke datum het evenement plaatsvindt. Bepaal dan eerst welke gegevens je per veld in wil voeren.

De Ja/Nee velden zijn het meest eenvoudig. In dit voorbeeld: bij de vraag of je met kinderen het evenement gaat bezoeken, heb je dus twee interessante waardes: ja en nee. 

Daarna komen de keuzelijsten. Stel dat in bovenstaand voorbeeld in een keuzelijst van steden slechts 1 stad gekozen kan worden. Zorg er dan voor dat in elke testcase die je gaat samenstellen, een andere stad gekozen wordt. Heb je meer testcases dan steden, probeer dan zoveel mogelijk elke stad evenveel te herhalen. Wanneer je meerdere steden mag kiezen, kies dan minimaal de volgende: 0 steden, 1 stad, 2 steden. Probeer de steden zo te kiezen, dat ze niet of nauwelijks overlappende resultaten zullen hebben. In dit geval: twee steden die ver uit elkaar liggen. Hierdoor kan je beter zien dat alle gekozen waardes ook werkelijk in de zoekopdracht worden meegenomen. Maar kies ook testcases met de omgekeerde optie: twee steden die juist heel dicht tegen elkaar liggen. Dit is vooral om na te gaan of zoekresultaten dubbel getoond worden.

Dan hou je nog de vrije velden over: het aantal kilometers en de datum. Kies voor deze velden waardes die overduidelijk andere resultaten opleveren. Als je dit niet weet, dan kan je hier hulp vragen van iemand in het bedrijf met meer domeinkennis. Deze kan je vertellen wat de meest gebruikte waardes zijn en wat vaak een ander zoekresultaat oplevert. Maar regelmatig kan je het zelf beredeneren. Neem bijvoorbeeld het aantal kilometers. Als je 2 en 3 kilometers aanhoudt, dan is de kans dat je dezelfde evenementen te zien krijgt vrij groot. Maar als je 2 en 30 kilometers aanhoudt, grote kans dat het aantal evenementen bij 30 km groter is. En qua datum: rond kerst zijn er vaak bijzondere evenementen, net als in de zomervakantie. Data in die periode geven zeer waarschijnlijk een ander resultaat.

Stel dat je zo tot de volgende verzameling gegevens komt:

Kinderen: Ja, Nee

Steden: 0 steden, 1 stad, 2 steden

Aantal kilometers: 2, 30, 100

Datum: 10 maart, 8 augustus, 25 december

Om tot een zo betrouwbaar mogelijke test te komen, zou ik aanraden al deze gegevens in elke mogelijke combinatie testen. Dus je krijgt 2 x 3 x 3 x 3 = 54 testcases. Als je over een tool of de kennis beschikt, kan je ook kiezen voor pairwise testen.  Een methode waarbij je elke combinatie van twee gegevens minimaal 1 keer test. Dit zorgt meestal voor een betrouwbare test, maar wel met flink minder testcases. Maar hoe dit werkt is een blog op zich. Er zijn wel online tools beschikbaar, die je hierbij kunnen helpen.

Als laatste stap, zoals eerder geschreven: bepaal de steden. Verdeel de steden uit de keuzelijst zo gelijk mogelijk over de testcases. Probeer testcases samen te stellen, waarbij de kans op dubbele zoekresultaten groot is. En probeer testcases te maken, waarbij de kans op dubbele zoekresultaten juist erg klein is. Als het kan: probeer ook bij de testcases voor meerdere steden steeds voor andere steden te kiezen.

Door de gegevens goed te verdelen, de combinaties te testen en de data goed te variëren vergroot je de kans alle regels, uitzonderingen en bijzondere situaties te raken. En daarmee om fouten te vinden. Is het ideaal? Nou, nee.... Maar als de ideale wijze niet kan, is het wel een heel goed alternatief.