Modbat

Modbat anv¨ander modeller utformade som extended finite state machines (EFSM) skrivna i programmeringsspr˚aket Scala. Modbat finns tillg¨angligt som .jar-fil eller via k¨allkoden p˚a Github [24]. Modbat l¨aggs till som en modul i utvecklingsmilj¨on eller k¨ors direkt fr˚an ter-minalen och inneh˚aller alla n¨odv¨andiga funktioner f¨or att modellera och k¨ora tester.

Kortfattat traverserar Modbat modellens tillst˚and och v¨aljer slumpm¨assigt en exekve-ringsv¨ag utifr˚an modellens nuvarande tillst˚and. Om inga exekveringsv¨agar i nuvarande tillst˚and finns s˚a avslutas testfallet. Den som modellerar har d¨arf¨or kontroll ¨over m¨ojliga exekveringsv¨agar och sekvenser. Verktyget kan hantera b˚ade ¨andliga och o¨andliga modeller d˚a Modbat inneh˚aller mekanismer f¨or att undvika o¨andliga k¨orningar. Mekanismerna ¨ar en avbrottssannolikhet samt kontroll av upprepade loopar. Avbrottssannolikheten inneb¨ar att det finns en anv¨andardefinierad sannolikhet f¨or att exekveringen av testfallet ska av-brytas vid varje steg i modellen. Testfallet avbryts n¨ar n˚agon av mekanismerna aktiveras eller n¨ar ett fel p˚atr¨affas, vilket inneb¨ar att systemets tillst˚and inte matchar modellens efter ett tillst˚andsbyte. D˚a fel p˚atr¨affats loggar Modbat stegen som ledde fram till felet i en separat fil f¨or just det testfallet.

Modeller f¨or Modbat

Kodexemplet nedan ¨ar h¨amtat fr˚an ett exempel p˚a en Modbatmodell som modellerar en enkel r¨aknare i Java [24]. N¨ar ett testfall k¨ors startar Modbat i det f¨orsta tillst˚andet, i detta fall “reset”, v¨aljs slumpm¨assigt mellan m¨ojliga ¨overg˚angar och k¨or anropen inom klam-merparanteserna. N¨ar Modbat n˚ar ett tillst˚and utan ¨overg˚angar avslutas testet. Modbat inneh˚aller ¨aven mekanismer som preconditions, guards med mera f¨or att i detalj kunna modellera systemet. F¨or ytterligare detaljer kring modelleringsprocessen med Modbat se [24][25].

’reset’ -> ’zero’ := { counter = new SimpleCounter() }

’zero’ -> ’one’ := { counter.inc }

’one’ -> ’two’ := { counter.inc }

’zero’ -> ’two’ := { counter.inc2 }

’two’ -> ’end’ := { assert (counter.value == 2) } 4.2.4 Modell ¨over bankomatsystemet

Modellen som anv¨ands f¨or att testa systemet illustreras i figur 1. Figuren ¨ar en ¨oversikt av modellen som beskriver fl¨odet och de huvudsakliga tillst˚anden. Arbetet med modelleringen presenteras tillsammans med erfarenheterna fr˚an MBT-processen i sektion 4.2.6.

Figur 1: Modell¨oversikt

Modellens olika tillst˚and och ¨overg˚angar representerar testsystemets olika menyer och v¨agar in/ut ur dem. Efter att en ¨overg˚ang traverserats bekr¨aftar modellen en upps¨attning villkor f¨or att se att testsystemet befinner sig i ett f¨orv¨antat giltigt tillst˚and. Hela modellen s˚a som den anv¨ands vid testningen finns i appendix B.

4.2.5 Testplan

F¨oljande punkter valideras under testningen. F¨orst presenteras steg som verifierar att modellen inte indikerar korrekta k¨orningar som fel.

KF-1 Korrekt kombination av pinkod och kontonummer verifieras och systemet g˚ar vidare till n¨asta tillst˚and (main).

KF-2 Inkorrekt kombination av pinkod och kontonummer accepteras ej och systemet st˚ar kvar vid inloggning.

KF-3 Verifiera att korrekta uttag utf¨ors. Aktuella saldon verifieras efter uttag med f¨orv¨antade uppdaterade v¨arden samt att systemet befinner sig i f¨orv¨antat tillst˚and.

