Mjukvarutestning, problem och utmaningar

Transkript

1 Institutionen för informatik Examensarbete i Informatik Kandidatuppsats, 15hp Systemvetarprogrammet, inriktning affärs och verksamhetsutveckling Mjukvarutestning, problem och utmaningar En undersökning på en testavdelningen i en agil miljö Författare: Mimoza Hasanaj Författare: Sebastian Ljung Handledare: Peter Adiels Termin: VT2016 Kurskod: 2IK10E

2 Sammanfattning/abstrakt För att ett företag skall få en smidig arbetsmetod samt för att upptäcka eventuella flaskhalsar i de dagliga rutinerna, är det inte ovanligt att externa resurser hyrs in för att undersöka företaget. Vad som upplevs vara naturligt för en avdelnings personal kan ofta lättare observeras av en utomstående. Syftet med denna studie är att undersöka vilka utmaningar och eventuella problem som presenterar sig på ett utvalt företags mjukvarutest avdelning. Datainsamling har utförts genom dokumentstudier och intervjuer med testpersonalen. Teorier inom metodiker samt mjukvarutestning har skapat det teoretiska ramverk. I och med detta har författarna av uppsatsen skapat sig en bild av hur verklighet ser ut, som sedan ligger till grund för diskussioner samt slutsatser. Undersökningen visar ett antal utmaningar för testpersonalen. I dagsläget råder det en viss kommunikationssvårighet mellan testpersonal, utvecklare samt kunder. Problemet härstammar i otillräckligt ifyllda specifikationer vilket skapar problem för testare att återskapa buggar/fel. Även det faktum att samma arbetsmetodik inte används över de olika avdelningarna skapar en brist på förståelse mellan personal. Underbemanning bland testpersonalen ligger även till grund för problem gällande kompetens allokering samt tidsbrister. Likaså ligger ett komplext system med äldre kod till grund för utmaningar då en stor förståelse för systemet krävs för att lösningar i en del inte ska skapa problem i en annan del. 1

3 Summary/abstract If a company wants to have a neat working method and identify any bottlenecks in their daily routine, it is not uncommon to hire external resources for an investigation of the company. Furthermore what might feel natural for staff members of the company can often be seen or even observed easier by someone external (not related to the comapny). The purpose of this study is to examine the challenges and potential problems that present themselves in a specific enterprise software testing department. The gathering of data collection has been executed through document studies and interviews with teststaff. Theories within metholodgy and software testing has created the theoretical framework. With this, the authors of the paper created a picture of how the reality looks like, which then later formed the basis of discussions and conclusions. The analysis show a number of challenges to the teststaff. In their current situation there is some communication difficulties between the teststaff, developers and customers. The problem originates in inadequately completed specifications, which creates problems for testers when reproducing bugs/errors in the system. The fact that the same methodology is not used across the different departmenst creates a lack of understanding among the staff. Furthermore being understaffed when it comes to the test department are also the basis for problems regarding competence allocation and deadline flaws. Likewise there is a complex software system with an old code which base challenges for understanding of the system. It requires great knowledge so that the solution in one part would not harm or create problems in another part. 2

4 Förord Det har varit intressant att fördjupa sig i en verklig testavdelning och se de utmaningar som de idag har. Att få skapa sig en verklighetsuppfattning av den verkliga världen och inte enbart läsa kurslitteratur har varit lärorikt och spännande. Vi vill tacka företaget och de involverade respondenterna som tagit sig tiden att medverka i denna undersökning och därmed gjort detta arbete möjligt. Vi vill även tacka vår handlare Peter Adiels som varit ett stöd och hjälpt oss under arbetets gång. Mimoza Hasanaj & Sebastian Ljung 3

5 Innehåll 1 Introduktion Inledning/bakgrund Tidigare forskning Problemformulering Syfte och frågeställning/hypotes Avgränsning/Begränsning Målgrupp Disposition 10 2 Bakgrund/Teori Vattenfallsmetoden Agil systemutveckling Scrum Kanban Mjukvarutestning Manuella tester Regressiontester Funktionstest Acceptanstest Automatiska tester Test av automatisering i samband med förvaltning 16 3 Metod Vetenskaplig ansats Datainsamling Intervjuer Dokumentstudier Urval Genomförande Analys Tillförlitlighet Etiska överväganden 22 4 Resultat och analys 23 5 Diskussion Resultatdiskussion Metodreflektion 29 4

6 6 Avslutning Slutsats Förslag till fortsatt forskning 30 Referenser 31 Bilagor Bilaga 1 Intervjuunderlag Bilaga 2 Uppföljningsfrågor I Bilaga 3 Uppföljningsfrågor II 5

7 1 Introduktion I detta kapitlet sker en genomgång av uppsatsens inledning/bakgrund, tidigare forskning, problemformulering, syfte/forskningsfrågor, avgränsningar samt arbetets disposition. 1.1 Inledning/bakgrund Det område som uppsatsen kommer att utforska är vilka problem och utmaningar som finns i en specifik avdelning på ett företag som arbetar i en agil miljö. I det här fallet kommer studien att utföras på en testavdelning på ett företag som studenterna kom i kontakt med. Våra IT system står under ständig utveckling och interagerar med varandra på ett svåröverskådligt sätt förklarar Biniazan & Bjermert (2014). Det handlar om att leda självorganiserade testteam i en komplex miljö. Testarbetet blir allt mer utmanande och en effekt av detta är att testmetoderna och testtekniker utvecklas hela tiden. Författarna av artikeln (Biniazan & Bjermert, 2014) menar att vår förmåga att leda testarbetet inte har utvecklats i samma takt. Vilket leder till att vi med traditionell testledning saknar metoder att leda effektivt i vår komplexa verklighet. Valet av arbetsmetodik kan påverka ett företag påtagligt och komma med egna lösningar och/eller problem beroende på hur det implementeras inom företag. Cohn (2010) berättar hur Salesforce.com som övergick till Scrum under sitt första år släppte 94 % fler funktioner, levererade 500% mer värde till sina kunder och ökade leveransen av funktioner per utvecklare med 38%. Detta i jämförelse med föregående år. Cohn (2010) fortsätter förklara att Salesforce.com under sina följande två år ökade sina inkomster med mer än det dubbla till ett värde av mer än 1 miljard US dollar. Författaren visar här tydligt vikten och inverkan av rätt val av metodik kan ha på ett företag. Problem och utmaningar som ett företag är blinda för kan ofta ses enklare med externa resurser som då kan komma med förslag över olika lösningar. Lösningar kan, som i fallet med Salesforce.com, vara att helt enkelt övergå till en ny metodik som inte tidigare används. Kyletoft (2011) hävdar att det inte räcker att endast tillämpa nya tekniker eller verktyg. För att producera bättre kvalitet eller prestera på en högre nivå behöver vi även ändra hur teamen samarbetar samt hur vi organiserar arbetet. Därtill nämner Kyletoft (2011) att som testare i ett agilt team så finns ett antal utmaningar att möta för att få teamet att bli så agilt som möjligt, och skapa ett effektivt och kvalitativt arbetssätt. Utmaningarna är att allt inte finns dokumenterat när test sätts igång. Det kan upplevas som att det inte finns tid för tester och att mängden regressionstester växer kraftigt med varje iteration, samtidigt som du kanske känner dig hotad i din profession. Det kanske 6

