Resultat från användbarhetstestning

I detta avsnitt redovisas de resultat som vi fick fram av användbarhetstestet och analysen av svarsdatan från testerna som utfördes. Användbarhetstestet är också av betydelse för att svara på vår andra huvudfråga, om man kan “testa, jämföra och värdera CI-system”. I just denna studie kommer vi inte att utföra användbarhetstestet på flera olika CI-system men det är något som kan vara intressant att utföra (se avsnitt 6.3 “fortsatt forskning”). Bilaga 6 påvisar hur vi samlat och sammanställt data som kommer att presenteras grafiskt i form av diagram. Bilaga 7 är användarenkäten som användes för att samla in denna data och agerar som ett gränssnitt mellan oss och testare. Läsaren hänvisas till dessa bilagor för att ta del av mer utförlig information kring genomförandet av användbarhetstester. Resultatdatan som kommer att presenteras i detta avsnitt berör olika aspekter av användbarhetstestet som vi tycker är extra intressanta att titta på. Olika statistik kring utförandet av testerna samt testarnas subjektiva intryck av att lösa uppgifter och av TeamCity i sin helhet kommer att åskådliggöras. Samtliga diagram belyser skillnader mellan testgruppen som bestod av 5 testare och kontrollgruppen som bestod av 1 testare. Vi analyserar resultaten som redogörs och kan i vissa fall även tolka resultaten. Varje diagram förses med en förklaring till hur mätningen genomfördes och ibland även en förklaring till varför vi mätte just detta. Därefter följer en saklig redogörelse av hur datan som presenteras i diagrammen ska avläsas, följt av en subjektiv tolkning av datan där detta är möjligt.

Sida | 47 Totalt antal uppgifter som löstes

Vi kontrollerade hur många uppgifter av totalt 17 st som löstes av testare efter varje testsession via användarenkäten och inspelningar. En del testare ansåg sig vara klara med vissa uppgifter men det framkom efter granskning av inspelning att detta inte stämde, vi korrigerade svarsdatan utefter vår uppfattning om huruvida uppgiften löstes korrekt eller ej. Vi kan på nedanstående stapeldiagram avläsa att kontrollgruppen löste alla 17 uppgifter medan testgruppen löste nästan alla 17 uppgifter. Testgruppen hade 16.4 uppgifter lösta i snitt vilket innebar att 3 fel uppstod under de 5 testsessionerna. Varför testgruppen inte lyckades lösa alla uppgifter är svårt att avgöra utifrån den data som vi samlade in, det kan antingen bero på att användarenkätens uppgiftbeskrivning för vissa uppgifter var otydlig eller yttre faktorer som att TeamCity i vissa fall är så användarvänlig och layout-mässigt anpassad för att stödja nya användare att utföra vissa operationer. Eftersom felen uppstod bland 3 olika uppgifter (uppgift 3, 4 och 14) är det mer sannolikt att det har att göra med interaktionen mellan testare och TeamCity snarare än ett allmänt fel i utformandet av användarenkäten. Vi menar att ett fel i användarenkäten hade kommit till uttryck om olika testare begick samma fel under utförande av testet (dvs. om felet uppstod på samma uppgift). Uppgifterna i vilka fel uppstod tillhör huvudområdena “Anpassning av systemet för användarens behov”, “Inlärning av systemets funktioner” och “Inge förtroende och tillfredsställelse”.

Trots vår diskussion om de 3 felen som uppstod kan vi konstatera att det nästan “perfekta resultatet” för antal korrekt utförda uppgifter tyder på att TeamCity stödjer lärbarhet för användare som aldrig använt systemet tidigare.

Sida | 48 Total tid för utförande av samtliga uppgifter

Vi tittade inte bara på hur många uppgifter som löstes, vi tittade även på hur lång tid det tog för testarna att utföra alla uppgifter. Vi gjorde detta genom att gå igenom inspelningarna av testsessionerna och kolla hur lång tid det tog för varje testare att gå vidare till nästa uppgift, från att uppgift 1 påbörjades till att uppgift 17 avslutades.

Vi ser intressant data i nedanstående stapeldiagram (jämfört med diagrammet för “totalt antal uppgifter som löstes”). Kontrollgruppen genomförde samtliga uppgifter på 20 minuter och 19 sekunder, medan testgruppen utförde uppgifterna på 43 minuter och 18 sekunder. Vi ser därför en markant skillnad mellan oerfarna TeamCity användare och erfarna användare med avseende på hur snabbt vissa operationer kan utföras i TeamCity.

