Faldgruber ved testautomatisering

Automatisering, tyndt skåret

Det kan ikke benægtes, at testautomatisering har revolutioneret softwaretest. Og det var også på høje tid! I dagens verden med ultradistribuerede, containeriserede tjenester, der opdateres kontinuerligt, ville meningsfuld softwaretest være umulig uden den.  

Vi er så heldige at have så mange sofistikerede værktøjer til automatiseret test til rådighed. Og, må jeg tilføje, veluddannede QA-ingeniører til at bruge dem til alles fordel i udviklingsarbejdet.

Men af en eller anden grund ligger det i vores branches natur rutinemæssigt at reducere så betydelige fremskridt i kapacitet til modeluner og derefter forvandle disse modeluner til meningsløse ordsalater og slagord, der robotagtigt gentages af ledere på øverste niveau, forståsigpåere og konsulenter, som blot ønsker en undskyldning for at holde op med at tænke over problemet. Eller for at tjene hurtige penge.  

Sådan er det også med gennembruddene inden for testautomatisering, som hurtigt er blevet indlemmet i den reduktionistiske fortælling om, at “vi skal bare automatisere al vores test! Lige nu! Og så bliver alle vores testproblemer løst!”

Det er ikke alene en frygtelig idé, selv hvis den blev fremsat af mennesker, der forsøger at tage problemet alvorligt og ikke blot undgå det. Den er også skadelig, fordi det er en fortælling, der ved at lukke af for muligheden for at tænke grundigt over, hvordan automatisering integreres i testindsatsen, sikrer dens fiasko.  Det er uretfærdigt over for alle de mennesker (herunder kunder), der er afhængige af dens succes.

I denne henseende arver testautomatisering blot et særligt tilfælde af den generelle tilgang til SQA hos dem, der ikke forstår den og heller ikke ønsker at forstå den. Den behandles som en massevare, ikke som kompleks ekspertise. Det er derfor, folk inden for QA bliver ved med at høre ledelsen sige: “vi skal bare have mere QA!”, som om der et sted fandtes en softwaredelikatesse, hvor man kunne bestille det efter vægt, tyndt skåret.

Det er derfor, mantraet nu lyder: “vi skal bare have mere automatisering!”, uden at der skænkes en tanke til, hvad det egentlig ville betyde i forbindelse med jeres softwareudviklingsarbejde. På den måde nærer denne diskurs dysfunktionerne i jeres organisation. Den løser dem ikke.  

At forsøge direkte at modstå disse modeluner er som at forsøge at forhindre solen i at stå op. Eller i dette tilfælde gå ned. Den bedste modstandsstrategi er blot at nikke og smile til vicepræsidenterne og konsulenterne, gå tilbage til jeres skriveborde og finde ud af, hvordan automatisering bør udføres, og derefter præsentere disse idéer som de geniale resultater af jeres lederes fantasi. Men I har sikkert allerede lært den lektie i forbindelse med andre problemer.

Så lad os gøre det. Her er min liste over faldgruberne ved implementering af testautomatisering og måder at afbøde dem på, så automatisering kan indfri sit betydelige potentiale i jeres egen testindsats.

Automatiseringens omfang

Det vigtigste spørgsmål at besvare i begyndelsen er, hvor automatiseret test giver mest værdi for pengene i jeres testindsats. Hvis I tager jer tid til at gøre dette, sparer det jer for mange, mange hovedpiner senere.

At besvare dette spørgsmål handler i bund og grund om, hvor meget af jeres test der skal automatiseres, og hvor meget der skal forblive manuelt. Det vil måske overraske nogle af jer, som ustandseligt bombarderes med evangeliet om “automatisér al test!”. Men ignorer det nonsens; disse mennesker aner ikke, hvad de taler om.

At automatisere al jeres test – hvis det overhovedet er muligt – ville være en frygtelig beslutning, som kun kunne føre til katastrofe for jeres testindsats.  

Der er fantastiske ting, automatisering kan gøre, som manuel test ikke kan – eller i det mindste ikke lige så hurtigt og gentagne gange. Men det modsatte er også sandt. Der er ting, som kun manuel test kan gøre godt, og som automatisering ikke kan. Hvad er disse ting i hvert tilfælde?

Det, manuel test udmærker sig ved, mens automatiseret test ikke gør det, er ganske enkelt den menneskelige faktor. Fordelen ved at have et rigtigt menneske, der tålmodigt udfører dybdegående eksplorativ test, kan simpelthen ikke efterlignes af automatisering. Og jeg taler ikke kun om at finde fejl.  