8 känns som att ditt jobb ändras totalt i form eller till och med att du blir överflödig (Kyletoft, 2011). Efter det att vi genomfört vår praktik som mjukvarutestare under höstterminen 15 väcktes ett brinnande intresse för testområdet. Därför var vi båda intresserade av att fördjupa oss inom detta område. Efter diskussioner med varandra, handledare samt med det företag som uppsatsen skrevs hos ledde detta till att forskningsfrågan avgränsades till en testavdelningen istället för hela företaget. 1.2 Tidigare forskning Att övergå från en utvecklingsmetod till en annan har blivit en allmän rutin för många företag. Trots detta menar Nikitina, Kajko Mattsson och Stråle (2012) att det skrivs få rapporter som beskriver övergångsprocessen. Avhandlingen From scrum to scrumban: a case study of a process transition rapporterar om en övergångsprocess från Scrum till Scrumban. Vilket är en kombination av Scrum och Kanban, i ett mjukvaruföretag. Författarna granskar processen av övergången, ändringar som skapats under utvecklingsprocessen och den genomgående övergången samt de förbättringar som uppnåtts. Slutsatsen som författarna drog med studien är två huvudsakliga grunder för att lösa en processrelaterad och/eller organisatoriska problem är 1) inrätta mekanismer för kontinuerlig process förbättringar, och 2) att ha välutbildade och engagerade personal. Enbart de två punkterna kan göra stora förbättringar i processen och ge långvariga och hållbara resultat, med eller utan övergång till och/eller anta nya metoder. För närvarande är det många organisationer som övergår från den traditionella synen på agila strategier när det gäller system utvecklingsmetoder. Det är uppenbart att undersökningar främst har fokuserats på mindre organisations övergångar, medan mindre fokus har getts till större organisationer. Författarna Backlund, J. & Eriksson, J. (2013) syfte med denna studie är att få en djupare och bredare kunskap om följande forskningsfråga: Hur påverkar ett byte från traditionella systemutvecklingsmetoder till Scrum utvecklingsarbetet i stora globala organisationer? Hur kan Scrum anpassas till komplexa projekt med intern beställare? Ytterligare undersöks hur Scrum kan anpassas till komplexa projekt med en intern klient. Studien är baserad på en fallstudie, som tar en kvalitativ metod med semistrukturerade intervjuer för informationsinsamling som genomfördes på ett stort svenskt telekomföretag. Företaget inledde övergångsprocessen för ungefär två år sedan, med en övergång som fortfarande är pågående. Studien tyder på att den främsta orsaken till att anta ett flexibelt arbetssätt är för att optimera utvecklingsprocessen genom ökad effektivitet. Till följd av ändringen har ytterligare effekter erhållits, exempelvis en högre grad av laganda och en mer 7

9 transparent utvecklingsprocess. Slutligen visade studien att även om en organisation väljer att omfamna agila metoder, kan det praktiska sammanhanget i vilket det införs leda till att det är anpassat till den punkt där det avviker från dess mest centrala teoretiska underbyggnad. Företagets tekniska personal innehåller ett team av utvecklare i Sverige och ett annat i Vietnam. Varje lag består av 15 till 20 ingenjörer. I dokumentet hänvisar författarna av forskningen till dessa grupper som svenska utvecklingsteam, vietnamesiskt utvecklingsteam och vietnamesiska test team. Den vietnamesiska test teamet stöder både utvecklingsteamen med provning. I början av 2010, följde både utvecklingskontoren Scrum svagt. Det svenska utvecklingsteamet upplevde många processrelaterade problem och låg utvecklings motivation. Av denna anledning övergick det svenska utvecklingsteamet från Scrum till Scrumban i mars Detta innebär att Kanbans kontinuerliga utvecklingsflöde genomfördes. Dock kvarhöll organistationen några av Scrums element såsom dagliga möten, demos, planering, release och retrospektiv. Följande processrelaterade problem identifierar (Nikitina et al. 2012) under första övergångsfasen: Problem 1: Brist på kommunikation mönster: Även om företaget hade globalt distribuerad utveckling och testning lag, har de inte följt något kommunikationsmönster. Kommunikation inom varje utveckling och test team var bra. Men kommunikationen mellan lagen och produktägare var begränsad. De kommunicerade via e post, och sällan via konferenssamtal. Problem 2: Ingen samordning av arbetet: Svenska utvecklingsteamet följde Scrumban som drevs av ett kontinuerligt flöde, och den vietnamesiska utvecklingsteamet använde fortfarande Scrum som drevs av iterationer. Detta hade skapat utmaningar för Vietnamesiskt testteamet. De var tvungna att följa två olika processer: (1) Scrumban när de samarbetar med det svenska teamet och (2) Scrum när de samarbetar med det vietnamesiska teamet. Problem 3: Brist på definitionen av "klar": Definitionen av när en användares berättelse ansågs färdig "gjord" i agile språkbruk var inte tillräckligt klart för alla berörda parter. Problem 4: Prioritering av kortsiktiga lösningar: Hög vikt av att leverera alla de planerade funktioner genom sprint deadline gjorde att de vietnamesiska utvecklarna fokuserade på leverans av kortsiktiga mål samt planer och försummade de långsiktiga strategerna. Problem 5: Brist på process kunskap och engagemang: De vietnamesiska utvecklare och testare har inte genomgått någon utbildning i Agila metoder (Nikitina et al. 2012) 8