Att kontrollgruppen utförde samtliga uppgifter betydligt snabbare än testgruppen tyder på att TeamCity stödjer användbarhetsattributet effektiv användning.

Sida | 49 Användarnas tillfredsställelse av att lösa samtliga uppgifter

Efter varje utförd (eller outförd) uppgift angav testaren hur han eller hon upplevde att uppgiften löstes. Detta gjordes utefter en Likert skala där 1 innebär en låg tillfredsställelse med utförandet av en viss uppgift och 5 innebär hög tillfredsställelse.

I stapeldiagrammet kan vi avläsa en relativt hög nivå av tillfredsställelse för båda grupperna, dock ser vi att testgruppen var aningen mindre tillfredsställd i genomsnitt. Detta beror förmodligen på att testarna i testgruppen inte alltid visste hur de ska göra för att lösa vissa uppgifter. Vi kan också efter granskning av testformuläret se en korrelation mellan missnöje och misslyckande av utförandet av specifika uppgifter. Om vi tittar på kontrollgruppen kan vi se att testaren angivit nivå 5 av tillfredsställelse på samtliga uppgifter förutom uppgift 1, 6 och 11. Dessa uppgifter tillhör huvudområdet “Inlärning av systemets funktioner”. Om vi istället tittar på testgruppen kan vi se att testarna angivit en hög nivå av tillfredsställelse med 5,0 i snitt för uppgift 8 och 13. En låg nivå av tillfredsställelse kan vi avläsa för uppgift 4 med 2,8 i snitt. Uppgifterna med ett högt utslag tillhör huvudområdena “Inlärning av systemets funktioner” och “Minimera inverkan av fel”. Beträffande uppgiften med lågt utslag tillhör den huvudområdet “Anpassning av systemet för användarens behov”.

Vi kan se att på det stora hela verkar TeamCity stödja användbarhetsattributet tillfredsställelse. Det verkar dock finnas rum för förbättring när det gäller användarens tillfredsställelse och upplevelse av hur pass anpassningsbart systemet är för användarens behov.

Sida | 50 Total tid för utförandet av enskild uppgift

Under efterbehandligsfasen av testsessionerna tittade vi på hur lång tid det tar för varje testare att utföra varje enskild uppgift. Startpunkt och slutpunkt markerades när testaren påbörjade en ny uppgift i användarenkäten genom att gå till nästa sida. På så sätt kunde vi ta tidspunkter på ett objektivt sätt istället för att gissa oss fram till när en viss uppgift påbörjades eller avslutades. Vissa testare kommunicerade även med oss mellan utförandet av uppgifter, detta noterades och räknades bort för att inte driva upp datan till högre nivåer pga. dessa “pauser”.

Vi kan väldigt tydligt se från linjediagrammet att kontrollgruppen låg snäppet under testgruppen vad gäller snabbheten i att utföra uppgifterna. Dock kan vi se att genomsnittstiden för utförandet av enskild uppgift för testgruppen var aningen lägre på 1 minut och 10 sekunder jämfört med 1 minut och 16 sekunder för kontrollgruppen. Vad detta kan bero på är svårt att fastställa, dock kan vi konstatera att det har att göra med uppgiften “Kompilera källkod för ett projekt” som tillhör responsen “Det är enkelt att automatisera funktioner som ofta kommer att användas” och huvudområdet “Inlärning av systemets funktioner”.

Sida | 51 Tidigare erfarenhet av CI-system

Till skillnad från tidigare redovisad resultat så presenterar vi via detta stapeldiagram inte mätningar. Vi redogör här hur testarna har svarat när de tillfrågades vilken tidigare erfarenhet de har av CI-system och vilken CI-systemmjukvara de har använt sig av.

Som nämnt i utförandet av användbarhetstestet så var målgruppen för testerna användare som både hade erfarenhet av CI-system tidigare men ej av TeamCity och användare som tidigare använt sig av TeamCity. Detta åskådliggörs rätt tydligt i stapeldiagrammet då vi ser att endast testaren från kontrollgruppen angav att han hade erfarenhet av TeamCity. Han angav även erfarenhet av CruiseControl.net.

