Als we het hebben over ‘automatisch testen’ dan spreken we over testautomatisering. Wat is testautomatisering nou eigenlijk? Wat zijn de kenmerken ten opzichte van handmatige testen? En is het verstandig om over te gaan op automatisch testen? De definitie van automatisch testen is het automatiseren van testen op specifieke interfaces waarvan is onderkend dat deze efficiënter door computers dan met de hand uitgevoerd kunnen worden.
Bovenstaande is een feit. Natuurlijk wil je als tester niet continu testcases doorlopen en niet telkens hetzelfde blijven testen. Handmatig testen is tijdrovend en arbeidsintensief. Vraag je als tester daarom af of je de testen beter kunt uitvoeren bij gebruik van testautomatisering. Als we kijken naar hedendaagse testtools die het mogelijk maken om automatische testen te realiseren is het natuurlijk ideaal om hie van gebruik te maken. Zo kun je bijvoorbeeld met één druk op de knop, zeer snel rapportages genereren, bevindingen aanmaken en aan elkaar linken, installaties vergelijken . Met andere woorden ‘The sky is the limit’. Je hebt zoveel mogelijkheden wat testen betreft.
Het voornaamste verschil tussen handmatig testen en automatisch testen is dat er met handmatig testen meer gebreken worden gevonden. Dit is eigenlijk niet zo gek, omdat je behalve de testcase die je voor je hebt en aan het uitvoeren bent ook op andere zaken let. Denk hierbij aan foutieve spelling, de performance, verkeerde opbouw van schermen en andere van dit soort zaken. Alles waar je als goede tester op moet letten. Met handmatig testen kijk je verder. Tijdens automatisch testen worden de testcases specifiek doorlopen en gebeurt dit stap voor stap. Dit zijn meestal load-, stress- of unittesten die niet handmatig kunnen worden uitgevoerd. Testen die vaak herhaald moeten worden zoals regressietesten.
Projectmanagers die testautomatisering willen gaan doorvoeren moeten zich afvragen waarom ze het willen, of het niet te duur is, of ze geen specialisten willen inhuren en of testers hier een training voor moeten volgen.
Om antwoord te geven op dit soort vragen zal er een onderzoek gedaan moeten worden. Zo’n onderzoek kun je als testmanager zelf doen, maar je kunt er ook iemand voor inhuren. Als je iemand inhuurt, moet je je wel afvragen of deze persoon te vertrouwen is. Hoe weet je of deze persoon geen commerciële belangen heeft bij deze testtool?
Het is daarom belangrijk om eerst zelf onderzoek te doen en daarna pas iemand anders, bijvoorbeeld een test-collega van een andere afdeling, er naar te laten kijken. Wanneer dit gedaan is en men ervan overtuigd is dat automatisch testen een toegevoegde waarde is voor het project, kan er verder gekeken worden en besloten worden welke testtool geïmplementeerd wordt.
Automatisch testen, een apart onderdeel
Om testautomatisering succesvol toe te passen is het noodzakelijk om allereerst te starten met het structureren en beheren van test data, waarmee zowel handmatig als automatisch testen uitgevoerd kunnen worden. Dit is meestal de grootste efficiëntieverbetering gedurende de lifecycle van een testtraject. Bij automatisch testen denken mensen vaak dat dit onderdeel is van de reguliere testen die plaats vinden in een test traject. Dit is niet zo.
Het is belangrijk om de automatische testen niet te combineren met de handmatige testen, tenzij budget, resources en tijd geen probleem zijn testautomatisering is een project op zich, omdat hierbij meerdere activiteiten moeten worden uitgevoerd. Denk hierbij aan planning, voorbereiding, specificeren, uitvoeren, en afronding.
Een standaard
Ongeacht de grootte van een project, ben ik ben van mening dat ‘testautomatisering' een toegevoegde waarde is voor een testproject en dat dit een standaard dient te worden binnen een testproject. Niet alleen voor de automatische testen, maar ook voor de andere toepassingen die een test tool kan bieden is het verstandig om dit aan te schaffen.
Helaas worden veel projecten nog steeds alleen maar handmatig getest waardoor de kwaliteit achter loopt. Veel zaken wordt niet opnieuw getest, omdat dit al eerder is getest of omdat er geen tijd meer is. Men is bang om iets nieuws toe te passen of men vindt het te duur om een test tool aan te schaffen. Helemaal in iteratieve projecten waar heel vaak hetzelfde moet worden getest is het verstandig om gebruik te maken van een test tool.
Brahim,
Je haalt een zeer interesant topic aan. Vaak wordt er in dit soort scenario’s puur naar de kosten gekeken. Dit heeft vaak ook negatieve invloed op de kwaliteit.
Ik kan mij goed vinden in de oplossing die je zelf al aanhaalt. Beide vormen van testen hebben voor- en nadelen.
Als je dit in bepaalde omgevingen met elkaar combineert of afwisselt maak je gebruik van de sterke punten van beide manieren.
Brahim, zoals Ruud al zei: een interessant topic. Altijd goed voor veel discussie. Mijn reactie op een aantal zaken die je noemt:
“De definitie van automatisch testen is het automatiseren van testen…”. Ik haal graag dit artikel Michael Bolton aan als het gaat om testen en test automatisering. Testen zijn niet te automatiseren. Checks wel.
Je zegt: “Handmatig testen is tijdrovend en arbeidsintensief. Vraag je als tester daarom af of je de testen beter kunt uitvoeren bij gebruik van testautomatisering.” Volgens mij is testen noodzakelijk om de redenen die je later zelf noemt: “… omdat je behalve de testcase die je voor je hebt en aan het uitvoeren bent ook op andere zaken let.” Een testtool kan alleen checks uitvoeren, een mens kan veel meer en dat is de toegevoegde van testen. Een computer kan bijv. ook niet controleren of de gebruiker zijn werk kan doen met de software.
Testautomatisering kan veel meer zijn dan alleen maar tools inzetten om test cases te automatiseren. Testautomatisering moet de focus hebben om testen makkelijker en sneller te maken, zeker niet om testers te vervangen. Regressietesten en unit testen zijn inderdaad prima “testen” die we zouden kunnen automatiseren. En in software ontwikkel trajecten waar we in korte iteraties werken, is testautomatisering een must.
Developers kunnen testers helpen om beter en sneller te testen. Zij zijn in staat om fantastische tooling, scripts en logging te bouwen die het de tester makkelijk maken. Praat er eens over met je team. De mogelijkheden zijn eindeloos!
Je hele betoog dat testautomatisering een apart onderdeel moet zijn maar ook de afweging of testautomatisering zinvol is, snap ik niet. Testautomatisering zou een integraal onderdeel van een project moeten zijn. Uiteraard is een Proof of concept handig als je dure en complexe tooling (zoals Quality Centre en Quick Test Pro van HP) wilt inzetten. Maar ik vraag me af waarom je dat zou willen. Er zijn volgens mij goedkope tools op de markt die flexibeler zijn en beter passen in de context van je project.
In de laatste alinea zeg je: “Helaas worden veel projecten nog steeds alleen maar handmatig getest waardoor de kwaliteit achter loopt”. Over welke kwaliteit heb je het hier? Ik kan me genoeg projecten voorstellen die prima te testen zijn zonder enige vorm van testautomatisering.
Je zegt: “Helemaal in iteratieve projecten waar heel vaak hetzelfde moet worden getest is het verstandig om gebruik te maken van een test tool.”. Het is niet de tool die testautomatisering succesvol maakt, het is het team! Want: a fool with a tool is still a fool. In veel gevallen zijn oplossingen dichterbij dan we denken: onze developers! Testers grijpen te snel naar testautomatisering met (dure) experts. Met open source tooling, eigen ontwikkelde tooling, scripts is testautomatisering in veel gevallen prima te doen. Daarbij pleit ik graag voor veel aandacht voor testabilitytijdens het gehele project door het hele team.
Helaas laat het CMS geen HTML hyperlinks toe. Daarom nog even de links naar de artikelen die ik aanhaal in mijn reactie hierboven:
1e alinea:
Testing vs. checking: http://www.developsense.com/blog/2009/08/testing-vs-checking/
Laatste alinea:
Testabilty: http://www.developsense.com/blog/2009/07/testability/
Brahim,
ik ben het voor het overgrote meerendeel eens met Huib, daarnaat heb ik nog een puntje. Je stelt het volgende:
“Projectmanagers die testautomatisering willen gaan doorvoeren moeten zich afvragen waarom ze het willen, of het niet te duur is, of ze geen specialisten willen inhuren en of testers hier een training voor moeten volgen.
Om antwoord te geven op dit soort vragen zal er een onderzoek gedaan moeten worden. Zo’n onderzoek kun je als testmanager zelf doen, maar je kunt er ook iemand voor inhuren. Als je iemand inhuurt, moet je je wel afvragen of deze persoon te vertrouwen is. Hoe weet je of deze persoon geen commerciële belangen heeft bij deze testtool?
Het is daarom belangrijk om eerst zelf onderzoek te doen en daarna pas iemand anders, bijvoorbeeld een test-collega van een andere afdeling, er naar te laten kijken. Wanneer dit gedaan is en men ervan overtuigd is dat automatisch testen een toegevoegde waarde is voor het project, kan er verder gekeken worden en besloten worden welke testtool geïmplementeerd wordt.”
Ben je niet erg bang dat je hiermee een testmanager voor een onmogelijke taak stelt? Ik ben het eens dat je moet uitkijken bij het inzetten van externen voor tool-bias, maar dat is erg makkelijk op te vangen door een onafhankelijk iemand te laten komen.
Mijn voornaamste bezwaar tegen je bovenstande stuk is dat je hier een testmanager zonder voorkennis van testautomatisering een waarde oordeel gaat laten vellen over iets wat hij nog nooit gedaan heeft, waar hij geen ervaring mee heeft en dus waar hij geen waarde oordeel over kan vellen.
Ik vind dat een erg gevaarlijk idee, daar je daarmee het falen van testautomatisering in de hand werkt.
Hoe weet je als testmanager dat een specifieke tool, die jou aangeraden is door een forum, of een collega, of een sales meneer, inderdaad de tool is die je nodig hebt? Hoe weet je of je test automation architectuur inderdaad geschikt is voor wat je hoopt te bereiken?
Kortom, in mijn ogen: als je zelf eerder test automation implementaties en tool selecties hebt gedaan, zeker zelf doen. Als je dit nog nooit hebt gedaan, haal er alsjeblieft een externe bij, maar let er wel op dat het een externe is zonder tool-bias (en die zijn nooit te vinden bij de tool vendor!!).
Dit is heel interessante discussie, over een onderwerp waar heel veel over te schrijven valt. Ik zal er daarom ook niet heel veel aan toevoegen, maar…
Brahim sluit af met ‘[..] in iteratieve projecten waar heel vaak hetzelfde moet worden getest is het verstandig om gebruik te maken van een test tool.”
Dit is wat zwak uitgedrukt: In iteratieve (of Agile) projecten is het onontkoombaar dat er automatische regressietesten worden uitgevoerd. En dat het specificeren van uit te voeren testen standaard onderdeel wordt van het ontwikkelen. Alleen dan is het mogelijk om kort cyclisch op te leveren en snelle feedback te krijgen.
In die omstandigheden is testautomatisering geen optie, maar een must. En dat sluit handmatig testen niet uit.
Even een reactie, ben zelf veel bezig met test automatisering dus sowieso redelijk interessant.
Vooral: automatisch testen zal nooit handmatig testen vervangen, met nooit bedoel ik in ieder geval niet binnen afzienbare tijd. Naast kunstmatige intelligentie zou dat alleen kunnen met perfecte requirements/ontwerp, wat ik eigenlijk ook niet zie gebeuren. Sterker nog, ik denk dat kunstmatige intelligentie makkelijker te realiseren is.
Volledig automatisch checken zou wel theoretisch moeten kunnen, behalve dat dat ontzettend veel werk is en waarschijnlijk een niet al te beste kosten/baten verhouding biedt.
Met deze stelling in het achterhoofd betekent dat dat er altijd handmatig getest zal worden. Al is het wel zo dat automatisch testen het handmatig testen kan aanvullen, de ‘stomme checks’ weg automatiseren. Een voorbeeld: ik heb wel eens een methode geprogrammeerd waar elke wijziging betekende dat er 40+ testcases moesten worden uitgevoerd met een goed voorspelbare uitkomst (begon met 4). Uiteraard gebruik je dan een unit test framework en automatiseer je dat. Waarom zou je dat handmatig willen doen?
Ander voorbeeld is een database conversie test, een paar dagen programmeren en ik had ‘18,5 miljoen testcases’ (los van de discussie ‘wat is een testcase’). Deed dit toen voor mijn eigen vermaak, opdracht was om een steekproef van +/- 100 dossiers te testen, dat werden er 250.000. Automatisch checken (invoer en verwachte uitvoer zijn bij databases bekend namelijk) is dan zeer waardevol.
Belangrijk is het om te richten op datgene dat belangrijk is. Als voorbeeld: niet controleren of knopjes dat door een framework geleverd worden het doen (daar is uiteindelijk die framework voor. Dat is als het goed is al getest) maar of de acties van dat knopje leiden tot het verwachte resultaat.
Daarnaast ontwikkel ik steeds vaker TDD, aangezien ik zelf weet wat datgene dat ik ga maken moet doen werkt dat prima. Eerst vaststellen wat er moet gebeuren, tests maken, daadwerkelijk programmeren, tests draaien, alle tests groen = klaar. Ik mis daarom ook heel erg unit testen in je verhaal, een ‘makkelijke’ manier om zeer veel van datgene dat uiteindelijk belangrijk is te testen (‘business logic’).
Daarnaast, ik denk niet een project of testmanager over het algemeen een goede beslissing kan maken over welke testtool te gebruiken. Het is namelijk makkelijk om een situatie/demo te creeren waarbij (OSS) tools geweldig goed werken, totdat er daadwerkelijk iets getest moet worden.
Niemand is onpartijdig; de kans dat ik als ‘onafhankelijek externe’ een tool van welke leverancier dan ook zal aanraden is net zo groot als de kans dat een toolleverancier een OSS oplossing aan zal raden. Zelf heb ik namelijk een ongefundeerde afkeer voor alle commerciele tools, teveel slechte ervaringen. Gebruik liever opensource of zoals hierboven genoemd ‘scripts’. Ben daarin het type ontwikkelaar dat Huib omschrijft.
Om op te sommen, automatiseer elke test dat voorspelbaar is, voer een Proof of Concept uit met meerdere tools en vergelijk de mogelijkheden. Haal hierbij een onafhankelijke specialist bij als dat nodig is.
@Daniel
Je zegt: “volledig automatisch checken zou wel theoretisch moeten kunnen, behalve dat dat ontzettend veel werk is en waarschijnlijk een niet al te beste kosten/baten verhouding biedt. Met deze stelling in het achterhoofd betekent dat dat er altijd handmatig getest zal worden. Al is het wel zo dat automatisch testen het handmatig testen kan aanvullen, de ‘stomme checks’ weg automatiseren”.
Volledig automatisch checken kan theoretisch zeker. En de kosten/baten zullen zeker niet positief uitvallen. Dus dat moeten we vooral niet doen, eens! Maar je lijkt voorbij te gaan aan het feit dat testen noodzakelijk is. Testen is denkwerk dat niet door een computer gedaan kan worden. Nooit.
Ik ben het eens dat we zoveel mogelijk moeten proberen de domem checks te automatiseren. Hoewel afhankelijk van de context, durf ik te stellen dat we dit hoofdzakelijk in unit testen door de developers moeten laten doen.
Brahim,
Dank, leuk artikel.
Ik ondersteun met name heel nadrukkelijk je punt dat je van tevoren helder moet vaststellen WAAROM je testautomatisering wilt toepassen (kwaliteit verhogen? sneller kunnen testen? goedkoper kunnen testen? veel herhaling van testen?) en dat je dit daadwerkelijk onderzoekt op haalbaarheid.
Ik kom te vaak in de praktijk tegen dat testautomatisering wordt geimplementeerd om te scoren (‘kijk ons eens modern zijn!’), of vanuit de mythe dat geautomatiseerd testen per definitie goedkoper is omdat computers nu eenmaal sneller ‘denken’ dan mensen. Dat is niet (per definitie) de werkelijkheid. Ik heb diverse trajecten meegemaakt waarin zonder een goede impactanalyse gestart is en de kosten nooit worden terugverdiend, met als dieptepunt een SAP project met Java GUIs waarin een jaar SAP-TAO testautomatisering (miljoenenbedrag) in de prullenbak is beland omdat eigenlijk al onderstaande ‘vaak vergeten’ punten niet van tevoren zijn onderzocht.
Over het algemeen is het maken van testspecificaties en de testnavigatie een flink stuk bewerkelijker en duurder dan bij handmatig testen en ga je pas winst maken (tijd, geld, kwaliteit) tijdens de uitvoerfase, omdat uitvoer in de regel minder tijd kost. Dat betekent dat er ergens in de toekomst een break-even punt ligt. Pas na dat punt wordt testautomatisering goedkoper wordt dan handmatig testen. Als geld de drijfveer is, doe je er goed aan om dit (te proberen) te berekenen. Daarbij moet je rekening houden dat ook rework wordt meegenomen. In een applicatie waarin wijzigen gemaakt worden zul je ook je geautomatiseerde tests moeten wijzigen.
Een betere driver in mijn ogen is kwaliteit. Denk inderdaad aan Agile-projecten (zoals Jaap al aangeeft) waarin het in veel gevallen onontbeerlijk is om testen veel en vaak te herhalen. Ook tijd kan daarbij een belangrijke factor zijn.
Voordelen kunnen zijn:
– efficientie en effectiviteit (testers worden beu en slordig van steeds hetzelfde rondje-om-de-kerk);
– uitvoersnelheid ligt doorgaans hoger;
– KAN goedkoper zijn;
– kan gebruikt worden om in korte tijd grote volumes testdata aan te maken;
– nuttig als vaste test met bijvoorbeeld dagelijkse frequentie (Agile projecten, applicaties met een dusdanig belang dat een dagelijkse controleslag gewenst is);
Nadelen kunnen zijn:
– Testautomatiseringstools hebben geen intuitie (zoals Huib al aangeeft: testen dus niet, maar voeren checks uit);
– Testautomatiseringstools doen zoals Brahim al aangeeft geen impliciete waarnemingen;
– Testautomatiseringstools gebruiken een vaste pool met data, waardoor toevalligheden (een bepaald probleem treedt enkel met account x op) niet opvallen.
Vaak vergeten worden:
– dat sommige delen van het integrale proces niet te automatiseren zijn, denk aan de batchverwerking die moet plaatsvinden om een bancaire overschrijving ook definitief in de systemen in te boeken. Denk ook aan acties die omwille van het end-to-end-proces in aanpalende (externe) systemen moeten plaatsvinden die niet geautomatiseerd kunnen of mogen worden.
– testdata: grote hoeveelheden data aanmaken is tijdrovend!
– testdata: de wachtwoorden van de tweeduizend performancetestaccounts verlopen elke drie weken en de testers kunnen deze zelf niet resetten;
– testdata: wijzigende testdata-sets kunnen voor veel ellende zorgen mbt rework en navigatie-aanpassingen leiden, waardoor de terugverdientijd langer (of onmogelijk wordt). Gelukkig worden testautomatiseringstools en -aanpakken steeds flexibeler op dit aspect.
– met name wijzigingen aan de code en navigatie van de tests zijn duur
– sommige platformen zijn lastig te automatiseren, bijvoorbeeld omdat schermattributen en veldnamen dynamisch gegenereerd worden en elke release kunnen verschillen;
– analyse van de automatische testresultaten is deels handwerk
Daarom is van tevoren weten wat en waarom je meet heel belangrijk.
@Huib
Zie nu pas dat er is gereageerd (had mijn reactie zonder account geplaatst)
Wil alleen duidelijk stellen dat ik nooit zal zeggen dat er niet handmatig getest hoeft te worden, sterker nog. Mijn reactie begint zelfs met “Vooral: automatisch testen zal nooit handmatig testen vervangen”
En dat zeg ik als fanatieke test automatiseerder. Begrijp vooral niet hoe ik die indruk heb gewekt.