10 1.3 Problemformulering Med vår studie hoppas vi kunna bidra med en undersökning som fördjupar sig i de problem och utmaningar som en avdelning kan ha i en agil miljö. Eftersom mjukvarubranschen är ett väldigt konkurrenskraftig område är det av stor vikt att ett företags avdelningar opererar på en optimal nivå. Detta för att säkerställa att planeringar och leveranser inte fallerar. Genom att undersöka vilka utmaningar och nuvarande problem som ett företag har, kan anpassningar och planeringar bättre utförmas och därmed skapa en konkurrensfördel. Denna konkurrensfördel kan användas för att inte bara säkerställa att gamla kunder stannar inom företaget med även för att införskaffa nya kontakter samt kunder. Arbetsmetoder skiljer sig åt och används på olika sätt. Det är inte heller nödvändigt att endast använda en metodik utan ett företag kan använda delar från olika metodiker för att få ett arbetssätt som funkar just för ett företaget. Men ifall detta är lämpligt eller endast ställer till problem är något som kommer att beaktas tillammas med resterande punkter som kommer att presentera sig under arbetets gång. Det är inte alltid säkert att ett företag kan se med egna ögon ifall nuvarande arbetssätt är lämplig. Därmed kan det vara bra att som en extern resurs se med färska ögon på hur nuläget ser ut och hur detta kan förbättras. Vi har kommit i kontakt med ett företag som skall studeras för hjälpa effektivisera deras testavdelning, och därmed hjälpa i eventuella förändringar i nuläget. 1.4 Syfte och frågeställning/hypotes Syftet med studien är att undersöka och beskriva vilka problem och utmaningar som finns i nuläget i en specifik testavdelning hos ett företag som arbetar i en agil miljö. Följande frågeställningar kommer att besvaras för att uppnå ovanstående syfte: Vilka problem och utmaningar finns i nuläget i en specifik testavdelning hos ett företag som arbetar i en agil miljö. Resultatet av undersökningen har till avsikt att i ett beskrivande dokument förmedla de problem och utmaningar som finns i en specifik testavdelning. 9

11 1.5 Avgränsning/Begränsning Uppsatsen kommer att begränsa sig till endast testavdelningen och utmaningar i deras rutiner. Undersökningen kommer därmed inte att granska resterande avdelningar i företaget. Då detta var önskemålet från det företag som studenterna har varit i kontakt med och skriver sin uppsats hos. En annan faktor är även att då en undersökning över samtliga avdelningar i företaget skulle resultera i en tidplan som vore orimlig att hålla. 1.6 Målgrupp Då studien har utförts på ett verkligt företag riktar sig resultatet sig främst till det företag och personal som studenterna har utfört sitt arbete hos. Förutom dessa har även uppsatsen en generell målgrupp så som projektledare, testledare samt övriga testare. Personer inom dessa yrkesroller kan använda sig av materialet för att skapa sig en bättre förståelse samt planering inför framtida testperioder. Likaså riktar sig även uppsatsen till lärare och studenter som undervisar/studerar vid relevanta utbildningar och som är intresserade av området testprojektledning. 1.7 Disposition Följande är en beskrivning över examensarbetets kapitel samt innehåll. Introduktion Inledande kapitel med kortfattande förklaringar över uppsatsens innehåll samt målgrupp. Bakrund/Teori Litteratur samt artiklar presenteras som i sin tur används för att skapa en bättre förståelse för läsaren inom det område som kommer att undersökas i de kommande kapitel. Metod Metodavsnittet presenterar den vetenskapliga ansatsen. Kapitlet beskriver även datainsamlingstekniker som använts samt urval och förklaring av genomförandet vid arbetet med datainsamlingen. Kapitlet fortsätter med en förklaring över de tekniker som använts för analysering. Slutligen avslutas kapitlet med diskussion över reliabilitet och validitet samt etiska överväganden. Resultat och analys Det empiriska materialet sammanställs och presenteras tillsammans med resultatet av de analyser som utförts över det material som insamlats. 10

12 Diskussion Kapitlet diskuterar från författarnas synpunkt genomförandet och det resultat som uppsatsen kom fram till. Avslutning Avslutningsvis presenteras slutsatser och förslag till fortsatt forskning. 2 Begrepp och teori I följande kapital är intentionen att lyfta fram de olika begrepp och teorier som samlats in via artiklar från forskningsdatabaser samt litteratur. Kapitlet är indelat i två delar. Inledningsvis behandlas olika metoder inom systemutveckling såsom scrum, vattenfallsmetoden och kanban. Därefter fortsätter kapitlet med att beskriva vad testning inom mjukvaruutveckling innebär samt en genomgång av de vanligaste teknikerna. Att välja en metod innebär att bestämma hur resultatet ska tas fram. Det är ett strategiskt beslut som bland annat bestämmer vilken typ av resurser som behövs och när det behövs. Innehållet och metoden är beroende av varandra (Tonnquist 2014, 82). Beroende på vilken systemutvecklingsmetod som används blir testfasen annorlunda eftersom metoderna skiljer sig från varandra. Planeringen som sker inom de olika metoderna skiljer sig. De beskrivna systemutvecklingsmetoderna är metoder som företaget använder sig av: 2.1 Vattenfallsmetoden Modell där produkten tas fram i successiva seriella steg (Tonnquist 20014, 459). Vattenfallsmetoden går ut på att ett specifikt steg i utvecklingen skall avslutas innan nästa steg påbörjas. Från första början kan man planera alla steg i utvecklingen och på så viss är det möjligt att förutsäga vad som skall hända i framtiden (Beynon Davies 2009). En av de mest kända varianterna av sekventiell utveckling är vattenfallsmodellen. Sekventiell utveckling innebär att hela systemet utvecklas i en enda sekvens till skillnad mot metoder där systemet utvecklas och leveraras bit för bit (Eriksson 2008). Modellen består av ett antal faser där utvecklingen likt vattnet i ett vattenfall rinner ner från en fas till nästa, därav modellens namn. Eriksson (2008) nämner att vattenfallsmetoden består ofta av faserna analys, design, konstruktion och slutligen test. Grundtanken är att det som produceras i varje fas ska vara så bra att man inte behöver backa i trappan. Detta eftersom att man strävar efter perfekta krav innan man går vidare till design som måste vara perfekt innan man gör den slutliga konstruktionen. Vidare nämner Eriksson (2008) för att kunna uppnå detta används ofta dokumentgranskning. Eftersom det inte finns några perfekta krav i verkligheten, är det 11

