Software testing: waarom Record and Playback testtools niet werken

Inleiding

Een software leverancier zal vroeg of laat zijn produkt gaan testen om een vorm van garantie te bieden aan de klanten en om het risico af te dekken dat het een fiasco is. Vrij laat wordt er een test traject opgezet en meestal met behulp van Record and Playback testtools. Dit soort produkten kosten over het algemeen erg veel geld (er zijn tegenwoordig uitzonderingen) en verdienen de investering over het algemeen niet terug. 1In tegendeel het gaat soms zelfs meer kosten.

Hoe werken de Record and Playback testtools?

Record and Playback testtools zijn populair, omdat iedereen er mee lijkt te kunnen werken. Men start de testtool, start vervolgens de te testen applicatie en doe wat handelingen, zoals bijvoorbeeld het invoeren van een klant in de database. Sluit vervolgens de applicatie af en stop de testtool. Sla vervolgens het script of hoe het ook mag heten wat de testtool genereert op. Nu kan de testtool het script afspelen en tada de te testen applicatie start op, er worden handelingen uitgevoerd om een klant in de database in te voeren, de klantgegevens worden ingevoerd en de nieuwe klantkaart wordt opgeslagen. Of toch niet? Nee, de applicatie geeft een melding dat de klant al reeds in het systeem opgeslagen is.

Dit eenvoudige bovenstaande voorbeeld was om aan te geven dat de eenvoud van zo'n Record and Playback testtool tegenvalt. Het is niet voor niets dat veel leveranciers van zulke testtools consultants in dienst hebben om het geheel in een bedrijf te introduceren. Dit is ook de valkuil om voor zo'n testmethode te kiezen. Niet alleen de investering in het produkt is hoog, ook voor de support moet veel voor worden betaald. En voor de support zal nog veel meer voor worden betaald, want de scripts moeten ook onderhouden worden.

Nu kan men kiezen om iemand in dienst te nemen om de scripts te onderhouden, echter ook dat zal niet zomaar geld gaan opleveren. Het inzetten van een Record and Playback testtool en iemand die de scripts onderhoud zal zelden leiden tot het vinden van ernstige bugs. Ernstige bugs komen juist door uitvoeren van verschillende handelingen om hetzelfde gedaan te krijgen. Door het te automatiseren, wordt in feite telkens dezelfde handeling uitgevoerd. Als het de eerste keer goed ging, dan zal het waarschijnlijk ook de honderdste of duizendste keer goed gaan. Anders dan een performance test, is dit een zinloze test en zou niet uitgevoerd moeten worden.

Redenen waarom Record and Playback testtools niet werken

Ook al wordt er een script gemaakt dat intelligent met foutmeldingen omgaat en willekeurig data genereert, het zal nooit de creativiteit bezitten als die van een gebruiker. Vooral omdat de scripts gemaakt worden door iemand met een computerachtergrond en deze persoon zal in hetzelfde stramien denken als de eigenlijke programmeur.

Een ander punt waarom de testtools niet werken, is dat ze heel erg veel op de GUI leunen en deze is veelal aan verandering onderhevig. Een extra knop of invoerveld erbij of de tabvolgorde aangepassen leidt tot problemen met de testscripts. Maar nog erger is het geval dat niet alle knoppen dan wel invoervelden door de testtool direct te benaderen is, maar via bijvoorbeeld een X aantal tab's. Onderhoud wordt een probleem en kost veel tijd en levert veel frustratie en boekhouding op.

Als alles goed wordt bijgehouden van wat er in de GUI veranderd, dan nog zal er aan het uiteindelijke testscript gesleuteld moeten worden. Er zullen altijd last-minute veranderingen zijn. Gui aanpassing die wel zijn doorgevoerd, maar niet zijn vermeld. Het script is te snel met het uitvoeren van een handeling, omdat er een nieuwe en tragere SQL query is gemaakt. Kortom het kost veel tijd om de testscript te controleren en om vervolgens aan te passen. Dit meenemend met de kwaliteit van de testen, kan alleen maar negatief uitvallen om zo'n testtool in te zetten.