KF-4 Verifiera att ins¨attningar utf¨ors korrekt. Aktuella saldon verifieras med f¨orv¨antade nya v¨arden samt att systemet befinner sig i f¨orv¨antat tillst˚and.

KF-5 Verifiera utloggning. Systemet ska ˚aterg˚a till starttillst˚and och eventuella kontoupp-gifter ska vara rensade.

KF-6 Verifiera att utf¨orda ¨andringar lagras mellan ut- och inloggning.

F¨oljande fel introduceras sedan ett i taget:

IF-1 Tillg¨angligt saldo ¨andras ist¨allet f¨or totalt saldo.

IF-2 Vid uttag ur bankomaten r¨aknas antalet sedlar inte ner.

IF-3 Omr¨akningen fr˚an cent till dollar utf¨ors felaktigt.

IF-1 inneb¨ar att bekr¨aftelse av m¨angden inmatade pengar inte utf¨ors, och ist¨allet ¨andras tillg¨angligt saldo p˚a det inloggade kontot direkt. Fallet IF-2 identifieras oavsiktligt under utv¨arderingen av systemet och inneb¨ar att modulen som matar ut sedlar inte r¨aknar ner antalet sedlar vid uttag ur bankomaten. Felet inkluderas d˚a det ¨ar ett reellt exempel ur SUT. IF-3 motsvarar ett enkelt r¨aknefel d¨ar konverteringen fr˚an cent till dollar sker genom att dividera med 10 ist¨allet f¨or 100.

4.2.6 Erfarenheter fr˚an MBT-verktyg, modellering samt implementation Testverktyg och SUT

Processen b¨orjar med att b˚ade Modbat och testsystemet provk¨ors f¨or att bekr¨afta funk-tionen oberoende av varandra. Modbat anv¨ands inledningsvis tillsammans med exemplen ur tillh¨orande dokumentation [24]. En del problem med mjukvaruversioner och kompati-bilitet upplevs h¨ar men g˚ar att l¨osa med hj¨alp av tillh¨orande dokumentation. N¨asta steg

¨ar att validera ett v¨aldigt enkelt egenkonstruerat system och tillh¨orande modell. I det h¨ar steget upplever vi flera olika typer av problem som inledningsvis ¨ar sv˚ara att separera fr˚an varandra.

Det f¨orsta problemet g¨aller att kompilera Scala-modellen tillsammans med systemet. Ef-tersom Modbat k¨ors fr˚an terminalen kompileras ¨aven Java och Scala programmen manuellt d¨ar. Detta leder till att modellen inte hade tillg˚ang till systemet. L¨osningen blir ist¨allet att anv¨anda en integrerad utvecklingsmilj¨o (IDE) f¨or att kompilera modellen och systemet tillsammans och sedan utf¨ora testerna via terminalen och den kompilerade modellen.

Det andra problemet r¨or classpath och inst¨allningarna som beh¨over g¨oras f¨or att exekvera modellen via Modbat. Det h¨ar steget kr¨aver mindre fels¨okning men upplevs trots det inte som trivialt. Sammanfattningsvis g˚ar problemen att l¨osa med hj¨alp av dokumentationen men det kr¨avs tid f¨or varje enskild del.

Provk¨orningen av SUT var i stort oproblematiskt. Detta beror till st¨orsta del p˚a att systemet ¨ar avskalat och enkelt. Eftersom bankomatsystemet ¨ar skrivet helt med Javas standardbibliotek g˚ar det att exekvera redan vid f¨orsta f¨ors¨oket. Inga problem med kom-pabilitet identifierades.

Modellering

Modelleringen sker i tre steg. F¨orst identifierar vi ett ¨overgripande programfl¨ode genom att utforska systemet som anv¨andare. Under en normal process inneh˚aller detta steg gransk-ning av artefakter och krav f¨or att f˚anga f¨orv¨antat beteende hos SUT. I detta fall finns inget kravarbete och f˚a detaljer kring hur och vad systemet ska g¨ora vilket g¨or det sv˚arare att f˚a till r¨att detaljniv˚a i modellen. Bristen p˚a artefakter leder till os¨akerhet kring om hela systemets f¨orv¨antade beteende faktiskt modelleras. Vi ¨overs¨atter det ¨overgripande programfl¨odet till en enkel tillst˚andsmaskin. Tillst˚andsmaskinen beskriver systemet p˚a en h¨og niv˚a motsvarande beskrivningen i figur 1. I det andra steget definierar vi model-lens ¨overg˚angar samt vilken data den beh¨over h˚alla reda p˚a f¨or att verifiera motsvarande v¨arden i SUT. Exempelvis bekr¨aftas vissa tillst˚and genom de v¨arden SUT skickar till ban-komatens sk¨arm. I detta steg arbetar vi mer aktivt mot systemets k¨allkod d˚a det saknas artefakter fr˚an kravprocessen.