13 inte realistsikt att sträva efter detta. Ju mer tid man lägger på att skriva perfekta krav, desto längre tid tar det och då ökar risken att verkligheten hinner ändras vilket resulterar i att systemet inte lever upp till beställarens förväntningar (Eriksson 2008). Då test kommer in i slutet av vattenfallsmetoden är risken stor att man upptäcker allvarliga brister alltför sent vilket resulterar i att det inte går att åtgärda dem. Fel kommer också att upptäckas under själva konstruktionen då programkoden skrivs. Det får givetvis backa till analysfasen, med det kostar väldigt mycket pengar (Eriksson 2008). 2.2 Agil systemutveckling Arbetsmetod där man delar in projektet i tidbestämda sprintar (Tonnquist 2014, 442). En mer flexibel arbetsmetod. Denna typ av arbetsmetod passar när man exempelvis önskar snabbt användbart resultat berättar Tonnquist (2014). När det är svårt att få fram en vision på hur slutprodukten kommer att se ut samt när kraven är otydliga. En växlande situation och därav anses denna metod vara mer flexibel. Alla skall jobba heltid med projektet och det sker på samma plats. Dock lämpar det mindre bra om projektet har många externa beroenden. Att ett fast kontrakt förekommer och en bestämd deadline. Om målbilden och kraven är tydliga fungerar agila arbetsmetoder även mindre bra. Men många gånger rekommenderas en kombination. Vilket kan skapa en övergripande struktur under hela projektet. Dessutom flexibiliteten att kunna agera snabbt vid förändringar under den verkställande fasen. Tonnquist (2014) säger att val av metod inte påverkar förstudien särskilt men att delar av planeringen och i synnerhet genomförandet kommer att få annorlunda resultat. Projekt kan specificeras och realiseras stegvis, etapper. Där man bryter ner det man ska göra i krav och delmål, en bit i taget. I taket specificeras då kraven med att kunskapen och erfarenheten hämtas in. I korta drag är detta grundprincipen för agila projektmetoder. De uppdrag som baseras på kreativa processer, därav uppskattas flexibiliteten inom denna metod då det finns plats för förändringar. Dock lämpar sig det även i systemutvecklingsprojekt nämner Tonnquist (2014), som menar att det handlar om att få ett tillfälle att undersöka ett specifikt område. För att vidare kunna framföra nåt nytt och samla erfarenhet. Ingen vet i förväg vad man kommer komma fram till. Det förekommer oftast en komplex kravbild i systemutvecklingsprojekt som enbart kan vara beskriven på funktionsnivå. För att kunna ta fram de tekniska kraven måste man komma igång med projektet och därför kanske inte den bilden som målades upp i inledningen matchar verkligheten (Tonnquist 2014). 12

14 2.2.1 Scrum Scrum går ut på en agil arbetsmetod där man delar in projektet i tidsbestämda sprintar (Tonnquist, 2014). Eriksson (2008) framför ett exempel att de nyare utvecklingsmetoderna bygger på synsättet att det är bättre att stycka upp elefanten i många delar och att äta en bit i taget iterativ utveckling. Medan de sekventiella (vattenfallsmetoden) försöker man bygga ett komplett system på en gång. Liknande process som att försöka äta en hel elefant på en måltid (Eriksson 2008). Som tidigare nämnt bygger man en liten bit av systemet först inom iterativ utveckling och sedan förfinar den därefter i ett antal utvecklingsetapper (Eriksson 2008). Här byggs till skillnad från sekventiell utveckling några grundläggande funktioner inom ordermodulen, några inom lagermodulen och några inom faktureringsmodulen. Vid nästa iteration utökas detta system med ytterligare funktioner och förfinar de som tagits fram i tidigare etapp (Eriksson 2008). På så viss menar Eriksson (2008) att det sker en snabbare återkoppling från användarna så att systemet passar bättre till organisationens krav. Kraven hinner heller inte ändras så mycket som de gör när systemet utvecklas enligt vattenfallsmetoden (Eriksson, 2008). Denna sortens metod används främst inom mjukvaru och systemutvecklingsprojekt. Sprintarna, som är delar av processen är vanligtvis två till fyra veckor långa. Scrum bryter ner krav till delmål (och korta aktiviteter) detta samlas sedan i en produktlogg (Tonnquist 2014). Följaktligen delas loggen i mindre delar, en för varje sprint. Där sker också en prioritering av vad som ska göras först i varje sprint, detta mellan projektägaren och teamet som gemensamt fattar beslut. Idén med en sprint är att den ska leverera ett komplett användbart resultat. Först leds arbetet av en scrum master, vars främsta uppgift är att agera som coach för teamet i projektet. Precis som delarna i processerna (etapperna) delas, fungerar också teamet som bäst i mindre grupper, av fem till sju deltagare (Tonnquist 2014). Tidestimeringen i scrum är överordnat, hur mycket man hinner med under en sprint och liknande. Därtill kommer dagliga bedömningar om värdet av arbetet som är utfört samt hur mycket som är kvar. Det sker en justering efter varje sprint (Tonnquist 2014). 13

15 2.2.2 Kanban Kanban är baserad på Just In Time (JIT) och Lean production systemet vilket är en ny metod som får allt mer uppskattning. Den är mindre normativ i jämförelse med Scrum anser Nikitina et al. (2012). Därtill omfattar inte kanban utvecklings iterationer såsom sprintar, inga definerade roller som Scrum Master, inte heller några dagliga möten daily standups, retroperspektiv och slutligen innehåller den inte process artefakter, backlogs. Med Kanbans schemaläggning använder operatörerna visuella signaler för att avgöra hur mycket de kör samt när de slutar eller när en övergång sker. Reglerna i denna metod innebär att operatörerna får reda på när de stöter på problem och hur de skall gå tillväga när det uppstår. Kanbans schemaläggning definieras som efterfråga schemaläggning av författarna Gross, John M., McInnis, Kenneth R. (2003). Kanbans schemaläggning ersätter den traditionella eller dagliga sådan. Det fungerar som ett exekveringsverktyg snarare än ett planeringsverktyg. Kanban, som kan ta många former, styr driften av processen på en dag till dag basis. Kanban ersätter: Den dagliga schemaläggningsaktiviteterna som krävs för att driva produktionsprocessen Behovet av produktionsplanerare och chefer för att kontinuerligt övervaka status på schemaläggare för att bestämma när nästa punkt ska köras och när det skall alterneras 2.3 Mjukvarutestning För att försäkra kvaliteten används olika sorters tester för olika delar av ett system. Nedan redogörs de vanligaste testteknikerna kortfattat. Dessa beskrivs för att de kan användas inom testautmatisering samt att de har kopplingar till företaget (Eriksson 2008). Vad är test? Varför ska man testa? När? Hur? Vem? Vilka? Eriksson (2008) förklarar också att det behövs ett tydligt mål för testarbetet. Det är först när ett mål finns som det är möjligt att bestämma riktning. I sin tur styr målet faktorer såsom verktyg och utrustning som behövs samt hur fort processen skall gå. Att klarlägga testernas mål är en oerhört viktig del av arbetet. Här skall följande delar redogöras: Hur mycket skall testas? Hur lång tid får det ta? Vad förväntas testarbetet leda fram till? Vilka risker finns och hur ska de hanteras om de inträffar? 14

