Automatiserad testnings mörka sida och varför manuell testning fortfarande spelar roll

Automatiserad testning har blivit så integrerad i vissa rutiner att en del testare undrar om den helt kommer att ersätta manuell testning. 

Inte inom överskådlig tid. 

När Teslas team utformade Model 3 var ett sätt de ville öka produktionstakten på att ha en helt automatiserad monteringslinje. AI skulle montera bilen med nästan ingen övervakning från människor. 

Planen misslyckades katastrofalt.

Bilar körde in i varandra, dörrar borrades in i fönster och däcken gick inte att montera korrekt på fälgarna. 

Vad hände? Jo, det visade sig att robotar inte kan se särskilt bra. AI:n som ansvarade för monteringen av Model 3 kunde inte anpassa sig till oväntade komplikationer eller mindre feljusteringar. Om allt inte var perfekt inriktat gjorde den katastrofala misstag. 

Detsamma gäller för automatiserad testning inom QA. Vissa former av testning har för många variabler och kräver att den manuella testaren kan korrigera kursen och felsöka under arbetets gång. 

Vad är automatiserad testning?

Automatiserad testning innebär att en QA-testare använder ett verktyg för att köra ett testfall. Under utvecklingscykeln kommer samma testfall att testas flera gånger.

Vissa av de testfall som skulle ta ett team av QA-testare flera timmar att gå igenom manuellt kan utföras av ett verktyg för automatiserad testning på några minuter. Flera verktyg för automatiserad testning har blivit branschstandard. 

Den mörka sidan av automatiserad testning

Andra branscher, hantverk och yrken har behövt hantera införandet av automatisering inom sina områden. När det har hänt, oavsett om det varit inom flyget med autopilot, mattvävning eller testning, förlorar de som arbetar inom området sin förståelse för ”varför” bakom sitt arbete.

Detta är ett fenomen som QA-specialisten Jan Jaap Cannegieter lade märke till att det började hända bland testare. Hans största rädsla är att den automatiserade testningens enkelhet och den växande strävan att automatisera stora delar av testprocessen kommer att leda till en generation testare som vet vilka åtgärder de ska utföra men saknar förståelse för varför. 

Många testare vet allt om vissa verktyg eller programmeringsspråk, men de kan inte berätta för mig vad de testar eller varför de testar det. Och det är något dåligt.

Exempel på dålig automatiserad testning

Många QA-testare ser samma potential i automatiserad testning. Vanligtvis innebär det att det finns observerbara trender och vanliga misstag som en QA-testare kan göra. Här är några vanliga exempel på dålig automatiserad testning. 

Kapslade automatiserade tester

Kapslade automatiserade tester innebär att flera automatiserade tester körs ovanpå varandra.  När detta händer blir det svårt att ta reda på vad som har gått fel när ett fel uppstår. 

På kort sikt är de flesta fall av automatiserad testning positiva. QA-testaren använder rätt verktyg och kör det på rätt sätt. 

Många exempel på dålig automatiserad testning blir dåliga först sex månader senare, när automatiserade tester har kapslats inuti andra automatiserade tester, som i sin tur ligger inuti ytterligare andra automatiserade tester. 

Automatiserad UI-testning utan övervakning

Användargränssnittstestning säkerställer att det inte finns något en användare kan göra i användargränssnittet som får programmet att krascha eller orsakar funktionsfel. När testningen görs manuellt kan detta kräva många testare och mycket arbetskraft. Det är helt enkelt ineffektivt att testa på det sättet, särskilt när programmet blir större och fler funktioner behöver testas. 

Med automatiserad testning går processen snabbare, men den kan fortfarande kräva hela kapaciteten hos en QA-testares dator under en hel dag. För att hantera detta kör QA-testare testet i slutet av dagen, låter det arbeta under natten och kommer tillbaka till arbetet nästa morgon med resultaten väntande på dem. Det låter väl rimligt? 

På ytan verkar det vara det smarta sättet att göra det på. QA-testaren använder sin dator för att testa andra program under dagen och kör sedan den automatiserade UI-testningen på natten.

Det är just eftersom det verkar logiskt som detta är ett vanligt misstag. Mycket kan gå fel när automatiserad testning utförs utan övervakning.

Om något går fel tidigt kommer resten av resultaten att bli fel. En hel dags testning gav ingen användbar information på grund av ett fel som enkelt hade kunnat upptäckas och åtgärdas om någon hade varit där för att kontrollera att automatiseringstestet fungerade korrekt.

Även om automatiserad testning ibland kan leda till falska positiva resultat kan valet av rätt QA-automatiseringsverktyg avsevärt minska sådana fall. 

Att automatisera fel saker

Automatiseringstestning tar tid att konfigurera. QA måste se till att automatiseringsverktygen passar projektet och att QA-testarna vet hur verktygen ska användas korrekt. 

