SG 1 - Utför testanalys och design med hjälp av testdesigntekniker
Avrundad procentsats för aktiviteterna i enkäten:
SP 1.1 - 22 % SP 1.2 - 24 % SP 1.3 - 27 % SP 1.4 - 33 %
Bedömning av aktiviteterna:
Det är de två aktiviteterna SP 1.1 och SP 1.2 om testdesigntekniker som klassificeras som “N”. Under intervjun så framkommer det att intervjupersonen inte var bekant med testdesigntekniker. Teamet jobbar sedan tidigare nämnt ostrukturerat med testning. Begreppen white box testning och black box testning är inget som intervjupersonen verkar medveten om att de använder. Detta styrktes ytterligare av att i enkätresultaten så hade en av aktiviteterna om testdesigntekniker en av den lägsta procentsatsen för hela mognadsnivån.
SP 1.3, om utförandet av testfall, blir även den “N”. Enligt TMMi (2018) så ska testdata som krävs för att implementera och genomföra testfallen identifieras samt specificeras, eventuellt som en del av
testfallspecifikationen, men utifrån enkätresultatet och intervjun så kan det tolkas som att teamet inte gör det i en större utsträckning. Intervjupersonen säger att de sällan skriver testfall och att tillfällena blir isåfall när någonting verkligen måste fungera, beroende på projekt.
SP 1.4 handlar om dokumentationen kring spårbarhet för krav och testvillkoren. Trots att teamet använder Jira i stor utsträckning så är det ingen garanti att teamet kartlägger testfall med testvillkor, med tillägg som RTM för Jira. Sedan har teamet outtalade krav på testning. Det leder till bedömningen “N”.
Bedömningen innefattar:
SG 2 - Utför testimplementation
Avrundad procentsats för aktiviteterna i enkäten:
SP 2.1 - 33 % SP 2.2 - 27 % SP 2.3 - 22 % SP 2.4 - 24 %
Bedömning av aktiviteterna:
SP 2.1 kretsar kring utvecklandet och prioriteringen av testförfaranden, och som för teamet varierar mycket mellan projekt och baseras i stort sett på kunden. Projektledaren säger (anonym, personlig konversation, 7 maj 2020) att de vet om att det kan finnas ett starkt driv från kundens sida att ha struktur
38 på testförfaranden och att de då redan från början är med på noterna. Hen går vidare in på att de har fått tona ner omfattningen av administrationen för testverksamhet av budgetskäl. SP 2.1 hamnar på “P”.
SP 2.2 är kopplad till processområde 5 - SP 2.2, som berör testmiljön (TMMi-Foundation, 2018, sid 61), och handlar om att skapa specifik testdata. SP 2.2:s låga procentsats vägs upp av den aktiviteten (PA 5, SP 2.2) som har en procentsats på 51,11 %. Aktiviteten får “P”.
SG 2.3, om det finns en specifikation om röktester, är inget som framgår under varken intervjun eller den personliga konversationen med projektledaren (7 maj, 2020). Enkätresultatets låga procentsats pekar på en brist i utförandet i någon form av röktester och med det så föll beslutet på “N”.
SP 2.4 får bedömningen “N” med tanke på teamets hållning till testning överlag. Det finns inte belägg för att det redan skulle finnas ett testschema som beskriver sekvensen i vilken tester kommer att utföras i.
Bedömningen innefattar:
SG 3 - Utför testexekvering
Avrundad procentsats för aktiviteterna i enkäten:
SP 3.1 - 24 %
SP 3.2 - 27 % & 49 % SP 3.3 - 67 %
SP 3.4 - 36 %
Bedömning av aktiviteterna:
SP 3.1 är om röktester för att upptäcka buggar. Teamets hantering av buggar är inte bristfällig, dock framkommer det inte av varken intervjun eller av en högre procentsats från enkäten att det utförs röktester i syfte att upptäcka buggar för testobjektet. Den här aktiviteten är relaterad till processområde 5 för testmiljön, SP 2.4, och handlar om röktester i en testmiljö. Enligt TMM-Foundation (2018, sid 63) så kan bägge aktiviteterna kombineras. Båda aktiviteterna visar en låg procentsats och indikerar på att röktester inte är något som är vanligt förekommande hos teamet och får därför bedömningen “N”.
Aktiviteten för att automatiskt med skript och/eller manuellt utföra testfallen är egentligen en och samma aktivitet, SP 3.2, som bara är uppdelad för att kunna peka ut
vilken aktivitet som faktiskt utförs bland dessa två. Projektledaren säger (anonym, personlig konversation, 7 maj, 2020) kring automatiserade tester att automatiska tester utförs bara vid behov. Det finns kunder enligt hen där kunden inte ens bryr sig om testningen. Intervjupersonen säger också att de sällan skriver enhetstester som körs direkt emot koden och att de inte har automatiserade tester på så vis. Procentsatsen mellan dessa två nämnda aktiviteter är stor, med 26,67 % för “testfallen utförs automatiskt med
fördefinierade skript” och 48,89 % för “testfallen utförs manuellt med hjälp av dokumentation”. Det går utifrån detta då att dra slutsatsen att testfallen utförs till största del manuellt, vilket hamnar på
bedömningen “P” för hela aktiviteten.
SP 3.3 har den högsta procentsatsen för hela processområdet och därmed för SG 3. Sedan tidigare nämnt rapporteras allting in i Jira. Enligt intervjupersonen så prioriteras incidenter, som buggar, på hur allvarliga de är och görs ihop med kund. Aktiviteten får “L”.
Den sista aktiviteten för SG 3 är SP 3.4 om testloggar. Av de insamlade bevisen så framkommer det inte om testloggar är skrivna i Jira för att ge en kronologisk registrering av relevanta detaljer (vilka testfall som kördes och vem som gjorde det) om genomförandet av testerna. Därför blir bedömningen “N”.
Bedömningen innefattar:
SG 4 - Ta hand om testincidenter till avslut
Avrundad procentsats för aktiviteterna i enkäten:
39 SP 4.2 - 58 %
SP 4.3 - 58 %
Bedömning av aktiviteterna:
Enligt TMMi (2018) så ska incidenter för tester ses över av en ledning, som för teamet blir
projektledaren. Bedömningen för SP 4.1 blir därför “P”. All intern testning går igenom projektledaren och hen har det sista ordet om produkten kan släppas till kund eller inte. Projektledaren (anonym, personlig konversation, 7 maj, 2020) påpekar vikten av att bibehålla kvalitén av deras egna interna tester för annars kommer allting tillbaka.
Gällande SP 4.2, om ifall det finns lämpliga åtgärder för att fixa, testa om och stänga incidenter eller skjuta upp till ett senare släpp, så säger intervjupersonen att de använder sig av en tavla i Jira (se figur 6) som består av kolumner för att hålla reda på incidenter (buggar) som kan behöva åtgärdas. I den kan teamet spåra testningen och se om utfallet av testningen blir godkänt eller inte. Bedömningen blir “L”. Slutligen för SG 4 är SP 4.3 som går in lite i föregående aktivitet (SP 4.2) om att fixa incidenter, fast handlar istället om statusen för incidenter. Återigen så är det Jira-tavlan som förser med information om tillståndet för incidenten. Enligt TMMi (2018) ska en statusrapport finnas tilldelad till intressenter så de kan se pågående och avslutande incidenter. Man kan anta utifrån enkätsvaret att Jira i någon form även erbjuder denna möjlighet till sina intressenter.
Bedömningen blir “L”.
Sammanställd bedömning för processområdet
SG 1, SG 2 och SG 3 får bedömningen “N” medan SG 4 hamnar på en bedömning av “P”. Detta processområde hade lägre genomsnittsvärdet, 26,67 %, i enkätresultatet än alla de andra processområdena. Hela processområdet får bedömningen “N”.
PA 5 - Testmiljö
Bedömningen innefattar:
SG 1 - Utveckla kraven för testmiljön
Avrundad procentsats för aktiviteterna i enkäten:
SP 1.1 - 64 % SP 1.2 - 44 % SP 1.3 - 38 %
Bedömning av aktiviteterna:
När det kommer till SP 1.1 så säger intervjupersonen att testmiljön ska se så lik produktionsmiljön som möjligt. Det finns ett antal lösningar för kund för att komma åt testmiljön, såsom molntjänster om de har sin egen IT. Teamet har en ständig dialog med sina intressenter för att tillgodose deras behov kring testmiljön. Baserat på det intervjupersonen säger och det enkätresultatet visar så uppfyller bedömningen “L”.
Angående SP 1.2 så förekommer det en viss antydan till att teamet förvandlar testmiljöbehovet till prioriterade krav. Enkätresultatet visar på en relativt hög procentsatsen från enkätresultat, vilket resulterade i bedömningen “P”.
För SP 1.3 så härstammar krav och specifikationer från user stories som kommer från kundmöten, enligt intervjupersonen. Eftersom målet är att testmiljön ska likna produktionsmiljön så mycket som möjligt så kan man dra slutsatsen att det också i viss utsträckning berör de analyserade testmiljökraven för att se till att de är nödvändiga, tillräckliga och genomförbara. Med det i åtanke så blir bedömningen “P”.
Bedömningen innefattar:
40
Avrundad procentsats för aktiviteterna i enkäten:
SP 2.1 - 60 % SP 2.2 - 51 % SP 2.3, 2.4 - 22 %
Bedömning av aktiviteterna:
Om testmiljön implementeras efter vad som anges i specifikationen för testmiljökrav och enligt den definierade planen framgår inte vid intervjun eller med projektledaren (anonym, personlig konversation, 7 maj, 2020). På grund av bristen på övertygande bevis kring framförallt den definierade planen så blir bedömningen för SP 2.1 “P” istället för “L”, trots en hög procentsats från enkäten.
SP 2.2 är relaterad till föregående processområde, PA 4, SP 2.2. Med enkätresultatets högre procentsats så går det att dra slutsatsen att teamet försöker efterlikna den riktiga produkten så att de har en representativ testdata i testmiljön efter en kravspecifikation.
Bedömningen blir “L”.
SP 2.3 och SP 2.4 kretsar kring röktester i en testmiljö och har en procentsats som är bland de lägsta för samtliga aktiviteter över alla processområden. SP 2.4 är nära besläktad med PA 4, SP 3.1, och handlar om röktester i en testmiljö och röktester är, som redan konstaterats, inte något som teamet uttryckligen utför. Båda aktiviteterna får därför bedömningen “N”.
Bedömningen innefattar:
SG 3 - Hantera och kontrollera testmiljöer
Avrundad procentsats för aktiviteterna i enkäten:
SP 3.1 - 33 % SP 3.2 - 40 % SP 3.3 - 76 % SP 3.4 - 78 %
Bedömning av aktiviteterna:
SP 3.1 rör systemhanteringen och att den är en del av att sätta upp en testmiljö, och man kan utgå från att teamet gör detta. Dock finns det inga bevis för att de utför en specifik loggning för systemhanteringen. Bedömningen blir dock “P”.
SP 3.2 handlar om testdata och det är sedan tidigare känt att testdata förekommer i testmiljön men hur den hanteras och kontrolleras gentemot testutförandeprocessen framgår inte av studiens resultat.
Bedömningen blir “P”.
SP 3.3:s enkätresultatet visar på att flera i teamet tycker att testmiljön är tillgänglig och används av flera grupper som samordnas för att uppnå maximal effektivitet. Detta styrks också av intervjupersonens svar gällande testmiljö.
Bedömningen för aktiviteten blir “L”.
All rapportering, t.ex. incidenter, som sker kring testmiljön rapporteras in genom Jira. Intervjupersonen säger att kunden kan gå in till testmiljön hur ofta och hur mycket de vill och allt de hittar och loggar i Jira kommer teamet att ta hand om. Bedömningen för SP 3.4 blir därför “L”.
Sammanställd bedömning för processområdet
Bedömningen för SG 1 och SG 3 blir “P”. SG 2:s slutgiltiga bedömning blir “N” på grund av SP 2.3 och 2.4. Samtliga påståenden om särskilt röktester visar på en återkommande låg procentsats i enkäten. Processområdet bedöms till “N”.
41
Bedömning av mognadsnivå
Den informella bedömningen blir att teamet inte når upp till mognadsnivå 3 eftersom samtliga processområden är rankade som “N” på mognadsnivå 2, vilket resulterar i att teamet stannar på
mognadsnivå 1. För att en mognadsnivå kan anses vara uppnådd så krävs det att varje processområde är antingen “L” eller “F” (TMMi-Foundation, 2014, s. 16).
4.3 Rekommendationer
Baserat på analysen redogörs rekommendationer. Enligt den “svagaste länken”-principen är rekommendationerna efter de KPA och PA som är klassificerade som “N” (Not Achieved).
TIM:s rekommendationer
TIM:s rekommendationer följer och baseras på aktiviteterna som nämns i modellen (Ericson, et. al, 1997). Strategierna som nämns i teorin (tabell 2) är en vägledning för att nå upp till en viss nivå.
Följande rekommendationer är baserade på bilaga 1, 8 och 9 samt tabell 2 för att nå upp till nästa nivå i varje KPA.
Organisation (Uppnådd nivå 0)
- Hitta en standard (t.ex. IEEE-829), alternativt producera en egen, som teamet ska gå följa. - Om möjligheten finns så anställ en testledare som specialiserar sig på test enbart.
Planering och sökning (Uppnådd nivå 0)
- Etablera start- och stopkriterier för era tester. Detta etableras i en testplan för varje projekt. - Hitta en standard för planering av test (t.ex. IEEE-829). Sätt upp en policy och kontrollera att detta efterföljs, detta skapar ett gemensamt mönster för test i teamet.
- Förändringar i testplanen ska också ske efter standard. Teamet har en god planering gällande userstories och det iterativa arbete som teamet har låter de att snabbt förändra i planering gentemot kraven.
Testfall (Uppnådd nivå 0)
- Se till att testfall som skrivs revideras med kraven.
- De testfall som skrivs (även fast dem är få) baseras på krav. Men efterfölj en vald standard (t.ex. IEEE-829) för testning.
- De test som utförs, om ni har kapaciteten, skriv testfall för dem. Detta leder till mindre ad hoc-testning.
Testware (Uppnådd nivå 1)
- Använd statistik för hur teamet ligger till i era projekt, t.ex. hur många stories (samt testfall relaterade till dem) som är kvar eller aktiva buggar.
Granskning (Nivå 0)
- Hitta en standard för granskning av test i relation med kraven (t.ex. att ha testfall kopplade till en userstory och hitta sätt att testa en sådan på).
TMMi:s rekommendationer
TMMi:s dokumentation (2018) ligger till grund för följande rekommendationer baserat på analysen.
PA 2.1 - Testpolicy och strategi (“N”)