Resultat för TIM

I följande del kommer förklaringar till varför aktiviteter i KPA gavs en viss rating. Det redogörs även för vad TIM inte täcker som modell. För tabell över betyg se bilaga 9.

Nedan är en mognadsprofil för konsultverksamheten som presenterar resultatet för TIM (se figur 8).

Figur 8. Mognadsprofil för konsultverksamheten där alla KPA är på nivå 0 förutom Testware. Inspirerad av mognadsprofilen av Ericson et. al. (1997)

Teckenförklaring

ID - Ingen Data (från enkäten)

Organisation (Nivå 1)

Avrundad procentsats för aktiviteterna i enkäten:

“Testning sker i enlighet med dokumenterad standard” - 18% “Det finns en testledare” - 21%

“Det finns ett testteam” - 0%

Bedömning av aktiviteterna:

Dokumenterad standard för test finns det ej hos teamet, de tester som förekommer är av utvecklarna själva och sedan av en projektledare som utför systemtester. Både intervjun och enkätsvaren visar på inget användande av dokumenterad standard för testning. Detta leder till ratingen “N” på “Testning sker enligt dokumenterad standard”.

Projektledaren nämns som testledare men är löst kopplat till detta. Intervjun tillsammans med enkätsvaren gällande denna fråga påvisar att det har blivit en standard för projektledaren även agera som testledare

26 (för systemtesterna) inom deras projekt. Utifrån detta ges ratingen “P” eftersom testledare inte är en fast roll i teamet.

Något testteam finns inte i någon av projekten. Som tidigare nämnt så har varje utvecklare ansvaret för funktionstesterna och projektledaren för systemtesterna. Från intervjun så framkommer det att kunden har ansvar för att acceptanstesterna utförs. En annan aspekt är att projekten varierar i storlek (större e-handel till mindre företagshemsidor) vilket gör att det inte möjligt att ha ett etablerat testteam. Den andra

anledningen vilket gör att ett testteam kan etableras är budgeten för projektet som kommer in. Om det inte finns täckning för ett testteam så kan detta inte möjliggöras. Detta intygades senare från en projektledare (anonym, personlig kommunikation, 7 maj 2020), vilket ger ratingen “NA” på “Det finns ett testteam”.

Organisation (Nivå 2)

Avrundad procentsats för aktiviteterna i enkäten:

“Testningsfunktionen är samlokerade” - ID

“Nyckelpersoner arbetar fulltid på ett projekt och resurser (personer) är inte delade mellan projekt” - 0% “Test är separat från utveckling” - ID

“Team strukturen är baserad på resursinventering och projektets behov” - ID “Ansvar är definierade, dokumenterade och förstådda” - 42%

“Träning av personal möter organisationens behov” - 32%

Bedömning av aktiviteterna:

Från intervjun framgår det att teamet sitter i samma lokal vilket då också leder till att

“Testningsfunktionen är samlokaliserade”får ratingen “F”. Enligt Ericson, et. al. (1997) så behövs samlokalisering inom teamet för att etablera en god kommunikation mellan medlemmarna.

Nyckelpersoner arbetar dock inte bara på ett projekt. Denna aktivitet har angetts som “NA” då det inte är möjligt att ha endast en person arbetandes på ett projekt. I alla fall inte med nuvarande projekt och teamstruktur.

Test är till viss del separerad från utveckling då teamet har etablerade interntester (enhets- och

systemtester), som är test som utförs av teamet själva, och acceptanstester, som utförs av kund. Dock så görs testerna till stor del via debugging hos utvecklarna, vilket utifrån självständighetsgraden faller på 1:a graden. Det ges stora indikationer att självtestning är ett vanligt sätt att testa inom teamet utifrån den intervjuade (se avsnitt 2.9 för graden av självständighet inom testning). Detta ger “Test är separerat från utveckling” ratingen “P”.

För “Teamstrukturen är baserad på resursinventering och projektbehov” så påvisar enkäten ratingen “L”, vilket även intygas av projektledaren (anonym, personlig kommunikation, 7 maj 2020). Projektledaren intygar att innan ett projekt tas in så genomförs en resursinventering för att möta projektbehovet (anonym, personlig kommunikation, 7 maj 2020). Det enda som stoppar aktiviteten att nå till “F” är att ingen har rollen som testledare. När det kommer till ansvar så är dessa till stor del förstådda hos teamet, även fast de inte är dokumenterade. Detta ger ratingen “P” på “Ansvar är definierade, dokumenterade och förstådda”. Gällande träning av personal så framgår det inte i någon större skala utifrån den intervjuade. Detta ger ratingen “N” på “Träning av personal möter organisationens behov”.