16 När svaren på dessa frågor är besvarade kan en riktning väljas, upplägg av testarbetet. Allt skall skrivas ner i en testplan således blir detta strategin. Detta är ett sätt att hjälpa uppnå målen. Vid osäkerhet under arbetets gång kan personal med hjälp av strategin få vägledningen med sitt arbete. Givetvis finns det undantag och avvikelser under testarbetet, det är dock viktigt att tidigt ha lagt upp en plan och sedan formulera om den vid avvikelser (Eriksson 2008). Arbetet inom test har utvecklats mycket berättar Eriksson (2008). Det är inte längre enbart en utvecklare som skriver ett program i ett programmeringsspråk för diverse plattformar, förklarar Eriksson (2008). Då var det mer begränsat, allt från användare till utvecklare. Innan visste man vem/vilka som skulle använda systemet och därför var kunskaperna mer omfattande verksamhet och system. Idag talar vi om mer komplexa system vars utveckling innebär högre krav på utvecklarna. Allt fler företag integrerar med system, som fungerar som en kedja, en mycket lång sådan som innehåller ett antal länkar. Därför skall strategierna vara effektiva för att få samordningen att operera. För att säkerställa den höga kvaliteten på ett strukturerat och effektivt sätt träder test fram (Eriksson 2008) Manuella tester Saha (2008) beskriver manuell testning som processen att manuellt testa mjukvara, utförd av en eller flera individer. Testning på denna nivå kan exempelvis vara över användargränssnitt, databas säkerhet eller mjukvaru säkerhet. Till skillnad från automatisk testning menar Saha (2008) att manuell testning är långsamt och arbetsintensivt. Denna testmetod utförs trots allt personligen av testpersonalen som måste klicka sig runt i systemet Regressiontest Test som utförs vid varje leverans av systemet för att upptäcka följdfel som tillkommit vid rättning av fel (Eriksson 2008). En process för mjukvarutestning genom att upprepa test och ta reda på om den nya modifikationen har lett till några fel. Då ändringar och uppdateringar i redan fungerande mjukvara kan påverka funktionaliteten negativt. (Ammann & Offutt 2008) Funktionstest Syftet är att testa processer och sammanhängande flöden. Allt för att säkerställa att komponenterna i systemet kommunicerar med varandra på ett korrekt sätt. Denna typ av test utförs oftast när det är ett nytt system. Noggrannheten vid funktionstest tas på stort allvar då man går igenom punkt för punkt för att inte missa något (Eriksson 2008). 15

17 2.3.4 Acceptanstest Utförs av användarna eller av representanter för användarna. Syftet med testerna i denna fasen är att utvärdera om systemet är byggt enligt de krav som ställts. En kombination av testfall och ad hoc tester används till grund för testerna (Eriksson 2008). Ad hoc test, utförs utan testfall eller andra skriftliga instruktioner Automatiska tester Automatiserad testning är en av de mest effektiva metoder som om de utförs på rätt sätt kan de bidra till att öka effektiviteten och i slutänden minska testkostnaden. Samtidigt bidra till ökad system och programvara kvalitet när det handlar om snabbare, bredare och effektivare att detektera fel. (Dustin et al. 2009). För testning av programvara är den främsta utmaningen idag att kunderna vill ha mer programvara funktionellt, billigare och snabbare leverans. På samma gång förväntar de sig att kvaliteten på programvaran ska uppfylla om inte överträffa förväntningarna (Dustin et al. 2009). Konsekvenserna för test teamet blir enormt. Fler funktioner innebär att baslinjen blir större och mer komplex att testa, vilket i sin tur innebär att fler testfall måste köras för varje leverans och fler leveranser kommer att beställas för varje år. Fler leveranser innebär också fler regressionstester. Att skära ner på kostnaderna innebär att testningen måste kompletteras på färre arbetstimmar (Dustin et al. 2009). 2.4 Test av automatisering i samband med förvaltning Ett bra tillfälle enligt Eriksson (2008) att automatisera tester är under systemets förvaltningsfas. Det innebär att man med hjälp av ett testverktyg skriver ett testprogram. Det programmet realiserar sedan ett antal teststeg, kontrollerar resultatet samt rapporterar det vidare. Eriksson (2008) förklarar att motivet till val av automatisering är för att kunna köra fler testfall på en kortare tid, på vissa testfall. Till synes är det billigare att utveckla automatiserade testfall under förvaltning än i jämförelse under nyutvecklingen. Under förvaltningen är systemet och kraven mer stabila, visionen mer tydlig därav blir det oftast billigare (Eriksson 2008). Likaså som automatisering har sina fördelar medför den även motsatsen. Testfall måste finnas om det inte gör så kostar det i sig tid Att köpa eller ta fram testverktyg kostar För användning av verktygen krävs utbildning Programmen som skrivs måste dokumenteras, testas och förvaltas precis som allt annat 16

18 Det är viktigt att beräkna hur stora tidsvinster som kan göras med hjälp av automatisering innan ett beslut fattas om det skall införas eller inte. För att göra en sådan beräkning delas testfall in, sådana som görs ofta och tvärtom de som utförs mindre. Detsamma gäller de testfall som tar längst att utföra och de som tar mindre tid (Eriksson 2008). 3 Metod I detta kapitel avsnitt presenteras vetenskaplig ansats och val av metod. Hur datainsamlingen och urvalet har gått tillväga i förhållande till undersökningens syfte och frågeställning. Därtill även tillförlitlighet och etiska överväganden förklaras. 3.1 Vetenskaplig ansats En induktiv ansats valdes för arbetet med uppsatsen. Syftet med studien är att undersöka och beskriva vilka problem och utmaningar som finns i nuläget i en specifik testavdelning hos ett företag vars miljö arbetar med agila metoder. Jacobsen (2002) beskriver en ideal induktiv ansats, en undersökning som utförs nästan helt utan förväntningar och förutfattade meningar. Jacobsen (2002) fortsätter förklara att undersökningen utförs genom att all relevant data samlas in och senare systematiseras (och reducera). Vilket innebär att en filtrering och förenkling av informationen genomförs (Jacobsen 2002). Detta görs för att få en överblick av innehållet. De tjocka beskrivningarna blir i sin helhet alltför omfattande och därmed ogenomträngliga för andra än oss själva menar Jacobsen (2002) som också anser att systematisering är nödvändigt för att vi ska kunna förmedla vad vi funnit. Då vi som skrev uppsatsen fortfarande är studenter hade vi inga fördomar eller förväntningar, helt enkelt eftersom vår egna erfarenhet var ytterst begränsad. Därav stämde en induktiv ansats mycket väl överens med hur vi planerade vår undersökning. Likaså bestod datainsamling av inget speciellt fokus utan efter diskussioner med personalen på företaget skapades en överenskommelse om vilka områden som data borde samlas in från. För datainsamling valdes en kvalitativ undersökningsmetod. Således med fokus på datainsamling för primärdata på gruppintervjuer, med öppna frågor för att skapa intressanta diskussioner. Därtill utfördes även en datainsamling över sekundärdata. Detta bestod av en dokumentstudie där medlemmar ur testpersonalen fick förklara processkartor och diverse dokument. Dessa dokument studerades mer och mer allt eftersom uppsatsen skrevs. 17