Slutligen vill vi även påpeka att tidigare erfarenhet av CI-system kan ha en betydelse för olika statistik och data som erhålls från denna typ av användbarhetstest. Det kan vara så att Jenkins är likt eller olikt till användning och utseende som TeamCity. Detta innebär att inlärningskurvan för TeamCity kan bero på vilken tidigare erfarenhet av CI-system man har, därför är detta viktigt att belysa och ta hänsyn till både i vår studie och liknande studier, genom att exempelvis ställa motsvarande fråga i andra enkäter.

Sida | 52 Hur pass väl stödjer TeamCity “Lärbarhet”?

Som tidigare nämnt så använder vi oss av 4 användbarhetsattribut för att fastställa vilket intryck testarna har av TeamCity. Vi börjar med att diskutera lärbarhet. Lärbarhet har att göra med hur snabbt användaren lär sig använda systemet och hur lätt det är att minnas hur man använder systemet.

Vi kan från diagrammet avläsa att kontrollgruppen angav den högsta nivån för lärbarhet. Kanske beror detta på att denna testare redan är bekant med hur TeamCity används och därför även anser att nya användare kommer att snabbt kommer att lära sig hur man använder TeamCity.

Om vi tittar på testgruppen kan vi se att de allra flesta svarat att de anser att TeamCity stödjer lärbarhet. Denna data är aningen mer intressant att titta på, främst pga. dessa testare uppgav att de inte använt TeamCity tidigare. Detta tyder på att nya användare efter utförandet av 17 uppgifter tycker att TeamCity är ganska bra på att lära användaren hur man kommer igång med användningen av CI-systemet.

Sida | 53 Hur pass väl stödjer TeamCity “Effektiv användning”?

Effektiv användning av ett system innebär att en användare snabbt kan utföra operationer i systemet och kan effektivisera det han eller hon genomför med hjälp av systemet ju mer bekant han eller hon blir med användandet av systemet.

Resultatdatan som åskådliggörs via diagrammet påvisar även här att de flesta testare har en uppfattning om att TeamCity stödjer effektiv användning. Till skillnad från föregående diskussion om lärbarhet, är det mer betydelsefullt att belysa kontrollgruppens uppfattning av effektiv användning. Detta eftersom en testare med tidigare erfarenhet av TeamCity förmodligen har använt systemet under en viss tid och kan därför ha en uppfattning om TeamCity “håller i längden”. Om vi tittar på testgruppen kan vi se att de flesta angett nivå 4 för just detta användbarhetsattribut. Både testare 4 och 5 har angett att TeamCity stödjer effektiv användning trots att deras totala tid för utförandet av uppgifterna hörde till de längre tidtagningarna.

Tolkning: Att de markerat nivå 5 kan bero på att de under testets gång ansåg att det gick fortare framåt när de lärde sig använda systemet bättre, men kanske också pga. testsessionen var så pass långt gången att de snabbt ville “fylla i den sista sidan” i användarenkäten och bli klara med testsessionen.

Sida | 54 Hur pass väl stödjer TeamCity “Tillförlitlighet”?

Ett system som är tillförlitligt är ett system utformat på så sätt att en användarens interaktion med systemet genererar ett lågt eller obefintligt antal fel vid “normalt bruk”. Tillförlitlighet innebär även att ett system snabbt kan återhämta sig från fel som kan uppstå. Som vi kan se på diagrammet nedan så har samtliga testare angett högsta nivå för att påvisa att TeamCity stödjer tillförlitlighet. Detta är rätt ointressant data att diskutera eftersom det inte finns någon variation, dock kan vi konstatera att TeamCity är ett tillförlitligt system utifrån denna data.

En intressant sak som vi kan påpeka är testare 3’s svar på frågan. Denna testare angav att han inte hade tillräckligt med erfarenhet av TeamCity för att dra denna slutsats och att ytterligare användning av TeamCity krävs för att på ett bestämt sätt kunna fastställa om TeamCity faktiskt är tillförlitligt.

Sida | 55 Hur pass väl stödjer TeamCity “Tillfredsställelse”?

En användares tillfredsställelse med ett system är hur denna individ subjektivt upplever användningen av systemet. Som nämnt har testaren efter varje uppgift svarat på hur tillfredsställd han eller hon är med hur uppgiften löstes. Även på slutet av användarenkäten frågar vi testaren hur tillfredsställd han eller hon är med TeamCity i stort.

Vi kan även i detta diagram se en homogenitet mellan svarsdatan där endast små avvikelser förekommer. De allra flesta testare har angett nivå 4 av tillfredsställelse för TeamCity.

