De valkuilen van testautomatisering
Automatisering, flinterdun gesneden
Het valt niet te ontkennen dat testautomatisering een revolutie in softwaretesten teweeg heeft gebracht. En precies op tijd ook! In de huidige wereld van uiterst gedistribueerde, gecontaineriseerde en voortdurend bijgewerkte diensten zou zinvol softwaretesten zonder testautomatisering onmogelijk zijn.
We mogen ons gelukkig prijzen dat we zoveel geavanceerde geautomatiseerde testtools tot onze beschikking hebben. En, mag ik daaraan toevoegen, goed opgeleide QA-ingenieurs om ze in het ontwikkelingsproces in ieders belang te gebruiken.
Om de een of andere reden ligt het echter in de aard van onze industrie om zulke belangrijke vooruitgangen in mogelijkheden routinematig af te doen als rages, en die rages vervolgens om te zetten in betekenisloze woordsalades en slogans die robotachtig worden herhaald door managers uit het hogere management, opiniemakers en consultants die gewoon een excuus willen om niet meer over het probleem te hoeven nadenken. Of om snel geld te verdienen.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Zo vergaat het ook de doorbraken op het gebied van testautomatisering, die al snel zijn opgenomen in het simplistische verhaal: “we moeten gewoon al onze tests automatiseren! Nu meteen! En al onze testproblemen zijn opgelost!”
Dit is niet alleen een vreselijk idee, zelfs als het zou worden voorgesteld door mensen die het probleem serieus proberen te nemen en het niet gewoon willen vermijden. Het is ook verderfelijk, omdat het een verhaal is dat, door de mogelijkheid om diep na te denken over de integratie van automatisering in testinspanningen bij voorbaat uit te sluiten, het falen ervan verzekert. Dat is oneerlijk tegenover alle mensen, inclusief klanten, die afhankelijk zijn van het succes ervan.
In dit opzicht neemt testautomatisering gewoon een bijzonder geval over van de algemene benadering van SQA door mensen die het niet begrijpen en dat ook niet willen. Het wordt behandeld als een bulkproduct, niet als complexe expertise. Daarom horen mensen in QA steeds van het hogere management: “we hebben gewoon meer QA nodig!”, alsof er ergens een softwaredelicatessenwinkel is waar je QA per pond, flinterdun gesneden, kunt bestellen.
Daarom luidt de mantra nu: “we hebben gewoon meer automatisering nodig!”, zonder dat er wordt nagedacht over wat dat werkelijk zou betekenen in de context van jullie softwareontwikkelingsinspanningen. Als zodanig voedt dit discours de disfuncties van jullie organisatie. Het lost ze niet op.
Deze modieuze tendensen rechtstreeks proberen tegen te gaan is hetzelfde als proberen te voorkomen dat de zon opkomt. Of in dit geval ondergaat. De beste manier om weerstand te bieden is gewoon naar de vicepresidenten en consultants te knikken en te glimlachen, terug te gaan naar je hokje en de juiste manier te bedenken om automatisering toe te passen, en die ideeën vervolgens te presenteren als de briljante vondsten van je managers. Maar die les heb je waarschijnlijk al geleerd bij andere kwesties.
Laten we dat dan doen. Hier is mijn lijst met valkuilen bij het implementeren van testautomatisering, en manieren om die te beperken, zodat automatisering haar aanzienlijke belofte binnen jullie eigen testinspanningen kan waarmaken.
Reikwijdte van automatisering
De belangrijkste vraag die je aan het begin moet beantwoorden, is waar geautomatiseerd testen binnen jullie testinspanningen de meeste waar voor zijn geld oplevert. De tijd nemen om dit te bepalen bespaart je later heel veel kopzorgen.
Het antwoord op deze vraag komt neer op de vraag welk deel van jullie tests moet worden geautomatiseerd en welk deel handmatig moet blijven. Dit kan verrassend zijn om te horen voor degenen onder jullie die onophoudelijk worden overspoeld door het evangelie van “automatiseer alle tests!”. Trek je daar echter niets van aan; deze mensen weten niet waar ze het over hebben.
Al jullie tests automatiseren - ervan uitgaande dat dit überhaupt mogelijk is - zou een vreselijke beslissing zijn die alleen maar tot een ramp voor jullie testinspanningen kan leiden.
Er zijn geweldige dingen die automatisering kan doen en die handmatig testen niet kan, of op zijn minst niet zo snel en herhaaldelijk. Maar het omgekeerde is ook waar. Er zijn dingen die alleen handmatig testen goed kan doen en die automatisering niet kan. Wat zijn die dingen in elk geval?
Waar handmatig testen uitblinkt ten opzichte van geautomatiseerd testen, is simpelweg de menselijke factor. Het voordeel van een echte persoon die geduldig diepgaand verkennend test, kan niet door automatisering worden nagebootst. En ik heb het niet alleen over het ontdekken van softwarefouten.
Iedereen kan softwarefouten vinden. Klanten doen dat voortdurend gratis. De toegevoegde waarde van een professionele QA’er is dat intuïtieve gevoel voor hoe je een stuk software kunt laten ontsporen, vooral als het gaat om het bepalen hoe klanten de software kunnen gebruiken op manieren waarvoor deze nooit is ontworpen en die toch - vaak met catastrofale gevolgen - mogelijk blijken.
Een ander voordeel van handmatig testen is dat een handmatige tester, zodra die een softwarefout heeft gevonden, onmiddellijk kan beginnen met het bepalen van de reikwijdte en ernst ervan. Dat wil zeggen: het afbakenen van de testcontexten (besturingssystemen, werkstromen, interacties tussen diensten en afhankelijkheden) waarin de softwarefout zich specifiek voordoet, en die waarin dat niet het geval is.
Geautomatiseerde testscripts kunnen dit helemaal niet goed en vanuit het oogpunt van een software-ingenieur is dit juist de cruciale informatie die nodig is om een softwarefout te diagnosticeren en op te lossen. Een foutrapport waarin alleen staat: “ik deed dit en toen gebeurde dit slechte ding” is voor hen nutteloos.
Handmatig testen is in feite veel tijdefficiënter bij het leveren van deze informatie en is, omdat het inherent interactief is en op het moment zelf met het ontwikkelteam plaatsvindt, veel rijker aan informatie wat betreft feedback en analyse van de hoofdoorzaak.
Ja, Virginia, handmatig testen is niet altijd de minst efficiënte en meest tijdrovende manier om softwarefouten te vinden, te diagnosticeren en op te lossen, en om de oplossingen ervan te valideren (of niet).
Waar automatisering echter een duidelijk voordeel heeft, is bij continu testen van uptime en stabiliteit—met name voor gedistribueerde systemen. Dit staat nu veel centraler gezien onze huidige ontwikkelcontext van continue integratie en implementatie in realtime in gedistribueerde omgevingen.
Automatisering is ook efficiënter bij wat je “testen in bulk” zou kunnen noemen, waarbij je een enorme matrix van duizenden systeemcondities en hun variabelen hebt die moeten worden afgedekt om te zien of een ervan volledig defect is of het systeem zal laten uitvallen.
De vuistregel die je moet gebruiken om je ontwerpen te sturen bij het bepalen waar je handmatig of geautomatiseerd testen prioriteit geeft, is deze:
Handmatig testen heeft meestal de voorkeur voor het eerste testen van nieuwe functies en mogelijkheden. Geautomatiseerd testen is duidelijk het beste voor continue algemene regressietests en voor belasting- en prestatietests.
Gedurende de levenscyclus van een product of dienst moet het testen van dezelfde mogelijkheid evolueren van handmatig naar geautomatiseerd. Het is een continuüm van de levenscyclus van een mogelijkheid. Geen Chinese muur die nooit mag worden doorbroken, waarbij geen van beide kanten hoeft te weten wat er aan de andere kant gebeurt. De standaardaanname moet zijn dat wat vandaag handmatig wordt getest, in de loop van de tijd moet overgaan naar geautomatiseerd testen.
Kwalificaties van een automatiseringsengineer
Het is wellicht onvermijdelijk dat bij het aannemen van engineers voor geautomatiseerd testen, de belangrijkste gewenste kwalificaties het vaardigheidsniveau van de kandidaten zijn in (a) de automatiseringstools die zij geacht worden te gebruiken, en (b) de testscripttalen die door die tools worden gebruikt.
Maar als dit de enige kwalificaties zijn waarop je je richt, maak je een grote fout. Dit zijn noodzakelijke, maar nauwelijks voldoende kwalificaties voor de rol van automatiseringsengineer.
Waarom? Om de eenvoudige reden dat weten hoe je een automatiseringstool gebruikt en hoe je scripts maakt in de bijbehorende scripttaal je precies niets vertelt over hun begrip van QA zelf.
Helaas zie ik bijna nooit automatiseringsengineers die deze opleiding of achtergrond hebben. Ze worden simpelweg aangenomen omdat ze scriptwizards zijn, niet omdat ze vaardig zijn in het ontwerpen van een effectieve, diagnostische test.
Deze kwalificaties zijn in feite belangrijker dan ervaring met de automatiseringstools en talen die zij zullen gebruiken. Die kunnen ze gemakkelijk leren als dat nodig is. Maar het kost enorm veel tijd en inspanning om iemand te leren hoe je tests ontwerpt en de resultaten ervan interpreteert.
Het zou feitelijk beter zijn om gewoon een ervaren analist die je al in huis hebt op te leiden in de benodigde automatiseringstools. Deze automatiseringsvaardigheden zijn immers inmiddels gemeengoed. De intuïtie en het inzicht van een ervaren tester zijn dat niet.
Onwetendheid automatiseren geeft je alleen sneller en herhaalbaarder onwetendheid en ondermijnt de efficiëntie die je met geautomatiseerd testen zocht.
Ontwerpnormen voor automatisering
Het spreekt voor zich dat je, als je aan een grootschalige testautomatiseringsinspanning begint, eerst algemene normen moet definiëren waaraan alle automatisering moet voldoen om voor gebruik bij het testen te worden geaccepteerd. Toch lijkt het, zoals bij veel vanzelfsprekendheden, alsof er minder verstandige mensen zijn dan je zou verwachten.
Dit zijn de onderwerpen die deze normen moeten omvatten.
Begrijpelijkheid
Een van de frustrerende mysteries van softwareontwikkeling is hoe ambachtelijk die uiteindelijk blijkt te zijn. Het komt helaas helemaal niet zelden voor dat een software-engineer je vertelt dat hij een bug niet kan oplossen omdat hij de code waarin die voorkomt niet heeft geschreven. Het is alsof code die door een andere engineer is geschreven, in een vreemde taal staat die hij niet begrijpt.
Dit komt helaas even vaak voor binnen engineering voor testautomatisering. Ik kan je niet vertellen hoe vaak een QA-engineer me heeft gezegd dat hij een onderdeel van testautomatisering niet kan bijwerken voor een belangrijke productupgrade omdat hij het niet heeft geschreven en het daarom niet begrijpt en ook niet kan begrijpen. O ja, en de engineer die het had geschreven, had het bedrijf twee maanden geleden verlaten.
Dit is bij geautomatiseerde testscripts nog minder acceptabel dan bij nieuwe softwarecode die ontwerplogica implementeert en niet alleen bepaalde stappen laat uitvoeren. Toch komt het verbazingwekkend vaak voor.
Dit betekent dat je, voordat je een dozijn QA-engineers aanneemt en ze vrolijk honderden geautomatiseerde testscripts laat produceren, ervoor moet zorgen dat je eerst algemene normen voor begrijpelijkheid hebt gedefinieerd en daarin training hebt gegeven.
Het moet een vereiste zijn dat alle testscripts onderling begrijpelijk zijn voor al je QA-engineers, zodat je uiteindelijk niet voor het onderhoud ervan afhankelijk bent van één enkele, vaak tijdelijke medewerker.
Definieer en handhaaf een beoordelings- en acceptatieproces voor alle kandidaten voor geautomatiseerde scripts aan de hand van deze normen voordat ze bij het testen kunnen worden ingezet.
Onderhoudbaarheid
Onderhoudbaarheid hangt nauw samen met het probleem van begrijpelijkheid, maar de twee zijn logisch en operationeel van elkaar gescheiden. Een testscript kan gemakkelijk worden begrepen door testengineers die het niet hebben geschreven en toch zo zijn gestructureerd dat het een nachtmerrie is om bij te werken of aan te passen.
Hier is een voorbeeld uit de praktijk.
Bij een van mijn werkgevers bereidden we de testinspanning voor een upgrade van gemiddeld niveau van hun belangrijkste product voor. Er was een releasecyclus van vier weken gepland, wat in dit geval eigenlijk redelijk was.
Toen ik de benodigde testinspanning plande, realiseerde ik me dat we ook het belangrijkste geautomatiseerde regressietestscript zouden moeten bijwerken. Toen ik de lead-QA-engineer vroeg hoe lang die update zou duren, antwoordde hij: “acht weken”. Twee keer zo lang als de volledige release! Zelfs als je rekening houdt met de zonde van engineers om schattingen op te blazen, was dit extreem.
Ik liet enkele andere testengineers het script en de schatting beoordelen. Ze waren het er allemaal over eens dat het script op zo'n onhandige en ineffici manier was geschreven, dat het vele weken van nauwgezet herschrijven van het volledige script zou kosten om het voor de volgende release bij te werken, ook al waren de updates zelf geen fundamentele herschrijvingen van het product.
Die situatie was een klassiek voorbeeld van een zonde uit de software-engineering die naar de test-engineering was overgeheveld. Het is tijd om een einde te maken aan deze waanzin.
Mijn advies hier is identiek aan het advies dat ik hierboven gaf over het probleem van begrijpelijkheid. Laat je QA-engineers onder geen enkele omstandigheid wegduiken in hun test-engineeringgrotten en een week of twee later tevoorschijn komen met iets dat misschien als test werkt, maar waarvan het bijwerken binnen een redelijke termijn een nachtmerrie van zinloos lijden zal zijn.
Stel normen op voor de mogelijkheid om tijdig updates uit te voeren en creëer een beoordelings- en acceptatieproces om te waarborgen dat hieraan wordt voldaan. Dit kan eenvoudig worden samengevoegd met dezelfde inspanningen om begrijpelijkheid te waarborgen, zodat alles onderdeel kan zijn van hetzelfde beoordelingsproces.
Je QA-engineers zijn geen schilders uit de renaissance en je vraagt ze niet om de Sixtijnse Kapel opnieuw te schilderen. Het zou geen leven lang moeten duren.
Testrollen en testautomatisering
Een van de inefficiëntiepatronen die een soepele en vruchtbare integratie van automatisering in je testinspanning als geheel belemmert, is de onjuiste veronderstelling dat elke stap in het geautomatiseerde testproces binnen de automatiseringsgroep zelf moet plaatsvinden.
Dit is nog een vergissing. Hoewel het in dit geval niet helemaal een voor de hand liggende is.
Automatiseringstechnici zijn waarschijnlijk de best betaalde medewerkers in je team, dus hun tijd is kostbaar. Bovendien zal het volume aan testscripts dat door dat team moet worden gemaakt en voortdurend bijgewerkt in de loop der tijd alleen maar groeien, terwijl je groep testengineers bij lange na niet snel genoeg zal kunnen groeien om dit bij te houden. Zelfs niet als je voor Google werkt.
Het is dan ook operationeel zinvol om enige arbeidsverdeling aan te brengen tussen het automatiseringsteam en de rest van je team. Meer specifiek gaat het om de verdeling tussen medewerkers die geautomatiseerde scripts en hulpmiddelen maken en onderhouden, en degenen die de geautomatiseerde tests daadwerkelijk uitvoeren.
Duidelijk is dat eerstgenoemde verantwoordelijkheden alleen door het automatiseringsteam zelf kunnen worden uitgevoerd. Daarvoor zijn ze uiteindelijk ook in dienst genomen. Dat geldt echter niet voor de laatstgenoemde.
Er is geen reden waarom analisten niet ook zelfstandig geautomatiseerde tests zouden kunnen uitvoeren en de resultaten ervan zouden kunnen interpreteren.
Heel weinig mensen denken in deze termen, maar deze arbeidsverdeling is volkomen logisch. Om te beginnen maakt ze een aanzienlijke hoeveelheid tijd vrij, zodat de automatiseringstechnici zich kunnen richten op het creëren van nieuwe automatisering.
Daarnaast versterkt dit de hierboven gedefinieerde vereiste van begrijpelijkheid. Als automatisering centraal staat in je testinspanning, dan moet het ook centraal staan dat iedereen in je testteam, wel of geen automatiseringstechnicus, je geautomatiseerde tests moet kunnen begrijpen en gebruiken. Zelfs handmatige testers.
Zo'n systeem van rolverdeling zal de flexibiliteit van de beschikbare medewerkers binnen je volledige QA-team aanzienlijk vergroten en daardoor ook efficiëntie in tijd en planning creëren die anders niet zou bestaan.
Tot slot
Het ontwikkelen van een robuuste capaciteit voor geautomatiseerd testen, zoals hierboven gedefinieerd, is tegenwoordig simpelweg noodzakelijk. Zonder deze capaciteit kun je niet spreken van professionele, effectieve QA.
Toch beginnen veel veelbelovende avonturen vol enthousiasme en blijdschap, om vervolgens aan het einde van de reis in een nederlaag te eindigen. Ik zie dit in zeer veel gevallen gebeuren binnen QA met betrekking tot testautomatisering.
Het probleem is dat je relatief gemakkelijk in geautomatiseerd testen kunt duiken. Het is duur, maar in elk geval gemakkelijk om te doen alsof je je inspant. Geautomatiseerd testen kan echter ook een afgrond zijn waar je, net als Wile E. Coyote in de Roadrunner-tekenfilms, gedachteloos vanaf rent en valt zodra je de moeite neemt om naar beneden te kijken.
Het moet vanaf het begin duidelijk zijn dat testautomatisering een levenscyclus heeft. Elk testscript heeft een levenscyclus van maanden, zo niet jaren.
Het gaat niet alleen om het schrijven van een aantal geautomatiseerde testscripts die aan al je behoeften voldoen voor het product in zijn huidige ontwikkelingsstadium. Het gaat erom hoe je al die automatisering naadloos kunt laten meegroeien naarmate het product zich gedurende zijn eigen levenscyclus ontwikkelt.
Als je de problemen rond de reikwijdte van automatisering, kwalificaties van QA-engineers, begrijpelijkheid, onderhoudbaarheid en rolbepaling negeert, zul je merken dat na verloop van tijd al die automatiseringsinspanningen een witte olifant en een bodemloze put zijn geworden die onmogelijk te begrijpen of te onderhouden is.
En al het geld dat je eraan hebt besteed, zal verspild zijn. Iets wat de bazen van je bazen zeker zullen opmerken.
Aan de andere kant zul je, als je het advies dat ik hierboven geef opvolgt en dit natuurlijk aanpast aan de specifieke kenmerken van je eigen uitdagingen en situatie, deze verouderingscrisis grotendeels vermijden en jarenlang de vruchten plukken van productieve testautomatisering.
Zoals altijd: veel succes.
Gerelateerde artikelen:
- 10 BESTE TOOLS VOOR HET MONITOREN VAN WEBSERVERS
- BESTE PRAKTIJKEN VOOR AUTOMATISERING IN DIGITALE TRANSFORMATIE
Ook de moeite waard: WAT IS MABL? OVERZICHT EN RONDLEIDING DOOR DE FUNCTIES