Adaptionslager

Det sista steget i modelleringsprocessen innan Modbat kan anv¨andas f¨or att verifiera SUT med hj¨alp av modellen ¨ar att skriva ett adaptionslager, allts˚a att koppla samman modellen och SUT. Detta steg beskrivs ¨overgripande i de flesta verk som f¨orklarar MBT processen men utan n¨armare detaljer. Steget visar sig vara ett av de mest komplicerade att genomf¨ora i praktiken. I stort beh¨over verktyget kunna kontrollera tre saker, vad som visas p˚a bankomatens sk¨arm, indata till systemet via bankomatens emulerade tangentbord och systemets interna v¨arden f¨or bland annat. saldon och sedelr¨akning.

Adaptionslagret implementeras huvudsakligen enligt adaptions-metoden som beskrivs i avsnitt 2.2, allts˚a att en abstraktion skrivs kring systemet f¨or att matcha modellens ab-straktionsniv˚a. Ist¨allet f¨or att kapsla in hela systemet implementeras en klass i bankomaten som f˚ar tillg˚ang till alla ¨ovriga klasser. P˚a detta s¨att kan adaptionsklassen n˚a relevanta data samtidigt som SUT fungerar som tidigare. En del ¨andringar i SUT kr¨avs f¨or att f˚a adaptionsklassen att fungera. Det handlar till st¨orsta del om att ¨andra tillg˚ang och sprida referenser till adaptions-klassen. Detta l¨oser kontroll av systemets v¨arden samt vad som visas p˚a sk¨armen, men inte kontroll ¨over indata.

D˚a systemet emulerar input fr˚an ett numeriskt tangentbord via inmatning av siffror i ter-minalen beh¨over modellen f˚a kontroll ¨over inputstr¨ommen. Inledningsvis l¨oses detta genom att byta ut inputstr¨ommen fr˚an terminalen mot en str¨om inneh˚allande en kontrollerad se-rie indata. Detta fungerar vid inledande f¨ors¨ok men misslyckas vid exekvering av testfallen d˚a det inte till˚ater att dynamisk indata genereras beroende p˚a modellens tillst˚and.

Den l¨osning som ist¨allet anv¨ands ¨ar att koppla bort tangentbords-avl¨asningen fr˚an

ter-minalen och ers¨atta den med indata som kommer fr˚an adaptions-klassen. Detta g¨or att motsvarande indata som en anv¨andare matat in via terminalen kan skickas fr˚an modellen via adaptionsklassen.

Genomf¨orande av tester

F¨or att integrera Modbat, SUT och tillh¨orande modell anv¨ands samma angrepss¨att som vid provk¨orning av Modbat. Systemet och modellen kompileras tillsammans via en IDE och exekveras sedan fr˚an terminalen tillsammans med Modbat f¨or att genomf¨ora tester-na.

Modbat kan effektivt utf¨ora tester och lyckas framf¨orallt utf¨ora serier av tester som an-nars skulle vara osannolika. Eftersom de utf¨orda stegen slumpm¨assigt v¨aljs ut fr˚an m¨ojliga

¨overg˚angar i modellens nuvarande tillst˚and testas ¨aven osannolika serier av inputs, ex-empelvis att saldot kontrolleras upprepade g˚anger i rad eller att felaktiga uttagsv¨arden upprepas g˚ang p˚a g˚ang. Den stokastiska delen g¨or ¨aven att det finns en os¨akerhet om hela systemet exekveras i varje upps¨attning testfall. Verktyget hanterar detta genom att rap-portera andelen ¨overg˚angar och tillst˚and som bes¨okts efter varje exekvering. Ett exempel p˚a hur rapporten f¨or en lyckad k¨orning ser ut finns i figur 2.

Figur 2: K¨orning utan identifierade fel

Figur 3: K¨orning med identifierade fel

I fall d¨ar n˚agot testfall misslyckas genereras en logg-fil inneh˚allande anropen som leder till felet. Detta g¨or att det g˚ar att identifiera var ett fel intr¨affat. Rapporten fr˚an en k¨orning d¨ar fel identiferas visas i figur 3. Ett exempel p˚a tillh¨orande logg-fil finns i figur 4.