Sammanställd bedömning av Organisation

Teamet har aktiviteter på nivå 1 som har fått rating “N” vilket resulterar i att de är på nivå 0, eftersom det t ex inte finns dokumenterad standard för test.

TIM har till stor del har lagt fokus på team eller företag som bara jobbar mot en produkt. Då företaget i fråga jobbar med flera projekt samtidigt, så leder detta till att nyckelpersoner inte kan jobba heltid med bara ett projekt.

27

Planering och Sökning (Nivå 1)

Avrundad procentsats för aktiviteterna i enkäten:

“Grundläggande planering genomförs” - 27% “Start- och slutkriterier sätts för alla testnivåer” - ID “Testresultat dokumenteras och distribueras” - ID

“Planer är utförda efter standarder och avvikelser dokumenteras” - 9% “Planering är utfört enligt dokumenterat policy” - ID

“Planer förändras med kraven” - 36%

“Förändringar i testplanen är gjord efter dokumenterad policy” - ID

Bedömning av aktiviteterna:

Grundläggande planering utförs av teamet, dock inte alltid testrelaterat. Många av de saker som planeras är userstories och funktioner kring dem. Start- och slutkriterier baseras på hur “långt” en feature har kommit. Har en feature kommit till “klar för test” så börjar man testa. Därefter, att den har testats och godkänts för att släppas till kund, så anses det vara slutkriteriet för testet. Detta ger “Grundläggande planering genomförs” och “Testresultat dokumenteras och distribueras” ratingen “L”. För “Start- och slutkriterier sätts för alla testnivåer” så hamnar ratingen på “P” på grund av bristen av testplan i projekten. Alla testresultat hanteras i Jira och på så sätt distribueras de mellan teamet och även intressenter som har tillgång till Jira-tavlan. Planer följs upp i form av sprintar och sprintmöten. Daily standup genomförs för varje arbetsdag för att hålla teamet uppdaterat om vad man jobbar med samt vilka svårigheter man har för dagen. Planer som skapas följer ingen standard men hur långt funktionerna har kommit i arbetsprocessen dokumenteras i Jira. Detta ger betyget “P” i “Planer är utförda efter standarder och avvikelser

dokumenteras”. Detsamma faller på “Planering är utfört enligt dokumenterad policy”.

Planer ändras med kraven enligt både intervjupersonen och enkätresultaten, vilket ger “Planer förändras med kraven” ratingen “L”. Då det inte finns en dokumenterad policy för hur förändringar i testplanen skall göras (samt att det inte finns en testplan), så får “Förändringar i testplanen är gjord efter

dokumenterad policy” ratingen “N”.

Planering och Sökning (Nivå 2)

Avrundad procentsats för aktiviteterna i enkäten:

“Planering och uppföljning sker digitalt” - 75% “Generiska planer används” - 3%

“Valen av testmetoder och testnivåer balanseras mot testobjekt och testuppgifter” - ID “Framsteg är mätta och jämförda mot planerna” - ID

“Planering är utfört av en tränad testare eller planerare” - ID “Planering är utfört på ett evolutionärt sätt” - 60%

“Resursförutsägelse är gjord efter dokumenterad policy” - ID

Bedömning av aktiviteterna:

All planering och uppföljning som tas upp sker via Jira. Detta ger ratingen “F” för “Planering och uppföljning sker digitalt”. Då inga testplaner finns tillgängliga så kan inte “Generiska planer används” få högre rating än “N”. Ericson et. al. (1997) specificerar dock inte vad som menas med “generiska planer”. Med denna osäkerhet ges slutligen ratingen “NR” då det finns tvivelaktigheter i bevisen och modellen. Det var bristande bevis på aktiviteten “Valen av testmetoder och testnivåer balanseras mot testobjekt och testuppgifter” vilket ger ratingen “N”. Framsteg är mätta i Jira, den mäter (eller bekräftar) att en viss funktion eller “user story” har kommit vidare i arbetsprocessen. Detta ger “Framsteg är mätta och jämförda mot planerna” ratingen “L”. All planering sker på ett evolutionärt sätt, d.v.s under projektets livsgång, vilket intygas av projektledaren (anonym, personlig kommunikation, 7 maj 2020). Detta ger “Planering utfört på ett evolutionärt sätt” ratingen “L”

