Fallgruvene ved testautomatisering

Automatisering, oppskåret i tynne skiver

Det kan ikke benektes at testautomatisering har revolusjonert programvaretesting. Og akkurat i tide også! I dagens verden med svært distribuerte, containeriserte og kontinuerlig oppdaterte tjenester ville meningsfull programvaretesting vært umulig uten den.  

Vi er heldige som har så mange sofistikerte verktøy for automatisert testing til rådighet. Og, om jeg får legge til, velutdannede QA-ingeniører som kan bruke dem til alles fordel i utviklingsarbeidet.

Av en eller annen grunn ligger det imidlertid i vår bransjes natur å vanemessig redusere slike betydelige fremskritt i kapasitet til motetrender, og disse motetrendene til meningsløse ordsalater og slagord som robotisk gjentas av toppledere, forståsegpåere og konsulenter som bare ønsker en unnskyldning for å slutte å tenke på problemet. Eller for å tjene raske penger.  

Slik er det også med gjennombruddene innen testautomatisering, som raskt har blitt fanget inn i den forenklede fortellingen om at «vi trenger bare å automatisere all testingen vår! Med en gang! Og alle testproblemene våre vil bli løst!»

Dette er ikke bare en forferdelig idé, selv om den skulle bli foreslått av mennesker som prøver å ta problemet på alvor og ikke bare unngå det. Den er også skadelig fordi det er en fortelling som, ved å stenge muligheten for å tenke grundig gjennom hvordan automatisering skal integreres i testarbeidet, sikrer at den mislykkes.  Det er urettferdig overfor alle menneskene (inkludert kundene) som er avhengige av at den lykkes.

I denne henseende arver testautomatisering bare et særtilfelle av den generelle tilnærmingen til SQA hos dem som ikke forstår det, og heller ikke ønsker å forstå det. Det behandles som en massevare, ikke som kompleks ekspertise. Derfor fortsetter folk innen QA å høre fra toppledelsen: «Vi trenger bare mer QA!» som om det finnes en programvaresjappe et sted der man kan bestille det etter vekt, oppskåret i tynne skiver.

Derfor er mantraet nå «vi trenger bare mer automatisering!» uten at man tenker over hva det egentlig ville bety i forbindelse med programvareutviklingsarbeidet deres. Dermed bidrar denne diskursen til organisasjonens dysfunksjoner. Den løser dem ikke.  

Å forsøke å stå direkte imot disse motepregede tendensene er som å prøve å hindre solen i å stå opp. Eller, i dette tilfellet, gå ned. Den beste motstandsstrategien er ganske enkelt å nikke og smile til visepresidentene og konsulentene, gå tilbake til arbeidsplassene deres og finne ut den riktige måten å automatisere på, og deretter presentere disse ideene som de geniale produktene av ledernes fantasi. Men dere har sannsynligvis allerede lært den leksen i forbindelse med andre spørsmål.

Så la oss gjøre det. Her er listen min over fallgruvene ved å implementere testautomatisering, og måter å redusere dem på, slik at automatiseringen kan innfri sitt betydelige løfte i deres eget testarbeid.

Omfanget av automatiseringen

Det viktigste spørsmålet å besvare i begynnelsen er hvor automatisert testing gir størst verdi for innsatsen i testarbeidet deres. Å ta seg tid til dette vil spare dere for mange, mange hodepiner senere.

Svaret på dette spørsmålet koker ned til hvor mye av testingen deres som bør automatiseres, og hvor mye som bør forbli manuell. Dette kan være overraskende å høre for dere som ustanselig bombarderes av evangeliet om «automatiser all testing!». Men ikke bry dere om dette tullet; disse menneskene aner ikke hva de snakker om.

Å automatisere all testingen deres – forutsatt at det i det hele tatt er mulig – ville være en forferdelig beslutning som bare kunne føre til katastrofe for testarbeidet deres.  

Det finnes fantastiske ting automatisering kan gjøre som manuell testing ikke kan, eller i hvert fall ikke like raskt og gjentatte ganger. Men det motsatte er også sant. Det finnes ting bare manuell testing kan gjøre godt, og som automatisering ikke kan. Hva er disse tingene i hvert tilfelle?

Der manuell testing utmerker seg fremfor automatisert testing, er ganske enkelt den menneskelige faktoren. Fordelen ved å ha et faktisk menneske som tålmodig utfører grundig utforskende testing, kan ganske enkelt ikke gjenskapes med automatisering. Og jeg snakker ikke bare om å finne feil.  