De testscripts zullen niet op elke machine werken en zijn meestal gebonden aan de machine waarop ze gemaakt zijn. Dit hoeft niet uit te maken, als de machine vergelijkbaar is met die van de klant. Een testmachine zou ideaal zijn, maar over het algemeen wordt de testtool op een ontwikkelmachine gebruikt. Hierdoor wordt het resultaat van de testtool alleen maar twijfelachtiger.

Conclusies

Het vertrouwen in een Record and Playback testtool zou minimaal moeten zijn. Alleen maar testen met een testtool en in zo'n laat stadium is te vergelijken met alles op een paard zetten waarvan de prestaties een beetje bekend van zijn. Het uiteindelijke resultaat kan mee- of tegenvallen, het blijft een gok en gokken is het laatste wat er gewild wordt.

Alles van de te testen applicatie willen testen met een testtool, is ondoenelijk en zou niet de opzet moeten zijn. Iedereen die dit verwacht, zal bij gebruik van een testtool weldra een illusie armer worden. Al is er nog zo grondig te werk gegaan, de eerste klant hangt waarschijnlijk binnen een uur aan de telefoon met een gevonden bug. Een applicatie volledig dekken m.b.v. een testtool is een illusie en zou ook niet het streven moeten zijn.

Bij juist gebruik kunnen Record and Playback testtools wel degelijk van pas komen. Absoluut niet voor overall tests, maar voor goed afgebakende gebieden zijn ze erg nuttig. Hou het simpel en daardoor overzichtelijk. Ken de beperkingen van de tool en probeer er niet meer van te verwachten, dan dat het eigenlijk kan. Het is geen heilige graal.

Record and Playback testtools zijn ze erg nuttig bij het vinden van problemen. Wie kent het niet dat bij een bepaalde volgorde van handelingen er een melding of een fout optreedt, maar de volgorde is niet meer helemaal duidelijk. Vervolgens begint het zoeken naar die specifieke volgorde en er is zo een uur voorbij. Wanneer er een testtool was gebruikt, was de volgorde vrij eenvoudig te achterhalen. Door het script uit te voeren, of door het lezen van de script code. Op deze manier kan er veel beter geanalyseerd worden van wat er nou precies fout ging, dan proberen te achterhalen welke handelingen er zijn uitgevoerd waardoor het fout ging.

Het onderhouden van testscripts is veel werk en eigenlijk kan wel gesteld worden dat de scripts slechts eenmalig van dienst zullen zijn. Het opnieuw maken van de testscripts zal waarschijnlijk minder tijd kosten, dan ze allemaal een voor een afgaan opzoek naar mogelijke onvolkomendheden, die zeker gevonden zullen worden.

Het hergebruik van scripts kan alleen uit, als de GUI niet of nauwlijks aan verandering onderhevig is of dat de testtool alle objecten op het scherm direct (op naam) kan benaderen. Ontwikkeltools worden daar steeds betere in en daardoor zou in de toekomst een testtool wel meer toegevoegde waarde hebben bij het overall testen.

Record and Playback testtools

Hier is een lijst met de bekendste Record and Playback testtools. Daarnaast wil ik wijzen op een freeware scripting tool Autoit . Dit pakket is niet specifiek bedoeld voor het testen. Echter voor het analyseren en performance testen is dit pakket uitermate geschikt. Neem ook kijkje bij de editor Scite van dezelfde makers. Daar zit de record and Playback tool bij.

Voor een redelijk bedrag is het pakket Test Complete van AutomatedQA een aanrader. Circa $ 350,- voor de goedkoopste variant en is daarmee erg goedkoop t.o.v. de andere pakketten en als het om de functonaliteit en prestaties gaat, kan het zich meten met de grote jongens.

Het overzicht: