• No results found

Testdesign och utförande (“N”) SG 1

In document Examensarbete Kandidatexamen (Page 49-71)

- Se över och jämför testernas faktiska framsteg gentemot testplanen (TMMi-Foundation, 2018, s. 48). Ett exempel är att ha ett tidschema för varje sprint som uppskattas i testplanen.

PA 2.4 - Testdesign och utförande (“N”) SG 1

- Testförhållanden och testfall är identifierade och prioriterade med hjälp av testdesigntekniker. Enligt analysen så används ingen testdesignteknik idag. Dokumentera testförhållandena och testfall i en specifikation för testdesign. Se IEEE 829 (2008) för exempel av specifikation av testdesign (TMMi-Foundation, 2018, s. 59).

SG 2

- Röktester utförs i början av testutförandet för att kontrollera om testobjektet är redo för detaljerad och vidare testning. Analysen indikerar att sådan inte används i någon större utsträckning. Definiera en lista över kontroller som ska utföras under röktestet med hjälp av

inmatningskriterierna enligt definitionen i testplanen. Exempel på vad röktest ska innefatta: - Alla nödvändiga huvudfunktioner är tillgängliga.

- Representativa funktioner är tillgängliga och fungerar, där systemet valideras mot giltig inmatningsdata.

- Gränssnitt med andra komponenter eller system som testas fungerar.

- Dokumentationen är fullständig för den tillgängliga funktionaliteten, t.ex. anteckningar om releasen, användarmanual, installationsmanual.

(TMMi-Foundation, 2018, s. 62)

- Ett schema över testutföranden där intressenter är inblandade. Testutföranden ska efter ett schema utföras utefter deras prioriteringsnivå. (TMMi-Foundation, 2018, s. 62)

SG 3

- Testloggar enligt IEEE 829 (2008) kan skrivas, vilket ska bestå av en testlogg-identifierare, objekt som testas, miljö där testningen har utförts, exekveringsbeskrivning, testresultat, avvikelser och incidentrapport-identifierare. Testloggen ska sedan granskas med intressenter.

(TMMi-Foundation, 2018, s. 64)

PA 2.5 - Testmiljö (“N”) SG 2

- Se rekommendationerna för röktester i PA 2.4, SG 2. Röktestet för testmiljön utförs för att bestämma om testmiljön är redo att användas för testning. Definiera en lista över kontroller som ska utföras under röktestet i testmiljön. Utveckla testmiljöns röktestprocedur baserat på de kontroller som identifierats genom sätta testfall i en körbar ordning och inkluderar all annan information som behövs för utföra röktestet. Dokumentera testmiljöens röktestprocedur i en specifikation för testproceduren, baserad på specifikationens standard för testproceduren. Granska specifikationen för testproceduren för röktester med intressenter.

Se över testproceduren för röktester för testmiljön vid behov. (TMMi-Foundation, 2018)

43

5 Slutsats

Slutsatsen avser att med vad vi kommit fram till från de föregående kapitlen besvara frågeställningarna under problemformuleringen

Står TIM upp mot dagens form av agil konsultverksamhet?

Det är enligt Ning Chen (2013):s slutsats ihop med vår bedömning av teamet möjligt att applicera TIM:s delar i KPA:n i det agila tänket. Det som Ning Chen (2013) beskriver är att testförbättringsmodeller förklarar vad som ska göras, likaså standarden IEEE-829 som TIM hänvisar till, medan det agila

arbetssättet förklarar hur det ska göras. För att kartlägga vad som behövs i vilken del, baserat på vad som beskrivs om de agila delarna i kapitel 2.7, så har följande tabell (tabell 6) framtagits:

44

Hur skiljer sig dessa modeller (TIM och TMMi)?

Som tidigare nämnt så har Ericson et. al. (1997) valt att skapa sin modell i ett mer modulerat sätt. Detta leder till att det studerade teamet kan med mognadsprofilen framför sig (se figur 8) utifrån det besluta för sig själva vilken KPA de vill förbättra eller kanske lyfta de styrkor som finns, som i teamets fall är Testware. TMMi-Foundation (2018) har valt att TMMi ska följa ett "allt eller inget"-tillvägagångssätt, vilket innebär att alla objekt inom en viss mognadsnivå måste uppnås innan nästa kan nås. Beroende på behov kan TIM:s struktur vara mer gynnsamt för teamet.

TIM är dock ospecificerad i vad som bör förbättras och går inte in för djupt i exempel, till skillnad från TMMi som har valt att lista arbetssätt och produkter kring dessa arbetssätt (t.ex. PA 2.1, SG 1, SP1.1, där de specificerar vad som innefattas i “test goals”, såsom “Mission Statement”, “Business Drivers” etc. (TMMi-Foundation, 2018)).

Hur skiljer sig rekommendationerna åt mellan modellerna?

Den största skillnaden av rekommendationer som vi kom fram till är att TIM rekommenderar att ha en enskild testare, och helst ett team av testare, redan från första nivån. Risken att ha en testare i så tidigt stadie för TIM kan leda till att teamet i praktiken inte hinner med att anpassa sin arbetsmetod mot en mer testanpassad metod. TMMi har fördelen att introducera arbetsmetoderna innan testare kommer in i bilden, som för det studerade teamet skulle leda till att gå från självständighetsgrad 1 till 3 på en gång. Med TMMi:s gradvisa introduktion av arbetsmetoder så avancerar teamet sakta men säkert från

självständighetsgrad 1 till 2.

TMMi introducerar testare först på mognadsnivå 3 under processområdet om testorganisationer (se bilaga 4, PA 1, SG 3), vilket avser bland annat att identifiera och organisera en grupp högt kvalificerade

människor ansvariga för testning (TMMi-Foundation, 2018, sid 78).

Betydelsen av att utföra röktester var något som TMMi lade vikt på medan TIM saknade aktiviteter för det. Resultatet visade att röktester inte var något som teamet beaktade och bedömningen ledde därför till en lägre klassificering på grund av de processområden som innefattade röktester (Testdesign och utförande och Testmiljö). Det främsta fokuset baserat på TMMi:s rekommendationer är att teamet behöver utföra fler dokumenterade röktester inom testning.

45

6 Diskussion

I detta kapitel presenteras reflektioner för studien. Dessutom tas förslag till vidare forskning upp.

En av orsakerna till att studera fler testförbättringsmodeller härstammar från Cosic & Antonios (2012) diskussion gällande framtida forskning. Vi såg möjligheten att erbjuda en genomarbetad analys mellan TIM och TMMi i praktiken, vars modeller inte tidigare har ställts mot varandra utan som istället har staplats upp i samband med andra modeller. Vår uppfattning är att det har getts en mer teoretisk synvinkel utifrån dessa rapporter, medan vår erbjuder en praktisk synvinkel i skillnaden kring TIM och TMMi.

Eftersom vi är lekmän (studenter) som utgår från den kostnadsfria dokumentationen för TMMi så innebar det en sorts informell bedömning hos konsultverksamheten och vi är medvetna om att den avviker från hur en ackrediterad bedömare skulle utföra den. Det går med tidigare erfarenhet och utbildning inom TMMi bli granskad med den informella bedömningen av en ackrediterad panel för att få en certifiering hos TMMi-Foundation (TMMi-Foundation, 2018).

En reflektion för datainsamlingsmetoderna är kring enkäter. Trots testpiloter för enkäterna så räknade vi med att det fanns en risk att medlemmarna i teamet inte alltid förstod påståendena och att det kunde resultera i osäker data. Det kunde handla om en tolkningsfråga kring vissa påståenden på grund av att de var i vissa fall vaga eller tvetydiga. En anledning till varför de inte riktigt kunde begripa sig på samtliga påståenden var isåfall bristen på ett fördjupat fokus på just testning för konsultverksamheten. Det var en utmaning att försöka ta sig runt detta eftersom vi har haft modellerna i sig att luta oss på och så som de är formulerade. Därför var intervjuer ett passande komplement till enkäter. Vi har haft en del data att tolka och har ansträngt oss för att presentera den på ett lämpligt sätt.

Vidare till TIM så märks det en viss tidsskillnad i hur Ericson, et. al. (1997) har valt att lägga stort fokus på att göra allt datorbaserat. Med tanke på att denna modell skapades i slutet av 90-talet och den agila metoden grundades 2001 så kan det vara enkelt att nämna att dessa inte passar ihop. Men som nämnt tidigare så funkar TIM förvånansvärt bra gentemot den agila metoden. Det beror främst på att TIM bara fokuserar på vad som ska göras, som till skillnad från den agila modellen som har fokus på hur det ska göras.

Konsultverksamhetens anonymitet var av etiska skäl nödvändigt. En låg mognadsnivå, även om den är informell, bedömdes kunna leda till ett bortfall av potentiella kunder om de var offentliga i rapporten. Avgränsningen för studien kring att bara studera den andra mognadsnivån av TIM och TMMi hos teamet var ett risktagande trots att vi gjorde en beräknad gissning baserat på uppstartsmötet. Studiens befintliga upplägg för dataanalysen hade inte varit hållbart om fler nivåer var inkluderat i studien. Det hade krävts ett helt annat tillvägagångsätt i hur enkät- och intervjufrågor var utformade för att vara mer anpassad för fler mognadsnivåer. Ett alternativ hade varit att väva in fler snarlika aktiviteter från samtliga

mognadsnivåer i ett påstående, fast det hade också behövts ett mer omfattande arbete senare vid dataanalysen.

46

Förslag på vidare forskning

Eftersom studien enbart täckte upp mognadsnivå 2 för TMMi och mognadsnivå 1 för TIM hos en konsultverksamhet så kan det bli ännu mer relevant om det utförs en jämförande studie då mot en

verksamhet som arbetar med till exempel utveckling av labbutrustning, som då sträcker sig över samtliga mognadsnivåer. I den verksamheten där buggar kan vara kritiska, om inte livshotande. Förslagsvis så ska en ackrediterad bedömare utföra denna bedömning så att den blir formell.

47

7 Referenser

Afzal, Wasif & Alone, Snehal & Glocksien, Kerstin & Torkar, Richard. (2015). Software test process improvement approaches: A systematic literature review and an industrial case study. Journal of Systems and Software. 1-33.

Atlassian Jira Software - Features (u.å.). Hämtad den 2020-05-07 från https://www.atlassian.com/software/jira/features

Atlassian (2018). A preview of the new agility boards jira software. Hämtad 2020-05-11 från https://www.atlassian.com/blog/jira-software/preview-new-agility-boards-jira-software Atlassian Software Support (u.å.). Hämtad den 2020-05-20 från

https://confluence.atlassian.com/jirakb/using-jira-software-for-test-case-management-136872198.html Axelos (2016) What is configuration management. Hämtad den 2020-05-12 från

https://www.axelos.com/news/blogs/november-2016/what-is-configuration-management

Björklund, Maria & Paulsson, Ulf (2012) Seminarieboken – att skriva, presentera och opponera. Lund: Studentlitteratur.

Burnstein, I. (2003). Practical Software Testing: A Process Oriented Approach (1. ed.). Springer. Chicago. Relevant längre? Varför?

Burnstein I., Suwanassart T., and Carlson C. (1996). Developing a Testing Maturity Model. Part 1. Crosstalk, Journal of Defense Software Engineering, 9, no. 8, 21–24. Hämtad den 2020-05-14 från https://pdfs.semanticscholar.org/ebd7/7d4611876e981ab41a559b977525378d63c6.pdf

Burnstein I., Suwanassart T., and Carlson C. (1996). Developing a Testing Maturity Model. Part 2. Crosstalk, Journal of Defense Software Engineering, 9, no. 8, 21–24. Hämtad den 2020-04-20 från https://pdfs.semanticscholar.org/ebd7/7d4611876e981ab41a559b977525378d63c6.pdf

Camargo et al. (2013) Identifying a Subset of TMMi Practices to Establish a Streamlined Software Testing Process. 27th Brazilian Symposium on Software Engineering, pages 137–146.

Chen, N. (2013). std 829-2008 and Agile Process – Can They Work Together?

Hämtad den 2020-06-07 från https://www.semanticscholar.org/paper/std-829-2008-and-Agile-Process-%E2%80%93-Can-They-Work-Chen/a2070c4a9467bc62f07835400351e70de3454116

Cosic A., Antonio M., (2012). Processförbättring med hjälp

av TMMi-Modellen - Utvärdering av en testprocess på ett medelstort Företag. Linnéuniversitet. Hämtad den 2020-04-20 från http://lnu.diva-portal.org/smash/get/diva2:566607/FULLTEXT01.pdf

Devinti.com (u.å.). Requirements Traceability Matrix is not only for requirements. Hämtad den 2020-05-09 från Https://deviniti.com/atlassian/requirements-traceability-matrix-jira/

Ericson, T., Subotic, A., & Ursing, S. (1997). TIM—a test improvement model. Software Testing, Verification and Reliability, 7(4), 229-246.

