Automatiseringstestningens mörka sida & varför manuella tester fortfarande spelar roll
Automatiserad testning har blivit så integrerad i vissa rutiner att en del testare undrar om den kommer att ersätta manuell testning helt.
Inte inom den närmaste framtiden.
När Teslas team utformade Model 3 var ett sätt de ville öka produktionstakten på att ha ett helt automatiserat monteringsband. AI skulle montera bilen med nästan ingen övervakning från människor.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Planen misslyckades katastrofalt.
Bilar kraschade 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. Den AI som ansvarade för monteringen av Model 3 kunde inte anpassa sig till oväntade komplikationer eller små feljusteringar. Om allt inte var perfekt inriktat gjorde den katastrofala misstag.
Detsamma gäller 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 testfall som skulle ta ett team av QA-testare flera timmar att gå igenom manuellt kan utföras av ett automatiserat testverktyg 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 farhåga är att den automatiserade testningens enkelhet och den växande strävan efter 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 och varför de testar det. Och det är 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.
Kapsling av automatiserade tester
Kapsling av 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 in i andra automatiserade tester, som i sin tur ligger inuti ytterligare andra automatiserade tester.
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 fel. När den utfö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 växer och fler funktioner behöver testas.
Med automatiserad testning blir processen snabbare, men den kan fortfarande kräva hela kapaciteten hos en QA-testares dator under en hel dag. För att hantera det kör QA-testare testet i slutet av dagen, låter det arbeta över natten och kommer tillbaka till jobbet nästa morgon, med resultaten klara och väntande. 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 vara felaktiga. En hel dags testning gav ingen användbar information på grund av ett fel som enkelt hade kunnat upptäckas och korrigeras om någon hade varit där för att kontrollera att det automatiserade testet fungerade korrekt.
Även om automatiserade tester ibland kan leda till falska positiva resultat kan valet av rätt verktyg för QA-automatisering avsevärt minska sådana fall.
Att automatisera fel saker
Det tar tid att konfigurera automatiserade tester. QA måste se till att automatiseringsverktygen passar projektet och att QA-testarna vet hur verktygen ska användas på rätt sätt.
Allt detta kräver mycket tid och organisation, och om slutresultatet blir 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 automatiserade tester 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 utförs för sällan för att besväret ska vara värt det; vissa uppgifter kan helt enkelt inte automatiseras enkelt.
Att ersätta manuella tester
Automatiserade tester kan bara upptäcka det som de 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 upptäcker inte att något är fel med det andra (teckensnitten).
Manuella tester 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 automatiserade tester fokuserar på en enskild uppgift kan de vara grundliga. Men de kan inte vara heltäckande.
Exempel på bra automatiserade tester
Testautomatisering utförs för att minimera risker. När en QA-testare kan minimera risken och maximera effektiviteten bör automatiserade tester absolut användas. 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 automatiserade tester bör användas i stället för manuella tester är att fråga om testet kommer att vara snabbt eller kontinuerligt. Om testet ska köras kontinuerligt är automatiserade tester 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 kommer en QA-testare att inse att hen: a) har lagt mer tid än om hen hade kört automatiserade tester och b) har gjort ett sämre jobb och skapat mer huvudvärk senare.
Jason Huggins, grundaren av det populära automatiseringsverktyget Selenium, utvecklade programmet eftersom han upptäckte att så många av hans dagar som testare gick åt till att utföra samma uppgifter – uppgifter som han tyckte var så enkla och okomplicerade att till och med en robot kunde utföra dem. Därför utvecklade han ett skript som automatiskt testade webbläsarfunktionalitet åt honom. Det blev genast en framgång och blev snabbt branschstandard.
Även de QA-professionella som är skeptiska till automatiserade tester vet att de i många fall fyller en funktion.
Varför manuella tester aldrig kommer att dö ut
Vi har gått igenom de bra, de dåliga och de mycket dåliga aspekterna av AT. Vi vet i vilka situationer det fungerar bra och var det får monteringslinjer att kasta bildäck runt i fabriken. Låt oss för en stund titta på manuella tester och varför de fortfarande är så viktiga för QA-testare.
Automatiserade tester behöver övervakning
Som nämndes ovan, med Musks problem med Model 3 och riskerna med att köra automatiserade tester över natten, kan saker gå mycket fel när du lämnar automatiseringsverktygen ensamma.
De stora fördelarna med automatiserade tester uppstår när de utförs tillsammans med manuella tester eller under överinseende av en QA-testare. Bara av den anledningen kan QA-testare vara lugna i vetskapen om att AT inte kommer att ta över deras roller inom överskådlig framtid.
Manuella tester använder explorativ testning
När en testare utför ett explorativt test utforskar hen programvaran utan någon förutbestämd plan. Det är en av de mest populära formerna av testning inom QA.
Explorativ testning kan endast utföras genom manuella tester.
Fördelen med explorativ testning är att testaren kan anpassa sig till sina upptäckter direkt, utan att behöva skriva ett nytt testfall.
Utforskande testning möjliggör också samarbete, teoriskapande och samarbete direkt i stunden.
Allteftersom den agila utvecklingsteorin har blivit mer framträdande, har även utforskande testning blivit det.
Testautomatisering saknar den flexibilitet och kreativitet som krävs för att vara tillräckligt agil för utforskande testning. Den fungerar bäst i en strikt miljö där den vet exakt vad den ska leta efter. Utforskande testning är raka motsatsen – QA-testaren instrueras att gå vart de vill.
Vad tycker du?
Vissa svär vid testautomatisering, medan andra fortfarande tycker att manuella tester är rätt väg att gå. Hur tycker du att QA-team kan få ut så mycket som möjligt av testautomatisering? 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.