Ännu en intressant sak som kan påpekas är testare 2’s svar för denna fråga där testaren angett att en längre tid med användandet av CI-systemet krävs för att kunna fastställa om TeamCity är tillfredsställande att användas.

Sida | 56

5. Slutsats

Vår frågeställning bestod av 2 huvudfrågor och 4 delfrågor (se avsnitt 1.3).

Efter genomförd marknadsundersökning och litteraturundersökning kan vi dra en slutsats kring vad ett CI-system principiellt bör bestå av, vilka funktioner den bör förse användaren med samt vilka kvalitetsattribut som bör eftersträvas.

Svaren till vår första huvudfråga “Vilka funktionella och icke-funktionella krav måste CI-

system uppfylla för att vara till nytta för användning?” är följande:

● Funktionella krav:

○ Källkodshantering (eng. source code management) ○ Kompilering av källkod (eng. build/compile source code)

○ Exekvering av byggskript (eng. running arbitrary build scripts), med möjlighet till byggautomatisering (eng. enable build automation)

○ Körning av tester (eng. run tests)

○ Notifiering av status för bygge (eng. feedback/notification of build status) ○ Stöd för paketering och distribution av mjukvara (eng. support deployment of

stable software)

● Icke-funktionella krav:

○ Prestanda (eng. performance) ○ Användbarhet (eng. usability) ○ Tillförlitlighet (eng. reliability) ○ Utbyggbarhet (eng. extensibility) ○ Stabilitet (eng. stability)

○ Underhållsmässighet (eng. maintainability)

Efter genomförd användbarhetstest kan vi även besvara vår andra huvudfråga och därmed validera en del av den slutsats vi fått fram via första huvudfrågan.

Vår andra huvudfråga “Kan man enligt fastställda krav testa, värdera och jämföra CI-

system?” besvaras positivt via de resultat som vi redogör i avsnitt 4.4.6. Genom en

utvärdering av användbarhet för CI-systemet TeamCity demonstrerade vi detta praktiskt. Genom att använda sig av testformuläret som vi fick fram under utförandet av användbarhetstestet och genom att modifiera användarenkäten för ett annat CI-system kan man även utföra användbarhetstestet för andra CI-systemmjukvaror.

Sida | 57 Delfråga 1 “Vilken mjukvara för CI-system används mest?” besvaras av både litteratur- undersökningen och marknadsundersökningen.

Enligt undersökningarna kom vi fram till följande: ● Litteraturundersökningen pekar på:

○ CruiseControl och dess varianter ○ Jenkins ○ Hudson ○ Bamboo ○ TeamCity ○ Buildbot ● Marknadsundersökningen pekar på: ○ Jenkins ○ TeamCity

CruiseControl och dess varianter nämns fortfarande i litteratur och är en väletablerad CI- server mjukvara som funnits i över 10 år. Hudson som senare blev Jenkins har en stor marknadsandel och nämns även den i litteraturen. TeamCity nämns inte så ofta i litteratur, däremot visar marknadsundersökningen att även den har en stor marknadsandel. Vi kan dra slutsatsen att Jenkins används mest, tätt följd av TeamCity men att även andra CI-server mjukvaror så som CruiseControl nämns i litteraturen och säkerligen används än idag.

Delfråga 2 “Vilka för- och nackdelar finns det för ett CI-system?” besvaras av marknadsundersökningen och diskuteras även i avsnitt 2.4. Med hjälp av denna fråga vill vi ta reda på vad som utmärker vissa CI-system från andra och vad det är som gör att en grupp utvecklare väljer att använda ett CI-system över ett annat. Vi tittar också på eventuella nackdelar som utvecklare tycker att deras CI-system har. Svarsobjekten för marknadsundersökningen har angivit att de främsta fördelarna med deras CI-system är att det är lättanvänt, stabilt och tillförlitligt.

När svarsobjekten tillfrågades om nackdelar med deras CI-system var det en signifikant andel som inte kunde identifiera någon betydlig nackdel. Om vi däremot tittar på de svarsobjekt som identifierade nackdelar med sitt CI-system nämnde de svårigheter med att felsöka, en hög kostnad (av att sätta upp och underhålla systemet) och instabilitet. Andra nackdelar specificerades också men dessa nämns ej här.