Alle kan finne feil. Kunder gjør det gratis hele tiden. Verdien en profesjonell QA tilfører, er den intuitive forståelsen av hvordan man kan ødelegge et stykke programvare, særlig når det gjelder å avgjøre hvordan programvaren kan brukes av kunder på måter den aldri var utviklet for å støtte, men som likevel – ofte med katastrofale resultater – er mulig. 

En annen fordel med manuell testing er at en manuell tester, etter å ha funnet en feil, umiddelbart kan begynne å fastslå omfanget og alvorlighetsgraden. Det vil si å snevre inn testkontekstene (operativsystemer, arbeidsflyter, samspill mellom tjenester og avhengigheter) der feilen spesifikt oppstår, og kontekstene der den ikke gjør det. 

Automatiserte testskript kan slett ikke gjøre dette særlig godt, og fra en programvareingeniørs synspunkt er dette den virkelig avgjørende informasjonen de trenger for å diagnostisere og utbedre en feil. En feilrapport som ganske enkelt sier «Jeg gjorde dette, og så skjedde denne dårlige tingen», er ubrukelig for dem.

Manuell testing er faktisk langt mer tidseffektiv når det gjelder å fremskaffe denne informasjonen, og fordi den i seg selv er interaktiv og skjer i øyeblikket sammen med utviklerne, gir den langt mer informasjonsrik tilbakemelding og analyse av bakenforliggende årsaker.  

Ja, Virginia, manuell testing er ikke alltid den minst effektive og mest tidkrevende måten å finne, diagnostisere og utbedre feil på, og å validere (eller ikke validere) rettingene av dem. 

Der automatisering har en åpenbar fordel, er imidlertid i kontinuerlig testing av oppetid og stabilitet – særlig for distribuerte systemer. Dette er langt mer sentralt nå, gitt vår nåværende utviklingskontekst med kontinuerlig integrasjon og distribusjon til distribuerte miljøer i sanntid.

Automatisering er også mer effektivt til det du kan kalle «massetesting», der du har en enorm matrise med tusenvis av systembetingelser og variablene deres som må dekkes for å se om noen av dem er fullstendig ødelagt eller vil føre til at systemet går ned.

Tommelfingerregelen du bør bruke for å styre utformingen av hva som skal prioriteres av manuell eller automatisert testing, er denne: 

Manuell testing foretrekkes vanligvis ved den innledende testingen av nye funksjoner og egenskaper. Automatisert testing er klart best for kontinuerlig generell regresjonstesting samt for belastnings- og ytelsestesting.

Gjennom livssyklusen til et produkt eller en tjeneste bør testingen av den samme egenskapen utvikle seg fra manuell til automatisert. Det er et kontinuerlig spekter for egenskapens livssyklus. Ikke en kinesisk mur som aldri skal brytes, der ingen av sidene trenger å være klar over hva som skjer på den andre siden. Utgangspunktet bør være at det som testes manuelt i dag, med tiden skal gå over til automatisert testing.

Kvalifikasjoner for automatiseringsingeniører

Det er kanskje uunngåelig at de viktigste ønskede kvalifikasjonene ved ansettelse av ingeniører innen automatisert testing vil være kandidatenes ferdighetsnivå innen (a) automatiseringsverktøyene de forventes å bruke, og (b) skriptspråkene for testing som disse verktøyene benytter.  

Men hvis dette er de eneste kvalifikasjonene du fokuserer på, gjør du en stor feil. Dette er nødvendige, men langt fra tilstrekkelige kvalifikasjoner for rollen som automatiseringsingeniør.

Hvorfor? Av den enkle grunnen at det å vite hvordan man bruker et automatiseringsverktøy, og hvordan man oppretter skript i skriptspråket det bruker, forteller deg absolutt ingenting om vedkommendes forståelse av kvalitetssikring i seg selv.

Jeg ser dessverre nesten aldri automatiseringsingeniører som har denne opplæringen eller bakgrunnen. De ansettes ganske enkelt fordi de er trollmenn innen skripting, ikke fordi de har ferdigheter i å utforme en effektiv, diagnostisk test.

Disse kvalifikasjonene er faktisk viktigere enn erfaring med automatiseringsverktøyene og språkene de skal bruke. De kan lett lære seg dette ved behov. Men det tar svært lang tid og krever stor innsats å lære noen hvordan man utformer tester og tolker resultatene.  

Det ville faktisk vært bedre å ta en erfaren analytiker du allerede har, og lære vedkommende opp i de nødvendige automatiseringsverktøyene. Automatiseringsferdigheter er tross alt blitt en handelsvare. Intuisjonen og innsikten til en erfaren tester er det ikke.