Figur 4: Exempel p˚a loggfil vid identifierat fel 4.2.7 Genomf¨orande och utfall enligt testplan

Modbat k¨ors i sviter om 200 test per k¨orning med en avbrottssannolikhet p˚a 2%. ¨Over en upps¨attning av 30 testomg˚angar ger detta ett medelv¨arde p˚a 11.952,5 inputs per omg˚ang (min: 3.894 max: 32.039 sd: 7.403,6). Utfallen enligt testplanen sammanfattas i tabell 3.

Tabell 3: Utfall fr˚an modellbaserad testning

ID Beskrivning Resultat

KF-1 Auktorisera vid korrekt inloggning Inga fel identifieras KF-2 Auktorisera ej vid inkorrekt inloggning Inga fel identifieras KF-3 Verifiera att korrekta uttag utf¨ors. Inga fel identifieras KF-4 Verifiera att ins¨attningar utf¨ors korrekt. Inga fel identifieras KF-5 Verifiera utloggning ur systemet. Inga fel identifieras KF-6 Verifiera datalagring Inga fel identifieras IF-1 Ins¨attning uppdaterar fel saldo Inf¨ort fel identifieras IF-2 Fel i sedelr¨aknaren Inf¨ort fel identifieras ej IF-3 Fel i konvertering mellan cent/dollar Inf¨ort fel identifieras

Alla steg f¨or att verifiera att SUT och Modbat ¨ar integrerade och fungerar tillsammans (KF-1 - KF-6) genomf¨ors utan identifierade fel. N¨ar ett fel introduceras som leder till att fel saldo uppdateras (IF-1) lyckas Modbat identifiera detta med hj¨alp av modellen d˚a den parallella kontrollr¨akningen av saldona i modellen inte ¨overensst¨ammer med saldot i SUT. P˚a samma s¨att identifieras fel i konvertering mellan dollar och cent vid inmatning av sedlar (IF-3). Fel i nedr¨akning av antal sedlar (IF-2) identifieras d¨aremot inte. An-ledningen att IF-2 inte identifieras ¨ar att modellen inte innefattar modulen som hanterar sedelm¨angden.

Inledningsvis rapporterar Modbat fel redan innan n˚agot avsiktligt fel fr˚an testplanen inf¨orts i SUT. Verktyget och tillh¨orande rapporter anv¨ands d˚a f¨or att identifiera en bug vi r˚akat inf¨ora vid anpassningen av systemet f¨or att implementera adaptionslagret. Felet ¨ar

en specifik upps¨attning inputs som under vissa f¨oruts¨attningar leder till att systemet tol-kar indata p˚a ett felaktigt s¨att. Med hj¨alp av fel-loggen kan de specifika f¨oruts¨attningarna identifieras och adaptionslagret korrigeras.

5 Diskussion

5.1 Svar p˚a forskningsfr˚agor

RQ1 - Vilka tecken p˚a anv¨andning av MBT inom industrin kan utl¨asas av publicerade forskningsrapporter?

Endast ett f˚atal praktiska exempel p˚a MBT som testmetod i industrin identifieras. Totalt sju forskningsrapporter kvarst˚ar efter fulltextgranskningen. Tv˚a av dessa ¨ar f¨orsta- och andrahands rapporter p˚a att MBT anv¨ands som testmetod [16][17]. Resterande ¨ar studier d¨ar f¨orfattarna varit med och arbetat med MBT [18][19][20][21][22].

Antalet exempel tyder p˚a att MBT inte har n˚agon st¨orre spridning i mjukvaruindu-strin.

RQ2 - Vilka sv˚arigheter och hinder f¨or att anv¨anda MBT inom industrin finns beskrivna i forskningsrapporterna fr˚an RQ1 och vilka sv˚arigheter och hinder kan hittas i en utforskande fallstudie?

De hinder som identifieras i litteraturstudien ¨ar: modelleringsfel och kravet p˚a att mo-dellen ska vara korrekt f¨or att testerna faktiska ska verifiera SUT [18][19], tids˚atg˚ang och sv˚arigheter med implementation av adaptionslagret [19][20] samt verktygsproblem i form av dyra propriet¨ara l¨osningar eller verktyg d¨ar modellerna saknar kompatibilitet med and-ra verktyg [18].