Alle kan finde fejl. Kunder gør det gratis hele tiden. Værdien, en professionel QA tilfører, er en intuitiv fornemmelse for, hvordan man kan ødelægge et stykke software, især når det gælder om at afgøre, hvordan softwaren kan bruges af kunder på måder, den aldrig er designet til at blive brugt på, men som den alligevel – ofte med katastrofale resultater – kan håndtere. 

En anden fordel ved manuel test er, at en manuel tester, efter at have fundet en fejl, straks kan gå i gang med at fastslå dens omfang og alvorlighed. Det vil sige indsnævre de testkontekster (operativsystemer, arbejdsgange, interaktioner mellem tjenester og afhængigheder), hvor den specifikt optræder, og dem, hvor den ikke gør.

Automatiserede testskripter kan slet ikke gøre dette særlig godt, og fra en softwareingeniørs synspunkt er det netop de afgørende oplysninger, de har brug for til at diagnosticere og rette enhver fejl. En fejlrapport, der blot siger: “Jeg gjorde dette, og så skete denne dårlige ting”, er ubrugelig for dem.

Manuel test er faktisk langt mere tidseffektiv, når det gælder om at fremskaffe disse oplysninger, og fordi den i sagens natur er interaktiv og foregår i øjeblikket sammen med udviklingen, giver den langt mere informationsrig feedback og analyse af den grundlæggende årsag.  

Ja, Virginia, manuel test er ikke altid den mindst effektive og mest tidskrævende måde at finde, diagnosticere og rette fejl på samt validere (eller ikke validere) deres rettelser. 

Hvor automatisering imidlertid har en åbenlys fordel, er ved kontinuerlig test af oppetid og stabilitet – især for distribuerede systemer. Dette er langt mere centralt nu i betragtning af vores aktuelle udviklingskontekst med kontinuerlig integration og udrulning i distribuerede miljøer i realtid.

Automatisering er også mere effektiv til det, man kunne kalde »massetest«, hvor man har en enorm matrix af tusindvis af systembetingelser og deres variabler, der skal dækkes for at se, om nogen af dem er helt ødelagte eller vil få systemet til at gå ned.

Tommelfingerreglen, du bør bruge til at styre dine beslutninger om, hvor du skal prioritere enten manuel eller automatiseret test, er denne: 

Manuel test foretrækkes normalt til den indledende test af nye funktioner og muligheder. Automatiseret test er klart bedst til kontinuerlig generel regression samt til belastnings- og ydeevnetest.

Gennem et produkts eller en tjenestes livscyklus bør test af den samme funktion udvikle sig fra manuel til automatiseret. Det er et kontinuum for funktionens livscyklus. Ikke en kinesisk mur, der aldrig må overskrides, hvor ingen af siderne behøver at være opmærksomme på, hvad der foregår på den anden. Standardantagelsen bør være, at det, der testes manuelt i dag, med tiden bør overgå til automatiseret test.

Kvalifikationer for automatiseringsingeniører

Det er måske uundgåeligt, at de vigtigste ønskede kvalifikationer ved ansættelse af ingeniører inden for automatiseret test vil være kandidaternes færdighedsniveau i (a) de automatiseringsværktøjer, de forventes at bruge, og (b) de testscriptsprog, som disse værktøjer anvender.  

Men hvis det er de eneste kvalifikationer, du fokuserer på, begår du en stor fejl. De er nødvendige, men langt fra tilstrækkelige kvalifikationer til rollen som automatiseringsingeniør.

Hvorfor? Af den simple grund, at det at vide, hvordan man bruger et automatiseringsværktøj, og hvordan man opretter scripts i dets scriptsprog, fortæller dig præcis ingenting om deres forståelse af kvalitetssikring i sig selv.

Desværre møder jeg næsten aldrig automatiseringsingeniører, der har denne uddannelse eller baggrund. De bliver ansat, simpelthen fordi de er eksperter i scripting, ikke fordi de har evner til at designe en effektiv og diagnostisk test.

Disse kvalifikationer er faktisk vigtigere end erfaring med de automatiseringsværktøjer og -sprog, de skal bruge. De kan nemt lære disse, hvis det bliver nødvendigt. Men det tager meget lang tid og kræver en stor indsats at oplære nogen i at designe test og fortolke resultaterne.  

Det ville faktisk være bedre blot at tage en erfaren analytiker, du allerede har, og oplære vedkommende i de nødvendige automatiseringsværktøjer. Disse automatiseringsevner er trods alt blevet en standardvare. En erfaren testers intuition og indsigt er de ikke.

