De tre testprofilerna

Under analysen av fälttesten har olika utvecklingsidéer tagit form. Idéerna grundar sig i syftet med testning av mjukvara och i acceptanstestetens syfte. Förbättringsförslagen fokuserar på att belysa olika områden och kallas därför testprofiler. Profilerna är behäftade med olika för och nackdelar och är olika kostsamma att följa. Ingen profil är bättre än någon annan och i den bästa av värdar så går det att använda sig av alla fyra för att plocka fram ett testramverk som är så utförligt som möjligt. Vårt förslag är att iterera sig fram till en lösning som är effektiv både till hur väl den utvärderar kvalitet och identifierar defekter samtidigt som en lågkostnad bibehålls.

57

7.6.1 Verifierandeprofil

Denna profil har som mål är att fortsätta längs funktionalitets och pålitlighetsspåret. Bygger vidare på den funktionstäckning som utformats.

 Mål - Påvisar att mjukvaran är fri från fel

 Fördel: - Relativt billig att implementera, skapar tilltro till mjukvaran, grundutförandet

fungerar som det ska, enkelt att följa kvantitativt användande, fungerar bra som statisk mall.

 Nackdelar – Sannolikheten att finna ytterligare defekter är fortsatt låg, resultatet kan vara av

lågt värde ifall produkten överlag är stabil.

 Kostnad – Låg, vidare intervjuer och eventuell korrigering av loggning.

Med detta fokus vill vi skapa trygghet i att programmets grundfunktionalitet fungerar och inte leder till att avvikande beteende. Strukturen borde korrigeras i nära samarbete med gruppens CM-roller (sköter sammanfogandet av mjukvaran till den färdiga produkten SDP3) för att undersöka vilka olika delar som bygger SDP3. Därefter kan intervjuer med produktägare för respektive del utföras för att identifiera grundpelare i mjukvaran för respektive delar, här bör också loggningen utföras så att det går att följa användandet av dessa delar. Efter att intervjuer med respektive produktägare kan ett kärnpaket av SDP3 funktioner byggas upp och följas under fälttestet. På så vis verifikationen detaljerad och resultatet av varje fälttest blir nyttigt för samtliga grupper. Kärnpaketet kan sedan utökas med säkerhetskritiska funktioner eller användarprofiler för att skapa ytterligare trygghet till mjukvaransfunktionalitet. Då mjukvaran redan genomgått regressionstest så är sannolikheten att detta fokusområde identifierar nya defekter relativt låg, finns det samtidigt en hög tilltro till

programmets funktionalitet så är det risk för att denna profil bara blir en kostnad som inte ger något mervärde till testningen.

7.6.2 Testandeprofil

Profilen är en vidareutveckling av testningen som sker på gruppen. Denna profil gör att strukturen inte längre kan hålla en statiskform utan istället behöver korrigeringar göras mellan testomgångarna.

 Mål – Finna ytterligare defekter i mjukvaran, ta tillvara den större kombinationen av

konfigurationer som besöker verkstäderna.

 Fördel – Har större potential till att hitta fler fel i mjukvaran, följer korrigeringar som gjorts

och påvisar att dessa inte medfört fel, potentiellt det effektivaste spåret sett till kostnad/antal defekter som identifierats, en trygghet för utvecklare att veta att ändring inte påverkat det verkliga användarna.

 Nackdel – Kostsamt att korrigera strukturen mellan fälttest, kostsamt att effektivisera struktur

enligt denna profil, fortsatt risk att kostnaden inte ger den önskade effekten, flera parametrar som det inte går att styra över kan ge dålig täckning.

 Kostnad – Relativt hög, intervjuer, studier och viss mjukvaruutveckling krävs för att denna

modell ska bli effektiv.

Denna modell kan ses som en vidare regressionstestning. Fortsatta tester syftar till att hitta defekter i mjukvaran. Vilka tester ska du utföras? Ett axiom inom mjukvarutestning är att det aldrig går att testa alla delar av mjukvaran. Ett urval behöver göras för att välja ut vilka tester som ska följas upp. När en regressionssvit väljs ut finns det två områden som anses effektiva att undersöka för att hitta defekter.