Aven risken f¨¨ or tillst˚andsexplosioner d¨ar m¨angden testfall blir ohanterbar pekas ut [19].

Sv˚arigheter med hantering av dataunderlag f¨or datadrivna testfall beskrivs av Vieira m.fl.

[21].

Ett icke-tekniskt hinder som lyfts fram av Entin m.fl. ¨ar sv˚arigheten att f˚a med kollegor och ledning vid inf¨orande av MBT. De lyfter vidare fram versionshantering av modeller som ett eventuellt problem d˚a r¨att version av modellen beh¨over matchas med systemet och ¨ovriga artefakter f¨or att kunna reproducera fel [18].

Den utforskande fallstudien bekr¨aftar tre huvudsakliga utmaningar som identifieras i lit-teraturstudien. Den f¨orsta utmaningen r¨or att konstruera modellen s˚a att den korrekt representerar systemets tillt¨ankta beteende.

Den andra utmaningen ¨ar verktygen som anv¨ands f¨or MBT. Upplevelsen av verktyget inf¨or och under utf¨orandet av fallstudien ¨ar att det fungerar f¨or att testa men kr¨aver inledande arbete f¨or att b˚ade utv¨ardera och n˚a stadiet d¨ar de f¨orsta testerna kan utf¨oras.

Detta kan sammanfattas som att anv¨andbarheten upplevs som f¨orh˚allandevis l˚ag vilket g¨or startstr¨ackan on¨odigt l˚ang.

Den sista utmaningen ¨ar att skriva adaptionslagret s˚a att testfallen kan exekveras direkt via modellen. Detta steg ¨ar tidskr¨avande eftersom alla relevanta delar av systemet beh¨over exponeras f¨or verktyget och kan bli v¨aldigt komplicerat. Det finns ¨aven en risk att SUT p˚averkas under implementation av adaptionslagret vilket i sin tur kan p˚averka utfallen av testerna.

Hypotes

Utifr˚an svaren p˚a RQ 1 och RQ 2 kan hypotesen att MBT prim¨art ¨ar av akademiskt intres-se, och att en upps¨attning hinder f¨or bredare anv¨andning kvarst˚ar inte anses falsifierad.

Hypotesen st¨ammer i bem¨arkelsen att det inte kan p˚avisas n˚agon bredare anv¨andning av MBT inom industrin men det finns enstaka exempel.

5.2 Resultat i relation till tidigare forskning

Utting m.fl. drog 2012 slutsatsen att MBT ¨ar redo f¨or storskalig lansering vilket vi inte hittar n˚agra tecken p˚a att ha h¨ant [5]. F˚atalet reella till¨ampningar av MBT som identi-fieras tyder p˚a att MBT inte anv¨ands i den utstr¨ackning som motsvarar den akademiska litteraturen inom omr˚adet. Precis som Khan m.fl. p˚apekar finns det m˚anga exempel p˚a fallstudier d¨ar MBT ser ut att anv¨andas i ett verkligt sammanhang [12]. Dessa ¨ar i de flesta fall exempel d¨ar f¨orfattarna har en koppling till organisationen som ¨ager systemet, alternativt l˚anar ett system, och inneb¨ar utv¨ardering av MBT snarare ¨an till¨ampning av MBT som testmetod.

Detta leder till fr˚agor kring varf¨or inte fler exempel p˚a d¨ar MBT till¨ampas som testmetod kunde identifieras. Ett sk¨al kan vara att industrin saknar tillr¨acklig anledning att byta angreppss¨att och hantera den omst¨allning och barnsjukdomar som medf¨oljer. Santos m.fl.

drar slutsatsen att forskare ¨ar mer intresserade av nya metoder och verktyg medan verk-samma inom industrin ¨ar mer intresserade av f¨orb¨attring av befintliga arbetss¨att [13].

Detta st¨ammer med slutsatserna kring m¨anniskornas roll vid inf¨orandet av MBT och vik-ten av att kollegor och ledning ¨ar med, som Entin m.fl. tar upp. Om intresset ¨ar l˚agt ¨ar det sv˚art f¨or en metod att f˚a genomslag [18]. ¨Aven Weißleder och Schlingloff konstaterar att det ¨ar sv˚art att hitta tid och pengar f¨or nya arbetss¨att [4]. Villalobos-Arias m.fl. drar slutsatsen att bristande tillg¨anglighet hos MBT ¨ar det st¨orsta hindret [7].