Automatisering af uvidenhed giver dig blot uvidenhed hurtigere og mere konsekvent og underminerer den effektivitet, du søgte at opnå med automatiseret test. 

Standarder for automatiseringsdesign

Det siger sig selv, at hvis du går i gang med en omfattende testautomatiseringsindsats, skal du først definere generelle standarder, som al automatisering skal overholde for at blive godkendt til brug i test. Men som med mange selvfølgeligheder synes der at være færre skarpe hoveder til rådighed, end man skulle tro.

Her er, hvad disse standarder bør omfatte.

Forståelighed

Et af de frustrerende mysterier ved softwareudvikling er, hvor håndværksmæssig den viser sig at være. Det er desværre langt fra en sjælden oplevelse, at en softwareingeniør fortæller dig, at vedkommende ikke kan rette en fejl, fordi han eller hun ikke skrev den kode, hvor den optræder. Det er, som om kode skrevet af en anden ingeniør er på et fremmedsprog, de ikke forstår.

Dette er desværre lige så almindeligt inden for automatisering af test. Jeg kan ikke fortælle dig, hvor mange gange en QA-ingeniør har sagt til mig, at vedkommende ikke ved, hvordan et stykke testautomatisering skal opdateres til en større produktopgradering, fordi han eller hun ikke skrev det og derfor hverken forstår eller kan forstå det. Nå ja, og den ingeniør, der gjorde det, forlod virksomheden for to måneder siden.

Dette er endnu mindre acceptabelt i forbindelse med automatiserede testscripts, end det er i forbindelse med ny softwarekode, der implementerer designlogik og ikke blot får bestemte trin til at foregå. Alligevel er det forbavsende almindeligt.

Det betyder, at før du ansætter et dusin QA-ingeniører og sætter dem til muntert at producere hundredvis af automatiserede testscripts, skal du sikre dig, at du først har defineret og undervist i generelle standarder for forståelighed.  

Det skal være et krav, at alle testscripts skal være gensidigt forståelige for alle dine QA-ingeniører, så du ikke ender med kun at have én enkelt, ofte midlertidig ressource til at vedligeholde dem.  

Definér og håndhæv en gennemgangs- og godkendelsesproces for alle kandidater til automatiserede scripts op imod disse standarder, før de kan anvendes i test. 

Vedligeholdelsesvenlighed

Vedligeholdelsesvenlighed er tæt forbundet med problemet omkring forståelighed, men de to ting er logisk og operationelt adskilte. Et testscript kan være let at forstå for testingeniører, som ikke har skrevet det, og alligevel være struktureret på en sådan måde, at det er et mareridt at opdatere eller ændre.

Her er et eksempel fra det virkelige liv. 

Hos en af mine tidligere arbejdsgivere forberedte vi testindsatsen til en opgradering på mellemniveau af deres flagskibsprodukt. Den var planlagt til en udgivelsescyklus på fire uger, hvilket faktisk var rimeligt i dette tilfælde.

Da jeg planlagde den nødvendige testindsats, indså jeg, at vi også skulle opdatere det vigtigste automatiserede regressionstest-script. Da jeg spurgte den ledende QA-ingeniør, hvor lang tid opdateringen ville tage, svarede han “otte uger”. Det dobbelte af tiden for hele udgivelsen! Selv når man medregner ingeniørkunsten at oppuste estimater, var dette ekstremt.  

Jeg bad nogle andre testingeniører gennemgå scriptet og estimatet. De var alle enige om, at scriptet var skrevet på en så klodset og ineffektiv måde, at det ville tage mange uger med omhyggelig omskrivning af hele scriptet at opdatere det til den næste udgivelse, selv om opdateringerne i sig selv ikke var grundlæggende omskrivninger af produktet.

Situationen var et klassisk eksempel på en synd inden for softwareudvikling, der var blevet teleporteret ind i testudvikling. Det er på tide at stoppe galskaben.

Mit råd her er identisk med det, jeg gav ovenfor om problemet med forståelighed. Lad under ingen omstændigheder jeres QA-ingeniører gemme sig i deres testudviklingshuler og dukke op en uge eller to senere med noget, der måske fungerer som en test, men som vil være et mareridt af meningsløs lidelse at opdatere rettidigt.

Indfør standarder for rettidig opdatering, og skab en gennemgangs- og acceptproces for at sikre, at de overholdes. Dette kan let integreres i den samme indsats for at sikre forståelighed, så det hele kan være en del af den samme gennemgangsproces.

Jeres QA-ingeniører er ikke renæssancemalere, og I beder dem ikke om at male Det Sixtinske Kapel om. Det burde ikke tage et helt liv.

Testroller og testautomatisering