19 3.2 Datainsamling Med hjälp av intervjuer med utvalda personer i företaget som har erfarenhet av test och liknande, gjordes datainsamlingen. Syftet med intervjun var för att besvara bland annat frågeställningen samt ge en djupare förståelse kring utmaningarna förtaget i frågan handskas med. Denna typ av data hämtades in direkt från källorna och kommer att fungera som resultat till analysen Intervjuer Det utfördes en kort presentation av arbetet och syftet förutom detta så presenterade de sig själva kort för en bättre inblick av företaget och hur de arbetar. Intervjun tog plats i ett rum inom företaget, det kändes mest naturligt då det är ytterst viktigt att få till en bra trygghetskänsla. Jacobsen (2002) berättar att detta val är viktigt eftersom mycket forskning har visat att den miljö kontexten där intervjun försiggår regelbundet påverkar innehållet i intervjun, kallad kontexteffekten. Vidare nämner Jacobsen (2002) att det inte finns några neutrala kontexter. Alla påverkar intervjun i en eller annan form. Därmed är det omöjligt att säga att en kontext är bättre eller sämre än en annan. Jacobsen (2002) förklarar att en öppen gruppintervju är ett samtal i en grupp, alltså med flera gruppmedlemmar samtidigt. En grupp samtidigt i stället för varje individ för sig. Vidare nämner Jacobsen (2002) att undersökaren fungerar mer som debattledare eller ordförande än som ren intervjuare med frågor. Fortsättningsvis beskriver Jacobsen (2002) viktiga val man skall fatta innan detta beslut såsom att hur gruppen ska sättas samman, antalet, forskarens roll och om det ska ordnas ett eller flera möten med samma grupp. Frågorna till intervjun var öppna. Då det läggs få eller inga begränsningar på vad uppgiftslämnaren kan säga (Jacobsen 2002). Det resultat undersökaren får har formen av en mängd anteckningar och/eller bandupptagningar som därefter ska analyseras (Jacobsen 2002). Frågorna var förbestämda och utskickade några få dagar innan den faktiska intervjun, givetvis fanns det avvikningar såsom följdfrågor eller liknande som tillpassade stunden. Enligt Jacobsen (2002) är vanligtvis den öppna intervjun strukturerad till en viss grad, till exempel med hjälp av en lista över de ämnen som ska tas upp. Delvis har vi strukturerat intervjun dock med valet att kunna ställa frågorna på ett sätt där informatörerna kan/får vara öppna i sina svar samt utveckla. Slutligen skickades intervjufrågor via e mail enskilt till samtliga respondenter, vars struktur resulterade i direkta svar istället för diskussioner. 18

20 3.2.2 Dokumentstudier Dokumentundersökningar används som en sekundär datainsamlingsmetod (Jacobsen 2002). Syftet med dokumentstudien var att hjälpa oss skapa en uppfattning över företagets arbetsprocesser för att kunna använda denna information som grund vid senare intervjuer. När primärdata är omöjliga att hämta används dokumentundersökning enligt Jacobsen (2002). Detta skulle till exempel kunna användas om intervjuer eller observationer inte ger svar. Istället utförs en granskning av dokument genom publika handlingar, företagsårsredogörelse eller loggböcker till exempel användas (Jacobsen 2002). Förutom intervjuer utfördes även dokumentstudier där ett andra besök av företaget gjordes. Den här gången med avsikt att samla dokument och ytterligare information. Förutom ett genomdrag av hur de arbetar och med vilka typer av verktyg de använder sig av. Fick vi även ta del av en del processkartor och liknande som visade deras arbetsflöde. Vidare har inga observationer eller enkätundersökning gjorts. Av den anledningen att vi valde att arbeta utifrån ett kvalitativt perspektiv (se Vetenskaplig ansats). Främst ligger gruppintervjun som primärdata på vår datainsamling. Därtill en datainsamling för sekundärdata som bestod av en dokumentstudie. 3.3 Urval Denna rapport avser ett urval som enligt Jacobsen (2002) kallas information. Urvalet bygger på att vi har valt uppgiftslämnare till vår studie som vi anser kan ge oss en riklig och god information. Det kan även misstänkas för att göra ett strategiskt urval, det vill säga att vi välja ut de enheter som vi vet kommer att ge ett svar av en viss typ (Jacobsen 2002). Det kan ocskså enligt Jacobsen (2002) vara personer som besitter kunskap inom ämnet vi är intresserade av eller personer som är bra på att uttrycka sig och är villiga att lämna information till oss. Urvalet gjordes med avsikt för informationen som var värdefull och användbar för resultatet. Respondenterna var personer med en viss roll inom företaget, besatt en viss kompetens samt var öppna att ge svar på frågorna med bra insikt. En population är alltid avgränsad (Jacobsen 2002) det vill säga alla de undersökningsenheter vi önskar uttala oss om. Vidare nämner Jacobsen (2002) att en population kan vara mycket mindre, till exempel om vi vill undersöka arbetsmiljön på ett företag, där är populationen de som arbetar på företaget. Populationen från vår undersökning innefattar informatörer/respondenter från företaget som arbetar inom testavdelningen, där intervjuerna tog plats. Respondenterna som var involverade var tre stycken testare inom olika områden. 19