Allt detta kräver mycket tid och organisation, och om slutresultatet är att ett test som vanligtvis körs en gång i månaden automatiseras är det inte värt besväret. Innan du börjar med automatiseringstestning bör du se till att det du tänker automatisera kommer att spara QA-testarna en mätbar mängd tid.

Det går inte bara att automatisera uppgifter som är för sällsynta för att vara värda besväret; vissa uppgifter kan helt enkelt inte automatiseras på ett enkelt sätt.

Att ersätta manuell testning

Automatiserad testning kan bara upptäcka det som den instruerats att leta efter. Om teckensnitten på en webbsida ser konstiga ut, men testet bara kontrollerade att alla länkar på webbplatsen fungerade, löser det ett problem (länkarna) men vet inte att något är fel med det andra (teckensnitten). 

Manuell testning kan upptäcka saker utanför testets ursprungliga omfattning. Metoden explorativ testning utformades för att ge QA-testaren utrymme att hitta oväntade buggar när de uppstod, även om det inte var det de ursprungligen letade efter. När automatiseringstestning fokuserar på en enskild uppgift kan den vara grundlig. Men den kan inte vara heltäckande. 

Exempel på bra automatiserad testning

Testautomatisering utförs för att minimera risker. När en QA-testare kan minimera risken och maximera effektiviteten bör automatiseringstestning definitivt utföras.  Det finns ingen anledning för en QA-testare att ägna timmar åt att manuellt kontrollera länkarna på en webbplats när en webbcrawler kan utföra samma aktivitet på kortare tid och med liten risk att göra ett misstag.

En bra tumregel för att avgöra när automatiseringstestning bör användas i stället för manuell testning är att fråga om testet kommer att vara snabbt eller kontinuerligt. Om testet ska köras kontinuerligt är automatiseringstestning rätt väg att gå. 

Människor är sämre än maskiner på att konsekvent utföra repetitiva uppgifter på en hög nivå. Vi längtar efter variation och kopplar mentalt bort när vi gör samma sak för länge. Det gör att misstag kan slinka igenom. 

På så sätt inser en QA-testare att de: a) har lagt mer tid än om de hade kört automatiseringstestning och b) har gjort ett sämre jobb och skapat fler problem längre fram. 

Jason Huggins, grundaren av det populära automatiseringstestverktyget Selenium, utvecklade programmet eftersom han upptäckte att så många av hans dagar som testare ägnades åt att köra samma uppgifter – uppgifter som han tyckte var så enkla och raka att till och med en robot kunde utföra dem. Därför utvecklade han ett skript som automatiskt testade webbläsarfunktioner åt honom. Det blev en omedelbar framgång och blev snabbt branschstandard. 

Även de QA-experter som är skeptiska till automatiseringstestning vet att den i många fall fyller en funktion. 

Varför manuell testning aldrig kommer att dö

Vi har gått igenom de bra, de dåliga och de mycket dåliga aspekterna av AT. Vi vet i vilka situationer den fungerar bra och var den får monteringslinjer att kasta bildäck runt i fabriken. Låt oss för en stund titta på manuell testning och varför den fortfarande är så viktig för QA-testare. 

Automatiserad testning behöver övervakning

Som nämndes ovan, med Musks Model 3-problem och riskerna med att köra automatiseringstestning över natten, kan saker gå väldigt fel när du lämnar automatiseringsverktygen utan uppsikt. 

De stora fördelarna med automatiseringstestning uppstår när den utförs tillsammans med manuell testning eller under överinseende av en QA-testare. Bara av den anledningen kan QA-testare känna sig trygga med att AT inte kommer att ta över deras roller inom överskådlig framtid. 

Manuell testning använder explorativ testning

När en testare utför ett explorativt test utforskar de programvaran utan någon förutbestämd plan. Det är en av de mest populära testformerna inom QA.

Explorativ testning kan endast utföras genom manuell testning. 

Fördelen med explorativ testning är att testaren kan anpassa sig efter sina upptäckter direkt, utan att behöva skriva ett nytt testfall. 

Explorativ testning möjliggör också samarbete, teoriskapande och samarbete direkt under arbetets gång. 

I takt med att den agila utvecklingsteorin har blivit allt mer framträdande har även explorativ testning blivit det. 

Automatiserad testning saknar den flexibilitet och kreativitet som krävs för att vara tillräckligt agil för explorativ testning. Den fungerar bäst i en strikt miljö där den vet exakt vad den ska leta efter. Explorativ testning är raka motsatsen – QA-testaren instrueras att gå vart de vill. 

Vad tycker du?

Vissa svär vid automatiserad testning, medan andra fortfarande tycker att manuell testning är rätt väg att gå. Hur tycker du att QA-team kan få ut mesta möjliga av automatiserad testning? Tycker du att vi är redo för AI inom testning?

Prenumerera på The CTO Clubs nyhetsbrev för att få de senaste artiklarna och uppdateringarna från branschexperter.