Uppnådda effekter
I Rafi et. als. [43] litteraturstudie angående begränsningar och fördelar med automatiserad testning konstaterades det att automatiserad testning inte kan ersätta manuell testning. Detta konfirmeras i denna studie då utvecklarna menar att de automatiserade testerna fungerar som ett komplement till den manuella testningen. Enhetstesterna är bra för att täcka in testfall som är svåra eller jobbiga att testa manuellt, samtidigt som den manuella testningen sker i samma utsträckning som tidigare.
I och med detta kan dock andra resultat från litteraturstudien ifrågasättas. Automatiserad testning anges vara mindre tidskrävande. När vissa tester är automatiserade kan de män- skliga ansträngningar istället läggas på annat och med automatiserad testning finns möj- ligheten att genomföra fler tester under en viss tidsperiod. I detta projekt har inte dessa effekter märkts av. Visserligen körs fler tester men utvecklarna rapporterar även mer tid lagd på testning. Rafi et. al. rapporterar dock även att processen för testautomation behöver tid för att mogna. Det krävs en högre initial tidsinvestering innan nyttan av av testautomation kan märkas. Även utvecklarna uttryckte att det initialt tog mer tid att skriva tester men att de var övertygade om att det skulle betala tillbaka sig. Under slututvärderingen drog de par- alleller till andra projekt som då låg i slutfasen. Enligt utvecklarna var det där tydligt att en automatiserad testsvit hade kunnat spara mycket testningstid. Detta tyder på att avsaknaden av tidsvinster i denna studie kan bero på att projektet inte fått tillräcklig tid att mogna. Det primära målet för Exsitec var att få ett större förtroende för kodens kvalitet. Enligt utvecklarna har detta mål uppnåtts. De menade att de kände "större trygghet för att logiken fungerar". Även produktkvaliteten uppskattas ha blivit bättre. De automatiserade testerna var mer restriktiva än de manuella och detta ledde till att fel som annars hade förbisetts blev upptäckt. Den förbättrade kodkvaliteten kan alltså ses som en konsekvens av en ökad för- måga att upptäcka fel. Alla dessa effekter stämmer överens med det som Rafi et. al. kom fram till.
Införandet av modeller för testförbättring medför enligt Garousi, Felderer och Keller [18] att spårbarheten för fel ökar. Detta har återfunnits i denna studie, men orsaken verkar en- dast vara enhetstester snarare än hela processen. Utvecklarna uttryckte att det blivit lättare att hitta källan till ett fel. De menade att detta berodde på att enhetstesterna ligger närmre logiken, jämfört med de manuella testerna som testar servicelagret.
Generellt sätt har den nya testprocessen, enligt utvecklarna, medfört positiva effekter. En mer diversifierad teststrategi, större förtroende för kodkvaliteten, färre buggar och bättre spårbarhet. Haugset och Hanssen [21] menar dock att automatiserad testning kan ge en falsk känsla av säkerhet och godkända tester inte behöver innebära att applikationen fungerar. Det krävs erfarenhet för att skriva bra tester. Utvecklarna verkade medvetna om detta och menade att det är viktigt att poängtera att även fast de anser att testningen blivit bättre så finns det mycket att förbättra. De konstaterade att man inte kan lita på att applikationen fungerar för att testerna är godkända och att ett ökat test-scope, främst genom att använda sig av end-to-end-testning, integrationstester och att enhetstesta smarta komponenter, skulle gör testsviten ännu mer tillförlitlig. De är även medvetna om deras begränsade erfarenhet och ansåg att de inte hade skrivit tillräckligt många tester för att kunna avgöra vad som kate- goriserar ett bra test. Trots dessa begränsningar var den rådande uppfattningen att det ökade förtroendet för kodkvaliteten var befogad då koden ändå testades betydligt mer än tidigare.
6.2
Metod
Vi valde att använda ett iterativt arbetssätt för att hitta en lämplig testprocess för avdelningen, på ett naturligt sätt. Idén bakom valet av CMD byggde på att låta utvecklarna själva påverka
6.2. Metod
utformningen av processen i så stor utsträckning som möjligt. CMD har utgjort ett ramverk för studien och möjliggjort en studie nära utvecklarnas vardagliga miljö.
I enlighet med CMD gjordes all utvärdering från utvecklarnas perspektiv efter att de haft praktisk erfarenhet av metoderna och verktygen i sin arbetsmiljö. Detta gjorde att processen kunde utvärderas utifrån hur den verkligen fungerade i miljön den var tänkt att användas i. Detta bedöms vara en faktor som ökar sannolikheten att avdelningen kommer kunna fort- sätta arbetet med att förbättra sitt testningsarbete även efter studiens slut. Utvecklarna har nu praktisk erfarenhet av verktygen, och de vet att processen faktiskt fungerar för dem och inte bara "i teorin".
En studie som bygger så mycket på involverade utvecklare blir dock mycket beroende av utvecklarnas möjlighet att lägga tid på projektet. Detta visade sig bli den största begränsnin- gen för studien. Under studiens gång blev projektet nedprioriterat vilket begränsade hur mycket processen kunde utvecklas. Utvecklarna hann således inte jobba tillräckligt mycket med processen för att hinna införa och utvärdera så många ändringar som det var tänkt. Denna begränsning hanterades genom en utförligare utvärdering i slutet av arbetet för att ta tillvara alla erfarenheter av processen och utvecklarnas syn på testningsarbetet i framtiden. Det resulterade ändå i att färre aspekter av testningsarbetet hann utvärderas. De delar av testprocessen som konstaterades vara viktigast hade således mindre "konkurrens" från andra möjliga delar.
Validitet och reliabilitet
Validiteten för studien diskuteras utifrån de fyra aspekter av validitet Runeson och Höst [46] definierat.
Konstruktionell validitet
Denna aspekt behandlar huruvida det som studeras verkligen motsvarar forskarnas frågeställning [46]. Den konstruktionella validiteten har främst tagits i beaktande då studien utformades. Genom att studera en verklig miljö och jobba nära utvecklarna har risken för missförstånd minimerats genom att undvika hypotetiska exempel och låtsasapplikationer. Utvecklarna har bara behövt utvärdera verktyg och metoder som de använt i den miljö de är tänkta att användas vilket minskat risken för att utvecklare och forskare tolkat ämnet på allt- för olika sätt. Utvecklare som blivit intervjuade har alltid fått se transkriptionen av intervjun för att kunna korrigera eventuella feltolkningar från forskarnas håll.
Intern validitet
Denna aspekt av validitet berör de slutsatser studien kommer fram till. Om en faktor sägs ha en viss påverkan finns det en risk för att okända faktorer också spelat en roll utan att forskarna identifierat dem. Detta är främst viktigt att ta i beaktande för studier som syftar till att påvisa kausala samband [46]. Denna studie är inte explanativ till sin natur och målet har varit att identifiera de faktorer i en testprocess som upplevs viktigast av utvecklarna, inte att bevisa kausala relationer. Denna studie har således inte påverkats av intern validitet, som endast är applicerbar på explanativa studier enligt Yin [59].
Extern validitet
Huruvida resultaten som uppnåtts är generaliserbara, och i så fall till vilken grad, utgör studi- ens externa validitet. I kvalitativa studier finns sällan en statistiskt representativ urvalsgrupp som kan ligga till grund för slutsatserna. Istället måste analysen ske utifrån vilka slutsatser som kan tänkas vara relevanta för andra fall. [46]