Eriksson, U. (2008). Kravhantering för IT-system.(2. uppl.) Lund: Studentlitteratur.

Fowler, M., & Highsmith, J. (2001). The Agile Manifesto. Software Development, 9(8), 28-35. GIT (u.å). Hämtad den 2020-05-13 från https://git-scm.com/.

48 Graham, B & Van Veenendaal, E. (2014). Improving the Test Process. Implementing Improvement and Change – A Study Guide for the ISTQB Expert Level Module. Rocky Nook, Inc.

Graham, D., Van Veenendaal, E., & Evans, I. (2008). Foundations of software testing: ISTQB certification. Cengage Learning EMEA.

Hagman D., Andersson A. (2009). En analys av testprocesser med TMap som testmetod. Högskolan Dalarna. Hämtad den 2020-04-20 från

http://du.diva-portal.org/smash/get/diva2:518657/FULLTEXT01.pdf

Hindi F. (2013). Beskrivning och jämförelse av testverktyg - Ett underlag för val av testverktyg. Högskolan Dalarna. Hämtad den 2020-05-23 från

https://www.diva-portal.org/smash/get/diva2:626450/FULLTEXT02.pdf

K. Hrabovská, N. Šimková, B. Rossi, and T. Pitner (2019). Smart grids and software testing process models”. Hämtad den 2020-06-03 från

https://www.researchgate.net/publication/335362815_Smart_Grids_and_Software_Testing_Process_Mod els

IEEE (u.å.). Hämtad den 2020-05-13 från https://www.ieee.org/

IEEE (1983). Standard for Software Test Documentation. Hämtad den 2020-06-07 från https://ieeexplore.ieee.org/document/573169

IEEE (2008). Standard for Software and System Test Documentation (IEEE 4578383:2008). Hämtad den 2020-05-13 från https://ieeexplore.ieee.org/document/4578383

ISO/IEC 15504 (2012). Information technology – Process assessment. Hämtad den 2020-05-14 från https://www.iso.org/standard/60555.html

ISTQB Glossary (u.å). Hämtad den 2020-05-23 från https://glossary.istqb.org/se/term/rktest-1 Jacobs, J., Moll, J.V., & Stokes, T. (2000). The Process of Test Process Improvement. XOOTIC MAGAZINE, 8(2), 23-29. Hämtad den 2020-04-18 från

https://www.researchgate.net/publication/252741924_The_Process_of_Test_Process_Improvement Lynn, R (u.å.) Kanban vs. Scrum: What are the differences? Hämtad 2020-06-06 från

https://www.planview.com/resources/articles/kanban-vs-scrum/

Mowat, P. (2017). TMMi, Accenture Test Assessment Framework and Agile Assessments are the same, are they not PoV? Hämtad den 2020-05-08 från

https://www.tmmi.org/tm6/wp-content/uploads/2016/08/TMMi-ATAF-Agile-Assessmentx.pdf

Nayab, N. (2010). "The Difference Between CMMI vs CMM". Bright Hub PM. Hämtad den 2020-04-06 från https://www.brighthubpm.com/certification/69744-cmmi-vs-cmm-which-is-better/

Oates, B. J. (2006). Researching information systems and computing. Sage.

SmartSheet (2020) What’s the Difference? Agile vs Scrum vs Waterfall vs Kanban. Hämtad 2020-06-07 från https://www.smartsheet.com/agile-vs-scrum-vs-waterfall-vs-kanban

Sogeti. (u.å.). Test Process Improvement. Hämtad den 2020-06-03 från https://www.sogeti.se/losningar/test/tpi/

49 Techopedia (u.å.). IEEE-829. Hämtad den 2020-06-06 från

https://www.techopedia.com/definition/4487/ieee-829

TMMi-Foundation (2018). TMMi Framework R1 2. Ireland: TMMi Foundation. TMMi-Foundation. (2014). TMMi Assessment Method Application Requirements (TAMAR). Hämtad den 2020-04-17 från

http://www.tmmifoundation.org/downloads/tmmi/TMMi.TAMAR.pdf

Tryqa (u.å.). Software testing process improvement models – TMMi, TPI Next, CTP, STEP. Hämtad den 2020-05-20 från http://tryqa.com/software-testing-process-improvement-models-tmmi-tpi-next-ctp-step Wells, B. (2005). A Standard Test Process Assessment Method? The case for Test Maturity

Model! Hämtat den 2020-06-01 från http://nikilabs.com/onewebmedia/TMMi_Overview.pdf