Delfråga 3 “Hur pass utbredd är användningen av CI-system bland utvecklare inom företag

som använder sig av dessa system?” besvaras av marknadsundersökningen (se analys av

fråga 4). 41% av svarsobjekten svarade att 100% av deras utvecklare använder sig av CI- systemet och övriga svarsobjekt anger att ca 60-100% av utvecklare på företaget påverkas av CI-systemet. Endast tre svarsobjekt utav 39 svarade att CI-systemet endast påverkar 10%, 30% resp. 50% av deras verksamhet, där de resterande angav en större andel utvecklare

Sida | 58 som påverkas av CI-systemet. Vi kan därför konstatera att nästintill 100% av utvecklare på företagen påverkas av CI-systemet där ett sådant är implementerat.

Delfråga 4 “Leder CI-system till en mer effektiv utvecklingsprocess för mjukvaruutvecklare?” besvaras av marknadsundersökningen (se analys av fråga 10). 97% av svarsobjekten har svarat att deras CI-system leder till att deras verksamhet kan prestera bättre. Att en tillämpning och användning av CI-system har övervägande fördelar jämfört med dess nackdelar nämns även i litteraturen. Därmed kan vi dra slutsatsen att ett CI-system leder till en mer effektiv utvecklingsprocess för mjukvaruutvecklare.

Sida | 59

6. Diskussion

I detta avsnitt vill vi diskutera sådant som tidigare nämnts i rapporten. Vi börjar med att diskutera krav som CI-system bör uppfylla enligt våra undersökningar i avsnitt 6.1 och huruvida vår uppfattning om vilka krav som var viktiga stämde under tidiga skeden av examensarbetet. I avsnitt 6.2 redovisar vi smärre fel och misstag som gjordes under examensarbetets gång men även alternativa tillvägagångssätt och förbättringsförslag, med andra ord utföranden av moment som hade kunnat göras på ett annat sätt. Slutligen kommer vi i avsnitt 6.3 att spåna på framtida forskningsförslag och försöka klargöra hur man kan gå vidare med de resultat som vi kommit fram till i vår studie.

6.1 Diskussion av kraven

Vi kan från både litteratur- och marknadsundersökningen komma underfund med att CI- system består av betydligt fler funktionella krav än vad vi hade förväntat oss (grönmarkerade) under tidiga skeden av examensarbetet. Av dessa undersökningar framgår det att följande funktionella krav är betydelsefulla:

● Källkodshantering (eng. source code management) ● Kompilering av källkod (eng. build/compile source code) ● Exekvering av byggskript (eng. running arbitrary build scripts) ● Körning av tester (eng. run tests)

● Notifiering av status för bygge (eng. feedback/notification of build status) ● Stöd för distribution av mjukvara (eng. support deployment of stable software) ● Möjliggörandet av byggautomatisering (eng. enable build automation)

○ Förse utvecklarna med en infrastruktur som möjliggör upprepbara byggen (eng. provide infrastructure for repeatable builds)

● Hantering av byggartefakter (eng. internal handling of build artifacts)

Vi kan dock se att de funktionella krav som vi utgick från fick högt utslag i undersökningarna. Vi förutsåg inte att övriga funktionella krav som listas ovan (ej grönmarkerade) även är av betydelse.

Den största överraskningen för oss var beträffande icke-funktionella krav där vi förväntade oss att “performance” (grönmarkerat) skulle få högst utslag. Visserligen påvisar båda undersökningarna att “performance” är ett eftersträvat icke-funktionellt krav för CI-system, däremot visade sig att det fanns andra minst lika betydelsefulla icke-funktionella krav (ej grönmarkerade) som både litteraturen och slutanvändare av CI-system påpekade. Samtliga icke-funktionella krav som är av intresse listas nedan:

● Prestanda (eng. performance) ● Användbarhet (eng. usability) ● Flyttbarhet (eng. portability)

● Interoperabilitet (eng. interoperability) ● Utbyggbarhet (eng. extensibility) ● Stabilitet (eng. stability)

● Tillförlitlighet (eng. reliability)

Sida | 60 Varför stämde då vår tidigare uppfattning om vilka krav som ett CI-system måste uppfylla inte helt överens med den slutsats som vi kom fram till efter undersökningarna? Troligtvis beror det på ett flertal olika anledningar. Under förstudien hade vi inte all information till vårt förfogande och vi hade därför en väldigt vag idé om hur CI-system används och vad de