Certifierad Testare Avancerad Nivåh24-files.s3.amazonaws.com/65073/161755-QK37m.pdf · Certifierad...

Certifierad Testare

Avancerad Nivå

Version 2007 2010-02-01

International Software Testing Qualifications Board

Swedish Software Testing Board

Copyright Detta dokument får kopieras i delar eller i sin helhet om källan anges

Certifierad Testare Kursplan avancerad nivå

Svensk Version 2007 Sid 2 (125) Feb 2010

© International Software Testing Qualifications Board

Copyright © International Software Testing Qualifications Board (hädanefter kallad ISTQB®). Den engelska versionen är framtagen av: Bernard Homès (ordförande), Graham Bath, Rex Black, Sigrid Eldh, Jayapradeep Jiothis, Paul Jorgensen, Vipul Kocher, Judy McKay, Klaus Olsen, Randy Rice, Jürgen Richter, Eric Riou Du Cosquer, Mike Smith, Geoff Thompson, Erik Van Veenendaal; 2006-2007. Översättning till svenska: Love Amcoff, Gunnel Barkeby, Mats Grindal, Erik Johansson, Stefan Nilsson, Ingela Skytte; 2009.




Revisionshistoria

Version Datum Kommentar

R1.0 2010-02 Första frisläppta versionen av den svenska versionen av ISTQB: Certified Tester, Advanced Level, Version 2007

v 2007 2011-03 Ändrat versionsnamn så att det överensstämmer med Syllabus versionsnamn. Sidfot uppdaterad till ”Svensk Version 2007”. Ändrat filnamn till Kursplan AL v 2007. Inga andra ändringar




Innehållsförteckning Revisionshistoria ..................................................................................................................................... 3 Innehållsförteckning ................................................................................................................................. 4 Tillkännagivanden .................................................................................................................................... 8 0. Introduktion till Denna Kursplan .......................................................................................................... 9

0.1 International Software Testing Qualifications Board ..................................................................... 9 0.2 Förväntningar .............................................................................................................................. 12

0.2.1 Avancerad Nivå: Testledare ................................................................................................ 12 0.2.2 Avancerad Nivå; Testanalytiker ........................................................................................... 12 0.2.3 Avancerad Nivå: Teknisk Testanalytiker ............................................................................. 12

0.3 Inlärningsmål/Kunskapsnivåer .................................................................................................... 13 0.4 Inlärningsmål för Testledare........................................................................................................ 15 0.5 Inlärningsmål för Testanalytiker .................................................................................................. 19 0.6 Inlärningsmål för Tekniska Testanalytiker ................................................................................... 22

1. Grundläggande Principer för Programvarutestning ........................................................................... 26 1.1 Inledning ...................................................................................................................................... 26 1.2 Testning i Programvarans Livscykel ........................................................................................... 26 1.3 Speciella System ......................................................................................................................... 28

1.3.1 System av System ............................................................................................................... 28 1.3.2 Säkerhetskritiska System .................................................................................................... 29

1.4 Mätetal & Mätning ....................................................................................................................... 30 1.5 Etik .............................................................................................................................................. 31

2. Testprocesser .................................................................................................................................... 32 2.1 Inledning ...................................................................................................................................... 32 2.2 Testprocessmodeller ................................................................................................................... 32 2.3 Testplanering & Teststyrning ...................................................................................................... 33 2.4 Testanalys & Testdesign ............................................................................................................. 33

2.4.1 Identifiering av Testvillkor .................................................................................................... 33 2.4.2 Framtagning av Testfall ....................................................................................................... 34

2.5 Testimplementering & Exekvering .............................................................................................. 35 2.5.1 Testimplementering ............................................................................................................. 35 2.5.2 Testexekvering .................................................................................................................... 36

2.6 Utvärdering av Avslutskriterier och Rapportering ....................................................................... 37 2.7 Testavslutningsaktiviteter ............................................................................................................ 38

3. Testledning ........................................................................................................................................ 40 3.1 Inledning ...................................................................................................................................... 40 3.2 Testledningsdokumentation ........................................................................................................ 40

3.2.1 Testpolicy ............................................................................................................................. 40 3.2.2 Teststrategi .......................................................................................................................... 41 3.2.3 Övergripande Testplan ........................................................................................................ 42 3.2.4 Nivåtestplan ......................................................................................................................... 43

3.3 Mallar för Dokumentation av Testplaner ..................................................................................... 43 3.4 Testestimering ............................................................................................................................. 43 3.5 Schemaläggning av Testplanering .............................................................................................. 45 3.6 Övervakning & Styrning av Testprogress ................................................................................... 45 3.7 Testningens Värde för Affärsverksamheten ................................................................................ 46 3.8 Distribuerad Testning .................................................................................................................. 47 3.9 Riskbaserad Testning ................................................................................................................. 48

3.9.1 Inledning .............................................................................................................................. 48 3.9.2 Riskhantering ....................................................................................................................... 49 3.9.3 Riskhantering i Programvarans Livscykel ............................................................................ 52

3.10 Failure Mode and Effects Analysis (FMEA) .............................................................................. 52 3.10.1 Användningsområden ........................................................................................................ 53




3.10.2 Implementeringssteg ......................................................................................................... 53 3.10.3 Nytta & Överväganden ...................................................................................................... 53

3.11 Att Tänka på vid Testledning..................................................................................................... 53 3.11.1 Testledning av Utforskande Testning (Exploratory Testing) ............................................. 53 3.11.2 Testledning av System av System .................................................................................... 54 3.11.3 Testledning av Säkerhetskritiska System .......................................................................... 54 3.11.4 Testledning - Övrigt ........................................................................................................... 55

4. Testtekniker ....................................................................................................................................... 58 4.1 Inledning ...................................................................................................................................... 58 4.2 Specifikationsbaserade Testtekniker .......................................................................................... 58 4.3 Strukturbaserade Testtekniker .................................................................................................... 60 4.4 Defekt- och Erfarenhetsbaserade Testtekniker .......................................................................... 62

4.4.1 Defektbaserade Tekniker ..................................................................................................... 62 4.4.2 Erfarenhetsbaserade Tekniker ............................................................................................ 62

4.5 Statisk Analys .............................................................................................................................. 64 4.5.1 Statisk Analys av Kod .......................................................................................................... 64 4.5.2 Statisk Analys av Arkitektur ................................................................................................. 65

4.6 Dynamisk Analys ......................................................................................................................... 66 4.6.1 Översikt ................................................................................................................................ 66 4.6.2 Upptäcka Minnesläckor ....................................................................................................... 66 4.6.3 Upptäcka Vilda Pekare ........................................................................................................ 66 4.6.4 Analys av Prestanda ............................................................................................................ 67

5. Testning av Programvaruegenskaper ............................................................................................... 68 5.1 Inledning ...................................................................................................................................... 68 5.2 Kvalitetsattribut för Domäntestning ............................................................................................. 68

5.2.1 Testning av Noggrannhet .................................................................................................... 68 5.2.2 Testning av Lämplighet ........................................................................................................ 69 5.2.3 Testning av Interoperabilitet ................................................................................................ 69 5.2.4 Testning av Funktionell Informationssäkerhet ..................................................................... 69 5.2.5 Testning av Användbarhet ................................................................................................... 69 5.2.6 Testning av Tillgänglighet .................................................................................................... 71

5.3 Kvalitetsattribut för Teknisk Testning .......................................................................................... 71 5.3.1 Testning av Teknisk Informationssäkerhet .......................................................................... 72 5.3.2 Tillförlitlighetstestning .......................................................................................................... 73 5.3.3 Effektivitetstestning .............................................................................................................. 75 5.3.4 Testning av Underhållbarhet ................................................................................................ 76 5.3.5 Portabilitetstestning ............................................................................................................. 76

6. Granskningar ..................................................................................................................................... 79 6.1 Inledning ...................................................................................................................................... 79 6.2 Granskningsprinciper .................................................................................................................. 79 6.3 Granskningsmetoder ................................................................................................................... 80

6.3.1 Administrationsgranskning, och Revision ............................................................................ 80 6.3.2 Granskningar av Speciella Arbetsprodukter ........................................................................ 81 6.3.3 Att Genomföra en Formell Granskning ................................................................................ 81

6.4 Införande av Granskningar .......................................................................................................... 81 6.5 Framgångsfaktorer för Granskningar .......................................................................................... 82

7. Avvikelsehantering ............................................................................................................................ 84 7.1 Inledning ...................................................................................................................................... 84 7.2 När kan Defekter Detekteras? .................................................................................................... 84 7.3 Defekters Livscykel ..................................................................................................................... 84

7.3.1 Steg 1: Identifiering .............................................................................................................. 84 7.3.2 Steg 2: Analys ...................................................................................................................... 85 7.3.3 Steg 3: Åtgärd ...................................................................................................................... 85 7.3.4 Steg 4: Avslut ....................................................................................................................... 85

7.4 Incidentrapportens Fält ............................................................................................................... 85




7.5 Mätetal & Incidentrapporthantering ............................................................................................. 86 7.6 Kommunikation av Incidentinformation ....................................................................................... 86

8. Standarder & Testförbättringsprocesser ........................................................................................... 87 8.1 Inledning ...................................................................................................................................... 87 8.2 Överväganden för Standarder .................................................................................................... 87

8.2.1 Generellt om Standarder ..................................................................................................... 88 8.2.2 Internationella Standarder ................................................................................................... 88 8.2.3 Nationella Standarder .......................................................................................................... 89 8.2.4 Branschspecifika Standarder ............................................................................................... 89 8.2.5 Andra Standarder ................................................................................................................ 90

8.3 Test Improvement Process ......................................................................................................... 90 8.3.1 Introduktion till Processförbättringar .................................................................................... 91 8.3.2 Inriktning hos Processförbättringsmodeller ......................................................................... 91

8.4 Förbättra Testprocessen ............................................................................................................. 91 8.5 Förbättra Testprocessen med TMM ............................................................................................ 93 8.6 Förbättra Testprocessen med TPI .............................................................................................. 94 8.7 Förbättra Testprocessen med CTP ............................................................................................. 94 8.8 Förbättra Testprocessen med STEP .......................................................................................... 95 8.9 Capability Maturity Model Integration, CMMI CMMI ................................................................... 96

9. Testverktyg & Automatisering ........................................................................................................... 97 9.1 Inledning ...................................................................................................................................... 97 9.2 Testverktygskoncept ................................................................................................................... 97

9.2.1 Kostnadsfördelar och Risker med Testverktyg och Automatisering .................................... 97 9.2.2 Strategier för Testverktyg .................................................................................................... 98 9.2.3 Integration & Informationsutbyte mellan Verktyg ................................................................. 99 9.2.4 Automatiseringsspråk: Skript, Skriptspråk ........................................................................... 99 9.2.5 Konceptet Testorakel ......................................................................................................... 100 9.2.6 Driftsättning av Testverktyg ............................................................................................... 100 9.2.7 Användning av Testverktyg med Öppen Källkod............................................................... 101 9.2.8 Egenutvecklade Testverktyg.............................................................................................. 101 9.2.9 Klassificering av Testverktyg ............................................................................................. 101

9.3 Testverktygskategorier .............................................................................................................. 102 9.3.1 Testledningsverktyg ........................................................................................................... 102 9.3.2 Testexekveringsverktyg ..................................................................................................... 102 9.3.3 Debugging- & Felsökningsverktyg ..................................................................................... 103 9.3.4 Felplanterings- & Felinjiceringsverktyg .............................................................................. 103 9.3.5 Simulerings- & Emuleringsverktyg ..................................................................................... 104 9.3.6 Verktyg för Statisk och Dynamisk Analys .......................................................................... 104 9.3.7 Nyckelordsdriven Testautomatisering ............................................................................... 105 9.3.8 Verktyg för Prestandatestning ........................................................................................... 105 9.3.9 Verktyg för Testning av Webbapplikationer ....................................................................... 106

10. Yrkeskunnande – Bygga Team ..................................................................................................... 107 10.1 Inledning .................................................................................................................................. 107 10.2 Individuella Färdigheter ........................................................................................................... 107 10.3 Gruppdynamik ......................................................................................................................... 108 10.4 Anpassa Organisationen för Testning ..................................................................................... 108 10.5 Motivation ................................................................................................................................ 109 10.6 Kommunikation ....................................................................................................................... 110

11. Referenser ..................................................................................................................................... 111 11.1 Standarder .............................................................................................................................. 111

11.1.1 Per Kapitel ....................................................................................................................... 111 11.1.2 Alfabetiskt ........................................................................................................................ 111

11.2 Böcker ..................................................................................................................................... 112 11.3 Andra Referenser .................................................................................................................... 113

12. Bilaga A – Kursplan Bakgrund ...................................................................................................... 114




13. Bilaga B – För Läsarens Kännedom ............................................................................................. 115 13.1 Examineringsnämnder ............................................................................................................ 115 13.2 Certifieringskandidater & Kursleverantörer ............................................................................. 115

14. Bilaga C – För Kursleverantörers Kännedom ............................................................................... 116 14.1 Moduler ................................................................................................................................... 116 14.2 Kurstider .................................................................................................................................. 116

14.2.1 Kurstid per modul ............................................................................................................. 116 14.2.2 Gemensamma Delar ........................................................................................................ 116 14.2.3 Källor ................................................................................................................................ 116

14.3 Praktiska Övningar .................................................................................................................. 116 15. Bilaga D – Rekommendationer ..................................................................................................... 117

15.1 Rekommendationer för Realisering ........................................................................................ 117 16. Bilaga E – Avsteg från SSTBs Ordlista ......................................................................................... 120

16.1 Engelska till Svenska .............................................................................................................. 120 16.2 Svenska till Svenska ............................................................................................................... 121

17. Index .............................................................................................................................................. 122




Tillkännagivanden Det engelska originalet av detta dokument är framtaget av en arbetsgrupp från ”International Software Testing Qualifications Board Advanced Level Working Party”: Bernard Homès (ordförande), Graham Bath, Rex Black, Sigrid Eldh, Jayapradeep Jiothis, Paul Jorgensen, Vipul Kocher, Judy McKay, Thomas Mueller, Klaus Olsen, Randy Rice, Jürgen Richter, Eric Riou Du Cosquer, Mike Smith, Geoff Thompson, Erik Van Veenendaal. Denna grupp tackar granskningsgruppen samt alla nationella organ, anslutna till ISTQB, för deras input och förslag. Vid tidpunkten för färdigställandet av det engelska originalet bestod ”Advanced Level Working Party” av följande medlemmar (i bokstavsordning):

Bernard Homès (ordförande)

Reto Armuzzi Sue Atkins Graham Bath Paul Beekman Armin Beer Rex Black Francisca Blunschi Armin Born Con Bracke Chris Carter Maria Clara Choucair Robert Dankanin Piet de Roo Sigrid Eldh Tim Edmonds Erwin Engelsma Graham Freeburn Dorothy Graham Brian Hambling Jeff B Higgott Bernard Homès Rob Hendriks Dr Suhaimi Ibrahim

Phillip Isles Pr. Paul C. Jorgensen Vipul Kocher Anastasios Kyriakopoulos Junfei Ma Fergus McClachlan Judy McKay Don Mills Gary Mogyorodi Richard Morgan Silvio Moser Ernst Müller Reto Müller Thomas Müller Peter Mullins Beat Nagel Richard Neeve Klaus Olsen Dale Perry Helmut Pichler Jörg Pietzsch Avionam Porat Iris Pinkster

Horst Pohlmann Meile Posthuma Eric Riou Du Cosquer Stefan Ruff Hans Schaefer Maud Schlich Rajesh Sivaraman Mike Smith Katja Stalder Neil Thompson Benjamin Timmermans Chris van Bael Jurian van de Laar Marnix van den Ent Mark van der Zwan Stephanie van Dijck Jan van Moll Erik Van Veenendaal Roland Weber Phillip Whettlock Derek Young Mike Young Wenqiang Zheng.

Den engelska versionen av dokumentet släpptes av General Assembly of ISTQB® den 12 oktober 2007.

Den svenska versionen av dokumentet släpptes av SSTB i februari 2010.




0. Introduktion till Denna Kursplan

0.1 International Software Testing Qualifications Board

International Software Testing Qualifications Board (hädanefter kallad ISTQB®)) består av nationella medlemsorganisationer, vilka representerar länder och regioner över hela världen. När den engelska versionen frisläpptes 2007 var 33 organisationer medlemmar i ISTQB®. Mer detaljer om ISTQB® finns på www.istqb.org. SSTB (Swedish Software Testing Board), den svenska medlemsorganisationen, är bl.a. ansvarig för att sköta ackreditering och examinering i Sverige. Mer information om SSTB finns på www.sstb.se.

Syftet med Detta Dokument

Denna kursplan utgör basen för International Software Testing Qualification på avancerad nivå. Detta dokument är tänkt för följande målgrupper.

1. Medlemsorganisationer - för översättning till det egna språket och för att ackreditera kursleverantörer. Nationella organisationer kan anpassa kursplanen språkligt om så behövs samt komplettera referenserna med egna lokala publikationer.

2. Examinationsnämnder - för skapande av examinationsfrågor på det egna språket, anpassade till inlärningsmålen för respektive modul.

3. Kursleverantörer - för produktion av kursmaterial och beslut om lämpliga undervisnings-metoder.

4. Certifieringskandidater - som förberedelse inför examination (som en del av ett kurstillfälle eller fristående).

5. Alla som arbetar med framtagning av programvara eller system - för att främja yrket programvaru- och systemtestning, och som en bas för böcker och artiklar.

ISTQB® tillåter andra att använda denna kursplan för andra syften, under förutsättning att de begär och erhåller skriftlig tillåtelse.

Målgrupp för Certifierad Testare på Avancerad Nivå i Programvarutestning

Certifieringen på avancerad nivå vänder sig till personer som har kommit en bit på väg i sina karriärer inom programvarutestning. Det inkluderar personer i roller som t.ex. testare, testanalytiker, test-ingenjörer, testkonsulter, testledare, acceptanstestare och programvaruutvecklare. Denna certifiering riktar sig även till dem som vill ha en djupare förståelse för programvarutestning, t.ex. projektledare, kvalitetsansvariga, systemansvariga, utvecklingsansvariga, IT chefer, produkt- och marknads-analytiker samt chefskonsulter. För att bli certifierad på avancerad nivå måste kandidaterna redan ha ett certifikat på grundnivån, samt kunna visa den aktuella examinationsnämnden att de har tillräckligt mycket praktisk erfarenhet för att betraktas som kvalificerade för den avancerade nivån. Kontrollera med aktuell examinationsnämnd vilka specifika krav de ställer på praktisk erfarenhet.

Inlärningsmål/Kunskapsnivå

Inlärningsmålen för varje kapitel är indelade så att man klart kan identifiera vad som gäller för de tre olika modulerna Mer detaljer och exempel på inlärningsmål finns i avsnitt 0.3.

Även om det inte nämns uttryckligen bland inlärningsmålen gäller att hela denna kursplans innehåll, alla begrepp och huvudsyften med de ingående standarderna ska vara igenkända (K1).




Examination

Alla examinationsfrågor på avancerad nivå ska grunda sig på denna kursplan och på grundnivåns kursplan. Svaren på frågorna kan baseras på mer än ett avsnitt i denna och i grundnivåns kursplan. Alla avsnitt i denna och i grundnivåns kursplan kan bli föremål för examination.

Examinationens utseende (format) definieras av ”Riktlinjer för avancerade examinationer” från ISTQB®. Individuella medlemsorganisationer kan – om så önskas – ha en annan examinations-ordning.

Examinationer kan genomföras som en del av en ackrediterad kurs eller oberoende, t.ex. på något examinationscenter. Examinationer kan vara pappersbaserade eller elektroniska. Alla examinationer måste övervakas av en person utsedd av en nationell medlemsorganisation eller en examinations-nämnd.

Ackreditering

Kursleverantörer, vars kursmaterial följer kursplanen, kan i Sverige bli ackrediterade av SSTB. Ackrediteringsföreskrifter och hänvisningar kan erhållas av SSTB eller ISTQB®. En ackrediterad kurs innebär att kursleverantören erkänner och följer SSTBs föreskrifter och hänvisningar samt att kursen följer kursplanen. Detta innebär också att kursleverantören kan anordna en ISTQB®-examination som del av kursen.

Mer information finns i Bilaga C – För Kursleverantörers Kännedom

Detaljnivå

Detaljnivån i denna kursplan tillåter internationellt jämförbar undervisning och examination. För att uppnå detta mål, omfattar kursplanen följande punkter.

Generella undervisningsmål som beskriver avsikten med den avancerade nivån.

Inlärningsmål för varje kunskapsområde vilka beskriver de olika nivåerna av kunskap och förståelse som ska uppnås.

Den information som skall läras ut inklusive beskrivningar av och referenser till övriga källor.

En lista med begrepp som studenterna måste kunna komma ihåg och förstå.

En beskrivning av nyckelområden som ska läras ut, vilket även inbegriper erkända källor och standarder.

Kursplanens innehåll är inte en beskrivning av hela kunskapsområdet programvarutestning, utan speglar den kunskapsnivå som måste täckas in av kursen på avancerad nivå.

Kursplanens Organisation

Kursplanen innehåller 10 kapitel, vart och ett med ett introduktionsavsnitt som beskriver hur respektive kapitel ska tillämpas för de tre olika testrollerna (modulerna).

I undervisningssyfte tillhandahålls avsnitt 0.3 till 0.6 med specifika mål per kapitel för respektive modul. Dessa avsnitt anger också den förväntade minimitiden avsatt för undervisning av dessa kapitel.

En rekommendation är att läsa kursplanen och samtidigt kontrollera inlärningsmålen för det aktuella kapitlet. Det tillåter läsaren att fullt ut förstå vad som krävs och vad som är viktigast i varje kapitel för var och en av de tre modulerna.

Begrepp och Definitioner

Många begrepp i programvarulitteraturen är utbytbara mot varandra. Definitionerna i denna kursplan för avancerad nivå finns i ”Ordlista Engelsk/Svensk, version 2.0” utgiven av SSTB. I några fall har




översättningen av denna kursplan givit upphov till avsteg från denna ordlista. Dessa avsteg finns beskrivna i Bilaga E – Avsteg från SSTBs Ordlista.

Tillvägagångssätt

Det finns ett antal metoder som kan användas inom testning, t.ex. sådana som baserar sig på specifikationer, kodstruktur, data, risker, processer, standarder och liknande taxonomier Olika processer och verktyg erbjuder stöd till testprocesserna och det finns metoder för förbättring av existerande processer.

Denna kursplan är organiserad enligt de metoder som föreslås i ISO 9126, med en uppdelning i funktionella, icke-funktionella och stödjande metoder. Stödprocesser för testning och några förbättringsmetoder nämns också. Detta sätt att organisera materialet inklusive urvalet av de processer som ska ingå i kursen har gjorts på godtycklig basis men med den tanken att det ska ge avancerade testare och testledare en bra grund att stå på.




0.2 Förväntningar

Den certifiering på avancerad nivå som beskrivs i denna kursplan utgår ifrån de tre huvudsakliga rollbeskrivningarna testledare, testanalytiker och teknisk testanalytiker som behövs i en test-organisation. Var och en av dessa roller omfattar grundläggande ansvar och förväntningar. Inom organisationen kan dessa roller spridas på olika individer eller hanteras av en och samma individ. Här nedan beskrivs de tre rollerna.

0.2.1 Avancerad Nivå: Testledare

Testledare på avancerad nivå skall kunna

definiera strategi och övergripande testmål för de system som skall testas

planera och tidsuppskatta de nödvändiga aktiviteterna och följa upp dessa

beskriva och organisera de planerade aktiviteterna

välja ut, skaffa och tilldela lämpliga resurser för de olika aktiviteterna

välja ut, organisera och leda testteamen

organisera kommunikationen inom och mellan testteamen och med alla andra intressenter

motivera tagna beslut och rapportera lämplig information när så erfordras.

0.2.2 Avancerad Nivå; Testanalytiker

Testanalytiker på avancerad nivå skall kunna

strukturera de aktiviteter som är definierade i teststrategin ur ett verksamhetsperspektiv

analysera systemet tillräcklig noggrant så att användarens förväntningar på kvalitet kan uppfyllas

utvärdera systemkraven med ett verksamhetsperspektiv (validering)

förbereda och genomföra lämpliga aktiviteter och rapportera hur de fortskrider

stödja utvärderingar och beslut genom att tillhandahålla nödvändig information

implementera nödvändiga verktyg och tekniker för att kunna uppnå de definierade målen.

0.2.3 Avancerad Nivå: Teknisk Testanalytiker

Teknisk Testanalytiker på avancerad nivå skall kunna

strukturera de aktiviteter som är definierade i teststrategin ur ett teknikperspektiv

analysera systemets interna struktur tillräckligt noggrant för att kunna uppnå förväntad kvalitet

utvärdera systemet utifrån tekniska kvalitetsegenskaper såsom prestanda, informationssäkerhet, mm

förbereda och genomföra lämpliga aktiviteter och rapportera hur de fortskrider

genomföra tekniska testaktiviteter

stödja utvärderingar och beslut genom att tillhandahålla nödvändig information

implementera nödvändiga verktyg och tekniker för att kunna uppnå de definierade målen.




0.3 Inlärningsmål/Kunskapsnivåer

Denna kursplan använder följande nivåer för att definiera inlärningsmål. För varje modul beskrivs inlärningsmålen med hjälp av dessa nivåer i inledningen av respektive kapitel.

Nivå 1: Komma ihåg (K1)

Deltagaren ska känna igen, minnas och erinra sig ett uttryck eller ett begrepp.

Nyckelord: Minnas, erinra sig, känna igen, kunna.

Exempel:

Känna igen definitionen av ”felsymptom” såsom

“utebliven leverans av en tjänst till en slutanvändare eller annan intressent” eller

”avvikelse från programvarans eller systemets förväntade beteende eller resultat”

Nivå 2: Förstå (K2)

Deltagaren kan motivera påståenden inom ämnesområdet med anledningar eller förklaringar. Deltagaren kan summera, särskilja, klassificera och exemplifiera fakta (t.ex. jämföra begrepp), test-principer och testprocedurer (t.ex. förklara aktivitetsordningen).

Nyckelord: Sammanfatta, klassificera, jämföra, kartlägga, kontrastera exemplifiera, förklara, tolka, beskriva dra slutsatser, summera, kategorisera.

Exempel:

Förklara varför testfall skall designas så tidigt som möjligt.

För att upptäcka defekter när det är billigt att eliminera dem.

För att upptäcka de viktigaste defekterna först.

Förklara likheter och skillnader mellan integrations- och systemtestning.

Likheter: mer än en komponent testas, icke-funktionella egenskaper kan testas.

Olikheter: integrationstestning är inriktad på gränssnitt och samspel, medan systemtestning är inriktad på helheten såsom testning utgående från ett användarperspektiv.

Nivå 3: Tillämpa (K3)

Deltagaren kan välja rätt användning av ett koncept eller en teknik och tillämpa den utifrån ett givet sammanhang. K3 gäller oftast för kunskaper om procedurer. K3 kräver ingen kreativitet, som i fallet med utvärdering av en programvaruapplikation eller skapandet av en modell för en given program-vara. K3 är t.ex. när vi utifrån en given modell beskriver de olika stegen för att skapa testfall.

Nyckelord: Implementera, exekvera, använda, följa en metod, tillämpa en metod

Exempel:

Kunna identifiera gränsvärden för partitioner (eller klasser) med giltiga eller ogiltiga värden.

Kunna, med hjälp av ett tillståndsdiagram och en uppsättning existerande testfall, använda den generiska metoden tillståndsbaserad testning.

Nivå 4: Analysera (K4)

Deltagaren kan dela upp information som är relaterad till en metod eller en teknik i dess beståndsdelar för en ökad förståelse, och kan skilja på fakta och slutsatser. Typiska användningsområden är att analysera dokument, programvara eller projektläge och föreslå lämpliga åtgärder för att lösa problem eller genomföra arbetsuppgifter.

Nyckelord: Analysera, differentiera, välja, strukturera, fokusera, beskriva attribut, dela upp, utvärdera, bedöma, övervaka, koordinera, skapa, syntetisera, generera, göra antaganden, planera, designa, konstruera, producera.




Exempel:

analysera produktrisker och föreslå förebyggande och korrigerande åtgärder för att begränsa riskerna

beskriva vilka delar i en incidentrapport som är fakta och vad som är slutsatser dragna utifrån resultatet

Referenser (för inlärningsmålens kognitiva nivåer)

Bloom, B. S. (1956). Taxonomy of Educational Objectives, Handbook I: The Cognitive Domain, David McKay, Co. Inc.

Anderson, L. W. and Krathwohl, D. R. (eds) (2001). A Taxonomy for Learning, Teaching, and Assessing: A Revision of Bloom's Taxonomy of Educational Objectives, Allyn & Bacon.




0.4 Inlärningsmål för Testledare

Detta avsnitt innehåller en lista med detaljerade inlärningsmål för modulen testledare.

Generellt gäller att alla delar av kursplanen kan förekomma i examinationen på K1 nivå, dvs. deltagaren ska känna igen, minnas och erinra sig begrepp och koncept. Av denna anledning innehåller listan nedan endast inlärningsmålen på K2, K3 och K4 nivå.

Introduktion till Kursplanen för Testledare – [60 minuter]

(Inklusive repetition av kursplanen för ISTQB® grundkurs)

Kapitel 1: Grundläggande Principer för Programvarutestning – [150 minuter]

1.2 Testning i Programvarans Livscykel

(K2) beskriva hur testning ingår i programvaruutveckling och underhållsarbete

(K4) analysera livscykelmodeller för programvara och beskriva de mest lämpliga arbets-uppgifterna och testaktiviteterna som skall utföras (t.ex. kunna skilja på testaktiviteter och utvecklingsaktiviteter)

1.3 Speciella System

(K2) förklara med exempel vad som är speciellt med att testa system av system

(K2) förklara varför testning av säkerhetskritiska system kräver fokus på alla de tre områdena organisationsstruktur, utvecklingsmodell och produkttyp, för att kunna påvisa överens-stämmelse med regler och förordningar

1.4 Mätetal & Mätning

(K2) beskriva och jämföra vanliga testrelaterade mätetal

(K3) övervaka testaktiviteter genom att utföra mätningar av testobjekt och testprocessen

Kapitel 2: Testprocesser – [120 minuter]

2.3 Testplanering & Teststyrning

(K2) beskriva, genom att ge exempel, hur teststrategier påverkar testplaneringen

(K2) förklara med exempel hur utvecklingsprodukter är relaterade till testprodukter och vice versa

(K2) klassificera teststyrningsaktiviteter ur perspektivet att kunna avgöra om testuppdrag, strategier och mål har uppnåtts

2.5 Testimplementering & Exekvering

(K2) förklara förutsättningarna för testexekvering

(K2) förklara med exempel fördelar och nackdelar med tidig testimplementering genom att i exemplen inkludera lämpliga testtekniker

(K2) förklara varför användare och/eller kunder skulle kunna delta i testexekvering

(K2) beskriva hur nivån på testloggar kan variera beroende på testnivån

2.6 Utvärdering av Avslutskriterier och Rapportering

(K2) sammanfatta den information som behöver samlas in under testprocessen för att ge tillräckligt underlag för rapportering och utvärdering gentemot fastställda avslutskriterier

2.7 Testavslutningsaktiviteter

(K2) sammanfatta testavslutningsaktiviteternas fyra huvudgrupper

(K3) generalisera lärdomar under testavslutsfasen för att identifiera områden/aktiviteter som kan förbättras eller upprepas




Kapitel 3: Testledning – [1120 minuter]

3.2 Testledningsdokumentation

(K4) beskriva innehåll i testledningsdokument i enlighet med IEEE829, t.ex. testplan, testdesignspecifikation och testprocedur

(K2) beskriva minst fyra viktiga delar i en teststrategi/tillvägagångssätt och vilka dokument som enligt IEEE 829 avspeglar teststrategin

(K2) förklara hur och varför avvikelser från teststrategin hanteras i andra testlednings-dokument

3.3 Mallar för Dokumentation av Testplaner

(K2) summera innehållet i IEEE 829:s ”Master Test Plan”

(K2) återge och med egna ord förklara rubrikerna i testplanen som IEEE 829 beskriver, med avseende på anpassning till organisation, produktrisker samt projektets risker, storlek och formalism

3.4 Testestimering

(K3) estimera testarbetet för ett litet representativt system genom att dels använda ett mätetalsbaserat och ett erfarenhetsbaserat angreppssätt. Hänsyn ska tas till faktorer som påverkar kostnad, arbetsinsats och löptid

(K2) förstå och exemplifiera de faktorer som finns listade i kursplanen vilka kan leda till bristande precision i tidsuppskattningarna

3.5 Schemaläggning av Testplanering

(K2) förklara fördelarna med tidig och iterativ testplanering samt exemplifiera

3.6 Övervakning & Styrning av Testprogress

(K2) jämföra de olika metoderna för styrning av testverksamheten

(K2) ge åtminstone fem begreppsmässigt olika exempel på hur styrningen av testverk-samheten kan påverkas av hittills uppnådda resultat

(K4) använda testprogressrelaterade observationer för att skapa en åtgärdsplan för för-bättringar av den nuvarande testprocessen

(K4) analysera testresultat och fastställa testprogressen, dokumenterad i en statusrapport och i en slutlig testrapport, som omfattar alla fem rapporteringsdimensioner

3.7 Testningens Värde för Affärsverksamheten

(K2) ge exempel (mätetal) för de fyra typerna av kostnader som ingår i begreppet “kvalitetskostnad”

(K3) utifrån ett givet sammanhang beskriv de kvantitativa och/eller kvalitativa värden som testningen kan tillföra

3.8 Distribuerad Testning

(K2) lista risker, likheter och skillnader mellan de tre bemanningsstrategierna (distribuerad, ”outsourced” eller ”insourced” testning)

3.9 Riskbaserad Testning

3.9.1 Inledning

(K2) förklara de olika sätt, på vilka riskbaserad testning hanterar risker

(K4) identifiera projektrisker och produktrisker samt definiera lämplig teststrategi och testplan baserat på dessa risker

3.9.2 Riskhantering

(K3) använda metoden FMEA för att genomföra en riskanalys av produkten ur en testares perspektiv

(K4) sammanfatta vanliga riskperspektiv hos olika intressenter i ett projekt och använd denna sammanfattning och deras kollektiva omdöme för att planera testaktiviteter för riskminskning




3.9.3 Riskhantering i Programvarans Livscykel

(K2) beskriva de egenskaper hos riskhanteringen som innebär att den måste bedrivas som en iterativ process

(K3) omsätta en bestämd riskbaserad teststrategi till testaktiviteter samt övervaka effekterna av strategin under testningen

(K4) analysera och rapportera testresultat och fastställa/lägga fram resterande risker för att underlätta för projektledningen att fatta förnuftiga leveransbeslut

3.10 Failure Mode and Effects Analysis (FMEA)

(K2) beskriva vad FMEA innebär. Förklara med exempel hur FMEA tillämpas i projekt och hur det kan gagna olika projekt

3.11 Att Tänka på vid Testledning

(K2) jämföra testledning vid utforskande testning, system av system och testning av säkerhetskritiska system med avseende på strategi, för- och nackdelar, lämplighet samt deras påverkan på planering, övervakning och styrning och på täckningsgraden

Kapitel 4: Testtekniker – [0 minuter]

Inga inlärningsmål (på någon K-nivå) är tillämpliga för testledaren.

Kapitel 5: Testning av Programvaruegenskaper – [0 minuter]

Inga inlärningsmål (på någon K-nivå) är tillämpliga för testledaren.

Kapitel 6: Granskningar – [120 minuter]

6.2 Granskningsprinciper

(K2) förklara fördelarna med granskningar jämfört med dynamiska testtekniker och med andra statiska testtekniker

6.4 Införande av Granskningar

(K2) jämföra granskningsmetoder med varandra och beskriva deras relativa styrkor, svagheter och användningsområden

(K3) leda ett granskningsteam genom en formell granskning med hjälp av den definierade processen

(K4) ta fram en granskningsplan som en del av ett projekts kvalitetsplan/testplan. Granskningsplanen ska innehålla olika granskningstekniker med hänsyn taget till typ av defekter man letar efter och tillgänglig kompetens. Granskningsplanen ska även anpassas till och komplettera den planerade dynamiska testningen

6.5 Framgångsfaktorer for Granskningar

(K2) förklara riskerna med att inte ta hänsyn till tekniska, organisatoriska eller mänskliga faktorer när man genomför granskningar

Kapitel 7: Avvikelsehantering – [80 minuter]

(K3) använda livscykeln för avvikelsehantering i enlighet med IEEE Standard 1044-1993 för att hantera defekter

(K3) utvärdera den befintliga defektrapporteringsprocessen mot IEEE Standard 1044-1993 och dess defekttaxonomi för att förbättra processens kvalitet

(K4) analysera existerande felrapporter och uppdatera defekttaxonomin




Kapitel 8: Standarder & Testförbättringsprocesser – [120 minuter]

(K2) sammanfatta var man kan hitta programvarustandarder och förklara varför de är användbara för programvarutestning

8.4 Förbättra Testprocessen

(K3) skriva en testförbättringsplan som innehåller generella steg och pekar ut rätt personer

(K2) sammanfatta testförbättringsprocesserna som de definieras i TMM, TPI, CTP, STEP, samt processområdena verifiering och validering i CMMI

(K2) förklara utvärderingskriterierna för testförbättringsmodellerna TMM, TPI, CTP, STEP, samt för processområdena verifiering och validering i CMMI

Kapitel 9: Testverktyg & Automatisering – [90 minuter]

9.2 Testverktygskoncept

(K2) jämföra innehåll och aspekter hos var och en av verktygskoncepten “Kostnadsfördelar och Risker med Testverktyg och Automatisering”, “Strategier för Testverktyg”, “Integration & Informationsutbyte mellan Verktyg”, “Automatiseringsspråk: Skript, Skriptspråk”, “Konceptet Testorakel”, “Driftsättning av Testverktyg”, “Användning av Testverktyg med Öppen Källkod”, “Egenutvecklade Testverktyg” och “Klassificering av Testverktyg”

(K2) beskriva varför och när det är viktigt att skapa en strategi eller en utrullningsplan för testverktyg

(K2) förstå de olika faserna i implementeringen av testverktyg

9.3 Testverktygskategorier

(K2) sammanfatta testverktygskategorierna efter mål, avsedd användning, styrkor, risker och kunna ge exempel

(K2) sammanfatta specifika krav på testverktyg och “open source”-testverktyg vid testning av säkerhetskritiska system

(K2) beskriva viktiga aspekter hos och konsekvenser av olika testverktyg och deras implementering, användning och påverkan på testprocessen

(K2) beskriva när, varför, fördelar, risker och konsekvenser vid implementering av ett eget verktyg

Kapitel 10: Yrkeskunnande – Bygga Team [240 minuter]

10.2 Individuella Färdigheter

(K3) använda ett givet frågeformulär för att utvärdera team-medlemmars styrkor och svag-heter i förhållande till användandet av programvarusystem, domän- och affärskunskaper och områdena systemutveckling, programvarutestning och social kompetens

10.3 Gruppdynamik

(K3) genomföra en ”gap” analys för att bestämma vilka tekniska och mjuka kunskaper som krävs för lediga befattningar i en organisation

10.4 Anpassa Organisationen för Testning

(K2) karaktärisera olika organisatoriska möjligheter och jämföra dem med ”in-” och ”outsourcing” samt ”in-” och ”off-shoring”

10.5 Motivation

(K2) ge exempel på motiverande och motivationssänkande faktorer för testare

10.6 Kommunikation

(K2) exemplifiera professionell, objektiv och effektiv kommunikation i ett projekt från testarens synvinkel. Risker och möjligheter bör beaktas




0.5 Inlärningsmål för Testanalytiker

Detta avsnitt innehåller en lista med detaljerade inlärningsmål för modulen testanalytiker. Generellt gäller att alla delar av kursplanen är på K1-nivå, dvs. deltagaren ska känna igen, minnas och erinra sig begrepp och koncept. Därför innehåller tabellen nedan endast inlärningsmålen på K2, K3 och K4 nivå.

Introduktion till Kursplanen för Testanalytiker – [60 minuter]




2.4 Testanalys & Testdesign

(K2) förklara orsakerna till att funktionstestning utförs i olika stadier i en applikations livscykel

(K2) ge exempel på kriterier, vid identifiering av testvillkor som påverkar deras struktur och nivå

(K2) beskriva hur testanalys och testdesign kan betraktas som statiska testtekniker, som kan användas för att upptäcka defekter

(K2) förklara med exempel begreppet testorakel och hur detta kan användas i test-specificeringsarbetet


(K2) beskriva förutsättningarna för testexekvering, inklusive: testartefakter; testmiljö; konfigu-rationshantering och felhantering


(K3) bestämma om testavslutskriterier uppnåtts mha en uppsättning gjorda mätningar



(K3) prioritera urval av testfall, testtäckning och testdata baserat på risker och dokumentera detta på lämpligt sätt i testschema och testprocedurer

(K2) dra upp riktlinjerna för ett riskbaserat angreppssätt vad avser planering och exekvering av domäntestning


4.2 Specifikationsbaserade Testtekniker

(K2) för var och en av de specifikationsbaserade teknikerna, ge exempel på typiska defekter som de kan hitta och ange motsvarande täckningskriterier

(K3) skriva testfall utifrån modeller av programvaran med hjälp av följande testdesigntekniker (testerna skall uppnå en given täckningsgrad av modellen)

o ekvivalensklassindelning o gränsvärdesanalys o beslutstabeller o tillståndsbaserad testning o klassifikationsträdsmetoden o parvis testning o användningsfallsbaserad testning




(K4) analysera ett system, eller dess kravspecifikation, för att bestämma vilka specifikationsbaserade tekniker som skall användas för specifika ändamål. Utifrån analyserna av systemet och målsättningarna med testningen samt med stöd av IEEE 829, dra upp riktlinjerna för en testdokumentation med fokus på funktionella och domäntestfall, innefattande testdesign, testfall och testimplementering

4.4 Defekt- och Erfarenhetsbaserade Testtekniker

(K2) beskriva principerna för och resonemanget bakom defektbaserade tekniker samt särskilja deras användningsområden från specifikationsbaserade och strukturbaserade teknikers

(K2) förklara defekttaxonomier och deras användningsområden med exempel

(K2) förstå principerna för och resonemanget bakom erfarenhetsbaserade tekniker samt när de kan användas

(K3) specificera, exekvera och rapportera testning med hjälp av utforskande testning

(K2) använda de olika typerna av programvaruattacker för att kategorisera de defekter som dessa metoder kan upptäcka

(K4) analysera ett system för att bestämma vilka specifikationsbaserade, defekt-baserade eller erfarenhetsbaserade tekniker som bör tillämpas för specifika ändamål


5.2 Kvalitetsattribut för Domäntestning

(K4) förklara, med exempel, vilka testtekniker (listade i kapitel 4) som är lämpliga vid test av kvalitetsattribut såsom noggrannhet, lämplighet, interoperabilitet, funktionell informations-säkerhet och tillgänglighet

(K3) planera, designa, specificera och exekvera testfall för användbarhet med lämpliga tekniker för att uppnå identifierade testmål och för att hitta specifika typer av defekter

5.3 Kvalitetsattribut för Teknisk Testning

(K2) förklara anledningen till att en teststrategi bör inkludera testning av effektivitet, till-förlitlighet samt teknisk informationssäkerhet och ge exempel på typer av defekter som man förväntar sig att upptäcka

(K2) kategorisera de tekniska kvalitetsattributen utifrån defekttyper, typisk användning i programvarulivscykeln och lämpliga testtekniker


(K3) använda en granskningschecklista för att verifiera kod och arkitektur ur en testares synvinkel

(K3) använda en granskningschecklista för att verifiera krav och användningsfall ur en testares synvinkel



(K4) analysera, klassificera och beskriva funktionella och icke-funktionella avvikelser i tydliga felrapporter

Kapitel 8: Standarder & Testförbättringsprocesser [0 minuter]

Inga inlärningsmål (på någon K-nivå) är tillämpliga för testanalytikern.






(K2) jämföra innehåll och aspekter hos var och en av verktygskoncepten “Kostnadsfördelar och Risker med Testverktyg och Automatisering”, “Strategier för Testverktyg”, “Integration & Informationsutbyte mellan Verktyg”, “Automatiseringsspråk: Skript, Skriptspråk ”, “Konceptet Testorakel”, “Driftsättning av Testverktyg”, “Användning av Testverktyg med Öppen Källkod”, “Egenutvecklade Testverktyg” och “Klassificering av Testverktyg”



(K2) associera de olika verktygstyperna med olika nivåer och typer av testning

Kapitel 10: Yrkeskunnande – Bygga Team - [30 minuter]

10.6 Kommunikation





0.6 Inlärningsmål för Tekniska Testanalytiker

Detta avsnitt innehåller en lista med detaljerade inlärningsmål för modulen teknisk testanalytiker. Generellt gäller att alla delar av kursplanen är på K1-nivå, dvs. deltagaren ska känna igen, minnas och erinra sig begrepp och koncept. Därför innehåller tabellen nedan endast inlärningsmålen på K2, K3 och K4 nivå.

Introduktion till Kursplanen för Tekniska Testanalytiker – [60 minuter]





(K2) förklara inom vilka stadier i en applikations livscykel som icke-funktionella och arkitekturbaserade tester kan tillämpas. Förklara varför icke-funktionell testning endast äger rum inom specifika stadier i applikationens livscykel

(K2) ge exempel på kriterier, vid identifiering av testvillkor som påverkar deras struktur och nivå

(K2) beskriva hur testanalys och testdesign kan betraktas som statiska testtekniker, som kan användas för att upptäcka defekter

(K2) förklara med exempel begreppet testorakel och hur detta kan användas i test-specificeringsarbetet


(K2) beskriva förutsättningarna för testexekvering, inklusive: testartefakter; testmiljö; konfigu-rationshantering; och felhantering


(K3) bestämma om testavslutskriterier uppnåtts mha en uppsättning gjorda mätningar



(K2) dra upp riktlinjerna för ett riskbaserat angreppssätt vad avser planering och exekvering av teknisk testning



(K2) för var och en av de specifikationsbaserade teknikerna, ge exempel på typiska defekter som de kan hitta

(K3) skriva testfall utifrån modeller av programvaran med hjälp av följande testdesigntekniker (testerna skall uppnå en given täckningsgrad av modellen)

o ekvivalensklassindelning o gränsvärdesanalys o beslutstabeller o tillståndsbaserad testning




(K4) analysera ett system, eller dess kravspecifikation, för att bestämma vilka specifikationsbaserade tekniker som skall användas för specifika ändamål. Utifrån analyserna av systemet och målsättningarna med testningen samt med stöd av IEEE 829, dra upp riktlinjerna för en testdokumentation med fokus på ickefunktionella och komponenttestfall, innefattande testdesign, testfall och testimplementering

4.3 Strukturbaserade Testtekniker

(K2) för var och en av de strukturbaserade teknikerna, ge exempel på typiska defekter som de kan hitta

(K3) skriva testfall med användande av följande testdesigntekniker (testerna skall uppnå en given täckningsgrad)

o kodsatstestning o beslutstestning o MCDC testning o testning av villkorskombinationer

(K4) analysera ett system för att bestämma vilka strukturbaserade tekniker som skall användas för specifika ändamål

(K2) för varje strukturbaserad teknik, förstå tekniken, dess motsvarande täckningsmått och när den kan användas

(K4) kunna jämföra och analysera strukturbaserade tekniker för att avgöra vilken som är mest lämplig i en given situation


(K2) beskriva principerna för och resonemanget bakom defektbaserade tekniker samt särskilja deras användningsområden från specifikationsbaserade och strukturbaserade teknikers

(K2) förklara defekttaxonomier och deras användningsområden med exempel

(K2) förstå principerna för och resonemanget bakom erfarenhetsbaserade tekniker samt när de kan användas

(K3) specificera, exekvera och rapportera testning med hjälp av utforskande testning

(K3) specificera testfall med hjälp av olika typer av programvaruattacker

(K4) analysera ett system för att bestämma vilka specifikationsbaserade, defektbaserade eller erfarenhetsbaserade tekniker som bör tillämpas för specifika ändamål

4.5 Statisk Analys

(K3) använda kontrollflödesanalys och dataflödesanalys för att verifiera att koden inte innehåller några kontroll- eller dataflödesavvikelser

(K4) tolka resultaten generade av verktyg för analys av kontroll- och dataflöden för att avgöra om koden innehåller några kontroll- eller dataflödesavvikelser

(K2) förklara hur anropsträd kan användas för att utvärdera kvaliteten hos en arkitektur och hur dessa kan användas i testplanerings- och testdesignarbetet, inklusive vilka typer av defekter som kan identifieras och de begränsningar som användning av anropsträd kan innebära

4.6 Dynamisk Analys

(K2) förklara hur man utför dynamisk analys av kod. Sammanfatta de defekter som kan upptäckas med denna teknik och beskriva dess begränsningar



(K2) kategorisera kvalitetsattributen för domäntestning utifrån defekttyper, typisk användning i programvarulivscykeln och lämpliga testtekniker

(K4) specificera testfall för vissa typer att kvalitetsattribut med lämpliga tekniker för att uppnå identifierade testmål och för att hitta specifika typer av defekter





(K2) kategorisera de tekniska kvalitetsattributen utifrån defekttyper, typisk användning i programvarulivscykeln och lämpliga testtekniker

(K2) förstå och förklara de olika faserna i en applikations livscykel där testning av attributen informationssäkerhet, tillförlitlighet och effektivitet kan genomföras (inklusive deras mot-svarande sub-attribut i ISO 9126)

(K2) förstå skillnaderna mellan de typer av defekter som kan upptäckas vid testning av attributen informationssäkerhet, tillförlitlighet och effektivitet (inklusive deras motsvarande sub-attribut i ISO 9126)

(K2) formulera teststrategier som innefattar testning av attributen informationssäkerhet, tillförlitlighet och effektivitet samt deras motsvarande sub-attribut i ISO9 126

(K3) specificera testfall för attributen informationssäkerhet, tillförlitlighet och effektivitet samt deras motsvarande sub-attribut i ISO 9126

(K2) förstå och förklara skälen till att testning av underhållbarhet, portabilitet och tillgänglighet ska ingå i en teststrategi

(K3) specificera testfall för underhållbarhet och portabililtet


(K4) skapa en granskningschecklista för att upptäcka typiska defekter vid kod- och arkitektur-granskning



(K4) analysera, klassificera och beskriva funktionella och icke-funktionella avvikelser i tydliga felrapporter

Kapitel 8: Standarder & Testförbättringsprocesser [0 minuter]

Inga inlärningsmål (på någon K-nivå) är tillämpliga för den tekniska testanalytikern



(K2) jämföra innehåll och aspekter hos var och en av verktygskoncepten “Kostnadsfördelar och Risker med Testverktyg och Automatisering”, “Strategier för Testverktyg”, “Integration & Informationsutbyte mellan Verktyg”, “Automatiseringsspråk: Skript, Skriptspråk”, “Konceptet Testorakel”, “Driftsättning av Testverktyg”, “Användning av Testverktyg med Öppen Källkod”, “Egenutvecklade Testverktyg” och “Klassificering av Testverktyg”



(K2) associera de olika verktygstyperna med olika nivåer och typer av testning

9.3.7 Nyckelordsdriven Testautomatisering

(K3) baserat på en verksamhetsbeskrivning, skapa nyckelord/aktionsordstabeller som ska användas av ett testexekveringsverktyg anpassat för detta ändamål

(K3) spela in tester med “Capture-Replay”-verktyg för att skapa förutsättningar för regres-sionstestning med hög kvalitet, där många testfall kan exekveras under korta tidsperioder

9.3.8 Verktyg för Prestandatestning

(K3) designa prestandatester med hjälp av prestandatestverktyg, inklusive planering och mätningar av systemegenskaper




Kapitel 10: Yrkeskunnande – Bygga Team - [30 minuter]

10.6 Kommunikation





1. Grundläggande Principer för Programvarutestning

Begrepp:

Etik, mätning, mätetal, programvarans livscykel, system av system, säkerhetskritiska system

1.1 Inledning

Kapitel 1 introducerar centrala testkoncept, vilka har betydelse för alla som arbetar med test i någon roll, såväl testledare, testanalytiker som teknisk testanalytiker. Under kursens gång kommer kurs-ledaren att förklara och exemplifiera dessa begrepp i förhållande till den version av kursen som ges. När kursen ges för tekniska testanalytiker kommer dessutom de generella termerna mätetal och mätningar (avsnitt 1.4) att exemplifieras med speciella tekniska mätetal som t.ex. används vid prestandamätningar.

Avsnitt 1.2 fokuserar på testprocessen som del av livscykeln för programvaruutveckling. Detta avsnitt bygger på de grundläggande principerna som introducerades under grundkursen. Särskilt fokus riktas mot hur en testprocess anpassas till olika modeller för programvaruutveckling och andra IT-processer.

Ett systems beskaffenhet kan ha avgörande betydelse för hur systemet ska testas. I avsnitt 1.3 presenteras två speciella typer av system, system av system (även kallade multi-system) och säker-hetskritiska system. Dessa typer av system ställer speciella krav på testningen, vilket man som testare måste känna till.

Erfarna testare kommer att ställas inför ett antal utmaningar när de, i sin egen organisation, i sitt team eller i sina arbetsuppgifter, skall införa de olika testmetoderna och angreppssätten som beskrivs i denna kursplan.

1.2 Testning i Programvarans Livscykel

Testning är en integrerad del av olika programvaruutvecklingsmodeller såsom

sekventiella modeller (vattenfallsmodellen, V-modellen och W-modellen)

iterativa modeller (Rapid Application Development (RAD), och spiralmodellen)

inkrementella modeller (evolutionära och agila metoder).

I teststrategin måste det långsiktiga testupplägget definieras. Detta omfattar bl.a. organisation, processdefinitioner samt val av verktyg och metoder.

Testprocesser används inte isolerat utan de är sammanflätade med och påverkas av andra processer, t.ex. processer för:

kravhantering och kravledning

projektledning

konfigurations- och ändringshantering

programvaruutveckling

underhåll av programvara

teknisk support

framtagning av teknisk dokumentation.

I sekventiella utvecklingsmodeller är den tidiga testplaneringen och den senare testexekveringen närbesläktade. Testaktiviteter kan både överlappa och genomföras parallellt.

Ändrings- och konfigurationshantering är viktiga stödaktiviteter vid programvarutestning. Utan en lämplig och fungerande ändringshantering kan systemet inte uppdateras på ett tillförlitligt sätt. Utan lämplig och fungerande konfigurationshantering är risken stor att utveckling i flera samtidiga spår misslyckas eller att ändringar till och med tappas bort.




Utöver de testnivåer som definieras i grundkursen kan man, beroende på projektmiljön, behöva definiera ytterligare testnivåer, t.ex.

testning av programvara integrerad med hårdvara

systemintegrationstestning

testning av funktioners växelverkan

integrationstestning av kundprodukt.

Varje testnivå har följande kännetecken:

testmål

testomfattning

spårbarhet till testbasen

start- och avslutskriterier

testleverabler inklusive rapportering

testtekniker

mätningar och mätetal

testverktyg

överensstämmelse med standarder, t.ex. organisationens eller branschspecifika standarder.

Beroende på sammanhanget kan mål och omfattning för varje testnivå antingen hanteras var för sig eller gemensamt på projektnivå (t.ex. för undvika onödigt dubbelarbete med liknande tester på olika testnivåer).

Testaktiviteterna måste anpassas till den valda livscykelmodellen för programvaruutvecklingen, som kan vara sekventiell (t.ex. vattenfallsmodellen, V-modellen, W-modellen), iterativ (t.ex. Rapid Application Development (RAD) och spiralmodellen) eller inkrementell (t.ex. evolutionära och agila metoder).

Till exempel, i V-modellen, skulle ISTQB® grundläggande testprocess kunna anpassas enligt följande.

Systemtestplanering genomförs parallellt med projektplaneringen och teststyrningen fortsätter tills systemtestexekveringen och testavslutsaktiviteterna är avklarade.

Systemtestanalys och systemtestdesign genomförs parallellt med framtagning av kravspecifikation, system- och arkitekturdesignspecifikationer (hög-nivå) och komponentdesignspecifikation (låg-nivå).

Planering och implementering av systemtestmiljön (t.ex. uppsättning av testplatser) kan starta samtidigt med systemdesignen, även om det mesta av arbetet normalt genomförs parallellt med kodning och komponenttestning. Ofta fortsätter arbetet med att färdigställa systemtest-miljön ända fram till dagarna före starten av systemtestexekveringen.

Systemtestexekvering startar när startkriterierna för systemtesten är uppfyllda (eller upp-hävda), vilket oftast betyder att åtminstone komponenttestning och ofta även komponent-integrationstestning är genomförda. Systemtestexekvering fortsätter tills dess avsluts-kriterierna för systemtest är uppfyllda.

Utvärdering av avslutskriterier för systemtest och rapportering av systemtestresultat bör göras under hela systemtestexekveringen, normalt med högre frekvens och betydelse när projektets måldatum närmar sig.

Avslutningsaktiviteter för systemtesterna genomförs när avslutskriterier för systemtest är uppfyllda och systemtestexekveringen har förklarats vara komplett. Ibland kan dock avsluts-aktiviteterna senareläggas tills acceptanstestningen har genomförts och samtliga projekt-aktiviteter har avslutats.

Testledaren måste, för varje testnivå, och för den valda kombinationen av programvarans livscykel och testprocess, planera denna anpassning under testplaneringen och/eller projektplaneringen. För speciellt komplexa projekt måste testprocesser inte bara anpassas utan också modifieras beroende på projektsammanhanget. Det behövs bl.a. göras vid system av system som är vanliga inom stora företag och vid utveckling av vissa militära produkter, (t.ex. när det är lättare att hitta en defekt på en högre nivå än på en lägre nivå).




1.3 Speciella System

1.3.1 System av System

Ett system av system är en grupp samverkande systemenheter (inklusive hårdvara med individuella programvaruapplikationer och kommunikation), ihopkopplade för att uppnå ett gemensamt mål utan att det existerar någon gemensam hanteringsmodell för helheten. Kännetecken och risker, som associeras med system av system inkluderar följande punkter.

Successiv sammanslagning av oberoende samarbetande systemenheter för att undvika skapandet av hela systemet av system från början. Detta kan uppnås t.ex. genom att integrera COTS-system vilka endast kräver en begränsad vidareutveckling.

Teknisk och organisatorisk komplexitet (t.ex. bland olika intressenter) är exempel på risker för effektiv ledning. Olika livscykelmodeller kan ha använts för de olika ingående systemen, vilket kan leda till kommunikationsproblem bland de olika inblandade teamen (utveckling, testning, tillverkning, produktion, användare osv.). Den övergripande ledningen för utvecklingen av system av system måste kunna hantera den inneboende tekniska komplexiteten som kom-binerandet av de olika ingående systemen innebär, samt kunna hantera olika organisatoriska problem/frågor såsom outsourcing och offshoring.

Konfidentialitet och skydd av speciell teknisk kunskap, gränssnitt mellan olika organisationer (t.ex. offentlig och statlig sektor) eller legala bestämmelser (t.ex. för att förhindra mono-polistiskt beteende) kan innebära att ett komplext system måste betraktas som ett system av system.

System av system är i sig själva mindre tillförlitliga än individuella system, eftersom varje begränsning i en systemkomponent automatiskt blir en begränsning för hela systemet av system.

Den höga nivån på teknisk och funktionell interoperabilitet vilket fordras av individuella systemkomponenter i ett system av system, medför att integrationstestningen är av högsta vikt och kräver väldefinierade och överenskomna gränssnitt.

1.3.1.1 Ledning och Testning av System av System

Högre komplexitet i projektledning och konfigurationsledning är vanligt vid utveckling av system av system. Därför är omfattande kvalitetssäkring och definierade processer vanligtvis associerade med komplexa system och system av system. Formell utvecklingslivscykel, milstolpar och granskningar är också vanligt förekommande under utveckling av system av system.

1.3.1.2 Livscykelegenskaper hos System av System

Varje testnivå för ett system av system har följande ytterligare kännetecken förutom de som beskrivs i avsnitt 1.2 Testning i Programvarans Livscykel

fler nivåer av integration och versionshantering

långa projekt

formell kunskaps- och informationsöverföring mellan projektmedlemmar

utveckling av systemkomponenter, och identifiering av krav på regressionstester för system av system sker ofta vild olika tillfällen

underhållstestning är nödvändigt efter utbyte av systemkomponenter pga. att de uppgraderats eller är föråldrade.

Under utveckling av ett system av system kommer varje testnivå att påverka alla följande testnivåer. Till exempel kan “systemtest” för en systemkomponent betraktas som “komponent” på en högre testnivå.

Normalt kommer varje systemkomponent (inom ett system av system) att genomgå varje nivå av testning och därefter integreras i systemet av system med den ytterligare testning som detta innebär.

Se avsnitt 3.11.2 för specifika ledningsfrågor associerade med system av system.




1.3.2 Säkerhetskritiska System

Säkerhetskritiska system är sådana system som, om de slutar fungera helt eller delvis (dvs. försämras påtagligt, t.ex. pga. felaktig heller vårdslös hantering), kan ge upphov till katastrofala eller kritiska följder. Leverantörer av säkerhetskritiska system kan bli ansvariga för skador som deras system orsakat. Testaktiviteter används därför för att reducera dessa risker. Testaktiviteter med åtföljande dokumentation utgör bevis på att systemet testats på ett för ändamålet tillräckligt sätt för att undvika katastrofala eller kritiska följder.

Säkerhetskritiska system är till exempel flygkontrollsystem, automatiska handelssystem, medicinska system, kontrollsystem för kärnkraftverk osv.

Följande punkter bör beaktas vid implementering av säkerhetskritiska system

spårbarhet till regulatoriska (legala) krav via de metoder som använts för att uppnå kravöverensstämmelse

rigoröst angreppssätt med avseende på både utveckling och testning

säkerhetsanalys

redundant arkitektur och metoder för att säkerställa denna arkitektur

fokus på kvalitet

hög kvalitetsnivå på dokumentationen (djup och bredd)

högre nivå på dokumentationskrav för att underlätta processrevisioner.

Se avsnitt 3.11.3 för specifika ledningsfrågor associerade med säkerhetskritiska system.

1.3.2.1 Överensstämmelse med Föreskrifter

De flesta typer av säkerhetskritiska system påverkas av någon typ av statliga, internationella eller områdesspecifika föreskrifter och/eller standarder (se också avsnitt 8.2 Överväganden för Standarder). Dessa föreskrifter och standarder ställer antingen krav på utvecklingsprocessen och organisationsstrukturen, eller på produkten som utvecklas.

För att demonstrera överensstämmelse med krav på utvecklingsprocess eller organisationsstruktur kan det räcka med revisioner och organisationsscheman,

För att demonstrera överensstämmelse med krav på det utvecklade systemet (produkten), är det nödvändigt att visa att varje krav har hanterats på ett adekvat sätt. I dessa fall måste man kunna påvisa total spårbarhet från krav till bevis för att kravet är uppfyllt! Denna typ av krav påverkar styrning av utvecklingsarbetet, val av utvecklingslivscykel, testaktiviteter och kvalificering/certifiering (oftast av en oberoende auktoriserad instans) genom hela utvecklingsprocessen.

1.3.2.2 Säkerhetskritiska System & Komplexitet

Många komplexa system och system av system har säkerhetskritiska aspekter. Ibland är inte säkerhetsaspekterna uppenbara på lägre systemnivåer (eller delsystem) utan bara på högre nivåer när det komplexa systemet byggs ihop (exempel på dylika system är: styrsystem för flygplan och flygledningskontrollsystem).

Ytterligare en illustration: en router är inte ett kritiskt system i sig, men kan bli det om den behövs för kritisk information, t.ex. i medicinska system som använder telekommunikation.

Riskhantering, som minskar sannolikheten för eller påverkan av en risk, är oumbärlig vid utveckling och testning av säkerhetskritiska system (jmf kapitel 3). Utöver riskhantering används dessutom ofta ”Failure Mode and Effects Analysis (FMEA)” (se avsnitt 3.10) och ”Software Common Cause Failure Analysis” i detta sammanhang.




1.4 Mätetal & Mätning

En mängd mätetal (typ av mätning, sort, enhet) med associerade mätvärden (faktiska värden) bör användas under hela livscykeln för programvaruutveckling för att hålla koll på olika aspekter av utvecklingen. Exempel på mätetal är planerade aktiviteter, täckningsgrad, arbetsbelastning, osv. För många mätetal är det fördelaktigt att fastsälla en uppskattad utveckling och sen jämföra den faktiska utvecklingen hos det aktuella mätetalet mot uppskattningen.

Exempel på aspekter som kan användas för kontroll av utvecklingen inkluderar

1. tidsplan, överensstämmelse med plan och planens utveckling över tiden 2. krav, deras utveckling och påverkan på tidsplaner, resurser och aktiviteter 3. arbetsbelastning och resursutnyttjande samt deras utvecklingar över tiden 4. milstolpar med beskrivningar av deras omfattningar och deras utveckling över tiden 5. kostnader, faktiska och planerade fram till slutförande av aktiviteter 6. risker och aktiviteter för att minska/eliminera deras påverkan, samt utvecklingen av riskerna

över tiden 7. upptäckta defekter, korrigerade defekter samt tidsåtgång för korrigeringar.

Genom att använda lämpliga mätetal kan testare rapportera data på ett konsekvent sätt till sin ledning och dessutom kan uppföljning av uppnådda resultat ske på likartat sätt under projektet.

Följande tre områden måste man ta hänsyn till

Definiering av mätetal: Ett begränsat antal användbara mätetal bör definieras. När dessa väl bestämts måste man komma överens med alla intressenter om hur dessa mätetal ska tolkas. På så sätt kan man undvika senare diskussioner om vad uppmätta mätvärden egentligen betyder. Mätetal kan definieras relaterade till process- eller aktivitetsmål, för komponenter eller system, för individer eller för team. Det finns en tendens att definiera och använda för många mätetal i stället för att välja de mest lämpliga.

Hantering av mätvärden: Insamling, rapportering och sammanställning av mätvärden bör automatiseras så mycket som möjligt dels för att minska tiden som läggs ner på att samla in rådata och dels för att minska risken för fel Variationer i insamlade data över tid kan vara tecken på att den tolkning som man kommit överens om under definitionsfasen inte är korrekt.

Rapportering av mätetal: Ett mål med att mäta är att förse ledningen med projektets aktuella status. Presentationer kan antingen visa ögonblicksbilder av mätetal just nu eller visa deras utveckling över tid så att trender kan analyseras.




1.5 Etik

Att vara programvarutestare innebär att man i bland får ta del av information av konfidentiell natur samt att man jobbar under tystnadsplikt. Detta gör att etiska principer är nödvändiga, bland annat för att säkra att information inte används på ett otillbörligt sätt. Med vedertagna etiska principer för ingen-jörer från ACM och IEEE som underlag, har ISTQB® fastslagit följande etiska principer:

ALLMÄNHETEN - Certifierade programvarutestare skall handla i allmänhetens intresse. KUND OCH ARBETSGIVARE - Certifierade programvarutestare skall agera i kunds och arbets-

givares intresse, i överensstämmelse med allmänhetens intresse. PRODUKT - Certifierade programvarutestare skall försäkra sig om att de leverabler de tillhanda-

håller (för produkter och system som de testar) motsvarar högsta möjliga professionella standard.

OMDÖME - Certifierade programvarutestare ska upprätthålla integritet och oberoende sina professionella omdömen.

LEDNING - Certifierade testledare och testkoordinatorer inom programvaruutveckling skall bidra med och främja etiska tillvägagångssätt vid ledningen av programvaruprojekt.

YRKESROLL - Certifierade programvarutestare skall främja integriteten och anseendet för testyrket i överensstämmelse med allmänhetens intresse.

KOLLEGOR - Certifierade programvarutestare skall vara rättvisa mot och stötta sina kollegor samt främja samarbete med programvaruutvecklare.

SJÄLV – Certifierade testare skall delta i ett livslångt lärande avseende sitt yrkes praxis och främja ett etiskt tillvägagångssätt gentemot yrkets praxis.




2. Testprocesser

Begrepp:

avslutskriterier, BS 7925-2, IEEE 829, slutlig testrapport, testavslut, testdesign, testexekvering, testfall, testimplementering, testlogg, testplanering, testprocedur, testskript, teststyrning, testvillkor

2.1 Inledning

I kursplanen för ISTQB® certifierad testare grundnivå beskrivs innehållet i en grundläggande testprocess genom följande aktiviteter:

Planering och Uppföljning

Analys och Design

Implementering och Exekvering

Utvärdering av avslutskriterier och Rapportering

Testavslutningsaktiviteter

Aktiviteterna kan utföras sekventiellt eller delvis parallellt. T.ex. kan analys och design genomföras parallellt med implementering och exekvering medan de övriga aktiviteterna genomförs sekventiellt.

Då testledning är en viktig del av testprocessen, är innehållet i detta kapitel centralt för testledare för att framgångsrikt kunna leda testprojekt. För Testanalytiker och Tekniska testanalytiker är kunska-perna uppnådda på grundnivån i stort sätt tillräckliga med undantag för aktiviteterna som ingår i testanalys och designsteget. De nödvändiga kunskaperna för dessa uppgifter täcks generellt in i detta avsnitt och mer detaljerat i kapitel 4 Testtekniker och kapitel 5 Testning av Programvaruegenskaper.

2.2 Testprocessmodeller

Processmodeller utgör approximationer och abstraktioner. Testprocessmodeller fångar inte upp alla de komplexa problem, alla nyanser och aktiviteter som varje projekt ställs inför i en verklig situation. Modellerna skall betraktas som hjälpmedel för att förstå och organisera testarbetet, inte som absoluta sanningar med regler ristade i sten.

Även om denna kursplan använder sig av processen beskriven i kursplanen för ISTQB® certifierad testare grundnivå (se föregående avsnitt för en översikt) som ett genomgående exempel finns det andra användbara testprocessmodeller. Tre av dessa listas nedan. De är alla både testprocess-modeller och testförbättringsmodeller (Practical Software Testing inbegriper Test Maturity Model) och definieras utifrån de testmognadsnivåer de stödjer. Alla tre testprocesser samt TPI® behandlas mer detaljerat i avsnitt 8.3 Test Improvement Process.

Practical Software Testing – Test Maturity Model [Burnstein03]

Critical Testing Processes [Black03]

Systematic Test and Evaluation Process (STEP)




2.3 Testplanering & Teststyrning

Detta avsnitt fokuserar på planering och styrning av testprocesser.

Det mesta av testplaneringen är förlagd till början av testarbetet. Uppgiften består av att identifiera och implementera de aktiviteter och de resurser som krävs för att klara uppgiften och uppfylla de mål som identifierats och finns dokumenterade i projektbeskrivning och teststrategin.

Riskbaserad testning (se kapitel 3 Testledning) bör användas som underlag till testplanerings-processen. Riskbaserad testning identifierar produktrisker, vilka kan ligga till grund för planering av en viss aktivitet. Till exempel, om man upptäcker att allvarliga defekter ofta hittas i designspecifikatio-nerna kan användandet av riskbaserad testning under testplaneringsprocessen resultera i att ytterligare statisk testning (granskningar) av designspecifikationerna planeras in, innan kodningen utförs. Riskbaserad testning tillhandahåller också information om hur testplaneringsprocessen skall prioritera testaktiviteterna relativt varandra.

Komplexa beroenden, inklusive många-till-många beroenden kan finnas mellan testbasen, testvill-koren, testfallen och testprocedurerna. Dessa beroenden behöver utredas för att testplanering och teststyrning ska kunna utföras på ett effektivt sätt.

Teststyrning skall utföras kontinuerligt. Detta inbegriper att jämföra det faktiska utfallet med planen och att rapportera statusen, inklusive avvikelser från planen. Teststyrning används för att hjälpa testprojektet att uppfylla det uppdrag, de strategier och de mål som satts upp. Teststyrning inkluderar även att vid behov planera om och göra nödvändiga uppdateringar av testplanen.

Indata till teststyrning är inte bara information från testerna som utförs utan även information om eventuella förändringar i villkoren för projektet eller åtagandet. Till exempel, om dynamisk testning indikerar att det finns en mängd defekter i ett område som inte troddes innehålla defekter eller om testexekveringsperioden måste kortas pga. för sent teststart, så måste riskanalysen och testplan-eringen i båda fallen omarbetas. Resultatet av en sådan omarbetning kan vara en omprioritering av tester eller en omallokering av det återstående testarbetet.

Innehållet i testplaneringsdokument gås igenom i kapitel 3 Testledning.

Några mätetal som vanligen används under testplanering och teststyrning är:

risker och testtäckningsgrad

information om de upptäckta felen

planerad tid jämfört med faktisk tidsåtgång för de olika testaktiviteterna.


Under testplaneringen identifieras och formuleras ett antal testmål. Testanalys och testdesign använder dessa testmål för att:

identifiera testvillkoren

skapa testfall som täcker alla de identifierade testvillkoren.

De prioriteringskriterier som formulerats via testplaneringens riskanalys skall beaktas under hela processen, från analys och design till implementering och exekvering.

2.4.1 Identifiering av Testvillkor

Identifieringen av testvillkor bygger på en analys av de, i testbasen, ingående informationskällorna. Analysen baseras även på testmålen beskrivna i testplanen och genomförs med hjälp av testtekniker och metoder beskrivna i teststrategin och/eller testplanen.




Nivån och strukturen på testvillkoren bör baseras på testobjektets funktionella och icke funktionella egenskaper, t.ex. med hjälp av följande faktorer.

1. Testbasens detaljeringsgrad: högnivåkrav kan inledningsvis generera högnivåtestvillkor, från vilka lågnivåtestvillkor kan härledas. Betrakta till exempel testvillkoret: ”Visa att skärmbild X fungerar”, vilket via härledning kan resultera i lågnivåtestvillkoret ”Visa att sidan X inte accepterar ett kontonummer som är en siffra kortare än numret borde vara”.

2. De produktrisker man väljer att hantera. T.ex. kan högriskfunktioner kräva att detaljerade lågnivåtestvillkor definieras.

3. Befintliga krav på spårbarhet och rapportering. 4. Om beslut tagits att arbeta enbart med testvillkor och inte utveckla testfall t.ex. vid informell

testning.

2.4.2 Framtagning av Testfall

Testfall designas genom att applicera de testtekniker (se kapitel 4) som fastställts i teststrategin på testvillkoren. Testfallen skall vara spårbara till de krav som testas och möjliga att verifiera. Dessutom skall testobjektets beteende, som resultat av ett exekverat testfall, vara möjligt att återupprepa genom att exekvera testfallet en gång till.

Under testfallsdesignen skall följande identifieras:

miljö- och tillståndsvillkor som måste vara uppfyllda före testexekveringen

krav på testdata

förväntat resultat och sluttillstånd.

Den stora utmaningen är oftast att identifiera det förväntade resultatet, dvs. vilken eller vilka testorakler som ska användas. Vid identifieringen av förväntat resultat måste testaren dessutom tänka på i vilket sluttillstånd testobjekt och testmiljö skall befinna sig i och inte bara vilka utdata som ska presenteras. Om testbasen är klart definierad är detta, i teorin, ganska enkelt. Men i verkligheten är testbasen ofta vagt eller motsägelsefullt formulerad och viktiga områden kan ha låg täckningsgrad eller helt sakna testbas. I fall som dessa har testaren behov av specialistkompetens, antingen genom att besitta den själv eller ha tillgång till expertis. Även i de fall då testbasen är välspecificerad kan komplexa interaktioner med svåröversiktliga kombinationer av stimuli och svarsdata göra det svårt att förutse förväntade resultat. Därför kan testorakel vara nödvändiga också i dessa fall. Att exekvera tester där det inte finns någon möjlighet att kontrollera om resultatet är korrekt har litet eller inget värde. De kan istället ge upphov till oriktiga felrapporter och en falsk tilltro till systemet.

De aktiviteter som beskrivs ovan kan appliceras på alla testnivåer men testbasen kommer att variera beroende på nivå. Till exempel kan acceptanstester huvudsakligen vara baserade på krav-specifikationer, användningsfall och affärsprocesser, medan komponenttester till största delen bygger på detaljerade designspecifikationer.

Under arbetet med att utveckla testvillkor och testfall brukar resultaten dokumenteras i form av s.k. testartefakter. IEEE 829 är en dokumentationsstandard som bl.a. beskriver hur testartefakter ska dokumenteras. För aktiviteten testanalys och testdesign ingår de två dokumenten testdesign-specifikation och testfallsspecifikation. På motsvarande sätt täcks även aktiviteten testimplementering. I realiteten varierar graden av dokumentation av testartefakterna mycket. Den kan till exempel vara beroende av:

projektrisker (vad måste/behöver inte dokumenteras)

vilket “mervärde” dokumentationen tillför projektet

standarder som skall följas

den livscykelmodell som används (till exempel så försöker man i lättviktsprocesser att ersätta en del av den traditionellt använda dokumentationen med tät kommunikation).

kraven på spårbarhet från testbas via testanalys och testdesign till testfall.

Beroende på omfattningen av testningen, kan testanalys och testdesign fokusera på en större eller mindre del av testobjektets kvalitetsegenskaper Standarden ISO 9126 är bra referensmaterial i detta




avseende. När man testar system med ingående hårdvara kan det finnas ytterligare egenskaper som behöver beaktas.

Testanalys och testdesignaktiviteterna respektive granskningar och statisk analys kan förstärka varandra. Till exempel är en testanalys av kravspecifikationen ett utmärkt sätt att förbereda sig för ett kravgranskningsmöte. På samma sätt, bör testartefakter såsom testfall, produktrisker och testplaner granskas och analyseras statiskt.

Under testdesignen bör kraven på testinfrastrukturen detaljeras. Dock kan dessa i praktiken inte färdigställas före testimplementeringen. Notera att testinfrastrukturen inte bara består av testobjekt och testartefakter utan även av exempelvis lokaler, utrustning, personal, programvara, verktyg, kring-utrustning, användarbehörigheter och övrig utrustning för att testerna ska kunna genomföras.

Mätetal som vanligen används under testanalys och testdesign är:

procentuell andel av kraven som täcks av testvillkor

procentuell andel av testvillkoren som täcks av testfall

antal defekter hittade under testanalys och testdesign.


2.5.1 Testimplementering

Aktiviteten testimplementering innefattar att skapa testprocedurer (testskript) utifrån testfallen, att färdigställa testdata och testmiljö, samt att upprätta ett testexekveringsschema. Testimplementeringen innefattar även att kontrollera uttalade och underförstådda startkriterier för den testnivå man befinner sig på.

Testprocedurer bör prioriteras inbördes för att säkerställa att målen, beskrivna i teststrategin, uppnås så effektivt som möjligt. En möjlighet är, till exempel, att exekvera de viktigaste testprocedurerna först.

Detaljeringsgraden och därmed komplexiteten hos testimplementeringsarbetet påverkas av motsvarande detaljeringsgrad hos testartefakterna (testfall och testvillkor). I vissa fall finns det dess-utom regulatoriska krav att ha i beaktande. Ofta innebär detta att resultatet av testningen skall gå att bedöma med avseende på överensstämmelse med tillämpliga standarder såsom United States Federal Aviation Administration’s DO-178B/ED 12B.

Som beskrivs i avsnitt 2.4 ovan, så består testfall bland annat av testdata. I vissa fall kan de datamängder som krävs vara väldigt stora. Under testimplementeringsarbetet skapar testarna alla dessa data som kan bestå både av indata och av miljödata (data som behöver finnas i systemet innan testexekveringen). Ofta lagras dessa data i databaser och liknande lagringsutrymmen. Testarna skapar dessutom skript och andra datagenereringsmekanismer för att kunna generera data som skall skickas till systemet såsom inkommande last under testexekveringen.

Under testimplementeringsarbetet bör testarna även slugtgiltigt fastställa den ordning i vilken manuella och automatiska tester skall utföras. I de fall då testexekveringen skall ske automatiserat ingår även framtagning av testexekveringsplattform (även kallat test-harness) och testskript i testimplemente-ringen. Testaren bör noggrant undersöka om det finns beroenden mellan testfallen som kräver att dessa måste köras i en viss ordning. Beroenden med avseende på testmiljö och testdata skall också beaktas.

Testmiljön är ytterligare något som också kräver fokus under testimplementeringsfasen. Senast under denna fas bör testmiljön vara fullt uppsatt och verifierad så att testexekveringen kan starta utan problem. En ändamålsenlig miljö är en nödvändighet: Testmiljön måste vara tillräckligt flexibel och verklighetstrogen så att de defekter som är viktiga med avseende på testvillkoren kan hittas. Vidare skall testmiljön fungera normalt när inga felsymptom inträffar och tester skall kunna återupprepa om det krävs, till exempel under en senare testnivå.




Slutligen måste testarna under testimplementeringsfasen försäkra sig om att de som ansvarar för uppsättning och underhåll av testmiljön är utsedda och tillgängliga och att alla testartefakter, testsupportverktyg och tillhörande processer är på plats och färdiga att användas. Detta inkluderar konfigurationshantering, avvikelsehantering, testloggning och testledning. Dessutom måste testarna verifiera de procedurer som dels används för att samla och sammanställa de data som ligger till grund för att avgöra om avslutskriterierna har uppfyllts och dels avgör hur testresultaten rapporteras.

Det är klokt att balansera testimplementeringen genom att använda flera olika strategier. Till exempel kombineras ofta riskbaserade analytiska teststrategier med dynamiska teststrategier. På så sätt kan en del av tiden för testexekveringen användas för testning som inte följer förutbestämda skript.

Testning utan dokumenterade instruktioner bör inte vara ad hoc eller utan specifik inriktning eftersom det kan vara svårt att tidsuppskatta om det inte redan genomförs under bestämda tidsintervall (se SBTM). Över tiden har testare utvecklat en mängd olika erfarenhetsbaserade testtekniker (se avsnitt 4.4) såsom; attackbaserad testning [Whittaker03], felgissning [Myers79] och utforskande testning (exploratory testing). Testanalys, testdesign och testimplementering utförs fortfarande men huvud-sakligen under testexekveringen. När man använder sig av dessa erfarenhetsbaserade testtekniker utgör ofta resultatet från ett test underlag för analys, design och implementering av efterföljande tester. Dessa tekniker har fördelen av att vara lättviktiga och samtidigt effektiva när det gäller att upp-täcka fel. Detta kräver dock mycket erfarna och kunniga testare. Vidare kan tidsåtgången för dessa tekniker vara svår att uppskatta. Dessutom kan det vara svårt att få en god bild av täckningsgraden och det kan vara svårt att återupprepa ett test utan speciella verktyg, t.ex. vid regressionstestning.

2.5.2 Testexekvering

Testexekveringen startas så snart testobjekten levererats och startkriterierna för testexekveringen är uppfyllda. Testfall ska exekveras enligt testprocedurerna, men ett visst spelrum kan ges till testaren för att åstadkomma ytterligare täckning av testscenarier och beteenden som observeras under testningen och bedöms intressanta. Sådana avvikelser från testprocedurerna skall dokumenteras så att varje felsymptom som observeras kan återupprepas. Automatiserade tester följer sina instruktioner utan avvikelser.

Kärnan i testexekveringen är jämförelsen mellan det faktiska och det förväntade resultatet. Det är av största vikt att testarna fokuserar på denna jämförelse, annars kan felsymptom missas (falska positiva resultat) eller ett korrekt resultat tolkas som ett felsymptom (falska negativa resultat). Det jobb som lagts ner på testdesign och testimplementering är då bortkastat. När förväntat och faktiskt resultat inte överensstämmer definieras detta som en incident. Incidenter måste undersökas noggrant för att fastslå orsaken (dvs. om incidenter beror på en defekt i testobjektet eller har andra orsaker) och dessutom samla så mycket information som möjligt för att underlätta lösningen av det eventuella problemet. Avvikelsehantering gås igenom i detalj i kapitel 7.

När en incident inträffat bör även testspecifikationen undersökas för att säkerställa att den är korrekt. En testspecifikation kan vara felaktig på ett flertal sätt, testdata kan vara felaktiga eller så kan testdokumentationen vara defekt. Dessutom kan testdokumentationen vara felaktigt tolkad och testningen felaktigt utförd. Om testspecifikationen är felaktig ska den rättas och testerna köras om. Även ändringar i testbasen och testobjekten kan göra att testspecifikationen blir felaktig. Även om ett testfall redan många gånger har använts med framgång måste testare vara medvetna om att resultaten från en testkörning ändå kan vara felaktiga pga. att testerna följer en icke uppdaterad testspecifikation.

Under testexekvering måste testresultaten loggas på ett lämpligt sätt. Man kan vara tvungen att köra om redan körda tester på grund av att loggade resultat saknas. Detta resulterar i ineffektivitet och förseningar. (Notera att lämplig testloggning även kan vara till hjälp vid mätning av täckningsgrad och skapande av återupprepbarhet under dynamisk testning.) Eftersom testobjekt, testartefakter och testmiljö alla kan förändras måste även versionsinformation loggas.

Testloggning ger en kronologiskt ordnad beskrivning av de relevanta detaljerna från testexekveringen.




Loggning av resultat ska ske både för separata testfall och för händelser som inträffar under testexekvering, vilka kan bidra till kvalitetssäkringen. För varje test skall både dess unika identifiering och status loggas under testexekveringen. Tillräckligt med information skall loggas för att kunna mäta täckningsgrad och för att kunna dokumentera orsakerna till förseningar och avbrott i testningen. Dessutom måste information loggas för att stödja teststyrning, testprogressrapportering, jämförelser med avslutskriterier samt testprocessförbättring.

Detaljeringsgraden i och utförandet av loggningen varierar med testnivå och teststrategi. Betrakta till exempel automatiserad komponenttestning. I detta fall skapas och sammanställs loggningsinforma-tionen till största delen automatiskt genom att testskript och testverktyg innehåller stöd för detta. Om manuell acceptanstestning tillämpas kan testexekveringen dokumenteras av testarna och en test-ledare samlar in och sammanställer informationen. I vissa fall kan loggningens struktur och innehåll påverkas av regulatoriska krav eller en kommande revision. Motsvarande krav på struktur m.m. kan även påverka testimplementeringen.

IEEE 829 standarden innehåller en beskrivning av den information som bör samlas i testloggen.

dokumentets identitetsbeteckning

beskrivning

aktivitets- och händelseinformation

Även BS-7925-2 innehåller en sådan beskrivning.

I vissa fall kan användare eller kunder delta i testexekveringen. En orsak till att ta med användare eller kunder i testexekveringen kan vara att man vill öka förtroendet för produkten. En förutsättning för att man ska lyckas skapa förtroende för produkten är att testerna inte resulterar i någon större mängd avvikelser. I de tidiga testnivåerna är testfallen oftast framtagna med syfte att hitta många fel, varför denna förutsättning sällan är giltig i dessa sammanhang. Däremot kan det gälla under t.ex. acceptans-testning, där man ofta vill fokusera på att bygga förtroende.

Mätetal som vanligen används under testimplementering och testexekvering kan inkludera

procentuell andel av testmiljöerna som konfigurerats

procentuell andel av testdata som laddats

procentuell andel av testvillkor och testfall som exekverats

procentuell andel av testfall som automatiserats.


Dokumentation och rapportering vid övervakning och styrning av testprogressen beskrivs i detalj i avsnitt 3.6. Från ett testprocessperspektiv säkerställer uppföljning av testprogressen att rätt information samlas in för att klara rapporteringskraven. Detta inkluderar att mäta hur projektet framskrider mot testavslut.

Mätetal för att övervaka testprogress och testavslut har en koppling till de överenskomna avsluts-kriterierna (beslutade under testplanering). Avslutskriterierna kan innehålla en, flera eller alla av följande

Antal testvillkor, testfall eller testspecifikationer som planerats respektive exekverats, oftast uppdelade i godkända och underkända.

Totala antalet defekter som hittats, uppdelade på åtgärdade resp. kvarstående samt klassade med avseende på allvarlighet och prioritet.

Antal förändringar (ändringsbegäran) som skapats, accepterats (införts) resp. testats.

Planerade kontra faktiska utgifter.

Planerad kontra faktisk tidsåtgång.

Identifierade risker fördelade på hanterade med testaktiviteter resp. kvarvarande.

Procentuell andel av testtiden som förlorats pga. av stoppande händelser.

Objekt som omtestats.

Total planerad kontra effektiv testtid.




IEEE 829 beskriver en slutlig testrapport (Test Summary Report) bestående av nedanstående avsnitt:

Dokumentets identitetsbeteckning

Sammanfattning

Avvikelser från plan

Utvärdering av testomfattningen

Summering av resultaten

Utvärdering

Sammanfattning av aktiviteter

Godkännanden

Testrapporter kan skrivas både för varje testnivå och för hela projektet då all testning är avslutad.

2.7 Testavslutningsaktiviteter

När testexekveringen är fullbordad skall viktiga resultat och testartefakter sammanställas och för-medlas till rätt mottagare eller arkiveras. Dessa aktiviteter kallas gemensamt för testavslutsaktiviteter. Det finns fyra huvudgrupper av testavslutningsaktiviteter:

1. Säkerställande att allt testarbete verkligen har fullbordats. Som exempel; alla planerade testfall antingen har exekverats eller medvetet skippats. Ett annat exempel är att alla defekter antingen har fixats och testats om, skjutits upp till kommande utgåvor eller accepterats som permanenta begränsningar.

2. Leverans av användbara och värdehöjande produkter till aktuella mottagare. Till exempel bör kända defekter som skjutits upp eller accepterats kommuniceras till användare och supportpersonal. Testfall, inklusive regressionstestsviter, och testmiljöspecifikationer levereras till de ansvariga för underhållstestningen.

3. Genomförande av tillbakablicksmöten (Lessons Learned) där viktiga erfarenheter (både från testprojektet och från hela programvaruutvecklingscykeln) skall dokumenteras och planer tas fram för att förhindra att samma problem inte återupprepas i kommande projekt. Om ett problem inte kan lösas helt finns möjlighet att se till att höjd tas för problemet i kommande planer. Exempel på ämnen som kan behandlas vid tillbakablicksmöten är: a. Sent upptäckta kluster av defekter, vilka kan ha fått testteamet att inse att det vid

framtida produktriskanalyser behövs en bredare representation från användarsidan. b. Felaktiga estimat som i framtida projekt behöver beaktas och vilkas underliggande

orsaker måste utredas. T.ex. om det var testningen som var ineffektiv eller om det var den estimerade tiden som var alldeles för låg.

c. Trendanalys, eller orsaks- och verkansanalys, av defekter som genomförs genom att relatera defekter till varför och när de inträffade samt identifiering av eventuella trender. T.ex. kan sena ändringsbegäran ha påverkat kvaliteten på analys- och utvecklingsarbetet. Saknade rutiner på en testnivå, där defekter skulle ha hittats tidigare och mer kostnadseffektivt, kan ha medfört att vissa aktiviteter inte genomförts på ett korrekt sätt i ett misslyckat försök att spara tid. Defekttrender bör även undersökas i ljuset av ny teknologi, personaländringar och bristande kompetens.

d. Identifiering av möjliga processförbättringar. 4. Arkivering av resultat, loggar, testrapporter samt övriga dokument och arbetsrelaterade

produkter i samma konfigurationshanteringssystem som det utvecklade systemet självt. Som exempel bör testplan och projektplan sparas i ett lämpligt arkiv med en klar koppling till den version av systemet de användes för.

Trots att dessa aktiviteter är viktiga glöms de ofta bort. Därför bör de vara explicit uttryckta i test-planen.

Det är vanligt att en eller flera av dessa aktiviteter inte utförs, vanligtvis beroende på en för tidig upplösning av teamet, resursbrist eller pressade tidsplaner i efterföljande projekt.

I projekt som bedrivs inom ramen för ett kontrakt, såsom anpassad utveckling, bör kontraktet preci-sera vilka uppgifter som ingår.




Mätetal som vanligen används under testavslutningsaktiviteterna inkluderar

procentuell andel testfall som har utförts under testexekveringen (täckningsgrad)

procentuell andel testfall som har arkiverats för återanvändning

andel testfall som automatiserats och andel som skall automatiseras

procentuell andel testfall som kan användas vid regressionstestning

procentuell andel olösta felrapporter som har lämnats utan åtgärd (t.ex. skjutits upp, stängts eller överförts till en förändringsbegäran)

procentuell andel identifierade testartefakter som blivit arkiverade.




3. Testledning

Begrepp:

FMEA, nivåtestplan, produktrisk, projektrisk, riskanalys, riskbaserad testning, riskhantering, riskidentifiering, riskminskning, risknivå, risktyp, schemaläggning av testaktiviteter, sessionsbaserad testledning, testestimering, testledning, testnivå, testplan, testmängdsanalys (test point analysis) , , testpolicy, teststrategi, teststyrning, testövervakning, wide band delphi, övergripande testplan

3.1 Inledning

Det här kapitlet beskriver testledarens ansvarsområden.

3.2 Testledningsdokumentation

Testledningsarbete består ofta av framtagande av dokumentation. Benämningen av och syftet med dessa testledningsdokument brukar variera, men följande testledningsdokument är vanligt före-kommande inom organisationer och projekt.

Testpolicy: beskriver en organisations testfilosofi (och eventuell kvalitetssäkring).

Teststrategi (alt. testhandbok): beskriver en organisations testmetoder, inklusive produkt- och projektriskhantering, testarbetets uppdelning i olika steg, nivåer eller faser samt de huvud-aktiviteter som är associerade med testarbetet.

Övergripande testplan (alt. projekttestplan eller testapproach): beskriver tillämpningen av teststrategin för ett specifikt projekt, de testnivåer som kommer att utföras och förhållandet mellan dessa testnivåer.

Nivåtestplan (alt. fastestplan): beskriver de särskilda aktiviteter som ska utföras inom varje specifik testnivå (en nivåtestplan per testnivå). Nivåtestplanerna innehåller en mera utförlig beskrivning av de testnivåer som dokumenterats i den övergripande testplanen.

I vissa organisationer och i vissa projekt förekommer kombinationer och varianter av dessa dokument. Dessutom kan innehållen i dessa dokument ingå som delar i andra dokument eller helt enkelt vara del av den ”tysta kunskap” som finns i varje organisation, dvs. vara odokumenterade. Större organisationer samt organisationer som ställer höga formella krav tenderar att använda sig av alla dessa dokument i skriven form medan mindre företag och företag som arbetar mer informellt producerar dessa dokument i mindre omfattning. I denna kursplan beskrivs varje dokumenttyp separat även om det i praktiken är organisations- och projektkontext som styr utformningen av dokumentationsstrategin.

3.2.1 Testpolicy

Testpolicyn beskriver en organisations testfilosofi (och eventuellt kvalitetssäkring). Den är kommunicerad, antingen skriftligt eller genom ledningens direktiv, och beskriver organisationens målsättning med testarbetet. Policyn kan tas fram av IT-, Forskning och Utvecklings- eller Produkt-utvecklingsavdelningen. Oavsett vilka som tar fram testpolicyn bör den avspegla organisationens värderingar och mål med testarbetet.

I vissa fall kan testpolicyn vara ett komplement till eller en del av en mera omfattande kvalitetspolicy, vilken i så fall beskriver organisationens syn på kvalitetsarbete som helhet.




En testpolicy bör vara ett kortfattat, övergripande dokument som:

tillhandahåller en definition av testning, som t.ex. att testning skapar förtroende för att systemet fungerar som det är tänkt och att testarbetet leder till att defekter upptäcks

formulerar en grundläggande testprocess som t.ex. testplanering och styrning, test analys och design, testimplementering och exekvering, utvärdering av avslutskriterier för testerna och testrapportering samt testavslutningsaktiviteter

beskriver hur utvärdering av testningens effektivitet ska gå till, t.ex. procentuellt antal defekter som upptäcks (DDP = Defect Detection Percentage) och relativ kostnad för defekter som hittas under testningen jämfört med kostnad för att hantera defekter efter att produkten frisläppts

definierar önskade kvalitetsmål, t.ex. i termer av tillförlitlighet (t.ex. mätning av felfrekvens) eller användbarhet

specificerar aktiviteter för testprocessförbättringar, t.ex. tillämpning av Test Maturity Model eller Test Process Improvement modellen, alternativt genomförande av rekommendationer erhållna genom återmatning av erfarenheter från tidigare projekt.

Testpolicyn kan beskriva testaktiviteter såväl för nyutveckling som för underhåll av redan frisläppta system. Den kan också referera till en standard för testterminologi som ska användas av hela organisationen.

3.2.2 Teststrategi

Teststrategin beskriver en organisations testmetoder, inklusive produkt- och projektriskhantering, testningens indelning i olika nivåer eller faser samt de huvudaktiviteter som är associerade med testarbetet. Innehållet i teststrategin inklusive process- och aktivitetsbeskrivningar ska vara konsis-tenta mot innehållet i testpolicyn. Teststrategin tillhandahåller generella krav på testverksamheten som gäller för hela organisationen eller för ett eller flera projekt.

Som beskrivs i kursplan certifierad testare, grundnivå, kan teststrategier (även benämnda testan-greppssätt) klassificeras efter när testdesignen startar.

Förebyggande strategier (Preventative strategies): testdesignen startar tidigt för att förhindra defekter.

Reaktiva strategier (Reactive strategies): testdesignen startar efter att programvaran eller systemet är producerat.

Typiska strategier (eller tillvägagångssätt) är:

analytiska strategier, såsom riskbaserad testning

modellbaserade strategier, såsom driftsprofilering

metodiska strategier, såsom egenskapsbaserad testning

process- eller standardstyrda strategier, såsom att följa standarden IEEE 829 vad beträffar testdokumentationen

dynamiska och heuristiska strategier, såsom att använda defekt- eller attackbaserad testning

konsultativa strategier, såsom användarstyrd testning

strategier för regressionstestning, såsom omfattande automatisering.

Strategier kan kombineras och skräddarsys för att passa en specifik verksamhet eller ett projekt. De valda strategierna måste överensstämma med både organisationens behov och förutsättningar.

I många fall tydliggör teststrategin projekt- och produktrisker och beskriver hur testprocessen hanterar dessa risker. I sådana fall ska kopplingen mellan risker och testning förklaras tydligt då testuppläggen utgör alternativ till hur dessa risker kan reduceras och hanteras.

Teststrategin kan beskriva vilka testnivåer som ska ingå. I dessa fall bör den innehålla riktlinjer på en hög nivå för val av startkriterier och avslutskriterier för respektive testnivå. Dessutom bör förhållandet mellan de olika testnivåerna (t.ex. mål för testtäckningsgrad) beskrivas.




Teststrategin kan också beskriva följande punkter.

integrationsprocedurer

testdesigntekniker

grad av oberoende (vilket kan variera beroende på testnivå).

obligatoriska och valfria (rådgörande) standarder

testmiljöer

testautomatisering

återanvändning av testartefakter

omtestning och regressionstestning

teststyrning och rapportering

testmätningar och mätetal

avvikelsehantering

tillvägagångssätt för konfigurationshantering av testartefakter

Både kortsiktiga och långsiktiga teststrategier bör definieras. Det kan göras i ett eller flera dokument. Olika teststrategier är lämpliga för olika organisationer och projekt. T.ex. kan en mer genomarbetad strategi behövas för informationssäkerhets- eller säkerhetskritiska applikationer jämfört med andra typer av applikationer.

3.2.3 Övergripande Testplan

Den övergripande testplanen beskriver tillämpningen av teststrategin för ett specifikt projekt, de testnivåer som kommer att utföras och förhållandet mellan dessa testnivåer. Den övergripande test-planen bör överrensstämma med testpolicyn och strategin. Om planen inte stämmer överrens med strategin i alla delar ska varje avvikelse eller undantag förklaras Den övergripande testplanen bör komplettera projektplanen eller verksamhetshandboken genom att i mer detalj beskriva omfattningen av den i projektet planerade testningen.

Innehållet och strukturen i den övergripande testplanen kan variera beroende på organisationen, dess dokumentionsstandard och projektets krav på formalism. Dock är följande innehåll vanligt i den över-gripande testplanen.

Vilka delar av systemet som ska testas respektive inte testas.

Vilka egenskaper som ska testas respektive inte testas.

Testschema och budget, vilken ska överensstämma med projektets eller verksamhetens budget.

Testexekveringscykler och deras förhållande till leveransplanen för programvaran.

Affärsnyttan och värdet av testningen.

Beroenden mellan och leverabler till och från testningen och övriga inblandade avdelningar och intressenter.

Definitioner av vad varje beskriven testnivå omfattar respektive inte omfattar.

För varje testnivå, beskrivningar av specifika start- och avslutskriterier, samt kriterier för tillfälligt avbrytande och återupptagande av testverksamheten. Dessa kriterier ska även spegla förhållandet mellan testnivåerna.

Projektrisker för testverksamheten.

För små projekt eller verksamheter, där bara en testnivå är formaliserad, är oftast den övergripande testplanen och testplanen för denna enda formaliserade testnivå kombinerad i ett och samma dokument. Till exempel i en situation där systemtest är den enda formaliserade testnivån, med informell komponent- och integrationstestning, vilken skall utföras av utvecklarna samt informell acceptanstestning, vilken skall utföras av kunderna som del i en betatestnings process. Då kan systemtestplanen innehålla de element som omnämnts i detta avsnitt.

Vanligen har testverksamheten dessutom beroenden till andra aktiviteter inom projektet. Om sådana aktiviteter inte är tillräckligt dokumenterade, särskilt vad beträffar deras respektive påverkan och förhållande till testningen, kan denna information inkluderas i den övergripande testplanen (eller i




passande nivåtestplan). T.ex. om konfigurationshanteringsprocessen inte är dokumenterad, bör testplanen specificera hur testobjekten ska levereras till testgruppen.

3.2.4 Nivåtestplan

Nivåtestplanen beskriver de särskilda aktiviteter som ska utföras inom varje testnivå mera utförligt än i den övergripande testplanen, där så är nödvändigt. Den innehåller en mer detaljerad tidsplan samt detaljer kring aktiviteter och milstenar som inte nödvändigtvis täcks upp av den övergripande testplanen. Dessutom bör nivåtestplanerna täcka in detaljer om hur standarder och mallar påverkar testspecifikationsarbetet på de olika testnivåerna.

Inom mindre formella projekt eller organisationer är oftast en nivåtestplan det enda testlednings-dokument som skrivs. I sådana fall kan en del av den information som nämns i avsnitt 3.2.1, 3.2.2 och 3.2.3 täckas av detta dokument.

3.3 Mallar för Dokumentation av Testplaner

Som nämns i avsnitt 3.2.3, kan innehållet och strukturen i den övergripande testplanen variera beroende på organisation, dess dokumentationsstandard och projektets grad av formalism. Många organisationer utvecklar eller anpassar mallar för att säkerställa att testplanerna blir likformiga och läsbara för alla projekt och verksamheter. Färdiga mallar för dokumentering av testplaner finns att tillgå.

IEEE 829 ”Standard for Software Testing Documentation” innehåller mallar för testdokumentation och vägledning för hur de ska tillämpas, inklusive framtagande av testplaner. Standarden tar också upp det närbesläktade ämnet leverans av testartefakter (t.ex., leverans av programvara till testverk-samheten).

3.4 Testestimering

Testestimering är den ledningsaktivitet som resulterar i ungefärliga kostnader och måldatum för de aktiviteter som ingår i en specifik verksamhet eller ett projekt. Bra estimeringar

representerar den samlade visdomen hos erfarna praktiker och har stöd hos dem som är involverade

innehåller detaljerade förteckningar över kostnader, resurser, aktiviteter och personer som är involverade

innehåller de mest troliga uppskattningarna av kostnad, arbetsinsats och tidsåtgång för varje aktivitet.

Trots att god praxis för estimering är väl etablerat, är estimeringsarbetet när det gäller aktiviteter för utveckling av programvara och system sedan länge känt för att vara fyllt med både tekniska och politiska svårigheter. Testestimering är tillämpningen av denna goda praxis för de testaktiviteter som tillhör ett projekt eller en verksamhet.

Samtliga aktiviteter som ingår i testprocessen, t.ex. testplanering och styrning, testanalys och design, testimplementering och exekvering, testutvärdering och rapportering, samt testavslutningsaktiviteter ska omfattas av testestimeringen. Generellt är estimaten för kostnad, arbetsinsats och speciellt tidsåtgång för testexekvering de mest intressanta för ledningen, eftersom det är vanligt att testexekveringen ingår i projektets kritiska linje. Om kvaliteten hos programvaran är låg eller okänd har dock estimeringen av testexekveringen en tendens att vara svår att genomföra och de resultat som ändå framkommer är ofta opålitliga. Förutom tid och pengar är det vanligt att uttrycka estimat för testexekveringen i termer av antalet testfall som krävs. Antaganden som görs under estimeringen bör dokumenteras som en del av estimeringen.




Testestimering bör ta alla faktorer i beaktande som kan påverka kostnader, arbetsinsatser och tidsåtgång för testaktiviteterna. Dessa faktorer inkluderar (men är inte begränsade till) följande:

önskad kvalitetsnivå hos systemet

storleken på systemet som ska testas

historik från tidigare testprojekt (vilket även kan innehålla mätdata)

processfaktorer, däribland: utveckling eller underhåll av teststrategin, livscykel eller processmognad samt exaktheten hos tidigare projektestimeringar

materiella faktorer, däribland: o testautomatisering och verktyg, testmiljö, testdata, utvecklingsmiljö(er) o projektdokumentation (t.ex. krav, designspecifikationer etc.) o återanvändbarheten hos de produkter som används i testarbetet

mänskliga faktorer, däribland: o chefer och tekniska ledare o styrelsens och högre ledningens engagemang och förväntningar o färdigheter, erfarenhet och attityder inom projektgruppen o kontinuitet inom projektgruppen o projektgruppens förhållanden till andra grupper och intressenter o underhåll av test- och felsökningsmiljön o tillgång till kompetenta konsulter o domänkunskap

Andra faktorer som kan påverka testestimeringen är:

processens komplexitet

teknologi

organisation

antalet intressenter i testningen

antal testteam och speciellt deras geografiska spridning

markant ökning av resursbehoven

utbildning och behov av vägledning

införskaffande eller utveckling av nya verktyg

införande eller användning av verktyg

testtekniker

specialtillverkad hårdvara

antal testartefakter

krav på hög detaljeringsgrad i testspecifikationer, speciellt vid en okänd dokumentations-standard

komplex timing av komponentleveranser, speciellt för integrationstest och testutveckling

känsliga testdata (t.ex. data som är tidskänsliga)

Estimeringar kan utföras nerifrån och upp eller uppifrån och ner. Följande tekniker kan användas i testestimering:

intuition och gissningar

tidigare erfarenheter

Work Breakdown Structures (WBS)

gruppestimeringar (t.ex. Wide Band Delphi)

trepunktsestimering

testmängdsanalys (Test Point Analysis – TPA) [Pol02]

företagsstandarder och normer

procentandelen av det totala projektarbetet eller personalfördelning (t.ex. förhållandet testare-utvecklare)

organisatorisk historia och mätetal, däribland analysmodeller som estimerar antalet defekter, antalet testcykler, antalet testfall, medelansträngning per test samt antalet regressionstest-cykler




medelvärden för branschen och predikteringsmodeller såsom testmängd (test points), funktionsgrad (function points), antalet kodrader, uppskatttad utvecklingskostnad eller andra projektparametrar

De färdiga estimaten skall i de flesta fall levereras till ledningen tillsammans med en motivering (se avsnitt 3.7). Det är vanligt att ledningen inte accepterar de initiala estimaten. Då blir följden att förhandlingar behöver genomföras vilka kan leda till omarbetningar av estimaten. Under idealiska förhållanden representerar de slutliga estimaten den bästa möjliga balansen mellan organisations- och projektmål rörande kvalitet, tidsplan, budget och egenskaper som ska implementeras.

3.5 Schemaläggning av Testplanering

För att skapa en plan med hög kvalitet är det generellt viktigt att under planeringsarbetet identifiera och hantera de risker som är associerade med de planerade aktiviteterna. Planeringsarbetet kräver även att behoven av koordinering med övriga inblandade identifieras. Detta gäller även vid testplanering. Testplanering kan dessutom bidra med ytterligare nytta för projektet om avancerad planering utförts, baserat på testestimat innehållande:

identifiering och hantering av projektrisker och problem utanför själva testområdet

identifiering och hantering av produkt- (kvalitets)risker och problem före testexekveringen

identifierade problem i projektplanen eller andra arbetsprodukter inom projektet

Möjligheter att öka anslagen testpersonal, budget, satsning på och/eller tid för att uppnå högre kvalitet

identifiering av kritiska komponenter (och således få insikter om vikten av att dessa komponenter levereras tidigt)

Schemaläggning av testaktiviteter bör göras i nära samarbete med utveckling, eftersom testning i hög grad är beroende av utvecklingens leverans- och tidsplaner.

Om testplaneringsarbetet inte påbörjas förrän all nödvändig information finns tillgänglig, är det risk för att planen kommer för sent. Därmed riskerar man att gå miste om de fördelar som det innebär att börja testa tidigt. Börja med att ta fram en preliminär plan som innehåller de grova dragen. När ytterligare information finns att tillgå kan testplansförfattaren (oftast en testledare) lägga till den nya informationen till planen. Detta iterativa tillvägagångssätt för skapande, frisläppande och granskning av testplanen eller testplanerna gör även att dessa fungerar som medel för att främja samstämmighet, kommunikation och diskussioner om testning.

3.6 Övervakning & Styrning av Testprogress

Övervakning av testprogressen sker primärt inom följande fem områden:

produktrisker

defekter/avvikelser

testfall

täckningsgrad

förtroende

Produktrisker, defekter/avvikelser, testfall och täckningsgrad mäts och rapporteras oftast på, i förväg, överenskomna sätt i projektet eller i verksamheten. Företrädesvis är dessa mätningar relaterade till de definierade avslutskriterierna som fastställts i testplanen. Förtroende baseras oftast på subjektiva bedömningar, trots att det är mätbart genom undersökningar.

Mätetal relaterade till produktrisker omfattar:

antalet kvarvarande risker (inkl. risktyp och risknivå)

antalet minimerade risker (inkl. risktyp och risknivå).




Mätetal relaterade till defekter/avvikelser omfattar:

ackumulerat antal rapporterade (identifierade) defekter jämfört med ackumulerat antal lösta (avförda) defekter

genomsnittlig tid mellan två på varandra följande felsymptom eller frekvens med vilken felsymptom uppstår

kategorisering av defekter med avseende på specifika testelement eller komponenter; grundorsaker; källor; testutgåvor; fas; upptäckta eller avförda; och i en del fall även ägare

trender i tidsåtgång mellan felrapportering och lösning.

Mätetal relaterade till testfall omfattar:

totalt antal planerade, specificerade (utvecklade), genomförda, godkända, underkända, blockerade och skippade testfall

status avseende regressionstestning och omtestning av felrättningar

antalet timmar planerade för testning jämfört med antalet upparbetade testtimmar.

Mätetal relaterade till testtäckningsgrad omfattar:

täckning av krav och designelement

risktäckning

miljö/konfigurations-täckning.

Mätvärden kan rapporteras muntligt, numeriskt i tabeller eller med grafer. Dessa kan användas för ett antal olika syften.

Analys för att, via testresultaten, upptäcka vad som händer med produkten, projektet, eller processen.

Rapportering för att kommunicera insikter och resultat från testarbetet till projektets med-lemmar och övriga intressenter.

Styrning för att ändra förloppet hos testverksamheten eller projektet i sin helhet samt att övervaka resultatet av de genomförda förändringarna.

Hur man bäst samlar in, analyserar och rapporterar dessa mätvärden beror på informationsbehov, målsättning och förmåga hos dem som ska använda sig av informationen.

Teststyrning bör baseras på avvikelser från testplanen, vilka ska finnas dokumenterade i testprogress-rapporten. Denna information består till stor del av observationer och mätningar av testprogress och testresultat som jämförs med innehållet i den befintliga testplanen. Teststyrningens syfte är att minimera avvikelserna från testplanen. Möjliga åtgärder inkluderar att

revidera kvalitetsriskanalysen (produktrisker), testprioriteringar och/eller testplaner

se över prioritering av testfall

utöka antalet resurser eller på annat sätt öka testinsatsen

ändra leveransdatum

ändra omfattningen (funktionaliteten) av projektet

se över avslutskriterierna för test (bara efter godkännande från intressenterna).

Införande av ovanstående alternativ kräver samförstånd mellan projekt- eller verksamhetsintressenter och samtycke från projekt- eller verksamhetschefer.

Testrapportens upplägg beror mycket på vilken målgrupp som rapporten riktar sig mot, t.ex. projekt-ledning eller företagsledning. För en projektledare är detaljerad information om defekter troligen intressant medan företagsledningen intresserar sig mer för statusen på produktriskerna.

IEEE 829 ”Standard for Software Testing Documentation” innehåller en mall för testrapportering.

3.7 Testningens Värde för Affärsverksamheten

Trots att de flesta organisationer betraktar testning som värdefull i någon mening, är det bara ett fåtal chefer, inklusive testchefer, som kan kvantifiera, beskriva eller tala för detta värde. Dessutom tenderar många testchefer, testledare och testare att fokusera på taktiska detaljer inom testning (aspekter




specifika för uppgiften eller nivån) i stället för de stora strategiska testrelaterade frågeställningar som övriga projektmedlemmar, särskilt chefer, bryr sig om.

Testningen tillför värde till organisationen, projektet och/eller verksamheten både kvantitativt och kvalitativt.

Kvantitativa värden inkluderar att förebygga eller hitta och lösa defekter innan leverans, att göra olösta defekter kända innan leverans, att minska risker genom testning och att leverera information om projekt-, process- och produktstatus.

Kvalitativa värden inkluderar förbättrat rykte om kvalitet, smidigare och mer förutsägbara leveranser, ökat förtroende, uppbyggnad av förtroende, skydd mot juridisk ansvarsskyldighet samt minskad risk för förlust av hela uppdrag och till och med liv.

Testchefer och testledare bör förstå vilka av dessa värden som är applicerbara för den egna organisationen, projektet och/eller verksamheten samt kunna kommunicera information om testningen utifrån dessa värden.

En väletablerad metod för mätning av de kvantitativa värdena och testningens effektivitet kallas kvalitetskostnad (eller, ibland, kostnad för dålig kvalitet). Kvalitetskostnad innehåller en klassificering av projekt- eller verksamhetskostnader i fyra kategorier:

kostnad för förebygganden

kostnad för detektering

kostnad för interna felsymptom

kostnad för externa felsymptom

En del av testbudgeten är kostnad för detektering, medan resten är kostnader för interna felsymptom. Den totala kostnaden för detektering och interna felsymptom är oftast betydligt lägre än motsvarande kostnad för externa felsymptom, vilket gör testning så värdefullt. Genom att beräkna kostnaderna för dessa fyra kategorier, kan testchefer och testledare skapa övertygande ”business case” för testning.

3.8 Distribuerad Testning

Det är inte alltid som allt testarbete utförs av en enskild testgrupp sammansatt av anställda ingående i projektgruppen, eller arbetet utförs i samma lokaler som resten av projektet. Om testarbetet sker utspritt på flera olika platser kan testningen kallas distribuerad. Om testarbetet utförs på en eller flera platser av människor som inte är anställda av den organisation som äger projektet och där dessutom arbetet inte utförs i samma lokaler som resten av projektgruppen, används ofta benämningen ”outsourcing”. Om istället testarbetet utförs i samma lokaler som det övriga projektarbetet, men av människor som inte är anställda av organisationen som äger projektet, kallas det ofta ”insourcing”.

Gemensamt för alla sådana sätt att organisera testarbetet är behovet av tydliga kommunikationskanaler och väl definierade förväntningar med avseende på målsättningar, uppgifter och leverabler. Projektgruppen kan inte förlita sig lika mycket på informella kommunikationskanaler såsom korridorprat och att kollegor umgås på fritiden. Skilda lokaler, tidszoner, kulturer och språk gör allt detta ännu mera kritiskt.

Behovet av en ensad testmetodik är också större vid dessa former av organisation. Om två testgrupper använder sig av olika metodiker eller om testgruppen använder sig av en annan metodik än utvecklarna eller projektledningen, kommer det att resultera i stora problem, speciellt under testexekvering.

Vid distribuerad testning måste fördelningen av testarbetet mellan de olika platserna vara tydlig och genomtänkt. Utan sådan planering och koordinering är det risk att testarbetet inte kommer att utföras av den mest kompetenta och lämpade gruppen. Vidare kan testarbetet bli lidande av glapp (vilket ökar antalet icke omhändertagna risker vid leverans) och överlapp (vilket minskar effektiviteten).

Slutligen, viktigt för alla dylika sätt att organisera testarbete är att hela projektgruppen utvecklar och underhåller tillit till att alla testgrupper utför sina uppgifter korrekt oavsett organisation, kultur, språk




och geografiska gränser. Brist på förtroende leder till ineffektivitet och förseningar som beror på oproportionerligt kontrollbehov, skuldbeläggande samt politiska utspel (skyddande av revir).


3.9.1 Inledning

En risk är eventualiteten av ett skeende med oönskat utfall. Risker existerar när problem kan inträffa som minskar kunders, användares, projektdeltagares eller intressenters uppfattning om produktkvalitet eller projektresultat.

När huvudeffekterna av de potentiella problemen påverkar produktens kvalitet kallas dessa produktrisker (eller kvalitetsrisker). Ett exempel är risken för tillförlitlighetsdefekter som kan orsaka att systemet kraschar under normal drift.

När huvudeffekterna av de potentiella problemen påverkar projektresultatet kallas dessa projektrisker (eller planeringsrisker). Ett exempel är risken för personalbrist som kan påverka projektets slutförande.

Alla risker är inte av samma dignitet. Risknivån påverkas av olika faktorer.

Sannolikheten att problemet uppstår.

Konsekvensen av problemet om det skulle inträffa.

Vid riskbaserad testning utförs testningen så att den svarar mot risker på tre sätt.

För varje identifierad och viktig produktrisk (kvalitetsrisk) utförs lämpliga testaktiviteter som svarar mot risknivån hos risken. Dessa testaktiviteter inkluderar allokering av testresurser, val av tekniker, schemaläggning av testaktiviteter och rättning av defekter (buggar).

Planering och ledning av testarbetet sker på ett sätt som leder till minskning av och tillhandahåller åtgärdsplaner för varje identifierad och viktig projektrisk (planeringsrisk).

Rapportering av testresultat och projektstatus beskriver kvarvarande risker; t.ex. via tester som ännu inte utförts eller som har skippats, eller defekter som ännu inte blivit rättade eller omtestade.

Dessa tre typer av respons på risker bör ske under hela livscykeln, inte bara i början och slutet av projektet. Under projektets genomförande bör testarna speciellt sträva efter att:

minska risker genom att hitta de viktigaste defekterna (gäller produktrisker) och genom att genomföra lämpliga planerade åtgärder för riskminimering som finns beskrivna i teststrategin och testplanen

omvärdera riskerna genom att justera (uppåt eller nedåt) de uppskattade sannolikheterna och de uppskattade konsekvenserna för riskerna baserat på ytterligare information som framkommer allteftersom projektet fortskrider.

I båda fallen påverkar vidtagna åtgärder risknivån.

Riskbaserad testning liknar på många sätt försäkringar. Man köper försäkringar när man oroar sig för en möjlig risk och man ignorerar risker som man inte oroar sig för. Kvantitativa analyser liknande de riskutvärderingar som görs av försäkringsbolag kan vara användbara, men oftast bygger riskbaserad testning på kvalitativa analyser.

För att kunna utföra riskbaserad testning på rätt sätt bör testare kunna identifiera, analysera och minska olika slags produkt- och projektrisker, bl.a. risker relaterade till säkerhet, affärs- och ekonomiska intressen, system- och datasäkerhet samt tekniska och politiska faktorer.




3.9.2 Riskhantering

Riskhantering kan betraktas som bestående av tre huvudaktiviteter:

1. riskidentifiering 2. riskanalys 3. riskminskning (även riskkontroll)

Dessa aktiviteter är i någon mening sekventiella, men behovet av kontinuerlig riskhantering, som omnämns i föregående och följande avsnitt, betyder att i de flesta projekt alla tre riskhanterings-aktiviteter bör utföras iterativt.

För att vara mest effektiv bör alla projektets alla intressenter inkluderas i riskhanteringen. I praktiken är det dock vanligt att en del intressenter får agera ställföreträdare för andra intressenter. Som till exempel vid utveckling av programvara avsedd för den breda marknaden kan en liten grupp av möjliga kunder bli tillfrågade att hjälpa till att identifiera tänkbara defekter. Dessa defekter skulle kunna ha stor påverkan på användningen av programvaran. I detta fall fungerar denna grupp av möjliga användare som ställföreträdare för hela den eventuella kundbasen.

På grund av testanalytikers speciella kompetens bör de vara aktivt involverade i riskidentifierings- och riskanalysaktiviteterna.

3.9.2.1 Riskidentifiering

Testare kan identifiera både produkt- och projektrisker med hjälp av en eller flera av följande tekniker:

intervjuer med experter

oberoende analyser

användning av mallar för riskanalys

lärdomar (från t.ex. projektutvärderingsmöten)

risk workshops (t.ex. FMEA)

brainstorming

checklistor

ta tillvara tidigare erfarenhet

Riskidentifieringsprocessen har störst möjlighet att upptäcka många viktiga risker om en så bred grupp av intressenter som möjligt involveras.

Vissa processer för riskidentifiering avslutas med själva identifieringen av risken.

En del tekniker såsom “Failure Mode and Effects Analysis” (FMEA), kräver att för varje möjligt felsymptomsläge identifiera vilka effekter det felsymptomsläget kan orsaka i resten av systemet (inklusive högnivåsystem vid utveckling av system av system) och för de potentiella användarna av systemet.

Andra tekniker, såsom analys av risker som kan orsaka skada eller fara för liv (hazard analysis), kräver att förväntade källor till risker identifieras och eventuellt bearbetas.

För beskrivning av användandet av “Failure Mode and Effects Analysis” och dess kompletterande ”Criticality Analysis”, se avsnitt 3.10 och [Stamatis95], [Black02], [Craig02], [Gerrard02].

3.9.2.2 Riskanalys

Medan riskidentifiering handlar om att identifiera så många relevanta risker som möjligt, är risk-analysen den aktivitet i vilken dessa risker undersöks. Närmare bestämt görs en kategorisering av varje risk och en fastställning av sannolikhet och konsekvens associerade till respektive risk.

Kategorisering av risker innebär att varje risk blir bestämd till en viss typ. Typer av kvalitetsrisker som kan användas för klassificering av risker beskrivs i ISO/IEC 9126-1:2001, ”Software Engineering – Software Product Quality”, standard för egenskaper i programvaruprodukter. En del organisationer har sina egna uppsättningar av egenskapsbeskrivningar.




Notera att vid användandet av checklistor som en grund för riskidentifieringen, sker ofta klassificeringen av risktyper under själva identifieringsarbetet.

Att fastställa risknivån för varje risk innefattar uppskattning av sannolikheten för att risken ska inträffa respektive konsekvensen den för med sig om den inträffar. Sannolikheten för att en risk ska inträffa uttrycks ofta som sannolikheten för att det eventuella problemet kan förekomma i systemet som testas. Med andra ord, det härrör från tekniska risker.

Faktorer som påverkar tekniska risker:

komplexitet i teknologi och hos team

personal- och utbildningsfrågor för verksamhetsanalytiker, konstruktörer och programmerare

konflikter inom teamet

kontraktsproblem med leverantörer

geografisk spridning av utvecklingsorganisationen

befintliga kontra nya tillvägagångssätt

verktyg och teknologi

dåligt chefskap eller teknisk ledning

tidspress, resursbrist och press från ledningen

brist på tidigare kvalitetssäkring

hög förändringsfrekvens

stort antal tidigare defekter

gränssnitts- och integrationsfrågor.

Konsekvensen (eller påverkan) som risken för med sig om den inträffar uttrycks ofta som allvarlighet med avseende på hur användare, kunder eller andra intressenter påverkas. Med andra ord, det härrör från affärsrisker.

Faktorer som påverkar affärsrisker:

hur ofta de påverkade delarna används

skador på image

affärsförluster

potentiella finansiella, ekologiska eller sociala förluster eller ansvar

civila eller juridiskt rättsliga sanktioner

licensförluster

brist på lämpliga “work-arounds”

synliga eller spektakulära felsymptom som kan leda till negativ publicitet.

Testare kan antingen fastställa risknivån kvantitativt eller kvalitativt. Om både sannolikhet och konsekvens kan fastställas kvantitativt, kan man multiplicera de båda värdena med varandra för att räkna ut kostnaden för risken om den inträffar. Detta är den förväntade förlusten associerad med en specifik risk.

Oftast är det dock bara möjligt att fastställa risknivån kvalitativt. Detta innebär att man inte med säkerhet säga huruvida sannolikheten är 90 %, 75 %, 50 %, 25 % eller 10 % utan istället bedömer man sannolikheten utifrån en uppsättning tröskelvärden, t.ex. väldigt hög, hög, medium, låg eller väldigt låg. Detta kvalitativa synsätt ska inte ses som underlägset kvantitativa tillvägagångssätt eftersom kvantitativa tillvägagångssätt som inte utförs på rätt sätt vilseleder intressenter i hur de faktiskt ska uppfatta och hantera risken. Informella tillvägagångssätt såsom de som finns beskrivna i [vanVeenendaal02], [Craig02] och [Black07b] är ofta kvalitativa och mindre rigorösa.

3.9.2.3 Riskminskning

När en risk väl har blivit identifierad och analyserad, finns det fyra möjliga sätt att hantera risken. 1. Minska risken genom förebyggande åtgärder som minskar sannolikheten och/eller kon-

sekvensen. 2. Ta fram åtgärdsplaner för att minska konsekvensen om risken faller ut. 3. Överföra risken till någon annan part som får hantera risken. 4. Ignorera och acceptera risken.




Vilket sätt man väljer att hantera risken på beror på vilka möjligheter som ges m.a.p. såväl fördelar som kostnader samt nya risker som detta val kan föra med sig.

Strategier för Riskminskning

I de flesta strategier för riskbaserad testning är riskidentifiering, riskanalys och fastställande av riskminskningsaktiviteter grundläggande komponenter i den övergripande testplanen och i övriga testplaner. Risknivån för varje risk avgör testningens omfattning (t.ex. minskningsåtgärder) som planeras för respektive risk. En del säkerhetsrelaterade standarder (t.ex. FAA DO-178B/ED 12B, IEC 61508) pekar ut både testtekniker och täckningskriterier som ska uppnås baserat på risknivån.

Minskning av Projektrisker

Om det finns identifierade projektrisker kan dessa behöva delges och hanteras av projektledaren. Sådana risker står inte alltid i testorganisationens makt att reducera. Emellertid kan och bör en del projektrisker hanteras av testledaren, såsom:

testmiljö och verktygsmognad

tillgänglighet och kvalifikationer hos testteamet

låg kvalitet på input till testningen

hög förändringstakt av testbasen

brist på standarder, regler och metoder för testningen.

Tillvägagångssätt för riskminskning innefattar tidig förberedelse av testartefakter, förberedande testning både av testutrustning och av tidigare versioner av produkten, tuffare startkriterier för testningen, krav på testbarhet, deltagande i granskningar av resultat från tidigare, deltagande i problem- och förändringshanteringsaktiviteter samt övervakning av projektförlopp och kvalitet.

Minskning av Produktrisker

Testning är en central aktivitet för att minska produktrisker (kvalitetsrisker). Testare minskar risker genom att påvisa och skapa medvetenhet kring förekomsten av defekter. Därigenom skapas möjligheter att hantera dem före leverans. I den mån testare inte upptäcker defekter minskar testningen risker genom att säkerställa att systemet fungerar korrekt under vissa givna förutsättningar (dvs. för alla situationer som testats).

Produktrisker (kvalitetsrisker) kan även minskas genom andra aktiviteter än testning. Som t.ex. om det är identifierat att kraven håller för låg kvalitet kan en effektiv lösning vara att införa noggranna granskningar som en minskningsaktivitet i motsats till att skriva och prioritera tester som kommer att utföras först när de dåligt skrivna kraven blivit till faktisk kod via en design.

Risknivån används också för att prioritera testfall. I en del fall utförs all testning av höga risker innan någon låg risk testas, dvs. testfallen utförs i strikt riskordning vilket ofta kallas ”djupet-först”. I andra fall används ett tillvägagångssätt som bygger på stickprov. I detta fall väljs testfall fördelade över alla identifierade risker viktat m.a.p. risknivå. På detta sätt anpassas urvalet av tester samtidigt som det är säkerställt att varje risk åtminstone täcks av något testfall. Detta kallas ofta ”bredden-först”.

Andra riskminskande aktiviteter som kan genomföras av testare är att:

välja lämpliga testdesigntekniker

välja lämpliga granskningstekniker

genomföra granskningar av testdesignen

välja lämplig nivå av oberoende

dra lärdom av mycket erfarna personer

utföra omtestning på lämpligt sätt

utföra regressionstestning på lämpligt sätt.

Gerrard [Gerrard02] definierar konceptet testeffektivitet för att indikera (procentuellt) hur effektiv testningen förväntas vara som riskreduceringsmekanism. Om testeffektiviteten är låg bör man undvika att använda testning som medel för att minska riskerna.

Oavsett om riskbaserad testning utförs med djupet-först eller bredden-först är det möjligt att tiden avsatt för testningen tar slut innan alla planerade tester har genomförts. Om detta inträffar ska




testarna vid detta tillfälle rapportera den återstående risknivån till ledningen. Ledningen beslutar då huruvida testningen ska utökas eller om den kvarstående riskbilden ska överföras på användare, kunder, help desk/teknisk support och/eller driftspersonal.

Riskanalys för Ytterligare Testning

Om det finns tid över för fortsatt testning bör varje ytterligare testcykel anpassas till resultaten från en ny riskanalys. Huvudfokus är då på helt nya produktrisker eller produktrisker som förändrats mycket, instabila eller defekttäta områden som upptäckts under testningen, samt områden som misstänks vara dåligt testade (områden med låg testtäckningsgrad). Det rekommenderas också starkt att ha en uppdaterad riskbild inför varje milsten inom projektet.

3.9.3 Riskhantering i Programvarans Livscykel

I en ideal värld genomförs riskhantering genom hela livscykeln. Om en organisation har en dokumenterad testpolicy och/eller teststrategi bör dessa beskriva en generell process för hantering av produkt- och projektrisker inom testningen och visa hur riskhanteringen är integrerad i och påverkar alla stadier inom testningen.

Riskidentifiering och riskanalys kan startas under den initiala fasen av projektet, oavsett vilken utvecklingsmodell för programvarans livscykel som tillämpas. Riskminskningsaktiviteter kan planeras och verkställas som del av den allmänna testplaneringsprocessen. Både projekt- och produktrisker kan hanteras i den övergripande testplanen och/eller nivåtestplanerna. Både risktyp och riskens nivå kommer att påverka vilken testnivå som riskerna ska hanteras på, omfattningen av den insats som behövs för att minimera risken, vilka testtekniker och andra metoder som behövs för att minska risken samt formuleringen av kriterier för att bedöma om riskminskningen är tillräcklig.

När testplaneringen är genomförd ska riskhantering, inklusive identifiering, analys och minskning fortgå genom hela projektet. Detta innefattar identifiering av nya risker, omvärdering av risknivåer för existerande risker samt utvärdering av effektiviteten hos riskminskningsaktiviteterna. Om t.ex. en riskidentifiering och analysgenomgång, som är baserad på kravspecifikationen, genomförs under kravfasen, bör en utvärdering av riskerna göras igen efter att designspecifikationen färdigställts. Ett annat exempel är om det under testningen visar sig att en komponent innehåller många fler defekter än beräknat, kan man dra slutsatsen att sannolikheten för defekter inom detta område är större än förväntat och därför justera sannolikheten och därmed hela risknivån uppåt. Detta kan i sin tur resultera i en ökning av antalet testfall som behöver genomföras för denna komponent.

Så snart de initiala riskidentifierings- och analysaktiviteterna är avslutade kan man mäta till vilken grad som minskningsaktiviteterna bidrar till att minska riskerna. Det kan göras genom att spåra testfall och upptäckta defekter tillbaka till deras associerade risker. Allt eftersom tester genomförs och defekter upptäcks kan testarna undersöka den kvarvarande, återstående risknivån. Detta är ett argument för att använda riskbaserad testning för att bedöma vad som är rätt tillfälle för frisläppning. Se [Black03] för ett exempel på rapportering av testresultat baserat på risktäckningsgrad.

Testrapportering bör beskriva öppna respektive täckta risker samt hittills uppnådd respektive ännu inte uppnådd nytta.

3.10 Failure Mode and Effects Analysis (FMEA)

”Failure Mode and Effects Analysis” (FMEA) och en variant som inkluderar kritikalitetsanalys (FMECA) är iterativa aktiviteter avsedda att analysera effekter och kritikalitet för feltillstånd inom ett system. Tillämpningen av dessa analyser för programvara benämns ibland SFMEA och SFMECA där S står för Software (programvara). I följande avsnitt är det bara termen FMEA som används men informationen är applicerbar även på de andra tre metoderna.




3.10.1 Användningsområden

FMEA bör tillämpas:

där kritikaliteten för programvaran eller systemet i fråga måste analyseras för att minska risken för avvikelser (t.ex. säkerhetskritiska system såsom flygledningssystem)

där obligatoriska eller regulatoriska krav kräver detta (se även avsnitt 1.3.2 Säkerhetskritiska System)

för att avlägsna defekter på ett tidigt stadium

för att formulera specifika testöverväganden, driftsbegränsningar och utvecklingsbeslut för säkerhetskritiska system.

3.10.2 Implementeringssteg

FMEA bör påbörjas så snart preliminär information på hög nivå finns tillgänglig och utökas till lägre nivåer allt eftersom fler detaljer blir tillgängliga. FMEA kan appliceras på vilken systemnivå eller detaljeringsgrad av programvaran som helst beroende på den information som finns tillgänglig och på programvarukraven.

Vid genomförande; iterativt för varje kritisk funktion, modul eller komponent

välj en funktion och fastställ dess möjliga felsymptomslägen, dvs. hur funktionen kan fallera

därefter, fastställ de möjliga orsakerna till dessa felsymptom, deras påverkan och designa mekanismer för minskning eller minimering av felsymptomen.

3.10.3 Nytta & Överväganden

FMEA ger följande fördelar:

uppdagande av systemavvikelser orsakade av avvikelser i programvaran eller användningsfel

en systematisk användning av FMEA kan bidra till en helhetsanalys på systemnivå

resultat kan användas för utvecklingsbeslut och/eller motiveringar för dessa

resultat kan användas för att fokusera testningen på specifika (kritiska) områden av programvaran.

Följande måste övervägas när FMEA appliceras:

FMEA stödjer inte sekvenser av felsymptom.

Skapandet av FMEA tabeller kan vara tidskrävande.

Det kan vara svårt att avgränsa vissa funktioner.

Felpropagering kan vara svår att analysera.

3.11 Att Tänka på vid Testledning

3.11.1 Testledning av Utforskande Testning (Exploratory Testing)

Sessionsbaserad testledning (Session-based test management (SBTM)) är ett koncept för styrning av utforskande testning. En session är den grundläggande enheten i testarbetet, vilken utförs utan avbrott och fokuserat på ett specifikt testobjekt med ett specifikt testmål (testmålet beskrivs i listform s.k. test charter). I slutet av varje session skrivs en rapport över vilka aktiviteter som har genomförts den kallas ofta sessionsrapport (session sheet). SBTM verkar inom en dokumenterad processtruktur och alstrar protokoll som utgör ett komplement till den gängse testdokumentationen.

En testsession kan delas upp i tre delar.

sessionsstart: Uppsättning av testmiljön och ökning av förståelsen för produkten

testdesign och exekvering: Undersökning av testobjektet och sökande efter avvikelser

defektutredning och rapportering: Börjar när testaren upptäcker något som ser ut att vara en avvikelse.




En SBTM sessionsrapport innehåller följande:

sessionens testmål (session charter)

testarens/testarnas namn

tidpunkt (datum och tid) för sessionsstart

delaktiviteter (sessioner)

datafiler

testnoteringar

frågeställningar

defekter

I slutet av varje session genomför testledaren en översyn av sessionen tillsammans med testteamet. Under denna översyn går testledaren igenom sessionsrapporterna, förbättrar dokumentationen av testmålen (test charters), får feedback på testningen från testarna samt uppskattar behov och formulerar planer för kommande sessioner.

Agendan för en sådan översyn förkortas på engelska ”PROOF”:

Past: Vad har hänt under sessionen?

Results: Vad har åstadkommits under sessionen?

Outlook: Vad återstår att göra?

Obstacles: Vilka hinder finns för väl utförd testning?

Feelings: Vad har testaren för känslor inför allt detta?

3.11.2 Testledning av System av System

Följande frågeställningar är associerade med testledning av system av system.

Testledningen är mer komplex eftersom de enskilda systemen som tillsammans bildar system av system, kan vara utvecklade på olika platser, av olika organisationer, med hjälp av olika livscykelmodeller. Av dessa anledningar är det vanligt att den övergripande testplanen innehåller en formell livscykelmodell med tyngdpunkt på ledningsfrågor såsom milstenar och kvalitetskontrollpunkter. Det finns oftast en formellt definierad kvalitetssäkringsprocess som kan vara definierad i en separat kvalitetsplan.

Stödjande processer såsom konfigurationshantering, ändringshantering och leverans-hantering måste vara formellt definierade med överenskomna gränssnitt mot testledningen. Dessa processer är nödvändiga för att säkerställa att leveranser av programvara görs på ett kontrollerat sätt, ändringar införs på ett kontrollerat sätt och att programvaror som testas har definierade och fastställda konfigurationer.

Uppförandet och hanteringen av representativa testmiljöer, inklusive testdata, kan vara en stor teknisk och organisatorisk utmaning.

Strategin för integrationstestning kan kräva framtagning av simulatorer. För integrations-testning på tidiga testnivåer kan simulatorerna som krävs vara relativt enkla och billiga, medan simulatorer av hela system, som kan behövas för integrationstestning på högre nivåer för system av system, kan vara komplexa och dyra. Planeringen, estimeringen och utvecklingen av simulatorer hanteras ofta i separata projekt.

Beroenden mellan de olika delarna i ett system av system medför extra begränsningar för system- och acceptanstester. Det krävs också extra fokus på systemintegrationstestning och den medföljande dokumentationen, t.ex. på gränssnittsspecifikationer.

3.11.3 Testledning av Säkerhetskritiska System

Följande frågeställningar är associerade till testledning av säkerhetskritiska system:

Normalt används branschspecifika (domän) standarder (t.ex. för transportbranschen, medicin-branschen och militären). Dessa standarder kan tillämpas antingen för utvecklingsprocessen och organisationsstrukturen eller för produkten som utvecklas. För mer detaljer, se kapitel 8.2.4.




Uttalade eller formella ansvarskrav kan medföra krav på att formella aspekter tillämpas, såsom kravspårbarhet, definierade testtäckningsnivåer som ska uppfyllas, definierade acceptanskriterier som ska uppnås och kravställd testdokumentation.

För att bevisa uppfyllelse av de branschspecifika standarderna vad beträffar organisations-strukturen och utvecklingsprocessen, kan revisioner (audits) och organisationsscheman vara tillräckligt.

En fördefinierad livscykelmodell för utveckling ska följas. Vilken modell det är beror på vilken standard som tillämpas, men den är ofta, av naturliga skäl, sekventiell.

Om ett system har blivit klassat som ”kritiskt” av en organisation, måste följande icke-funktionella attribut tas med i teststrategin och/eller testplanen:

o tillförlitlighet (Reliability) o tillgänglighet (Availability) o underhållbarhet (Maintainability) o säkerhet och informationssäkerhet (Safety and security).

På grund av dessa attribut kallas ibland sådana system för RAMS system.

3.11.4 Testledning - Övrigt

Att inte planera för icke-funktionella tester kan riskera produktens framgång. Många typer av icke-funktionella tester är dessvärre förknippade med höga kostnader vilket måste vägas mot riskerna.

Det finns många olika typer av icke-funktionella tester, men alla är inte tillämpliga på alla typer av applikationer.

Följande faktorer kan påverka planeringen och exekveringen av icke-funktionella tester:

intressenters krav

behov av verktyg

behov av hårdvara

organisatoriska faktorer

kommunikation

informationssäkerhet.

3.11.4.1 Intressenters Krav

Icke-funktionella krav är ofta dåligt specificerade eller till och med inte formulerade alls. Under testplaneringen måste testarna dels kunna skaffa sig kännedom om intressenternas förväntningar på de icke-funktionella egenskaperna och dels kunna utvärdera de risker som dessa förväntningar utgör.

Det är klokt att genomföra kravinsamlingen från flera olika perspektiv. Till exempel bör intressenter såsom kunder, användare, driftspersonal och underhållspersonal vara delaktiga i kravframtagningen, annars är sannolikheten stor att en del krav förbises.

För att förbättra testbarheten av icke-funktionella krav behöver följande väsentligheter beaktas.

Krav läses oftare än de skrivs. Att satsa på att specificera testbara krav är nästan alltid kostnadseffektivt. Använd ett enkelt språk, konsekvent och koncist (dvs. använd ett språk som är definierat i projektets datalexikon). Det är särskilt viktigt att vara noggrann när man använder ord såsom “ska” (dvs. obligatoriskt), “bör” (dvs. önskvärt) och “måste” (bäst att undvika eller använda som synonym till ”ska”).

Läsare av krav har olika bakgrunder.

Krav måste vara tydliga och koncisa för att undvika tolkningsutrymme. Ett standardiserat format för kravformulering bör användas.

Specificera krav kvantitativt när det är möjligt. Välj ett lämpligt mätetal för att uttrycka en egenskap (t.ex. prestanda mätt i millisekunder) och ange ett område inom vilket resultatet kan utvärderas som godkänt eller icke godkänt. För vissa icke-funktionella egenskaper (t.ex. användbarhet) kan detta vara svårt.




3.11.4.2 Behov av Verktygsuppsättning

För prestanda-, effektivitets- och en del informationssäkerhetstester är kommersiella verktyg och simulatorer ofta relevanta. Testplaneringen bör därför innehålla estimat över kostnaderna och tidsåtgången som krävs för hantering av dessa verktyg. När specialverktyg behövs ska även planeringen ta höjd för upplärning av nya verktyg alternativt kostnaden för att hyra in externa verktygsspecialister.

Utvecklingen av komplexa simulatorer kan ske inom ett eget separat projekt och bör då planeras som ett sådant. I synnerhet när simulatorn ska användas för utveckling och testning av säkerhetskritiska applikationer bör planeringen av simulatorutvecklingen ta hänsyn till acceptanstestning och eventuellt certifiering, som då utförs av en oberoende organisation.

3.11.4.3 Behov av Hårdvara

Många icke-funktionella tester kräver en produktionslik testmiljö för att mätningarna ska bli realistiska. Storlek och komplexitet hos systemet som ska testas kan ha en väsentlig påverkan på planering och finansiering av testerna. Kostnaden att förbereda och genomföra icke-funktionella tester kan vara så hög att bara en begränsad del av tiden är tillgänglig för själva testexekveringen. Att t.ex. verifiera krav på skalbarhet hos en välbesökt webbplats kan kräva simulering av hundra tusen virtuella användare. Detta kan ha en väsentlig påverkan både på kostnader för hårdvara och för testverktyg. Dessutom är ofta licenskostnaderna för prestandaverktyg underskattade, vilket också kan innebära begränsningar av den tillgängliga tiden för sådana tester.

Genomförande av användbarhetstester kan kräva att ett dedicerat labb sätts upp eller att omfattande användarenkäter genomförs. Dessa typer av tester utförs oftast bara en gång inom en utvecklingslivscykel.

Många andra typer av icke-funktionella tester (t.ex. informationssäkerhetstester och prestandatester) kräver en produktionsliknande miljö för själva exekveringen. Eftersom kostnaden för sådana miljöer kan vara mycket hög kan nyttjandet av den faktiska produktionsmiljön vara det enda möjliga alternativet. Tidpunkten för genomförande av tester i en produktionsmiljö måste vara noga planerad och det är troligt att sådana tester endast kan utföras vid specifika tidpunkter (t.ex. nattetid).

När effektivitetsrelaterade tester (t.ex. prestanda, last) ska genomföras är dator- och kommunikations-bandbredd en ytterligare faktor att ta hänsyn till vid planering Behoven av bandbredd beror i huvudsak på antalet virtuella användare som ska simuleras och hur mycket nätverkstrafik de sannolikt kommer att generera. Att missa att ta höjd för detta kan resultera i att de utförda prestandamätningarna inte är representativa.

3.11.4.4 Organisatoriska Faktorer

Icke-funktionella tester kan innefatta mätningar av beteenden hos flera komponenter i ett komplett system (t.ex. servrar, databaser, nätverk). Planering och samordning av testerna kan bli omfattande om dessa komponenter är distribuerade över ett antal olika platser och organisationer. T.ex. kan vissa programvarukomponenter bara vara tillgängliga för systemtest vid vissa tillfällen per dag eller per år, eller så kanske en organisation bara erbjuder testhjälp ett begränsat antal dagar. Att i sådana situationer inte säkerställa att systemkomponenter och personal från andra organisationer finns tillgängliga ”i beredskap” för testarbete, kan resultera i stora störningar av de planerade testerna.

3.11.4.5 Kommunikation

För att specificera och genomföra vissa typer av icke-funktionella tester (särskilt effektivitetstester) kan det vara nödvändigt att kunna modifiera specifika kommunikationsprotokoll. Vid planeringen av dessa typer av tester ska det säkerställas att sådana förändringar är möjliga att genomföra (t.ex. att verktyg kan erbjuda den kompatibiliteten).

3.11.4.6 Informationssäkerhet

Under testplaneringen måste hänsyn tas till de specifika informationssäkerhetsåtgärder som är implementerade i systemet för att säkerställa att alla testaktiviteter är möjliga att genomföra. Till




exempel kan användandet av datakryptering göra det svårt att skapa testdata och försvåra verifiering av resultat.

Policy och lagar för datasäkerhet kan hindra skapande av virtuella användare som baseras på verklig produktionsdata. Att skapa anonyma testdata kan vara en icke obetydlig uppgift som måste planeras som en del av testimplementationen.




4. Testtekniker

Begrepp:

användningsfallsbaserad testning, beslutstabellbaserad testning, beslutstestning, bågtestning, BS 7925-2, dataflödesanalys, defektbaserad testdesign, defekttaxonomi, dynamisk analys, ekvivalens-klassindelning, erfarenhetsbaserad testdesign, felgissning, gränsvärdesanalys (Boundary Value Analysis BVA), klassifikationsträd, kodsatstestning, kontrollflödesanalys, kravbaserad testning, LCSAJ, MCDC testning, minnesläcka, parvis testning, programvaruattacker, specifikationsbaserad testdesign, statisk analys, strukturbaserad testdesign, test charter (testunderlag), testning av villkorskombinationer, tillståndsbaserad testning, testning utifrån orsak-verkangrafer (Cause-effect graphing), utforskande testning (exploratory testing) , vilda pekare, villkorstestning, vägtestning

4.1 Inledning

Detta kapitel täcker följande huvudkategorier av testdesigntekniker:

specifikationsbaserade (alt. beteende-baserade eller black-box)

strukturbaserade (alt. white-box)

defektbaserade

erfarenhetsbaserade

Dessa kategorier av tekniker kompletterar varandra och kan användas i alla testaktiviteter oberoende av testnivå. Testtekniker från alla dessa kategorier kan användas av både testanalytiker och tekniska testanalytiker. Denna kursplan gör följande uppdelning av kategorierna för de två rollerna, baserat på den mest förekommande användningen:

specifikationsbaserade testanalytiker och tekniska testanalytiker.

strukturbaserade tekniska testanalytiker.

defektbaserade testanalytiker och tekniska testanalytiker.

Erfarenhetsbaserade testanalytiker och tekniska testanalytiker.

Utöver dessa huvudkategorier täcker detta kapitel även andra testdesigntekniker såsom attack-baserad testning samt statisk och dynamisk analys. Alla dessa tekniker används normalt av tekniska testanalytiker.

Observera att specifikationsbaserade tekniker kan fokusera både på funktionella och icke-funktionella egenskaper. Testning av icke-funktionella egenskaper beskrivs närmare i nästa kapitel.


Specifikationsbaserade testtekniker (även kallade black-box tekniker) erbjuder möjligheter att identifiera och välja ut testvillkor eller testfall enbart baserat på en analys av testbasen, dvs. dokumentationen av en komponent eller ett system, utan kunskap om den interna strukturen hos implementationen.

Gemensamma egenskaper hos specifikationsbaserade tekniker är.

Modeller, med varierande grad av formalism, används för att beskriva aspekter hos testproblemet, programvaran, eller dess komponenter.

Från dessa modeller identifieras testfall på ett strukturerat och systematiskt sätt.

De flesta specifikationsbaserade tekniker erbjuder även någon form av täckningsmått, som kan användas för att utvärdera kvaliteten hos testfallsurvalet. En hundraprocentig täckning skall dock ej tolkas som att testfallsmängden är komplett, utan snarare att man uttömt möjligheterna att med den använda tekniken identifiera fler meningsfulla testfall.




Specifikationsbaserade tester är ofta kravbaserade och eftersom kravspecifikationer beskriver systemets beteende, speciellt i fråga om funktionalitet, är kravbaserad testning ofta en central del av testningen av systemets beteende. De specifikationsbaserade tekniker som nämns i detta kapitel kan tillämpas på kravspecifikationen. Detta sker genom att modeller av systembeteendet skapas utifrån kravspecifikationens text, bilder och diagram. Genom att sedan applicera de olika teknikerna på modellerna erhålls testfall.

I denna kursplan ingår följande specifikationsbaserade testdesigntekniker:

Namn Teknik Täckningsmått Ekvivalensklassindelning Se ISTQB®/SSTB: svensk kursplan certifierad

testare, grundnivå; version 2007, kapitel 4.3.1 för beskrivning.

Antal täckta partitioner / totalt antal partitioner.

Gränsvärdesanalys (Boundary Value Analysis BVA) Se ISTQB®/SSTB: svensk kursplan certifierad

testare, grundnivå; version 2007, kapitel 4.3.2 för beskrivning. Observera att BVA kan tillämpas med antingen två eller tre gränsvärden per gräns. Vilket av dessa alternativ som ska användas är en riskav-vägning.

Antal täckta gränsvärden / totalt antal gränsvärden.

Beslutstabeller och orsak-verkangrafer Se ISTQB®/SSTB: svensk kursplan certifierad

testare, grundnivå; version 2007, kapitel 4.3.3 för beskrivning. Beslutstabellbaserad testning innebär att alla kombinationer av villkorsvärden, alla relationer och alla begränsningar av kombinationer av villkorsvärden kommer att testas. Observera att beslutstabellbaserad testning erbjuder möjligheten att antingen testa alla kombinationer av villkorsvärden eller att testa ett urval av dessa genom att reducera den ursprungliga beslutstabellen. Vilket av dessa alternativ som ska användas är en riskavvägning. [Copeland03] Som alternativ till beslutstabeller kan även en närbesläktad grafisk metod som baseras på orsak-verkangrafer användas.

Antal täckta kombinationer av villkorsvärden / totalt antal kombinationer av villkorsvärden.

Tillståndsbaserad testning Se ISTQB®/SSTB: svensk kursplan certifierad


Baserat på övergångar och sekvenser av övergångar definieras ett antal relaterade täckningsmått. Täckning av tillstånds-övergångar (även kallat täckning av till-ståndsövergångssekvenser av längd 1 eller 0-switch coverage) definieras som den procentuella mängden av tillåtna övergångar som passerats under testningen. Täckning av tillståndsövergångs-sekvenser av längd N+1 (även kallat N-switch coverage) är en generalisering av detta täckningsmått, vilket betecknar den procentuella mängden av tillåtna sekvenser av övergångar av längd N+1 som testats.




Klassifikationsträd, ortogonalitetsmatriser och parvis täckning Dessa metoder bygger på identifieringen av

intressanta faktorer, parametrar eller variabler, samt de värden som dessa kan anta. Utifrån mängden av alla möjliga kombinationer av dessa värden identifieras delmängder som uppfyller olika nivåer av täckning baserat på enskilda värden (”singletons”), par av värden, tripplar av värden etc. [Copeland03] Klassifikationsträd är en specifik metod som baseras på en grafisk representation av de intressanta testvillkoren samt de testfall som identifierats för att täcka kombinationer av dessa testvillkor [Grochtmann94]

Beror på den använda tekniken. T.ex. är parvis täckning och klassificeringsträd olika.

Användningsfallsbaserad testning Se ISTQB®/SSTB: svensk kursplan certifierad


Inga formella täckningsmått finns definierade.

Dessa testtekniker kan ofta kombineras. Till exempel skulle ekvivalensklassindelning kunna appliceras på vissa villkor i en beslutstabell, för att på så sätt identifiera flera olika situationer som uppfyller dessa villkor. De resulterande testfallen skulle då täcka inte bara alla kombinationer av värden på de ingående villkoren, utan även de olika identifierade ekvivalensklasserna för de villkor som partitionerats.

4.3 Strukturbaserade Testtekniker

Strukturbaserade testtekniker, även kallade white-box eller kodbaserade testtekniker, är de test-tekniker där programkod, data, arkitektur eller flöden används som bas för testdesignen och där testfall systematiskt identifieras utifrån strukturen hos implementationen. De olika testteknikerna fokuserar på olika strukturella element. Alla testtekniker har associerade täckningsgradskriterier, vilka används för att avgöra när testfallsidentifieringen är komplett. Att testfallsidentifieringen är komplett innebär inte att den totala mängden testfall är komplett utan att man uttömt möjligheterna att med den använda tekniken identifiera fler meningsfulla testfall från den använda implementationsstrukturen. Varje organisation eller projekt bör, baserat på sina specifika mål, använda lämpliga täckningskriterier genom att använda motsvarande testtekniker och mäta den uppnådda täckningen.

Gemensamma egenskaper hos strukturbaserade testtekniker är.

Testfall identifieras baserat på information om hur programvaran är konstruerad, t.ex. kod eller design.

Uppnådd täckning, för ett visst täckningsmått, kan mätas för en uppsättning existerande testfall. Därefter kan täckningen ökas genom att systematiskt identifiera nya testfall.

I denna kursplan ingår följande strukturbaserade testdesigntekniker:

Namn Teknik Täckningsmått Kodsatstestning Exekverbara kodsatser används som bas för

testfallsidentifiering. (Kommentarer och andra icke-exekverbara kodsatser skall exkluderas).

Antal exekverade kodsatser / totalt antal [exekverbara] kodsatser

Beslutstestning Beslutspunkter i koden (t.ex. if-else, switch/case,

for och while-konstruktioner) används som bas för testfallsidentifiering.

Antal utfall från exekverade beslutspunkter / totalt antal utfall.




Bågtestning Bågtestning är en teknik som bygger på att koden

representerats i form av en kontrollflödesgraf. Bågtestning innebär att kontrollflödesgrafens bågar används som bas för testfallsidentifiering. Observera att beslutstestning och bågtestning är samma vid 100 % täckningsgrad, men kan för samma mängd testfall vara olika vid lägre täckningsgrad.

Antal exekverade bågar / totalt antal bågar.

Villkorstestning Varje besluts olika villkor samt de olika alternativen

i case/switch konstruktioner används som bas för testfallsidentifiering.

Antal exekverade sanningsvärden för de ingående villkoren i respektive beslut / Totalt antal sanningsvärden för de ingående villkoren i respektive beslut.

Villkorskombinationstestning Alla möjliga kombinationer av sanningsvärden för

de ingående villkoren i respektive beslut används som bas vid testfallsidentifiering.

Antal exekverade kombinationer av sanningsvärden för de ingående villkoren i respektive beslut / Totalt antal kombinationer av sanningsvärden för de ingående villkoren i respektive beslut.

MCDC Testning Alla möjliga kombinationer av sanningsvärden för

de ingående villkoren, som kan påverka beslutet används som bas vid testfallsidentifiering.

Antal exekverade kombinationer av sanningsvärden för de ingående villkoren i respektive beslut, som påverkar beslutet / Totalt antal kombinationer av sanningsvärden för de ingående villkoren i respektive beslut, som påverkar beslutet

LCSAJ Den engelska texten som beskriver LCSAJ

innehåller ett antal stora fel, vilka är felrapporterade. I väntan på rätting har SSTB ersatt denna text med nedanstående text. LCSAJ är en testteknik framtagen för att hantera problemet med att loopar i ett kontrollflöde kan resultera i en oändlig mängd möjliga vägar genom koden. En LCSAJ (”Linear Code Sequence And Jump”) är en sekvens av kodinstruktioner med följande egenskaper: (a) varje LCSAJ har en startpunkt som antingen är programmets första kodinstruktion eller målinstruktionen i ett hopp. (b) alla kodinstruktioner i en LCSAJ kommer i sekvens i programmet och (c) en LCSAJ slutar med ett hopp eller programmets sista kodinstruktion. LCSAJ har följande egenskaper: (i) LCSAJ fokuserar både på villkorliga och ovillkorliga hopp, (ii) Antalet LCSAJer är alltid ändligt, (iii) Vissa LCSAJer överlappar. Vid design av testfall för LCSAJ testning krävs tillgång till källkoden. Eftersom antalet LCSAJer är ändligt kan LCSAJ användas för att definiera ett täckningsmått.

Antal exekverade LCSAJ:er / totalt antal LCSAJ:er.




Vägtestning Alla möjliga unika sekvenser av kodrader (vägar)

används som bas vid testfallsidentifiering. Antal exekverade vägar / totalt antal vägar.

Ett vanligt användningsområde för strukturella täckningsmått är att mäta hur komplett en uppsättning testfall är med avseende på kodtäckning, där testfallen är skapade av t.ex. specifikationsbaserade och/eller erfarenhetsbaserade testtekniker. Vanligtvis används en typ av testverktyg som kallas kodtäckningsanalysator för att mäta den uppnådda täckningsgraden. Dessa verktyg kan både mäta och rapportera en total täckningsgrad samt identifiera områden av koden som ännu inte täckts. Om den totala täckningsgraden är för låg eller viktiga områden av koden ännu inte testats, kan detta åtgärdas genom användningen av strukturbaserade eller andra testtekniker.

Analys av Täckningsgrad

Dynamisk testning med hjälp av strukturbaserade eller andra testtekniker kan användas för att avgöra om tillräcklig kodtäckning uppnåtts. Detta används för att påvisa att en viss täckningsgrad uppnåtts, bland annat vid test av säkerhetskritiska produkter där detta ofta är kravställt, se även kapitel 1.3.2. Täckningsgradsinformationen kan även användas för att identifiera kodavsnitt som överhuvudtaget inte blivit exekverade, vilka därmed kräver att ytterligare testfall skapas.


4.4.1 Defektbaserade Tekniker

I en defektbaserad testteknik används olika typer av defekter som bas för testfallsidentifiering. För varje typ av defekt identifieras testfall på ett systematiskt sätt utifrån denna defekttyps kännetecken.

Även dessa tekniker har associerade täckningsmått som kan användas för att bestämma när testfallsframtagningen kan avslutas. I praktiken är dock täckningsmått för defektbaserade testtekniker mindre systematiska än motsvarande täckningsmått för specifikations- och strukturbaserade test-tekniker. Detta innebär att den uppsättning generella regler som utgör täckningsmått för defekt-baserade testtekniker, måste tolkas av testaren i de sammanhang de används. Hundraprocentig täckning med avseende på en specifik defektbaserad testteknik innebär inte att testningen är komplett utan enbart att de defekter som man tagit hänsyn till inte längre kan ge upphov till några meningsfulla testfall.

I denna kursplan ingår följande defektbaserade testdesignteknik:

Namn Teknik Täckningsmått

Taxonomibaserad testning (kategorier & listor av potentiella defekter) Baserat på taxonomin, eller listan med defekttyper,

väljer testaren ut potentiella problem för analys och framtagning av testfall. Taxonomier kan fokusera på grundorsaker, defekter eller felsymptom. Till exempel så listar defekttaxonomier de vanligaste defekterna i programvaran under test.

Antal med testfall täckta defekter eller typer av defekter / totalt antal valda defekter eller typer av defekter.

4.4.2 Erfarenhetsbaserade Tekniker

Testtekniker som utgår ifrån defektrelaterad information, främst defekthistorik, men som inte har systematiska täckningsmått kategoriseras som erfarenhetsbaserade testtekniker. Erfarenhets-baserade testtekniker utnyttjar testarens kunskap och intuition kombinerat med erfarenheter från liknande applikationer och teknologier. Dessa typer av tester är ofta effektiva när det gäller att hitta defekter, men inte lika lämpliga som andra testtekniker när det gäller att uppnå en bestämd




täckningsgrad. Erfarenhetsbaserade testtekniker är heller inte lika bra som andra testtekniker när det gäller att producera återanvändbara testprocedurer.

Vid användning av dynamiska och heuristiska tillvägagångssätt tenderar testarna att favorisera erfarenhetsbaserade testtekniker. Detta medför att testningen är mer reaktiv än tillvägagångssätt då testerna planerats i förväg. Vid användning av erfarenhetsbaserade testtekniker är exekvering och utvärdering av resultaten aktiviteter som sker samtidigt. Vissa av de mer strukturerade teknikerna är inte helt samtidiga, utan testfallen skapas ibland innan testexekveringen och inte som ett direkt resultat av de beteenden som testarna observerat.

Observera att trots att nedanstående beskrivningar av testtekniker innehåller idéer om täckningsmått så har inte erfarenhetsbaserade tekniker några formella sådana.

I denna kursplan ingår följande erfarenhetsbaserade testdesigntekniker:

Namn Teknik Täckningsmått

Felgissning Testaren använder sin erfarenhet för att gissa var

potentiella misstag givit upphov till defekter. Därefter väljer testaren metod för att identifiera dessa eventuella defekter. Felgissningsmetodiken kan även vara användbar vid riskanalys för att identifiera potentiella feltillstånd [Myers97].

Om felgissning bygger på en taxonomi kan denna användas för att formulera täckningsmått. Annars är tillämpliga täckningsmått begränsade till testarens erfarenhet och den tillgängliga tiden.

Checklistebaserad testning Vid checklistebaserad testning använder testaren

en lista som beskriver sådant som ska kontrolleras eller inte glömmas bort. Listan kan även innehålla regler eller kriterier som ska gälla för den produkt som ska testas. Eftersom checklistan ofta innehåller information på ganska hög nivå kan det krävas stor erfarenhet hos testaren. Checklistor är ofta baserade på standarder, erfarenhet och andra liknande informationskällor. Ett exempel på checklistebaserad testning är användningen av en standardchecklista vid testning av användargräns-snitt.

Varje element i checklistan har täckts av testfall.

Utforskande testning (Exploratory Testing) Utforskande testning (exploratory testing) bygger

på att testaren lär sig om produkten och dess defekter samtidigt som han planerar, designar, utför och rapporterar testerna och deras resultat. ”Utforskande testning av god kvalitet innehåller en övergripande planering men stödjer på samma gång interaktivitet och kreativitet. Testaren anpassar hela tiden sina testmål och sin testning till de rådande omständigheterna och de hittills uppnådda resultaten. Dokumentationen av testningen och de uppnådda resultaten är av mindre omfattning [Veenendaal02].

Som bas för eventuella täckningsmått används testunderlag (”test charters”). Dessa innehåller övergripande mål eller målsättningar med vägledning för hur ett specifikt område eller testobjekt ska testas. Baserat på testunderlaget planeras sedan en testsession (”exploratory testing session”). Den ska beskriva vad som ska uppnås, av vem, vad fokus ligger på under testsessionen, vad som ska resp. inte ska testas och hur testsessionen ska genomföras, t.ex. via en uppsättning riktlinjer för vilka defekter man ska leta efter och vilken kvalitet man ska uppnå.




Attackbaserad testning

Vid attack-baserad testning försöker testaren utvärdera systemkvaliteten genom att medvetet få specifika felsymptom att uppkomma. Principen för programvaruattacker, som [Whittaker03] beskriver dem, är baserad på interaktionen mellan den testade programvaran och dess driftsmiljö. Detta inkluderar även användargränssnitt samt kommunikationen mellan operativsystemet och kärnan, APIer och filsystem. I allmänhet är dessa typer av kommunikation baserade på exakta överföringar av data. Förvanskningar av data i någon av dessa dataöverföringar kan vara orsaken till felsymptom.

Eventuella täckningsmått bygger på de olika gränssnitten som ingår i den testade produkten. De vanligaste gränssnitten är användargränssnitt, samt gränssnitt till operativsystemet, kärnan, APIer och filsystem.

Defekt- och erfarenhetsbaserade tekniker använder kunskaper om defekter och andra erfarenheter för att öka graden av defektdetektering. Teknikerna varierar från ”snabbtester”, vilka kännetecknas av att testaren inte gjort någon formell planering av de aktiviteter som ska genomföras, till genomarbetade testupplägg där testfallen är skriptade i förväg. Defekt- och erfarenhetsbaserade tekniker är använd-bara i nästan alla testsammanhang, men är av speciellt värde när:

få eller inga specifikationer är tillgängliga

systemet under test är dåligt dokumenterat

otillräckligt med tid är anslaget för design och implementering av testfall och testprocedurer

testarna har djupa kunskaper om eller erfarenheter av branschen, domänen eller teknologin

man söker alternativ till den förberedda testningen

man vill analysera felsymptom som uppkommit under drift.

Defekt- och erfarenhetsbaserade tekniker är även användbara som komplement till specifikations- och strukturbaserade testtekniker eftersom de bidrar till att fylla luckor i testtäckningsgraden som resulterar från systematiska svagheter hos de specifikations- och strukturbaserade testteknikerna.

4.5 Statisk Analys

Statisk analys handlar om att testa utan att för den skull exekvera programvaran under test. Statisk analys genomförs oftast på kod eller systemarkitektur.

4.5.1 Statisk Analys av Kod

Alla typer av testning, undersökning eller granskning som kan utföras utan att exekvera testobjektets kod kallas för statisk analys. Det finns ett antal olika statiska analystekniker, vilka beskrivs i detta avsnitt.

4.5.1.1 Kontrollflödesanalys

Kontrollflödesanalys ger information om de logiska beslutspunkterna i programvaran och den inneboende komplexiteten i deras struktur. Kontrollflödesanalys beskrivs i ISTQB®/SSTB: svensk kursplan certifierad testare, grundnivå; version 2007 och i [Beizer95].

4.5.1.2 Dataflödesanalys Den engelska texten som beskriver dataflödesanalys innehåller ett antal stora fel, vilka är felrapporterade. I väntan på rätting har SSTB ersatt denna text med nedanstående text.

Dataflödesanalys ger information om hur variabler används i programvaran. I grunden kan två operationer (skrivning (”define”) resp. läsning (”use”) utföras på en variabel. Vid dataflödesanalys används ett verktyg, vanligtvis en kompilator, för att undersöka sekvenser av operationer på de olika variablerna. Vissa typer av sekvenser, såsom ”läsning före skrivning” och ”skrivning följt av skrivning”,




är kanske felaktiga och därför kommer verktyget att peka ut dessa sekvenser i form av varningar. Det är upp till verktygsanvändaren att bestämma om man vill åtgärda eller ignorera varje varning.

4.5.1.3Överensstämmelse med Kodningsstandarder

Statisk analys kan även användas för att undersöka kodens överensstämmelse med befintliga kodningsstandarder, vilka kan innefatta både arkitekturaspekter och reglering av användningen (eller förbud att använda) vissa kodstrukturer i det använda programmeringsspråket.

Överensstämmelse med kodningsstandarder gör programvaran enklare att både underhålla och testa. Krav på koden som härstammar från vissa programmeringsspråk kan också kontrolleras med hjälp av statisk analys.

4.5.1.4 Mätning av Kodens Egenskaper

Vid statisk analys kan ett antal olika mätetal som avspeglar kodens egenskaper användas. Mätningar av dessa egenskaper gör det möjligt att uppnå både högre underhållbarhet och högre tillförlitlighet hos koden. Exempel på sådana mätetal är:

cyklomatisk komplexitet

storlek

kommenteringsfrekvens

antal nästlingsnivåer

antal funktionsanrop.

4.5.2 Statisk Analys av Arkitektur

4.5.2.1 Statisk Analys av en Webbapplikation

Även arkitekturen hos en webbapplikation kan utvärderas med hjälp av verktyg för statisk analys. I detta fall är ofta målet att ta reda på om den trädliknande strukturen hos webbapplikationen är balanserad. Om det finns en obalans kan detta leda till:

svårare testning

dyrare underhåll

problem för användaren att navigera i applikationen.

Vissa testverktyg innehåller även analysmekanismer för att, via statisk analys, tillhandahålla information om storlek och tid för nedladdning av de olika delarna av webbapplikationen. Dessutom kan vissa av dessa verktyg undersöka om länkarna på en sida fungerar eller inte (dvs. http error 404). (Denna undersökning är egentligen dynamisk analys). Informationen från statisk analys är intressant för utvecklare, testare och webbansvarig.

4.5.2.2 Anropsträd

Anropsträd kan användas för flera syften.

Design av testfall som ska anropa en specifik komponent.

Identifiering av antalet anrop som görs från olika ställen i programvaran till en viss komponent.

Skapa ett förslag på integrationsordning för systemets komponenter (t.ex. parvis eller grannintegration [Jorgensen02]).

Utvärdera strukturen hos systemets kod och arkitektur.

Även dynamisk analys kan ge information om anropande komponenter. I dessa fall innefattar informa-tionen t.ex. antalet gånger som en komponent anropas under exekvering. Genom att slå ihop informationen från anropsträd med den dynamiska analysinformationen kan testaren identifiera vilka komponenter som anropas ofta. Om en sådan komponent dessutom är komplex (se 1.3.2.2 Säkerhetskritiska System & Komplexitet), så är komponenten en het kandidat för detaljerad och nog-grann testning.




4.6 Dynamisk Analys

Den grundläggande principen för dynamisk analys är att analysera en applikations beteende under exekvering. Detta kräver ofta att någon form av instrumentering införts i koden, antingen manuellt eller automatiskt.

4.6.1 Översikt

Avvikelser som inte omedelbart kan återskapas kan ha stor påverkan både på testarbetsmängden och på möjligheterna att leverera och använda systemet på ett produktivt sätt. Sådana avvikelser kan bero på minnesläckor, felaktig användning av pekare, eller annan förvanskning av vital data (t.ex. systemstacken) [Kaner02]. Typiska symptom på dessa typer av defekter inkluderar gradvis försämring av systemprestanda och till och med systemkrascher. En teststrategi bör ta hänsyn till risker associerade med dessa typer av defekter och, där det är nödvändigt, innehålla dynamiska analysaktiviteter (vanligen genom verktygsanvändning) för att minska dessa risker.

Dynamisk analys utförs alltid under det att programvaran exekveras. Fokus för dynamisk analys inkluderar:

Förebyggande av avvikelser genom upptäckt av vilda pekare och minnesläckor.

Analys av felsymptom som är svåra att återskapa.

Utvärdering av nätverksbeteende.

Förbättring av systemets prestanda genom att tillhandahålla information om systemets beteende under drift.

Dynamisk analys kan användas på alla testnivåer, men är speciellt användbar under komponent- och integrationstestning. I allmänhet krävs både teknisk kunskap och systemkunskap för att specificera målen med dynamisk analys och framför allt för att analysera resultaten.

4.6.2 Upptäcka Minnesläckor

Minnesläckor uppstår när ett program, under exekvering, dynamiskt allokerar minne och därefter inte återlämnar detta minne, pga. programmeringsmisstag. Konsekvensen blir att programmet ej längre kan använda denna del av minnet. I värsta fall kan det användbara minnet helt ta slut.

Minnesläckor är en typ av problem som ofta inte kan upptäckas omedelbart utan sakta utvecklas över tiden och skapar problem först en tid efter driftssättning. Under testning gör man ofta ominstallationer eller startar om systemet, varför de negativa effekterna av minnesläckor inte syns förrän systemet är i drift.

Stadigt försämrade svarstider kan vara symptom på minnesläckor, som till slut kan få systemet att krascha eller på annat sätt orsaka större systemavbrott. Ofta kan dessa felsymptom åtgärdas med en omstart eller en ombootning av systemet, men i vissa fall kan en sådan åtgärd vara opraktisk eller till och med omöjlig.

Verktyg kan användas för att identifiera förekomsten av minnesläckor och lokalisera var i koden problemen uppstår. Denna information används sen för att åtgärda problemen permanent. Mindre avancerade verktyg, som t.ex. minnesmonitorer, kan också användas för att skaffa sig en bild av den generella minnesanvändningen över tiden. Om mängden tillgängligt minne verkar minska, kan det vara ett tecken på att det finns en minnesläcka och i sådant fall bör en djupare analys genomföras.

Andra besläktade former av läckor inkluderar filhandtag, semaforer och liknande resurspooler.

4.6.3 Upptäcka Vilda Pekare

En pekare i ett program som av någon anledning inte längre är användbar kallas “vilda pekare”. T.ex. kan pekaren ha ”tappat” adressen till det objekt, den funktion eller den minnesarea (t.ex. att pekaren




pekar utanför gränserna till en vektor) som pekaren är tänkt att peka på. När ett program, under exekvering, använder en vild pekare kan det få flera olika konsekvenser.

1. Programmet beter sig helt korrekt. Detta kan inträffa om pekaren innehåller en adress till en plats i minnet där det råkar stå någon för programmet meningsfull information.

2. Programmet kan krascha. Detta inträffar om pekaren innehåller en adress till en minnes-position som är kritisk för programmets exekvering och därför övervakas av operativsystemet.

3. Programmets beteende är inkorrekt då programmets objekt innehåller fel information, eller fel objekt används i en viss situation. I dessa situationer kan programmet fortsätta att fungera, men med eventuella felmeddelanden som direkta resultat.

4. Data förändras eller förstörs då information skrivs på fel ställe i minnet.

Notera att varje förändring av ett programs minnesanvändning (t.ex. ett nytt bygge av programvaran efter en kodändring) kan trigga någon av de fyra konsekvenserna i ovanstående lista. Detta är speciellt kritiskt när programmet initialt tycks fungera korrekt, trots vilda pekare, för att senare, ev. under drift, oväntat krascha efter en programvaruuppdatering. Det är viktigt att förstå att sådana felsymptom är symptom på underliggande misstag (dvs. introduktion av vilda pekare) snarare än ett misstag som har att göra med uppdateringen. (Se [Kaner02], “Lesson 74”).

Verktyg kan identifiera vilda pekare under drift, oavsett vilken konsekvens de får på programmets beteende.

4.6.4 Analys av Prestanda

Dynamisk analys kan användas för att analysera ett programs prestanda. Verktyg kan hjälpa till att identifiera prestandaflaskhalsar och kan generera en stor mängd prestandamätvärden av många olika slag. Dessa mätetal kan sedan användas av utvecklarna för att finjustera systemets prestanda. Denna aktivitet kallas även ”prestandaprofilering”.




5. Testning av Programvaruegenskaper

Begrepp:

Användbarhetstestning, driftacceptanstestning, driftsprofil, effektivitetstestning, heuristisk evaluering, interoperabilitetstestning, portatbilitetstestning, reliability growth model, SUMI (Software Usability Measurement Inventory), testning av informationssäkerhet, testning av lämplighet, testning av noggrannhet, testning av underhållbarhet, testning av återhämtningsbarhet, tillförlitlighetstestning, tillgänglighetstestning

5.1 Inledning

Medan föregående kapitel beskrev de specifika tekniker som finns tillgängliga för testaren, beskriver detta kapitel hur dessa tekniker ska tillämpas för att testa de olika kvalitetsattribut som tillsammans utgör ett systems eller en programvaras kvalitet.

De olika kvalitetsattributen är i denna kursplan uppdelade i två separata avsnitt, ett för testanalytikern och ett för den tekniska testanalytikern. ISO 9126 har använts som en vägledning för beskrivningarna av kvalitetsattributen i den här kursplanen.

Det grundläggande inlärningsmålet för alla tre modulerna är att förstå alla de olika kvalitetsattributen. En del kvalitetsattribut gås igenom mera noggrant i modulen för testanalytikern medan andra gås igenom i modulen för den tekniska testanalytikern, så att representativa risker kan identifieras, passande teststrategier utvecklas och testfall specificeras.


Funktionell testning fokuserar på ”vad” produkten gör. Testbasen för funktionell testning är oftast krav eller specifikationer, specifik domänexpertis eller underförstådda behov. De funktionella testerna varierar beroende på vilken testnivå eller fas de ingår i. T.ex. kommer en funktionell test som ingår i integrationstestning att testa funktionaliteten hos modulernas gränssnitt, vilka tillsammans implementerar en definierad funktion, medan funktionaliteten hos applikationen i sin helhet testas på systemtestnivån. För system av system fokuserar den funktionella testningen i huvudsak på den totala funktionaliteten som tillhandahålls gemensamt av de integrerade systemen.

En stor mängd olika testtekniker används vid funktionell testning (se kapitel 4). Funktionell testning kan genomföras av dedicerade testare, domänexperter eller utvecklare (då oftast på komponent-nivån).

Domäntestning berör följande kvalitetsattribut:

noggrannhet

lämplighet

interoperabilitet

funktionell informationssäkerhet

användbarhet

tillgänglighet

5.2.1 Testning av Noggrannhet

Funktionell noggrannhet handlar om applikationers uppfyllelse av sina specificerade eller underför-stådda krav men kan även omfatta noggrannhet i beräkningar. Testning av noggrannhet nyttjar flera av testteknikerna som beskrivs i kapitel 4.




5.2.2 Testning av Lämplighet

Testning av lämplighet innebär utvärdering och validering av hur väl en grupp funktioner uppfyller sina avsedda specificerade uppgifter. Testningen kan baseras på användningsfall eller metoder.

5.2.3 Testning av Interoperabilitet

Interoperabilitetstestning undersöker huruvida en given applikation kan fungera korrekt i alla avsedda målmiljöer (hårdvara, programvara, mellanprogramvara, operativsystem etc.). Specificering av tester för interoperabilitet kräver att alla kombinationer av de avsedda målmiljöerna är identifierade, konfigurerade och tillgängliga för testteamet. Dessa miljöer testas sedan genom att använda ett urval av de funktionella testfallen vilka exekverar de olika komponenterna som finns i den testade målmiljön.

Interoperabilitet är relaterat till hur olika programvarusystem interagerar med varandra. Programvaror med god interoperabilitet kan lätt integreras med ett antal andra system utan att det krävs stora förändringar. Antalet förändringar och hur stor insats som krävs för att genomföra dessa förändringar kan användas som ett mått på interoperabilitet.

Testning av programvarors interoperabilitet kan t.ex. fokusera på följande designegenskaper:

Användning av branschomfattande kommunikationsstandarder, såsom XML, i programvaran.

Förmågan hos programvaran att automatiskt identifiera och anpassa sig till kommunikations-behoven hos systemen som programvaran interagerar med.

Interoperabilitetstestning kan vara särskilt viktigt:

för organisationer som utvecklar standardprogramvara (COTS = Commersial Off The Shelf) och testverktyg

vid utveckling av system av system.

Den här typen av testning utförs huvudsakligen inom systemintegrationstestning.

5.2.4 Testning av Funktionell Informationssäkerhet

Testning av funktionell informationssäkerhet (penetreringstestning) undersöker förmågan hos programvaran att förhindra obehörig (avsiktlig eller oavsiktlig) åtkomst till funktioner eller data. Testningen fokuserar på användarrättigheter, åtkomst och privilegier. Säkerhetsrelaterad information bör, precis som all annan information, finnas tillgänglig i systemets specifikationer. Säkerhetstestning omfattar även ett antal aspekter vilka är mer relevanta för den tekniska testanalytikern och behandlas i avsnitt 5.3 nedan.

5.2.5 Testning av Användbarhet

Det är viktigt att förstå de svårigheter som användare kan uppleva hos ett föreslaget programvarusystem. För att förstå problematiken är det först nödvändigt att inse att benämningen ”användare” kan innefatta ett stort urval av olika typer av människor, exempelvis IT-experter, barn och människor med olika funktionshinder.

Vissa nationella institutioner (t.ex. ”British Royal National Institute for the Blind”) rekommenderar att webbsidor ska vara anpassade till olika typer av funktionshinder (t.ex. synskador, hörselskador, rörelsehinder och kognitiva nedsättningar). Genom att anpassa applikationer och webbsidor till dessa typer av användare förbättras användbarheten för alla.

Användbarhetstestning genomförs i allmänhet med identifierade typer av användare som ska uppnå formulerade mål i specifika miljöer eller situationer. Användbarhetstestning fokuserar på hur lämplig programvaran är för användarna i dessa situationer och inkluderar följande faktorer.

Ändamålsenlighet: till vilken grad programvaran möjliggör för användaren att uppnå de formulerade målen, i det specifika sammanhanget, med tillräcklig noggrannhet och full-ständighet.




Effektivitet: den mängd resurser (t.ex. tid) som användaren behöver lägga ned för att med programvaran uppnå de formulerade målen i det specifika sammanhanget.

Tillfredsställelse: förmågan hos programvaran att tillfredställa användarnas behov i ett specificerat sammanhang.

Attribut som kan mätas i samband med användbarhetstestning är:

förståelse: de egenskaper hos programvaran som påverkar graden av ansträngning som krävs av användaren för att förstå det logiska konceptet och dess användbarhet

inlärningsmöjlighet: de egenskaper hos programvaran som påverkar graden av ansträngning som krävs av användaren för att lära sig använda applikationen

funktionsduglighet: de egenskaper hos programvaran som påverkar graden av ansträngning som krävs av användaren för att utföra uppgifter ändamålsenligt och effektivt

attraktivitet: hur tilltalande programvaran är för användaren.

Utvärdering av användbarhet har två syften:

att avlägsna användbarhetsdefekter (kallas ibland för formativ utvärdering)

att testa användbarhetskrav (kallas ibland för summativ utvärdering).

Testare bör inneha expertis eller kunskaper inom följande områden:

sociologi

psykologi

nationella standarder (t.ex. “American Disabilities Act”)

ergonomi

Validering av den faktiska implementationen bör ske så verklighetstroget som möjligt. Det kan innebära uppsättning av ett användbarhetslabb med videokameror, kontorsmodeller, gransknings-paneler, användare etc., så att utvecklingsteamet kan iaktta vilken effekt användningen av systemet har på riktiga användare.

Många användbarhetstester kanske genomförs som del av andra tester, t.ex. under funktionella systemtester. Riktlinjer för användbarhet kan vara till stor hjälp för att uppnå ett konsekvent tillvägagångssätt för att upptäcka och rapportera användbarhetsfel inom hela livscykeln.

5.2.5.1 Tekniker för Användbarhetstestning

De väsentligaste teknikerna för användbarhetstestning är:

inspektion, utvärdering eller granskning

verifiering och validering av den faktiska implementationen

genomförande av enkäter och intervjuundersökningar.

Inspektion, Utvärdering eller Granskning

Ett kostnadseffektivt sätt att upptäcka problem tidigt kan vara att genomföra inspektioner eller granskningar av specifikationer och design ur ett användarperspektiv, vilket ökar användarens inflytande.

Heuristisk utvärdering (systematisk inspektion av användargränssnittets design med avseende på användbarhet) kan användas för att upptäcka användbarhetsproblem i designen så att dessa problem kan åtgärdas i den iterativa designprocessen. Det innebär att en liten grupp utvärderare undersöker gränssnittet och bedömer dess uppfyllelse av en rad erkända användbarhetsprinciper (”heuristikerna”).

Validering av den Faktiska Implementationen

För att genomföra validering av den faktiska implementationen kan tester som är specificerade för funktionella systemtester utvecklas till scenarier för användbarhetstest. Dessa testscenarier mäter specifika användbarhetsattribut, såsom inlärningshastighet eller funktionsduglighet, snarare än funktionella resultat.

Scenarier för användbarhetstest kan vara specifikt utvecklade för att testa syntax och semantik.




Syntax: strukturen eller grammatiken hos gränssnittet (t.ex. vad som kan skrivas i ett inmatningsfält).

Semantik: betydelsen och syftet (t.ex. vettiga och meningsfulla systemmeddelanden och utdata tillgängligt för användaren).

Tekniker för att utveckla dessa testscenarier kan vara:

specifikationsbaserade metoder, såsom beskrivna i t.ex. BS-7925-2.

användningsfall, antingen i klartext eller definierade med UML (Unified Modeling Language).

Testscenarier för användbarhetstester innehåller:

användarinstruktioner

tid avsatt till för- och slutintervjuer, för att ge instruktioner och för att ta emot återkoppling

överenskommet protokoll för genomförande av testsessionen. Detta protokoll innehåller en beskrivning av hur testet ska genomföras, tidsåtgång, anteckningar som ska föras och loggning av testsessionen samt vilka intervju- och enkätmetoder som ska tillämpas.

Enkäter och Intervjuundersökningar

Tekniker för enkäter och intervjuundersökningar kan tillämpas för att observera hur användare arbetar med systemet i ett labb för användbarhetstester. Standardiserade och offentligt tillgängliga enkäter såsom SUMI (Software Usability Measurement Inventory) och WAMMI (Website Analysis and MeasureMent Inventory) medger jämförelser mot en databas med tidigare genomförda användbarhetstester. Dessutom, eftersom SUMI tillhandahåller verkliga användbarhetsmätningar utgör detta en bra möjlighet att använda dem som avsluts- eller acceptanskriterier.

5.2.6 Testning av Tillgänglighet

Det är viktigt att betrakta tillgängligheten hos programvaran för dem som har särskilda krav på eller begränsningar av användningen av programvaran. Detta inkluderar bland annat personer med funktionshinder. Relevanta standarder ska beaktas, såsom ”Web Content Accessibility Guidelines” och lagstiftningar, såsom ”Disability Discrimination Acts” (UK, Australia) och ”Section 508” (US).


Kvalitetsattribut för tekniska testanalytiker är fokuserade på “hur” produkten fungerar, snarare än på funktionella aspekter av ”vad” den gör. Dessa tester kan genomföras inom vilken testnivå som helst, men är särskilt relevanta för:

Komponenttest (speciellt realtids- och inbyggda system):

prestandamätningar

resursanvändning

Systemtest och driftacceptanstest:

omfattar alla kvalitetsattribut som nämns nedan, i enlighet med risker och tillgängliga resurser.

teknikorienterade tester på dessa nivåer fokuserar på testning av kompletta och driftslika system, dvs. kombinationer av hårdvara och programvara, däribland servrar, klienter, data-baser, nätverk och övriga resurser.

Det är vanligt att tester fortsätter att genomföras efter att produkten har driftsatts. Dessa tester genomförs ofta av ett separat team eller organisation. Mätningar av kvalitetsattribut insamlade under så kallade för-produktionstester, kan utgöra grunden till servicenivåavtal (SLA = Service Level Agreements) mellan leverantören av programvarusystemet och dess operatör.




I gruppen kvalitetsattribut för tekniska testanalytiker ingår:

teknisk informationssäkerhet.

tillförlitlighet

effektivitet

underhållbarhet

portabilitet

5.3.1 Testning av Teknisk Informationssäkerhet

Testning av informationssäkerhet skiljer sig på två viktiga sätt från andra typer av domän eller teknisk testning.

1. Standardtekniker som används för urval av indata för test kan missa viktiga informationssäkerhetsproblem.

2. Symptom på informationssäkerhetsfel skiljer sig mycket från andra typer av felsymptom.

Många säkerhetsproblem kommer av att programvaran inte enbart fungerar som den är designad utan även utför extra handlingar som inte är avsiktliga. Dessa sidoeffekter utgör ett av de största hoten mot programvarans informationssäkerhet. Ett exempel är en mediaspelare som helt korrekt spelar upp ljud, men gör det genom att skriva data på okrypterade temporära lagringsplatser, vilket kan utnyttjas av programvarupirater.

För informationssäkerhet är den största utmaningen att förhindra att obehöriga personer använder information på ett icke avsiktligt sätt. Säkerhetstestning innebär att försöka forcera ett systems säkerhetsspärrar för att testa systemets förmåga att stå emot olika säkerhetshot, såsom:

obehörig kopiering av applikationer eller data (t.ex. piratkopiering)

obehörig åtkomst (t.ex. möjligheten att utföra aktiviteter för vilket användaren i fråga inte har rättigheter till)

buffertöverskridande, vilket kan orsakas av att extremt långa strängar matas in i ett inmatningsfält i användargränssnittet. När väl ett buffertöverskridande har inträffat kan det finnas möjlighet att exekvera skadliga kodinstruktioner

blockering av tjänst (DoS - ”Denial of Service”), vilket förhindrar andra användare från att interagera med en applikation (t.ex. genom att överbelasta en webbserver med nonsens)

avlyssning av dataöverföringar via nätverk med syfte att komma över känslig information (t.ex. överföringar av kreditkortsinformation)

knäckning av krypteringskoder som används för att skydda känsligt data

logiska bomber (kallas ibland för “Easter Eggs” i USA), vilka kan vara uppsåtligt inlagda i koden och som aktiveras under vissa förutsättningar (t.ex. på ett specifikt datum). När logiska bomber aktiveras kan de utföra skadliga aktiviteter såsom radering av filer eller formatering av diskar.

Informationssäkerhetsproblem kan grupperas enligt följande:

användargränssnittsrelaterade: o obehörig åtkomst o inmatning av skadliga data

filsystemrelaterade: o åtkomst av känsliga data lagrade i filer eller lagringsplatser (databaser)

operativsystemrelaterade: o lagring av känslig information, såsom okrypterade lösenord lagrade i minnet som skulle

kunna göras åtkomliga genom att krascha systemet t.ex. med hjälp av. inmatning av skadliga data

relaterade till extern programvara: o samverkan mellan externa komponenter som systemet utnyttjar. Problem kan förekomma

både på nätverksnivå (t.ex. felaktiga datapaket eller meddelanden som skickas) och på programvarukomponentnivå (t.ex. avvikelser hos en programvarukomponent som programvaran litar på)




Det bör noteras att förbättringar av ett systems informationssäkerhet kan påverka dess prestanda. Därför är det klokt att genomföra prestandatester igen efter att förbättringar av informationssäkerheten har genomförts.

5.3.1.1 Tekniker för Testning av Informationssäkerhet

Följande tillvägagångssätt kan användas för att utveckla tester för informationssäkerhet.

Informationsinsamling En profil- eller nätverkskarta över systemet konstrueras med hjälp av generellt tillgängliga hjälpmedel. Denna information kan innehålla namn på anställda, fysiska adresser, detaljer rörande det interna nätverket, IP-nummer, programvarans och hårdvarans identitet samt operativsystemets utgåva.

Sårbarhetsanalys Systemet skannas med generella verktyg. Sådana verktyg används inte direkt för att utföra själva testningen utan för att identifiera svagheter som är, eller kan resultera i, överträdelser av informationssäkerhetspolicyn. Specifika svagheter kan även identifieras med hjälp av checklistor, såsom de som finns tillgängliga på www.testingstandards.co.uk.

Attackplaner Baserat på den insamlade informationen kan “attackplaner” utvecklas. Attackplaner är planer för testning med avsikt att knäcka en specifik informationssäkerhetspolicy i systemet. Ofta krävs en stor mängd indata i många olika gränssnitt (t.ex. användargränssnitt och filsystem) för att upptäcka de allvarligaste informationssäkerhetsfelen. De olika typerna av “attacker” som beskrivs i [Whittaker04] är en värdefull källa till tekniker som är speciellt utvecklade för testning av informationssäkerhet. För mer information om ”attacker”, se avsnitt 4.4.

5.3.2 Tillförlitlighetstestning

En målsättning med tillförlitlighetstestning är att via statistiska mätetal övervaka programvarans mognad över tiden och jämföra denna med ett önskvärt tillförlitlighetsmål. Mätetalen kan vara av typen MTBF (”Mean Time Between Failures”), MTTR (”Mean Time To Repair”) eller någon annan typ av mätning av felintensitet (t.ex. antal avvikelser av en specifik allvarlighetsgrad per vecka). Utvecklingen över tiden av de använda mätetalen kan uttryckas i form av en ”Reliability Growth Model”.

Tillförlitlighetstestning kan utföras genom att upprepa en uppsättning förutbestämda tester, genom att välja slumpmässigt från en pool av testfall eller genom att generera testfall från en statistisk modell. Som en konsekvens av att man behöver statistisk signifikans krävs vanligtvis många testfall vilket gör att tillförlitlighetstestning kan ta betydande tid i anspråk (i storleksordningen dagar).

Analyser av programvarans mognadstillväxt över tiden kan användas som avslutskriterier (t.ex. vid frisläppning för produktion). Specifika mätningar såsom MTBF och MTTR kan också användas i servicenivåavtal och övervakas under drift.

“Software Reliability Engineering and Testing” (SRET) är ett standardiserat tillvägagångssätt för tillförlitlighetstestning.

5.3.2.1 Robusthetstestning

Medan funktionell testning undersöker programvarans feltolerans i form av att kunna hantera oväntade indatavärden (så kallade negativa tester), så utvärderar tekniskt orienterade tester ett systems förmåga att hantera fel som uppkommer utanför den testade applikationen. Sådana fel rapporteras vanligtvis av operativsystemet (t.ex. fulla diskar, processer eller tjänster som inte är tillgängliga, filer som inte hittas, minne som inte är tillgängligt etc.). Feltoleranstester på systemnivå kan stödjas av verktyg.

5.3.2.2 Testning av Återhämtningsbarhet

En ytterligare typ av tillförlitlighetstestning fokuserar på programvarans förmåga att kunna återhämta sig efter en hårdvaru- eller programvaruavvikelse, vilket ska resultera i att normal drift återupptas. Testning av återhämtningsbarhet inkluderar ”Failover”- och “Backup & Restore”-tester.




I vissa system måste systemdriften säkerställas även om det sker programvaruavvikelser. I sådana system implementeras normalt mekanismer i hårdvara och/eller programvara som utan driftsavbrott överför exekveringen från en enhet till en annan i händelse av avvikelser hos den första enheten. “Failover”-tester syftar till att testa dessa mekanismer och kan vara tillämpliga där t.ex. risken för finansiella förluster är extrem eller där kritiska säkerhetsproblem förekommer. I de fall då testningen inkluderar katastrofala händelser kan denna typ av testning av återhämtningsbarhet även kallas “disaster recovery”-testning.

Typiska hårdvaruåtgärder för återhämtningsbarhet kan innefatta lastbalansering över ett flertal processorer respektive klustring av servrar, processorer eller diskar, så att en sekundär enhet omedelbart kan ta över från en primär enhet om denna skulle gå ner (t.ex. RAID: ”Redundant Array of Inexpensive Disks”). En typisk programvaruåtgärd kan innebära implementering av flera oberoende instanser av ett programvarusystem (t.ex. ett flygplans flygledningssystem) i så kallade redundant olika system. Redundanta system innehåller oftast en kombination av programvaru- och hårdvaruåtgärder och kan kallas för duplex-, triplex- eller quadruplexsystem, beroende på antalet oberoende instanser (2, 3 eller 4 respektive). Olikhetsaspekten i de så kallade redundant olika systemen uppnås genom att programvarukrav är tillgängliga för två (eller fler) helt oberoende utvecklingsteam. Målet är att tillhandahålla samma funktionaliteter med olika programvaror, vilket gör det mindre sannolikt att defekta indata som orsakar problem för ett system ska få samma effekt i de övriga systemen. Dessa åtgärder som görs för att förbättra återhämtningsbarheten hos ett system kan även direkt påverka dess tillförlitlighet och bör också beaktas när tillförlitlighetstestning genomförs.

“Failover”-testning är explicit designat för att testa redundanta system genom att simulera felsymptomslägen eller framkalla dessa i en kontrollerad miljö. ”Failover”-mekanismen testas genom att först injicera fel i systemet för att framkalla ett specifikt felsymptom. Därefter kontrolleras att data inte går förlorat eller blir korrupt, samt att överenskommen servicenivå upprätthålls (t.ex. funktionsåtkomst och svarstider) trots det uppkomna felsymptomet. För mer information om ”failover”-testning, se www.testingstandards.co.uk.

”Backup & Restore”-tester fokuserar på implementerade åtgärder för att minimera effekterna av ett felsymptom. Testning görs av manuella och automatiska ”Backup & Restore”-rutiner och kontrollerar att data inte gått förlorat eller blivit korrupt efter en ”backup” följt av en ”restore”. Testfallen är utvecklade för att säkerställa att de kritiska vägarna genom rutinerna fungerar. Tekniska granskningar kan genomföras för att ”torrköra” dessa scenarier och validera manualer mot den gällande installationsrutinen. Driftacceptanstester validerar scenarier i en produktions- eller produktionslik miljö.

”Backup & Restore”-tester kan innefatta följande:

tidsåtgång för genomförande av en viss typ av ”backup” (t.ex. fullständig eller inkrementell)

tidsåtgång för återläsning av data (”restore”)

garanterade nivåer av återställande av data (t.ex. återställande av all data som inte är äldre än 24 timmar, återställande av specifikt transaktionsdata som inte är äldre än en timme).

5.3.2.3 Tekniker för Tillförlitlighetstestning

Tillförlitlighetstester baseras oftast på användningsmönster (även kallat “driftsprofiler”) och kan genomföras formellt eller utifrån risker. Testdata kan genereras med slumpbaserade metoder.

Om man använder en modell för att åskådliggöra systemets tillförlitlighetsökning över tiden bör valet av modell motiveras. För en given uppsättning av mätningar av tillförlitligheten hos ett system vid olika tidpunkter, kan verktyg användas för att identifiera den matematiska funktionen som bäst stämmer överens med de tillgängliga mätningarna.

Tillförlitlighetstester kan även användas för att upptäcka minnesläckor. Detta kräver upprepad exekvering av särskilt minnesintensiva aktiviteter, för att kunna kontrollera att reserverat minne lämnas tillbaka på ett korrekt sätt.

http://www.testingstandards.co.uk/




5.3.3 Effektivitetstestning

Kvalitetsattribut för effektivitet utvärderas genom tester som fokuserar på tids- och resursbeteenden. De tidsrelaterade aspekterna av effektivitetstestning tas upp nedan genom prestanda-, last-, stress- och skalbarhetstestning.

5.3.3.1 Prestandatestning

Prestandatestning kan generellt indelas i olika kategorier beroende på vilken icke-funktionell aspekt som ska testas, inklusive prestanda-, last-, stress- och skalbarhetstester.

Specifik prestandatestning fokuserar på förmågan hos en komponent eller ett system att reagera på inmatningar från användare eller andra system inom en specificerad tid och under specificerade villkor (se även last och stress nedan). Typ av prestandamätningar varierar med testmålen. För enskilda komponenter kan prestanda mätas i CPU-cykler, medan prestanda för klientbaserade system oftast mäts i svarstid för ett bestämt användaranrop. För system vars arkitektur består av många komponenter (t.ex. klienter, servrar, databaser) görs prestandamätningar både på helheten och på individuella komponenter så att prestandaflaskhalsar kan identifieras.

5.3.3.2 Lasttestning

Lasttestning fokuserar på förmågan hos systemet att hantera ökade nivåer av förutsedda realistiska laster, vilka är resultat av systemanrop från många parallella användare. Genomsnittliga svarstider för olika vanligt förekommande användarscenarier (driftsprofiler) mäts och analyseras. Se även [Splaine01].

Det finns två typer av lasttestning, fleranvändartestning (med realistiskt antal användare) och volymtestning (med ett stort antal användare). Lasttestning tittar både på svarstider och på nätverkskapacitet.

5.3.3.3 Stresstestning

Stresstestning fokuserar på förmågan hos ett system att hantera belastningar som ligger på eller bortom den för systemet maximala kapaciteten. När systemets last ökar bör prestanda hos systemet degraderas långsamt och förutsägbart utan felsymptom. Vid stresstestning bör den funktionella integriteten hos systemet testas, för att upptäcka funktionella fel i kod eller data som uppkommer på grund av den höga belastningen.

En möjlig målsättning med stresstestning är att upptäcka den faktiska gränsen för när systemet fallerar så att den ”svagaste länken i kedjan” kan identifieras. Identifiering av den svagaste länken via stresstestning gör att systemet kan utökas med ytterligare komponenter, t.ex. minne, CPU kapacitet, databaslagring, i rätt ordning.

I ”spike”-testning simuleras kombinationer av förutsättningar som kan resultera i en plötslig extrem last av systemet. Flera sådana spikar med mellanliggande perioder av låg användning kallas för ”bounce”-tester. Dessa tester fastställer hur bra systemet kan hantera laster och huruvida det har förmågan att begära och släppa systemresurser allt efter behov. Se även [Splaine01].

5.3.3.4 Skalbarhetstestning

Skalbarhetstestning fokuserar på förmågan hos systemet att uppfylla framtida effektivitetskrav, vilka kan vara utöver de som för närvarande ställs på systemet. Målet med testerna är att bedöma systemets förmåga att växa (t.ex. med fler användare, större mängd data lagrat) utan att fastställda prestandakrav överskrids eller att systemet slutar fungera. När gränserna för systemets förmåga att växa väl är kända, kan tröskelvärden sättas upp och övervakas i produktion för att ge en varning om annalkande problem.

5.3.3.5 Test av Resursanvändning

Effektivitetstestning kan även relatera till resursanvändning och i dessa sammanhang utvärdera användningen av systemresurser (t.ex. minnesutrymme, diskkapacitet och nätverksbandbredd). Resursanvändning kontrolleras både under normal belastning och under stress, såsom höga nivåer av




transaktioner eller datavolymer. Till exempel är minnesutnyttjande (ibland kallat ”memory footprint”) en viktig komponent vid prestandatestning av inbyggda realtidssystem.

5.3.3.6 Tekniker för Testning av Effektivitet

Specificeringen av testfall för de olika typerna av effektivitetstester, såsom prestanda, last och stress, baserar sig på definitioner av driftsprofiler. Varje driftsprofil representerar en specifik typ av användning av en applikation och innehåller en beskrivning av interaktionen mellan användaren och applikationen. För en given applikation kan det finnas ett flertal driftsprofiler.

Antalet användare per driftsprofil som ska användas under testningen kan antingen mätas m.h.a. övervakningsverktyg på en verklig eller jämförbar applikation eller genom att estimera antalet användare. Sådan estimering kan vara baserad på algoritmer eller tillhandahållas av affärs-organisationen och är särskilt viktig vid skalbarhetstestning.

Driftsprofiler är basen för testfall och genereras oftast av testverktyg. I detta sammanhang används ofta begreppet ”virtuella användare” för att representera en simulerad användare inom driftsprofilen.

5.3.4 Testning av Underhållbarhet

Tester av underhållbarhet relaterar i allmänhet till hur lätt programvaran kan analyseras, förändras och testas. Statisk analys och användning av checklistor är lämpliga tekniker.

5.3.4.1 Dynamisk Testning av Underhållbarhet

Dynamisk testning av underhållbarhet syftar till att testa de dokumenterade procedurerna för underhåll av en specifik applikation (t.ex. för uppgraderingar av programvaran). Ett urval av underhållsscenarier används som testfall för att säkerställa att begärda servicenivåer kan uppnås med hjälp av de dokumenterade procedurerna.

Den här typen av testning är särskilt relevant när den underliggande infrastrukturen är komplex och supportrutiner kanske involverar flera olika avdelningar/organisationer. Den kan ibland genomföras som en del av driftacceptanstestningen. [www.testingstandards.co.uk]

5.3.4.2 Analysbarhet (Felavhjälpande Underhåll)

Denna typ av testning av underhållbarhet fokuserar på mätningar av tiden det tar att diagnostisera och åtgärda problem inom ett system. Ett enkelt mått kan vara genomsnittstiden för att diagnostisera och åtgärda ett identifierat fel.

5.3.4.3 Förändringsbarhet, Stabilitet och Testbarhet (Underhåll vid Förändring)

Underhållbarheten av ett system kan också mätas i form av den ansträngning som krävs för att göra förändringar i systemet (t.ex. kodförändringar). Eftersom ansträngningen som krävs är beroende av ett antal olika faktorer, såsom designmetoder för programvara (t.ex. objektorientering), kodstandarder etc. kan den här typen av underhållstestning även utföras genom analyser och granskningar. Testbarhet relaterar till den ansträngning som krävs för att testa genomförda förändringar i programvaran. Stabilitet relaterar till förändringars generella effekt på ett system. System med låg stabilitet uppvisar ett stort antal kedjereaktionsproblem (dominoeffekter, även känt som efterdyningar) efter att förändringar har genomförts i programvaran. [ISO9126] [www.testingstandards.co.uk]

5.3.5 Portabilitetstestning

Portabilitetstester relaterar i allmänhet till hur lätt programvara kan överföras till sin avsedda miljö, antingen initialt eller från en sedan tidigare existerande miljö. Portabilitetstester innefattar tester av installerbarhet, kompatibilitet/samexistens, anpassningsmöjlighet och ersättningsbarhet.

5.3.5.1 Testning av Installerbarhet

Vid testning av installerbarhet är testobjektet den programvara som ska användas för att installera annan programvara i dess målmiljö. Testobjekt kan t.ex. vara programvara speciellt utvecklad för att






installera ett operativsystem på en processor eller en installations-wizard, som används för att installera en produkt på en PC-klient. Följande lista innehåller typiska målsättningar för testning av installerbarhet.

Verifiering och validering av att installationen av en programvara lyckas när instruktionerna i en installationsmanual följs. Detta inkluderar även användning av eventuella installationsskript eller en installations-wizard. Om flera installationsalternativ existerar, t.ex. olika hårdvaru- och programvarukonfigurationer eller olika grader av installation (t.ex. fullständig eller delvis), så ska alla dessa alternativ testas.

Testning av att avvikelser som kan uppkomma under installationen (t.ex. en misslyckad laddning av en specifik DLL) inte leder till att systemet hamnar i ett okänt läge (t.ex. program-vara som bara delvis blivit installerad eller systemkonfigurationer som inte fungerar på rätt sätt).

Testning av att en ofullständig (avbruten) installation/avinstallation kan slutföras.

Testning av att en installations-wizard klarar av att identifiera ogiltiga hårdvaruplattformar eller ogiltiga operativsystemkonfigurationer.

Kontroll av att installationsprocessen kan slutföras inom ett specificerat antal minuter eller inom ett specificerat antal steg.

Verifiering och validering av att programvaran kan degraderas eller avinstalleras.

Normalt brukar installationstestningen kompletteras med en funktionell testning för att upptäcka eventuella fel som kan ha blivit införda i systemet av installationen (t.ex. felaktiga konfigurationer, funktioner som inte är tillgängliga). Parallellt med installationstestningen genomförs ofta användbar-hetstestning (t.ex. för att kontrollera att installationsinstruktionerna och eventuella åter-matningar/felmeddelanden under installationen är förståeliga för användaren).

5.3.5.2 Samexistens och Kompatibilitet

Datorsystem som inte är relaterade till varandra sägs vara samexisterande om de kan köra på samma miljö (t.ex. på samma hårdvara) utan att påverka varandras beteende (t.ex. resurskonflikter). Samexistenstester kan genomföras, t.ex. när ny- eller uppgraderad programvara rullas ut i en miljö (t.ex. servrar), vilken redan innehåller installerade applikationer.

Samexistensproblem kan inte upptäckas när en applikation testas i en miljö där den är den enda installerade applikationen. Däremot kan dessa problem upptäckas när en applikation testas i en miljö (t.ex. produktionsmiljön) som även kör andra applikationer.

Typiska målsättningar för samexistenstestning är:

utvärdering av möjlig negativ påverkan på funktionaliteten när flera applikationer är instal-lerade i samma miljö (t.ex. konflikter i resursanvändning när en server kör flera applikationer)

utvärdering av hur applikationer påverkas av rättningar och uppgraderingar av operativ-systemet.

Två datorsystem eller programvaror sägs vara kompatibla om de båda följer en gemensam standard, för t.ex. hantering av data. Detta kan t.ex. innebära att man kan klippa och klistra över applikationsgränser eller att en applikation kan öppna en fil som är skapad av en annan applikation. Det kan även handla om s.k. bakåt-kompatibilitet, dvs. att en nyare version av en applikation kan hantera data skapad i en tidigare version

Målsättningen för kompatibilitetstestning beror på vad kompatibiliteten består av, men kräver minst två applikationer, eller versioner av applikationer eller datorsystem – en producent och en konsument.

Testning av samexistens och kompatibilitet utförs oftast efter att systemtestningen och användar-acceptanstestningen är framgångsrikt avslutade.

5.3.5.3 Testning av Anpassningsmöjlighet

Testning av anpassningsmöjlighet undersöker om en given applikation kan fungera på ett korrekt sätt i alla för applikationen avsedda målmiljöer (hårdvara, programvara, mellanprogramvara, operativ-system, etc.). Specificering av tester för anpassningsmöjlighet kräver identifiering av alla olika typer




och versioner av de delar som målmiljön kan bestå av. Dessutom behöver alla relevanta kombina-tioner av delar av målmiljön vara identifierade, konfigurerade och finnas tillgängliga för testteamet. Dessa miljöer testas sedan med hjälp av ett urval av funktionella tester som exekverar de olika komponenterna som finns i miljön.

Anpassningsmöjlighet kan relatera till programvarans förmåga att kunna flyttas till olika specificerade miljöer genom att använda en fördefinierad procedur. Testningen kan även utvärdera själva proceduren.

Testning av anpassningsmöjlighet kan utföras i kombination med testning av installerbarhet och följs oftast av funktionella tester för att upptäcka möjliga fel som kan ha blivit införda när programvaran flyttats till en annan miljö.

5.3.5.4 Testning av Ersättningsbarhet

Ersättningsbarhet fokuserar på förmågan hos ett system att kunna ersätta dess programvaru-komponenter med andra programvarukomponenter. Det kan vara särskilt relevant för system som använder kommersiell programvara (COTS - Commercial Off The Shelf) för vissa komponenter i systemet.

Test av ersättningsbarhet kan utföras parallellt med funktionella integrationstester där mer än en alternativ komponent finns tillgänglig för integration med det kompletta systemet. Ersättningsbarhet kan även utvärderas med hjälp av tekniska granskningar eller inspektioner, där tyngdpunkten ligger på att kontrollera tydligheten i definitionerna av de gränssnitt som ska användas av potentiella ersätt-ningskomponenter.




6. Granskningar

Begrepp

Administrationsgranskning, genomgång, granskare, granskning, IEEE 1028, informell granskning, inspektion, inspektionsledare, moderator, revision(audit), teknisk granskning

6.1 Inledning

En lyckad granskningsprocess fordrar planering, aktivt deltagande och uppföljning. Kurshållare måste försäkra sig om att testledaren förstår sitt ansvar för planering och uppföljningsaktiviteter. Testare måste delta aktivt i granskningsprocessen och bidra med sina speciella kunskaper och infallsvinklar. För att bättre förstå sina respektive roller i de olika tekniska granskningsprocesserna bör alla ha fått en formell utbildning i hur granskningar går till. Alla som deltar i granskningar måste känna till och förstå fördelarna med en väl genomförd teknisk granskning. Korrekt genomförda inspektioner ger det enskilt största och mest kostnadseffektiva bidraget till den totala levererade kvaliteten. IEEE 1028 är en internationell standard för granskningar.

6.2 Granskningsprinciper

En granskning är en typ av statisk testning. Huvudsyftet med granskningar är oftast att hitta defekter. Granskare hittar defekter genom att undersöka själva dokumentet.

De grundläggande granskningsmetoderna beskrivs i avsnitt 3.2 i grundkursens kursplan (version 2007) och listas nedan i avsnitt 6.3.

För alla granskningsmetoder gäller att resultatet blir bäst om de genomförs så fort som alla relevanta källdokument (dokument som beskriver projektkraven) och standarder (som projektet måste uppfylla) finns tillgängliga. Om något dokument eller standard saknas, kan man inte upptäcka defekter och inkonsekvenser mellan dokumenten utan bara i enstaka dokument. Granskare måste också få tillgång till dokumentet i så god tid att de hinner genomföra granskningen på ett adekvat sätt.

Granskning kan genomföras för alla typer av dokument, till exempel källkod, kravspecifikationer, utkast, skisser, testplaner, testdokument, osv. Dynamisk testning följer normalt på granskning av källkod; dessa tester är designade att hitta sådana defekter, som inte kan hittas med statiska metoder.

En granskning kan leda till tre möjliga resultat.

Dokumentet kan användas som det är eller efter mindre ändringar.

Dokumentet måste uppdateras men ingen ytterligare granskning är nödvändig.

Dokumentet måste ändras så mycket att en ny granskning är nödvändig .

Roller och ansvar för personer, som deltar i en typisk formell granskning, t.ex. ledare/chef, moderator eller mötesledare, författare, granskare och sekreterare beskrivs i grundkursens kursplan. Andra som kan vara inblandade i granskningar är beslutsfattare eller andra intressenter, samt kunder och användarrepresentanter. Ytterligare en valfri roll, som ibland används i inspektioner, är en uppläsare. Under granskningsmötet läser uppläsaren det granskade dokumentet högt och kan ge förklaringar och omskrivningar av eventuella otydligheter. Förutom sin granskningsroll kan individuella granskare också tilldelas en defektbaserad roll som innebär att granskaren ska leta efter speciella typer av defekter.

Flera granskningsmetoder kan tillämpas på en enstaka arbetsprodukt. Ett team kan till exempel genomföra en teknisk granskning för att besluta vilka funktioner som skall införas i en kommande iteration. Inspektioner kan sedan genomföras på specifikationerna som innehåller de nya funktionerna.




6.3 Granskningsmetoder

Grundnivåns kursplan beskrev följande granskningsmetoder:

informell granskning

genomgång

teknisk granskning

inspektion

I praktiken kan även hybrider av dessa granskningsmetoder finnas, t.ex. en teknisk granskning med en uppsättning regler.

6.3.1 Administrationsgranskning, och Revision

Förutom de metoder som nämndes i grundkursens kursplan beskriver IEEE 1028 också följande granskningsmetoder:

administrationsgranskning

revision (Audit)

De viktigaste kännetecknen hos en administrationsgranskning är:

huvudsyften: att från ett projektperspektiv övervaka progress, utvärdera status och besluta om åtgärder som behöver vidtas

genomförs av eller är till för projektledare och produktägare

genomförs av eller är till för intressenter eller beslutsfattare, t.ex. högre linjechefer eller styrelseledamöter

kontrollerar överensstämmelse med och avvikelser från planer eller ledningsprocessernas tillämpbarhet

innehåller utvärdering av projektrisker

resultatet innehåller åtgärder som ska genomföras och frågeställningar som skall lösas

deltagare förväntas vara förberedda

beslut dokumenteras.

Observera att testledare bör delta i och vid behov uppmana till administrationsgranskningar av testprogressen.

Revisioner, även kallat ”audit”, är ytterst formella och genomförs för att visa överensstämmelse med vissa krav eller förväntningar, oftast härrörande från tillämpliga standarder eller kontraktsåtaganden. Som sådan är revision den minst effektiva metoden när det gäller att upptäcka defekter.

Följande lista innehåller de viktigaste kännetecknen hos en revision.

Huvudsyftet är att oberoende utvärdera överensstämmelse med processer, legala krav, standarder osv.

En revisionsledare ansvarar för revisionen och är mötesledare under granskningsmöten.

Revisorer samlar in bevis för överensstämmelse genom att intervjua, bevittna projektaktiviteter och undersöka dokument.

Revisionen utmynnar i observationer, rekommendationer, korrigerande åtgärder och en bedömning av utfallet (godkänt eller inte).




6.3.2 Granskningar av Speciella Arbetsprodukter

Granskningar kan även namnges i termer av de arbetsprodukter eller aktiviteter som skall granskas, såsom

kontraktsgranskning

kravgranskning

designgranskning o preliminär designgranskning o kritisk designgranskning

acceptansgranskning/kvalificeringsgranskning

granskning av driftsättningsmognad

En kontraktsgranskning kan vara associerad med en kontraktsmilstolpe och skulle typiskt genomföras i form av en administrationsgranskning. I en sådan bör chefer, kunder och teknisk personal medverka. I synnerhet för säkerhetskritiska eller säkerhetsrelaterade system är kontraktsgranskningar vanliga.

En kravgranskning kan genomföras i form av en genomgång, en teknisk granskning eller en inspektion, och kan ta hänsyn till såväl säkerhetskrav och driftssäkerhetskrav som funktionella och icke-funktionella krav. En kravgranskning kan även inkludera acceptanskriterier och testvillkor.

Designgranskningar genomförs oftast i form av tekniska granskningar eller inspektioner och involverar teknisk personal samt kunder eller andra intressenter. Den preliminära designgranskningen syftar till att utvärdera utkast av teknisk design och testning. Den kritiska designgranskningen täcker alla föreslagna designlösningar, inklusive testfall och procedurer.

Acceptansgranskningar genomförs för att få ledningens godkännande av ett system. Detta kallas också kvalificeringsgranskning, och genomförs normalt i form av en administrationsgranskning eller en revision.

6.3.3 Att Genomföra en Formell Granskning

I grundkursens kursplan beskrivs sex faser i en formell granskning: planering, kick-off, individuell förberedelse, granskningsmöte, omarbetning och uppföljning. Det är viktigt att bemanna granskningar med personer som har lämplig bakgrund för den arbetsprodukt som skall granskas. T.ex. ska testplaner granskas av testledare, affärskrav eller testdesign granskas av testanalytiker och funktions-specifikationer, testfall eller testskript granskas av tekniska testanalytiker.

6.4 Införande av Granskningar

För att lyckas med införandet av granskningar i en organisation måste följande steg tas (inte nödvändigtvis i nedanstående ordning):

försäkra sig om ledningens stöd

utbilda beslutsfattare om kostnader, vinster, problem och frågeställningar i samband med införande av granskningsmetodik

välja ut och dokumentera granskningsprocedurer inklusive format och infrastruktur (t.ex. en databas för mätetal associerade med granskningar)

utbilda deltagarna i granskningstekniker och procedurer

se till att få stöd från dem som skall genomföra granskningar och dem som skall få sitt arbete granskat

genomföra pilotgranskningar

visa på fördelarna med granskningar, främst kostnadsbesparingar

tillämpa granskningar på de viktigaste dokumenten, t.ex. kontrakt, planer osv.




Granskningsprocesser bör kontinuerligt ses över och förbättras allt efter som. Ledningen bör vara medveten om att införandet av en ny granskningsteknik är en investering – vinsterna kommer inte omedelbart men kommer att öka signifikant med tiden.

6.5 Framgångsfaktorer för Granskningar

Det finns ett antal faktorer, som bidrar till framgångsrika granskningar. Granskningar behöver inte vara svåra att genomföra, men om inte nedanstående tekniska, organisatoriska och mänskliga faktorer beaktas ökar riskerna att granskningen inte når tillfredställande resultat.

Tekniska Faktorer

Säkerställ att den definierade granskningsprocessen följs på ett korrekt sätt, speciellt när det gäller de mer formella granskningsmetoderna såsom inspektioner.

Dokumentera granskningskostnaderna (inklusive den tid som lagts ner) samt de uppnådda vinsterna.

Granska tidiga utkast eller delar av dokument för att hitta systematiska fel innan dessa byggs in i hela dokumentet.

Säkerställ att dokumentet, eller den del av dokumentet, som ska granskas är moget för granskning innan granskningsprocessen startas genom att tillämpa startkriterier.

Använd organisationsspecifika checklistor för vanligt förekommande fel.

Använd flera granskningsmetoder, valet av metod beror på syftet med granskningen. Exempel på syften är ensning av dokument, teknisk förbättring, informationsöverföring och granskning av projektprogress.

Innan administrationsgranskning genomförs i syfte att besluta om en större investering, se till att granska eller inspektera alla viktiga dokument, som ligger till grund för detta beslut till exempel implementeringsförslag, kontrakt eller högnivåkrav.

Dokument kan stickprovgranskas. Observera att stickprovsgranskning inte kan ersätta ensning.

Uppmuntra identifieringen av de viktigaste defekterna, fokusera på innehåll - inte format.

Förbättra granskningsprocessen kontinuerligt.

Organisatoriska Faktorer

Säkerställ att ledningen tillåter att tillräckligt mycket tid avsätts för granskningsaktiviteter, även under tidspress.

Observera att nedlagd tid och spenderade pengar inte behöver stå i proportion till antal hittade fel.

Avsätt tillräckligt mycket tid för omarbetning på grund av defekter som hittats vid granskningarna.

Använd aldrig mätvärden insamlade vid granskningar för prestandabedömning av individer.

Säkerställ varje granskning, oavsett typ, genomförs med att rätt bemanning.

Genomför granskningsutbildning, speciellt för de formella granskningsmetoderna.

Skapa ett mötesforum för granskningsledarna där de kan utbyta idéer och erfarenheter.

Säkerställ att alla deltar i granskningar och att alla får sina dokument granskade.

Tillämpa de mest formella granskningsmetoderna på de viktigaste dokumenten.

Skapa välbalanserade granskningsteam med individer som har olika kunskaper och bakgrunder.

Processförbättringsaktiviteter bör genomföras så att systematiska problem, identifierade under granskningar, kan avhjälpas.

Tillvarata förbättringar som identifierats under granskningsprocessen.




Mänskliga Faktorer

Utbilda intressenter och beslutsfattare så att de förstår att defekter kommer att hittas och att tid måste avsättas för omarbetning och omgranskning.

Säkerställ att granskningar genomförs på ett för författarna positivt sätt.

Skapa en positiv anda som uppmuntrar upptäckt av defekter utan att skuldbelägga författaren.

Säkerställ att kommentarer är konstruktiva, användbara och objektiva, inte subjektiva.

Genomför inte granskningar mot författarens vilja.

Uppmuntra deltagarna att vara extra noggranna när det gäller de viktigaste aspekterna av dokumenten som granskas.

För mer information om granskningar och inspektioner se [Gilb93] och [Weigers02].




7. Avvikelsehantering

Begrepp

allvarlighet, anomali, avvikelse, avvikelseloggning, defekt, felsymptom, grundorsaksanalys (RCA), IEEE 829, IEEE 1044, IEEE 1044.1, incident, CCB, misstag, prioritet

7.1 Inledning

Både testledare och testare ska känna till och kunna tillämpa felhanteringsprocessen. Testledare fokuserar på själva processen, bland annat metoder för att hitta, spåra och ta bort defekter, medan testare primärt är engagerade med att registrera de problem som hittats inom det egna testområdet. Testanalytikers och tekniska testanalytikers arbete har olika inriktning i de olika livscykelstegen. Testanalytiker utvärderar ett systems beteende ur affärs- eller användarbehov, t.ex., om det är det möjligt för en användare att veta vad han skall göra när ett meddelande dyker upp eller om systemet beter sig oväntat. Tekniska testanalytiker utvärderar hur själva programvaran uppför sig och undersöker problem ur teknisk synvinkel, t.ex. undersöka om samma avvikelse uppträder på olika plattformar eller med olika minneskonfigurationer.

7.2 När kan Defekter Detekteras?

En avvikelse är en oväntad händelse som kräver ytterligare utredning. En defekt är ett verkligt fel, som man har beslutat åtgärda genom en lämplig förändring av testobjektet.

En defekt kan hittas med hjälp av statisk testning. En avvikelse kan endast hittas genom dynamisk testning. Varje fas i programvarans livscykel bör innehålla metod(er) för detektering och eliminering av potentiella defekter T.ex. bör man under utvecklingsfasen använda sig av kod- och design-granskningar för att hitta defekter. Vid dynamisk testning använder man testfall för att upptäcka felsymptom. Ju tidigare en defekt hittas och korrigeras, desto lägre blir kvalitetskostnaderna för systemet i sin helhet. Observera att defekter kan finnas såväl i testartefakter som i det testade objektet!

7.3 Defekters Livscykel

Alla defekter har en livscykel, även om vissa defekter inte passerar alla steg. Enligt IEEE 1044-1993 består defektens livscykel av fyra steg.

Steg 1: Identifiering

Steg 2: Analys

Steg 3: Åtgärd

Steg 4: Avslut

Inom varje steg finns det tre aktiviteter som syftar till att vidareutveckla incidentinformationen.

Registrering

Klassificering

Identifiering av påverkan

7.3.1 Steg 1: Identifiering

Identifieringssteget inträffar när en potentiell defekt (eller incident) upptäcks. Detta kan inträffa i alla faser av programvarans livscykel. Den information som identifierar defekten och dess egenskaper skall registreras när defekten upptäcks. Detta inkluderar information om den omgivning i vilken




defekten hittades, vem som hittade defekten, en beskrivning av själva incidenten, tidpunkten för upptäckten och – om tredjepartsprogramvara används – leverantör av den felaktiga programvaran. Den identifierade incidenten klassas genom att beskriva speciella kännetecken hos den potentiella defekten. Detta inkluderar projektaktivitet, projektfas, misstänkt orsak, repeterbarhet, symtom och den produktstatus som avvikelsen orsakar. Med hjälp av denna information kan sedan de potentiella konsekvenserna av incidenten analyseras genom att uppskatta hur allvarlig defekten är och hur projektets tidsplan och kostnader påverkas.

7.3.2 Steg 2: Analys

Efter identifieringen analyseras varje potentiell defekt. Detta steg används i första hand för att hitta relaterade problem och föreslå lösningar, vilket kan innebära att inga åtgärder vidtas (t.ex. om den potentiella defekten inte längre betraktas som en verklig defekt). Kompletterande data registreras och klassificeringen såväl som uppskattningen av påföljderna som gjordes under det tidigare steget omvärderas.

7.3.3 Steg 3: Åtgärd

Med resultatet från analyssteget som bas påbörjas åtgärdssteget. Åtgärderna inkluderar dels sådant som krävs för att rätta defekten dels varje åtgärd som behövs för att förändra/förbättra processer och metoder så att liknande defekter kan undvikas i framtiden. Såväl regressionstestning, omtestning som progressionstestning (testning av ny funktionalitet) måste genomföras efter varje förändring. Komplet-terande information registreras under detta steg - dessutom genomförs återigen en omvärdering av klassificeringen och påföljderna från de tidigare stegen.

7.3.4 Steg 4: Avslut

Slutligen flyttas avvikelsen till avslutssteget där ytterligare information registreras och incident-rapporten klassificeras som antingen stängd, uppskjuten, hopslagen (med annan avvikelse) eller överlämnad till ett annat projekt.

7.4 Incidentrapportens Fält

IEEE 1044-1993 innehåller en mall för incidentrapporterring. I mallen beskrivs ett antal obligatoriska fält som fylls i vid olika skeden av defektens livscykel. Det finns också en stor grupp valfria fält definierade. Enligt IEEE 1044.1 är det tillåtet att - när man implementerar IEEE 1044-1933 - skapa en mappning mellan fälten i IEEEs incidentrapport och de motsvarande begrepp som används i den egna organisationen. Detta innebär att man kan ha överensstämmelse med IEEE 1044-1993 utan att behöva använda exakt samma namnkonvention. En överensstämmelse med IEEE innebär också att man kan jämföra incidentinformation mellan flera företag och organisationer.

Oberoende om en överensstämmelse med IEEE är målet eller inte, måste de fält som man använder vid defektrapportering ge tillräckligt mycket information så att nödvändiga åtgärder kan vidtas för defekten. En användbar felrapport är:

komplett

koncis (kortfattad och exakt)

korrekt

objektiv.

Förutom information nödvändig för att åtgärda den specifika defekten, måste det också finnas information för korrekt klassificering, riskanalys och processförbättringar.




7.5 Mätetal & Incidentrapporthantering

En incidentrapport måste innehålla tillräckligt med information för att stödja uppföljning av test-progressen och analys av defekttäthet, mätetal för hittade resp. korrigerade defekter samt öppna resp. stängda incidentrapporter. Dessutom måste incidentinformationen bidra till processförbättringsinitiativ genom att göra det möjligt att identifiera i vilken fas av produktlivscykeln som misstag begåtts, genomföra analys av grundorsaker (RCA) och att identifiera defekttrender, som kan användas som indata till strategiska justeringar av riskminimeringsaktiviteterna.

7.6 Kommunikation av Incidentinformation

Avvikelsehantering inkluderar en ändamålsenlig kommunikation som dels är fri från anklagelser och som dels stödjer insamling och uttolkning av information på ett objektivt sätt. Det är absolut nödvändigt att incidentrapporter är objektiva, korrekta och riktigt klassificerade för att professionella relationer ska kunna upprätthållas mellan dem som rapporterar defekter och dem som skall korrigera defekterna. Testare kan tillfrågas om prioritering av defekter med avseende på hur viktiga de är och skall i så fall bidra med objektiv information.

Felanalysmöten, t.ex. CCB, kan genomföras för att bidra till en korrekt prioritering. Verktyg för felhantering kan inte ersätta bra kommunikation, inte heller kan felanalysmöten ersätta användandet av ett bra verktyg för felhantering. Både kommunikation och ett lämpligt verktygsstöd är nödvändigt för en effektiv felhantering.




8. Standarder & Testförbättringsprocesser

Begrepp

Capability Maturity Model (CMM), Capability Maturity Model Integration (CMMI), Test Maturity Model (TMM), Test Maturity Model integration (TMMi), Test Process Improvement (TPI)

8.1 Inledning

Stöd för att införa och förbättra testprocesser kan komma från en rad olika källor. Inledningsvis handlar detta kapitel om standarder som är användbara (ibland obligatoriska) informationskällor till en mängd testrelaterade områden. Att veta vilka standarder som finns och när det är lämpligt att applicera dem ingår i kunskapsmålen för både testledare och testare. Kursleverantörer bör belysa de specifika standarder som är särskilt relevanta för den modul som lärs ut.

Så snart en testprocess börjat användas bör den genomgå kontinuerliga förbättringsaktiviteter. Avsnitt 8.3 innehåller först en genomgång av generella förbättringsaktiviteter, följt av en introduktion till några specifika modeller som kan användas för testprocessförbättringar.

I första hand, måste testledare förstå alla delar av materialet i detta kapitel, men det är också viktigt att testanalytiker och tekniska testanalytiker, som viktiga aktörer i förbättringsarbetet, är medvetna om de förbättringsmodeller som finns.

8.2 Överväganden för Standarder

I denna kursplan och i kursplanen för ISTQB® certifierad testare grundnivå ingår vissa standarder. Det finns standarder för ett antal ämnen med anknytning till programvara såsom:

programvaruutvecklingslivscykeln

programvarutestning och metoder

konfigurationshantering

programvaruunderhåll

kvalitetssäkring

projektledning

krav

programmeringsspråk

programvarugränssnitt

felhantering.

Syftet med denna kursplan är inte att lista eller rekommendera specifika standarder. Istället är syftet att göra testarna medvetna om hur standarder skapas och hur de bör användas i en specifik situation.

Standarder kan ha olika ursprung och fokus:

Internationella eller med internationella mål

Nationella, t.ex. nationella tillämpningar av internationella normer

Branschspecifika, t.ex. när internationella eller nationella standarder anpassas eller utvecklas för specifika branscher

Vissa överväganden bör göras vid användning av standarder. Dessa beskrivs närmare i följande avsnitt.




8.2.1 Generellt om Standarder

8.2.1.1 Källor till Standarder

Standarder skapas av grupper av yrkeskunniga specialister och återspeglar deras kollektiva kunskaper och erfarenheter. ISO och IEEE är de två huvudsakliga standardiseringsorganen för internationella standarder. Ofta finns det dessutom viktiga nations- och branschspecifika standarder.

Testare bör känna till de standarder som gäller för deras bransch och sammanhang, vare sig det gäller formella standarder (internationella, nationella eller branschspecifika) eller egna standarder och rekommendationer. Eftersom även standarder utvecklas och förändras är det nödvändigt att ange vilken version (publiceringsdatum) av standarden som använts för att säkerställa spårbarhet mot rätt version. När en standard hänvisas till utan specificerat datum eller version, anses det vara den senaste versionen som refereras.

8.2.1.2 Nyttan med Standarder

Standarder kan användas som ett instrument för att främja konstruktiv kvalitetssäkring. Denna typ av kvalitetssäkring fokuserar på att minimera riskerna för att defekter införs istället för att upptäcka dem genom testning, vilket kallas analytisk kvalitetssäkring. Alla standarder är inte applicerbara i alla projekt. Information och krav som anges i en standard kan vara till nytta för eller skapa problem för ett projekt beroende på situationen. Att följa en standard för standardens egen skull kommer inte att hjälpa testarna hitta fler defekter i en produkt under utveckling [Kaner02]. Däremot kan standarder ge referensramar, och en grund på vilken man kan bygga specifika testlösningar.

8.2.1.3 Överensstämmelser & Konflikter

Alla standarder är inte kompatibla med varandra. I vissa fall saknas överensstämmelse mellan två standarder och ibland är informationen till och med motstridig. Det är upp till användaren av standarden att avgöra nyttan av olika standarder utifrån den tänkta användningen, dess omgivning och sammanhang.

8.2.2 Internationella Standarder

8.2.2.1 ISO

ISO [www.iso.org] står för International Standards Organization (nyligen ändrat till International Organization for Standardization) och består av representanter från de nationella organ, i respektive land, som är mest lämpliga ifråga om standardisering. Detta internationella organ har skapat och tillhandahåller ett antal standarder, användbara för programvarutestare, till exempel

ISO 9126:1998, som numera är uppdelad i följande standarder och tekniska rapporter (TR): o ISO/IEC 9126-1:2001 Software engineering – Product quality – Part 1: Quality model o ISO/IEC TR 9126-2:2003 Software engineering – Product quality – Part 2: External

metrics o ISO/IEC TR 9126-3:2003 Software engineering – Product quality – Part 3: Internal

metrics o ISO/IEC TR 9126-4:2004 Software engineering – Product quality – Part 4: Quality in

use metrics

ISO 12207:1995/Amd 2:2004 Systems and Software Engineering – Software Lifecycle Processes

ISO/IEC 155041-2:2003 Information technology – Process assessment – Part 2: Performing an assessment

Denna förteckning är inte uttömmande; andra ISO-standarder kan vara tillämpliga beroende på sammanhang och miljö.

1 ISO 15504 är också känd som SPICE, och har sitt ursprung i SPICE projektet




8.2.2.2 IEEE

IEEE [www.ieee.org] stod ursprungligen för Institute of Electrical and Electronics Engineers men omfattar nu så många områden även utanför el och elektronik att man nu enbart använder IEEE, vilket ska uttalas ”eye-triple-E”. IEEE är en vinstdrivande USA-baserad organisation. Nationella representanter finns i mer än hundra länder. Även denna organisation erbjuder ett antal standarder som är användbara för programvarutestare, såsom:

IEEE 610:1991 IEEE standard computer dictionary. A compilation of IEEE standard computer glossaries

IEEE 829:1998 IEEE standard for software test documentation

IEEE 1028:1997 IEEE standard for software reviews

IEEE 1044:1995 IEEE guide to classification for software anomalies

Inte heller denna förteckning är uttömmande; andra IEEE-standarder kan vara tillämpliga beroende på sammanhang och miljö.

8.2.3 Nationella Standarder

Många länder har sina egna specifika standarder. Vissa av dessa standarder gäller och/eller är användbara för programvarutestning. En sådan är Brittisk standard BS-7925-2:1998 “Software component testing” som innehåller information om flera av de testtekniker som beskrivs i denna kursplan, däribland:

ekvivalensklassindelning

gränsvärdesanalys

tillståndsbaserad testning

testning av orsak-verkangrafer

kodsatstestning

bågtestning/beslutstestning

villkorstestning

slumpbaserade tester

BS-7925-2 innehåller även en beskrivning av en komponenttestprocess.

8.2.4 Branschspecifika Standarder

Standarder finns också för olika branscher. Ibland är dessa framtagna specifikt för den aktuella branschen och ibland är det en anpassning av en befintlig, generell standard. Även här finns aspekter av intresse för programvarutestning, programvarukvalitet och programvaruutveckling.

8.2.4.1 Flygindustri

RTCA DO-178B/ED 12B “Software Considerations in Airborne Systems and Equipment Certification” är en standard som är tillämplig på programvara som används i civil luftfart. Denna standard gäller även för programvara som används för att skapa (eller verifiera) sådan programvara. För programvara utvecklad för flygindustrin, föreskriver Federal Aviation Administration (FAA) och det internationella Joint Aviation Authorities (JAA) användningen av vissa strukturella täckningsmått. Val av täcknings-mått baseras på en säkerhetsklassificering som är uppbyggd på hur kritiska funktionerna är i programvaran som testas:

Criticality Level

Potential Impact of Failure Required Structural Coverage

A Catastrophic Prevent continued safe flight and landing

Condition determination, Decision, and Statement

B Hazardous/ Severe-Major

Large reduction in safety margins or functional capabilities

Crew can not be relied upon to perform their tasks accurately or completely

Serious or fatal injuries to a small number of occupants

Decision and Statement




Criticality Level

Potential Impact of Failure Required Structural Coverage

C Major Significant reduction in safety margins

Significant increase in crew workload

Discomfort to occupants possibly including injuries

Statement

D Minor Slight reduction of aircraft safety margins of functional capabilities

Slight increase in crew workload

Some inconvenience to occupants

None

E No effect No impact on the capabilities of the aircraft

No increase in crew workload None

Tabellen ovan är tagen från RTCA DO-178B/ED 12B och beskriver nivåerna av strukturell täckning som skall uppnås beroende på nivån på säkerhetskritikaliteten hos programvaran som ska certifieras för användning inom civil luftfart.

8.2.4.2 Rymdindustri

Vissa branscher applicerar och skräddarsyr generella standarder för sina specifika domäner. Detta är fallet för rymdindustrin via ECSS (European Cooperation on Space Standardization) [www.ecss.org]. Beroende på hur säkerhetskritisk programvaran är, rekommenderar ECSS metoder och tekniker som är förenliga med ISTQB® kursplaner för certifierad testare, grundnivå och avancerad nivå, inklusive:

SFMECA - Software Failure Modes, Effects and Criticality Analysis

SFTA - Software Fault Tree Analysis

HSIA - Hardware Software Interaction Analysis

SCCFA - Software Common Cause Failure Analysis

8.2.4.3 Food & Drug Administration

För medicinska system som omfattas av Title 21 CFR Part 820, rekommenderar den amerikanska Food and Drug Administration (FDA) vissa strukturella och funktionella testtekniker. Även FDA rekommenderar teststrategier och principer som är förenliga med ISTQB® kursplaner för certifierad testare, grundnivå och avancerad nivå.

8.2.5 Andra Standarder

Antalet standarder som finns i olika branscher är mycket stort. Vissa är anpassningar till specifika domäner eller branscher och vissa gäller för särskilda uppgifter eller ger en förklaring till hur man kan använda en standard. Det är upp till testaren att vara medveten om de olika standarder (inbegripet interna standarder, "bästa metoder", etc.) som gäller inom domänen, branschen eller sammanhanget. Ibland ordnas standarder i hierarkiska strukturer med avseende på hur anpassade de är för specifika kontrakt. Det är upp till testledaren att vara medveten om de standarder som måste uppfyllas, och se till att de efterlevs i tillräcklig utsträckning.

8.3 Test Improvement Process

Precis som testning används för att förbättra programvara, utnyttjas kvalitetsprocesser för att förbättra arbetet med att utveckla programvara (och därmed förhoppningsvis kvaliteten på den därigenom utvecklade programvaran). Processförbättring kan också tillämpas på testprocesser. Olika sätt och metoder finns tillgängliga för att förbättra testning av programvara och system som innehåller programvara. Precis som med kvalitetsprocesser i allmänhet syftar testförbättringsmetoder till att öka kvaliteten i testarbetet (och därmed förhoppningsvis kvaliteten hos testleverablerna) genom att ge riktlinjer för arbete och områden för förbättring.

Testning står ofta för en stor del av de totala projektkostnaderna. Trots detta ägnas endast begränsad uppmärksamhet åt testprocessen i flera processförbättringsmodeller, som t.ex. CMMI (se nedan för detaljer).




Testförbättringsmodeller såsom Test Maturity Model (TMM), Systematic Test and Evaluation Process (STEP), Critical Testing Processes (CTP) och Test Process Improvement (TPI) har utvecklats för att täcka detta område. TPI och TMM specificerar tvärorganisatoriska mätetal som kan användas dels för att kartlägga testprocessens prestanda och dels för att användas som riktlinjer för process-förbättringar.

Nu för tiden finns många förbättringsmodeller tillgängliga. Förutom de som omfattas av detta avsnitt bör också Test Organization Maturity (TOM), Test Improvement Model (TIM) och Software Quality Rank (SQR) övervägas. Det finns även ett stort antal regionala modeller. Professionella testare bör undersöka alla tillgängliga modeller för att identifiera vilken som passar bäst för den aktuella situationen.

De modeller som presenterats i detta avsnitt är i första hand avsedda för att ge en representativ bild av hur dessa modeller fungerar och vad som skall ingå i en testförbättringsmodell. Uppräkningen ovan skall inte ses som en rekommendation för användning.

8.3.1 Introduktion till Processförbättringar

Processförbättringar har betydelse för både utvecklingsprocessen och testprocessen. Att lära av sina misstag gör det möjligt att förbättra den process organisationen använder för att utveckla och testa programvara. Demingcykeln: Plan, Do, Check, Act, har använts i flera årtionden och är fortfarande relevant för testare som behöver förbättra sina arbetsprocesser.

En förutsättning för processförbättring är en tro på att ett systems kvalitet i hög grad påverkas av kvaliteten i de processer som används för att utveckla systemets programvara. Ett motiv för kvalitetsförbättring är att högre kvalitet i programvara och metoder minskar behovet av resurser för att underhålla programvaran, vilket därmed ger mer tid för att skapa fler och bättre lösningar i framtiden.

Processmodeller ger en startpunkt för förbättringar genom att organisationens mognad utvärderas med hjälp av modellen. Modellen ger även ett ramverk för att förbättra organisationens processer baserat på utfallet av en utvärdering.

En processutvärdering leder till en processduglighetsbedömning, vilket kan motivera en process-förbättringsaktivitet. I ett senare skede kan en ny processutvärdering genomföras för att mäta effekten av förbättringen.

8.3.2 Inriktning hos Processförbättringsmodeller

Processförbättringsmodeller kan ha två olika typer av inriktningar: process- respektive innehålls-inriktning.

Processinriktning används som ett ramverk för en bedömning, dvs. för att utvärdera en organisations förmåga jämfört med modellen och för att utvärdera organisationen inom detta ramverk.

Innehållsinriktning används för att förbättra processen när utvärderingen väl är klar.

Vissa processförbättringsmodeller har båda dessa inriktningar inbyggda medan andra modeller bara stödjer den ena.

8.4 Förbättra Testprocessen

I strävan att uppnå högre mognadsgrad och professionalism har IT-branschen börjat arbeta med testprocessförbättringsmodeller. Branschspecifika standardmodeller hjälper till att utveckla tvärorganisatoriska åtgärder och mätetal som kan användas som jämförelse. Modeller som bygger på ett antal mognadssteg, såsom TMMi och CMMI gör det möjligt att göra jämförelser mellan olika företag och organisationer. En annan typ av modeller, de kontinuerliga, låter en organisation hantera sina högprioriterade förbättringsåtgärder med större frihet avseende genomförandeordningen.




Framsprunget ur behovet av processförbättringar i testindustrin har ett flertal standarder tagits fram. Några av dessa är STEP, TMMi, TPI och CTP. Dessa gås igenom i detta avsnitt.

De fyra ovan nämnda testprocessförbättringsmodellerna innehåller alla en utvärderingskomponent vilken gör det möjligt att ta fram en bild av var organisationen befinner sig med avseende på nuvarande testprocesser. När en utvärdering gjorts, ger TMMi och TPI en plan för att förbättra testprocessen. STEP och CTP förser istället organisationen med möjligheter att avgöra var den största processförbättringsavkastningen finns och överlämnar till organisationen att välja lämplig färdplan.

Så snart man beslutat att göra en översyn av testprocesserna i syfte att hitta och implementera förbättringsaktiviteter bör åtgärderna som vidtas följa stegen i IMPROVE-modellen:

Initiate

Measure

Prioritize and Plan

Define and Redefine

Operate

Validate

Evolve

Initiate

I detta steg kommer man överens med intressenterna om vilken omfattning, vilka mål och vilka delar av processen som skall ingå i processförbättringsarbetet. Här väljs också den processmodell som skall användas för att identifiera vilka förbättringar som bör utföras. Antingen väljs en befintlig modell eller så definieras en modell specifikt för ändamålet.

Innan processförbättringsaktiviteterna startar bör dels framgångskriterier definieras och dels en metod implementeras med vilken framgångskriterierna kontinuerligt kan mätas under förbättringsarbetet.

Measure

Den överenskomna processmodellen används och resulterar i en lista på möjliga processförbättringar.

Prioritize & Plan

Listan över möjliga processförbättringar sorteras i prioritetsordning. Ordningen kan baseras på avkastning på investeringar, risker, anpassning till organisationens strategi eller mätbara kvantitativa eller kvalitativa fördelar.

När prioritetsordningen är fastställd bör en plan tas fram och lanseras. Denna plan beskriver hur förbättringarna skall införas.

Define & Redefine

Baserat på processförbättringskraven som identifierats, definieras nya processer där det krävs. Där befintliga processer kräver en uppdatering omdefinieras dessa och görs redo för lansering.

Operate

När processförändringarna utvecklats, introduceras de. Detta kan innefatta nödvändig utbildning eller handledning och att testa processerna i pilotprojekt för att sedan övergå till en fullskalig tillämpning av dem.

Validate

När processförbättringarna implementerats fullständigt ska den på förhand överenskomna nyttan värderas. Detta är nyckeln till att driva ett framgångsrikt processförbättringsprojekt. I detta samman-hang är det viktigt att alla framgångskriterier för processförbättringsverksamheten har uppfyllts.




Evolve

Beroende på den modell som används, är detta det skede av processen där övervakning av nästa mognadsnivå startar och ett beslut tas att antingen starta förbättringsprocessen igen eller att avsluta den. Användningen av bedömningsmodeller är en vanlig metod som garanterar ett standardiserat tillvägagångssätt för att förbättra testprocesser med hjälp av beprövade och pålitliga metoder. Testprocessförbättring kan dock också ske utan modeller med hjälp av till exempel analytiska metoder och tillbakablicksmöten.

8.5 Förbättra Testprocessen med TMM

Testing Maturity Model är tänkt som ett komplement till CMM och består liksom CMM av fem nivåer. Var och en av nivåerna innehåller definierade processområden som måste vara helt uppfyllda innan organisationen kan gå vidare till nästa nivå. Modeller som bygger på definierade mognadssteg kallas stegrepresentationsmodeller. TMM tillhandahåller både en processreferensmodell och en innehålls-referensmodell.

TMM nivåerna är:

Nivå 1: Initial

Den första nivån representerar ett tillstånd där det inte finns någon formellt dokumenterad eller strukturerad testprocess. Testfall utvecklas vanligtvis utan eftertanke efter det att programvara redan är färdig. Vidare ses ingen skillnad mellan testning och avlusning. Testningen tros vara en metod för att bevisa att programvaran fungerar.

Nivå 2: Definition

Den andra nivån uppnås genom att sätta upp testpolicy och testmål samt införa en testplaneringsprocess med grundläggande testtekniker och metoder.

Nivå 3: Integration

Den tredje nivån är uppnådd när det finns en testprocess integrerad i programvarans utvecklingslivscykel och testprocessen är dokumenterad i formella standarder, rutiner och metoder. Det ska även finnas en tydlig testverksamhet som kan övervakas och styras.

Nivå 4: Ledning & Mätning

Nivå fyra uppnås när testprocessen på ett effektivt sätt kan mätas, förvaltas och anpassas till specifika projekt.

Nivå 5: Optimering

Den slutliga nivån beskriver ett tillstånd av testprocessmognad, i vilket information från testningen kan användas för att förhindra att defekter införs och där fokus ligger på att optimera den befintliga testprocessen.

För att uppnå en viss TMM nivå måste ett antal fördefinierade mognadsmål och delmål uppnås. Dessa mål som definieras i termer av aktiviteter, uppgifter och ansvar, bedöms enligt specificerade "perspektiv" för chef, utvecklare/testare och kund/användare. För mer information om TMM, se [Burnstein03].

TMMi Foundation [se www.tmmifoundation.org för en detaljerad beskrivning] har tagit fram efterföljaren till TMM: TMMi. TMMi är en detaljerad modell för testprocessförbättring som baseras på TMM. Den är utvecklad av Illinois Institute of Technology och baseras på praktiska erfarenheter av att använda TMM. TMMi betraktas som ett komplement till CMMI. Strukturen i TMMi bygger till stor del på CMMIs struktur (t.ex. processområden, allmänna mål, allmänna rutiner, specifika mål och specifika metoder).




8.6 Förbättra Testprocessen med TPI

TPI (Test Process Improvement) använder en kontinuerlig representation snarare än stegrepresent-ationen som TMM använder.

Den testprocessoptimeringsplan som beskrivs i [Koomen99] innefattar en rad nyckelområden som är indelade i de fyra hörnstenarna livscykel, organisation, infrastruktur och verktyg samt tekniker. För varje nyckelområde kan mognadsnivån bedömas på en två till fyrgradig skala (A-D), där A är låg. Det är även möjligt att mycket omogna organisationer för vissa nyckelområden inte uppnår den grundläggande nivån A. Antalet grader i skalan varierar för olika nyckelområden. T.ex. har området ”uppskattning och planering” endast två nivåer (A resp. B) medan t.ex. området ”mätetal har alla fyra.

Mognadsnivån för en organisation inom ett visst nyckelområde bedöms genom utvärdering av ett antal kontrollfrågor, vilka anges i TPI-modellen. Om till exempel alla kontrollfrågor för nyckelområdet "rapportering" besvarats positivt på nivå A och B, då är därmed nivå B uppnådd för detta nyckel-område.

TPI-modellen definierar beroenden även mellan nyckelområdenas olika nivåer. Dessa beroenden säkerställer att testprocessen utvecklas jämnt. Det är inte möjligt, att exempelvis uppnå nivå A i nyckelområdet "mätetal" utan att också uppnå nivå A i nyckelområdet "rapportering" (det vill säga, det finns ingen mening att använda mätetal om de inte redovisas). Användningen av beroenden är valfri i TPI-modellen.

TPI är främst en processreferensmodell.

TPI innehåller en testmognadsmatris vilken kopplar nivåerna (A, B, C eller D) för de olika nyckel-områdena mot en övergripande testmognadsnivå. De övergripande testmognadsnivåerna är:

kontrollerad

effektiv

optimerande.

Under en TPI utvärdering, används kvantitativa mätetal och kvalitativa intervjuer för att fastställa testprocessens mognadsnivå.

8.7 Förbättra Testprocessen med CTP

Som beskrivs i [Black02], är den grundläggande teorin för bedömningsmodellen Critical Testing Process att vissa testprocesser är kritiska. Dessa kritiska processer kommer, om de används på ett korrekt sätt, att främja testteamets framgång. Omvänt, om processens aktiviteter genomförs dåligt, kommer även erfarna testare och testledare sannolikt inte lyckas särskilt väl. Modellen identifierar tolv kritiska testprocesser.

CTP är främst en innehållsreferensmodell.

CTP modellen är kontextkänslig, vilket gör det möjligt att anpassa den efter bland annat:

identifiering av specifika utmaningar

igenkänning av attribut hos bra processer

prioritering av processförbättringar.

CTP modellen är anpassningsbar inom ramen för alla utvecklingslivscykelmodeller för programvara.

CTP börjar med en utvärdering av den nuvarande testprocessen. Bedömningen identifierar starka respektive svaga områden och ger prioriterade rekommendationer till förbättringar baserade på organisatoriska behov. Även om bedömningar som utförs varierar beroende på de specifika samman-hang där de utförs, undersöks vanligen följande kvantitativa mätetal under en CTP bedömning:

andel upptäckta defekter

avkastning på testinvesteringar

kravtäckningsgrad och risktäckningsgrad




overhead för testreleasearbetet

andel felrapporter som avskrivits (rejected).

Följande kvalitativa faktorer utvärderas vanligen under en CTP bedömning:

testteamets roll och effektivitet

testplanens nytta

testteamets kunskaper i testning, inom domänen och inom teknikområdet

felrapportnyttan

nyttan av testresultatrapporten

nyttan med ändringshanteringen.

När bedömningen har identifierat svaga områden, upprättas planer för att få förbättringar på plats.

Generiska förbättringsplaner tillhandahålls av modellen för var och en av de tolv kritiska test-processerna, men under anpassningen förväntas bedömningsgruppen göra stora förändringar i dem.

8.8 Förbättra Testprocessen med STEP

I likhet med CTP och till skillnad från TMMi och TPI, kräver inte STEP (Systematic Test and Evaluation Process) att förbättringar sker i en viss ordning.

Grundförutsättningar för metoden innefattar:

en kravbaserad testningsstrategi

att testning startar i början av livscykeln

att tester används som krav och användningsmodeller

att designen av testartefakter leder programvarudesignen

att defekter upptäcks tidigare eller förhindras helt och hållet

att defekter analyseras systematiskt

att testare och utvecklare arbetar tillsammans.

STEP är främst en innehållsreferensmodell.

STEP-metoden bygger på idén att testning är en livscykelinriktad aktivitet som inleds under krav-formuleringen och fortsätter fram till dess systemet avvecklas. STEP-metoden betonar "testa först koda sen" med hjälp av en kravbaserad teststrategi, som innebär att tidigt skapade testfall validerar kravspecifikation innan design och kodning inleds. Metoden identifierar och fokuserar på förbättring av tre viktiga testfaser:

planering

insamling

mätning

Under en STEP utvärdering, används både kvantitativa mätetal och kvalitativa intervjuer. Kvantitativa mätetal inkluderar:

teststatus över tiden

kravtäckningsgrad och risktäckningsgrad

defekttrender avseende upptäckt, allvarlighet och klustring

defekttäthet

felrättningseffektivitet

andel upptäckta defekter

i vilka faser som defekter introducerats, upptäckts och rättats

kostnader för testning i form av tid, arbete och pengar.

Kvantitativa faktorer inkluderar:

utnyttjandegraden av den definierade testprocessen

kundnöjdhet

I vissa fall används bedömningsmodellen från STEP med mognadsmodellen från TPI.




8.9 Capability Maturity Model Integration, CMMI CMMI

CMMI kan genomföras via två metoder eller representationer: stegrepresentation eller den kontinuerliga representationen. I stegrepresentationen finns det fem "mognadsnivåer", där varje nivå bygger på de processområden som fastställdes i de tidigare nivåerna. I den kontinuerliga represent-ationen har organisationen möjlighet att koncentrera sitt förbättringsarbete på de egna primära områdena utan att behöva ta hänsyn till tidigare nivåer.

Stegrepresentationen är i första hand inkluderad i CMMI för att säkerställa enhetlighet med CMM, medan den kontinuerliga representationen allmänt anses mer flexibel.

Inom CMMI hänvisar processområdena validering och verifiering till både statiska och dynamiska test-processer.




9. Testverktyg & Automatisering

Begrepp

Avlusningsverktyg (debugverktyg) , verktyg för dynamisk analys, emulator, verktyg för felinjicering, hyperlänktestverktyg, nyckelordsdriven testning, simulator, testexekveringsverktyg, testlednings-verktyg, testorakel, verktyg för prestandatestning, verktyg för statisk analys

9.1 Inledning

Detta kapitel fördjupar innehållet i kursplanen för ISTQB®/SSTB: svensk kursplan certifierad testare, grundnivå; version 2007, genom att först ta upp en del grundkoncept och sedan diskutera några specifika verktyg i mer detalj.

Även om vissa koncept som tas upp i detta kapitel är mest relevanta för en specifik roll (testledare, testanalytiker eller teknisk testanalytiker) så är det nödvändigt med en grundförståelse av koncepten oavsett roll. Grundförståelsen kan sedan utökas där det är lämpligt.

Verktyg kan grupperas på ett antal olika sätt, t.ex. efter typ av användare, såsom testledare, testanalytiker och teknisk testanalytiker. Denna särskilda gruppering, vilken avspeglar de olika modulerna i denna kursplan, används hädanefter i de följande avsnitten i detta kapitel. Generellt är verktygen som beskrivs i dessa avsnitt i huvudsak relevanta för en av modulerna, även om en del verktyg (t.ex. testledningsverktyg) också kan vara användbara för de andra modulerna. Där så är fallet, kommer kursleverantören att ge exempel på verktygstillämpning för specifika sammanhang.


Verktyg kan starkt förbättra effektiviteten och noggrannheten i testarbetet, men bara om rätt verktyg införs i verksamheten på rätt sätt. Testverktyg måste hanteras precis som allt annat inom en välskött testorganisation. När man pratar om testautomatisering tänker man ofta på testexekvering, men de flesta manuella aktiviteter innehåller något mått av automatiseringsmöjligheter, vilket betyder att de flesta testaktiviteter kan automatiseras i någon utsträckning om bara rätt verktyg finns att tillgå.

Precis som alla andra testartefakter så bör alla testverktyg (inklusive versioner) alla testskript och all dokumentation från testsessioner konfigurationshanteras och knytas till den specifika programvaru-version som de har använts ihop med. Testverktyg är en viktig del av testvaran och bör hanteras därefter, såsom att:

skapa en arkitektur för testverktyget innan det tas fram

fastställa lämplig konfigurationshantering, inklusive versionsinformation, av skript, verktyg, patchar etc.

skapa och underhålla bibliotek (återanvändning av gemensamma delar hos testfall)

dokumentera testverktygsimplementationen (t.ex. en process för hur ett verktyg används och hanteras inom organisationen)

planera för framtiden genom att strukturera testfallen för framtida utveckling, t.ex. göra dem expanderbara och underhållbara.

9.2.1 Kostnadsfördelar och Risker med Testverktyg och Automatisering

En förutsättning för ett lyckat införande av ett verktyg är att man genomfört en kostnadsanalys som visar att investeringen lönar sig. Kostnadsanalysen skall jämföra de faktiska kostnaderna för arbetet om det utförts manuellt respektive med hjälp av verktyget och bör omfatta nedanstående poster. Alla poster ska översättas till någon form av mätbara kostnader (timmar, pengar etc.).




Kostnadsdelar:

initiala kostnader o kunskapsinhämtning (inlärningskurva för verktyget) o utvärdering (verktygsjämförelser) vid behov o integration med andra verktyg o initiala kostnader för inköp, anpassning eller utveckling av verktyget

löpande kostnader o kostnader för att äga verktyg (underhåll, licensavgifter, supportavgifter, upprätthålla

kunskapsnivåer) o portabilitet o tillgänglighet och tillbehör (om något saknas) o kontinuerliga kostnadsutvärderingar o kvalitetsförbättringar för att optimera användningen av verktyget.

Business-case som bara baseras på pilotprojekt för automatiseringen missar ofta viktiga kostnader, såsom kostnader för underhåll, uppdatering och utökning av testskripten när systemet förändras. Livslängden för ett testfall är den tid testfallet fungerar utan omarbetning. Tiden som krävs för att implementera ett testskript är oftast mycket längre än den tid som går åt för att utföra motsvarande testfall manuellt. Men automatisering gör det totalt sett billigare om samma testfall ska exekveras många gånger. Dessutom kommer automatisering att innebära möjligheter att skapa många fler liknande testskript mycket snabbare och därigenom underlätta utökandet av bra testfall över tiden. Förutom detta kommer avsevärda förbättringar av testtäckningen och testeffektiviteten att uppnås för den fortsatta testautomatiseringen efter implementeringsperioden. Business-case för verktygs-implementationer måste därför vara baserade på ett långsiktigt tänkande.

Vid ett visst läge, måste det för varje testfall övervägas om det är värt att automatisera. Många automatiseringsprojekt baseras på implementering av lättillgängliga manuella testfall utan att granska den faktiska nyttan med en automatisering av varje enskilt testfall. Det är troligt att varje given grupp av testfall (en svit) består av manuella, delvis automatiserade och helautomatiserade tester.

Förutom de aspekter som togs upp i kursplanen för ISTQB®/SSTB: svensk kursplan certifierad testare, grundnivå; version 2007, bör följande beaktas:

ytterligare fördelar: o testexekveringstiden för automatiserade tester kan lättare förutsägas o regressionstestning och omtestning av felrättningar går fortare och säkrare sent i

projektet när testfallen är automatiserade o användning av automatiserade testverktyg kan höja statusen och den tekniska nivån

hos testaren eller testteamet o automatisering kan användas i parallell, iterativ och inkrementell utveckling för att ge

bättre regressionstestning av varje programvarubygge o täckning av vissa typer av tester som inte kan genomföras manuellt (t.ex. prestanda

och tillförlitlighet)

ytterligare risker: o otillräcklig eller icke korrekt manuell testning automatiseras såsom den är, utan

eftertanke o testvaran kan bli svår att underhålla, dvs. kräva många ändringar när programvaran

som ska testas förändras o antalet defekter som upptäcks kan minska när testarna inte längre är direkt

inblandade i själva exekveringen av testfallen, eftersom bara de automatiserade, skriptade testerna genomförs

9.2.2 Strategier för Testverktyg

Testverktyg är oftast avsedda att användas i fler än ett specifikt projekt. Beroende på investeringens omfattning och projektets livslängd kan en tillfredställande kostnadsbesparing kanske inte uppnås inom det aktuella projektet, vilket däremot skulle kunna uppnås för efterföljande versioner av




programvaran. T.ex. eftersom underhållsfasen oftast är testintensiv (för varje rättning av program-varan måste en stor regressionstestsvit exekveras), kan det ibland vara kostnadseffektivt att automatisera testerna av ett system som befinner sig i underhållsfasen om systemets livslängd kan göra det ekonomiskt. Ett annat exempel är att det är lätt för människor att begå misstag när man utför testning manuellt (såsom skrivfel), därför är det kostnadseffektivt att automatisera inmatning av data och jämförelser av resultat mot ett orakel (dvs. jämförelse av testresultat mot förväntat resultat).

För företag som använder och är beroende av många testverktyg (för olika faser och ändamål) rekommenderas en långsiktig testverktygsstrategi som beslutsstöd för in- och utfasning av olika verktygsversioner och verktygsstöd. För större, verktygsintensiva företag kan det vara klokt att tillhandahålla generella riktlinjer för inköp av verktyg, strategier, anpassningar och vilket skriptspråk som ska användas.

9.2.3 Integration & Informationsutbyte mellan Verktyg

Oftast används fler än ett testverktyg inom test- (och utvecklings-) processen. T.ex. kan ett företag använda ett verktyg för statisk analys, ett testlednings- och rapporteringsverktyg, ett konfigurations-hanteringsverktyg, ett avvikelsehanteringsverktyg och ett testexekveringsverktyg, alla samtidigt. Det är viktigt att säkerställa att verktygen kan integreras och utbyta information med varandra på ett fördelaktigt sätt. T.ex. skulle det vara att föredra att all testexekveringsstatus rapporterades direkt till testledningssystemet för att tillhandahålla omedelbar uppdatering av testningens framsteg och direkt spårbarhet mellan kraven och testfall. Att lagra testskript både i en testledningsdatabas och i konfigurationshanteringssystemet är mer arbetskrävande och mer felbenäget. Om en testare vill skapa en avvikelserapport mitt under exekveringen av ett testfall måste defektspårnings- och testledningssystemen vara integrerade. Eftersom verktyg för statisk analys kan vara separerade från de andra verktygen skulle det vara mycket mer praktiskt om verktyget kunde rapportera avvikelser, varningar och återmatningar direkt till testledningssystemet.

Att köpa en hel svit testverktyg från samma leverantör betyder inte automatiskt att verktygen arbetar ihop på det sätt som beskrivs ovan, men det är ett rimligt krav. Förutsatt att organisationen har tid för det arbete som en automatisering skulle medföra borde alla dessa aspekter värderas mot kostnaden för att automatisera informationsutbytet och jämföras med risken att förvanska eller helt förlora information med en helt manuell hantering.

Nya koncept såsom integrerade utvecklingsmiljöer, t.ex. Eclipse, är till för att underlätta integrationen och användandet av olika verktyg i samma miljö genom att tillhandahålla ett gemensamt gränssnitt för utvecklings- och testverktyg. En verktygsleverantör kan bli Eclipse-kompatibel genom att skapa en plug-in till Eclipse ramverk, vilket gör att det nya verktyget får samma utseende och känsla som andra verktyg som också bygger på Eclipse. Detta skapar en stor fördel för användaren. Men observera att verktyg inte per automatik kan integreras och utbyta information med varandra, bara för att användar-gränssnitten är likartade.

9.2.4 Automatiseringsspråk: Skript, Skriptspråk

Skript och skriptspråk används ibland för att implementera och utöka testvillkor och testfall. T.ex. vid testning av en webbapplikation kan ett skript användas för att kringgå användargränssnittet för att testa själva API:t (Application Programming Interface) på ett bättre sätt. Ett annat exempel är fallet när testningen av ett användargränssnitt har automatiserats för att kunna testa alla möjliga kombinationer av indata, vilket skulle vara omöjligt med manuell testning.

Skriptspråk kan variera stort i komplexitet och i vilket stöd de erbjuder användarna. Observera att skriptspråken har en spännvidd från normala programmeringsspråk till väldigt specifika standarder, t.ex. signaleringsprotokoll som TTCN-3.




9.2.5 Konceptet Testorakel

Testorakel används generellt för att per automatik generera förväntat resultat. Som sådana utför de samma funktion som programvaran som testas och är därför mycket sällan tillgängliga. Men, i situationer där ett gammalt system ska ersättas av ett nytt system med bibehållen funktionalitet så kan det gamla systemet fungera som ett orakel. Orakel kan också användas när man ska testa system med mycket hög prestanda – så hög prestanda att testmiljön inte hänger med. Då kan ett lågprestandaorakel byggas eller användas för att generera förväntat resultat, som sedan används i den funktionella testningen av programvaran som ska levereras.

9.2.6 Driftsättning av Testverktyg

Varje automatiserat verktyg är i sig en programvara och kan ha beroenden både till hårdvara och till annan programvara. Alla verktyg bör vara dokumenterade och testade var för sig, oberoende av om de är inköpta i befintligt skick eller om de är anpassade eller skapade inom den egna organisationen. En del verktyg är mer integrerade med den befintliga utvecklings- eller testmiljön, andra fungerar bättre som självständiga verktyg.

När systemet som testas körs på egenägd hårdvara, eget operativ system, inbyggd programvara eller använder icke standardiserade konfigurationer, kan det vara nödvändigt att skapa (nyutveckla) eller specialanpassa ett verktyg så att det passar för den specifika miljön. Det är alltid klokt att göra en kostnadsanalys som inkluderar så väl de initiala kostnaderna som de långsiktiga underhålls-kostnaderna.

Vid införande av ett automatiseringsverktyg är det inte alltid klokt att automatisera de manuella testfallen såsom de är, utan man bör omdefiniera testfallen så att de bättre passar för automatisering. Detta kan innebära formatering av testfall, återanvändning av delar av testfall, användning av variabler i stället för hårdkodade värden samt utnyttjande av verktygets fördelar. T.ex. har de flesta testverktyg möjlighet att hoppa mellan testfall, upprepa och förändra exekveringsordningen, allt med goda analys- och rapporteringsmöjligheter. För många testautomatiseringsverktyg är programmeringsfärdigheter nödvändiga för att kunna skapa effektiva testprogram (skript) och testsviter. Om en testsvit inte är omsorgsfullt konstruerad är risken stor att den blir mycket svår att hantera och uppdatera. För att säkerställa att alla fördelar med ett verktyg kan utnyttjas, kan det vara värdefullt med lämpliga utbildningar t.ex. i hur testverktyget fungerar, i programmering och i designtekniker.

Även när manuella testfall har automatiserats är det viktigt att periodvis utföra testerna manuellt för att bibehålla kunskapen om hur testerna fungerar och för att verifiera att de utförs korrekt.

När ett verktyg tas i bruk och antalet testskript ökar, kan det uppstå behov av att lägga till egenskaper som kan tillhandahållas av andra verktyg. Detta är inte alltid möjligt eftersom verktygen inte alltid har öppna gränssnitt och ibland använder sig av egna, icke standardiserade skriptspråk. Det är klokt att använda verktyg som har ”plug-ins” till öppna ramverk eller API:er (Application Programming Interface). Detta är ett sätt att framtidssäkra testskripten.

För varje typ av verktyg, oberoende av vilken fas de ska användas i, bör egenskaperna som listas nedan beaktas. Dessa egenskaper kan användas både för utvärderingar av testverktyg och när ett verktyg ska byggas. Ett verktyg kan vara svagt eller starkt inom vart och ett av dessa områden. Den här typen av lista kan även vara användbar när likartade verktyg ska jämföras.

Egenskaper för:

analys (förståelse av koncept, indata, information tillhandahållen manuellt eller automatiskt)

design (manuell, automatiskt genererad)

urval (manuellt, automatiskt enligt ett urval av kriterier, t.ex. täckningsgrad)

exekvering (manuell, automatisk, exekveringsmekanismer, förmåga att starta om etc.)

utvärdering (t.ex. testorakel)




presentation (refereras ofta till som loggning eller rapporteringsfunktioner vilka kan vara, manuella eller automatiska t.ex. jämförande, formulärstyrda, standardiserade, eller kriteriestyrda).

9.2.7 Användning av Testverktyg med Öppen Källkod

Verktyg som används för test av säkerhetskritiska system måste vara certifierade för att säkerställa att de svarar upp mot motsvarande standarder som gäller för de system som ska testas. Det är inte att rekommendera att använda verktyg med öppen källkod för test av säkerhetskritiska system, såvida de inte är certifierade på lämplig nivå.

Kvaliteten på programvara med öppen källkod är beroende av exponering, historia och nyttjandet av programvaran i fråga och bör inte antas vara mer (eller mindre) korrekt än andra kommersiellt tillgängliga verktyg.

Alla testverktyg bör utvärderas med avseende på deras kvalitet. Med en del verktygstyper är det lätt att vilseledas till ett positivt utvärderingsresultat pga. felaktig verktygsexekvering (t.ex. om verktyget har hoppat över exekveringen av vissa testfall utan att rapportera vad som hoppats över). Även licensavgifter bör noggrant vägas in i utvärderingen. I vissa situationer kan det också finnas förväntningar på att egna modifieringar av koden som görs för att förbättra verktyget ska göras tillgängliga för alla.

9.2.8 Egenutvecklade Testverktyg

Många testverktyg tas fram för att enskilda testare och utvecklare har behov av att snabba upp sitt eget arbete. Andra orsaker till att utveckla egna testverktyg är att det inte finns lämpliga kommersiella verktyg eller att egenutvecklad hårdvara eller testmiljö används. Dessa verktyg är oftast effektiva för just de behov de utvecklats för, men är också oftast beroende av den person som utvecklat verktyget. Dessa verktyg bör dokumenteras så att de kan underhållas av andra än den som skapat verktyget. Det är också viktigt att granska syfte, mål, fördelar och möjliga nackdelar innan verktyget sprids över hela organisationen, eftersom oplanerad spridning och utökning av verktyg i förlängningen kan leda till ineffektivitet.

9.2.9 Klassificering av Testverktyg

Utöver att verktyg klassificeras baserat på vilken aktivitet de stödjer (vilket är konceptet som tillämpas i ISTQB®/SSTB: svensk kursplan certifierad testare, grundnivå; version 2007) finns andra verktygs-klassificeringar, däribland:

testnivå som verktyget används i, t.ex. komponenttest, integrationstest, systemtest, acceptanstest

typ av fel de kan upptäcka

angreppssätt för test eller testteknik (se nedan)

testningens syfte, t.ex. mätning, drivning, loggning, jämförelser

domän, t.ex. trafiksimulering & signalering, nätverk, protokoll, transaktioner, TV-skärmar, expertsystem

testområde, t.ex. datainmatning, miljö, konfiguration eller andra konceptuella områden

grad av anpassning, t.ex. som det är (utan anpassning), som ramverk (för anpassning), som plug-in (såsom Eclipse), som standard- eller certifieringstestsviter eller egenutvecklat

Slutligen, kan verktyg grupperas efter användaren, såsom testledare, testanalytiker respektive teknisk testanalytiker. Den här grupperingen, som motsvarar modulerna i denna kursplan, används i resterande avsnitt i detta kapitel. ISTQB®/SSTB: svensk kursplan certifierad testare, grundnivå; version 2007 innehåller ett avsnitt om testverktyg. Avsnitten nedan innehåller ytterligare aspekter på de verktyg som ingår i grundnivån.





Detta avsnitt har följande mål:

tillhandahålla ytterligare information för de verktygskategorier som presenteras i ISTQB®/SSTB: svensk kursplan certifierad testare, grundnivå; version 2007, kapitel 6, såsom testledningsverktyg, testexekveringsverktyg och verktyg för prestandatestning

presentera nya verktygskategorier

För generell information rörande övriga verktygskategorier som inte tas upp i det här avsnittet se ISTQB®/SSTB: svensk kursplan certifierad testare, grundnivå; version 2007, kapitel 6.

9.3.1 Testledningsverktyg

För generell information rörande testledningsverktyg se ISTQB®/SSTB: svensk kursplan certifierad testare, grundnivå; version 2007, avsnitt 6.1.2.

Testledningsverktyg bör ha möjligheten att spåra följande information:

testartefakter

automatiskt uppsamlad testmiljödata, även för komplicerade miljöer

exekveringsdata från komplicerade exekveringssituationer, inklusive samtidig exekvering av testsviter i olika testmiljöer under samma testsession över flera olika testorganisationer

mätetal såsom: o testvillkor o exekveringstid (t.ex. för ett testfall, en svit, en regressionssvit) och andra viktiga tider

samt bearbetningar av dessa t.ex. genomsnittstider, vilka kan bidra till ledningens beslut

o antal testfall, testartefakter och testmiljöer o antal godkända/underkända tester o antal oavslutade testfall (och anledningen till varför de inte är exekverade) o trender o krav o förhållande och spårbarhet mellan testartefakter

koncept som stöds av testledningsverktyg, såsom: o organisering av testartefakter, lagring och drivning av testfall o testvillkor och testmiljöer o regressionssviter, test sessioner o loggning och avvikelsehanteringsinformation o omstart av testmiljön (och ominitiering) o mätetal för testartefakter (testdokumentation) för att dokumentera testprogressen

Testledningsverktyg används av testledare, testanalytiker och tekniska testanalytiker.

9.3.2 Testexekveringsverktyg

För generell information rörande testexekveringsverktyg se ISTQB®/SSTB: svensk kursplan certifierad testare, grundnivå; version 2007, avsnitt 6.1.5.

Testexekveringsverktyg används mest av testanalytiker och tekniska testanalytiker på alla testnivåer. Verktygen används för att exekvera tester och för att kontrollera deras utfall. Målsättningar med att använda ett testexekveringsverktyg är en eller flera av följande:

minska kostnader (prestation eller tid)

hinna exekvera fler tester än vad som hinns med manuellt

göra tester mer repeterbara.

Oftast används testexekveringsverktyg för att automatisera regressionstester.




Testexekveringsverktyg exekverar instruktioner som är skrivna i ett programmeringsspråk, ofta kallat skriptspråk. Instruktionerna till verktyget är på en väldigt detaljerad nivå som specificerar alla individuella knapptryckningar, tangentslag och musrörelser. Detta gör de detaljerade skripten väldigt känsliga för förändringar av programvaran som testas, i synnerhet för förändringar i det grafiska användargränssnittet.

Utgångspunkten för ett skript kan vara en inspelning (gjort med ett ”capture/replay”-verktyg). Andra möjliga utgångspunkter är mallar, nyckelord, nyskapande eller ändringar av existerande skript. Skript är programvara och fungerar exakt som vilken annan programvara som helst. Vid icke-systematisk testning kan inspelning även användas för att spela in alla händelser så att intressanta situationer kan återskapas. De flesta testexekveringsverktyg innehåller en komparator, vilket gör det möjligt att jämföra det verkliga testresultatet mot ett lagrat förväntat resultat. Tendensen inom testning (precis som inom programmering) är att man går från detaljerade ”låg-nivå” instruktioner till ett mera ”hög-nivå” språk. I båda fallen utnyttjas bibliotek, makron och färdigskrivna programmoduler. I testsammanhang använder man sig ibland av nyckelordsdriven eller aktionsordsdriven skriptning. Detta bygger på att man skapat programmoduler (skriptmoduler) som motsvarar olika användaraktiviteter och märkt dessa med nyckelord som fångar innehållet i respektive aktivitet. Den främsta fördelen med detta är att instruktioner separeras från data. Det är samma koncept som att utnyttja mallar när man skriver skript för att minska användarnas arbetsinsatser.

Huvudorsaker till att användning av testverktyg ibland misslyckas är dåliga programmeringskunskaper och för liten förståelse för att testverktyg bara löser delar av problemen med att automatisera testexekveringen. Det är också så att testskripten i sig kan innehålla defekter. Det är viktigt att poängtera att all automatisering av testexekvering kräver ledning, ansträngning, kunskaper och fokus, bland annat en genomtänkt testarkitektur och en etablerad konfigurationshantering. Användandet av en testarkitektur kan skapa oberoenden från en specifik testverktygsleverantör. När ett verktyg införskaffas finns en tendens att tro att verktygets standard måste följas, t.ex. för hur man strukturerar och namnger skripten. Men en automatisering av testuppsättningen kan skapa en brygga mellan det man själv anser vara bästa sättet att organisera testerna och vad verktyget kräver för att kunna exekvera dem.

9.3.3 Debugging- & Felsökningsverktyg

Verktyg kan användas för felsökning för att successivt krympa området kring ett fel. Det kan också vara nödvändigt att använda felsökningsverktyg i sammanhang där det inte är uppenbart vilket fel som orsakar det synliga felsymptomet. Felsökningsverktyg innehåller spårningsmekanismer och simulerade miljöer vilka används för att interagera med programvaran eller extrahera information från systemet för att successivt krympa området kring felet.

Programmerare återupprepar felen och undersöker programmens tillstånd genom att använda avlusnings- och spårningsverktyg. Dessa gör det möjligt för programmerare att:

exekvera program kodrad för kodrad

stoppa programmet på vilken kodrad som helst i programmet

tilldela och undersöka programvariabler.

Det bör klargöras att avlusning (och avlusningsverktyg) är relaterat till testning, men är inte testning (eller verktyg för testning) i sig. Avlusnings- och spårningsverktyg kan användas i felsökningssyften av testare för att lättare kunna lokalisera från vilket område i koden felet härstammar och, på så vis få hjälp med att avgöra vart felrapporten ska skickas. Avlusnings-, spårnings- och felsökningsverktyg används i huvudsak av tekniska testanalytiker.

9.3.4 Felplanterings- & Felinjiceringsverktyg

Felplantering och felinjicering är två olika tekniker som kan användas inom testning. Felplantering använder ett verktyg liknande en kompilator för att skapa enstaka eller begränsade typer av kodfel på ett systematiskt sätt. Dessa verktyg används också ofta i samband med mutationstestning och kallas ibland för mutationstestverktyg.




Vid felinjicering introduceras felaktiga värden eller andra felaktigheter i något befintligt gränssnitt hos programvaran under test. Ibland (åter)införs även avsiktligt fel. Det primära syftet med felinjicering är att kontrollera att programvaran kan hantera felet (feltolerans). Ett alternativt syfte kan vara att utvärdera att ett testfall i en testsvit upptäcker det avsiktligt införda felet.

Verktyg för felplantering och felinjicering används i huvudsak av tekniska testanalytiker. I vissa fall kan dock även testanalytiker använda dessa verktyg, t.ex. för att manipulera data i en databas eller att införa fel i ett dataflöde för att testa systemets uppförande.

9.3.5 Simulerings- & Emuleringsverktyg

Simulatorer används för att stödja tester där kod eller andra system inte finns tillgängliga, är dyra eller opraktiska att använda (t.ex. testning av programvara som ska klara härdsmältor i kärnkraftverk). En del simulatorer och ”test harness”-verktyg har också stöd för eller kan efterlikna felbeteenden så att även feltillstånd eller felscenarior kan testas. Svagheten hos dessa typer av verktyg är att resursrelaterade fel såsom timingproblem kanske inte upptäcks, vilket kan vara väldigt viktigt för vissa typer av system.

Emulatorer är en specifik typ av simulatorer, som består av programvara skriven för att efterlikna hårdvarans beteende med hög detaljeringsgrad. Fördelen med att använda emulatorer är att mer detaljerad testning möjliggörs. Specifikt innebär detta att spårning och avlusning kan ske på kodradsnivå och att tidsberoenden kan återskapas, vilket kan vara omöjligt i ett verkligt system. Emulatorer är ofta dyra att ta fram, men fördelarna med att kunna analysera systemet när det körs i ”slow-motion” kan vara ovärderliga för en del parallella, tidsberoende och komplexa system.

Beroende på vilken slags emulator som krävs kan både testanalytiker och tekniska testanalytiker använda denna typ av verktyg.

9.3.6 Verktyg för Statisk och Dynamisk Analys

För generell information rörande testverktyg för statisk och dynamisk analys, se ISTQB®/SSTB: svensk kursplan certifierad testare, grundnivå; version 2007, avsnitt 6.1.6 ”Verktygsstöd för prestanda och övervakning”.

9.3.6.1 Verktyg för Statisk Analys

Verktyg för statisk analys kan användas när som helst i programvarans livscykel och inklusive alla nivåer/faser av programvarans utveckling, beroende på vilken typ av mätningar verktyget tillhanda-håller.

Verktyg för statisk analys rapporterar resultat i form av varningar. Varningar som är ogrundade kallas falskt positiva. Sant positiva varningar är riktiga fel som kan leda till felsymptom om de exekveras. Det kan vara svårt och tidsödande att skilja falskt från sant positiva varningar eftersom det kräver noggrann felsökning. Senare varianter av verktyg för statisk analys är bättre på att skilja falskt från sant positiva varningar eftersom de kan dra nytta av information från den dynamiska bindningen under kompileringen. Dessa verktyg används i huvudsak av tekniska testanalytiker.

9.3.6.2 Verktyg för Dynamisk analys

Verktyg för dynamisk analys tillhandahåller exekverings- (run-time) information om den exekverande programvarans tillstånd. Dessa verktyg används oftast för att identifiera oinitialiserade pekare, kontrollera pekares aritmetik, övervaka allokeringen, användning och avallokering av dynamiskt minne för att upptäcka minnesläckor samt belysa andra fel som är svåra att finna med statisk testning. Minnesverktyg bör användas på flera testnivåer vid test av stora komplexa system, eftersom minnesproblem skapas dynamiskt. Observera att olika kommersiella testverktyg kan vara implemen-terade på olika sätt och därför riktar in sig på och rapporterar olika typer av minnes- och resurs- (stack, heap) problem. Slutsatsen är att två olika minnesverktyg kan komma att identifiera olika typer av problem. Minnesverktyg är särskilt användbara för en del programmeringsspråk (C, C++) där




minneshanteringen är lämnad åt programmeraren. Dessa verktyg används i huvudsak av tekniska testanalytiker.

9.3.7 Nyckelordsdriven Testautomatisering

Nyckelord (även kallade “Aktionsord”) används oftast för att representera verksamhetsaktiviteter på hög nivå (t.ex. ”makulera order”). Varje nyckelord knyts till ett antal detaljerade interaktioner med systemet som testas. Sekvenser av nyckelord (relevant testdata inräknat) används för att specificera testfall.[Buwalda01]

Vid testautomatisering är varje nyckelord implementerat som ett eller flera exekverbara testskript. Verktygen läser testfallen som är skrivna med nyckelord och anropar motsvarande testskript som implementerar nyckelorden Skripten är starkt modulära för att möjliggöra en enkel mappning mot specifika nyckelord. Programmeringskunskaper krävs för att implementera dessa modulära skript.

De huvudsakliga fördelarna med nyckelordsdriven testautomatisering är:

Nyckelord kan definieras av domänexperter vilka har djup insikt i en specifik applikations- eller verksamhetsdomän. Nyckelorden kan göra specificeringen av testfall mera effektiv.

När väl nyckelorden blivit implementerade som skript kan personer med hög domänkunskap dra nytta av automatisk testfallsexekvering även om programmeringskunskapen är låg.

Testfall skrivna med nyckelord är lättare att underhålla därför att sannolikheten är låg att de behöver modifieras vid detaljförändringar i programvaran som ska testas.

Testfallsspecifikationerna är oberoende av sina implementationer. Nyckelord kan implementeras av olika skriptspråk och verktyg.

Nyckelordsbaserad testautomatisering används mest av domänexperter och testanalytiker.

9.3.8 Verktyg för Prestandatestning

För generell information rörande verktyg för prestandatestning, se kursplanen för ISTQB®/SSTB: svensk kursplan certifierad testare, grundnivå; version 2007, avsnitt 6.1.6 ”Verktygsstöd för prestanda och övervakning”.

Verktyg för prestandatestning har två huvudegenskaper:

lastgenerering

mätning och analys av systemrespons vid en given last.

Lastgenerering utförs genom att exekvera ett skript som implementerar en fördefinierad driftsprofil (se avsnitt 5.3.3). Skriptet kan initialt vara en inspelning av en ensam användare (t.ex. genom användning av ett ”capture replay”-verktyg) och därefter duplicerat i rätt omfattning för att motsvara den specificerade driftsprofilen. Vanligen görs detta av prestandatestverktyget. I detta sammanhang måste implementationen ta hänsyn till dataförändringar i varje transaktion (eller uppsättning av trans-aktioner).

Prestandaverktygen genererar en last genom att simulera ett stort antal användare av varierad typ (virtuella användare) med specificerade volymer indata. I jämförelse med ”capture replay”-verktygen, återskapar många prestandaskript användarinteraktionen med systemet på kommunikations-protokollsnivå och inte genom att simulera användarinteraktionen via ett grafiskt användargränssnitt. Ett begränsat antal lastgenereringsverktyg genererar last genom att driva applikationen via dess användargränssnitt.

Verktyg för prestandatest genomför ett stort antal mätningar under och efter testexekveringen för att möjliggöra prestandaanalyser. Typiska mätetal och rapporter vid prestandatestning omfattar:

antal simulerade användare

antal och typ av transaktioner som genereras av de simulerade användarna

svarstider på specifika transaktioner som initierats av användarna

rapporter baserade på testloggar och grafer över svarstider som funktion av lasten.




Viktiga faktorer att överväga vid implementering av verktyg för prestandatest innefattar:

hårdvara och nätverksbandbredd som krävs för att generera lasten

verktygets kompatibilitet med de kommunikationsprotokoll som används av systemet som ska testas

verktygets stöd för enkla och flexibla implementationer av olika driftsprofiler

behov av övervaknings-, analys- och rapporteringsegenskaper hos verktyget.

Ofta köps eller hyrs verktyg för prestandatester istället för att utvecklas av den egna organisationen eftersom det vanligen krävs stora insatser för att utveckla dem. Trots det kan det ibland vara skäligt att utveckla ett specifikt prestandaverktyg t.ex. om tekniska begränsningar förhindrar att kommersiella verktyg används eller om lastprofilen eller de egenskaper som verktyget ska tillhandahålla är relativt enkla. Verktyg för prestandatester används oftast av tekniska testanalytiker.

Observera att prestandarelaterade defekter ofta har stor påverkan på programvaran som testas. När prestandakraven är bindande, är det oftast bäst att prestandatesta de kritiska komponenterna så snart det är möjligt (med hjälp av ”drivers” och stubbar), istället för att vänta tills systemtesterna ska genomföras.

9.3.9 Verktyg för Testning av Webbapplikationer

Hyperlänktestverktyg används för att skanna och kontrollera att inga brutna eller saknade hyperlänkar förekommer på en webbplats. En del verktyg tillhandahåller ytterligare information såsom en graf över arkitekturen (en riktad graf över webbplatsen), hastigheten och storleken på nedladdning (per URL), antalet träffar och volymer. Dessa verktyg kan också vara användbara för övervakning av att avtalade servicenivåer (SLA - Service Level Agreements) uppfylls.




10. Yrkeskunnande – Bygga Team

Begrepp

Oberoende testning

10.1 Inledning

Alla professionella testare bör vara medvetna om de individuella färdigheter som krävs för att de skall kunna utföra sina uppgifter väl. Detta avsnitt fokuserar till en början på dessa individuella färdigheter och fortsätter sedan med ett par frågeställningar specifika för testledare, såsom gruppdynamik, organisation, motivation och kommunikation.

10.2 Individuella Färdigheter

En individs förmåga att testa programvara kan uppnås både genom erfarenhet och genom utbildning inom olika arbetsområden. Vart och ett av nedanstående områden kan bidra till testarens kunskaps-bas:

användning av programvarusystem

domän- eller affärskunskaper

aktivt arbete inom olika faser i programvaruutvecklingsprocessen, t.ex. analys, utveckling och teknisk support

aktivt arbete med programvarutestning.

Användare av programvarusystem förstår systemet väl ur användarsynpunkt och känner till hur systemet används i drift, var avvikelser skulle få störst påverkan och hur systemet förväntas uppföra sig. Användare med domänkunskaper vet vilka områden av systemet som är viktigast ur affärs-synpunkt och hur dessa områden påverkar systemets möjlighet att möta affärskraven. Dessa kunskaper kan användas för att prioritera testaktiviteter, skapa realistiska testfall och testdata, samt bidra med eller verifiera användningsfall.

Kännedom om utvecklingsprocessen för programvara (kravanalys, design och kodning) ger förståelse för var misstag kan göras och defekter introduceras, var de kan detekteras och hur man kan förhindra att de införs överhuvudtaget. Erfarenheter från teknisk support ger kunskaper om användarnas erfarenheter, förväntningar och krav på användbarhet. Erfarenheter från programvaruutveckling är viktiga vid utnyttjande av avancerade testautomatiseringsverktyg som kräver programmerings- och designexpertis.

Specifika färdigheter inom programvarutestning inkluderar förmåga att analysera specifikationer, delta i riskanalys, designa testfall och ha uthållighet både när det gäller exekvering av tester och dokumentering av resultat.

För testledare är det speciellt viktigt att ha kunskaper om och erfarenheter av projektledning, eftersom testledning liknar projektledning, t.ex. när det handlar om planering, uppföljning och rapportering till intressenter.

Social kompetens, som att kunna ge och ta kritik, vara drivande och entusiasmerande samt att kunna förhandla, är viktigt för testrollen. Tekniskt skickliga testare kommer troligen att misslyckas i sin roll som testare om de inte besitter och tillämpar nödvändig social kompetens. Dessutom måste de kunna samarbeta med andra. För att nå framgång som testare bör man dessutom vara välorganiserad, ha sinne för detaljer och kunna uttrycka sig väl i tal och skrift.




10.3 Gruppdynamik

En av ledningens viktigaste uppgifter i en organisation är att välja personal. Det är mycket man måste tänka på förutom de specifika individuella kunskaperna som krävs för jobbet. Man måste ta hänsyn till gruppdynamiken när en individ väljs ut för att ingå i ett team. Kommer personen att komplettera de kunskaper och personlighetstyper som redan finns i teamet? Vidare är det viktigt att beakta fördelarna med att ha såväl olika personlighetstyper i testteamet som en blandning av tekniska kunskaper. Ett starkt testteam kan hantera många projekt med varierad komplexitet, samtidigt som man framgångsrikt interagerar med de övriga projektmedlemmarna.

Nya gruppmedlemmar måste snabbt tas upp i teamet samt ges lämplig handledning. Varje person bör tilldelas en bestämd roll inom teamet. Rollfördelningen kan baseras på en genomgång av individernas färdigheter. Målet är att få varje person att lyckas individuellt samtidigt som de bidrar till teamets totala framgång. Detta görs huvudsakligen genom att matcha personlighetstyper med teamroller samt genom att dels bygga vidare på individens personliga egenskaper och dels genom kompetens-utveckling.

Det är viktigt att komma ihåg att den perfekta testaren knappast kommer att finnas tillgänglig. Trots det kan starka team byggas genom att balansera olika individers styrkor och svagheter. Kunskapsutbyte och jobbrotation inom gruppen krävs för att bygga upp och underhålla teamets gemensamma kunskaper och öka flexibiliteten.

10.4 Anpassa Organisationen för Testning

Testning kan ingå i en organisationsstruktur på många olika sätt. Även om alla har ett ansvar för kvaliteten under hela utvecklingscykeln, är ett oberoende testteams bidrag till produktens kvalitet särskilt viktigt. Testningens grad av oberoende varierar i praktiken, vilket framgår av nedanstående rangordning av oberoendet, från minst till störst.

Inga oberoende testare. o I detta fall finns inget oberoende alls utan utvecklaren testar sin egen kod. o Om testning överhuvudtaget hinns med, undersöker utvecklaren själv om koden

fungerar utifrån sin egen tolkning, vilket kan, men inte behöver, motsvara de faktiska kraven.

o Utvecklaren kan snabbt rätta alla upptäckta defekter.

Testning utförs av en annan utvecklare än den som skrivit koden. o Detta ger ett visst mått av oberoende mellan utvecklaren och testaren. o Utvecklare som testar en kollegas kod kan tveka inför att rapportera fel. o Utvecklarens attityd till testning innebär ofta att fokus ligger på positiva testfall.

Testning utförs av en testare (eller en grupp av testare) som är en del av utvecklingsteamet. o Testaren (testarna) rapporterar till projektledningen. o Testarens attityd till testning innebär att fokus ligger mer på att verifiera

kravuppfyllnad. o Eftersom testaren är en del av utvecklingsteamet, kan han eller hon också ha

utvecklingsansvar.

Testarna kommer från andra delar av företaget, användarkollektivet, eller annan icke-utvecklande teknisk organisation.

o Oberoende rapportering till intressenter. o För dessa grupper ligger fokus i första hand på kvalitet. o Kompetensutvecklingen är fokuserad på testning.

Externa testspecialister genomför tester inom specifika områden. o Testområden kan vara användbarhet, informationssäkerhet eller prestanda. o För dessa personer bör fokus ligga på kvaliteten, men det kan bero på hur

rapporteringsstrukturen ser ut.




Testning genomförs av en extern organisation utanför företaget. o Maximalt oberoende uppnås. o Kunskapsöverföringen kan bli otillräcklig. o Det är nödvändigt med klara krav och en väldefinierad kommunikationsstruktur. o Kvalitetsnivån hos den externa organisationen måste kontrolleras regelbundet.

Graden av oberoende mellan utvecklings- och testorganisationer varierar. Det är viktigt att förstå att man måste kompromissa. Högre grad av oberoende innebär mer isolering och mindre kunskaps-överföring. En lägre grad av oberoende kan innebära ökade kunskaper, men kan också medföra motstridiga mål. Graden av oberoende bestäms också av vilken programvaruutvecklingsmodell som används, till exempel är testaren ofta en del av utvecklingsteamet när agila metoder används.

Alternativen i listan ovan kan blandas inom en organisation. Testning kan utföras inom utvecklings-organisationen såväl som av en oberoende testorganisation. En eventuell avslutande certifiering kan därefter utföras av en extern organisation. Det är viktigt att förstå och fastställa ansvar inom och förväntningar på varje testfas så att produktens slutliga kvalitet maximeras inom tids- och budgetramarna.

Outsourcing är ett sätt att använda sig av en extern organisation. Denna organisation kan tillhandahålla testservice i det inköpande företagets lokaler, i sina egna lokaler men i samma land eller i ett helt annat land (kallas ibland off-shore). Outsourcing medför utmaningar, speciellt när företaget ligger utomlands. Frågeställningar som man måste ta hänsyn till är bland andra nedanstående:

kulturella skillnader

övervakning av resurserna

informationsöverföring, kommunikation

skydd av intellektuell egendom

färdigheter, kompetensutveckling och utbildning

personalomsättning

korrekta kostnadsuppskattningar

kvalitet

10.5 Motivation

Det finns många sätt att motivera personer inom testning. Dessa omfattar:

erkännande för genomfört arbete

ledningens uppskattning

respekt inom projektteamet och bland kollegor

tillfredsställande belöning för genomfört arbete (inklusive lön, avancemang och bonus).

Ibland gör projektets förutsättningar att dessa motivationsfaktorer är svåra att använda eller inte fungerar. Till exempel kan en testare jobba hårt i ett projekt med en omöjlig deadline. Testaren kan göra allt vad som står i sin makt för att bibehålla kvalitetsfokus i testteamet, arbeta övertid och anstränga sig extra, men ändå kan det hända att produkten släpps innan den borde på grund av yttre påverkan. Resultatet kan bli att produktens kvalitet är låg trots all ansträngning från testarens sida. Motivationen kan påverkas negativt om inte testarens bidrag förstås eller mäts, oberoende av om slutprodukten är bra eller inte.

Testteamet måste försäkra sig om att lämpliga mätningar genomförs som kan visa att man utfört ett bra arbete vad avser testning, riskminskning och noggrann dokumentering av resultaten. Om inte denna typ av information samlas in och offentliggörs, är det lätt för ett testteam att tappa motivationen då man inte får det erkännande man tycker sig ha förtjänat.

Erkännande utgörs inte enbart av de abstrakta begreppen respekt och uppskattning, utan det ska även synas i termer av möjligheter till avancemang, lönenivå och karriärvägar. Dessa möjligheter kanske inte står till buds om testgruppen inte respekteras.




Erkännande och respekt erhålls när det är tydligt att en testare bidragit till att öka projektets värde. I ett enskilt projekt uppnår man detta snabbast genom att involvera testarna från projektstart och behålla deras engagemang genom hela livscykeln. Med tiden kommer testarna att få uppskattning och respekt genom sina bidrag till projektets positiva utveckling. Dessa bidrag bör dock kvantifieras i monetära termer såsom kostnader för dålig produktkvalitet och kostnader för riskminskning.

10.6 Kommunikation

Kommunikation inom ett testteam sker huvudsakligen på tre nivåer:

dokumentation av testartefakter: teststrategi, testplan, testfall, slutliga testrapporter, incident-rapporter, etc.

feedback på granskade dokument: krav, funktionsspecifikationer, användningsfall, komponenttestdokumentation, etc.

informationsinsamling och informationsspridning: interaktion med utvecklare, andra med-lemmar i testteamet, ledning osv.

För att bygga upp och behålla respekten för testteamet måste all kommunikation vara professionell, objektiv och effektiv. Diplomati och objektivitet krävs när man ger feedback och speciellt när man ger konstruktiva förslag på andras arbetsprodukter.

All kommunikation bör vara fokuserad på att uppnå testmålen samt att förbättra kvaliteten både i produkterna och i processerna som används för att ta fram programvarusystemet. Testare kommunicerar med många olika typer av grupper; användare, projektmedlemmar, ledning, externa testgrupper och kunder. Kommunikationen måste vara ändamålsenlig för målgruppen. Till exempel kan rapportering av defekttrender utformad för utvecklingsteamet vara alldeles för detaljerad för att vara ändamålsenlig för en styrgrupp.




11. Referenser

11.1 Standarder

Detta avsnitt listar de standarder som omnämns i kursplanen

11.1.1 Per Kapitel

Följande kapitel refererar till nedanstående standarder:

Kapitel 2 BS-7925-2, IEEE 829, DO-178B/ED-12B

Kapitel 3 IEEE829, D0-178B/ED-12B

Kapitel 4 BS 7925-2

Kapitel 5 ISO 9126

Kapitel 6 IEEE 1028

Kapitel 7 IEEE 829, IEEE 1044, IEEE 1044.1

11.1.2 Alfabetiskt

Följande standarder refereras i listade kapitel

[BS-7925-2] BS 7925-2 (1998) Software Component Testing Kapitel 2 och 4

[IEEE 829] IEEE Std 829™ (1998) IEEE Standard for Software Test Documentation (en ny version av denna standard existerar, men denna kursplan använder version 1998) Kapitel 2 och 3

[IEEE 1028] IEEE Std 1028™ (1997) IEEE Standard for Software Reviews Kapitel 6

[IEEE 1044] IEEE Std 1044™ (1993) IEEE Standard Classification for Software Anomalies Kapitel 7

[ISO 9126] ISO/IEC 9126-1:2001, Software Engineering – Software Product Quality Kapitel 5

[ISTQB] ISTQB Glossary of terms used in Software Testing, Version 2.0, 2007

[RTCA DO-178B/ED-12B]: Software Considerations in Airborne systems and Equipment certification, RTCA/EUROCAE ED12B.1992 Kapitel 2 och 3




11.2 Böcker

[Beizer95]: Beizer Boris, “Black-box testing”, John Wiley & Sons, 1995, ISBN 0-471-12094-4

[Black02]: Rex Black, “Managing the Testing Process (2nd edition)”, John Wiley & Sons: New York, 2002, ISBN 0-471-22398-0

[Black03]: Rex Black, “Critical Testing Processes”, Addison-Wesley, 2003, ISBN 0-201-74868-1

[Black07]: Rex Black, “Pragmatic Software Testing”, John Wiley and Sons, 2007, ISBN 978-0-470-12790-2

[Burnstein03]: Ilene Burnstein, “Practical Software Testing”, Springer, 2003, ISBN 0-387-95131-8

[Buwalda01]: Hans Buwalda, “Integrated Test Design and Automation” Addison-Wesley Longman, 2001, ISBN 0-201-73725-6

[Copeland03]: Lee Copeland, “A Practitioner's Guide to Software Test Design”, Artech House, 2003, ISBN 1-58053-791-X

[Craig02]: Craig, Rick David; Jaskiel, Stefan P., “Systematic Software Testing”, Artech House, 2002, ISBN 1-580-53508-9

[Gerrard02]: Paul Gerrard, Neil Thompson, “Risk-based e-business testing”, Artech House, 2002, ISBN 1-580-53314-0

[Gilb93]: Gilb Tom, Graham Dorothy, “Software inspection”, Addison-Wesley, 1993, ISBN 0-201-63181-4

[Graham07]: Dorothy Graham, Erik van Veenendaal, Isabel Evans, Rex Black “Foundations of Software Testing”, Thomson Learning, 2007, ISBN 978-1-84480-355-2

[Grochmann94]: M. Grochmann (1994), Test case design using Classification Trees, in: conference proceeedings STAR 1994

[Jorgensen02]: Paul C.Jorgensen, “Software Testing, a Craftsman’s Approach second edition”, CRC press, 2002, ISBN 0-8493-0809-7

[Kaner02]: Cem Kaner, James Bach, Bret Pettichord; “Lessons Learned in Software Testing”; Wiley, 2002, ISBN: 0-471-08112-4

[Koomen99]: Tim Koomen, Martin Pol, “Test Process Improvement”, Addison-Wesley, 1999, ISBN 0-201-59624-5.

[Myers79]: Glenford J.Myers, “The Art of Software Testing”, John Wiley & Sons, 1979, ISBN 0-471-46912-2

[Pol02]: Martin Pol, Ruud Teunissen, Erik van Veenendaal, “Software Testing: A Guide to the Tmap Approach”, Addison-Wesley, 2002, ISBN 0-201-74571-2

[Splaine01]: Steven Splaine, Stefan P.,Jaskiel, “The Web-Testing Handbook”, STQE Publishing, 2001, ISBN 0-970-43630-0

[Stamatis95]: D.H. Stamatis, “Failure Mode and Effect Analysis”, ASQC Quality Press, 1995, ISBN 0-873-89300

[vanVeenendaal02]: van Veenendaal Erik, “The Testing Practitioner”, UTN Publsihing, 2002, ISBN 90-72194-65-9

[Whittaker03]: James Whittaker, “How to Break Software”, Addison-Wesley, 2003, ISBN 0-201-79619-8

[Whittaker04]: James Whittaker and Herbert Thompson, “How to Break Software Security”, Peason/ Addison-Wesley, 2004, ISBN 0-321-19433-0




11.3 Andra Referenser

Följande referenser pekar på information som kan hittas på Internet.

Även om dessa referenser kontrollerades när denna kursplan publicerades på engelska, ansvarar inte ISTQB för att dessa referenser fortfarande är tillgängliga.

Kapitel 5 - www.testingstandards.co.uk

Kapitel 6 - Buggtaxonomi: www.testingeducation.org/a/bsct2.pdf - Otto Vinters buggtaxonomi baserat på Boris Beizers arbete: ottovinter.dk/bugtaxst.doc - Bra översikt over olika taxonomier: testingeducation.org/a/bugtax.pdf - Heuristic Risk-Based Testing intervju med James Bach på What IsTesting.com: www.whatistesting.com/interviews/jbach.htm - Exploratory Testing Explained: www.satisfice.com/articles/et-article.pdf - Exploring Exploratory Testing, Andy Tinkham and Cem Kaner, 2003: www.testingeducation.org/articles/index.html - Pettichord, Bret, “An Exploratory Testing Workshop Report”: www.testingcraft.com/exploratory-pettichord.html

Kapitel 9 - CMMI: www.sei.cmu.edu/library/ - TMMi: www.tmmifoundation.org/

www.testingstandards.co.uk

http://www.testingeducation.org/a/bsct2.pdf

http://ottovinter.dk/bugtaxst.doc

http://testingeducation.org/a/bugtax.pdf

http://www.whatistesting.com/interviews/jbach.htm

http://www.satisfice.com/articles/et-article.pdf

www.testingeducation.org/articles/index.html

http://www.testingcraft.com/exploratory-pettichord.html

www.sei.cmu.edu/library/

http://www.tmmifoundation.org/




12. Bilaga A – Kursplan Bakgrund

Målsättningar med Avancerad Testcertifiering Att få testare och testledare erkända som viktiga och professionella yrkesroller inom

programvaruverksamheten.

Att tillhandahålla ett standardramverk för testares karriärutveckling.

Att möjliggöra för professionellt kvalificerade testare att bli erkända av arbetsgivare, kunder och kolleger, och att höja testarnas status.

Att främja stabila och bra testmetoder inom alla programvarudiscipliner.

Att identifiera testområden som är av betydelse och har värde för industrin.

Att möjliggöra för programvaruleverantörer att anställa certifierade testare och på så sätt få kommersiella fördelar gentemot sina konkurrenter via reklam för sin anställningspolicy när det gäller testare.

Att ge testare, och andra med testintressen, en möjlighet att få en internationellt erkänd certifiering inom området.

Inträdeskrav för certifiering Villkoren för att delta i en examinering för ISTQB Avancerat Certifikat i Programvarutestning är att:

inneha ett certifikat från grundnivån, utfärdat av en av ISTQB godkänd examineringsnämnd eller erkänt nationellt organ

ha ett lämpligt antal års erfarenhet i programvarutestning eller utveckling. Det faktiska antalet år bestäms av den examineringsnämnd eller det nationella organ som beviljar den avancerade certifieringen

agera enligt de etiska principerna i denna kursplan.

Kandidaterna rekommenderas också att gå en kurs som har godkänts av ett nationellt organ knutet till ISTQB. Utbildning är emellertid inte ett krav för att delta i någon ISTQB examinering.

Ett existerande certifikat på praktiserande eller avancerad nivå inom programvarutestning (från ett ISTQB-godkänt nationellt organ eller examineringsnämnd) som erhållits innan detta internationella certifikat släpptes, bedöms vara likvärdigt med det internationella certifikatet. Det avancerade certifikatet förfaller inte och behöver inte förnyas. Utdelningsdatum framgår av certifikatet.

Lokala aspekter hanteras av ett av ISTQB godkänt nationellt organ i varje anslutet land. ISTQB har angivit vilka skyldigheter medlemmarna har, men de realiseras inom varje land. Dessa skyldigheter innebär bland annat ackreditering av kursleverantörer och arrangerande av examinationer, direkt eller indirekt genom en eller flera kontrakterade examineringsnämnder.




13. Bilaga B – För Läsarens Kännedom

13.1 Examineringsnämnder

Denna kursplan för avancerad nivå kräver kunskaper om innehållet i “Kursplan för Certifierad Testare Grundnivå”, version 2007 med de kunskapsnivåer som specificeras i den kursplanen.

Examineringsnämnder, godkända av ISTQB, kan skapa frågor inom alla ämnen som nämns i denna kursplan.

Det rekommenderas att de frågor som genereras tilldelas olika värden beroende på inlärningsmålen för respektive ämne. Till exempel: en fråga som hänför sig till kunskapsnivå 1 bör belönas med färre poäng än en som hänför sig till kunskapsnivå 3, och en fråga på kunskapsnivå 4 bör belönas med ytterligare poäng.

13.2 Certifieringskandidater & Kursleverantörer

För att erhålla ett certifikat på avancerad nivå måste certifieringskandidaterna inneha ett certifikat på grundnivå och dessutom visa examineringsnämnden att de har tillräcklig praktisk erfarenhet för att betraktas som kvalificerade för certifikatet på avancerad nivå. Kontrollera kriterierna för praktisk erfarenhet hos aktuell examineringsnämnd. ISTQB föreslår ett minimikrav på 5 års praktisk erfarenhet inom programvaruindustrin, och tre års praktisk erfarenhet om certifieringskandidaten är fil.kand. eller motsvarande inom teknisk utbildning.

För att uppnå tillräckliga kunskaper för den avancerade nivån inom testningsyrket krävs mer än bara kännedom om innehållet i denna kursplan. Certifieringskandidater och kursleverantörer uppmanas att lägga ner mer tid på inläsning och efterforskningar än vad som anges i denna kursplan.

Denna kursplan erbjuder listor med referenser, böcker och standarder som certifieringskandidater och kursleverantörer skulle kunna läsa för att bättre förstå de angivna ämnesområdena.




14. Bilaga C – För Kursleverantörers Kännedom

14.1 Moduler

Denna kursplan beskriver innehållet i följande tre moduler:

Avancerad Nivå - Testledare

Avancerad Nivå - Testanalytiker

Avancerad Nivå – Teknisk testanalytiker

Om man klarar examinering för alla tre modulerna erhålls certifikatet “Full Advanced Level Testing Professional”.

14.2 Kurstider

14.2.1 Kurstid per modul

Den tid som anses nödvändig och som rekommenderas för att lära ut de tre olika rollerna är följande:

Avancerad Nivå – Testledare 5 dagar

Avancerad Nivå – Testanalytiker 5 dagar

Avancerad Nivå – Teknisk testanalytiker 5 dagar

Denna tidsåtgång baserar sig på antal kapitel per modul och de specifika inlärningsmålen för varje kapitel. Minimitiden anges för varje kapitel och för varje roll.

Kursleverantörer kan lägga ner mer tid än vad som anges och examinander kan, som tidigare nämnts, lägga ner mer tid på inlärning och efterforskningar. Kursleverantörerna behöver inte presentera kapitlen i samma ordning som den som anges i kursplanen.

Kurserna behöver inte heller ges under fem på varandra följande dagar. Kursleverantörer kan organisera sina kurser på olika sätt, t.ex. 3+2 dagar för testledare eller 2 gemensamma dagar som följs av tre dagar var för testanalytiker respektive teknisk testanalytiker.

14.2.2 Gemensamma Delar

Kursleverantörer kan välja att lära ut de gemensamma delarna endast en gång, och på så sätt minska totaltiden och undvika upprepningar. Men kursleverantörer måste också komma ihåg att samma ämne kan betraktas ur olika synvinklar beroende på vilken modul det gäller.

14.2.3 Källor

Kursplanen innehåller referenser till etablerade standarder som måste användas när man tar fram kursmaterialet. Man måste, för varje standard, använda den version av standarden som denna kursplan pekar ut. Andra publikationer, mallar eller standarder som inte refereras i denna kursplan kan användas och refereras till, men ingår inte i examinationen.

14.3 Praktiska Övningar

Praktiskt arbete (korta övningar) bör finnas för alla områden där examinanderna förväntas kunna tillämpa sina kunskaper (Inlärningsmål 3 eller högre). Lektioner och övningar bör grunda sig på inlärningsmålen och ämnesbeskrivningarna i denna kursplan.




15. Bilaga D – Rekommendationer

Nedanstående rekommendationer berör ett flertal kapitel i denna kursplan och har därför samlats ihop i denna bilaga. Observera att detta också kan ingå i examineringen.

Bilagan innehåller ett antal rekommendationer som kan vara användbara när man träffar på testutmaningar. Dessa bygger på de sju grundläggande testprinciperna som presenterades i grundkursen. Det bör beaktas att denna bilaga inte är komplett, utan snarare utgör exempel på ”lessons learned”. Kursleverantörer ska välja de punkter i listan som är mest relevanta för den modul som ges.

15.1 Rekommendationer för Realisering

När testverksamheten ska realiseras kommer man att stöta på ett antal utmaningar. Erfarna testare ska kunna applicera de olika rekommendationerna i denna kursplan på det sammanhang, den organisation, det team, de uppgifter och de programvarukomponenter som ingår i testuppdraget. Listan nedan beskriver ett antal områden som har visat sig ha negativ påverkan på testarbetets resultat. Notera att listan inte har för avsikt att vara komplett.

Att lägga för stort fokus på funktionell testning: Defekter finns inte enbart i funktionaliteten. De är heller inte begränsade till när systemet används av en enda användare. Många samtidiga användare kan påverka programvarans beteende.

Att genomföra för lite konfigurationstestning: Om flera olika typer av processorer, operativsystem, virtuella maskiner, webbläsare och diverse kringutrustning kan kombineras på många sätt, kan testning av ett fåtal av dessa kombinationer medföra att ett stort antal potentiella defekter förblir oupptäckta.

Att skjuta upp stress- och lasttestning till sista minuten: Resultatet av stress- och lasttesterna kan leda till stora förändringar i programvaran (inklusive förändringar i den grundläggande arkitekturen). Eftersom detta kan vara mycket resurskrävande, kan det vara negativt för projektet om dessa tester genomförs alltför tätt inpå planerad produktionsstart.

Att inte testa dokumentationen: Ofta ingår dokumentation i leveransen av programvara till användarna. Om dokumentationen inte är korrekt kan användaren få problem med att använda programvaran fullt ut. Det kan i värsta fall leda till att användaren helt slutar använda programvaran.

Att inte testa installationsprocedurer: Trots att installationsprocedurer, och även ”Backup & Restore”-procedurer, bara används ett fåtal gånger är de oftast mer kritiska än själva programvaran. Om inte programvaran kan installeras kommer den inte heller att användas.

Att insistera på att avsluta en testuppgift helt innan man fortsätter med nästa: Även om några livscykelmodeller för programvaruutveckling föreslår sekventiell exekvering av uppgifter, är många uppgifter i praktiken möjliga att utföra parallellt (åtminstone delvis).

Att misslyckas med identifiering av riskområden: De områden som har identifierats som riskområden blir testade mer noggrant. Övriga områden, med få eller inga tester, kan emellertid senare visa sig vara mer riskfyllda än vad man uppskattade från början.

Att ha för hög detaljeringsgrad hos indata och testprocedurer: När testfall innehåller för mycket detaljer hämmas testarens kreativitet. När testaren får utrymme för sin kreativitet kan detta leda till upptäckt av ytterligare defekter i ett närområde till det specificerade testfallet.

Att inte notera och utforska ”irrelevanta” udda beteenden: Observationer av udda resultat och beteenden som kan tyckas irrelevanta är ofta indikationer på att defekter (precis som isberg) lurar under ytan.




Att bara kontrollera att produkten gör vad den förväntas göra: Genom att begränsa testningen till vad produkten förväntas göra, och inte vad den inte förväntas göra, är det troligt att man missar icke-önskvärda beteenden hos programvaran, t.ex. extra, oönskad funktionalitet.

Testsviter som bara förstås av dem som skapat sviterna: Eftersom testare kan få nya ansvarsområden måste andra testare kunna läsa och förstå de testfall och testinstruktioner som tidigare specificerats. Om man misslyckas med att skapa läsbara och förståeliga testspecifikationer kan det få negativa följder på så sätt att testfallet exekveras felaktigt eller till och med stryks helt eftersom man inte förstått dess syfte.

Att bara testa i de synliga användargränssnitten: En programvaras gränssnitt begränsas inte till användargränssnitten. Avvikelser kan även förekomma i interaktionen med programvaran vid t.ex. kommunikation mellan processer, vid batchexekvering och vid avbrottshantering.

Att felrapportering och konfigurationshantering är bristfällig: Felrapportering och felhantering samt även konfigurationshantering är extremt viktiga för att lyckas med projektet, vilket inkluderar både utveckling och testning. En framgångsrik testare är en testare som får många defekter att bli åtgärdade snarare än en testare som hittar många defekter, men som misslyckas med att rapportera dem på ett sätt som gör att de kan åtgärdas.

Att enbart underhålla regressionstestsviterna: Underhåll av testsviter begränsas inte till att kontrollera att inga regressionsdefekter uppstått. Koden kommer att utvecklas med tiden och ytterligare tester kommer att behöva utvecklas både för att täcka den nya funktionaliteten och för att kunna regressionstesta andra områden av programvaran.

Att inte dokumentera erfarenheter: Testaktiviteterna slutar inte när programvaran levererats till kund eller distribuerats till marknaden. En ny version eller utgåva av programvaran kommer med all sannolikhet att produceras. Därför bör kunskaper och erfarenheter lagras och överföras till de testare som ansvarar för nästa teststeg.

Att försöka automatisera alla testfall: Automatisering kan tyckas vara en bra idé, men automatisering är ett utvecklingsprojekt i sig. Alla tester bör inte automatiseras. Somliga tester går fortare att exekvera manuellt än automatiskt.

Att förvänta sig att alla manuella testfall kommer att kunna köras om: Det är ofta orealistiskt att tro att alla manuella testfall kommer att kunna köras om. Testarnas uppmärksamhet kommer att skifta, och de tenderar att fokusera på specifika områden av programvaran, medvetet eller omedvetet.

Att bara se till kostnadsbesparingen vid testdesign vid valet att använda GUI verktyg: Ett in- och uppspelningsverktyg (”capture/replay”) för GUI (grafiska användargränssnitt) kan innebära en stor initial investering. Det bör bara användas för att stödja en väl definierad strategi och efter att alla tillhörande kostnader är identifierade och utvärderade.

Att förvänta sig att regressionstester kommer att upptäcka ett stort antal nya defekter: Rent generellt upptäcks inte många nya defekter under regressionstestning, mest beroende på att den består av testfall som redan exekverats på tidigare version av samma programvara. Defekterna borde därmed redan ha upptäckts under dessa tidigare exekveringar. Det betyder dock inte att man kan eliminera regressionstestning helt eftersom syftet med regressionstestning är att förvissa sig om att det som tidigare fungerade fortfarande fungerar.

Oförmåga att tolka information om kodtäckning på ett realistiskt sätt: Ofta används siffror (som kan representera t.ex. kodtäckning) för att redovisa resultat av testaktiviteter. Ur ledningens synvinkel kan siffror på kodtäckning och andra mätetal verka mycket intressanta, men enbart siffror kan inte påvisa effektiviteten eller relevansen hos testaktiviteten. Som exempel skulle 100 % kodtäckning kunna låta som ett bra mål, men är det realistiskt? Vad avser kodtäckningen (instruktion, villkor eller MCDC)?




Att ta bort testfall från en regressionstestsvit bara för att de inte bidrar till täckningsgraden: I en regressionstestsvit kan (bör) vissa tester tas bort och andra läggas till. Orsaken till borttagande bör inte enbart grunda sig på om testfallet ökar täckningsgraden eller inte, eftersom ett testfalls syfte (frånvaron av en viss typ av fel) kanske inte har någon påverkan på täckningsgraden. Observera även att kodtäckningsgrad inte den enda typen av täckningsgrad. Tester kan ha skapats av helt andra skäl än för att öka täckningsgraden, såsom undersökning av specifika värden eller händelsekedjor.

Att använda täckningsgrad som ett prestandamål för testare: Täckningsgrad är ett mått på fullständighet, inte på personalens förmåga att prestera eller på deras effektivitet. För att utvärdera testarnas effektivitet i förhållande till sin organisation och sina projekt kan andra mätetal definieras. Men användandet av sådana måste tänkas igenom noga så att oönskade effekter (dysfunktioner) kan undvikas.

Att helt överge täckningsgrad: Det finns olika typer av täckningsgrad, t.ex. kodsatser, villkor, komponenter, funktioner osv. Arbetsbördan att få fram adekvata mätvärden kan vara avsevärd. Det är emellertid inte ett skäl till att överge mätning av täckningsgrad helt och hållet. Tvärtom kan det vara mycket användbart i testarbetet.

Många av ovanstående punkter behandlas i samband med specifika avsnitt i denna kursplan.

Då testmetoder och tillämpningar introduceras i er organisation, bör inte bara punktlistan ovan beaktas utan också ytterligare informationskällor såsom:

ISTQB:s olika kursplaner (Grundkurs och Avancerad).

Böcker som listas i referenslistan i denna kursplan.

Referensmodeller som de som beskrivs i avsnitt 8.3.




16. Bilaga E – Avsteg från SSTBs Ordlista

Under arbetet med denna översättning har vissa avsteg gjorts från SSTBs officiella ordlista (version 2.0). Vid nästa revidering av denna ordlista kommer dessa ändringar att införas i ordlistan och som konsekvens även införas i kursplanen för grundnivån.

16.1 Engelska till Svenska

Engelskt begrepp Nytt begrepp använt i denna kursplan

Tidigare begrepp (se Ordlista Engelsk/Svensk version 2.0)

0-switch coverage Se även N-switch coverage

täckning av tillståndsövergångar (även täckning av tillstånds-övergångssekvenser av längd 1)

0-övergångstäckning

0-switch testing Se även N-switch testing

Testning av tillståndsövergångar (även testning av tillstånds-övergångssekvenser av längd 1)

0-övergångstestning

accessibility testing tillgänglighetstestning tillgångstestning

branch testing bågtestning kodgrenstestning

condition determination coverage

MCDC (Modified Condition Determination Coverage)

täckning av villkorsbeslut

condition determination testing

MCDC testning testning av villkorsbeslut

decision tables beslutstabeller kodvillkorstabeller

decision coverage beslutstäckning kodvillkorstäckning

decision testing beslutstestning kodvillkorstestning

failure mode feltillstånd felsymptomsläge

fault injection felinjicering -

fault seeding plantering av fel felinjicering

function points funktionsgrad -

hazard analysis analys av risker som kan leda till skada eller fara för liv

ovisshetsanalys

multipel condition coverage

villkorskombinationstäckning kombinationsvillkorstäckning

multipel condition testing villkorskombinationstestning kombinationsvillkorstestning

N-switch coverage täckning av tillståndsövergångs-sekvenser av längd N+1

täckning av N-övergångar

N-switch testing testning av tillståndsövergångs-sekvenser av längd N+1 Se även N-switch coverage

testning av N-övergångar

random testing 1: slumpbaserad testning, 2: slumpmässig testning

slumpmässig testning

risk mitigation riskminskning risknedsättning

state transition testing tillståndsbaserad testning testning av tillståndsöver-gångar

test harness testexekveringsplattform (även test harness)

testsele

test points testmängd -

test progress monitoring uppföljning av testprogress testprogressövervakning

use case testing användningsfallsbaserad testning testning utifrån användningsfall

wild pointers fel- och/eller oinitialiserade pekare (även vilda pekare)

löpande pekare




16.2 Svenska till Svenska

Tidigare begrepp (Ordlista Engelsk/Svensk version 2.0)

Nytt begrepp Använt i denna kursplan

0-övergångstestning testning av tillståndsövergångssekvenser av längd 1 Se även N-switch testing

0-övergångstäckning täckning av tillståndsövergångssekvenser av längd 1 Se även N-switch coverage

felinjicering2 plantering av fel

felsymptomsläge feltillstånd

kodgrenstestning bågtestning

kodvillkorstabeller beslutstabeller

kodvillkorstestning beslutstestning

kodvillkorstäckning beslutstäckning

kombinationsvillkorstestning villkorskombinationstestning

kombinationsvillkorstäckning villkorskombinationstäckning

löpande pekare fel- och/eller oinitialiserade pekare (även vilda pekare)

ovisshetsanalys analys av risker som kan leda till skada eller fara för liv

risknedsättning riskminskning

slumpmässig testning 1: slumpbaserad testning, 2: slumpmässig testning

testning av N-övergångar testning av tillståndsövergångssekvenser av längd N+1 Se även N-switch coverage

testning av tillståndsöver-gångar tillståndsbaserad testning

testning av villkorsbeslut MCDC testning

testning utifrån användningsfall användningsfallsbaserad testning

testprogressövervakning uppföljning av testprogress

testsele testexekveringsplattform (även test harness)

tillgångstestning tillgänglighetstestning

täckning av N-övergångar täckning av tillståndsövergångssekvenser av längd N+1

täckning av villkorsbeslut MCDC (Modified Condition Determination Coverage)

2 Notera att begreppet felinjicering i denna kursplan är översättning av begreppet ”fault injection”. I

SSTBs ordlista, version 2.0 översätts ”fault seeding” till felinjicering.




17. Index administrationssgranskning, 79 agila metoder, 26 allvarlighet, 84 analysbarhet, ISO 9126, 76 anomali, 84 anpassa organisationen för testning, 108 anpassningsmöjlighet, testning av, 77 användbarhet, 68

testtekniker, 70 användbarhetstestning, 69 användningsfall, 58, 60 återhämtningsbarhet, 68, 73 attackbaserad testning, 64 automatisering, 97 avslutskriterier, 32 avvikelse, 84 avvikelsehantering, 84 avvikelseloggning, 84 båge, 61 bågtestning, 58 beslut, 60 beslutstabeller, 58, 59 beslutstestning, 58 bilaga A, 114 bilaga B, 115 bilaga C, 116 bilaga D, 117 black-box tekniker, 58 BS 7925, 32, 37, 58, 89 BVA, 58, 59 bygga team, 107 Capability Maturity Model, 87 Capability Maturity Model Integration, 96 CCB, 84 checklista, 63 CMMI, 96 CTP, 94 dataflödesanalys, 58 defekt, 84

analys, 85 åtgärd, 85 detektering, 84 färdigställande, 85 identifiering, 84 livscykel, 84

defektbaserad testdesign, 58 testteknik, 62

defekttaxonomi, 58 distribuerad testning, 47 dokumentation av testplaner, 43 driftacceptans, 68

driftacceptanstest, 71, 74 driftsprofil, 68 dynamisk analys, 58, 66

minnesläckor, 66 översikt, 66 prestanda, 67 vilda pekare, 66

effektivitet, 68 testtekniker, 76

effektivitetstestning, 75 ekvivalensklassindelning, 58, 59 enkäter, 71 erfarenhetsbaserad

testdesign, 58 testteknik, 62

ersättningsbarhet, testning av, 78 etik, 26, 31 evolutionära metoder, 26 exploratory testing, 58, 63 failover, 73, 74 falska negativer, 36 falska positiver, 36 felavhjälpande underhåll, 76 felgissning, 58, 63 felsymptom, 84 FMEA, 29, 40

användningsområden, 53 beskrivning, 52 implementeringssteg, 53 nytta & överväganden, 53

förändringsbarhet, 76 förbättra testprocessen, 91

CTP, 94 STEP, 95 TMM, 93 TPI, 94

förväntningar, 12 funktionell informationssäkerhet, testning

av, 69 funktioners växelverkan, testning av, 27 genomgång, 79 grannintegration, 65 granskare, 79 granskning, 70, 79

administrationssgranskning, 80 formell, 81 framgångsfaktorer, 82 införande av, 81 metoder, 80 principer, 79 revision, 80 speciella arbetsprodukter, 81




gränsvärdesanalys, 58, 59 grundläggande principer för

programvarutestning, 26 grundorsaksanalys, 84 gruppdynamik, 108 hårdvara, behov av, 56 heuristisk, 68, 70 HSIA, 90 HW-SW-integrationstestning, 27 IEEE, 89

IEEE 1028, 79, 89 IEEE 1044, 84, 85, 89 IEEE 610, 89 IEEE 829, 32, 34, 37, 38, 41, 43, 46, 84, 89

incident, 84 hantering, 86 kommunikation, 86 mätetal, 86

incidentrapport fält, 85

individuella färdigheter, 107 informationssäkerhet, 68

testtekniker, 73 informell granskning, 79 inlärningsmål

teknisk testanalytiker, 22 testanalytiker, 19 testledare, 15

inspektion, 70, 79 installerbarhet, testning av, 76 interoperabilitet, 68 interoperabilitetstestning, 69 intervjuundersökningar, 71 inträdeskrav för certifiering, 114 intressenters krav, 55 ISO

ISO 9126, 11, 34, 49 iterativ modell, 26 klassifikationsträd, 58 kodsats, 60 kodsatstestning, 58 kommunikation, 56, 110 kompatibilitet, 77 komplexa system, 29 kontrollflödesanalys, 58 kravbaserad testning, 58 kundproduktsintegration, 27 kvalitetsattribut för domäntestning, 68 kvalitetsattribut för teknisk testning, 71 lämplighet, 68, 69 lasttestning, 75 LCSAJ, 58, 61 ledare, 79 leverabler, 27 livscykel, 26

agila metoder, 26 evolutionära metoder, 26 iterativ, 26 RAD, 26 Rapid Application Development, 26 sekventiell, 26 spiral, 26 vattenfall, 26 V-modell, 26 W-modell, 26

mål teknisk testanalytiker, 12 testanalytiker, 12 testledare, 12

mål med certifieringen, 114 mallar, 43 mätetal, 26, 27, 30, 33, 35, 37, 39

CTP, 94 defekter, 86 externa (ISO 9126), 88 interna (ISO 9126), 88 kvalitet, 88 STEP, 95 TPI, 94

mätning, 26, 30, 109 MCDC, 58 MCDC testning, 61 minnesläcka, 58 minskning av produktrisker, 51 minskning av projektrisker, 51 misstag, 84 moderator, 79 motivation, 109 MTBF, 73 MTTR, 73 nivåtestplan, 40, 43 noggrannhet, 68 obereonde testning, 107 organisatoriska faktorer, 56 orsak-verkangrafer, 58, 59 ortogonalitetsmatriser, 60 övergripande testplan, 40, 42 parvis integration, 65 parvis täckning, 60 parvis testning, 58 portabilitet, 68 portabilitetstestning, 76 prestandatestning, 75 prioritet, 84 processförbättringar, introduktion, 91 processförbättringsmodell, 91 produktrisk, 40 programvarans livscykel, 26 programvaruattacker, 58 programvaruegenskaper, testning av, 68




programvarutestning, grundläggande principer, 26

projektrisk, 40 RAD, 26 RAMS, 55 Rapid Application Development, 26 rapportering, 27 RCA, 84 rekommendationer, 117 reliability growth model, 68 revision, 79 riskanalys, 40, 49 riskbaserad testning, 40, 48 riskhantering, 40, 49

programvarans livscykel, 52 riskidentifiering, 40, 49 riskminskning, 40, 50 riskminskning, strategier för, 51 risknivå, 40 risktyp, 40 robusthetstestning, 73 säkerhetskritiska system, 26, 29

komplexitet, 29 överensstämmelse med föreskrifter, 29

samexistens, 77 SBTM, 36, 53 SCCFA, 29, 90 scenarier, 60 schemaläggning av testaktiviteter, 40 schemaläggning testplanering, 45 sekventiell modell, 26 sessionsbaserad testledning, 40 SFMECA, 90 SFTA, 90 skalbarhetstestning, 75 slutlig testrapport, 32 spårbarhet, 27 speciella system, 28 specifikationsbaserad testdesign, 58 specifikationsbaserade testtekniker, 58 spiralmodell, 26 SRET, 73 standarder, 87

branschspecifika, 89 BS 7925, 32, 37, 58, 89 CMM, 87 CMMI, 87, 91, 96 CTP, 91, 92, 94 DO-178B, 35, 51, 89, 90 ECSS, 90 ED-12B, 35, 51, 89, 90 FDA, 90 flygindustri, 89 generellt, 88 IEC 61508, 51

IEEE, 89 IEEE 1028, 79, 89 IEEE 1044, 84, 85, 89 IEEE 610, 89 IEEE 829, 32, 34, 37, 38, 41, 43, 46, 84, 89 internationella, 88 ISO, 88 ISO 12207, 88 ISO 15504, 88 ISO 9126, 11, 34, 49, 88 nationella, 89 nytta, 88 överensstämmelse & konflikt, 88 överväganden, 87 rymdindustri, 90 SQR, 91 STEP, 91, 92, 95 TIM, 91 TMM, 87, 91, 93 TMMi, 87, 92, 93 TOM, 91 TPI, 87, 91, 92, 94 UML, 71 ursprung, 88

start & avslutskriterier, 27 startkriterier, 114 statisk analys, 58, 64

anropsträd, 65 arkitektur, 65 dataflöde, 64 kod, 64 kodegenskaper, 65 kodningsstandarder, 65 kontrollföde, 64 webbapplikation, 65

STEP, 95 stresstestning, 75 strukturbaserad testdesign, 58 strukturbaserade testtekniker, 60 SUMI (Software Usability Measurement

Inventory), 68 system av system, 26, 28, 29

ledning&testning, 28 livscykelegenskaper, 28

system test, 71 taxonomier, 62 teknisk granskning, 79 teknisk informationssäkerhetstestning, 72 test av resursanvändning, 75 test charter, 58 test improvement process, 90 Test Maturity Model, 87 test point analysis, 40 Test Process Improvement, 87 testaktiviteter, 27




testanalys & testdesign, 33 testavslut, 32 testavslutningsaktiviteter, 38 testdesign, 32 testestimering, 40, 43 testexekvering, 32, 36 testfall, 32, 34 testförbättringsprocesser, 87 testimplementering, 32, 35 testimplementering & exekvering, 35 testledning, 40

dokumentation, 40 exploratory testing, 53 övrigt, 55 säkerhetskritiska system, 54 system av system, 54 utforskande testning, 53

testledning, att tänka på, 53 testlogg, 32 testmändsanalys, 40 testningens värde för affärsverksamheten,

46 testnivå, 40 testorakel, 100 testövervakning, 40 testplan, 40 testplanering, 32 testplanering & teststyrning, 33 testpolicy, 40 testprocedur, 32 testprocesser, 32 testprocessmodeller, 32 testprogress övervakning & styrning, 45 testskript, 32 teststrategi, 33, 40, 41 teststyrning, 32, 40 testtekniker, 27, 58 testverktyg, 27, 97

avlusning, 97 debug, 97 driftsättning, 100 dynamisk analys, 97, 104 egenutvecklade, 101 emulator, 97 felinjicering, 97, 103 felplantering, 103 felsökning, 103 hyperlänk, 97 integration & informationsutbyte, 99

kategorier, 102 klassificering, 101 koncept, 97 kostnadsfördelar, 97 nyckelordsdriven, 97, 105 prestanda, 97, 105 risker, 97 simulator, 97 simulering & emulering, 104 skript, skriptspråk, 99 statisk analys, 97, 104 strategier, 98 testexekvering, 97, 102 testledning, 97 testorakel, 100 webb, 106

testvillkor, 32, 33 tillförlitlighet, 68

testtekniker, 74 tillförlitlighetstestning, 73 tillgänglighet, 68 tillgänglighetstestning, 71 tillståndsbaserad testning, 58, 59 TMM, 93 TPI, 94 underhåll vid förändring, 76 underhållbarhet, 68, 76 underhållbarhet, dynamisk testning av, 76 underhållstestning, 28 utforskande testning, 58, 63 utvärdering, 70 utvärdering av avslutskriterier och

rapportering, 37 väg, 62 vägtestning, 58 validering, 70 vattenfallsmodellen, 26 verktyg

orakel, 97 verktygsuppsättning, behov av, 56 vilda pekare, 58 villkor, 61 villkorskombinationer, 58, 61 villkorstestning, 58 V-modell, 26 WAMMI, 71 wide band delphy, 40 W-modell, 26 yrkeskunnande, 107

Certifierad Testare Avancerad Nivåh24-files.s3.amazonaws.com/65073/161755-QK37m.pdf · Certifierad...

Documents

Transcript of Certifierad Testare Avancerad Nivåh24-files.s3.amazonaws.com/65073/161755-QK37m.pdf · Certifierad...