Wiley Online Library (u.å.). Author Guidelines - Software Testing, Verification and Reliability. Hämtad den 2020-04-20 från https://onlinelibrary.wiley.com/page/journal/10991689/homepage/forauthors.html

50

8 Bilagor

Bilaga 1

Kortfattat om de olika aktiviteterna som måste fullföljas för att en KPA ska nå en viss nivå.

Organisation

Baseline (Level 1) Testning sker i enlighet med dokumenterad standard.

Det finns en testledare och ett testteam. Cost-effectiveness (Level 2) Testningsfunktionen är samlokerade.

Nyckelpersoner arbetar fulltid på ett projekt och resurser (personer) är inte delade mellan projekt.

Enskilda testfunktioner.

Team strukturen är baserad på resurs inventering och projekt behov.

Ansvar är definierade, dokumenterade och förstådda.

Träning av personal möter organisationens behov.

Risk-lowering (Level 3) Testkänsliga resursallokeringar och uppgift planering görs på alla nivåer. Testfunktionen strävar efter stöd från ledning

Testare involveras i alla utvecklingsfaser och utvecklare involveras i testningen. Personal roterar mellan utveckling och testning.

Optimizing (Level 4) Testare är en del av multidisciplinära team.

Kontinuerlig förbättring på organisationsnivå.

Grupper för dessa förbättringar har etablerats.

51

Planering och sökning

Baseline (Level 1) Grundläggande planering genomförs. Start- och slutkriterier sätts för alla testnivåer.

Testresultat dokumenteras och distribueras.

Planer är utförda efter standarder och avvikelser dokumenteras.

Planering är utfört enligt dokumenterat policy.

Planer förändras med kraven.

Förändringar i testplanen är gjord efter dokumenterad policy.

Cost-effectiveness (Level 2) Planering och uppföljning sker digitalt. Generiska planer används.

Valen av testmetoder och testnivåer balanseras mot testobjekt och testuppgifter.

Framsteg är mätta och jämförda mot planerna.

Planering är utfört av en tränad testare eller planerare.

Planering är utfört på ett evolutionärt sätt. Resursförutsägelse är gjord efter

dokumenterad policy.

Risk-lowering (Level 3) Riskanalys är utförd och influerar planering och resursplacering. Påverkade parter godkänner planer, inklusive test objekt.

Fullföljande av testobjekt är dokumenterat. Planering är utförd av en erfaren planerare och/eller testare.

Planer ändras med faktiska omständigheter.

Optimizing (Level 4) Modeller för kostnad, resurs, risk etc. är gjorda.

Planering och uppföljning av aktiviteter är kontinuerligt förbättrade baserat på analyser och erfarenheter.

Efterundersökning är gjorda och resultat utdelade.

Testfall

Baseline (Level 1) Testfall blir reviderade när kraven ändras. Testfall baseras på kraven.

52 Testfall är designade och dokumenterade

enligt dokumenterad policy före genomförande.

Testfall genomförs efter dokumenterade instruktioner.

Cost-effectiveness (Level 2) Testfall är designade via dokumenterade tekniker.

Testbarhet influerar krav och design. Testfall är organiserade efter testnivå, krav, test objekt, uppgifter osv.

Risk-lowering (Level 3) Testfall är rankad och vald beroende på den kritiska nivån den har.

Testfall är designade till svars på riskområden.

Optimizing (Level 4) Testfallsdesigntekniker är mätta, granskade och förbättrade.

53

Testware

Baseline (Level 1) Problem rapportering sker via dator. Filsystem används för “configuration management”.

Cost-effectiveness (Level 2) Datorstöd för problemspårning, kod spårning och testutförande.

Datorstöd för testfallsresultatinsamling, inspelning, bearbetning och rapportering. Verktyg för täckningsanalys används. Hårdvaru- och mjukvarusystem är simulerade.

Databaser används för “configuration management” av testware.

Testverktyg evalueras före de är köpta och används.

Statistikverktyg används för t.ex. kodgranskning.

Risk-lowering (Level 3) Datorstöd för riskanalys.

Testware och mjukvara hanteras under effektiv “configuration management”. Datorstöd för regressiontesting. Bara “mogen” teknologi används. Optimizing (Level 4) Datorstöd för resultatskontroll och

54

Reviews

Baseline (Level 1) Krav är granskade.