Automatisering av uvitenhet gir deg bare uvitenhet raskere og mer gjentakbart, og undergraver effektiviteten du ønsket å oppnå med automatisert testing. 

Standarder for automatiseringsutforming

Det sier seg selv at hvis du setter i gang med et storskala initiativ for testautomatisering, må du først definere generelle standarder som all automatisering må følge for å bli godkjent til bruk i testing. Likevel virker det, som med mange ting som sier seg selv, som om det finnes færre kloke hoder enn man skulle tro.

Dette er områdene disse standardene bør dekke.

Forståelighet

Et av de frustrerende mysteriene ved programvareutvikling er hvor håndverksmessig den viser seg å være. Det er dessverre slett ikke uvanlig at en programvareingeniør forteller deg at vedkommende ikke kan rette en feil fordi hen ikke skrev koden der den oppstår. Det er som om kode skrevet av en annen ingeniør er på et fremmed språk de ikke forstår.

Dette er dessverre like vanlig innen testautomatisering. Jeg kan ikke fortelle deg hvor mange ganger en kvalitetssikringsingeniør har sagt til meg at de ikke vet hvordan de skal oppdatere et stykke testautomatisering for en større produktopgradering fordi de ikke skrev det, og derfor ikke forstår det og heller ikke kan forstå det. Og ingeniøren som skrev det, sluttet i selskapet for to måneder siden.

Dette er enda mindre akseptabelt når det gjelder automatiserte testskript enn når det gjelder ny programvarekode som implementerer designlogikk, ikke bare sørger for at bestemte trinn utføres. Likevel er det oppsiktsvekkende vanlig.

Det betyr at før du ansetter et dusin kvalitetssikringsingeniører og lar dem fornøyd produsere hundrevis av automatiserte testskript, må du først ha definert og gitt opplæring i generelle standarder for forståelighet.  

Det må være et krav at alle testskript skal være gjensidig forståelige for alle kvalitetssikringsingeniørene dine, slik at du ikke ender opp med å være avhengig av én enkelt, ofte midlertidig ressurs for vedlikeholdet.  

Definer og håndhev en gjennomgangs- og godkjenningsprosess for alle kandidater til automatiserte skript opp mot disse standardene før de kan tas i bruk i testing. 

Vedlikeholdbarhet

Vedlikeholdbarhet er nært knyttet til problemet med forståelighet, men de to er logisk og operasjonelt separate. Et testskript kan være lett å forstå for testingeniører som ikke skrev det, og likevel være strukturert på en slik måte at det er et mareritt å oppdatere eller endre.

Her er et eksempel fra virkeligheten. 

Hos en av mine tidligere arbeidsgivere forberedte vi testarbeidet for en oppgradering på middels nivå av flaggskipproduktet deres. Den var planlagt for en utgivelsessyklus på fire uker, noe som faktisk var rimelig i dette tilfellet.

Da jeg planla det nødvendige testarbeidet, innså jeg at vi også måtte oppdatere det viktigste automatiserte regresjonstest-skriptet. Da jeg spurte den ledende QA-ingeniøren hvor lang tid denne oppdateringen ville ta, svarte han «åtte uker». Det dobbelte av tiden for hele utgivelsen! Selv om man tar høyde for ingeniørsynden det er å blåse opp estimater, var dette ekstremt.  

Jeg ba noen andre testingeniører gjennomgå skriptet og estimatet. De var alle enige om at skriptet var skrevet på en så klønete og ineffektiv måte at det ville ta mange uker med møysommelig omskriving av hele skriptet for å oppdatere det til neste utgivelse, selv om oppdateringene i seg selv ikke innebar grunnleggende omskrivinger av produktet.

Den situasjonen var et klassisk eksempel på at en synd innen programvareutvikling ble teleportert inn i testutvikling. Det er på tide å stoppe galskapen.

Mitt råd her er identisk med det jeg ga ovenfor om spørsmålet om forståelighet. Ikke la QA-ingeniørene deres under noen omstendigheter gjemme seg i testutviklingshulene sine og dukke opp en uke eller to senere med noe som kanskje fungerer som en test, men som vil være et mareritt av meningsløs lidelse å oppdatere i tide.

Innfør standarder for at oppdateringer skal kunne utføres innen rimelig tid, og opprett en gjennomgangs- og godkjenningsprosess for å sikre at de etterleves. Dette kan enkelt slås sammen med den samme innsatsen for å sikre forståelighet, slik at alt kan inngå i den samme gjennomgangsprosessen.

QA-ingeniørene deres er ikke renessansekunstnere, og dere ber dem ikke male Det sixtinske kapell på nytt. Det burde ikke ta et helt liv.