21 3.4 Genomförande Förfarandet av resultatets insamling har beskrivits under rubriken metod. Respondenterna kommer alla från det företag som uppsatsen använder sig av under undersökningen. Företaget hittades under en mässa som höll till på Linnéuniversitetet, i Växjö. Respondenterna besatt den kunskapen som var lämplig för arbetet. Efter en presentation av oss själva fick vi ett godkännande. Kort efter sammanställdes intervjufrågor som diskuterades med handledaren för att säkerställa att frågorna var relevanta och kunde uppnå det resultat som var önskat. Dessa skickades iväg innan intervjun tog plats (se Bilaga 1) för att respondenterna skulle få tid att förbereda sig. Intervjufrågorna baserades på frågeställningarna till uppsatsen för att säkerhetsställa att rätt information samlas in. Tiden på gruppintervjun varade cirka 90 min, där det bestod av tre anställda från företaget och oss två studenter. Enbart ett få tal noteringar gjordes av den orsaken att intervjun spelades in. Efter att den etappen var färdig verkställdes omskrivningen av inspelningen. Veckan därefter träffade vi personalen igen för ett möte angående dokumentstudien. Även detta möte spelades in för att säkerställa att informationen som delades med oss inte skulle glömmas bort. Därtill finnas ett underlag att arbete med under tiden framöver. Under detta möte som pågick under 60 minuter, gick personelen igenom olika processkartor samt förklarade olika verktyg och metoder de arbetade med. Dessa dokument skickades sedan till oss via e mail för senare studier. Avslutningsvis har vidare intervjufrågor skickats enskilt via e mail till samtliga respondenter. Detta för att säkerställa att svaren på frågorna skulle besvaras utan yttre påverkningar samt för att få mer information att bearbeta. 3.5 Analys Jacobsen (2002) beskriver analysprocessen med tre steg: Beskrivning, systematisering och kategorisering samt slutligen kombination. För arbetet med analys av det insamlade materialet har vi valt att följa dessa punkter. Beskrivning Jacobsen (2002) förklarar den inledande punkten beskrivning med att man bör utföra renskrivningar på det insamlade materialet. Detta följs av att skriva kommentarer för att skapa en djupare förståelse. Slutligen hävdar Jacobsen (2002) att man bör avsluta med att sammafatta intervjuer och observationer för att göra materialet mer överskådligt och lättillgängligt. Inledningsvis började vi med att transkribera alla inspelade intervjuerna till text. Detta för att säkerställa att vi inte gick miste om någon data samt för att underlätta arbetet med materialet. Detta följdes av att vi tillförde kommentarer för att senare enklare kategorisera datan samt för 20

22 att skapa en bättre förståelse. Avslutningsvis sammanfattade vi det inspelade materialet för att göra datan mer överskådlig Systematisering och kategorisering Jacobsen (2002) beskriver denna del med en inledningsvis systematisering och reducering av all den mängd data som insamlats. Detta för att man helt enkelt ska kunna enklare förmedla informationen till läsaren. Jacobsen (2002) fortsätter förklara denna del i analysen med att man samlar data till grupper. Genom att skapa kategorier skapar man en överblick över olika fenomen. Kategorisering underlättar att belysa att viss data behandlar samma ämne/fenomen, liknar varandra eller att datan skiljer sig från varandra. Vi valde att skapa olika kategorier som var relevanta för vår forskningsfråga och med tanke på att vi är avgränsade till en avdelning på ett företag. Genom att styckvist läsa våra tidigare transkriberade texter samt kommentarer, kunde vi därmed föra in texten under lämpliga kategorier. Under denna process utförde vi även den systematisering som Jacobsen tidigare nämnt. Kombination Sista punkten är kombination. Syftet med denna del i analysen är att börja tolka data vilket innebär att söka orsaker, försöka generalisera eller bringa viss ordning i datan (Jacobsen 2002). Det är också i denna fas som vi undersökare försöker se vad som har blivit sagt eller gjort (Jacobsen 2002). Med hänsyn till huvudfrågan eftersträvade vi att ta ut citat och liknande från informanterna för att styrka vår teori i arbetet. Jacobsen (2002) beskriver hur man kan planera, genomföra ett fåtal intervjuer eller observationer och analysera dem. För att sedan återgå till planeringen, förändra uppläggning, genomföra nya observationer eller intervjuer osv. Under arbetets gång har vi kontinuerligt valt att arbeta efter Jacobsens metod där intervjuer har utfört, bearbetats, planerat in fler intervjuer för att senare utföra dessa. Detta i samarbeta med vår handledare för verifiering av de frågor som skulle användas. 3.6 Tillförlitlighet När man samlar in data är det viktigt att sträva efter att datainsamlingen ska ha så hög tillförlitlighet (reliabilitet) som möjligt och så hög giltighet (validitet) som möjligt (Backman & Gardell 2012). Att datainsamlingen har hög giltighet berättar Backman, Y., Gardelli, T., Gardelli, V. & Persson, A. (2012) betyder att den verkligen mätt det man avsett att studera, att data faktiskt representerar det som undersökningen handlar om. Validitet För att säkerställa en god vetenskaplig kvalitet har vi varit noga med att se över den interna giltigheten vid validiteten. Jacobsen (2002) förklarar att ett vanligt och bra sätt att se över 21

23 intern giltighet är att be kolleger och/eller uppgiftslämnare att se över begrepp och frågor. Innan intervjufrågorna skickades till företagets personal så fick vår handledare först se över och tillsammans med oss diskutera dessa. Under handledningen diskuterade vi ifall där var några frågor som borde ändras samt ifall frågorna täckte området väl. Även vid intervjun på företaget hade vi en öppen diskussion med personalen över deras intryck och ifall där var några synpunkter på frågorna samt ifall de hade intrycket av att frågorna täckte området väl eller ifall där var mer som behövdes studeras. Svaren till intervjun transkriberades ner till ett dokument. Detta presenteras för att säkerställa för läsaren att resultatet har tolkats korrekt och på så sätt styrka trovärdigheten. Reliabilitet För att bedöma undersökningens tillförlitlighet, s.k. reliabilitet bör vi enligt Jacobsen (2002) ställ oss frågan om det är något hos själva undersökningen som har drivit det resultat vi kommit fram till. Som undersökare kan vi ha en effekt på fenomenet vi undersöker. Enklast kan detta beskrivas i samband med intervjuerna. Att det omedvetet skapas samtal under intervjuer d.v.s. hur det utformas och vad det innebär. Angivaren påverkas av intervjuaren, i utseende, klädsel, tal, kroppsspråk och så vidare (Jacobsen 2002). Dock har inte vi någon kontroll över hur motparten uppfattar oss som intervjuar. Av den orsaken i detta moment kan reliabiliteten ifrågasättas (Jacobsen 2002). 3.7 Etiska överväganden Jacobsen (2002) förklarar vikten av etiska överväganden med tre huvudpunkter. Att där är ett väl informerat samtycke. Det vill säga att personal skall frivilligt vara med i undersökningen och att syftet med undersökningen är klar. Rätten till privatliv skall respekteras och deltagare i undersökningen skall förstå att personlig information inte kommer att samlas in. Samt att insamlad information inte kommer att riskera deltagarens anonymitet. Slutligen tydliggör Jacobsen (2002) det tredje steget inom etiska överväganden med punkten gällande kravet att bli korrekt återgiven. Det är viktigt att insamlad data presenteras korrekt och inte blir på något sätt ändrad efter författarens åsikter eller andra faktorer. Innan studien påbörjades blev deltagarna väl informerade angående undersökningens syfte. Detta för att säkerställa egen vilja att medverka i arbete. Likaså för att där skulle vara en förståelse att information endast kommer att användas till en kandidatuppsats vid universitetet i Växjö. Båda studenterna blev tilldelade ett sekretessavtal som skrevs på innan studien påbörjades. 22

