Slack har underlättat kommunikationen väsentligt genom möjligheten att använda olika ka- naler för de olika delarna av systemet för att lättare behålla fokus i konversationen på det aktuella området.
A
Xamarin Test Recorder, ett
alternativ till användartester? Av
Alexander Sääf
A.1
Introduktion
För att testa många applikationer används en stor mängd användartester som kan ta mycket tid och möda. Att hitta sätt att minska mängden användartester som behövs för att uppnå ett användarvänligt system är därför av stor vikt. I projektet Kunderbjudande i molnet använ- des Xamarin Test Recorder för att testa den mobilapplikation som utvecklades. Xamarin Test Recorder tillåter inspelning av knapptryckningar för att sedan köra igenom de inspelade se- kvenserna som tester. Kan ett verktyg som detta användas för att minska tiden som behöver läggas på användartester?
A.1.1
Syfte
Syftet med den här rapporten är att först beskriva Xamarin Test Recorder och hur det använ- des i projektet Kunderbjudande i molnet. Sedan kommer rapporten analysera vilken påverkan det hade på användartesternas resultat och utförande, och om verktyget kan användas som ett alternativ till användartester, eller hur väl det fungerar som ett komplement till dem.
A.1.2
Frågeställningar
1. Hur kan Xamarin Test Recorder användas i kombination med användartester för att skapa ett bättre resultat från testningen?
2. Kan verktyg som Xamarin Test Recorder minska mängden användartester som behövs, alternativt helt ersätta dem?
A.2
Bakgrund
Kunden till projektet önskade en applikation som inte är krånglig att använda, då många av de tänkta användarna inte har stor vana vid teknik och då vill man inte skrämma bort dem med en avancerad applikation. Det planerades därför direkt in användartester för ap- plikationen. Ett verktyg som upptäcktes under förstudien var just Xamarin Test Recorder, som verkade som ett lovande alternativ för att testa applikationen under utvecklingen. Detta
A.3. Teori
väckte frågan om mängden användartester som utfördes kunde minskas efter testning med hjälp av Xamarin Test Recorder.
A.3
Teori
Det här kapitlet beskriver teori som ligger till grund för resten av rapporten.
A.3.1
Användbarhet
Användbarhet handlar om hur användbart ett system är[33]. Det är svårt att definiera vad användbarhet är, men det kan delas upp i fem kategorier. Dessa fem kategorier kan vara mer eller mindre viktiga för olika system, men alla är relevanta för användbarheten av system.
Lärbarhet
Lärbarhet handlar om hur svårt systemet är att börja använda. Detta mäts ofta genom att ge användare enkla uppgifter och mäta hur väl de klarar det.
Effektivitet
Effektivitet handlar om hur snabbt användare kan genomföra uppgifter när de väl lärt sig hur man gör. För att mäta detta brukar man ofta räkna hur många knapptryck som krävs för att utföra uppgifter.
Minnesvärdhet
Minnesvärdhet handlar om hur lätt det är att minnas hur systemet fungerar. Kan användare fortfarande utföra de uppgifter de en gång klarade om de inte använder systemet under en tid?
Antal fel
Antal fel är just det det låter som. Denna kategori är bra eftersom den är mycket lätt att mäta, man behöver bara låta användare utföra uppgifter och mäta antalet fel de gör.
Användartillfredsställelse
Användartillfredsställelse handlar om hur tillfredsställda användare är med systemet. För att ta reda på detta får användare fylla i en enkät eller vara med i en intervju där de svarar på frågor om systemet.
A.3.2
Användartester
Användartestning är en metod för att testa användbarheten av systemet genom att låta användare som är representativa för systemets målgrupp testa systemet[34]. Användaren får ett par uppgifter som den sedan försöker utföra medans en observatör ser över testningen. Syftet med användartesterna är både att hitta användbarhetsproblem och att bedöma använ- darens övergripande belåtenhet med systemet.
Användartester har flera fördelar. Framförallt kan det hjälpa till med att hitta problem innan systemet byggts färdigt. Att hitta fel tidigt är mycket viktigt för att undvika att tid slösas. Under ett användartest kommer man kunna mäta och märka ett antal olika saker, som:
A.4. Metod
• Identifiera ändringar som behövs för att förbättra användarnas upplevelse med syste- met.
• Få veta hur nöjda användarna är över lag med systemet.
En annan styrka med användartester är att de kan utföras på olika sätt, och kraven på plat- sen där testerna görs är låga. Det räcker med ett rum med antingen en observatör eller en inspelningsutrustning för att spela in användarens utförande. De kan till och med göras med användare som inte befinner sig på samma fysiska plats som utvecklingsteamet plats. Användartesters kostnad varierar självklart beroende på hur många användare man vill testa med och hur ingående testerna är. Desto fler användare och uppgifter, desto längre tid kommer det att ta. Även att förbereda testerna tar tid, något som är viktigt att planera för.
A.3.3
Xamarin Test Recorder
Xamarin Test Recorder är ett verktyg som hör till Xamarins testlösningar vars uppgift är att göra det enklare att skapa tester för applikationens UI [15]. Xamarin har redan stöd för UI-testning, men då behöver en utvecklare själv skriva kod för varje knapptryckning och interaktion med applikationen. Med Xamarin Test Recorder behöver man bara starta inspel- ningen och sedan interagera med applikationen på önskat sätt. Alla interaktioner spelas in och översätts till testkod automatiskt.
A.3.4
Xamarin Test Cloud
Xamarin Test Cloud är en molnlösning för att köra tester från Xamarin Test Recorder i molnet [35]. Det ger möjligheten att kunna köra testerna på upp till 2000 olika enheter, något som inte är möjligt att göra själv. Det ger också en god överblick över systemets nuvarande tillstånd genom att sammanställa testresultaten på ett överskådligt sätt.
A.4
Metod
I projektet användes både användartester och tester gjorda med Xamarin Test Recorder. Des- sa utfördes framförallt i iteration 4 men även precis i slutet av iteration 3. En stor anledning till att testerna inte genomfördes tidigare är att det uppstod stora tekniska problem med Xamarin Test Recorder som tog lång tid att lösa. För att försöka genomföra motsvarande tester i användartesterna och de automatiserade testerna definierades först uppgifterna som en användare ska kunna göra. Dessa uppgifter var de uppgifter som användare i användar- testerna sedan skulle genomföra. De automatiserade testerna skapades genom att Xamarin Test Recorder kördes medans en utvecklare genomförde uppgifterna.
För att kunna jämföra de två metoderna och försöka svara på frågeställningarna togs nog- granna anteckningar om vilka fel och problem som upptäcktes, när de upptäcktes och av vilken metod de upptäcktes. Dessa anteckningar dokumenterades och sammanställdes för att avgöra vilka fel/problem som upptäcktes med båda metoderna, och vilka som bara en av dem upptäckte. Genom att jämföra dessa kan slutsatser dras om ifall användande av Xamarin Test Recorder kan göra det som användartester gör och, om det inte kan, vilka delar det missar.
För att kunna säga mer om hur Xamarin Test Recorder kan användas i kombination med användartester hölls en diskussion med de utvecklare som arbetat med mobilapplikationen med målet att ta reda på hur de upplevt att det påverkat utvecklingen och de användartester de genomfört.
A.5. Resultat
A.5
Resultat
I det här kapitlet kommer resultaten från användartesterna och de automatiska testerna be- skrivas.
A.5.1
Användartester
I användartesterna visade det sig att nästan alla användare klarade av alla uppgifter, även om en del tog lite tid på sig. I tabell A.1 visas resultaten från användartesterna. Utöver att få veta vilka uppgifter som var svåra att klara av gav detta också många kommentarer om delar av systemet som skulle kunna göras tydligare eller smidigare. Ett exempel på det är att många användare kände att inloggningsknappen borde vara större så att den är enklare att trycka på.
Tabell A.1: Uppgiftsgenomförande (Totalt 4 användare)
Uppgift Klarad Varav utan pro-
blem
Varav med svårig- het
1. Logga in 4 4 0
2. Hitta Cashback 4 3 1
3. Hitta kampanj 4 4 0
4. Ladda upp kvitto 4 4 0
5. Utnyttja erbjudande 4 1 3
6. Se kvittostatus 3 3 0
Den enda uppgift som någon användare misslyckades med att utföra var att läsa av sta- tusen på sitt kvitto. Användaren insåg inte att symbolen på kvittot var ett timglas och hittade ingen annan indikation på statusen. Användaren påpekade att det skulle gått att förstå när ett kvitto väl blivit godkänt så man såg skillnaden mellan godkända och väntande kvitton. Det som var mest problematiskt verkar vara själva utnyttjandet av erbjudanden. Det fanns flera problem som orsakade detta. En användare försökte till exempel ladda upp ett kvitto direkt från välkomstskärmen (som annars endast används för uppladdning för lagring av kvitton) och förväntade sig att sedan få välja ett erbjudande. Något annat som förvirrade flera användare när de skulle utföra uppgiften var knappen för att besöka ett byggvaruhus hemsida. Flera användare upplevde inte att den valda symbolen påminde dem om en länk eller hemsida, och flera användare hade också svårt att förstå varför knappen fanns där. Något som inte framgår i tabellen är att applikationen kraschade i ett användartest när användaren skulle logga in. Detta togs inte med i tabellen då användaren klarade inlogg- ningen utan problem efter att applikationen startats om. Felet störde dock testet och gav användaren en märkbart sämre inställning till testet.
A.5.2
Automatiska tester
De automatiserade testerna visade en väldigt positiv bild av systemets tillstånd, med väldigt få problem. I tabell A.2 visas resultatet från de automatiserade testerna. Det enda testet som inte gått igenom var att logga in, som i en testomgång kraschade. Beteendet var det samma som som en användare stötte på i ett användartest (Se A.5.1). Efter att det felet åtgärdats genomfördes den andra testomgången där alla tester blev godkända.
A.6. Diskussion
Tabell A.2: Automatiserade tester
Test Antal godkänt Antal underkänt
1. Logga in 1 1
2. Hitta cashback 2 0
3. Hitta kampanj 2 0
4. Ladda upp kvitto 2 0
5. Utnyttja erbjudande 2 0
6. Se kvittostatus 2 0
A.6
Diskussion
Det kan ses tydliga skillnader mellan resultaten från de automatiserade testerna och an- vändartesterna. Det kanske mest tydliga exemplet på detta är det problem som användarna upplevde när det gäller att utnyttja kampanjer och cashbacks. Även om användarna klarade uppgiften hade de flesta problem och många hade synpunkter om hur det skulle kunna vara tydligare. Detta pekar på att det finns ett problem med designen av applikationens gränssnitt. De automatiserade testerna däremot, visar snarare att denna del av applikationen fungerar utan problem, det automatiska testet för att utnyttja ett erbjudande blev godkänt i varje testomgång. Detta beror på att de problem som användarna inte stötte på var fel som ledde till en krash, utan endast gjorde att de hade svårt att förstå. De automatiska testerna kommer alltid att förstå hur de ska göra, då de endast följer vad som spelats in, vilket gjorts av de utvecklare som utvecklat gränssnittet. Detta är en stor skillnad som innebär att de auto- matiska testerna inte kan ge oss samma information och feedback som användartesterna kan. Ett annat exempel på information som de automatiska testerna inte gav är alla de kom- mentarer som användare gav när de använde applikationen. Det kan vara lätt att inte märka småsaker i en applikation som man själv utvecklat och det kan dessutom vara svårt att sätta sig in i hur de tänkta användarna kommer uppleva saker. Kommentarer som t.ex. att det var svårt att trycka på inloggningsknappen eller att det inte är uppenbart att ikonen för länkar symboliserar just en länk är därför mycket viktiga att få under utvecklingen. Detta är återigen något som de automatiska testerna inte ger oss, då de enbart utför sina inspelade uppgifter utan att behöva tänka på hur lätt eller svårt det är att trycka på en knapp, eller vad en ikon betyder.
Det finns dock stora fördelar med att använda sig av automatiserade tester för använ- dargränssnitt. När en användare stöter på tekniska fel i applikationen kan det irritera användaren och på så vis påverka resten av testet. Det kan leda till att användaren inte är lika engagerad i att ge bra feedback, eller rent av klagar på saker som användaren egentligen inte tycker förstör, bara på grund av irritationen från felet. Att undvika att en användare stöter på tekniska fel är således mycket viktigt för att få ut så mycket som möjligt av de användartester man genomför. En dator har inte detta problem. Oavsett hur många fel den stöter på kommer den fortsätta göra sitt jobb på samma sätt och resultatet av ett test kommer inte påverkas av resultatet från ett annat.
Denna skillnad kan användas för att förbättra resultaten av de användartester man ge- nomför. Genom att använda sig av automatiserade tester först för att försöka eliminera alla tekniska problem innan en omgång användartester genomförs kan man undvika att tekniska problem förstör användartesterna. Eftersom testerna är automatiska kan de köras ofta under utvecklingen för att alltid kunna vara säker på att applikationen inte dragit på sig nya fel, vilket är mycket enklare och snabbare än att anordna användartester efter varje ändring.
A.7. Slutsatser
A.7
Slutsatser
Vi har alltså sett att automatiserade tester gjorda med Xamarin Test Recorder inte kan ersätta användartester, eftersom de missar många av de viktiga delarna av användartester. Den vik- tiga feedback som fås från användarna i användartester saknas helt i de inspelade testerna. Detta innebär att användartester och inspelade tester inte testar samma sak, vilket är anled- ningen till att man inte kan få samma resultat om man byter ut användartester med inspelade tester. Det kan dock vara fördelaktigt att kombinera de två metoderna för att uppnå ett ännu bättre resultat. De automatiserade testerna minskar risken för att tekniska fel ska dyka upp i de användartester som genomförs, och användartesterna utvinner den viktiga feedback som utvecklingsteamet behöver för att bygga ett bättre system.
B
Lättviktig kodgranskning med
GitHub pull request av Lenny
Johansson
B.1
Inledning
Defekter i källkod är i stort sett oundvikliga vid större mjukvaruprojekt. För att identifiera defekter används olika processer och verktyg. Vid utveckling av mjukvarusystem är det även önskvärt att flera utvecklare känner till andra delar av kodbasen än sin egen i syfte att öka kunskapen om systemet så de enklare kan arbeta med andra delar av systemet vid behov. Kodgranskning gör det möjligt att hitta defekter i kodbasen samtidigt som utvecklarna lär sig mer om andra delar av systemet [36][37]. Kodgranskning kan utföras på olika sätt där varje teknik har sin egen process och tidsomfattning. Den här rapporten kommer beskriva och undersöka effekten av lättviktig kodgranskning med pull request i GitHub.
B.1.1
Syfte
Rapportens syfte är att beskriva, undersöka och utvärdera effekten av lättviktig kodgransk- ning med GitHub pull request. Rapporten beskriver den valda kodgranskningsprocessen och resultatet av processen. Resultatet ställs sen i kontrast med förbrukad tid.
B.1.2
Frågeställning
1. Vilken effekt gav kodgranskning med GitHub pull request i projektet? 2. Väger resultatet upp tidskostnaden av kodgranskningen?
B.2
Bakgrund
Kunden som har gett uppdraget för kandidatprojektet har önskan att implementera resulta- tet i sitt eget system. Under inledningen av kandidatprojektet tog därmed gruppen beslut om olika tekniker och arbetssätt för att öka sannolikheten att producera en stabil slutprodukt. Kodgranskning valdes därför som ett sätt att hitta defekter i kodbasen och därmed öka slut- produktens kvalitet. GitHub pull request valdes för kodgranskning eftersom gruppen redan använde GitHub för versionshantering och därför inte behövde några extra verktyg för att utföra kodgranskning. Jag valde att skriva om kodgranskning i det individuella bidraget för
B.3. Teori
B.3
Teori
Det här avsnittet beskriver teorin bakom kodgranskning och några av de mest förekomman- de kodgranskningsmetoderna. Avsnittet beskriver även pull request och hur pull request an- vänds i GitHub.
Kodgranskning
Kodgranskning är undersökning av källkod för att identifiera defekter i koden [38]. Kod- granskning är en mycket effektiv metod för att minska antalet defekter i slutprodukter [39]. Även om huvudmotivet bakom kodgranskning är att hitta och lösa defekter så bidrar även kodgranskning med överföring av kunskap och ökar kodkvaliteten genom att utvecklarna bättre följer angiven kodstandard [37]. Effekten av kodgranskning blir att defekter minskar i källkoden men även att utvecklarna som granskar varandras kod lär sig om andra delar av systemet än vad de själva skrivit.
Formell kodgranskning
Det finns flera typer av kodgranskning där de två huvudtyperna är formell kodgranskning och lättviktig kodgranskning. Formell kodgranskning (även kallad traditionell kodgransk- ning) är en välstrukturerad och noggrann process med möten där granskarna går igenom och diskuterar koden. Formell kodgranskning är effektiv på att hitta en stor andel fel men är även tidskrävande [40].
Lättviktig kodgranskning
Ett alternativ till formell kodgranskning är lättviktig kodgranskning. Lättviktig kodgransk- ning kan utföras på flera olika sätt där några av de vanligaste typerna är parprogrammering, epost-trådar och verktygsassisterad kodgranskning [38].
Efter en omfattande studie utförd av mjukvaruföretaget Smart Bear om lättviktig kodgransk- ning vid Cisco Systems publicerade Smart Bear riktlinjer för hur effektiv kodgranskning kan utföras [40]. Enligt studien är de två viktigaste faktorerna för effektiv kodgranskning att inte mer än 400 rader kod granskas åt gången med en rekommendation av 100–300 rader kod, och att granskarna ska granska mindre än 300 rader kod i timmen. Tidsrekommendationen för antalet rader kod per timma är given för att maximera antalet funna defekter per timma. Granskas för många rader kod så ökar risken att missa en stor mängd defekter, och spenderar man för mycket tid så är inte granskningen effektiv.
Pull request
I ett versionshanterat mjukvaruprojekt är det fördelaktigt att hålla huvudgrenen så stabil och defektfri som möjligt. Därför behöver grenar som ska sammanfogas med projektets hu- vudgren bekräftas innan de sammanfogas. Det är där pull requests används. En utvecklare skapar en pull request för den kod som utvecklaren har skrivit och vill sammanfoga med hu- vudgrenen [41]. Därefter notifieras de som ansvarar för hanteringen av pull requests. Koden granskas för defekter och om den håller angiven kodstandard. Granskarna avgör sedan om koden får sammanfogas med huvudgrenen eller om något behöver ändras.
Pull request i GitHub
Pull requests i GitHub utgör en lättviktig och verktygsassisterad form av kodgranskning. GitHub bidrar med ett grafiskt gränssnitt för att skapa, bekräfta eller begära förändringar av pull requests. GitHub gör det enkelt att se vad som har förändrats i en pull request och ger möjligheten att kommentera på defekter eller oklarheter i grenen som granskas [42]. Efter
B.4. Metod
en kodgranskning har skett i kombination med en pull request kan granskaren lämna kom- menterar, godkänna eller begära förändringar av grenen som blivit granskad. Blir grenen godkänd så kan den sammanfogas med huvudgrenen. Blir grenen inte godkänd så kommer pull requesten hållas öppen tills bristerna i grenen är lösta. GitHub gör det möjligt att tilldela granskare för pull requests och kräva att en pull request ska granskas innan den får samman- fogas med huvudgrenen.
B.4
Metod
Kodgranskning i projektet utfördes inom varje subgrupp med en till två granskare per pull request. När en utvecklare skapade en pull request tilldelades de andra subgruppmedlem- marna rollen som granskare. GitHub gör det även möjligt att begära att en pull request blir godkänd innan den får sammanfogas med huvudgrenen vilket även användes för pull