Testroller og testautomatisering

Et av ineffektiviseringsmønstrene som hindrer en smidig og fruktbar integrering av automatisering i testarbeidet som helhet, er den feilaktige antakelsen om at hvert trinn i den automatiserte testprosessen må utføres av selve automatiseringsteamet.

Dette er en annen feil. Selv om den i dette tilfellet ikke er helt åpenbar.

Automatiseringsingeniører kommer sannsynligvis til å være de best betalte ressursene i teamet deres, så tiden deres er verdifull. I tillegg kommer mengden testskript som dette teamet må opprette og kontinuerlig oppdatere, bare til å vokse over tid, mens gruppen av testingeniører deres ikke vil kunne vokse i nærheten av raskt nok til å holde tritt. Ikke engang hvis dere jobber for Google.

Det gir derfor operasjonell mening å innføre en arbeidsdeling mellom automatiseringsteamet og resten av teamet. Mer spesifikt en arbeidsdeling mellom ressursene som oppretter og vedlikeholder automatiserte skript og verktøy, og dem som faktisk kjører de automatiserte testene.

Det er klart at de førstnevnte oppgavene bare kan utføres av automatiseringsteamet selv.  Det er tross alt derfor de ble ansatt i utgangspunktet. Dette gjelder imidlertid ikke de sistnevnte.  

Det er ingen grunn til at analytikere ikke også skal kunne kjøre automatiserte tester på egen hånd og tolke resultatene.  

Svært få tenker på det på denne måten, men denne arbeidsdelingen gir all mulig mening. For det første frigjør den betydelige mengder tid, slik at automatiseringsingeniørene kan konsentrere seg om å skape ny automatisering.

For det andre vil den styrke kravet om forståelighet som er definert ovenfor. Hvis automatisering står sentralt i testarbeidet deres, må det være like sentralt at alle i testteamet, enten de er automatiseringsingeniører eller ikke, skal kunne forstå og bruke de automatiserte testene deres. Også manuelle testere.

Et slikt system for rolldefinisjon vil i stor grad øke ressursfleksibiliteten i hele QA-teamet deres, og dermed også skape tids- og planleggingseffektivitet som ellers ikke ville eksistert. 

Avsluttende tanker

Å utvikle en robust kapasitet for automatisert testing, slik den er definert ovenfor, er ganske enkelt en nødvendighet i dag. Man kan ikke snakke om profesjonell og effektiv QA uten den.  

Likevel begynner mange lysende eventyr med entusiasme og glede, for så å ende med nederlag ved reisens slutt. Jeg ser dette skje i QA når det gjelder testautomatisering, i svært mange tilfeller.

Problemet er at det er relativt enkelt å kaste seg inn i automatisert testing. Det er kostbart, men det er i det minste enkelt å late som om man gjør en innsats. Automatisert testing kan imidlertid også være en klippe der du, som Wile E. Coyote i Roadrunner-tegnefilmene, tankeløst løper utfor og faller i det øyeblikket du tar deg bryet med å se ned.

Det må forstås fra begynnelsen av at testautomatisering har en livssyklus. Hvert testskript har en livssyklus på måneder, om ikke år.

Det handler ikke bare om å skrive en mengde automatiserte testskript som dekker alle behovene deres for produktet slik det er i sin nåværende utvikling. Det handler om hvordan dere sømløst skal kunne videreutvikle all denne automatiseringen etter hvert som produktet utvikler seg gjennom sin egen livssyklus.

Hvis du ignorerer problemene knyttet til automatiseringens omfang, kvalifikasjonene til QA-ingeniørene, forståelighet, vedlikeholdbarhet og rolledefinisjon, vil du med tiden oppdage at all denne automatiseringsinnsatsen har blitt en hvit elefant og et pengesluk som er umulig å forstå eller vedlikeholde.

Og alle pengene du brukte på det, vil ha vært bortkastet. Noe sjefenes sjefer ikke vil unngå å legge merke til.

På den annen side vil du, hvis du følger rådene jeg gir ovenfor, naturligvis tilpasset detaljene i dine egne utfordringer og din egen situasjon, i stor grad unngå denne foreldelseskrisen og nyte godt av fruktene fra produktiv testautomatisering i mange år fremover.

Som alltid, lykke til.

Relaterte artikler:

• 10 BESTE VERKTØY FOR OVERVÅKING AV WEB-SERVERE
• BESTE PRAKSISER FOR AUTOMATISERING I DIGITAL TRANSFORMASJON

Verdt å sjekke ut: HVA ER MABL? OVERSIKT OG GJENNOMGANG AV FUNKSJONER