Testen is standaard in het ontwikkelproces. Wat daarbij opvalt is dat we de testen veelal nog steeds handmatig uitvoeren. Veel projecten maken een start met geautomatiseerd testen, maar haken uiteindelijk af. Begrijpelijk vind ik eigenlijk. De oorzaak ligt volgens mij in het verkeerd toepassen van geautomatiseerd testen.
Veel projecten laten zich verleiden tot het opzetten van een geautomatiseerd testtraject. Op papier zijn er tal van voordelen, in de praktijk blijkt maar al te vaak dat de voordelen toch anders uitpakken. Geautomatiseerd testen wordt veelal gedaan om een besparing in het testtraject te realiseren, echter blijkt gedurende een project dat de kosten alleen maar stijgen en de resultaten achterblijven. Veel testen worden nog steeds handmatig gedaan of men is veel tijd kwijt met het verklaren van de fouten die uiteindelijk fouten in de testscripts blijken te zijn en niet in de applicatie.
Kan dit voorkomen worden? Het anwoord daarop is 'ja', maar dan moeten zowel de applicatie als de organisatie aan een aantal voorwaarden voldoen. Voorafgaand aan de beslissing om te starten met een geautomatiseerd testtraject dient eerst een gedegen selectie-traject te worden doorlopen om te bepalen of het zinvol én gewenst is om geautomatiseerde testscripts te gaan ontwikkelen.
Selectie-traject
Stap 1 in het selectie-traject is bepalen of de organisatie geschikt is om geautomatiseerd testen in te voeren. Om geautomatiseerd testen tot een succes te maken moeten een aantal voorwaarden zijn ingevuld:
– Interne kennis van geautomatiseerd testen is aanwezig.
– Interne kennis van geautomatiseerde testtools is aanwezig.
– De organisatie moet geautomatiseerd testen ondersteunen en erkennen.
– Besef in de organisatie dat geautomatiseerd testen niet goedkoper hoeft te zijn; kostenbesparing mag niet het hoofddoel zijn.
– Een ingericht selectie-proces voor de keuze om een applicatie wel of niet geautomatiseerd te testen.
– Een ingerichte testomgeving waarin geautomatiseerd testen middels marktconforme tools wordt ondersteund.
Stap 2 in het selectie-traject is het bepalen of een applicatie geschikt is om geautomatiseerd getest te worden. Indien de applicatie voldoet aan één of meer van onderstaande kenmerken dan is deze applicatie met zekerheid NIET geschikt voor geautomatiseerd testen:
– Een nieuw ontwikkelde applicatie.
– Een applicatie die aan veel wijzigingen onderhevig is.
– Een applicatie die weinig relaties heeft met andere applicaties.
– Applicaties in een weinig veranderende omgeving.
Indien een applicatie voldoet aan (bij voorkeur een combinatie van) de volgende kenmerken is deze WEL geschikt voor geautomatiseerd testen:
– Een applicatie met veel interfaces naar andere applicaties.
– Een applicatie in een omgeving die in beweging is.
– Een applicatie die aan weinig wijzigingen onderhevig is.
– Een applicatie die al enige tijd in productie is.
Voordelen
Indien aan alle voorwaarden voldaan is, levert geautomatiseerd testen zeker voordelen op. Een aantal belangrijke zijn:
– Voorspelbaar testresultaat.
– Snelle hertest ongewijzigde applicatie in gewijzigde omgeving.
– Testers blijven gemotiveerd; zij kunnen zich richten op de nieuwe applicaties en niet met het (soms eindeloos) hertesten van dezelfde testcases.
Conclusie
Is geautomatiseerd testen een utopie? Nee, indien de keuze tot stand gekomen is via een gedegen selectie-traject waarin de voors en tegens zijn afgewogen.
Carlo van Driel
Awareness-Groep
Aan de basis van een goede test liggen twee zaken
a. een testplan
b. capaciteit bij de deskundigen
Mijn ervaring is dat het maken van een testplan vaak niet in het projectplan voorkomt en dat als dat wel zo is, mn verschuivingen in de ontwikkeltijd de interne capaciteit nogal onder druk zet. Geautomatiseerd testen kan alleen als je voorspelbare resultaten hebt.
Userinterfaces en -interactie kun je alleen met echte mensen testen. M.n. onvoorspelbaar gedrag (of andere gewoontes) is de beste MonteCarlo-generator 😉
Beste Carlo,
Je noemt een aantal kenmerken die zouden maken dat een applicatie niet geschikt is voor geautomatiseerd testen, maar helaas leg je dat niet verder uit.
Ik pak er een uit: “Een applicatie die aan veel wijzigingen onderhevig is.” Ik zou denken: hoe vaker de applicatie wijzigt, hoe meer lol je hebt van je geautomatiseerde testset?
Groet, Frank
Beste Frank,
Hoe meer een applicatie aan veranderingen ondehevig is, hoe meer tijd je kwijt bent aan het aanpassen van je “geautomatiseerde” testscript en je testset. de tijdwinst wordt hierdoor gereduceerd tot 0.
Indien een applicatie weinig aanpassingen kent, zal er ook weinig gehertest hoeven te worden. Regressie kan immers alleen optreden bij wijzigingen.
Dus juist bij applicaties die vaak wijzigen en je dus vaak een regressietest zou moeten doen, is geautomatiseerd testen van toegevoegde waarde. Je wilt echter ook een geautomatiseerde test die onderhoudbaar is en gemakkelijk aanpasbaar is aan de wijzigingen zodat je daar zo min mogelijk tijd aan kwijt bent. En hiervoor zijn er wel degelijk oplossingen.
Als het gaat om onvoorspelbaarheid of de beleving van een gebruiker, blijft handmatig testen wel een welkom hulpmiddel. Een combinatie van geautomatiseerde functionele, technische (regressie) testen en handmatige gebruikerstesten lijkt me een ideale combi.
Een erg defensieve benadering voor geautomatiseerd testen. Maar niet onjuist.
Doel van een tool moet duidelijk zijn en dat zie je terug in de teststrategie. Specifieke tests vragen om tools. Dan moeten de tools het trouwens wel doen en dat valt ook niet altijd mee.
Ik mis een belangrijke voorwaarde in stap 1: namelijk: een gestructureerd testproces! Chaos automatiseren zal leiden tot geautomatiseerde chaos!
Daarnaast is het goed om bewust te zijn van de terugverdientijd van testautomatisering. Ik hoor/lees hierover verschillende verhalen. Maar reken iig op minimaal 4 maar vaker 5 tot 6 releases om het kostendekkend te maken. Overigens lijkt me kostenbesparing de slechtste reden om testen te automatiseren, dat lukt slechts in heel weinig gevallen.
Overigens heb ik vele plaatsen testautomatisering zien mislukken door de genoemde zaken, dus nuttige tips.
Maar testautomatisering kan wel degelijk erg succesvol zijn. Ook dat heb ik op (veel minder) plaatsen gezien.
Ben het eens met M@rtin: handmatig testen blijft absolute noodzaak in ieder project!
Misschien ook interessant om nog even het verhaal in wat bredere context te lezen. Ik kwam het tegen op de site waar de Test-M aanpak wordt beschreven.
Test-M site URL
en het verhaal is te vinden op de volgende download pagina
@ Carlo
Ik ben het niet helemaal met je eens over de zekerheid dat een applicatie NIET geschikt is voor geautomatiseerd testen en met name een “nieuw ontwikkelde applicatie”.
Dit is zeker het geval indien de watervalmethode als ontwikkelmethode wordt toegepast.
In een Agile ontwikkelproces daarentegen worden vaak vanaf het begin van een applicatie geautomatiseerde testtools toegepast en niet zonder reden. Er wordt vaker (soms dagelijks) een regressietest uitgevoerd en dus is het mogelijk om naast de handmatige testenuitvoering ook geautomatiseerd te testen.
Het gaat dus niet om of er een nieuwe applicatie gebouwd wordt, maar om de methode van ontwikkeling (Waterval of Agile)