Granskningsansvarig och ledning är given träning inom granskningstekniker.

Träning och stöd är inköpta för första projektet.

Standardiserade och dokumenterade granskningstekniker används.

Cost-effectiveness (Level 2) Alla granskningsanställda ges träning i granskningstekniker.

Checklistor, scenarios etc. är anpassade och använda.

Design- och koddokument är granskade. Organisationen har några

granskningstekniker att välja mellan. Risk-lowering (Level 3) Testware och testfall är granskade.

Granskningstekniker är evaluerade. Granskningsprocesser, produkter och resurser är mätta.

Granskningstekniker är kontinuerligt förbättrade.

Val av team och teknik är baserade på fakta.

Optimizing (Level 4) Granskningstekniker är kontinuerligt förbättrade.

Utval av team och teknik baseras på fakta. (Ericson, et. al., 1997)

55

Bilaga 2

Utdrag från Afzal, W, et. al. (2015)

Teckenförklaringar

Streckad pil = baserad på/influerad av standarder, tillvägagångssätt för processförbättring, teorier, modeller och paradigm.

56

Bilaga 3

Nedan visas de fem nivåerna för TMMi-modellen.

57

Bilaga 4

Följande text är en förteckning över TMMi:s mognadsnivåer och underkategorier, så som specifika aktiviteter, på engelska.

Level 2 - Managed

PA 2.1 Test Policy and Strategy SG 1 Establish a Test Policy

SP 1.1 Define test goals SP 1.2 Define test policy

SP 1.3 Distribute the test policy to stakeholders SG 2 Establish a Test Strategy

SP 2.1 Perform a generic product risk assessment SP 2.2 Define test strategy

SP 2.3 Distribute the test strategy to stakeholders SG 3 Establish Test Performance Indicators

SP 3.1 Define test performance indicators SP 3.2 Deploy test performance indicators PA 2.2 Test Planning

SG 1 Perform a Product Risk Assessment

SP 1.1 Define product risk categories and parameters SP 1.2 Identify product risks

SP 1.3 Analyze product risks SG 2 Establish a Test Approach

SP 2.1 Identify items and features to be tested SP 2.2 Define the test approach

SP 2.3 Define entry criteria SP 2.4 Define exit criteria

SP 2.5 Define suspension and resumption criteria SG 3 Establish Test Estimates

SP 3.1 Establish a top-level work breakdown structure SP 3.2 Define test lifecycle

SP 3.3 Determine estimates for test effort and cost SG 4 Develop a Test Plan

SP 4.1 Establish the test schedule SP 4.2 Plan for test staffing

SP 4.3 Plan stakeholder involvement SP 4.4 Identify test project risks SP 4.5 Establish the test plan SG 5 Obtain Commitment to the Test Plan

SP 5.1 Review test plan

SP 5.2 Reconcile work and resource levels SP 5.3 Obtain test plan commitments PA 2.3 Test Monitoring and Control

SG 1 Monitor Test Progress against Plan

SP 1.1 Monitor test planning parameters

SP 1.2 Monitor test environment resources provided and used SP 1.3 Monitor test commitments

58 SP 1.4 Monitor test project risks

SP 1.5 Monitor stakeholder involvement SP 1.6 Conduct test progress reviews

SP 1.7 Conduct test progress milestone reviews SG 2 Monitor Product Quality against Plan and Expectations

SP 2.1 Check against entry criteria SP 2.2 Monitor defects

SP 2.3 Monitor product risks SP 2.4 Monitor exit criteria

SP 2.5 Monitor suspension and resumption criteria SP 2.6 Conduct product quality reviews

SP 2.7 Conduct product quality milestone reviews SG 3 Manage Corrective Action to Closure

SP 3.1 Analyze issues SP 3.2 Take corrective action SP 3.3 Manage corrective action PA 2.4 Test Design and Execution

SG 1 Perform Test Analysis and Design using Test Design Techniques SP 1.1 Identify and prioritize test conditions

SP 1.2 Identify and prioritize test cases SP 1.3 Identify necessary specific test data

SP 1.4 Maintain horizontal traceability with requirements SG 2 Perform Test Implementation

SP 2.1 Develop and prioritize test procedures SP 2.2 Create specific test data

SP 2.3 Specify intake test procedure SP 2.4 Develop test execution schedule SG 3 Perform Test Execution

SP 3.1 Perform intake test

In document Examensarbete Kandidatexamen (Page 49-71)

Related documents