Av studiens resultat framgår att en stor utmaning när man skriver testskript för AGT är att hantera väntan på att element ska finnas tillgängliga på sidan innan man försöker utföra operationer på elementet. Det framkom också i studien att detta problem är än större i applikationer byggda med moderna webbramverk. Cypress är liksom Selenium WebDriver byggt i öppen källkod, men fungerar enligt en annan princip. Istället för att skicka kommandon till webbläsaren agerar Cypress istället “inuti” webbläsaren (Cypress, 2020). Detta gör enligt Cypress (2020) att verktyget ”vet” när element finns tillgängliga på sidan och utvecklare behöver inte bekymra sig om att definiera väntetider i skripten.
Studier som beskriver hur Cypress fungerar i praktiken och hur verktyget presterar jämfört med Selenium WebDriver vore mycket intressanta.
8 Slutsatser
Här ges en resumé av studien och de viktigaste slutsatserna av diskussionen presenteras.
Denna studie handlar om för- och nackdelar med olika typer av. verktyg för
automatiserade GUI-test och hur automatiserade GUI-tester med Selenium WebDriver fungerar i praktiken. Triona ville undersöka möjligheterna att automatisera
regressionstester av sin produkt C-Load, en molnbaserad webbtjänst för avtalsbaserad transportbokning. Regressionstesterna görs från GUI:t, vilket kräver särskilda verktyg.
Det primära syftet med studien är att med en anpassad urvalsprocess utvärdera ett möjligt verktyg i förhållande till C-Load-förvaltningens förväntningar på AGT och att utifrån resultatet föreslå hur C-Load-förvaltningen kan gå vidare med val av verktyg för AGT.
Baserat på tidigare forskning gjordes bedömningen att ett skript- och komponentbaserat verktyg där koden skrivs manuellt bäst uppfyller Trionas krav och förutsättningar. Detta eftersom det är komplicerat att skapa de modeller som används i modellbaserade verktyg, medan skriptlösa verktyg bör användas som ett komplement, inte som det enda verktyget.
Att använda ett komponentbaserat verktyg där koden skrivs manuellt motiveras främst av att detta bedöms minimera arbetet med att underhålla testskript. När C-Load-förvaltningen kommit igång med AGT kan det vara intressant att kombinera komponentbaserade med visuella test, för att kunna verifiera GUI:ts utseende.
Det verktyg som utvärderades var det i industrin mest använda skriptbaserade verktyget, Selenium WebDriver. Genom observationer och intervjuer kunde slutsatsen dras att det vore möjligt att automatisera regressionstester av C-Load med hjälp av Selenium WebDriver, och att det på sikt kan frigöra tid. Initialt skulle dock en betydande insats krävas för att implementera automatiserade tester. Selenium WebDriver uppfyller bara delvis C-Load-förvaltningens förväntningar på AGT och Triona bör utvärdera andra verktyg innan beslut fattas.
Något som bör beaktas vid valet av verktyg för AGT är att Selenium WebDriver är skapat för serverbaserad webbteknik. Att skapa testskript för applikationer byggda med moderna webramverk, där applikationslogiken till stor del hanteras i webbläsaren och asynkrona anrop görs mot servern, kräver en större utvecklingsinsats.
Att Selenium WebDriver inte fullt ut kan uppfylla C-Load-förvaltningens förväntningar ska inte tolkas som att verktyget ska uteslutas, eller att AGT är fel väg att gå. Det samlade intrycket är att AGT allmänt ses som mer eller mindre nödvändigt, men oavsett vilket verktyg som används lever AGT ofta inte riktigt upp till förväntningarna, då
arbetsinsatsen som krävs för att skapa och underhålla tester lätt underskattas. Det finns en konflikt i att med hög utvecklingstakt och korta utvecklingscykler är behovet av automatiserade tester stort, men samtidigt är det då som svårast att hantera underhåll av testskripten. Någon direkt lösning på detta dilemma verkar inte finnas, men problemet kan minskas genom att ha en teststrategi där merparten av testen körs på lägre nivåer, så att antalet testfall på GUI-nivå inte blir så stort
Källförteckning
Aho, P., Vos, T. (2018). Challenges in Automated Testing Through Graphical User Interface. 2018 IEEE International Conference on Software Testing, Verification and Validation Workshops (ICSTW), Västerås. Hämtad från
https://doi/10.1109/ICSTW.2018.00038
Alégroth, E. (2015). Visual GUI Testing: Automating High-level Software Testing in Industrial Practice. Doktorsavhandling, Chalmers tekniska högskola, Göteborg). Hämtad från https://research.chalmers.se/publication/221145
Alégroth, E., Feldt, R. (2017). On the long-term use of visual GUI testing in industrial practice: a case study. Empirical Software Engineering 22, 2937–2971. Hämtad från https://doi.org/10.1007/s10664-016-9497-6
Alegroth, E., Gao, Z., Oliveira, R., & Memon, A. (2015). Conceptualization and Evaluation of Component-Based Testing Unified with Visual GUI Testing: An Empirical Study. 2015 IEEE 8th International Conference on Software Testing, Verification and Validation (ICST), Graz. DOI: 10.1109/ICST.2015.7102584.
Bernardino, M., Rodrigues, E.M., Zorzo, A.F. & Marchezan, L. (2017).
Systematic mapping study on MBT: tools and models. IET Software, 11(4). doi:
10.1049/iet-sen.2015.0154
Berner. S., Weber. R., & Keller. R. K. (2005). Observations and lessons learned from automated testing. In Proceedings of the 27th international conference on Software engineering (ICSE ’05). Association for Computing Machinery, New York, NY, USA, 571–579. Hämtad från https://doi-org.www.bibproxy.du.se/10.1145/1062455.1062556 Bhargava, S., & Jain, P. B. (2018). Testing connect automated technologies. I-Manager's Journal on Software Engineering, 13(2), 18-24. Hämtad från
http://dx.doi.org/10.26634/jse.13.2.15225
Björklund, M. & Paulsson, U. (2012). Seminarieboken – Att skriva, presentera och opponera. Lund: Studentlitteratur.
Cypress. (2020). The web has evolved. Finally, testing has too.
Hämtad 2020-05-02 från https://www.cypress.io/
Debroy, V., Brimble, L., Yost, M., & Erry, A. (2018, 9-13 april). Automating Web Application Testing from the Ground Up: Experiences and Lessons Learned in an Industrial Setting. 2018 IEEE 11th International Conference on Software Testing, Verification and Validation (ICST), Västerås. Hämtad från
https://doi.org/10.1109/ICST.2018.00042
Dobslaw. F., Feldt. R., Michaëlsson. D., Haar. P., Gomes de Oliveira Neto F., & Torkar.
R. (2019). Estimating Return on Investment for GUI Test Automation Frameworks. 2019 EEE 30th International Symposium on Software Reliability Engineering (ISSRE), Berlin.
Hämtad från https://doi/10.1109/ISSRE.2019.00035
Ellims, M., Bridges, J. & Ince, D.C. (2006). The Economics of Unit Testing. Empirical Software Engineering 11, 5–31. Hämtad från https://doi.org/10.1007/s10664-006-5964-9
Eriksson, U. (2008). Test och kvalitetssäkring av IT-system. Lund: Studentlitteratur.
Fowler, M. (2018, 26 feb). The Practical Test Pyramid [Blogginlägg]. Hämtad från https://martinfowler.com/articles/practical-test-pyramid.html
Garousi. V., & Yildirim. E. (2018). Introducing Automated GUI Testing and Observing Its Benefits: An Industrial Case Study in the Context of Law-Practice Management Software.
2018 IEEE International Conference on Software Testing, Verification and Validation Workshops (ICSTW), Vasterås. Hämtad från https://doi/10.1109/ICSTW.2018.00042 Garousi, V. &. Mäntylä, M. (2016). A systematic literature review of literature reviews in software testing. Information and Software Technology, 80, 195- 216. Hämtad från https://doi.org/10.1016/j.infsof.2016.09.002.
IEEE (1994) Guide for Software Verification and Validation Plans," in IEEE Std 1059-1993, vol., no., pp.1-87, 28 April 1994, doi: 10.1109/IEEESTD.1994.121430. Hämtad från https://ieeexplore.ieee.org/document/838043
Janicki, M., Katara, M., & Pääkkönen, T. (2012). Obstacles and opportunities in deploying model‐based GUI testing of mobile software: a survey. Software Testing, Verification and Reliability, 22(5), 313-341. Hämtad från https://doi.org/10.1002/stvr.460
Leotta. M., Clerissi. D., Ricca. F., & Tonella P. (2013). Capture-replay vs. programmable web testing: An empirical assessment during test case evolution. 2013 20th Working Conference on Reverse Engineering (WCRE), Koblenz. Hämtad från
https://sepl.dibris.unige.it/publications/2013-leotta-WCRE.pdf
Mascheroni, M. A., & Irrazábal, E. (2018). Continuous testing and solutions for testing problems in continuous delivery: A systematic literature review. Computación y Sistemas, 22(3), 1009-1038. Hämtad från http://www.scielo.org.mx/scielo.php?pid=S1405-55462018000301009&script=sci_arttext
Microsoft. (2019a). An introduction to NuGets. Hämtad 2020-04-29 från https://docs.microsoft.com/en-us/nuget/what-is-nuget
Microsoft. (2019b). What features and services do I get with Azure DevOps? Hämtad 2020-05-14 från
https://docs.microsoft.com/en-us/azure/devops/user-guide/services?view=azure-devops
Nguyen, B.N., Robbins, B., Banerjee, I., Memon, A. (2014). GUITAR: an innovative tool for automated testing of GUI-driven software. Automated Software Engineering 21, 65–
105. https://doi.org/10.1007/s10515-013-0128-9
Oates, J. B. (2006). Researching Information Systems and Computing. London: SAGE.
Orakel (2020). Ord och uttryck i it-branschen. Hämtad 11 maj 2020 från https://it-ord.idg.se/ord/orakel/
Prabhu, J., Malmurugan, N. (2013). A Model for GUI Automated Testing Framework.
Software System. International Journal of Computer Applications, 64(15), 16-20. Hämtad från https://doi/10.5120/10710-5674
Presler-Marshall, K., Horton, E., Heckman, S., & Stolee, K. (2019, May). Wait, Wait. No, Tell Me. Analyzing Selenium Configuration Effects on Test Flakiness. 2019 IEEE/ACM
14th International Workshop on Automation of Software Test (AST). IEEE. Hämtad från https://doi/10.1109/AST.2019.000-1
Xie, Q. Memon, A. M. (2007). Designing and comparing automated test oracles for GUI-based software applications. ACM Transactions on software engineering and
methodology, 16 (1). DOI:https://doi.org/10.1145/1189748.1189752
Raulamo-Jurvanen, P., Mäntylä. M., & Garousi. V (2017). Choosing the Right Test Automation Tool: a Grey Literature Review of Practitioner Sources. In Proceedings of the 21st International Conference on Evaluation and Assessment in Software Engineering (EASE’17). Association for Computing Machinery, New York, NY, USA, 21–30. Hämtad från https://doi.org/10.1145/3084226.3084252
Selenium. (2020a). The Selenium Browser Automation Project. Hämtad 2020-05-02 från https://www.selenium.dev/documentation/en/
Selenium. (2020b). Page object model. Hämtad 2020-05-26 från
https://www.selenium.dev/documentation/en/guidelines_and_recommendations/page_obje ct_models/
Thummalapenta. S., Sinha. S., Singhania. N., & Chandra. S. (2012). Automating test automation. In Proceedings of the 34th International Conference on Software Engineering (ICSE ’12). IEEE Press, 881–891. Hämtad från
https://dl.acm.org/doi/10.5555/2337223.2337327
Utting, M., Pretschner, A., & Legeard, B. (2012). A taxonomy of model‐based testing approaches. Software testing, verification and reliability, 22(5), 297-312. Hämtad från https://doi.org/10.1002/stvr.456
Vila, E., Novakova, G., & Todorova, D. (2017). Automation testing framework for web applications with selenium WebDriver: Opportunities and threats. International Conference on Advances in Image Processing. Hämtad från
https://doi/10.1145/3133264.3133300
Vos. T. E. J., Marín. B., Escalona. M. J., & Marchetto. A. (2012). A Methodological Framework for Evaluating Software Testing Techniques and Tools. 12th International Conference on Quality Software, Xi'an, Shaanxi. Hämtad från
https://doi/10.1109/QSIC.2012.16
W3C (2018) W3C Recommendation 05 June 2018 Hämtad från https://www.w3.org/TR/2018/REC-webdriver1-20180605/
W3C (u, å) About W3C. Hämtad från https://www.w3.org/Consortium/
Wetzlmaier. T., & Ramler, R. (2017). Hybrid monkey testing: enhancing automated GUI tests with random test generation. In Proceedings of the 8th ACM SIGSOFT International Workshop on Automated Software Testing (pp. 5-10). Hämtad från
https://dl.acm.org/doi/abs/10.1145/3121245.3121247
Zeng. Y. (2014). Relationships between different versions of Selenium [Blogginlägg].
Hämtad från https://yizeng.me/2014/04/25/relationships-between-different-versions-of-selenium/
Bilaga 1: Intervjuguide
Frågor till Mirjami Olsson, förvaltningsledare och testledare C-Load Arbetssätt
Hur är arbetet med olika produkter och projekt organiserat?
Är både utvecklare och testare knutna till specifika produkter och/eller projekt eller är det mer rörligt?
Jobbar man på samma sätt med test i hela organisationen eller varierar det?
Test
Hur använder Triona automatiserade test i andra sammanhang än just regressionstester av GUI?
Använder Triona automatiserade regressionstester av GUI i andra produkter/projekt?
C-Load
Hur ser arkitekturen för C-Load ut?
Byggt med ASP.NET Core eller annat?
Test av C-Load
Hur går testningen av C-Load till idag?
Verktyg? NUnit? xUnit? Annat?
Miljöer?
Regressionstester C-Load
Hur ofta sker regressionstester av C-Load?
Hur lång tid tar det?
Hur mycket av regressionstesterna är redan automatiserade?
Vilka testfall körs för GUI regressionstester/Hur avgörs vilka testfall som ska köras?
Är tiden för test eller antalet testfall som körs variabelt?
Körs tillräckligt antal testfall eller skulle man behöva testa mer?
Hur rapporteras och sammanställs resultatet?
Frågor till övriga respondenter
Från vilket/vilka projekt/produkter har du erfarenhet av automatiserad GUI-testning?
Vilken roll hade du?
Varifrån kom initiativet att använda automatiserade GUI-test?
Vilka motiv fanns för att automatisera? / Vilka förväntningar fanns?
Vilket testverktyg användes?
Bakgrund till att testverktyget ni använde valdes? Vilken typ av system handlade det om?
(Web service? Desktop app?) Framework och språk för detta system?
I vilka test användes automatisering?
Motiv till att automatisera just dessa test?
Hur gick arbetet med automatiseringen till?
Fördelar jämfört med manuella tester?
Nackdelar jämfört med manuella tester?
Uppfylldes förväntningarna?
Bilaga 2: Kodexempel Page Object Model (POM)
I den första bilden utförs en inloggning på en loginsida och sedan navigerar skriptet till knappen för att lägga till ett nytt lass. I bild 1 finns all logik samlad i samma klass. Hur vi identifierar elementen, utför handlingar och hanterar waits. I bild 1 används långa Xpaths.
I bild 2 och 3 har vi implementerat POM och brutit ur logiken för att identifiera element och utföra handlingar till en LoginPage (Page Object) som innehåller metoder för identifiering och alla händelser. Här används ID selektorer istället för Xpath. I bild 3 använder vi bara metoderna från respektive page object. Allt som sker i bild 1 sker i bild 3 på de fyra första raderna av skriptet.
1.
2.
3.
Bilaga 3: Transkriberingar av intervjuer
Intervju 1 med Mirjami Olsson, förvaltningsledare och testledare
Fråga: Är både utvecklare och testare knutna till specifika produkter eller är det mer rörligt?
Svar: Det är definitivt mer rörligt. En del sitter heltid i ett projekt medans andra sitter deltid i flera projekt.
Fråga: Kallas alla produkter för projekt?
Svar: Det korrekta namnet är förvaltning.
Fråga: Du nämnde att C-Load fått en anmärkning på att ni inte använder automatiska enhetstester, vad innebär det?
Svar: Det är på grund av en ny kartläggning som vår CFO har gjort på hur det ser ut i de olika förvaltningarna. Där fick man en grön om det var okej, gul om en person har en viss kompetens eller röd om det saknas. Det fungerade som notiser till förvaltningar. T.ex för oss så fick vi en notis om att vi ska titta på ramverk för automatiserade enhetstester. En hälsokontroll som följs upp årligen.
Fråga: Om vi sätter upp skript för att prova med Selenium så kommer vi använda ett testframework, är det viktigt att vi väljer ett som ni tänker använda sen eller spelar det ingen roll?
Svar: Detta arbete har inte påbörjat från vårt håll, däremot har nog Thomas redan koll på vilket ramverk som är tänkt att användas. Det spelar nog inte så stor roll.
Fråga: Används automatiska tester i andra sammanhang än GUI?
Svar: Det varierar mycket mellan förvaltningar. Det är styrt av kraven.
Regressions tester på GUI är mindre vanliga än andra typer av tester.
Fråga: Kan du berätta lite allmänt om testning av C-Load?
Svar: Vi har en teststrategi i C-Load som säger hur och när vi ska testa, för kvalitetssäkringen och hur hela processen ser ut. Jag har valt som testledare att inte uppdatera den nu eftersom vi ska gå över till azure devops och då kommer vår test process förändras, vi går ifrån den klassiska vattenfallsmetoden till att ha mer scrumliknande testning och dels testa mycket tidigare och måste göra om strategin mer, därför är strategin lite eftersläpande. Testen börjar när vi kravar ett ärande och då analyser, kravinsamlare, krav är en del av test. När det är klart och vi är nöjda, då går det över till “färdigt” eller definition of ready, då utveckling kan börja, vi kör med testdriven utveckling så när utvecklarna börjar så startar dom med ett testfall. Jag verifier att dessa stämmer överens med kraven så att vi har sett kraven på samma sätt. När det är utvecklat så kan ärenden läggs ut på betamiljön och testas där. Vi jobbar med ganska hårda datum där vi följer en
utvecklingsperiod nu till sista februari kodstop och mars testperiod och driftsätter första april. När alla tester är gjorda och alla buggar är rättade uppdateras miljön till senaste versionen och då kan regressionstesterna börja och testar vi inte bara det som är ändrat utan hela flödet med speciellt fokus på det som är ändrat.
Regressionstestfallen hämtas ur en regressionstestbank där alla tidigare versioner sparas och kan plockas fram och ändrade till aktuell release.
Fråga: Vem är det som testar?
Svar: Som vi som är ett litet team så är jag både testledare och testare men jag kan inte sitta och testa själv allting, det skulle jag inte hinna så då så har vi en som är med och testar och en som är supportpersonal som också testar. Även utvecklare och produktägare sitter med och testar. Så lite beroende på hur stor release det är
så fördelar vi tester till olika personer inom förvaltningen. Så alla får mer eller mindre ta på sig en testhatt.
Fråga: Hur ofta testar ni?
Svar: Det är fyra planerade releaser, en per kvartal, så det är fyra gånger per år som vi har testperioder där vi regressionstester nya releases. Men däremellan kommer oplanerade och planerade patcher som behöver testas. Ibland väljer vi också att dela upp en release i två mindre. Test kan ske hela tiden men minst under dessa perioder. Innan man börjar testa så har man gjort en testplanering där man tar fram fall, testar dom, fylla med testdata, planering och genomförande. Varje release har en testplan med arbetsfördelning och vad som ska testas.
Fråga: Vilka miljöer finns?
Svar: Vi har en produktionsmiljö, en betamiljö med en produktionsdatabas, en acceptanstestmiljö, en demomiljö och en testmiljö med en testdatabas.
Fråga: Hur lång tid brukar det ta?
Svar: Det är sällan vi har mer än en vecka på att regressionstesta. Om man räknar in dokumentation, skriva användarhandledning, release notes och planering så är det är en längre period men själva testningen är en kort period.
Fråga: Hur väljer du vilka testfall som ska testas?
Svar: Vi har alltid en bas som testas och sen går jag igenom versionen vi har jobbat med och ser vad som behöver testas. Sen går man på erfarenhet vad man vet brukar behöva testas.
Fråga: När ni ska testa, har ni en viss tid på er och vad händer om ni inte hinner?
Stryker ni test eller flyttas tiden?
Svar: Det är testledaren som sitter på det beslutet, är systemet tillräckligt bra för att driftsättas? Senaste releasen fick vi flytta fram releasen två veckor t.ex, det gjorde vi dock innan testperioden började men såg direkt att det inte skulle hinnas med. Det har behövts göra ibland.
Fråga: Varför vill man automatisera?
Svar: För att spara tid och för att datorer ibland är mer att lita på än människor.
Speciellt för repetitiva uppgifter. För att se till att ett flöde fungerar som det ska och kunna täcka in fler test på samma tid.
Fråga: I de test case som vi har fått tilldelade, det viktiga är alltså att flödena fungerar från början till slut?
Svar: Ja precis, i de vanligaste webbläsarna.
Fråga: Är det viktigt att tiden man lägger totalt ska bli mindre för att få en bra ROI?
Svar: Det ska definitivt inte ta mer timmar för då är det inte värt utan någonstans vet vi att det är tidskrävande att testa och vi skulle genom att frigöra tid att utvecklaren kan börja på nästa release och jobba på en annan branch så målet är att det tar färre mantimmar på det hela. Men det är en avvägning på att det ska ta lite tid och ha en bra testtäckning så det är en avvägning man får göra men helt klart att det inte ska ta två heldagar att gå igenom flödet varje gång.
Fråga: Är det något som ni ser som en potentiell risk?
Svar: Att tappa det mänskliga ögat så att säga, eftersom vi inte har en kund som kör acceptanstester. Flödet fungerar men det ser inte bra ut t.ex. Själva känslan.
Intervju 2 med Hansi / Utvecklare
Fråga: Vilken roll har du haft i tidigare projekt som använt sig utav automatiserad testning?
Svar: Utvecklare och delade arkitektrollen med några andra.
Fråga: Vad var det ni gjorde?
Svar: Vi byggde ett system som bara kommunicerar med andra system.
Huvuddelen ligger på integration.
Fråga: Använde automatiska tester i delen av projektet du var en del va?
Svar: Absolut, enhetstester. Det är en kvalitetsfråga, vi bygger ingenting utan automatiska tester. I det projektet jag sitter i nu på ABB, det är en desktop application med CAD. Otroligt komplext med många år på nacken, det är svårt att leverera med kvalitet. Vi är beroende av att helt test team i Indien som kör regressionstester osv. på det och dom fångar inte allt som vi behöver få fångat. så automatisk testning är en förutsättning för att kunna leverera med kvalitet.
Fråga: Vad använder ni för verktyg/framework för enhetstestning
Svar: Vi körde med Visual Studio, TFS och C# framförallt men också Typescript och även .NET och .NET Core. Själva testerna kördes med Xunit och lite
Svar: Vi körde med Visual Studio, TFS och C# framförallt men också Typescript och även .NET och .NET Core. Själva testerna kördes med Xunit och lite