De tre eventuella problemomr˚aden vi identifierar i den utforskande fallstudien ¨ar i stort i linje med tidigare forskning. MBT-verktyget fungerar men ¨ar sv˚ara att komma ig˚ang med.

Detta p˚apekar ¨aven Marijan m.fl. och argumenterar f¨or att verktygen beh¨over bli mer anv¨andarv¨anliga och till˚atande [10]. Weißleder och Schlingloff tar upp os¨akerheten kring hur v¨al verktygen fungerar vid st¨orre industriella till¨ampningar [4]. Entin m.fl inst¨ammer i kritiken av verktygen och menar att kommersiella verktyg ¨ar dyra och att befintliga verktyg inte ¨ar tillr¨ackligt kompatibla med varandra i fall d¨ar modellen eller verktyget beh¨over bytas ut [18].

D¨aremot anser vi inte att detta ¨ar det st¨orsta problemet i ett l¨angre perspektiv och kan variera beroende p˚a verktyg. N¨ar verktyget v¨al ¨ar ig˚ang fungerar det utan problem. Ist¨allet upplever vi att integrationen mellan modellen och SUT som ett st¨orre problem. Ganesan m.fl. beskriver fel vid implementation av adaptionslagret som ett hinder [19]. Wendland m.fl. pekar ut tids˚atg˚angen f¨or att f˚a adaptionslagret att fungera som ett problem [20].

Vidare riskerar ¨andringar i SUT att introducera nya buggar och kan d¨armed p˚averka de delar som faktiskt ska verifieras.

Det sista och sv˚araste problemomr˚adet vi identifierar g¨aller abstraktionen som sker via modellen. Det faktum att flera av testerna utf¨ors utan att felet med sedelr¨aknaren identi-fieras visar tydligt hur k¨ansligt MBT ¨ar f¨or felaktiga modeller. I v˚art fall kan utel¨amnandet

delvis f¨orklaras av avsaknaden p˚a en kravspecifikation och ¨ovriga artefakter som vanligt-vis anv¨ands f¨or att konstruera modellen. Detta st¨ammer med vad Ganesan m.fl. beskriver som problem g¨allande modellering av system med odokumenterade krav [19]. B˚ade En-tin m.fl. och Ganesan m.fl. rapporterar exempel p˚a modelleringsfel under MBT-arbetet [18][19].

Enkelheten att utf¨ora en stor m¨angd tester n¨ar modellen och systemet var integrerade indikerar f¨ordelar med MBT som testmetod. Det ¨ar ¨aven enkelt att exekvera en stor m¨angd automatiskt genererade testfall, fr˚agan hur stor andel av dessa som faktiskt ¨ar v¨ardefulla ¨ar d¨aremot inte besvarad.

Under litteraturgenomg˚angen observerade vi ¨aven att n˚agra f¨orfattargrupper f¨orekommer upprepade g˚anger i olika konstellationer. Dessa grupper st˚ar bakom en stor andel av de publicerade verken vilket v¨acker fr˚agor kring huruvida intresset f¨or MBT ¨ar s¨arskilt ut-spritt utanf¨or kretsen som forskar p˚a utveckling av metoden.

5.3 Metoddiskussion

Metoden att leta i akademisk litteratur efter icke-akademiska till¨ampningar g˚ar att ifr˚agas¨atta.

Det ¨ar m¨ojligt att det finns exempel p˚a till¨ampning av MBT i industrin som ¨ar publice-rad i andra kanaler. Alternativt kan anv¨andningen vara opublicerad. Vidare ¨ar det i vissa forskningsrapporter inte sj¨alvklart om till¨ampningen ¨ar prim¨art fokuserad p˚a att testa mjukvara eller validera MBT. Till f¨oljd av detta p˚averkar tolkningen av inklusionskriteri-erna vilka studier som inkluderas.

Det ¨ar m¨ojligt att det finns exempel p˚a till¨ampning av MBT i industrin som ¨ar publice-rad i andra kanaler. Alternativt kan anv¨andningen vara opublicerad. Vidare ¨ar det i vissa forskningsrapporter inte sj¨alvklart om till¨ampningen ¨ar prim¨art fokuserad p˚a att testa mjukvara eller validera MBT. Till f¨oljd av detta p˚averkar tolkningen av inklusionskriteri-erna vilka studier som inkluderas.