Et af de ineffektivitetsmønstre, der hæmmer en problemfri og udbytterig integration af automatisering i jeres samlede testindsats, er den fejlagtige antagelse, at hvert trin i den automatiserede testproces skal foregå i selve automatiseringsgruppen.

Dette er endnu en fejl. Om end det i dette tilfælde ikke er en helt indlysende fejl.

Automatiseringsingeniører er sandsynligvis de bedst betalte ressourcer på jeres team, så deres tid er kostbar. Desuden vil mængden af testskripter, der skal oprettes og løbende opdateres af dette team, kun vokse med tiden, mens jeres pulje af testingeniører ikke vil kunne vokse næsten hurtigt nok til at følge med. Ikke engang hvis I arbejder for Google.

Det giver derfor operationel mening at indføre en arbejdsdeling mellem automatiseringsteamet og resten af jeres team. Mere specifikt en opdeling mellem de ressourcer, der opretter og vedligeholder automatiserede scripts og værktøjer, og dem, der faktisk kører de automatiserede tests.

Det er naturligvis kun automatiseringsteamet selv, der kan udføre førstnævnte ansvarsområder.  Det var trods alt derfor, de blev ansat i første omgang. Men det gælder ikke for sidstnævnte.  

Der er ingen grund til, at analytikere ikke også skal kunne køre automatiserede tests på egen hånd og fortolke deres resultater.  

Meget få mennesker tænker i disse baner, men denne arbejdsdeling giver al mulig mening. For det første frigiver den betydelige mængder tid, så automatiseringsingeniørerne kan fokusere på at skabe ny automatisering.

For det andet vil den understøtte kravet om forståelighed, der er defineret ovenfor. Hvis automatisering er central for jeres testindsats, skal det være lige så centralt, at alle i jeres testteam, uanset om de er automatiseringsingeniører eller ej, skal kunne forstå og bruge jeres automatiserede tests. Også manuelle testere.

Et sådant system til rolledefinition vil i høj grad øge fleksibiliteten med hensyn til ressourcer i hele jeres QA-team og derfor også skabe tids- og planlægningseffektivitet, som ellers ikke ville eksistere. 

Afsluttende tanker

At udvikle en robust kapacitet inden for automatiseret test, som defineret ovenfor, er ganske enkelt en nødvendighed i dag. Man kan ikke tale om professionel og effektiv QA uden den.  

Alligevel begynder mange strålende eventyr med begejstring og glæde, blot for at ende med nederlag ved rejsens afslutning. Jeg ser dette ske i QA i forbindelse med testautomatisering i rigtig, rigtig mange tilfælde.

Problemet er, at automatiseret testning er forholdsvis let at kaste sig ud i. Det er dyrt, men det er i det mindste let at lade som om, man gør en indsats. Automatiseret testning kan dog også være en klippekant, hvor man, ligesom Wile E. Coyote i tegnefilmene om Roadrunner, tankeløst løber ud over kanten og falder, så snart man besværer sig med at kigge ned.

Det skal forstås fra begyndelsen, at testautomatisering har en livscyklus. Ethvert testscript har en livscyklus på måneder, hvis ikke år.

Det handler ikke blot om at skrive en masse automatiserede testskripter, der opfylder alle jeres behov for produktet, som det aktuelt befinder sig i sin udvikling. Det handler om, hvordan I vil kunne videreudvikle al denne automatisering problemfrit, i takt med at produktet udvikler sig gennem sin egen livscyklus.

Hvis du ignorerer problemerne med automatiseringens omfang, QA-ingeniørernes kvalifikationer, forståelighed, vedligeholdelighed og rolledefinition, vil du med tiden opdage, at al den automatiseringsindsats er blevet en hvid elefant og en pengesluger, som det er umuligt at forstå eller vedligeholde.

Og alle de penge, du har brugt på det, vil være spildt. Noget, som dine chefers chefer ikke vil undgå at bemærke.

Hvis du derimod følger de råd, jeg giver ovenfor, naturligvis tilpasset de særlige forhold ved dine egne udfordringer og din situation, vil du i vid udstrækning undgå denne forældelseskrise og nyde godt af produktiv testautomatisering i mange år fremover.

Som altid ønskes du held og lykke.

Relaterede artikler:

• 10 BEDSTE VÆRKTØJER TIL OVERVÅGNING AF WEBSERVERE
• BEDSTE PRAKSISSER FOR AUTOMATISERING I DIGITAL TRANSFORMATION

Værd at tjekke ud: HVAD ER MABL? OVERSIGT OVER OG GENNEMGANG AF FUNKTIONER