Testplaneringen är inte utförd av en tränad testare eller planerare vilket ger “Planering är utfört av en tränad testare eller planerare” ratingen “N”. Detta förstärks även med intervjun då intervjupersonen

28 nämner att det inte finns någon “renodlad testare” på teamet. Med renodlad testare så menar

intervjupersonen en person som har testare som titel och enbart jobbar med test. När det kommer till resursförutsägelse så finns det ingen riktlinje för hur dessa skall utföras. När nya projekt ska hanteras så kontrollerar man budget och sedan på vilka resurser (utvecklare) som finns tillgängliga. Detta ger ratingen “P” på “Resursförutsägelse är gjord efter dokumenterad policy”.

Sammanställd bedömning av Planering och Sökning

Med det sammanställda resultatet, om man går efter “svagaste länken”-principen, så hamnar teamet på nivå 0 på Planering och Sökning.

Det går att applicera detta tänk gällande framgångs- och planeringsuppföljning i den agila metoden. När teamet rapporterar in var varje user story ligger i för fas (utveckling, klar för test, osv.) så kan det snabbt tas upp i en daily-standup eller vid sprintplanering. Baseline ger en god grund för hur det agila arbetssättet används. T.ex. “Planer ändras med krav” är mycket aktuell med det agila tänket och arbetsmetoden. Sprintar erbjuder även denna form av reaktionsförmåga i projekt, men det gäller dock att den som utvärderar mognadsnivån känner till agila arbetssätt sedan tidigare.

Testfall (Nivå 1)

Avrundad procentsats för aktiviteterna i enkäten:

“Testfall blir reviderade när kraven ändras” - 36% “Testfall baseras på kraven” - 42%

“Testfall är designade och dokumenterade enligt dokumenterad policy före genomförande” - 15% “Tesfall genomförs efter dokumenterade instruktioner” - 9%

Bedömning av aktiviteterna:

“Testfall blir reviderade när kraven ändras”, de testfall som finns ändras i samband med att kraven ändras enligt intervjupersonen. Men med bristen på klara bevis, samt att enkät resultatet så får teamet ratingen “P” för denna aktivitet. Att testfall baseras på kraven stämmer till god del både från intervjun och enkäten. Så intervjun tillsammans med enkäten ger “Testfall baseras på kraven” ratingen “L”.

Bristen på testfall belyses dock på båda aktiviteterna “Testfall är designade och dokumenterade enligt dokumenterad policy före genomförande” och “Testfall genomförs efter dokumenterade instruktioner”. Även intervjupersonen intygar att testfall utförs sällan men att de utförs där det behövs. Testfall brukar förekomma på de större projekten såsom E-handel eller stora applikationer med många funktioner. Men det beror oftast på hur upphandlingen ser ut och hur mycket tid som läggs på att det testas. Detta ger båda aktiviteterna “P” i rating.

Testfall (Nivå 2)

Avrundad procentsats för aktiviteterna i enkäten:

“Testfall är designade via dokumenterade tekniker” - ID “Testbarhet influerar krav och design” - ID

“Testfall är organiserade efter testnivå, krav, testobjekt, uppgifter osv” - ID

Bedömning av aktiviteterna:

Aktiviteterna “Testfall är designade via dokumenterade tekniker” och “Testfall är organiserade efter testnivå, krav, testobjekt, uppgifter o.s.v” får en rating på “N”. Då teamet har brist på testfall i sina projekt samt att det inte finns konkreta bevis för att testbarhet influerar krav. Det som nämns i intervjun så genomförs test av någon som känner till funktionaliteten av systemet i sin helhet (t.ex. projektledaren, utvecklaren). I intervjun nämndes också att teamet inte har någon designteknik när det kommer till testfall. För aktiviteten “Testbarhet influerar krav och design” finns det inte tillräckliga bevis för att det sker. Detta ger aktiviteten ratingen “N”.

Sammanställd bedömning av Testfall

Trots relativt goda resultat på vissa områden så uppnås inte nivå 1, som beror till stor del på att det inte finns en dokumenterad policy för testfall. Nivån för KPA:n blir 0.

29

Testware (Nivå 1)

Avrundad procentsats för aktiviteterna i enkäten:

“Problemrapportering sker via dator” - 79%

“Filsystem används för “configuration management” - ID

“Databaser används för “configuration management” av testware” - ID (Nivå 2)

Bedömning av aktiviteterna:

Alla problemrapporteringar (buggrapporter) hanteras i Jira, och som påvisas på både i enkäten och i intervjun där intervjupersonen instämmer i att det sker i stor utsträckning. Detta ger “Problemrapportering sker via dator” ratingen “F”.

Då projektens storlek kan variera från att vara e-handelssystem till små företagshemsidor så har “Filsystem används för configuration management” och “Databaser används för configuration

management” av testware” valts att sättas som “NA”. Om teamet hade arbetat med större system så som enterprise-system eller militärsystem så hade detta applicerats på teamet.

Testware (Nivå 2)

Avrundad procentsats för aktiviteterna i enkäten:

“Datorstöd för problem spårning, kodspårning och testutförande” - ID

“Datorstöd för testfallsresultatinsamling, inspelning, bearbetning och rapportering” - ID “Verktyg för täckningsanalys används” - ID

“Hårdvaru- och mjukvarusystem är simulerade” - ID “Testverktyg evalueras före de är köpta och används” - ID “Statistikverktyg används för t.ex. kodgranskning” - ID

Bedömning av aktiviteterna:

Jira är en stor del som används för att kontrollera projekten och deras tester. “Datorstöd för

problemspårning, kodspårning och testutförande” sker helt via Jira samt GIT. Detta bekräftas av arkitekt B (anonym, personlig kommunikation, 7 maj 2020) som även instämmer att Jira används i projekten. Därav ges ratingen “L” på aktiviteten. För “Datorstöd för testfallsresultatinsamling, inspelning, bearbetning och rapportering” så sker även det i Jira. Detta ger aktiviteten ratingen “L”.

När det kommer till “Verktyg för täckningsanalys används” så menar Ericson, et. al. (1997) att dessa verktyg används för att verifiera testningen av alla delar i projektet. Detta täcks till viss del upp av Jira:s tavelstruktur då t.ex. en userstory kan vandra från backlog till “klar för test” och slutligen “släpps till kund” (detta beror helt på upplägget i tavlan). Detta ger en täckningsanalys på userstory och

funktionsnivå som garanterar att de testas. Sedan, om det finns existerande backlog-items för specifika acceptanstester, så är detta inte verifierat från intervjun eller enkäten. Av tidigare nämnda anledningar så får denna aktivitet “P” i rating.

Vid intervjun framkom att för hård- och mjukvarusimulering så använder teamet browserstack. Där kan man simulera olika enheter och webbläsarversioner, detta beroende på vad kunden använder för enhet. Detta ger ratingen “L” på “Hårdvaru- och mjukvarusystem är simulerade”.

Vid en diskussion med arkitekt B (anonym, personlig kommunikation, 7 maj 2020) så framkommer det att testverktyg evalueras för användning. Detta för att det är en kostnad och inlärningsprocess som ingår vid dessa inköp. Detta stämmer överens med det Ericson, et. al. (1997) framför i sin rapport. Då det tar en hög nivå av resurser att anpassa sig till nya verktyg, så måste man evaluera dem innan inköp. Detta ger ratingen “F” på “Testverktyg evalueras”. För statistikverktyg så har Jira möjligheten att granska projekten med statistik (antal buggar, antal stories klara), men om det används finns det ingen bevisning för, vilket även ger denna aktivitet “N”.

30

Sammanställd bedömning av Testware

Teamet uppnår nivå 1 men når inte hela vägen vid nivå 2. Detta till stor del av bristen i statistiska verktyg för kodgranskning och täckningsanalys inom testning.

Granskning (nivå 1)

Avrundad procentsats för aktiviteterna i enkäten:

“Krav är granskade” - 33 %

“Granskningsansvarig och ledning är given träning inom granskningstekniker” - 24 % “Träning och stöd är inköpta för första projektet” - ID

“Standardiserade och dokumenterade granskningstekniker används” - 15 %

Bedömning av aktiviteterna:

Om man går efter Ericson, et. al. (1997) beskrivning är granskning av krav en generisk term som skall göra det möjligt att välja den metod eller teknik man önskar under en granskning. Gällande aktiviteten “krav är granskade” framkom det vid en diskussion med projektledaren (anonym, personlig

kommunikation, 7 maj 2020) att de använder effektkartläggning. Effektkartläggning enligt projektledaren används för att få fram processer, syfte och mål för mjukvara vilket då kan ses som en form av

kravgranskning. Utifrån det så kan “Krav är granskade” sättas som “L” då det finns bevis, med även enkätsvaret, att de granskas baserat på kundens behov.