Det första området är att undersöka den del av mjukvaran som genomgått förändring, när en utvecklare rör vid koden finns en direkt risk för att defekter introduceras. Defekterna är inte begränsade till enbart modulen där ändringen sker utan påverkar även alla de moduler som står i

58 beroende till den korrigerade modulen. Inte helt ovanligt är det heller att gränssnitt och integritet rubbas av förändringar. Förändring kan alltså leda till defekter.

Vårt andra undersökningsområde är att undersöka felbenägna moduler. En annan paradox inom mjukvarutestning är att ifall en modul innehåller ett fel ökar sannolikheten att det finns ytterligare fel i modulen. Detta kallas för att ”defect clustering”. Vilket tyder på att delar av mjukvaran som

tidigare har orsakat defekter kommer troligtvis att göra det även i framtiden. Att följa felbenägna moduler och även gå på magkänsla kan vara ett effektivt sätt att identifiera ytterligare defekter i mjukvaran.

En vidareutveckling av teststrukturen enligt denna modell går genom två steg. I det första steget behöver ett skript utvecklas som kommunicerar med ett Perforce API. Tanken är att skriptet tar emot två versionsnummer och returnerar en lista över de guider som genomgått förändring mellan de två versionerna, men också en lista över ytterligare funktionalitet i mjukvaran som inte funnits tidigare. Denna lista kan sedan matas in i Splunk för att kunna följas upp. Steg två består av intervjuer och statistisk sammanställning av felrapporter för att hitta de delar av systemet som ofta genererar fel. Med dessa två underlag borde teststrukturen kunna utvecklas så att fler defekter alternativt risker identifieras under en testomgång.

7.6.3 Kundnöjdhetsprofil

Läroboksexempel inom agilutveckling talar om acceptanstester och att dess primära syfta är att involvera kunden i testandet av mjukvara. Där målet är att i kundkretsar skapa en acceptans för mjukvaran, i slutet är det kunden som godkänner ifall mjukvaran kan släppas eller inte.

 Mål – Skapa acceptans hos kunderna.

 Fördel – Den effektivaste metoden för att faktiskt utvärdera kvalitén hos mjukvaran, skapar

ett engagemang hos kundbasen, ett ökar engagemang ökar troligtvis frekvensen på inrapporterade fel.

 Nackdel – Väldigt kostsamt, en organisatorisk omorganisation, kommer med största

sannolikhet kräva en helt annan form av teststruktur.

 Kostnad – Kundbesök, kundkontakt, omorganisation, utvecklande av ny teststruktur, skapa

kundcase.

Detta är den mest extrema av testprofilerna och skiftar fokus för syftet av en testomgång. Det är inte längre en uppföljning av en testtäckning utan istället en utvärdering som görs av kunderna. Anledningen till att denna profil lyfts in är främst för att mjukvaran redan genomgått automatiska regressionstester vilket borde hittat de flesta av defekterna i mjukvaran. Att sedan skicka mjukvaran på fälttest borde i teorin inte göra att särskilt många nya defekter rapporteras in vilket är dåligt ur ett effektivitetsperspektiv. Om fälttestet istället fokuserar på de kvalitetsaspekter som avgörs av

kundernas användare så borde de ge ett bättre resultat. Då kan istället de verkliga kvalitetsaspekterna undersökas.

Stegen för att förverkliga denna profil blir att först hitta lämpliga verkstäder att ingå ett närmare samarbete med. Här är det viktigt att hitta verkstäder med olika fokusområden. Därefter ska kundcase byggas upp för att hitta det typiska användandet hos varje verkstad. Sist ska en ny

teststruktur plockas fram med mål att lyfta in så många parametrar från ISO-modellen som möjligt fast på ett effektivt sätt. Det dagliga arbetet med fälttesten kommer också att behöva ändras där en nära kundkontakt blir av yttersta vikt.

59