De teman som här analyseras genom att jämföra tidigare forskning och data insamlad i observationer och intervjuer är applicerbarhet, webbläsare, exekveringstid, total tid för testrelaterade aktiviteter, samt teststrategi. Angående teman, se kapitel 3.
6.2.1 Applicerbarhet
Det var möjligt att skriva fungerande skript för alla steg i det testfall som användes i studien. För att kringgå problemet att vissa av Selenium WebDrivers metoder inte fungerade på Teleriks UI-komponenter användes dock alternativa lösningar som gav sämre precision i att identifiera element. O. Eriksson (personlig kommunikation, 4 maj, 2020) konstaterar att Selenium WebDriver bör fungera för C-Load så som det är byggt idag, men att Selenium WebDriver förmodligen inte är det bästa valet i moderna webramverk.
6.2.2 Webbläsare
C-Load-förvaltningen har behov av att testa i Google Chrome, Microsoft Edge, Mozilla Firefox och Internet Explorer. Enligt Selenium (2020a) stödjer Selenium WebDriver dessa webbläsare. I observationerna testades samtliga, men Chrome och Explorer var de enda webbläsarna där testen fungerade helt utan problem. Beskrivningar av den typ av problem som observerades med webbläsare har inte hittats i tidigare forskning. Av diskussioner på forum och dylikt framgår att denna typ av problem kan bero på vilka versioner av Selenium WebDriver, webbläsare, driver och operativsystem som används.
6.2.3 Exekveringstid
Angående tiden det tar att exekvera testfallen konstaterar Aho och Vos (2018) att GUI-tester, även om de automatiseras, tar betydligt längre tid att köra än enhetstestereftersom man måste invänta att GUI:t ska uppdateras. C. Landberg (personlig kommunikation, 29 april, 2020) berättar att Seleniumtesterna i Rask-projektet körs nattetid eftersom det tar så lång tid. I våra observationer, se avsnitt 6.1.2.2, tog de manuella testerna ca 86% längre tid än de automatiserade i Chrome och ca 33% längre tid i Internet Explorer. De observerade tiderna avser bara tiden för att exekvera ett testfall en gång och visar inte skillnaden mellan manuella och automatiserade test när en hel svit av testfall exekveras.
6.2.4 Total tid för testrelaterat arbete
Den totala arbetstiden som läggs på AGT beror främst på arbetsbördan med att skapa och underhålla testskript. Förekomst av opålitliga testskript påverkar båda dessa faktorer och även tid för felsökning under test.
6.2.4.1 Arbetsbörda med att skapa testskript
Enligt Aho och Vos (2018) och Dobslaw et al. (2019) är arbetet som krävs för att skapa testskript omfattande. Detta framkommer också i våra intervjuer. I TDP-projektet avslutades försöket med automatiska GUI-tester p.g.a. den arbetsinsats som krävdes var för stor i förhållande till nyttan med att köra testerna (P. Berglund, personlig
kommunikation, 4 maj, 2020). Även i Rask-projektet upplevdes arbetet med att skriva testskript som omfattande (O. Eriksson, personlig kommunikation, 4 maj, 2020).
Utvecklingen av testskript försvårades här av att applikationen i fråga var en så kallad Single Page Application, en teknik som enligt O. Eriksson (personlig kommunikation, 4 maj, 2020) gör att det krävs en extra utvecklingsinsats för att kunna använda Selenium WebDriver. Våra observationer visar också att processen för att skapa testskripten innehöll svårigheter framförallt med att säkerställa att element är tillgängliga, att hitta lämpliga metoder för att hantera element och att testskript inte fungerade i alla webbläsare.
6.2.4.2 Arbetsbörda med att underhålla testskript
Aho och Vos (2018) hävdar att det arbete som krävs för att underhålla testskript är den största utmaningen med att använda skriptbaserad GUI-testning. Enligt Dobslaw et al.
(2019) beror kostnaden för att underhålla testskripten på storlek och frekvens av förändringar i GUI:t. Intervjurespondenterna vittnar också om att i ett system där förändringar är frekventa klarar man inte att uppdatera testskripten i samma takt som systemet förändras, vilket leder till att test fallerar (C. Landberg, personlig kommunikation 29 april; O. Eriksson, personlig kommunikation, 4 maj, 2020).
Omfattningen av arbetet med att underhålla testskript kan enligt Debroy et al. (2018) m.fl.
minska genom att använda designmönstret POM. Av intervjuerna framgår att man i TDP-projektet utvecklade testskripten utan POM, vilket ledde till att skripten innehöll för mycket logik (P. Berglund, personlig kommunikation, 4 maj, 2020). I Rask-projektet användes POM. I våra observationer såg vi också att koden blev mer lättläst och enklare att ändra när vi gick över till POM. Se bilaga 2.
6.2.4.3 Opålitliga testskript
Mascheroni och Irrazábal (2018), Debroy et al. (2018) och Presler-Marshall et al. (2019) beskriver att opålitliga test, som inte ger konsekventa resultat, är en stor utmaning i automatiserade test. En vanlig orsak är enligt Mascheroni och Irrazábal (2018) att testskript försöker hitta element innan sidan har laddat klart. Detta problem uppkom både i TDP-projektet och Rask-projektet (O. Eriksson, personlig kommunikation, 4 maj 2020;
P. Berglund, personlig kommunikation, 4 maj, 2020). I Rask-projektet försvårades problemet p.g.a. den webbteknik som användes. Att få till stabila testskript i Rask-projektet var enligt O. Eriksson (personlig kommunikation, 4 maj, 2020) därför extra tidskrävande.
O. Eriksson (personlig kommunikation 4 maj, 2020) påpekar att opålitliga test bidrar till att betydande resurser används för att felsöka testskripten istället för att förbättra applikationer. I våra observationer tyckte vi också att det svåraste var att invänta element på rätt sätt, men att fungerande testskript plötsligt inte fungerade hände bara ett fåtal gånger.
6.2.5 Teststrategi
En bra teststrategi ska enligt Berner et al. (2005) och Alégroth et al. (2015) innehålla en kombination av tester på olika nivåer: enhetstester, integrationstester och systemtest.
Garousi och Yidirim (2018) menar att ett större antal testfall bör automatiseras på lägre nivåer och ett mindre antal på högre nivåer. O. Eriksson (personlig kommunikation, 4 maj 2020) beskriver sin vision av automatiserad testning på just det viset. På grund av webbtjänstens uppbyggnad kan enhetstester idag inte göras i C-Load. Detta kommer att ändras när C-Load migreras till Vue.js.
.
7 Diskussion del 2
Detta kapitel motsvarar steget “Presentera resultat” i den anpassade urvalsprocessen.
Resultatet av intervjuer och observationer diskuteras och forskningsfråga 2 besvaras.
Diskussionen delas in efter de teman som härrör från identifierade krav. Kapitlet avslutas med metodkritik och förslag till vidare forskning.
Applicerbarhet
Studien visar att det åtminstone i Chrome och Internet Explorer fungerar att med hjälp av Selenium WebDriver automatisera det grundläggande flödet i C-Load: att skapa lass, boka lass, lasta lass och lossa lass. Dock kan Selenium WebDrivers metoder inte alltid hantera Teleriks UI-komponenter på önskat sätt. I det testfall som användes i studien kunde alternativa lösningar med sämre precision användas, men det finns förmodligen testfall där detta orsakar större problem.
Enligt de erfarenheter som gjordes i Rask-projektet fungerar inte Selenium WebDrivers inbyggda metoder för att hantera väntetid i moderna webbramverk, där
applikationslogiken till stor del hanteras i webbläsaren och asynkrona anrop görs mot servern. I Rask-projektet ledde detta till betydande merarbete. Då Vue.js också är ett modernt ramverk uppstår sannolikt samma problem om Selenium WebDriver används när C-Load migreras till Vue.js.
Slutsats: Det är möjligt att automatisera regressionstester av C-Load med Selenium WebDriver, men potentiella problem finns på två områden:
Att hantera Teleriks UI-komponenter när mer komplicerade testfall ska automatiseras.
Att skapa stabila testskript när C-Load migreras till Vue.js
Webbläsare
Testskripten som skapades i studien fungerade i Chrome och Internet Explorer. I Firefox fungerade skripten delvis och i Edge inte alls. Hur de olika drivers som behövs för att testa i olika webbläsare ska installeras, vilka versioner som fungerar tillsammans och vilka inställningar som behöver göras är inte helt tydligt. Vi tror därför att problemen med Firefox och Edge går att lösa om man undersöker detta närmare.
Slutsats: Studien har inte kunnat visa att förväntningarna beträffande vilka webbläsare som kan användas för att testa C-Load med Selenium WebDriver uppfylls till mer än hälften. Det är förmodligen möjligt att lösa problemen med Edge och Firefox, men att problemen alls uppstår ökar den arbetsinsats som krävs för att automatisera GUI-test.
Exekveringstid
I det mycket begränsade test som gjordes för att kontrollera skillnaden i tid mellan att köra testen manuellt och med Selenium WebDriver tog det manuella testet i Internet Explorer endast 33% längre tid än det automatiserade. Som sagt ska inga långtgående slutsatser dras av detta, och det är säkert möjligt att förbättra testskripten så att denna skillnad blir större. Även tidigare forskning visar dock att GUI-tester är tidskrävande även om de automatiseras. Tidsvinsten ligger till stor del i att automatiserade tester kan köras kontinuerligt under lång tid och även på nätterna. Det är också på det viset automatiserade GUI-test körs i Rask-projektet. För att kunna köra testen oövervakade behövs väl fungerande rapportering och att testerna förses med data på ett effektivt sätt. För att
GUI-test inte ska ta för lång tid behövs en GUI-teststrategi där merparten av GUI-testen körs på lägre nivåer, så att antalet testfall på GUI-nivå inte blir så stort.
Slutsats: Det skulle gå snabbare att köra regressionstestfallen om Selenium WebDriver användes. Dock behöver ett mer komplett testramverk skapas och på sikt behövs en teststrategi som säkrar att antalet GUI-test inte blir för stort.
Effektivitet i att hitta defekter
Tidigare forskning visar att komponentbaserade verktyg är effektiva i att hitta defekter i funktionalitet. Observationer för att bekräfta eller förkasta att detta gäller när Selenium WebDriver används för att testa C-Load kunde som tidigare nämnts inte göras i denna studie. Att Selenium WebDriver är ett komponentbaserat verktyg medför att verktyget inte kan kontrollera att GUI:ts utseende är korrekt. Detta är en betydande nackdel då
regressionstesterna av C-Load också fungerar som acceptanstest. För att underlätta manuell kontroll av att GUI:t ser korrekt ut vore en möjlighet att låta Selenium WebDriver ta skärmbilder vid utvalda steg i automatiserade testfall.
Slutsats: Selenium WebDriver är förmodligen effektivt i att hitta defekter i funktionalitet i C-Load, men detta behöver verifieras innan Triona eventuellt fattar beslut om att använda verktyget. Selenium WebDriver kan däremot inte upptäcka defekter i hur GUI:t ser ut, vilket begränsar dess nytta i acceptanstester.
Total tid för testrelaterat arbete
Studien visar att de nackdelar med automatisk GUI-testning som beskrivs i litteraturen också upplevs när Selenium WebDriver används inom Triona. Att utveckla testskript är tidskrävande även för erfarna utvecklare. Speciellt gäller det moderna webbramverk där Selenium WebDrivers inbyggda metoder för att hantera väntetid inte fungerar.
En styrka hos C-Load-förvaltningen är att test och utveckling är integrerat, vilket innebär att det i test-teamet finns kompetens för att skapa och underhålla testskript. Tack vare denna styrka och att GUI:t i C-Load är stabilt tror vi att arbetet med att underhålla skript skulle vara överkomligt, förutsatt att POM eller liknande designmönster används. Även om teorin säger att det är underhållet som är den största utmaningen tror vi att det i fallet C-Load snarare är det arbete som krävs för att komma igång som kan vara ett hinder.
Detta speciellt eftersom C-Load inom ett par år ska flyttas över till Vue.js och testskripten då behöver skrivas om.
Slutsats: Automatisering med Selenium WebDriver kan på sikt leda till att den totala arbetstiden för att genomföra regressionstester i C-Load minskar. Dock är det tveksamt om det är värt att göra det arbete som krävs för att komma igång, eftersom C-Load inom ett par år har migrerats till Vue.js
Val av testfall
Slutsats: Med ett skriptbaserat verktyg som Selenium WebDriver skulle det gå bra att på samma sätt som idag välja ut testfall att köra från en bank av regressionstestfall.
Korrekt GUI
Att Selenium WebDriver inte kan kontrollera att GUI:ts utseende är korrekt är en betydande nackdel. För att underlätta manuell kontroll skulle Selenium WebDrivers funktion för att ta skärmbilder kunna användas på valda ställen i testskripten. Då behöver
inte hela testfall gås igenom manuellt, utan skärmbilderna som sparats kan kontrolleras i efterhand. En mer avancerad lösning kan vara att kombinera Selenium WebDriver, eller annat komponentbaserat verktyg, med ett visuellt verktyg, så som Alégroth et al. (2015) föreslår.
Slutsats: Selenium WebDriver uppfyller inte kravet att säkerställa att GUI:ts utseende är korrekt, men genom att ta skärmbilder skulle verktyget kunna användas för att underlätta den manuella kontrollen.