När det kommer till aktiviteten “Granskningsansvarig eller ledning är given träning inom

granskningstekniker” så löd frågan i enkäten: “Det finns möjligheter för träning/utbildning gällande kravgranskning”. Detta för att fånga in en bredare mängd personer som kan besitta denna träning och faktiskt ha hand om kravgranskning. Vid intervjun så framkommer det ingen vetskap om någon sådan utbildning hos teamet, detta bekräftas även av en projektledare (anonym, personlig kommunikation, 7 maj 2020). Detta ger aktiviteten ratingen “N”.

Aktiviteten “Träning och stöd är inköpta för första projektet” så menar Ericson et. al. (1997) att det är en säkerhetsåtgärd för att inte rubba förtroendet för den som kanske gör en kravgranskning för första gången. Dock så har teamet effektkartläggning som kravgranskningsteknik vilket dem använder i projekt. Denna aktivitet har då satts som “NA” då teamet inte är nya till kravgranskning.

Gällande aktiviteten “Standardiserade och dokumenterade granskningstekniker används” så förekommer effektkartläggning, vilket är den enda kravgranskningstekniken som förekommer hos teamet. Den är dock en dokumenterad standard. Detta ger aktiviteten ratingen “P”.

Granskning (nivå 2)

Avrundad procentsats för aktiviteterna i enkäten:

“Alla granskningsanställda ges träning i granskningstekniker” - 32 % “Checklistor, scenarios etc. är anpassade och använda” - ID

“Design- och koddokument är granskade” - 36 %

“Organisationen har några granskningstekniker att välja mellan” - ID

Bedömning av aktiviteterna:

Som tidigare nämnts så faller “Alla granskningsanställda ges träning i granskningtekniker” på ratingen “N” då det inte finns indikation eller bevis på att detta görs baserat på intervjusvaret, trots en relativt hög procentsats för aktiviteten. Samt med granskningsanställda så faller projektledare inom denna kategori då det är de som håller i kravhanteringen, enligt intervjupersonen.

Utifrån vad Ericson, et. al. (1997) menar med checklistor så går rapporten inte in i detalj på vad som menas. Det gör punkten väldigt otydlig att kunna kartlägga. Om bedömningen utgår blint från att “det finns checklistor för granskning” så finns det inga påvisade checklistor hos teamet. Gällande scenarion så försöker man, enligt intervjupersonen, att visualisera vilka personer som besöker webbplatsen och hur deras resa genom webbplatsen ser ut. Utifrån det så får man fram funktioner som ska tillgodose kundens önskemål. Detta bekräftas också via projektledaren (anonym, personlig kommunikation, 7 maj 2020).

31 Slutligen så hamnar ratingen på “P” för “Checklistor, scenarios etc. är anpassade och använda” till stor del för bristen på checklistor att följa.

Koddokument blir granskade enligt intervjupersonen och för att upprätthålla bra kod så nämns även “clean code”. Från diskussionen med projektledaren (anonym, personlig kommunikation, 7 maj 2020) så framkommer det att teamet även gör en granskning av designen med kund. Detta för att få fram hur allt ska fungera. Intervjun och diskussionen lyfter enkätresultatet från “P” till ratingen “L” på “Design- och koddokument är granskade”. Ericson et. al. (1997) menar på att kod- och designgranskning ska

genomföras för att upprätthålla testkvalitén, vilket teamet även gör för det mesta.

Bristen på val av granskningstekniker (utöver effektkartläggning) gör att “organisationen har några granskningstekniker att välja mellan” faller på en rating av “N”.

Sammanställd bedömning av Granskning

Bedömningen leder till att resultatet blir 0 på Granskning. Bristen på träning hos teamet är en av orsakerna till att teamet inte avancerar till nivå 1.

Resultat i relation med TIM:s delmål

Tabell 1 visar de delmål som finns. Som tidigare nämnt så finns inte en dokumenterad standard som teamet efterföljer gällande test. De har väldigt löst satta metoder för systemtest samt acceptanstest, men de har en grundläggande testfunktion. Detta ger dem ratingen “P” i nivån “Baseline”. För

“Cost-effectiveness” så uppfyller teamet delvis målet med att ha en snabb och systematiserad testning, vilket är på grund av användandet i Jira. För resterande mål i “Cost-effectiveness” så framkommer inte tillräcklig bevisning från intervjuerna eller tidigare analyserade aktiviteter. Detta gör att teamet inte når till delmålen under “Cost-effectiveness”.