24 Både företaget samt dess personal önskade vara anonyma och är därmed något som har respekterats i denna avhandling. All personal som har varit med under intervjuerna nämns endast som respondent och endast med dessas godkännande har intervjuer spelats in. Likaså nämns företaget enbart som Företaget. 4 Resultat och analys Nedan presenteras kategorier för att enklare förmedla information till läsaren. De kategorier som utformades efter vår analys blev som följande: nuläge, önskningar, osäkerheter samt problem/utmaningar. Vi anser att dessa kategorier bäst lämpar sig för att beskriva hur nuläget ser ut i testavdelningen samt hur personalens erfarenheter och åsikter speglas i den insamlade datan. Vi anser även att dessa kategorier underlättar för läsaren att orientera sig i texten för att enklare skapa sig en bild över materialet. Resultatet av kategorierna är som följande. Nuläge Till största del arbetar testavdelningen efter scrum som kompletteras med Vattenfallmetoden eller Kanban beroende på olika faktorer så som ifall de arbetar med nyutveckling eller vem som utvecklar. Vi ser här att avdelningen inte följer endast en arbetsmetodik utan väljer att plocka ut vad de vill använda sig av ur olika metoder för att leda sitt arbete. Då mycket oplanerat kommer in vid sidan om den redan planerade agendan anses Scrum inte alltid vara den bästa metodiken för att hantera sådant som inte ingår i planeringen. Här anser respondenterna att Kanban mycket bättre lämpar sig för förvaltningsärenden, det vill säga rena fel. Detta då man kontinuerligt planerar om så att det som är högst prioriterat alltid får störst uppmärksamhet. Scrum anses bättre lämpa sig för arbete med nyutveckling där planeringen låses i fasta delmoment (sprintar) som sedan avslutas med en leverans till kund. Vattenfallsmetoden är den metodik som används främst vid systemtest. Här arbetar testavdelningen främst manuellt istället för ett kontinuerligt arbete genom automatisering. Vattenfallsmetoden kan ibland ses som en konsekvens istället för ett aktivt val av metod svarar en av respontenterna. Detta då tidpress eller brist av alternativ kan leda till att personal inte har tid att arbeta agilt. Arbetet kan istället likna vattenfallmetoden där uppgifter genomförs och avlöser varandra på ett strikt tillvägagångssätt. Detta är inget som eftersträvas utan mer en konsekvens. Önskningar Enbart testavdelningen arbetar i nuläget efter Scrum och detta är något som upplevs som störande. Detta eftersom det resulterar i en minskad förståelse mellan olika avdelningar då de använder sig av olika metodiker. Skulle hela verksamheten arbeta efter samma arbetsmetodik skulle detta resultera i arbetet blir optimalt berättar respontenten. Från testavdelningens sida 23

25 är detta något som hade önskats men som samtidigt kan vara svårt att implementera då de olika avdelningarna ställer olika krav beroende på deras egna behov. Slutligen är en ökad testpersonal ett stort önskemål från respondenterna. I dagsläget är de så pass underbemannade att alla tester de önskar utföra helt enkelt inte hinns med. Vi finner omkring en testare för varje tio utvecklare vilket personalen i testavdelningen önskar kommer att förbättras i framtiden. Genom en ökad mängd testpersonal skulle mer tid kunna läggas på automatiska tester nämner en av respondenterna. Störst nytta skulle här ligga i satsningar på automatiserade regressionstester som i nuläget till största del måste utföras manuellt. Osäkerheter Tidigare har dagliga statusmöten varit ett verktyg som använts men som togs bort då det upplevdes vara ett moment som störde mer än det hjälpte i det dagliga arbetet. Dock har nu avdelningen valt att återupprätta dessa dagliga möten. Detta då de anses trots allt vara viktiga då det ger en möjlighet att ni ett tidigt skede kunna informera beställaren angående den nuvarande situationen. Dagliga möten kan även främja en ökad kompetensöverföringen inom teamen. En av respondenterna väljer att påpeka hur bra det är med dessa möten just för hur det underlättar att koordinera sitt eget arbete med sina kolleger. Något som tidigare var ett störmoment ska nu få en ny chans. Något som kan eventuellt störa arbetet än en gång eller som kan öka produktionen genom att hjälpa leda testpersonalen samt skapa ett ökat informationsflöde. Detta är ett osäkert moment som antingen kan leda till att processen läggs ner ännu en gång eller att de denna gång behålls. Problem/Utmaningar Slutligen har vi en kategori med uppenbara problem och utmaningar som datainsamlingen resulterade i. Här presenterar vi olika punkter som avdelningen kan ta till sig i deras arbete med att effektivisera sitt företag. Från utvecklarnas sida önskar testavdelningen att kommunikationen förbättras. Detta genom att bättre förklara vad som bör testas samt hur ett fel återskapas. Bättre ifyllda användardirektiv samt eventuella punkter som bör tas i hänsyn som påverkar hur systemet fungerar vid möjliga ändringar som utvecklarna har gjort i systemet. Här finner vi att mycket onödig tid får spenderas från testarnas sida för att skapa sig en förståelse över vad det är meningen att de ska testa. Likaså skapas en förvirring bland testpersonalen när ändringar har gjorts i systemet som direkt påverkar hur systemet beter sig. Detta är något som anses vara en punkt där utvecklarna kan bättra sig när de skriver sina användardirektiv och som direkt kommer att påverka testavdelningen prestationer. Ett problem som respondenterna finner i nuläget är att kunderna inte alltid ger en tillräcklig mängd information vi rapportering av fel. Detta hindrar personalen att återskapa problemet för att sedan lösa det som inte fungerar i systemet. På samma sätt kan en utvecklare som inte 24