Syftet med detta avsnitt är att analysera identifierade krav med hjälp av tidigare forskning om för- och nackdelar med olika typer av AGT-verktyg. Analysen ligger till grund för den diskussion som i kapitel 5 leder fram till svaret på forskningsfråga 1. Som beskrivs i kapitel 3 har de identifierade kraven omformulerats till teman för analys. De teman som här analyseras är exekveringstid, effektivitet i att hitta defekter, total tid för testrelaterat arbete, val av testfall och korrekt GUI.
Exekveringstid
Alégroth (2015) och Dobslaw et al. (2019) visar att skriptbaserade verktyg, både komponentbaserade och visuella, ger snabbare exekvering av testskript än manuella tester.
Dobslaw et al. (2019) och Alégroth et al. (2015) gör jämförelser där komponentbaserade verktyg är fyra respektive tre gånger snabbare än visuella verktyg. Skriptlösa verktyg kan inte direkt jämföras med skriptbaserade eller manuella tester med avseende på snabbhet eftersom testerna inte går till på samma sätt. Aho och Vos (2018) konstaterar dock att skriptlösa test är tidskrävande att utföra.
Effektivitet i att hitta defekter
Alégroth (2015) visar att visuella skriptbaserade verktyg upptäcker defekter lika effektivt eller mer effektivt än manuella test. Alégroth et al. (2015) jämför komponentbaserade och visuella skriptbaserade verktyg och drar slutsatsen att i systemtest är komponentbaserade verktyg mer effektiva än visuella, eftersom testfall som borde passera oftare fallerar med visuella verktyg. I acceptanstest är däremot visuella verktyg enligt Alégroth et al. mer effektiva än komponentbaserade eftersom komponentbaserade verktyg oftare missar defekter, så att testfall som borde fallera ändå passerar. Alégroth et al. (2015) presenterar idén att kombinera komponentbaserade och visuella verktyg för att dra nytta av bådas fördelar. Enligt Alégroth et al. (2015) kan acceptanstest ännu inte automatiseras fullständigt, utan manuella tester behövs också.
De flesta verktyg för skriptlösa test stödjer enligt Aho och Vos (2018) inte manuellt definierade testorakel. Med dessa verktyg går det alltså inte att bestämma vilka fel man vill testa för. Däremot är skriptlösa verktyg enligt Wetzlmaier och Ramler (2017) användbara för att upptäcka gömda fel som inte upptäcks med andra metoder.
Total tid för testrelaterat arbete
Med avseende på tidsåtgång har skriptbaserade verktyg enligt Aho och Vos (2018) en nackdel i att det tar mycket tid att skapa och underhålla testskript. Detta arbete kan bli mindre omfattande om modellbaserade verktyg används (Aho & Vos, 2018). Såväl Aho
och Vos (2018) som Utting et al. (2011) beskriver dock att modellbaserade verktyg kräver speciella kunskaper och att det är svårt att skapa de modeller som krävs för att test med dessa verktyg ska fungera väl.
Letotta et al. (2013) jämför Record & Replay -verktyg med manuellt skriven kod.
Slutsatsen är att det går snabbare att skapa testskript med Record & Replay-verktyg, men att tidsvinsten snabbt äts upp av att underhållet är mer krävande för skript skapade med Record & Replay-verktyg. Aho och Vos (2018) pekar ut just underhåll som den största utmaningen med automatiserade GUI-tester. Debroy et al. (2019) anser att nackdelar med Record and Replay-verktyg är bristen på kontroll och klumpig kod som är svårt att underhålla. Thummalapenta et al. (2012) påpekar att skript skapade med Record &
Replay-verktyg tenderar att sluta fungera redan vid små förändringar i GUI:t, vilket leder till behov av underhåll. Enligt Alégroth och Feldt (2017) är det krävande att underhålla de bilder som behövs i visuella verktyg.
Val av testfall
C-Load-förvaltningen väljer inför varje release ut relevanta regressionstestfall. Med skriptlösa verktyg genereras enligt Wetzlmaier och Ramler (2017) test där verktyget utför handlingar i GUI:t i slumpmässig ordning och med slumpmässig input. Att välja vilka testfall som ska köras är alltså inte möjligt.
Korrekt GUI
Det är viktigt för C-Load-förvaltningen att regressionstesterna säkerställer att det som visas i GUI:t är korrekt. I detta avseende har visuella verktyg en fördel jämfört med komponentbaserade. Visuella verktyg kontrollerar att det som faktiskt visas på skärmen är korrekt, medan komponentbaserade verktyg kontrollerar att den underliggande koden är korrekt (Alégroth, 2015). Alégroth et al. (2015) konstaterar också att visuella verktyg är bättre lämpade för acceptanstester än komponentbaserade verktyg, just för att visuella verktyg upptäcker defekter i GUI:ts utseende som komponentbaserade verktyg missar.
5 Diskussion del 1
Detta kapitel motsvarar steget “Identifiera lämplig typ av verktyg” i den anpassade urvalsprocessen. Baserat på den analys som gjorts av C-Load-förvaltningens krav och förutsättningar med hjälp av den teoretiska referensramen diskuteras vilken typ av verktyg som rekommenderas och forskningsfråga 1 besvaras.
I valet mellan skriptbaserade verktyg, modellbaserade verktyg och skriptlösa verktyg bedömer vi att ett skriptbaserat verktyg borde passa Triona och C-Load bäst. Även om modellbaserade verktyg har potential att minska arbetet med att skapa och underhålla testskript testfall är vårt intryck att startsträckan för att komma igång med modellbaserade test skulle bli orimligt lång för fallet C-Load. Att lyckas med modellbaserade verktyg kräver kompetens som inte finns inom C-Load-förvaltningen idag. Ett skriptlöst verktyg vore olämpligt att använda som enda verktyg för regressionstester, eftersom testningen är slumpmässig och därmed inte passar när man vill genomföra bestämda testfall.
Skriptbaserade verktyg däremot är lämpliga att använda för regressionstester på det sätt Triona önskar, och C-Load-förvaltningen har den kompetens som behövs.
I valet mellan visuella och komponentbaserade verktyg noterar vi att visuella verktyg har en fördel i att de kontrollerar att det som faktiskt visas på skärmen är korrekt, vilket gör att visuella verktyg lämpar sig väl för acceptanstester. Detta är viktigt för
C-Load-förvaltningen. Eftersom underhåll av testfall är en av de största utmaningarna med automatiserade GUI-tester och det anses särskilt krävande att underhålla de bilder som behövs i visuella verktyg, tror vi ändå att ett komponentbaserat verktyg är ett mindre riskabelt val att börja med. Om underhållet blir för krävande kan man tvingas avstå helt från automatiserade tester, medan problemet att komponentbaserade verktyg missar fel i GUI:ts utseende kan hanteras genom att komplettera de automatiska testerna med manuella kontroller. Fullständigt automatiserade GUI-tester verkar ändå inte vara ett nåbart mål i dagsläget. För komponentbaserade verktyg talar också snabbare exekvering av testfall jämfört med visuella verktyg. Att kombinera ett komponentbaserat och visuellt verktyg kan vara intressant när C-Load-förvaltningen kommit igång med AGT.
I valet mellan Record & Replay eller att skriva kod manuellt talar mycket för att manuellt skriven kod skulle passa C-Load-förvaltningen bättre. Bristen på kontroll över selektorer, klumpig kod som är svår att underhålla och sköra testskript talar emot Record & Replay-verktyg. Att skapa testskript kan gå snabbare med Record & Replay-verktyg, men tidsvinsten äts ganska snart upp av att inspelade skript kräver mer underhåll. Då C-Load-förvaltningen dessutom har den kompetens som krävs för att skriva kod manuellt anser vi inte att det finns några starka argument för Record & Replay-verktyg.