Certificeret tester Syllabus Advanced level Version 2007 ...

Certificeret tester International

Syllabus – Advanced level Software Testing Qualifications Board

Oplysninger om copyright: Dette dokument må kopieres helt eller delvist, hvis kilden klart angives.

Certificeret tester Syllabus – Advanced level

Version 2007

International Software Testing Qualifications Board



UK Version 2007 (12. oktober 2007) Side 1 af 111 DANSK IT oversættelse V2007DK.1.0

© International Software Testing Qualifications Board





Copyright © International Software Testing Qualifications Board (herefter kaldet ISTQB®). Arbejdsgruppe for Advanced level: Bernard Homès (formand), Graham Bath, Rex Black, Sigrid Eldh, Jayapradeep Jiothis, Paul Jorgensen, Vipul Kocher, Judy McKay, Klaus Olsen, Randy Rice, JürgenRichter, Eric Riou Du Cosquer, Mike Smith, Geoff Thompson, Erik Van Veenendaal 2006-2007.





Revisionshistorik

Version Dato Bemærkninger

ISEB v1.1 04SEP01 ISEB Practitioner Syllabus

ISTQB 1.2E SEP03 ISTQB Advanced Level Syllabus fra EOQ-SG

V2007 12OKT07 Syllabus – Advanced level – for certificerede testere, version 2007

V2007DK.1.0 OKT08 Syllabus V2007 oversat til dansk af DANSK IT





Indholdsfortegnelse Certificeret tester Syllabus – Advanced level ............................................................................................................ 1 Version 2007 ............................................................................................................................................................. 1 International Software Testing Qualifications Board .................................................................................................. 1 Indholdsfortegnelse ................................................................................................................................................... 4 Tak til! ........................................................................................................................................................................ 9 0. Introduktion til denne syllabus ............................................................................................................................. 10

0.1 International Software Testing Qualifications Board .............................................................................. 10 Formålet med dette dokument ......................................................................................................................... 10 Advanced level for certificerede testere inden for softwaretest ........................................................................ 10 Vidensniveau .................................................................................................................................................... 10 Eksamination .................................................................................................................................................... 10 Akkreditering .................................................................................................................................................... 11 Detaljeringsniveau ............................................................................................................................................ 11 Sådan er denne syllabus organiseret ............................................................................................................... 11 Termer og definitioner ...................................................................................................................................... 11 Fremgangsmåde .............................................................................................................................................. 12

0.2 Forventninger ................................................................................................................................................. 13 0.2.1 Advanced level-testansvarlig. .................................................................................................................. 13 0.2.2 Advanced level-testanalytiker. ................................................................................................................. 13 0.2.3 Advanced level-teknisk testanalytiker...................................................................................................... 13

0.3 Læringsmål/vidensniveau .............................................................................................................................. 14 Niveau 1: Huske (K1) ................................................................................................................................... 14 Niveau 2: Forstå (K2) ................................................................................................................................... 14 Niveau 3: Anvende (K3)................................................................................................................................ 14 Niveau 4: Analysere (K4) .............................................................................................................................. 14

0.4 Læringsmål for testansvarlige ........................................................................................................................ 15 Introduktion til syllabus for testansvarlige – [60 minutter] ............................................................................. 15 Kapitel 1: Grundlæggende aspekter ved softwaretest – [150 minutter] ........................................................ 15 Kapitel 2: Testprocesser – [120 minutter] ..................................................................................................... 15 Kapitel 3: Teststyring – [1120 minutter] ........................................................................................................ 15 Kapitel 4: Testteknikker – [0 minutter] .......................................................................................................... 17 Kapitel 5: Test af softwarekarakteristika – [0 minutter] ................................................................................. 17 Kapitel 6: Reviews – [120 minutter] .............................................................................................................. 17 Kapitel 8: Standarder og testforbedringsproces – [120 minutter] .................................................................. 17 Kapitel 9: Testværktøjer og -automatisering – [90 minutter] ......................................................................... 17 Kapitel 10: Personlige evner – gruppesammensætning – [240 minutter] ..................................................... 18

0.5 Undervisningsmål for testanalytikere ............................................................................................................. 19 Introduktion til syllabus for testanalytikere – [60 minutter] ............................................................................ 19 Kapitel 2: Testprocesser – [180 minutter] ..................................................................................................... 19 Kapitel 3: Teststyring – [120 minutter] .......................................................................................................... 19 Kapitel 4: Testteknikker – [1080 minutter]..................................................................................................... 19 Kapitel 5: Test af softwarekarakteristika – [210 minutter] ............................................................................. 20 Kapitel 6: Reviews – [180 minutter] .............................................................................................................. 20 Kapitel 7: Hændelseshåndtering – [120 minutter] ......................................................................................... 20 Kapitel 8: Standarder og testforbedringsprocessen – [0 minutter] ................................................................ 20 Kapitel 9: Testværktøjer og -automatisering – [90 minutter] ......................................................................... 20 Kapitel 10: Personlige evner – gruppesammensætning – [30 minutter] ....................................................... 20

0.6 Undervisningsmål for tekniske testanalytikere ............................................................................................... 21 Introduktion til syllabus for tekniske testanalytikere – [60 minutter] .............................................................. 21 Kapitel 2: Testprocesser – [180 minutter] ..................................................................................................... 21 Kapitel 3: Teststyring – [120 minutter] .......................................................................................................... 21 Kapitel 4: Testteknikker – [930 minutter] ...................................................................................................... 21 Kapitel 5: Test af softwarekarakteristika – [240 minutter] ............................................................................. 22 Kapitel 7: Hændelseshåndtering – [120 minutter] ......................................................................................... 23 Kapitel 8: Standarder og testforbedringsprocessen – [0 minutter] ................................................................ 23





Kapitel 9: Testværktøjer og -automation – [210 minutter] ............................................................................. 23 Kapitel 10: Medarbejderkvalifikationer – teamsammensætning – [30 minutter] ............................................ 23

1. Grundlæggende aspekter ved softwaretest ......................................................................................................... 24 1.1 Introduktion .................................................................................................................................................... 24 1.2 Test i software-livscyklen ............................................................................................................................... 24 1.3 Specifikke systemer ....................................................................................................................................... 26

1.3.1 Systemer af systemer.............................................................................................................................. 26 1.3.1.1 Styring og test af systemer af systemer ............................................................................................ 26 1.3.1.2 Livscyklusegenskaber for systemer af systemer .............................................................................. 26

1.3.2 Sikkerhedskritiske systemer .................................................................................................................... 27 1.3.2.1 Overholdelse af lovgivning ................................................................................................................ 27 1.3.2.2 Sikkerhedskritiske systemer og kompleksitet ................................................................................... 27

1.4 Metrikker og måling ....................................................................................................................................... 28 1.5 Etik ................................................................................................................................................................. 28

2. Testprocesser...................................................................................................................................................... 30 Termer: ............................................................................................................................................................ 30

2.1 Introduktion .................................................................................................................................................... 30 2.2 Testprocesmodeller ....................................................................................................................................... 30 2.3 Testplanlægning og -kontrol .......................................................................................................................... 31 2.4 Testanalyse og -design .................................................................................................................................. 31

2.4.1 Identifikation af testbetingelser ................................................................................................................ 31 2.4.2 Fremstilling af testcases .......................................................................................................................... 32

2.5 Testimplementering og -afvikling ................................................................................................................... 33 2.5.1 Testimplementering ................................................................................................................................. 33 2.5.2 Testafvikling ............................................................................................................................................ 34

2.6 Evaluering af slutkriterier og rapportering ...................................................................................................... 35 2.7 Testlukningsaktiviteter ................................................................................................................................... 36

3. Teststyring ........................................................................................................................................................... 37 Termer: ............................................................................................................................................................ 37

3.1 Introduktion .................................................................................................................................................... 37 3.2 Teststyringsdokumentation ............................................................................................................................ 37

3.2.1 Testpolitik ................................................................................................................................................ 37 3.2.2 Teststrategi ............................................................................................................................................. 38 3.2.3 Hovedtestplan ......................................................................................................................................... 39 3.2.4 Niveautestplan ........................................................................................................................................ 39

3.3 Skabeloner til testplandokumentation ............................................................................................................ 40 3.4 Testestimering ............................................................................................................................................... 40 3.5 Testplanlægning ............................................................................................................................................ 41 3.6 Overvågning af testfremdrift og kontrol .......................................................................................................... 42 3.7 Den forretningsmæssige værdi af test ........................................................................................................... 43 3.8 Distribueret, outsourcet og insourcet test ...................................................................................................... 43 3.9 Risikobaseret test .......................................................................................................................................... 44

3.9.1 Introduktion til risikobaseret test .............................................................................................................. 44 3.9.2 Risikostyring ............................................................................................................................................... 45

3.9.2.1 Risikoidentifikation ............................................................................................................................ 45 3.9.2.2 Risikoanalyse ................................................................................................................................... 46 3.9.2.3 Risikoreduktion ................................................................................................................................. 47 Reduktionsstrategier ..................................................................................................................................... 47 Reduktion af projektrisiko ............................................................................................................................. 47 Reduktion af produktrisiko ............................................................................................................................ 47 Justering af test til yderligere testcyklusser .................................................................................................. 49

3.9.3 Risikostyring i livscyklussen .................................................................................................................... 49 3.10 Failure Mode and Effect Analysis ................................................................................................................ 50

3.10.1 Anvendelsesområder ............................................................................................................................ 50 3.10.2 Implementeringstrin ............................................................................................................................... 50 3.10.3 Fordele og omkostninger ....................................................................................................................... 50

3.11 Teststyringsovervejelser .............................................................................................................................. 51 3.11.1 Teststyringsovervejelser for udforskende test ....................................................................................... 51 3.11.2 Teststyringsovervejelser for systemer af systemer ............................................................................... 51





3.11.3 Teststyringsovervejelser for sikkerhedskritiske systemer ...................................................................... 52 3.11.4 Andre teststyringsovervejelser .............................................................................................................. 52

3.11.4.1 Interessentkrav ............................................................................................................................... 52 3.11.4.2 Nødvendige værktøjer .................................................................................................................... 53 3.11.4.3 Nødvendig hardware ...................................................................................................................... 53 3.11.4.4 Organisatoriske overvejelser .......................................................................................................... 53 3.11.4.5 Overvejelser om kommunikation..................................................................................................... 53 3.11.4.6 Overvejelser om datasikkerhed ...................................................................................................... 53

4. Testteknikker ....................................................................................................................................................... 55 Termer: ............................................................................................................................................................ 55

4.1 Introduktion .................................................................................................................................................... 55 4.2 Specifikationsbaseret ..................................................................................................................................... 55 4.3 Strukturbaseret .............................................................................................................................................. 57

Dækningsanalyse ......................................................................................................................................... 58 4.4 Defekt- og erfaringsbaseret ........................................................................................................................... 59

4.4.1 Defektbaserede teknikker ........................................................................................................................ 59 4.4.2 Erfaringsbaserede teknikker .................................................................................................................... 59

4.5 Statisk analyse ............................................................................................................................................... 61 4.5.1 Statisk analyse af kode ........................................................................................................................... 61

4.5.1.1 Kontrolflowanalyse............................................................................................................................ 61 4.5.1.1 Dataflowanalyse ............................................................................................................................... 61 4.5.1.3 Overholdelse af kodningsstandarder ................................................................................................ 61 4.5.1.4 Generering af kodemetrikker ........................................................................................................... 61

4.5.2 Statisk analyse af arkitektur .................................................................................................................... 61 4.5.2.1 Statisk analyse af et websted ........................................................................................................... 61 4.5.2.2 Kaldegrafer ....................................................................................................................................... 62

4.6 Dynamisk analyse .......................................................................................................................................... 62 4.6.1 Oversigt ................................................................................................................................................... 62 4.6.2 Afdækning af hukommelseslæk .............................................................................................................. 62 4.6.3 Registrering af vilde pointere ................................................................................................................... 63 4.6.4 Analyse af performance .......................................................................................................................... 63

5. Test af softwarekarakteristika .............................................................................................................................. 64 Termer ............................................................................................................................................................. 64

5.1 Introduktion .................................................................................................................................................... 64 5.2 Kvalitetsattributter i domænetest ................................................................................................................... 64

5.2.1 Nøjagtighedstest ..................................................................................................................................... 64 5.2.2 Egnethedstest ......................................................................................................................................... 64 5.2.3 Tværoperationalitetstest .......................................................................................................................... 65 5.2.4 Funktionel sikkerhedstest ........................................................................................................................ 65 5.2.5 Brugervenlighedstest............................................................................................................................... 65

5.2.5.1 Specifikation af brugervenlighedstest .............................................................................................. 66 Inspektion, evaluering eller review ................................................................................................................ 66 Validering af den faktiske implementering .................................................................................................... 66 Analyser og spørgeskemaundersøgelser ..................................................................................................... 66

5.2.6 Tilgængelighedstest ................................................................................................................................ 67 5.3 Kvalitetsattributter i teknisk test ......................................................................................................................... 67

5.3.1 Test af teknisk sikkerhed ......................................................................................................................... 67 5.3.1.1 Specifikation af sikkerhedstest ......................................................................................................... 68

5.3.2 Pålidelighedstest ..................................................................................................................................... 68 5.3.2.1 Test for robusthed............................................................................................................................. 69 5.3.2.2 Genoprettelsestest............................................................................................................................ 69 5.3.2.3 Specifikation af pålidelighedstest ...................................................................................................... 69

5.3.3 Effektivitetstest ........................................................................................................................................ 70 5.3.3.1 Performancetest ............................................................................................................................... 70 5.3.3.2 Belastningstest ................................................................................................................................. 70 5.3.3.3 Stresstest .......................................................................................................................................... 70 5.3.3.4 Skalerbarhedstest ............................................................................................................................. 70 5.3.3.5 Test af ressourceudnyttelse .............................................................................................................. 70 5.3.3.6 Specifikation af effektivitetstest ......................................................................................................... 71





5.3.4 Vedligeholdelsesegnethedstest ............................................................................................................... 71 5.3.4.1 Dynamisk vedligeholdelsesegnethedstest ........................................................................................ 71 5.3.4.2 Analyseegnethed (korrigerende vedligeholdelse) ............................................................................. 71 5.3.4.3 Ændringsegnethed, stabilitet og testbarhed (adaptiv vedligeholdelse) ............................................. 71

5.3.5 Flytbarhedstest ........................................................................................................................................ 71 5.3.5.1 Installationstest ................................................................................................................................. 71 5.3.5.2 Sameksistens ................................................................................................................................... 72 5.3.5.3 Test af tilpasningsegnethed .............................................................................................................. 72 5.3.5.4 Udskiftningsegnethedstest ................................................................................................................ 72

6. Reviews ............................................................................................................................................................... 73 Termer ............................................................................................................................................................. 73

6.1 Introduktion .................................................................................................................................................... 73 6.2 Principperne for reviews ................................................................................................................................ 73 6.3 Reviewtyper ................................................................................................................................................... 74

6.3.1 Ledelsesreview og revision ..................................................................................................................... 74 6.3.2 Review af bestemte arbejdsprodukter ..................................................................................................... 74 6.3.3 Gennemførelse af et formelt review ........................................................................................................ 75

6.4 Indførelse af reviews ...................................................................................................................................... 75 6.5 Succesfaktorer for reviews............................................................................................................................. 76

Tekniske faktorer .......................................................................................................................................... 76 Organisatoriske faktorer ............................................................................................................................... 76 Medarbejderspørgsmål ................................................................................................................................. 76

7. Hændelseshåndtering ......................................................................................................................................... 77 Termer ............................................................................................................................................................. 77

7.1 Introduktion .................................................................................................................................................... 77 7.2 Hvornår kan en fejl findes? ............................................................................................................................ 77 7.3 Defektlivscyklus ............................................................................................................................................. 77

7.3.1 Trin 1: Erkendelse ................................................................................................................................... 77 7.3.2 Trin 2: Undersøgelse ............................................................................................................................... 78 7.3.3 Trin 3: Handling ....................................................................................................................................... 78 7.3.4 Trin 4: Arkivering ..................................................................................................................................... 78

7.4 Defektfelter .................................................................................................................................................... 78 7.5 Metrikker og hændelseshåndtering ................................................................................................................ 78 7.6 Kommunikation af hændelser ........................................................................................................................ 78

Termer ............................................................................................................................................................. 79 8.1 Introduktion .................................................................................................................................................... 79 8.2 Overvejelser om standarder........................................................................................................................... 79

8.2.1 Generelle aspekter ved standarder ......................................................................................................... 79 8.2.1.1 Kilder til standarder ........................................................................................................................... 79 8.2.1.2 Værdien af standarder ...................................................................................................................... 80 8.2.1.3 Sammenhæng og konflikter .............................................................................................................. 80

8.2.2 Internationale standarder ........................................................................................................................ 80 8.2.2.1 ISO ................................................................................................................................................... 80 8.2.2.2 IEEE ................................................................................................................................................. 80

8.2.3 Nationale standarder ............................................................................................................................... 81 8.2.4 Domænespecifikke standarder ................................................................................................................ 81

8.2.4.1 Flyelektroniske systemer .................................................................................................................. 81 8.2.4.2 Rumfartsindustri................................................................................................................................ 82 8.2.4.3 Administration af fødevarer og medicin ............................................................................................ 82

8.2.5 Andre standarder .................................................................................................................................... 82 8.3 Testforbedringsproces ................................................................................................................................... 82

8.3.1 Introduktion til procesforbedring .............................................................................................................. 83 8.3.2 Typer af procesforbedring ....................................................................................................................... 83

8.4 Forbedring af testprocessen .......................................................................................................................... 83 8.5 Forbedring af testprocessen med TMM ......................................................................................................... 84 8.6 Forbedring af testprocessen med TPI ............................................................................................................ 85 8.7 Forbedring af testprocessen med CTP (CTP) ................................................................................................ 86 8.8 Forbedring af testprocessen med STEP ........................................................................................................ 86 8.9 CMMI (Capability Maturity Model Integration) ................................................................................................ 87





9. Testværktøjer og -automation ............................................................................................................................. 88 Termer ............................................................................................................................................................. 88

9.1 Introduktion .................................................................................................................................................... 88 9.2 Testværktøjskoncepter .................................................................................................................................. 88

9.2.1 Cost-benefit og risici ved testværktøjer og automatisering ...................................................................... 88 9.2.2 Testværktøjsstrategier............................................................................................................................. 89 9.2.3 Integration og informationsudveksling mellem værktøjer ........................................................................ 90 9.2.4 Automatiseringssprog: Scripts, scriptsprog ............................................................................................. 90 9.2.5 Begrebet testorakler ................................................................................................................................ 90 9.2.6 Testværktøjsanvendelse ......................................................................................................................... 90 9.2.7 Brug af open source-testværktøjer .......................................................................................................... 91 9.2.8 Udvikling af egne testværktøjer ............................................................................................................... 91 9.2.9 Klassifikation af testværktøjer ................................................................................................................. 92

9.3 Testværktøjskategorier .................................................................................................................................. 92 9.3.1 Teststyringsværktøjer .............................................................................................................................. 92 9.3.2 Testafviklingsværktøj............................................................................................................................... 93 9.3.3 Debugging- og fejlfindingsværktøjer ........................................................................................................ 93 9.3.4 Fejlplantnings- og fejlindsættelsesværktøjer ........................................................................................... 94 9.3.5 Simulerings- og emuleringsværktøjer ...................................................................................................... 94 9.3.6 Statiske og dynamiske analyseværktøjer ................................................................................................ 94

9.3.6.1 Statiske analyseværktøjer ................................................................................................................ 94 9.3.6.2 Dynamiske analyseværktøjer ........................................................................................................... 94

9.3.7 Nøgleordsdrevet testautomation ............................................................................................................. 95 9.3.8 Performancetestværktøjer ....................................................................................................................... 95 9.3.9 Webværktøjer .......................................................................................................................................... 96

10. Personlige evner – gruppesammensætning ...................................................................................................... 97 Termer ............................................................................................................................................................. 97

10.1 Introduktion .................................................................................................................................................. 97 10.2 Individuelle evner ......................................................................................................................................... 97 10.3 Testgruppedynamik ..................................................................................................................................... 97 10.4 Indpasning af test i en organisation ............................................................................................................. 98 10.5 Motivation .................................................................................................................................................... 99 10.6 Kommunikation ............................................................................................................................................ 99

11. Referencer....................................................................................................................................................... 101 11.1 Standarder ................................................................................................................................................. 101

11.1.1 Pr. kapitel ............................................................................................................................................ 101 11.1.2 Alfabetisk ............................................................................................................................................. 101

11.2 Bøger ......................................................................................................................................................... 102 11.3 Andre referencer ........................................................................................................................................ 103

12. Appendiks A – Baggrund for syllabussen ........................................................................................................ 104 Målene med kvalifikationen Advanced Certificate .......................................................................................... 104 Startkravene til denne kvalifikation ................................................................................................................. 104

13. Appendiks B – Bemærkninger til læserne ....................................................................................................... 105 13.1 Eksamenspaneler ...................................................................................................................................... 105 13.2 Kandidater og kursusudbydere .................................................................................................................. 105

14. Appendiks C – Bemærkninger til kursusudbydere ........................................................................................... 106 14.1 Modularitet ................................................................................................................................................. 106 14.2 Uddannelsestider ....................................................................................................................................... 106

14.2.1 Uddannelse pr. modul ......................................................................................................................... 106 14.2.2 Sammenfald ........................................................................................................................................ 106 14.2.3 Kilder ................................................................................................................................................... 106

14.3 Praktiske øvelser ....................................................................................................................................... 106 15. Appendiks D – Anbefalinger ............................................................................................................................ 107

15.1 Anbefalinger til automatisering ................................................................................................................... 107 16. Indeks .............................................................................................................................................................. 110





Tak til! Dette dokument er udarbejdet af et kerneteam fra International Software Testing Qualifications Board Advanced Level-arbejdsgruppen: Bernard Homès (formand), 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 og Erik Van Veenendaal. Kerneteamet takker review-teamet og alle nationale grupper for deres forslag og input. På færdiggørelsestidspunktet for Syllabus – Advanced level var der følgende medlemmer i Advanced Level-arbejdsgruppen (i alfabetisk orden): Graham Bath, Rex Black, Robert Bender, Chris Carter, Maria Clara Choucair, Sigrid Eldh, Dorothy Graham, Bernard Homès (formand), Jayapradeep Jiothis, Vipul Kocher, Anastasios Kyriakopoulos, Judy McKay, Thomas Mueller, Klaus Olsen, Avinoam Porat, Meile Posthuma, Erkki Pöyhönen, Jürgen Richter, Eric Riou Du Cosquer, Jan Sabak, Hans Schaefer, Maud Schlich, Rajesh Sivaraman, Mike Smith, Michael Stahl, Geoff Thompson og Erik Van Veenendaal. Følgende personer deltog i review, kommentering og udvælgelse af denne syllabus: Bernard Homès (formand)

Reto Armuzzi Phillip Isles Meile Posthuma

Sue Atkins Pr. Paul C. Jorgensen Eric Riou Du Cosquer

Graham Bath Vipul Kocher Stefan Ruff

Paul Beekman Anastasios Kyriakopoulos Hans Schaefer

Armin Beer Junfei Ma Maud Schlich

Rex Black Fergus McClachlan Rajesh Sivaraman

Francisca Blunschi Judy McKay Mike Smith

Armin Born Don Mills Katja Stalder

Con Bracke Gary Mogyorodi Neil Thompson

Chris Carter Richard Morgan Benjamin Timmermans

Maria Clara Choucair Silvio Moser Chris van Bael

Robert Dankanin Ernst Müller Jurian van de Laar

Piet de Roo Reto Müller Marnix van den Ent

Sigrid Eldh Thomas Müller Mark van der Zwan

Tim Edmonds Peter Mullins Stephanie van Dijck

Erwin Engelsma Beat Nagel Jan van Moll

Graham Freeburn Richard Neeve Erik Van Veenendaal

Dorothy Graham Klaus Olsen Roland Weber

Brian Hambling Dale Perry Phillip Whettlock

Jeff B Higgott Helmut Pichler Derek Young

Bernard Homès (formand) Jörg Pietzsch Mike Young

Rob Hendriks Avionam Porat Wenqiang Zheng.

Dr Suhaimi Ibrahim Iris Pinkster

Horst Pohlmann

Dette dokument blev formelt frigivet af generalforsamlingen i ISTQB® den 12. oktober 2007.





0. Introduktion til denne syllabus

0.1 International Software Testing Qualifications Board International Software Testing Qualifications Board (herefter kaldet ISTQB®) består af medlemskommissioner, der repræsenterer lande eller områder over hele verden. På frigivelsestidspunktet bestod ISTQB® af 33 medlemskommissioner. Flere oplysninger om strukturen i og medlemskab af ISTQB kan findes på www.istqb.org.

Formålet med dette dokument Denne syllabus danner grundlag for International Software Testing Qualification på Advanced level. ISTQB® stiller denne syllabus til rådighed som følger: 1 For medlemskommissioner, til at oversætte syllabussen til deres lokale sprog og til at akkreditere

kursusudbydere. Nationale kommissioner kan tilpasse syllabussen til deres særlige sproglige behov og ændre referencerne, så de svarer til deres lokale publikationer.

2 For eksamenskommissioner, til at uddrage eksamensspørgsmål på deres lokale sprog tilpasset undervisningsmålene for hvert modul.

3 For kursusudbydere, til at udarbejde kursusmateriale og fastlægge passende undervisningsmetoder. 4 For certificeringskandidater, til forberedelse til eksamen (som en del af et undervisningsforløb eller gennem

uafhængigt). 5 For det internationale software- og systemarbejdesamfund, til at fremme software- og softwaretestfaget og

som grundlag for bøger og artikler. ISTQB® kan give andre grupper lov til at bruge syllabussen til andre formål, forudsat at de søger om og får skriftlig tilladelse på forhånd.

Advanced level for certificerede testere inden for softwaretest Kvalifikationen på Advanced level er målrettet til personer, der er nået til et videregående niveau i deres karriere inden for softwaretest. Det omfatter personer i roller som testere, testanalytikere, testteknikere, testkonsulenter, testledere, brugeraccepttestere og softwareudviklere. Advanced level-kvalifikationen egner sig også for alle, der ønsker en dybere forståelse af softwaretest, f.eks. projektledere, kvalitetschefer, softwareudviklingschefer, forretningsanalytikere, it-chefer og ledelseskonsulenter. For at kunne opnå Advanced level-certificering skal kandidaterne have Foundation Certificate, og overbevise den eksamenskommission, der eksaminerer dem, at de har tilstrækkelig praktisk erfaring til at være at betragte som kvalificerede til Advanced level. Kontakt den relevante eksamenskommission for at få oplysninger om deres specifikke kriterier for praktisk erfaring.

Vidensniveau Undervisningsmålene for hvert kapitel er opdelt således, at de klart kan identificeres for hvert enkelt modul. Yderligere oplysninger og eksempler på undervisningsmål findes i afsnit 0.3. Indholdet i denne syllabus, termer og hovedelementer (formål) fra alle de nævnte standarder skal som mininum huskes (K1), selv om det/de ikke er nævnt udtrykkeligt i undervisningsmålene.

Eksamination Alle eksamener til Advanced-certificering skal være baseret på denne syllabus og på syllabus for Foundation level. Svarene på eksamensspørgsmålene kan kræve brug af materiale, der er baseret på mere end et afsnit i denne syllabus og syllabus for Foundation level. Der kan eksamineres i alle afsnit af denne syllabus og syllabus for Foundation level.

http://www.istqb.org/





Eksamensformen er defineret i ISTQB®s Advanced Exam Guidelines. De enkelte medlemskommissioner kan anvende andre eksaminationsmetoder, hvis det ønskes. Eksamener kan tages som en del af et godkendt undervisningsforløb, eller de kan tages uafhængigt (f.eks. i et eksaminationscenter). Eksamenerne kan tages enten på papir eller elektronisk, men alle eksamener skal foregå under tilsyn/overvågning (kontrolleret af en person, der er udpeget af et nationalt kommission eller en eksamenskommission).

Akkreditering En ISTQB®-medlemskommission kan akkreditere kursusudbydere, hvis kursusmateriale følger syllabussen. Kursusudbyderne kan få retningslinjerne for akkreditering fra den kommission eller den organisation, der foretager akkrediteringen. Et akkrediteret kursus er anerkendt som værende i overensstemmelse med denne syllabus og har lov til at have en ISTQB®-eksamen som en del af kurset. Der er yderligere vejledning til kursusudbydere i Appendiks C – Information til kursusudbydere

Detaljeringsniveau Detaljeringsniveauet i denne syllabus muliggør internationalt konsistent undervisning og eksamination. For at nå dette mål består syllabussen af følgende:

Generelle undervisningsmål, der beskriver hensigten med Advanced level

Læringsmål for hvert vidensområde, der beskriver udbyttet af den kognitive undervisning og den tankegang, der skal opnås

En liste over de emner, der skal undervises i, inklusive en beskrivelse og referencer til yderligere kilder, hvis det er påkrævet

En liste over de termer, som de studerende skal kunne huske og have forstået

En beskrivelse af de nøglekoncepter, der skal undervises i, inklusive kilder som godkendt litteratur eller standarder

Syllabussens indhold er ikke en beskrivelse af hele vidensområdet inden for softwaretest. Den afspejler den detaljeringsgrad, der skal dækkes i Advanced level-kurser.

Sådan er denne syllabus organiseret Der er 10 hovedkapitler, der hver indeholder et indledende afsnit, der giver et overblik over, hvordan de enkelte kapitler passer sammen med de forskellige testdiscipliner (moduler). Til uddannelsesformål er afsnittene 0.3 til 0.6 forsynet med specifikke læringsmål for hvert modul pr. kapitel. Disse afsnit indeholder også angivelse af den forventede minimumstid til undervisning i disse emner. Det anbefales kraftigt at læse syllabussen og studere læringsmålene for det specifikke kapitel samtidig. Det giver læseren mulighed for at få en fuldstændig forståelse af, hvad der kræves, og hvad der er væsentligt i hvert kapitel for hvert af de tre moduler.

Termer og definitioner Mange af de termer, der bruges i softwarelitteraturen, bruges i flæng. Definitionerne i denne syllabus for Advanced level findes i det standardglossar for termer, der bruges i softwaretest, og som er udgivet af ISTQB®.





Fremgangsmåde Der er forskellige fremgangsmåder for test så som de, der er baseret på specifikationer, kodestruktur, data, risici, processer, standarder og lister over taksonomier. Forskellige processer og værktøjer understøtter testprocesserne, og metoder til forbedring af eksisterende processer er tilgængelige. Denne syllabus for Advanced level er organiseret omkring de fremgangsmåder, der er foreslået i ISO 9126, med en opdeling i funktionelle, ikke-funktionelle og støttende fremgangsmåder. Støtteprocesser og nogle metoder til forbedring er nævnt. Valget af denne opbygning og disse processer er sket på en arbitrær basis, der vurderes at give et godt grundlag for Advanced Level-testere og -testansvarlige.





0.2 Forventninger Den Advanced level-certificering, der er beskrevet i denne syllabus, vil blive eksamineret ud fra tre store opgavebeskrivelser, der hver repræsenterer basale ansvarsområder og forventninger i en organisation. I alle organisationer kan ansvar og de tilhørende opgaver deles af forskellige personer eller dækkes af en enkelt person. De arbejdsmæssige ansvarsområder er beskrevet nedenfor.

0.2.1 Advanced level-testansvarlig. Medarbejdere med advanced certificering i Teststyring, skal være i stand til at:

Definere de overordnede testmålsætninger og teststrategien for de systemer, der testes

Planlægge, tidsplanlægge og følge op på opgaverne

Beskrive og organisere de nødvendige aktiviteter

Vælge, anskaffe og tildele de nødvendige ressourcer til opgaverne

Vælge, organisere og lede testgrupper

Organisere kommunikationen mellem medlemmerne af testgrupperne og mellem testgrupper og alle de andre interessenter

Begrunde beslutningerne og sørge for passende rapportering af information.

0.2.2 Advanced level-testanalytiker. Advanced level-testanalytikere skal være i stand til at:

Strukturere de opgaver, der er defineret i teststrategien i form af forretningsområdekrav

Analysere systemet tilstrækkeligt detaljeret til at opfylde brugerens kvalitetsforventninger

Vurdere systemkravene for at bestemme anvendeligheden (evt. validiteten?) indenfor forretningsområdet

Forberede og afvikle de passede aktiviteter og rapportere om deres fremdrift

Tilvejebringe den nødvendige dokumentation til at understøtte vurderinger

Implementere de værktøjer og teknikker, der er nødvendige for at opnå de definerede mål

0.2.3 Advanced level-teknisk testanalytiker. Advanced level-tekniske testanalytikere skal være i stand til at:

Strukturere de opgaver, der er defineret i teststrategien i form af tekniske krav

Analysere systemets interne struktur tilstrækkeligt detaljeret til at opfylde det forventede kvalitetsniveau

Vurdere systemet med hensyn til tekniske kvalitetsattrubutter, f.eks. ydeevne, sikkerhed etc.

Forberede og afvikle de passede aktiviteter og rapportere om deres fremdrift

Udføre tekniske testaktiviteter

Tilvejebringe den nødvendige dokumentation til at understøtte vurderinger

Implementere de værktøjer og teknikker, der er nødvendige for at opnå de definerede mål





0.3 Læringsmål/vidensniveau De følgende læringsmål er defineret, så de gælder for denne syllabus. Hvert emne i syllabussen vil blive eksamineret i henhold til læringsmålet for det.

Niveau 1: Huske (K1)

Kandidaten genkender, husker og kan genkalde sig en term eller et begreb. Nøgleord: Huske, genkalde sig, genkende, vide. Eksempel Kan genkende definitionen af "afvigelse" som:

"den manglende levering af en service til en slutbruger eller enhver anden interessent" eller

"en komponents eller et systems faktiske afvigelse fra dens/dets forventede levering, service eller resultat".

Niveau 2: Forstå (K2)

Kandidaten kan vælge årsager eller forklaringer til udsagn, der er relateret til emnet, og kan opsummere, adskille, klassificere og give eksempler på fakta (f.eks. sammenligne termer), testkoncepterne og testprocedurerne (forklare rækkefølgen af opgaver). Nøgleord: Opsummere, klassificere, sammenligne, mappe, modskille, eksemplificere, fortolke, oversætte, repræsentere, udlede, konkludere, kategorisere. Eksempler Forklare årsagen til, at tests skal udarbejdes som tidligt som muligt:

For at finde fejl, når de er billigere at fjerne.

For at finde de vigtigste fejl først. Forklare lighederne og forskellene mellem integrations- og systemtest:

Ligheder: tester mere end én komponent og kan teste ikke-funktionelle aspekter.

Forskelle: integrationstest koncentrerer sig om grænseflader og sammenhænge, og systemtest koncentrerer sig om forhold ved hele systemet, f.eks. start-til-slut behandling.

Niveau 3: Anvende (K3)

Kandidaten kan vælge den korrekte anvendelse af et begreb eller en teknik og anvende den/det i en given kontekst. K3 anvendes normalt til proceduremæssig viden. Der er ikke involveret nogen kreativ handling som evaluering af et softwareprogram eller fremstilling af en model for en given software. Når vi har en given model og i syllabussen dækker de proceduremæssige trin, der skal bruges for at fremstille testcases fra en model, så er det K3. Nøgleord: Implementere, udføre, bruge, følge en procedure, anvende en procedure. Eksempel

Kan identificere grænseværdier for gyldige og ugyldige partitioner.

Bruge den generiske procedure for fremstilling af testcases til at vælge testcases fra et givet tilstandsovergangsdiagram (og et sæt af testcases) for at dække alle overgange.

Niveau 4: Analysere (K4)

Kandidaten kan opdele oplysninger, der er relateret til en procedure eller en teknik, i deres grundbestanddele for at få en bedre forståelse og kan skelne mellem fakta og forstyrrelser. En typisk anvendelse er at foretage en analyse af et dokument, et stykke software eller en projektsituation og at foreslå passende handlinger til løsning af et problem eller en opgave. Nøgleord: Analysere, adskille, vælge, strukturere, fokusere, tillægge, dekonstruere, evaluere, bedømme, overvåge, koordinere, fremstille, syntetisere, generere, fremsætte hypotese, planlægge, designe, konstruere, producere. Eksempel

Analysere produktrisici og foreslå forebyggende og korrigerende mildnende aktiviteter.

Beskrive hvilke dele af en hændelsesrapport, der er faktiske, og hvilke der er afledt af resultater. Reference (Med hensyn til de kognitive niveauer i undervisningsmål) 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 Læringsmål for testansvarlige Dette afsnit indeholder en liste over detaljerede læringsmål for modulet Testansvarlig. Generelt kan der eksamineres på K1-niveau i alle dele af denne syllabus. Det vil sige, at kandidaten genkender, husker og kan genkalde sig en term eller et begreb. Derfor indeholder tabellen nedenfor kun undervisningsmål for K2-, K3- og K4-niveauerne.

Introduktion til syllabus for testansvarlige – [60 minutter]

(inkluderer repetition af syllabus for Foundation level fra ISTQB®)

Kapitel 1: Grundlæggende aspekter ved softwaretest – [150 minutter]

1.2 Test i software-livscyklussen

(K2) Beskriv, hvordan test er en del af enhver aktivitet med softwareudviklings og -vedligeholdelsesaktivitet

(K4) Analysér softwarens livscyklusmodeller, og skitsér de mest passende opgaver/testaktiviteter, der skal udføres. (idet der skelnes mellem test- og udviklingsaktiviteter)

1.3 Specifikke systemer

(K2) Forklar ved hjælp af eksempler de specielle kendetegn for test af systemer af systemer

(K2) Forklar, hvorfor de tre hovedresultater fra test af sikkerhedskritiske systemer kræves for at vise overholdelse af lovgivning

1.4 Metrikker og måling

(K2) Beskriv og sammenlign de testrelaterede standardmetrikker

(K3) Overvåg testaktiviteterne ved at måle testobjektet eller testobjekterne og testprocessen

Kapitel 2: Testprocesser – [120 minutter]

2.3 Testplanlægning og -kontrol

(K2) Beskriv ved hjælp af eksempler, hvordan teststrategier påvirker testplanlægningen

(K2) Sammenlign testarbejdsprodukter, og forklar ved hjælp af eksempler relationerne mellem udviklings- og testarbejdsprodukter

(K2) Klassificer testkontrolaktiviteter, der har relation til bestemmelsen af, om testmission, -strategier og -mål er opnået

2.5 Testimplementering og -afvikling

(K2) Forklar startbetingelser for testafvikling

(K2) Forklar ved hjælp af eksempler fordelene og ulemperne ved tidlig testimplementering idet forskellige testteknikker tages i betragtning

(K2) Forklar årsagerne til, at brugere og/eller kunder kan blive inddraget i testafviklingen.

(K2) Beskriv, hvordan niveauet for testlogning kan variere afhængigt af testniveauet

2.6 Evaluering af slutkriterier og rapportering

(K2) Opsummér, hvilke informationer det er nødvendigt at indsamle under testprocessen for at understøtte præcis rapportering og evaluering i forhold til slutkriterierne

2.7 Testlukningsaktiviteter

(K2) Opsummér de fire grupper af testlukningsaktiviteter

(K3) Generalisér erfaringerne i testlukningsfasen for at afdække, om der er områder, der skal forbedres eller gentages

Kapitel 3: Teststyring – [1120 minutter]

3.2 Teststyringsdokumentation

(K4) Opsummer, teststyringsdokumenter, f.eks. testplan, testdesignspecifikation og testprocedure i overensstemmelse med IEEE 829

(K2) Beskriv mindst 4 vigtige elementer i en teststrategi/-tilgang, og hvilke dokumenter der i følge IEEE 829 indeholder elementer fra teststrategien

(K2) Illustrer, hvordan og hvorfor afvigelser fra teststrategien styres i andre teststyringsdokumenter.





3.3 Testplandokumentation

(K2) Opsummér IEEE 829s struktur for en hovedtestplan

(K2) Omskriv og fortolk de emner, der er foreslået i IEEE 829 standardens struktur for en testplan med hensyn til tilpasning til en organisation, produktrisikoen og risikoen, størrelsen og formaliteten for et projekt

3.4 Testestimering

(K3) Estimer testarbejdet for et lille eksempelsystem ved brug af en metrikbaseret og en erfaringsbaseret metode, idet de faktorer, der påvirker omkostninger og varighed, tages i betragtning

(K2) Forstå og giv eksempler på de faktorer, der er angivet i syllabus, og som kan føre til unøjagtigheder i estimaterne

3.5 Planlægning af testplanlægningen

(K2) Forklar fordelene ved tidlig og iterativ testplanlægning. Understøt forklaringen med eksempler

3.6 Overvågning og kontrol af testfremdrift

(K2) Sammenlign de forskellige procedurer til kontrol af testfremdrift

(K2) Giv mindst 5 begrebsmæssigt forskellige eksempler på, hvordan observationer vedr. testfremdriften kan påvirke testprocessens forløb

(K4) Brug observationer vedrørende testfremdrift gjort under overvågnings- og kontrolaktiviteter og måleresultater til at skitsere en handlingsplan til forbedring af den aktuelle testproces. Foreslå forbedringer

(K4) Analysér testresultater, og fastslå testfremdriften, der dokumenteres i en overvågningsrapport og en endelig testopsummeringsrapport, der dækker alle 4 rapporteringsdimensioner

3.7 Forretningsværdien af test

(K2) Giv eksempler (måleresultater) for hver af de 4 kategorier, der bestemmer "omkostningen ved kvalitet".

(K3) List de kvantitative og/eller kvalitative værdier, der er gældende i en given sammenhæng

3.8 Distribueret, outsourcet og insourcet test

(K2) List risici, ligheder og forskelle mellem 3 forskellige strategier (distribueret, outsourcet og insourcet test)

3.9 Risikobaseret test

3.9.1 Introduktion til risikobaseret test

(K2) Forklar de forskellige måder risikobaseret test behandler risici på

(K4) Identificer risici i et projekt og et produkt, og fastlæg den passende teststrategi og testplan på basis af disse risici

3.9.2 Risikostyring

(K3) Udfør en risikoanalyse for produktet fra en testers synspunkt, idet du følger den specifikke FMEA-metode

(K4) Opsummer resultaterne ud fra de forskellige risikosynsvinkler, som vigtige projektinteressenter har, og brug deres kollektive vurdering til at skitsere testaktiviteter, der kan afbøde risici

3.9.3 Risikostyring i livscyklussen

(K2) Beskriv karakteristika ved risikostyring, der kræver, at det er en iterativ proces

(K3) Oversæt en given risikobaseret teststrategi til testaktiviteter, og overvåg dens effekt under testen

(K4) Analyser og rapporter testresultater og fastlæg/foreslå residualrisici, så projektlederne bliver i stand til at tage intelligente beslutninger om frigivelse

3.10 Failure Mode and Effects Analysis

(K2) Beskriv begreberne i FMEA, forklar det anvendelse i projekter og fordele for projekter ved hjælp af eksempler

3.11 Problemer med teststyring

(K2) Sammenlign problemerne med teststyring ved udforskende test, systemer af systemer og test af sikkerhedskritiske systemer med hensyn til strategi, fordele og ulemper, tilstrækkelighed og deres effekt på planlægning, dækning og overvågning og kontrol





Kapitel 4: Testteknikker – [0 minutter]

Der gælder ingen læringsmål (på noget K-niveau) for testansvarlige.

Kapitel 5: Test af softwarekarakteristika – [0 minutter]

Der gælder ingen læringsmål (på noget K-niveau) for testansvarlige.

Kapitel 6: Reviews – [120 minutter]

6.2 Principperne for reviews

(K2) Forklar fordelene ved reviews sammenlignet med dynamisk test og andre statiske testteknikker

6.4 Indførelse af reviews

(K2) Sammenlign reviewtyper med hinanden, og vis deres relative styrke, svagheder og anvendelsesområder.

(K3) Før et reviewteam gennem et formelt review idet de fastlagte trin følges.

(K4) Skitsér en reviewplan som en del af en kvalitets-/testplan for et projekt, idet reviewteknikker overvejes i forhold til de fejl, der skal findes, de tilgængelige medarbejderkvalifikationer og afstemt med passende dynamiske testmetoder

6.5 Succesfaktorer for reviews

(K2) Forklar risiciene ved ikke at overveje de tekniske og organisatoriske faktorer og menneskelige aspekter ved gennemførelse af reviews.

Kapitel 7: Hændelseshåndtering – [80 minutter]

(K3) Behandl en defekt ved at følge livscyklus proceduren for hændelseshåndtering foreslået i IEEE Standard 1044-1993

(K3) Evaluer defektrapporter i forhold til IEEE Standard 1044-1993 og den anvendte defekttaksonomi for at forbedre deres kvalitet.

(K4) Analysér de fejlrapporter, der er oprettet over tid, og opdater defekttaksonomien

Kapitel 8: Standarder og testforbedringsproces – [120 minutter]

(K2) Opsummer kilderne til softwarestandarder, og forklar deres værdi for softwaretest

8.4 Forbedring af testprocesserne

(K3) Skriv en testforbedringsplan ved hjælp af de generiske trin, og omfattende de rigtige personer

(K2) Opsummer testforbedringsprocessen, som defineret i TMM, TPI, CTP, STEP og procesområderne verificering og validering i CMMI

(K2) Forklar evalueringskriterierne i testforbedringsmodellerne TMM, TPI, CTP, STEP og procesområderne verificering og validering i CMMI

Kapitel 9: Testværktøjer og -automatisering – [90 minutter]

9.2 Testværktøjskoncepter

(K2) Sammenlign elementerne og aspekterne i hvert af testværktøjskoncepterne "Fordele og risici", "Testværktøjsstrategier", "Værktøjsintegration", "Automatiseringssprog", "Testorakler", "Værktøjsanvendelse", "Open Source-værktøjer", "Værktøjsudvikling" og "Værktøjsklassifikation"

(K2) Beskriv, hvorfor og hvornår det er vigtigt at skrive en testværktøjsstrategi eller langtidsplan for testværktøj

(K2) Forstå de forskellige faser i indførelse af testværktøj

9.3 Testværktøjskategorier

(K2) Opsummér testværktøjskategorierne efter mål, tiltænkt anvendelse, styrker, risici og giv eksempler

(K2) Opsummér de specifikke krav til testværktøjer og open source-testværktøjer, der bruges til test af sikkerhedskritiske systemer

(K2) Beskriv vigtige aspekter og konsekvenser af forskellige testværktøjer og deres indførelse, brug og virkninger på testprocessen.

(K2) Beskriv, hvornår og hvorfor man kan vælge at udvikle sit eget værktøj, og fordele, risici og konsekvenser ved denne løsning.





Kapitel 10: Personlige evner – gruppesammensætning – [240 minutter]

10.2 Individuelle evner

(K3) Brug et givet spørgeskema til at fastlægge gruppemedlemmernes styrker og svagheder i relation til brug af softwaresystemer, domæne- og forretningsviden, områder indenfor systemudvikling, softwaretest og mellemmenneskelige evner

10.3Testgruppedynamik

(K3) Udfør en forskelsanalyse for at fastlægge de tekniske og adfærdsmæssige evner, der kræves til ledige stillinger i en organisation.

10.4 Indpasning af test i en organisation

(K2) Karakteriser de forskellige organisatoriske muligheder, og sammenlign dem med in-/outsourcing og in-/offshoring.

10.5 Motivation

(K2) Giv eksempler på faktorer, der motiverer henholdsvis demotiverer testere

10.6 Kommunikation

(K2) Beskriv ved hjælp af et eksempel professionel, objektiv og effektiv kommunikation i et projekt fra testerens synspunkt. Risici og muligheder kan overvejes.





0.5 Undervisningsmål for testanalytikere Dette afsnit indeholder en liste over detaljerede undervisningsmål for testanalytiker-modulet. Generelt er alle dele af denne syllabus på K1-niveau. Det vil sige, at kandidaten genkender, husker og kan genkalde sig en term eller et begreb. Derfor indeholder tabellen nedenfor kun undervisningsmål for K2-, K3- og K4-niveauerne.

Introduktion til syllabus for testanalytikere – [60 minutter]

(inklusive revision af syllabus for Foundation level fra ISTQB®) Kapitel 1: Grundlæggende aspekter ved softwaretest – [30 minutter]


2.4 Testanalyse og -design

(K2) Forklar årsagerne til den funktionelle test, der finder sted på bestemte stadier af et programs livscyklus

(K2) Eksemplificer de kriterier, der påvirker strukturen og niveauet i udvikling af testbetingelser

(K2) Beskriv, hvordan testanalyse og -design er statiske testteknikker, der kan bruges til at finde defekter

(K2) Forklar ved hjælp af eksempler begrebet testorakler, og hvordan et testorakel kan bruges i testspecifikationer


(K2) Beskriv startbetingelserne for testafvikling, herunder: test-delprodukter, testmiljø, konfigurationsstyring og defekthåndtering

2.6 Evaluering af afslutningskriterier og rapportering

(K3) Fastslå ud fra et givet sæt af måleresultater, om et testafslutningskriterium er opfyldt.



(K3) Prioriter udvælgelsen af testcases, testdækning og testdata på basis af risici, og dokumentér dette på passende måde i en testtidsplan og i testprocedurer

(K2) Skitsér aktiviteterne i en risikobaseret tilgang til planlægning og afvikling af domænetest


4.2 Specifikationsbaseret

(K2) List eksempler på typiske defekter, der identificeres af hver specifik specifikationsbaseret teknik, angiv tilhørende dækningskriterier

(K3) Skriv testcases fra givne softwaremodeller ved brug af de følgende testdesignteknikker (Testene skal opnå en given modeldækning)

o Ækvivalenspartitionering o Grænseværdianalyse o Beslutningstabeller o Tilstandsovergangstest o Klassifikationstræmetode o Parvis test o Usecases

(K4) Analysér et system, eller dets kravspecifikation, for at bestemme, hvilke specifikationsbaserede teknikker der skal anvendes til specifikke mål, og skitsér en testspecifikation baseret på IEEE 829, der fokuserer på funktionelle og domænebaserede testcases og testprocedurer





4.4 Defekt- og erfaringsbaseret

(K2) Beskriv principperne bag og årsagerne til defektbaserede teknikker, og adskil deres anvendelse fra specifikations- og strukturbaserede teknikker

(K2) Forklar defekttaksonomier og deres anvendelse ved hjælp af eksempler

(K2) Forstå principperne bag og årsagerne til brug af erfaringsbaserede teknikker, og hvornår de kan bruges

(K3) Specificer, afvikl og rapporter tests ved brug af udforskende test

(K2) Klassificer defekter, der identificeres af de forskellige typer af softwarefejlangreb, efter de fejl, de er rettet mod

(K4) Analysér et system for at bestemme, hvilke specifikationsbaserede, defektbaserede eller erfaringsbaserede teknikker, der kan anvendes til specifikke mål.


5.2 Kvalitetsattributter for domænetest

(K4) Forklar ved hjælp af eksempler, hvilke af testteknikkerne, som er anført i kapitel 4, der passer til test af nøjagtigheds-, egnetheds-, tværoperationalitets-, funktionel sikkerheds- og tilgængelighedskarakteristika.

(K3) Skitsér, design, specificer og afvikl brugervenlighedstests idet der bruges passende teknikker og givne testmål og fejl, der skal testes for, dækkes.

5.3 Kvalitetsattributter ved teknisk test

(K2) Forklar grundene til at medtage test af effektivitet, pålidelighed og teknisk sikkerhed i en teststrategi, og giv eksempler på de defekter, der forventes at blive fundet

(K2) Karakteriser ikke-funktionelle testtyper til teknisk test ud fra de typiske defekter, der skal testes for (angribes), den typiske anvendelse inden for programmets livscyklus og de testteknikker, der egner sig til at blive brugt til testdesign.


(K3) Brug en review-checkliste til at verificere kode og arkitektur fra en testers synsvinkel

(K3) Brug en review-checkliste til at verificere krav og usecases fra en testers synsvinkel



(K4) Analysér, klassificer og beskriv funktionelle og ikke-funktionelle defekter i forståelige defektrapporter

Kapitel 8: Standarder og testforbedringsprocessen – [0 minutter]

Der gælder ingen undervisningsmål (på noget K-niveau) for testanalytikere.

Kapitel 9: Testværktøjer og -automatisering – [90 minutter]


(K2) Sammenlign elementerne og aspekterne i hvert af testværktøjskoncepterne "Fordele og risici", "Testværktøjsstrategier", "Værktøjsintegration", "Automatiseringssprog", "Testorakler", "Værktøjsanvendelse", "Open Source-værktøjer", "Værktøjsudvikling" og "Værktøjsklassifikation"


(K2) Opsummér testværktøjskategorierne efter mål, tiltænkt anvendelse, styrker, risici og giv eksempler

(K2) Map værktøjerne i værktøjskategorierne til forskellige testniveauer og -typer

Kapitel 10: Personlige evner – gruppesammensætning – [30 minutter]

10.6 Kommunikation

(K2) Beskriv ved hjælp af eksempler professionel, objektiv og effektiv kommunikation i et projekt fra en testsynsvinkel. Du kan overveje risici og muligheder.





0.6 Undervisningsmål for tekniske testanalytikere Dette afsnit indeholder en liste over detaljerede undervisningsmål for modulet for tekniske testanalytikere. Generelt er alle dele af denne syllabus på K1-niveau. Det vil sige, at kandidaten genkender og husker en term eller et begreb. Derfor indeholder tabellen nedenfor kun undervisningsmål for K2-, K3- og K4-niveauerne.

Introduktion til syllabus for tekniske testanalytikere – [60 minutter]

(inklusive revision af syllabus for Foundation level fra ISTQB®) Kapitel 1: Basale aspekter ved softwaretest – [30 minutter]


2.4 Testanalyse og -design

(K2) Forklar om de stadier i et programs livscyklus, hvor ikke-funktionelle tests og arkitekturbaserede tests kan anvendes. (K2) Forklar årsagerne til den ikke-funktionelle test, der kun finder sted på bestemte stadier af et programs livscyklus

(K2) Eksemplificer de kriterier, der påvirker strukturen og niveauet i udvikling af testbetingelser

(K2) Beskriv, hvordan testanalyse og -design er statiske testteknikker, der kan bruges til at afsløre fejl

(K2) Forklar ved hjælp af eksempler begrebet testorakler, og hvordan et testorakel kan bruges i testspecifikationer

2.5 Testimplementering og -udførelse

(K2) Beskriv de betingelser, der skal være opfyldt, før testen udføres, herunder: test-delprodukter, testmiljø, konfigurationsstyring og fejlhåndtering

2.6 Evaluering af afslutningskriterier og rapportering

(K3) Fastslå ud fra et givet sæt af målinger, om et testafslutningskriterium er opfyldt.


3.9.2 Risikostyring

• ((K2) Skitsér aktiviteterne i en risikobaseret metode for planlægning og udførelse af domænetest


4.2 Specifikationsbaseret

(K2) List eksempler på typiske fejl, der skal identificeres af hver specifik specifikationsbaseret teknik

(K3) Skriv testcases fra en given softwaremodel fra det virkelige liv ved brug af de følgende teknikker til testdesign (Testene skal opnå en given modeldækning)

o Ækvivalenspartitionering o Grænseværdianalyse o Beslutningstabeller o Tilstandsovergangstest

(K4) Analysér et system, eller dets kravspecifikation, for at bestemme, hvilke specifikationsbaserede teknikker der skal anvendes til specifikke mål, og skitsér en testspecifikation baseret på IEEE 829, der fokuserer på komponent og ikke-funktionelle testcases og testprocedurer

4.3 Strukturbaseret

(K2) List eksempler på typiske fejl, der skal identificeres af hver specifik specifikationsbaseret teknik

(K3) Skriv reelle testcases ved brug af de følgende teknikker til testdesign (Testene skal opnå en given modeldækning)

o Instruktionstest o Beslutningstest o Bestemmende betingelsestest o Multibetingelsestest

(K4) Analysér et system for at bestemme, hvilke strukturbaserede teknikker der skal anvendes til specifikke testmål.

(K2) Forstå hver strukturbaseret teknik og dens tilhørende dækningskriterium, og hvornår du skal bruge den





(K4) Være i stand til at sammenligne og analysere hvilke strukturbaserede teknikker, der skal anvendes i forskellige situationer

4.4 Fejl- og erfaringsbaseret

(K2) Beskriv principperne bag og årsagerne til fejlbaserede teknikker, og adskil deres anvendelse fra specifikations- og strukturbaserede teknikker

(K2) Forklar ved hjælp af eksempler fejltaksonomier og deres anvendelse

(K2) Forstå principperne bag og årsagerne til at bruge erfaringsbaserede teknikker, og hvornår de skal bruges

(K3) Angiv, udfør og rapporter test ved brug af udforskende test

(K2) Angiv tests ved brug af de forskellige typer softwarefejlangreb efter de fejl, de er rettet mod

(K4) Analysér et system for at bestemme, hvilke specifikationsbaserede, fejlbaserede eller erfaringsbaserede teknikker, der skal anvendes til specifikke mål.

4.5 Statisk analyse

(K3) Brug algoritmerne “Kontrolflowanalyse” og “Dataflowanalyse” til at verificere, at der i programkoden ikke er nogen uregelmæssigheder i kontrol- eller dataflow (K4) Fortolk kontrol- og dataflowresultaterne, der kommer fra et værktøj, for at vurdere om koden har uregelmæssigheder i kontrol- eller dataflow (K2) Forklar brugen af kald-grafer til evaluering af kvaliteten i arkitekturen. Dette skal omfatte de fejl, der skal identificeres, behovet for testdesign og testplanlægning, begrænsninger af resultater

4.6 Dynamisk analyse

(K2) Forklar, hvordan dynamisk analyse af kode kan udføres, og opsummér, hvilke fejl der kan identificeres med denne teknik og dens begrænsninger


5.2 Kvalitetsattributter ved domænetest

(K2) Karakteriser ikke-funktionelle testtyper til domænetest ud fra de typiske fejl, der skal findes (angribes), den typiske anvendelse inden for programmets livscyklus og de testteknikker, der egner sig til at blive brugt til testdesign.

(K4) Angiv testcases for bestemte typer af ikke-funktionelle testtyper, og gennemgå de givne testmål og -fejl, der skal undersøges for.

5.3 Kvalitetsattributter ved teknisk test

(K2) Karakteriser ikke-funktionelle testtyper til teknisk test ud fra de typiske fejl, der skal findes (angribes), den typiske anvendelse inden for programmets livscyklus og de testteknikker, der egner sig til at blive brugt til testdesign.

(K2) Forstå og forklar, på hvilke stadier i et programs livscyklus der kan anvendes sikkerheds-, pålideligheds- og effektivitetstests (herunder de tilhørende ISO9126-underattributter)

(K2) Skeln mellem de fejltyper, der findes af sikkerheds-, pålideligheds- og effektivitetstests (herunder de tilhørende ISO9126-underattributter)

(K2) Karakteriser testmetoderne for kvalitetsattributterne for sikkerhed, pålidelighed og effektivitet og deres tilhørende ISO9126-underattributter.

(K3) Angiv testcases for kvalitetsattributterne for sikkerhed, pålidelighed og effektivitet og deres tilhørende ISO9126-underattributter.

(K2) Forstå og forklar årsagerne til, at tests af vedligeholdelsesegnethed, flytbarhed og adgang skal inkluderes i en teststrategi

(K3) Angiv testcases for ikke-funktionelle typer af test af vedligeholdelsesegnethed og flytbarhed


(K4) Skitsér en review-checkliste for at finde typiske fejl, der skal findes under review af kode og arkitektur







(K4) Analysér, klassificer og beskriv funktionelle og ikke-funktionelle fejl i forståelige fejlrapporter

Kapitel 8: Standarder og testforbedringsprocessen – [0 minutter]

Der gælder ingen undervisningsmål (på noget K-niveau) for tekniske testanalytikere.

Kapitel 9: Testværktøjer og -automation – [210 minutter]


(K2) Sammenlign elementerne og aspekterne i hvert af testværktøjskoncepterne "Fordele og risici", "Testværktøjsstrategier", "Værktøjsintegration", "Automatiseringssprog", "Testorakler", "Værktøjsopstilling", "Open Source-værktøjer", "Værktøjsudvikling" og "Værktøjsklassifikation"


(K2) Opsummér testværktøjskategorierne efter mål, tiltænkt anvendelse, styrker, risici og eksempler

(K2) Knyt værktøjerne i værktøjskategorierne til forskellige testniveauer og -typer

9.3.7 Nøgleordsdrevet testautomation

(K3) Fremstil nøgleords-/handlingsordstabeller, der skal bruges af et testafviklingsværktøj, ved brug af algoritmen til nøgleordsvalg

(K3) Optag tests med optage-/afspilleværktøjer for at muliggøre regressiontest af høj kvalitet, der dækker mange testcases inden for en kort tidsramme

9.3.8 Performancetestværktøjer

(K3) Design en performancetest ved brug af performancetestværktøjer inklusive planlægning og måling af systemkarakteristika

Kapitel 10: Medarbejderkvalifikationer – teamsammensætning – [30 minutter]

10.6 Kommunikation

(K2) Beskriv ved hjælp af et eksempel professionel, objektiv og effektiv kommunikation i et projekt fra testerens synspunkt. Du kan overveje risici og muligheder.





1. Grundlæggende aspekter ved softwaretest Termer: Etik, måling, metrik, sikkerhedskritiske systemer, system af systemer, software-livscyklus.

1.1 Introduktion Dette kapitel introducerer nogle centrale testtemaer, der har generel relevans for alle, der arbejder professionelt med test, uanset om det er som testansvarlige, testanalytikere eller tekniske testanalytikere. Undervisere skal forklare disse generelle temaer ud fra konteksten i det modul, der undervises i, og give relevante eksempler. For eksempel skal der i modulet “Teknisk testanalytiker” i det generelle tema om “metrikker og mål” (afsnit 1.4) bruges eksempler på specifikke tekniske metrikker, f.eks. performancemålinger. I afsnit 1.2 betragtes testprocessen som en del af hele softwareudviklings-livscyklussen. Dette tema bygger på de grundlæggende begreber, der er introduceret i Foundation Syllabus, og lægger speciel vægt på indpasningen af testprocessen i softwareudviklings-livscyklusmodeller og i andre it-processer. Systemer kan antage mange forskellige former, der kan have en væsentlig indflydelse på, hvordan test gribes an. I afsnit 1.3 introduceres der to specifikke typer af systemer, som alle testere skal være opmærksomme på: systemer af systemer (nogle gange kaldet "multisystemer”) og sikkerhedskritiske systemer. Avancerede testere står over for mange udfordringer, når de skal introducere de forskellige testaspekter, der er beskrevet i denne syllabus, i deres egne organisationer, grupper og opgaver.

1.2 Test i software-livscyklen Test er en integreret del af de forskellige softwareudviklingsmodeller, f.eks.:

sekventiel (vandfaldsmodel, V-model og W-model)

iterativ (RAD (Rapid Application Development) og Spiral-model)

inkrementel (evolutionære og Agile metoder). Den langsigtede livscyklustilgang til test bør overvejes og defineres som en del af teststrategien. Dette inkluderer organisering, definition af processer og valg af værktøjer eller metoder. Testprocesser udføres ikke i isolation, men er forbundet og relateret til andre processer, f.eks.:

Udarbejdelse og styring af krav

Projektledelse

Konfigurations- og ændringsstyring

Softwareudvikling

Softwarevedligeholdelse

Teknisk support

Produktion af teknisk dokumentation. Tidlig testplanlægning og den senere testudførelse er forbundet i de sekventielle softwareudviklingsmodeller. Testopgaver kan overlappe og/eller være sideløbende. Ændrings- og konfigurationsstyring er vigtige støtteopgaver for softwaretest. Uden en ordentlig ændringsstyring kan virkningen af ændringer af systemet ikke vurderes. Uden konfigurationsstyring kan sideløbende udviklingsversioner gå tabt eller blive håndteret forkert. Afhængigt af projektsammenhængen kan der også defineres flere testniveauer end dem, der er defineret i Foundation Level Syllabus, f.eks.:





Hardware-/softwareintegrationtest

Systemintegrationtest

Egenskabsinteraktiontest

Kundeproduktintegrationtest. Hvert testniveau har følgende karakteristika:

testmål

testomfang

sporbarhed til testgrundlag

start- og slutkriterier

testleverancer inklusive rapportering

testteknikker

målinger og metrikker

testværktøjer

overensstemmelse med organisationens eller andre standarder. Afhængigt af sammenhængen kan mål og omfang for hvert testniveau betragtes isoleret eller på projektniveau (f.eks. for at undgå unødvendig duplikering af ensartede tests på tværs af forskellige niveauer). Testaktiviteter skal indpasses i den valgte softwareudviklings-livcyklusmodel, der kan være sekventiel (f.eks. Vandfald, V-model og W-model), iterativ (f.eks. RAD (Rapid Application Development) og Spiral model) eller Inkrementel (f.eks. evolutionære og Agile metoder). I V-modellen for eksempel kan anvendelsen af den grundlæggende ISTQB®-testproces på systemtestniveauet indpasses på følgende måde:

Planlægning af systemtest sker samtidig med projektplanlægning, og testkontrollen fortsætter, indtil afvikling og afslutning af systemtest er fuldført.

Analyse og design af systemtest sker samtidig med udarbejdelse af kravspecifikation, designspecifikation for system og (høj niveau) arkitektur og designspecifikation for komponenter (lav niveau).

Implementeringen af systemtestmiljøet (f.eks. testbænke og testrig) kan muligvis starte under systemdesignet, selv om hovedparten af den typisk sker sideløbende med kodning og komponenttest, idet arbejdet med implementeringsaktiviteterne i forbindelse med systemtesten ofte strækker sig indtil få dage før starten af systemtestafviklingen.

Afviklingen af systemtesten begynder, når alle startkriterierne for systemtesten er opfyldt (eller opgivet), hvilket typisk betyder, at i det mindste komponenttest og ofte også komponentintegrationstest er fuldført. Systemtestafviklingen fortsætter, indtil slutkriterierne for systemtesten er opfyldt.

Evalueringen af slutkriterierne for systemtesten og rapporteringen af systemtestresultaterne sker under hele systemtestafviklingen, generelt med højere frekvens og større vigtighed, når deadline for projektet nærmer sig.

Systemtestens afslutningsaktiviteter foregår ofte, efter at slutkriterierne for systemtesten er opfyldt, og afviklingen af systemtesten er fuldført, selv om de nogle gange kan blive forsinket, til efter afslutningen af accepttesten og alle projektaktiviteter.

For hvert testniveau og for hver valgt kombination af softwarelivscyklus og testproces skal den testansvarlige udføre denne indpasning under testplanlægningen og/eller projektplanlægningen. Ved særligt komplekse projekter, f.eks. projekter med systemer af systemer (almindelige i militæret og i store virksomheder), skal testprocesserne ikke kun indpasses, de skal også ændres, så de passer til projektets sammenhæng (f.eks. når det er lettere at opdage en defekt på et højere niveau end på et lavere niveau).





1.3 Specifikke systemer

1.3.1 Systemer af systemer Et system af systemer er et sæt af samarbejdende komponenter (inklusive hardware, individuelle softwareprogrammer og kommunikationsveje), der er indbyrdes forbundet for at opfylde et fælles formål uden en entydig styringsstruktur. De karakteristika og risici, der er forbundet med systemer af systemer, inkluderer:

Progressiv sammenfletning af de uafhængige, samarbejdende systemer for at undgå at hele systemet skal fremstilles fra scratch. Dette kan f.eks. opnås ved at integrere COTS-systemer med kun begrænset yderligere udvikling.

Teknisk og organisatorisk kompleksitet (f.eks. mellem de forskellige interesser) udgør risici for effektiv styring. Der anvendes muligvis forskellige udviklingslivscyklusmodeller for de medvirkende systemer, hvilket kan føre til kommunikationsproblemer mellem de forskellige involverede grupper (udvikling, test, fremstilling, samlebånd, brugere etc.). Den overordnede styring af systemer af systemer skal være i stand til at håndtere den tekniske kompleksitet der følger med sammenkoblingen af de forskellige medvirkende systemer og være i stand til at håndtere forskellige organisatoriske problemer, så som outsourcing og offshoring.

Fortrolighed og beskyttelse af specifik knowhow, grænseflader mellem forskellige organisationer (f.eks. den offentlige og den private sektor) eller lovgivningsmæssige beslutninger (f.eks. forbund mod monopolistisk opførsel) kan betyde, at et komplekst system skal opfattes som et system af systemer.

Systemer af systemer er grundlæggende mindre pålidelige end individuelle systemer, da enhver begrænsning fra ét (under)system automatisk gælder for hele systemer af systemer.

Det høje niveau af teknisk og funktionel tværoperationalitet, der kræves af de enkelte komponenter i et system af systemer, medfører, at integrationstest er af kritisk betydning, og kræver velspecificerede og aftalte grænseflader.

1.3.1.1 Styring og test af systemer af systemer

Et højere kompleksitetsniveau for projektledelse og styring af komponentkonfiguration er almindelige problemer i forbindelse med systemer af systemer. Komplekse systemer og systemer af systemer forbindes normalt med en høj grad af kvalitetssikring og definerede processer. Formel udviklingslivscyklus, milepæle og review forbindes ofte med systemer af systemer.

1.3.1.2 Livscyklusegenskaber for systemer af systemer

Hvert testniveau for et system af systemer har følgende karakteristika i tillæg til dem, der er beskrevet i afsnittet 1.2 Test i software-livscyklen:

Flere integrationsniveauer og niveauer af versionsstyring

Lang projektvarighed

Formel overførsel af information mellem projektdeltagerne

Ikke-samtidig udvikling af komponenter og krav om regressionstest på system af systemer-niveau

Vedligeholdelsestest på grund af udskiftning af individuelle komponenter, der er blevet overflødige eller er blevet opgraderet.

I systemer af systemer skal et testniveau overvejes på det pågældende detaljeringsniveau og på højere integrationsniveauer. For eksempel kan “Systemtestniveau” for et element betragtes som "komponenttestniveau“ for en komponent på et højere niveau. Normalt går hvert enkelt system (i et system af systemer) gennem alle testniveauer og integreres derefter i et system af systemer med den tilknyttede ekstra test, der kræves. Se afsnit 3.11.2. for styringsproblemer specifikke for systemer af systemer.





1.3.2 Sikkerhedskritiske systemer "Sikkerhedskritiske systemer" er de systemer, hvor driftsstop eller begrænset drift (f.eks. som følge af en forkert eller utilsigtet handling) kan have katastrofale eller kritiske konsekvenser, Leverandøren af det sikkerhedskritiske system er muligvis ansvarlig for skade eller erstatning, og testaktiviteterne bruges derfor til at reducere dette ansvar. Testaktiviteterne skal producere bevis for, at systemet er blevet testet tilstrækkeligt for at undgå katastrofale eller kritiske konsekvenser. Eksempler på sikkerhedskritiske systemer inkluderer systemer til flykontrol, automatiske handelssystemer, centrale reguleringssystemer i atomkraftværker, medicinske systemer etc. Følgende aspekter bør være implementeret i sikkerhedskritiske systemer:

Sporbarhed i forhold til lovmæssige krav og krav om overensstemmelse

Streng tilgang til udvikling og test

Sikkerhedsanalyse

Redundant arkitektur og kontrol af disse

Fokus på kvalitet

Højt dokumentationsniveau (dybde og bredde i dokumentationen)

Højere niveau af revisionsmulighed. Afsnit 3.11.3 gennemgår problemerne med teststyring i relation til sikkerhedskritiske systemer.

1.3.2.1 Overholdelse af lovgivning

Sikkerhedskritiske systemer berøres ofte af offentlige, internationale eller branchespecifikke regler eller standarder (se også 8.2 Overvejelser om standarder). Disse kan gælde for udviklingsprocessen og den organisatoriske struktur, eller for det produkt, der udvikles. Til at vise overensstemmelse med den organisatoriske struktur og med udviklingsprocessen kan revision og organisationsdiagrammer være tilstrækkeligt. Til at vise, at det udviklede system (produkt) overholder specifikke love, er det nødvendigt at vise, at ethvert krav i disse love er tilstrækkeligt opfyldt. I disse tilfælde er fuld sporbarhed fra lovkrav til dokumentation nødvendigt for at vise opfyldelse. Dette påvirker styring, udviklingslivscyklus, testaktiviteter og kvalificering/certificering (udført af en godkendt myndighed) gennem hele udviklingsprocessen.

1.3.2.2 Sikkerhedskritiske systemer og kompleksitet

Mange komplekse systemer og systemer af systemer har sikkerhedskritiske komponenter. Nogle gange er sikkerhedsaspektet ikke åbenlyst på systemniveauet (eller delsystemniveauet), men kun på et højere niveau, når komplekse systemer implementeres (f.eks. operationel flyelektronik til luftfartøjer eller systemer til kontrol af lufttrafik). Eksempel: En router er ikke et kritisk system i sig selv, men den kan muligvis blive det, når den skal bruges til kritiske informationer, f.eks. i telemedicinske ydelser. Risikostyring, der reducerer sandsynligheden og/eller effekten af en risiko, er essentiel i forbindelse med sikkerhedskritisk udvikling og test (se kapitel 3). Desuden bruges Failure Mode and Effect Analysis (FMEA) (se afsnit 3.10) og analyse af normale årsager til softwarefejl ofte i sådanne sammenhænge.





1.4 Metrikker og måling Et udvalg af metrikker (tal) og målinger (tendenser, grafer etc.) bør benyttes gennem softwareudviklingslivscyklussen (f.eks. planlægning, dækning, arbejdsbelastning etc.). I hvert tilfælde skal der defineres en baseline, og derefter skal fremdrift registreres i forhold til denne baseline. Aspekter, der kan dækkes, inkluderer: 1. Tidsplan, dækning og deres udviklingen over tid 2. Krav, deres udvikling og deres indvirkning med hensyn til tidsplan, ressourcer og opgaver 3. Belastning og ressourceforbrug og deres udvikling over tid 4. Milepæle og omfang og deres udvikling over tid 5. Omkostninger, faktiske og planlagte til færdiggørelse af opgaverne 6. Risici og formildende handlinger og deres udvikling over tid 7. Fundne defekter, rettede defekter og varighed af rettelse. Brug af metrikker giver testere mulighed for at rapportere data på en konsistent måde til deres ledelse, og gør det muligt at foretage en sammenhængende opfølgning på fremdrift over tid. Tre områder skal tages i betragtning:

Definition af metrikker: Der bør defineres et begrænset sæt af brugbare metrikker. Når disse metrikker er blevet defineret, skal der opnås enighed om deres fortolkning med alle interessenter for at undgå fremtidige diskussioner når metrikværdierne udvikler sig. Metrikker kan defineres i forhold til målet for en proces eller opgave, for komponenter eller systemer og for enkeltpersoner eller grupper. Der er ofte en tendens til at definere for mange metrikker i stedet for at vælge de vigtigste.

Opfølgning på metrikker: Rapportering og sammenstilling af metrikker skal være så automatiseret som muligt for at reducere den tid, der bruges på at producere de rå metrikværdier. Variationer af data over tid for en specifik metrik kan reflekterer anden information, end den fortolkning, der var enighed om i metrikkens definitionsfase.

Rapportering af metrikker: Målet er at sørge for øjeblikkelig forståelse af informationerne til styringsformål. Præsentationer kan vise et øjebliksbillede af metrikkerne på et bestemt tidspunkt eller vise udviklingen af metrikken eller metrikkerne over tid, så tendenser kan vurderes.

1.5 Etik Deltagelse i softwaretest giver enkeltpersoner mulighed for at få indblik i fortrolige og interne oplysninger. Etiske regler er nødvendige blandt andet for at sikre, at oplysningerne ikke bruges på en upassende måde. Samtidig med at de etiske regler for teknikere i ACM og IEEE anerkendes, angiver ISTQB® følgende etiske regler:

OFFENTLIGHEDEN – Certificerede softwaretestere skal agere i overensstemmelse med offentlighedens interesser.

KLIENT OG ARBEJDSGIVER – Certificerede softwaretestere skal agere på en måde, der bedst muligt tager hensyn til deres klients og arbejdsgivers interesser og er konsistent med offentlighedens interesser.

PRODUKT – Certificerede softwaretestere skal sikre, at de leverancer, de udarbejder (om de produkter og systemer, de tester), opfylder de højest mulige professionelle standarder.

VURDERING – Certificerede softwaretestere skal opretholde integritet og uafhængighed i deres professionelle vurdering.

STYRING – Certificerede softwaretestansvarlige og -ledere skal bidrage med og fremme en etisk tilgang til styring af softwaretest.

ERHVERV– Certificerede softwaretestere skal fremme erhvervets integritet og ry i overensstemmelse med offentlighedens interesse.

KOLLEGAER – Certificerede softwaretestere skal være fair og støttende over for deres kollegaer og fremme samarbejdet med softwareudviklerne.

PERSONLIGT – Certificerede softwaretestere skal deltage i livslang indlæring med hensyn til udøvelsen af deres erhverv, og de skal fremme en etisk tilgang til udøvelsen af erhvervet.





2. Testprocesser

Termer: BS 7925/2, slutkriterium, IEEE 829, testcase, testlukning, testbetingelse, testkontrol, testdesign, testafvikling, testimplementering, testplanlægning, testprocedure, testscript, testopsummeringsrapport, testlog.

2.1 Introduktion I ISTQB® Foundation Level Syllabus var følgende grundlæggende testproces beskrevet omfattende følgende aktiviteter:

Planlægning og kontrol

Analyse og design

Implementering og afvikling

Evaluering af slutkriterier og rapportering

Testlukningsaktiviteter. Disse aktiviteter kan implementeres sekventielt, eller nogle af dem kan implementeres parallelt, f.eks. kan analyse og design implementeres parallelt med implementering og afvikling, mens de andre aktiviteter kan implementeres sekventielt. Da teststyring fundamentalt er relateret til testprocessen, skal den testansvarlig være i stand til at anvende alt indhold i dette afsnit i styringen af et specifikt projekt. Hvad angår testanalytikere og tekniske testanalytikere, er den viden, der er opnået på Foundation-niveauet, stort set tilstrækkelig, med undtagelse af de testudviklingsopgaver, der er angivet ovenfor. Den viden, der kræves til disse opgaver, er dækket generelt i dette afsnit og bliver derefter gennemgået detaljeret i kapitel 4 Testteknikker og kapitel 5 Test af softwarekarakteristika.

2.2 Testprocesmodeller Procesmodeller er tilnærmelser og abstraktioner. Testprocesmodeller indfanger ikke alle de kompleksiteter, nuancer og aktiviteter, der tilsammen udgør et virkeligt projekt eller aktivitet. Modeller skal ses som en hjælp til forståelse og organisering, ikke som den uforanderlige, afslørede sandhed. Denne syllabus bruger den proces, der er beskrevet i ISTQB® Foundations Level Syllabus (se ovenfor), som et eksempel, men der er andre vigtige testprocesmodeller, og eksempler på tre af dem er listet nedenfor. De er alle testprocesmodeller og modeller for testprocesforbedringer (Practical Software Testing indeholder Test Maturity Model), og er defineret ud fra de modenhedsniveauer, de understøtter. Alle tre testprocesmodeller samt TPI®, gennemgås yderligere i afsnit 8.3 Testforbedringsproces.

Practial Software Test – Test Maturity Model [Burnstein03]

Critical Testing Processes [Black03]

Systematic Test and Evaluation Process (STEP).





2.3 Testplanlægning og -kontrol Dette kapitel fokuserer på processerne til planlægning og kontrol af test. Testplanlægning sker oftest ved starten af testarbejdet og omfatter identifikation og implementering af alle de aktiviteter og ressourcer, der kræves for at opfylde den opgave, og de mål, der er beskrevet i teststrategien. Risikobaseret test (se kapitel 3 Teststyring) bruges til at give input til testplanlægningsprocessen om de afbødende aktiviteter, der kræves for at reducere de identificerede produktrisici. Hvis det f.eks. er fastslået, at alvorlige defekter normalt findes i designspecifikationen, kan testplanlægningsprocessen resultere i, at der foretages ekstra statiske tests (reviews) af designspecifikationen, før den overføres til kode. Risikobaseret test giver også input til testplanlægningsprocessen med hensyn til den relative prioritering af testaktiviteterne. Der kan eksistere komplekse relationer mellem testbasis, testbetingelser, testcases og testprocedurer, således at der findes mange-til-mange-relationer mellem disse arbejdsprodukter. Det er nødvendigt at forstå disse for at kunne sørge for, at testplanlægning og -kontrol udføres effektivt. Testkontrol er en løbende aktivitet. Den omfatter sammenligning af den faktiske fremdrift i forhold til planen og statusrapportering, herunder afvigelser fra planen. Testkontrol bruges som vejledning til testen, så opgaven fuldføres og strategierne og målene opfyldes, og testplanlægningsaktiviteterne gentages efter behov. Testkontrollen skal reagere på de oplysninger, der indsamles under testen, såvel som på de skiftende betingelser som et projekt eller en opgave fungerer under. Hvis dynamisk test f.eks. afslører grupper af defekter inden for områder, der ikke forventedes at indeholde mange defekter, eller hvis testafviklingsperioden forkortes på grund af en forsinkelse af teststarten, må risikoanalysen og planen revideres. Dette kan resultere i en omprioritering af tests og en re-allokering af det resterende testarbejde. Indholdet af testplanlægningsdokumenter behandles i kapitel 3 Teststyring. Metrikker til overvågning af testplanlægning og -kontrol kan omfatte:

Risiko- og testdækning

Defektfinding og informationer om defekter

Planlagte i forhold til faktiske timer brugt til at udvikle test-delprodukter og afvikle testcases.

2.4 Testanalyse og -design Under testplanlægning fastlægges et sæt af testmål. I processen med testanalyse og -design bruges disse mål til at:

Identificere testbetingelserne

Fremstille testcases der aktiverer de identificerede testbetingelser. Prioriteringskriterier, identificeret under risikoanalyse og testplanlægning skal anvendes gennem hele processen fra analyse og design til implementering og afvikling.

2.4.1 Identifikation af testbetingelser Testbetingelser identificeres ved analyse af testbasis og målene for at bestemme, hvad der skal testes ved brug af de testteknikker, der er anført i teststrategien og/eller testplanen. Beslutningen om at fastlægge niveauet for og struktureringen af testbetingelserne kan baseres på ,testelementernes funktionelle og ikke-funktionelle funktioner ved brug af følgende:

1. Detaljeringsgraden af testbasis: Krav på højt niveau kan f.eks. indledningsvis generere testbetingelser på højt niveau, som f.eks. Afprøv, at skærmbillede X fungerer, og derfra kan der afledes en testbetingelse





på lavt niveau, f.eks. Afprøv, at skærmbillede X afviser et kontonummer, der er et ciffer kortere end den korrekte længde

2. Adresserede produktrisici: Til en funktion med høj risiko er der f.eks. angivet testbetingelser på lavt niveau som mål

3. Krav til ledelsesrapportering og sporbarhed af information 4. Hvorvidt der er taget beslutning om kun at arbejde med testbetingelser og ikke udvikle testcases, f.eks.

ved at bruge testbetingelserne til at fokusere på uspecificeret test.

2.4.2 Fremstilling af testcases Testcases er designet ved trinvis detaljering og raffinering af de identificerede testbetingelser ved brug af testteknikker (se kapitel 4), der er defineret i teststrategien. De skal være gentagelige, verificerbare og sporbare til kravene. Testcasedesign inkluderer identifikation af:

forudsætningerne, f.eks. krav til enten projekt- eller lokalt testmiljø, og planerne for deres levering

kravene til testdata

de forventede resultater og post-betingelser. Det er ofte en særlig udfordring at definere det forventede resultat af en test, dvs. identifikationen af et eller flere testorakler, der kan bruges til testen. Ved identifikationen af de forventede resultater bekymrer testerne sig ikke kun om output på skærmen, men også om de datamæssige og miljømæssige post-betingelser. Hvis testbasis er klart defineret, er dette teoretisk set enkelt. Men testbasis er ofte uklare, modstridende og mangler dækning af nøgleområder, eller de mangler simpelthen helt. I disse tilfælde skal testeren have, eller have adgang til, ekspertise inden for emnet. Selv når testbasis er veldefineret, kan komplekse virkninger af komplekse input og reaktioner gøre definitionen af forventede resultater vanskelig, derfor er et testorakel essentielt. Testafvikling, der foregår uden nogen mulighed for at bestemme om resultaterne er korrekte, giver meget lav værdi, da der genereres falske hændelsesrapporter og falsk tillid til systemet. De aktiviteter, der er beskrevet ovenfor, kan gælde for alle testniveauer, selvom testbasis varierer. Brugeraccepttest kan f.eks. primært være baseret på kravspecifikationen, usecases og definerede forretningsprocesser, mens komponenttests primært kan være baseret på lavniveau-designspecifikation. Under udviklingen af testbetingelser og testcases udarbejdes der typisk en vis mængde dokumentation, der resulterer i testarbejdsprodukter. IEEE 829 er en standard for denne type dokumentation. Denne standard gennemgår de hovedtyper af dokumenter, der kan bruges til testanalyse og -design, testdesign-specifikation og testcase-specifikation samt til testimplementering. I praksis varierer det meget, i hvilket omfang testarbejdsprodukterne er dokumenteret. Dette kan f.eks. påvirkes af:

Projektrisici (hvad skal/skal ikke dokumenteres)

Den "værditilvækst", som dokumentationen giver til projektet

Standarder, der skal følges

Den anvendte livscyklusmodel (f.eks. forsøger en agil metode at minimere dokumentationen ved at sikre en tæt og hyppig kommunikation i gruppen)

Kravet om sporbarhed fra testbasis gennem testanalyse og -design. Afhængigt af omfanget af testen, kan testanalyse og design fokusere på testobjektets kvalitetsegenskaber. ISO 9126-standarden er en nyttig reference. Ved test af hardware- /softwaresystemer kan yderligere egenskaber være aktuelle. Testanalyse og -designprocessen kan forbedres ved at blande den med reviews og statiske analyse. For eksempel er gennemførelse af testanalyse og testdesign på basis af kravspecifikationen en udmærket måde at forberede et krav-review møde på. På samme måde bør testarbejdsprodukterne, f.eks. tests, risikoanalyser og testplaner, gennemgå review og statiske analyse. Under testdesign kan kravene til den krævede detaljerede infrastruktur muligvis defineres, men i praksis er de muligvis ikke fastlagt før testimplementeringen. Man må huske på, at testinfrastrukturen omfatter mere end





testobjekter og test-delprodukter (f.eks.: lokaler, udstyr, personale, software, værktøjer, perifere enheder, kommunikationsudstyr, brugerautorisationer og alle andre elementer, nødvendige for at køre testene). Metrikker til overvågning af testanalyse og -design kan inkludere:

Procentdel af kravene, der er dækket af testbetingelserne

Procentdel af testbetingelserne, der er dækket af testcases

Antallet af defekter fundet under testanalyse og -design.


2.5.1 Testimplementering Testimplementering omfatter organisering af testcases i testprocedurer (testscripts), endelig fastlæggelse af testdata og testmiljøer, og fremstilling af en testafviklingsplan, så afviklingen af testcases kan begynde. Det omfatter også kontrol af eksplicitte og implicitte startkriterier for det pågældende testniveau. Testprocedurerne skal prioriteres for at sikre, at de mål der er fastlagt i strategien opnås på den mest effektive måde, en tilgang kan f.eks. være at køre de vigtigste testprocedurer først. Detaljeringsniveauet og den tilhørende kompleksitet af arbejdet udført under testimplementeringen kan blive påvirket af detaljeringsgraden af testarbejdsprodukterne (testcases og testbetingelser). I nogle tilfælde gælder der lovmæssige krav, og testene skal godtgøre, at de overholder gældende standarder, f.eks. DO-178B/ED 12B fra United States Federal Aviation Administration. Som det er vist under punkt 2.4 ovenfor, kræves der testdata til test, og i nogle tilfælde kan disse datasæt være temmelig store. Under implementeringen opretter testere input og miljødata til placering i databaser og andre datalagre. Testere fremstiller også scripts og andre datageneratorer, der opretter data, der sendes til systemet som indgående belastning under testafviklingen. Under testimplementeringen skal testere fastlægge og bekræfte den rækkefølge, som manuelle og automatiserede tests skal køres i. Når der automatiseres, omfatter testimplementeringen fremstillingen af teststilladser og testscripts. Testere skal omhyggeligt teste for begrænsninger, der kan betyde, at tests skal køres i en bestemt rækkefølge. Afhængigheder af testmiljøet eller testdata skal være kendte og kontrollerede. Testimplementering omfatter også testmiljøet eller -miljøerne. I denne fase skal det sættes fuldstændigt op og verificeres før testafviklingen. Det er vigtigt med et testmiljø, der passer til formålet: Testmiljøet skal være i stand til at afsløre de defekter, der er til stede under testen; fungere normalt, når der ikke forekommer afvigelser, og skal være i stand til på passende måde at replikere f.eks. produktions- eller slutbrugermiljøet ved høj-niveau test. Under testimplementeringen skal testere sikre sig, at de ved, hvem der har ansvaret for fremstilling og vedligeholdelse af testmiljøet, at disse er tilgængelige, og at alle testdelprodukter, testsupportværktøjer og de tilhørende processer er klar til brug. Dette omfatter konfigurationsstyring, hændelseshåndtering og testlogning og -styring. Desuden skal testere verificere de procedurer, der indsamler data til evaluering af slutkriterier og rapportering af testresultater. Det er klogt at bruge en balanceret tilgang til testimplementering. F.eks. er risiko-baserede analytiske teststrategier ofte blandet med dynamiske teststrategier. I dette tilfælde allokeres nogle procent af testafviklingen til test, der ikke følger foruddefinerede scripts. Test uden scripts skal ikke være ad hoc eller uden mål, da det kan give en uforudsigelig varighed, medmindre det foregår i time-boxes (se SBTM). Gennem tiden har testere udviklet forskellige erfaringsbaserede teknikker, f.eks. angreb (se afsnit 4.4 og [Whittaker03]), fejlgætning [Myers79] og udforskende test. Testanalyse, testdesign og testimplementering optræder stadigvæk, men de optræder primært under testafviklingen. Når man følger disse dynamiske teststrategier, har resultatet af hver test indflydelse på analyse, design og implementering af de efterfølgende test. Selvom disse strategier er i letvægtsklassen og ofte er effektive til fejlfinding, kræver de eksperttestere, de kan være uforudsigelige med hensyn til varighed, de giver ofte ikke gode informationer om dækningen, og de kan være vanskelige at gentage uden hjælp fra specifikke værktøjer til regressionstest.





2.5.2 Testafvikling Testafviklingen begynder, når testobjektet er leveret, og startkriterierne for testafviklingen er opfyldt. Testen skal afvikles i overensstemmelse med testprocedurerne, selv om der kan gives noget råderum til testeren for at sikre dækning af yderligere interessante testscenarier og adfærd, der er observeret under test (alle afvigelser, der registreres under en sådan ’omvej’, skal beskrive variationer i forhold til den nedskrevne testprocedure, der er nødvendige for at reproducere afvigelsen). Automatiseret test følger deres definerede instruktioner uden ’omveje’. Centrum i testafviklingsaktiviteten er sammenligningen af de faktiske resultater med de forventede resultater. Testere skal udvise størst mulig opmærksomhed og fokus på disse opgaver, ellers kan alt arbejde med design og implementering af testen være spildt, når afvigelser overses (falske positive resultater), eller når korrekt opførsel klassificeres som forkert (falske negative resultater). Hvis det forventede og det faktiske resultatet ikke svarer til hinanden, er der opstået en hændelse. Hændelser skal undersøges nøje for at fastslå årsagen til dem (det kan være en defekt i testobjektet, eller noget andet) og for at indsamle data, der kan være til støtte ved løsningen af hændelsen. Hændelseshåndtering gennemgås nærmere i kapitel 7. Når en defekt er identificeret, skal testspecifikationen evalueres omhyggeligt for at sikre, at den er korrekt. En testspecifikation kan være forkert af flere årsager, herunder problemer i testdata, defekter i testdokumentationen eller en fejltagelse i den måde, testen blev afviklet på. Hvis den er forkert, skal den rettes og køres igen. Da ændringer i testbasis og testobjektet kan gøre, en testspecifikation forkert selv, efter at den er blevet kørt med succes mange gange, skal testere være opmærksomme på muligheden for, at de observerede resultater muligvis skyldes en forkert test. Under testafviklingen skal testresultater logges på passende vis. Test, der er blevet kørt, uden at resultaterne er blevet logget, skal muligvis gentages for at fastslå det korrekte resultat, hvilket kan føre til ineffektivitet og forsinkelser. (Bemærk, at tilstrækkelig logning kan løse de betænkeligheder med hensyn til dækning og mulighed for gentagelse, der er knyttet til dynamiske teststrategier). Da testobjekter, test-delprodukter og testmiljøer alle kan udvikler sig, skal logning identificere de specifikke versioner, der er testet. Testlogning giver en kronologisk registrering af relevante detaljer om afviklingen af tests. Logning af resultater gælder både for individuelle tests og for hændelser. Hver test bør være entydigt identificeret, og dens status logget, efterhånden som testafviklingen skrider fremad. Eventuelle hændelser, der påvirker testafviklingen, bør logges. Der bør logges tilstrækkeligt med oplysninger til at måle testdækningen og dokumentere årsagerne til forsinkelser og afbrydelser i testen. Desuden skal der logges oplysninger til støtte for testkontrol, rapportering af testfremdrift, måling af slutkriterier og forbedring af testprocessen. Logning varierer afhængigt af testniveauet og strategien. Hvis der f.eks. anvendes automatiseret komponenttest, indsamler de automatiserede tests det meste af logningsinformationerne. Hvis der anvendes manuel accepttest, samler den testansvarlige muligvis loggen. I nogle tilfælde, ligesom ved testimplementering, er logningen påvirket af krav fra lovgivning eller revisionskrav. IEEE 829-standarden indeholde en beskrivelse af de informationer, der skal registreres i en testlog.

Testlog-id

Beskrivelse

Aktivitet og hændelsesregistreringer. BS-7925-2 indeholder også en beskrivelse af de oplysninger, der kan logges. I nogle tilfælde kan brugere eller kunder deltage i testafviklingen. Det kan tjene som en måde at opbygge deres tillid til systemet på, selv om det forudsætter, at testene for det meste ikke resulterer i, at der findes defekter. En sådan forudsætning er for det meste ugyldig i de tidlige testniveauer, men kan muligvis være gyldig i forbindelse med accepttest. Metrikker til overvågning af testimplementering og -afvikling kan omfatte:

Procentdel af testmiljøer, der er konfigureret

Procentdel af testdataposter, der er indlæst

Procentdel af testbetingelser og -cases, der er afviklet





Procentdel af testcases, der er automatiseret.

2.6 Evaluering af slutkriterier og rapportering Dokumentation og rapportering til overvågning af testfremdrift og -kontrol gennemgås detaljeret i afsnit 3.6. Fra et testprocesmæssigt synspunkt medfører overvågningen af testfremdriften, at der indsamles information, der understøtter rapporteringskravene. Dette omfatter måling af fremdrift mod færdiggørelse. Metrikker til overvågning af testfremdrift og færdiggørelse omfatter en mapping til de aftalte slutkriterier (de, der blev aftalt under testplanlægningen), hvilket kan omfatte en eller alle af følgende:

Antallet af planlagte testbetingelser, testcases eller testspecifikationer og dem, der er afviklet, brudt ned på, om de bestod eller ej.

Det totale antal defekter, der er registreret, brudt ned på alvorlighedsgrad og prioritet, for dem, der er løst og dem der er udestående.

Antal af ændringer (ændringsanmodninger), der er fremsat, accepteret (udført) og testet.

De planlagte udgifter i forhold til de faktiske udgifter.

Den planlagte forbrugte tid i forhold til den faktiske forbrugte tid.

De identificerede risici brudt ned efter, om de er mildnet af testaktiviteten eller stadig udestående.

Procentdel af testtid, der er spildt på grund af blokerende hændelser.

Gen-testede elementer.

Den totale planlagte testtid i forhold til den effektive forbrugte testtid. Til testrapportering beskriver IEEE 829 en testopsummeringsrapport, der består af følgende afsnit:

Testopsummeringsrapport-id

Opsummering

Variationer

Fuldstændighedsvurdering

Overblik af resultater

Evaluering

Overblik af aktiviteter

Godkendelser Testrapportering kan ske, efter at hvert af testniveauerne er afsluttet, såvel som ved slutningen af hele testforløbet.





2.7 Testlukningsaktiviteter Når det bestemmes, at testafviklingen er fuldført, bør nøgleoutput indsamles og enten overgives til den relevante person eller arkiveres. Tilsammen er dette aktiviteterne i testlukning. Testlukningsaktiviteterne falder i fire hovedgrupper:

1. Sikring af, at alt testarbejde rent faktisk er afsluttet. F.eks. bør alle planlagte test enten være kørt eller bevidst sprunget over, og alle kendte defekter bør enten være løst, og løsningen bekræftet ved gen-test, udskudt til en fremtidig udgave eller accepteret som permanente begrænsninger.

2. Levering af værdifulde test-delprodukter til dem, der har behov for dem. F.eks. bør kendte defekter, der er udskudt eller accepteret, kommunikeres til dem, der skal bruge og understøtte brugen af systemet, og tests og testmiljøer gives til dem, der er ansvarlige for vedligeholdelsestest. Et andet test-delprodukt kan være en regressionstestpakke (enten automatiseret eller manuel).

3. Afholdelse af eller deltagelse i retrospektive møder (erfaringer fra testen) hvor vigtige erfaringer (både fra testprojektet og fra hele softwarens udviklingslivscyklus) kan dokumenteres, og der kan etableres planer til at sikre, at de enten ikke gentages i fremtiden, eller at der tages højde for problemerne i projektplanerne, hvis de ikke kan løses. For eksempel:

a. På grund af den sene opdagelse af uforudsete defektgrupper, har teamet muligvis opdaget, at et bredere tværsnit af brugerrepræsentanter burde deltage i kvalitetsrisikoanalyse-aktiviteter i fremtidige projekter.

b. Nugældende estimater kan være fejlvurderet i betydelig grad, og derfor skal fremtidige estimeringsaktiviteter tage højde for dette sammen med de underliggende årsager. Var testen f.eks. ineffektiv, eller var estimatet faktisk lavere, end det skulle have været.

c. Tendenser og årsags-/virkningsanalyse af defekter, ved at relaterer dem tilbage til, hvorfor og hvornår de opstod, og se, om der er nogle tendenser: for eksempel, om sene ændringer har påvirket kvaliteten af analysen og udviklingen, eller se efter dårlige arbejdsmetoder: f.eks. overspringning af et testniveau, der kunne have afsløret defekter tidligere og på en mere omkostningseffektiv måde, pga. tilsyneladende tidsbesparelse. Desuden: sammenkæde tendenser i defekter med områder så som nye teknologier, ændringer i bemanding eller manglen på kvalifikationer

d. Identifikation af potentielle procesforbedringsmuligheder. 4. Arkivering af resultater, logs, rapporter og andre dokumenter og test-delprodukter i det

konfigurationsstyringssystem,, der hører til selve systemet. F.eks. bør både testplanen og projektplanen opbevares i et planlægningsarkiv, med et klart link til det system og den version, de blev brugt på.

Disse opgaver er vigtige, mangler ofte, og bør eksplicit inkluderes som en del af testplanen. Det er almindeligt, at en eller flere af disse opgaver udelades, normalt på grund af en forhastet opløsning af gruppen, pres på ressourcer eller tidsplan fra efterfølgende projekter eller udbrændthed hos gruppen. På projekter, der er udført under en kontrakt, f.eks. udvikling til en bestemt kunde, bør kontrakten angive de krævede opgaver. Metrikker til overvågning af testlukningsaktiviteter kan inkludere:

Procentdel af testcases, der er kørt under testafviklingen (dækning).

Procentdel af testcases, der er overført til et genbrugslager for testcases.

Andelen af testcases, der er automatiseret, eller skal automatiseres.

Procentdel af testcases, der er identificeret som regressionstests.

Procentdel af udestående defektrapporter, der er lukket (f.eks. udskudt, ingen yderligere handling, ændringsanmodning etc.).

Procentdel af testdel-produkterne, der er identificeret og arkiveret.





3. Teststyring

Termer: FMEA (Failure Mode and Effect Analysis), testniveauplan, hovedtestplan, produktrisiko, projektrisiko, risikobaseret test, risikoanalyse, risikoidentifikation, risikoniveau, risikostyring, risikoreduktion, risikotype, testkontrol, sessionsbaseret teststyring, testestimering, testniveau, teststyring, testovervågning, testplan, testpolitik, TPA (test point analysis), testtidsplanlægning, teststrategi, wide band delphi.

3.1 Introduktion Hele dette kapitel dækker vidensområder, der er specielt krævet for testansvarlige.

3.2 Teststyringsdokumentation Dokumentation fremstilles ofte som en del af teststyringen. Mens de specifikke navne og omfanget af teststyringsdokumenterne ofte varierer, er det følgende almindelige typer teststyringsdokumenter, der findes i organisationer og i projekter:

Testpolitik, der beskriver organisationens filosofi med hensyn til test (og sandsynligvis kvalitetssikring).

Teststrategi (eller testhåndbog), der beskriver organisationens testmetoder, herunder produkt- og projektrisikostyring, opdelingen af testen i trin, niveauer eller faser og de højniveau-aktiviteter, der er knyttet til testen.

Hovedtestplan (eller projekttestplan eller testtilgang), der beskriver anvendelsen af teststrategien i et bestemt projekt, herunder de bestemte niveauer der skal udføres og relationerne mellem disse niveauer.

Niveautestplan (eller fasetestplan), der beskriver de bestemte aktiviteter, der skal udføres inden for hvert testniveau, herunder udvidelser af hovedtestplanen for det specifikke niveau, der dokumenteres.

I nogle organisationer og på nogle projekter kan disse dokumenttyper kombineres i et enkelt dokument, indholdet af disse dokumenttyper kan findes i andre dokumenter, og noget af indholdet i disse dokumenttyper kan findes som intuitive, ubeskrevne eller traditionelle testmetoder. Større og mere formelle organisationer og projekter har typisk alle disse dokumenttyper som skriftlige arbejdsprodukter, mens mindre og mere uformelle organisationer og projekter typisk har færre af denne type skriftlige arbejdsprodukter. Denne syllabus beskriver hver af disse dokumenttyper separat, men i praksis bestemmer den organisatoriske og projektmæssige sammenhæng den korrekte brug af hver type.

3.2.1 Testpolitik Testpolitikken beskriver organisationens filosofi med hensyn til test (og sandsynligvis kvalitetssikring). Den er enten givet i skriftlig form eller i form af retningslinjer fra ledelsen, og den angiver de overordnede mål for test, som organisationen ønsker at opnå. Denne politik kan være udarbejdet af it-afdelingen, research- og udviklingsafdelingen eller produktudviklingsafdelingen, men den bør afspejle de organisatoriske værdier og mål, der har relation til testen. I nogle tilfælde supplerer testpolitikken en bredere kvalitetspolitik eller er en del af den. Denne kvalitetspolitik beskriver de overordnede ledelsesværdier og -mål i relation til kvalitet. Hvor der findes en skriftlig testpolitik, kan det være et kort høj-niveau-dokument, der:





Giver en definition af test, f.eks. at den skal opbygge en tillid til, at systemet fungerer som tilsigtet, og bruges til at finde defekter

Beskriver en grundlæggende testproces, f.eks. testplanlægning og -kontrol, testanalyse og -design, testimplementering og -afvikling, vurdering af testslutkriterier og testrapportering og testlukningsaktiviteter

Beskriver, hvordan testens økonomiske og tidsmæssige effektivitet skal vurderes, f.eks. den procentdel af defekter, der skal findes (Defect Detection Percentage eller DDP) og de relative omkostninger ved defektfinding i test i modsætning til efter frigivelse

Definerer de ønskede kvalitetsmål, så som pålidelighed (f.eks. målt i form af afvigelseshyppighed) eller brugbarhed

Angiver aktiviteter for forbedring af testprocessen, f.eks. anvendelse af Test Maturity Model (TMM) eller Test Process Improvement-model (TPI), eller implementering af anbefalinger fra projekt-retrospektivt møde.

Testpolitikken kan omhandle testaktiviteter for både nyudvikling og vedligeholdelse. Den kan også referere til en standard for testterminologi, der skal bruges i hele organisationen.

3.2.2 Teststrategi Teststrategien beskriver organisationens testmetoder, herunder produkt- og projektrisikostyring, opdelingen af testen i niveauer eller faser og de høj-niveau aktiviteter der er knyttet til testen. Teststrategien og processen og aktiviteter, der er beskrevet i den, bør være i overensstemmelse med testpolitikken. Den skal udgøre det generiske testgrundlag for organisationen eller for et eller flere projekter. Som beskrevet i Foundation Syllabus, kan teststrategier (også kaldet testtilgange) klassificeres på basis af, hvornår testdesignet begynder:

Præventive strategier designer test tidligt for at forebygge defekter

Reaktive strategier, hvor testdesign kommer, efter at softwaren eller systemet er blevet fremstillet. Typiske strategier (eller tilgange) omfatter:

Analytiske strategier, f.eks. risikobaseret test

Modelbaserede strategier, f.eks. operationel profilering

Metodebaserede strategier, f.eks. kvalitetskarakteristik-baseret

Proces- eller standardkompatible strategier, f.eks. IEEE 829-baserede

Dynamiske og heuristiske strategier, f.eks. fejlbaserede angreb

Konsultative strategier, f.eks. brugerstyret test

Regressionsteststrategier, f.eks. omfattende automatisering. Forskellige strategier kan kombineres. Den specifikt valgte strategi skal passe til organisationens behov og muligheder, og organisationerne kan skræddersy strategier, så de passer til bestemte funktioner og projekter. I mange tilfælde forklarer en teststrategi projekt- og produktrisiciene og beskriver, hvordan testprocessen håndterer disse risici. I disse tilfælde bør forbindelsen mellem risici og test være tydeligt forklaret, og det samme skal mulighederne for reduktion og styring af disse risici. Teststrategien kan beskrive de testniveauer, der skal udføres. I disse tilfælde skal den give en høj-niveau vejledning for startkriterierne og slutkriterierne på hvert niveau og relationerne mellem niveauerne (f.eks. opdelingen af målene for testdækning). Teststrategien kan også følgende:

Integrationsprocedurer

Testspecifikationsteknikker

Uafhængighed af test(som kan variere afhængigt af niveauet)

Obligatoriske og valgfri standarder

Testmiljøer

Testautomation

Mulighed for genbrug af produkter fra softwarearbejdsprodukter og test-delprodukter

Gentest og regressionstest





Testkontrol og -rapportering

Testmåleresultater og -metrikker

Hændelseshåndtering

Konfigurationsstyringstilgang for test-delprodukter. Der skal både defineres kortsigtede og langsigtede teststrategier. Dette kan gøres i et eller flere dokumenter. Forskellige teststrategier passer til forskellige organisationer og projekter. F.eks. kan en strammere strategi være mere relevant, når det drejer sig om sikkerhedskritiske eller datakritiske applikationer, end i andre tilfælde.

3.2.3 Hovedtestplan Hovedtestplanen beskriver hvordan teststrategien anvendes for et bestemt projekt, herunder de niveauer, der skal udføres, og relationerne mellem disse niveauer. Hovedtestplanen bør være konsistent med testpolitikken og -strategien, og på specifikke områder, hvor den ikke er det, skal disse afvigelser og undtagelser forklares. Hovedtestplanen bør komplementere projektplanen eller driftsvejledningen på den måde, at den skal beskrive det testarbejde, der er en del af det større projekt eller driften. Selv om det specifikke indhold og strukturen i hovedtestplanen varierer afhængigt af organisationen, dens dokumentationsstandarder og formaliteten i projektet, inkluderer en hovedtestplan typisk følgende emner:

Elementer, der skal testes og de, der ikke skal testes.

Kvalitetsattributter, der skal testes og de, der ikke skal testes.

Testtidsplan og -budget (der bør være afstemt med projekt- eller driftsbudgettet).

Testafviklingscyklusser og deres sammenhæng med softwarereleaseplanen.

Forretningsmæssig begrundelse for og værdi af test.

Relationer og leverancer mellem test og andre medarbejdere eller afdelinger.

Definition af hvilke testelementer, der er omfattet hhv. ikke omfattet af hvert af de beskrevne niveauer.

Angiv startkriterier, fortsættelseskriterier (afbrydelse/genoptagelse), og slutkriterier for hvert niveau og relationerne mellem niveauerne.

Testprojektrisici. Ved mindre projekter eller driftsopgaver, hvor der kun er formaliseret ét testniveau, vil hovedtestplanen og testplanen for dette formaliserede niveau ofte være samlet i ét dokument. Hvis systemtest f.eks. er det eneste formaliserede niveau, mens uformel komponent- og integrationstest udføres af udviklere, og uformel accepttest udføres af kunderne som en del af en betatestproces, så kan systemtestplanen omfatte de elementer, der er omtalt i dette afsnit. Desuden afhænger testen typisk af andre aktiviteter i projektet. Hvis disse aktiviteter ikke er tilstrækkeligt dokumenteret, specielt hvad angår deres indflydelse på og relationer til testen, kan emner, der har relation til disse aktiviteter, være dækket i hovedtestplanen (eller i den pågældende niveautestplan). Hvis konfigurationsstyringsprocessen f.eks. ikke er dokumenteret, skal testplanen angive, hvordan testobjekter skal leveres til testteamet.

3.2.4 Niveautestplan Niveautestplanen beskriver de bestemte aktiviteter, der skal udføres inden for hvert testniveau, herunder nødvendige udvidelser af hovedtestplanen for det specifikke niveau, der dokumenteres. Den giver detaljerede informationer om tidsplanlægning, opgaver og milepæle, der ikke nødvendigvis er dækket i hovedtestplanen. Hvis der desuden bruges forskellige standarder og skabeloner til specifikation af test på forskellige niveauer, vil disse detaljer være behandlet i niveau testplanen. I mindre formelle projekter eller driftsopgaver er en enkelt niveautestplan ofte det eneste teststyringsdokument, der bliver skrevet. I sådanne situationer kan nogle af de informationselementer, der er nævnt i afsnittene 3.2.1, 3.2.2 og 3.2.3 være dækket i dette dokument.





3.3 Skabeloner til testplandokumentation Som nævnt i afsnit 3.2 varierer det specifikke indhold og strukturen i hovedtestplanen afhængigt af organisationen, dens dokumentationsstandarder og projektets formalitet. Mange organisationer udvikler eller tilpasser skabeloner for at sikre sammenfald og læsbarhed på tværs af projekter og driftsopgaver, og skabeloner for testplandokumentation er tilgængelige. IEEE 829 "Standard for Software Testing Documentation" indeholder skabeloner til testdokumentation og vejledning i anvendelsen af dem, herunder udarbejdelse af testplaner. Standarden behandler også det relaterede emne testelementoverførsel (dvs. frigivelse af testelementer til test).

3.4 Testestimering Estimering, som ledelsesaktivitet, er fremstillingen af et tilnærmet mål for de omkostninger og afslutningsdatoer, der er tilknyttet aktiviteterne i en bestemt driftsopgave eller et bestemt projekt. De bedste estimater:

Repræsenterer den samlede viden fra erfarne praktikere og støttes af de involverede deltagere

Giver specifikke, detaljerede oversigter over de omkostninger, ressourcer, opgaver og medarbejdere, der er involveret

Præsenterer for hver estimeret aktivitet, de mest sandsynlige omkostninger, og den mest sandsynlige arbejdsindsats og varighed.

Estimering af software- og systemarbejde har længe været kendt for at være fyldt med problemer, både tekniske og politiske, selv om de bedste fremgangsmåder for estimering i forbindelse med projektstyring er veletablerede. Testestimering er anvendelsen af disse bedste fremgangsmåder på de testaktiviteter, der er knyttet til et projekt eller en driftsopgave. Testestimering bør indeholde alle de aktiviteter, der er involveret i testprocessen, dvs. testplanlægning og -kontrol, testanalyse og -design, testimplementering og -afvikling, testvurdering og -rapportering og aktiviteter omkring testafslutning. De estimerede omkostninger, den estimerede arbejdsindsats og især varigheden af testafviklingen er ofte mest interessant for ledelsen, da testafviklingen typisk er på den kritiske vej i projektet. Men estimater for testafviklingen har en tendens til at være vanskelige at fremstille og til at være upålidelige, når den overordnede kvalitet af softwaren er lav eller ukendt. En normal praksis er også at estimere antallet af nødvendige testcases. Antagelser, der gøres under estimering, skal altid dokumenteres som en del af estimeringen. Testestimeringen bør tage alle faktorer, der kan påvirke omkostninger, arbejdsindsats og varighed af testaktiviteterne, i betragtning. Disse faktorer inkluderer (men er ikke begrænset til) følgende:

Det krævede kvalitetsniveau for systemet

Størrelsen af det system, der skal testes

Historiske data fra tidligere testprojekter (dette kan også omfatte benchmark data)

Procesfaktorer, herunder: teststrategi, udviklings- eller vedligeholdelseslivscyklus og procesmodenhed og nøjagtigheden af projektestimatet

Fysiske faktorer, herunder: testautomatisering og -værktøjer, testmiljø, testdata, udviklingsmiljø(er), projektdokumentation (f.eks. krav, design etc.) og genbrugelige test-delprodukter

Medarbejderfaktorer, herunder: chefer og tekniske ledere, den overordnede ledelses forpligtelse og forventninger, evner, erfaring og holdninger i projektgruppen, stabiliteten i projektgruppen, projektgruppens relationer, støtte til test- og debuggingmiljø, tilgængeligheden af uddannede kontraktansatte og konsulenter og domæneviden.





Blandt de andre faktorer, der kan påvirke testestimatet, er kompleksiteten af processen, teknologien, organisationen, antallet af interessenter i testen, mange undergrupper, specielt hvis de er geografisk adskilte; betydeligt behov for opsætning, træning og orientering; tilpasning eller udvikling af nye værktøjer, teknikker, skræddersyet hardware, antallet af test-delprodukter; krav om en høj detaljeringsgrad for testspecifikationerne, specielt hvis det skal ske efter en uvant dokumentationsstandard; kompleks timing af komponenternes ankomst, specielt ved integrationstest og testudvikling, og endelig skrøbelige testdata (f.eks. data, der er tidsfølsomme). Estimering kan enten foretages bottom-up eller top-down. De følgende teknikker kan bruges til testestimering:

Intuition og gæt

Tidligere erfaring

Nedbrydning af arbejdsopgaver (WBS)

Sessioner med teamestimering (f.eks. Wide Band Delphi)

Trepunktsestimat

Test Point Analysis (TPA) [Pol02]

Virksomhedsstandarder og -normer

Procentdele af den totale arbejdsindsats i projektet eller bemandingsniveauer (f.eks. forholdet mellem antallet af testere og antallet af udviklere)

Organisatorisk historik og metrikker, herunder metrikbaserede modeller, der estimerer antallet af defekter, antallet af testcyklusser, antallet af testcases, den gennemsnitlige arbejdsindsats for hver test og antallet af involverede regressionscyklusser

Branchegennemsnit og forudsigelsesmodeller, så som test-points, function-points, antal kodelinjer, estimeret arbejdsindsats for udvikler eller andre projektparametre.

I de fleste tilfælde skal estimatet, når det er udarbejdet, sendes til ledelsen sammen med en begrundelse (se afsnit 3.7). Ofte følger nogle forhandlinger, der tit resulterer i en ny bearbejdning af estimatet. Ideelt set repræsenterer estimatet den bedst mulige balance mellem organisatoriske og projektmæssige mål inden for områderne kvalitet, tidsplanlægning, budget og funktioner

3.5 Testplanlægning Generelt giver forhåndsplanlægning af enhver type aktiviteter mulighed for afdækning og styring af risici ved disse aktiviteter, for omhyggelig og rettidig koordination med andre involverede og for en plan af høj kvalitet. Det samme gælder for testplanlægning. Men hvad angår testplanlægning, så opnås der yderligere fordele ved tidlig planlægning på basis af testestimatet, herunder:

Opdagelse og styring af projektrisici og problemer, der ikke er omfattet af selve testen

Opdagelse og styring af produkt- (kvalitets-)risici og problemer før testafviklingen

Erkendelse af problemer i projektplanen eller andre arbejdsprodukter fra projektet

Muligheder for at forøge tildelingen af testpersonale, budget, arbejdsindsats og/eller varighed for at opnå højere kvalitet

Identifikation af kritiske komponenter (og derfor mulighed for at fremskynde leveringen af disse komponenter).

Testtidsplanlægning skal foretages i tæt samarbejde med udviklingen, da testen er meget afhængig af udviklings-(leverings)planen. Da muligheden for at udnytte disse potentielle fordele muligvis er gået tabt, når alle de oplysninger, der kræves for at fuldføre testplanen, er modtaget, skal testplanerne udvikles og udgives i udkastform så tidligt som muligt. I takt med at der kommer yderligere oplysninger, kan forfatteren til testplanen (typisk en testansvarlig) tilføje disse oplysninger til planen. Denne iterative metode til fremstilling, udgivelse og review af testplanen muliggør også, at testplanen eller testplanerne fungerer som et middel til at fremme konsensus, kommunikation og diskussion om testen.





3.6 Overvågning af testfremdrift og kontrol Der er fem primære dimensioner, som testfremdriften overvåges i forhold til:

Produktrisici

Defekter

Tests

Dækning

Tillid. Produktrisici, hændelser, tests og dækning kan måles, og bliver det ofte, og rapporteres på bestemte måder under projektet eller driftsopgaven. Det er at foretrække, at disse måleresultater er relateret til de definerede slutkriterier, angivet i testplanen. Tillid, der ganske vist kan måles gennem undersøgelser, rapporteres normalt subjektivt. Metrikker, der har relation til produktrisici, inkluderer:

Antallet af udestående risici (inkl. type og risikoniveau)

Antallet af mildnede risici (inkl. type og risikoniveau). Metrikker, der har relation til defekter, inkluderer:

Det samlede antal rapporterede (identificerede) i forhold til det samlede antal løste (lukkede)

Gennemsnitstiden mellem afvigelser (Meantime between failure) eller afvigelseshyppighed

Opdeling af antallet af defekter i forhold til:: bestemte testelementer eller –komponenter, underliggende årsager, kilder; testreleases; fase, hvor defekten blev indført, registreret eller fjernet; og i nogle tilfælde ejeren

Tendenser for forløbet tid fra defektrapportering til løsning. Metrikker, der har relation til test, inkluderer:

Totalt antal test, der er planlagt, specificeret (udviklet), kørt, bestået, fejlet, blokeret og sprunget over

Status for regressions- og gentest

Antal planlagte testtimer pr. dag i forhold til det faktisk opnåede antal testtimer. Metrikker, der har relation til testdækning, inkluderer:

Dækning af krav og designelement

Risikodækning

Miljø/konfigurationsdækning Disse måleresultater kan rapporteres verbalt i prosaform, numerisk i tabeller eller visuelt i grafer, og de kan bruges til en række formål, herunder:

Analyse, for at afdække hvad der sker med produktet, projektet eller processen via testresultaterne

Rapportering, for at kommunikere testresultaterne til de interesserede projektdeltagere og interessenter

Kontrol, for at ændre retningen på testen eller projektet som helhed og for at overvåge resultaterne af denne kursændring.

Hvilke måder, der er bedst til indsamling, analyse og rapportering af disse testmåleresultater, afhænger af de specifikke informationsbehov, mål og muligheder for dem, der skal bruge disse måleresultater. Når testresultaterne bruges til at påvirke eller måle kontrolindsatsen på projektet, skal følgende forhold overvejes:

Revision af kvalitetsrisikoanalysen, testprioriteter og/eller testplaner

Tilføjelse af ressourcer eller forøgelse af testindsatsen på anden måde

Forsinkelse af frigivelsesdato

Svækkelse eller forstærkning af slutkriterierne. Implementering af sådanne muligheder kræver typisk konsensus mellem projekt- eller driftsopgaveinteressenterne og samtykke fra projekt- eller driftscheferne. Måden, en testrapport er sat op på, afhænger i høj grad af målgruppen, f.eks. projektledelsen eller virksomhedens ledelse. For en projektleder er det sandsynligvis interessant at have detaljerede oplysninger om defekter. For virksomhedslederen kunne et vigtigt rapporteringspunkt være status for produktrisiciene.





IEEE 829 "Standard for Software Testing Documentation" indeholder en skabelon til en testopsummeringsrapport. Testkontrollen skal udføres på basis af afvigelser fra testplanen, beskrevet i testfremdriftsrapporten. Testkontrollens mål er at minimere afvigelsen fra testplanen. De mulige kontrolforanstaltninger inkluderer:

Fornyet gennemgang af prioriteringen af testcases

Indsættelse af yderligere ressourcer

Udskydelse af frigivelsesdato

Ændring af omfanget (funktionaliteten) af projektet

Fornyet gennemgang af testafslutningskriterierne (kun med godkendelse fra interessenterne).

3.7 Den forretningsmæssige værdi af test Selv om de fleste organisationer betragter test som værdifuld på en eller anden måde, er det kun få chefer, inklusive testansvarlige, der kan kvantificere, beskrive eller formulere denne værdi. Desuden fokuserer mange testansvarlige, testledere og testere på de taktiske detaljer ved test (aspekter, der er specifikke for opgaven eller niveauet), mens de ignorerer de mere strategiske (højere niveau) spørgsmål i forbindelse med test, som andre projektdeltagere, især chefer, bekymrer sig om. Test giver værdi til organisationen, projektet og/eller driftsopgaven på både kvantitative og kvalitative måder:

Kvantitative værdier omfatter afsløring af defekter, der således forhindres eller rettes før frigivelse, afsløring af defekter, der således er kendt før frigivelsen, reduktion af risiko gennem kørsel af test og levering af oplysninger om projekt-, proces- og produktstatus.

Kvalitative værdier omfatter et forbedret ry for kvalitet, gnidningsløse og mere forudsigelige frigivelser, øget tillid, opbygning af tillid, beskyttelse mod retsligt ansvar og reduktion af risikoen for tab af hele opgaver eller endog liv.

Testansvarlige og testledere bør have forståelse for, hvilke af disse værdier, der gælder for deres organisation, projekt og/eller driftsopgave, og være i stand til at kommunikere om test udtrykt vha. disse værdier. En velkendt metode til måling af den kvantitative værdi og effektiviteten af test kaldes kvalitetsudgiften (eller nogle gange omkostningen ved dårlig kvalitet). Omkostning ved kvalitet omfatter, at projekt- eller driftsomkostninger klassificeres i fire kategorier:

Omkostningerne ved forebyggelse

Omkostningerne ved registrering

Omkostningerne ved interne afvigelser

Omkostningerne ved eksterne afvigelser. En del af testbudgettet er omkostning ved defektafsløring, mens den resterende del er omkostningen ved interne afvigelser. De totale omkostninger ved defektafsløring og interne afvigelser er typisk langt under omkostningerne ved eksterne afvigelser, og det gør, at test giver udmærket værdi for pengene. Ved at bestemme omkostningerne i disse fire kategorier, er det muligt for testansvarlige og testledere at fremstille en overbevisende business case for test.

3.8 Distribueret, outsourcet og insourcet test I mange tilfælde udføres alt testarbejdet ikke af en enkelt testgruppe, sammensat af kollegaer til resten af projektgruppen, på et enkelt sted og samme sted som resten af projektgruppen. Hvis testarbejdet sker flere steder, kan det kaldes distribueret. Hvis testarbejdet udføres et eller flere steder af medarbejdere, der ikke er kollegaer med resten af projektgruppen, og som ikke er placeret sammen med projektgruppen, kan testarbejdet kaldes outsourcet. Hvis testarbejdet udføres af medarbejdere, der er placeret sammen med projektgruppen, men som ikke er kollegaer med dem, kan testarbejdet kaldes insourcet. Fælles for alle disse typer testarbejde er behovet for klare kommunikationskanaler og veldefinerede forventninger til missioner, opgaver og leverancer. Projektgruppen skal basere sig mindre på uformelle kommunikationskanaler som korridorsnak og kollegaer, der bruger social tid sammen. Placering, tidszone, kulturelle og sproglige forskelle kan gøre disse spørgsmål endnu mere kritiske.





På tværs af alt testarbejdet er der også behovet for afstemning af metoder. Hvis to testgrupper bruger forskellige metoder, eller testgruppen bruger en anden metode end udviklingsafdelingen eller projektledelsen, vil dette resultere i alvorlige problemer, specielt under testafviklingen. Ved distribueret test skal opdelingen af testarbejdet på flere steder være klart beskrevet og ske efter grundige overvejelser. Uden denne vejledning foretager den mest kompetente gruppe måske ikke det testarbejde, de er højt kvalificeret til. Desuden vil testarbejdet som helhed lide under mangler (der forøger den resterende kvalitetsrisiko ved leveringen) og overlapninger (der reducerer effektiviteten). Endelig er det ved alle den slags testarbejder af kritisk betydning, at hele projektgruppen udvikler og opretholder tillid til, at hvert af testgrupperne udfører deres rolle ordentligt på trods af organisatoriske, kulturelle, sproglige og geografiske grænser. Mangel på tillid fører til ineffektivitet og forsinkelser i forbindelse med verifikationsaktiviteter, fordeling af skyld for problemer og organisatorisk politisering.


3.9.1 Introduktion til risikobaseret test Risiko er muligheden for et uønsket resultat. Risici findes alle steder, hvor der kan forekomme problemer, der nedsætter kundens, brugerens, deltagerens eller interessentens opfattelse af produktkvalitet eller projektsucces. Hvor den primære effekt af det potentielle problem er på produktkvaliteten, kaldes de potentielle problemer for produktrisici (eller kvalitetsrisici). Som eksempel kan nævnes en mulig pålidelighedsdefekt(bug), der kan forårsage, at et system går ned under normal drift. Hvor den primære effekt af det potentielle problem er på projektets succes, kaldes det potentielle problem for en projektrisiko (eller planlægningsrisiko). Som eksempel kan nævnes en mulig mangel på bemanding, der kan forsinke færdiggørelsen af et projekt. Ikke alle risici giver grund til samme bekymring. Risikoniveauet påvirkes af forskellige faktorer:

Sandsynligheden for, at problemet opstår

Effekten af problemet, hvis det opstår. Ved risikobaseret test, udføres test på en måde, der imødekommer risiko på tre måder:

Fordeling af testindsats, valg af teknik, rækkefølgen af testaktiviteterne og rettelse af defekter (bugs) skal foretages på en måde, der passer til det risikoniveau, der er knyttet til hver signifikant, identificeret produkt- (kvalitets-)risiko.

Planlægning og styring af testarbejdet skal ske på en måde, der giver reduktion og forebyggelse af hver signifikant, identificeret projekt- (planlægnings)risiko.

Rapportering af testresultater og projektstatus med hensyn til udestående risici, f.eks. baseret på tests, der endnu ikke er kørt eller er blevet sprunget over, eller defekter, der endnu ikke er blevet udbedret eller gentestet.

Disse tre typer af behandling af risici bør ske gennem hele livscyklussen, ikke kun i starten eller slutningen af projektet. Specielt under projektet bør testere forsøge at gøre følgende:

Reducere risici ved at finde de vigtigste defekter (for produktrisici) og ved at anvende passende aktiviteter til reduktion og forebyggelse, der er detaljeret forklaret i teststrategien og testplanen

Foretage en evaluering af risici, idet effekten eller sandsynligheden for tidligere identificerede og analyserede risici forøges eller formindskes på basis af yderligere oplysninger, der er indsamlet i takt med, at projektet afvikles.

I begge tilfælde påvirker de foretagne handlinger den måde, testen behandler risiko på. Risikobaseret test kan på mange måder ses som værende analog til forsikring. Man køber forsikring, når man er bekymret over en potentiel risiko, og man ignorerer risici, som man ikke er bekymret over. Kvantitative analyser, der svarer til den risikovurdering, som aktuarer og andre fagfolk inden for forsikring udfører, kan være på sin plads, men typisk anvendes der kvalitative analyser ved risikobaseret test.





For at være i stand til at udføre en korrekt risikobaseret test, skal testere være i stand til at identificere, analysere og mildne typiske produkt- og projektrisici. der er relateret til sikkerhed, forretningsmæssige og økonomiske bekymringer, system- og datasikkerhed og tekniske og politiske faktorer.

3.9.2 Risikostyring Risikostyring kan betragtes, som sammensat af tre primære aktiviteter:

1. Risikoidentifikation 2. Risikoanalyse 3. Risikoreduktion (også kaldet risikokontrol).

Disse aktiviteter er på nogle måder sekventielle, men det behov for kontinuerlig risikostyring, der er nævnt i de tidligere og følgende afsnit, betyder, at alle tre typer af risikostyringsaktiviteter skal udføres gentagne gange gennem det meste af projektet. For at være mest effektiv inddrager risikostyringen alle interessenter i projektet, selv om projektrealiteterne kan resultere i, at nogle interessenter optræder som erstatning for andre interessenter. Ved udvikling af software til massemarkedet kan man f.eks. bede et lille udvalg af potentielle kunder om at hjælpe med at identificere potentielle defekter, der i høj grad ville påvirke deres brug af softwaren; i dette tilfælde fungerer de udvalgte potentielle kunder som erstatning for hele den potentielle kundebase. På grund af deres specielle ekspertise, bør testanalytikere involveres aktivt i risikoidentifikationen og analyseprocessen.

3.9.2.1 Risikoidentifikation

For både produkt- og projektrisici kan testere identificere risici vha. en eller flere af følgende teknikker:

Ekspertinterview

Uafhængige vurderinger

Brug af risikoskabeloner

Erfaringer (f.eks. fra produktevalueringssessioner)

Risikoworkshops (f.eks. FMEA)

Brainstorming

Checklister

Brug af erfaringer fra tidligere. Når det bredest mulige udvalg af interessenter inddrages, har risikoidentifikationsprocessen størst mulighed for at registrere det størst mulige antal signifikante risici. I nogle metoder til risikoidentifikation stopper processen ved identifikationen af selve risikoen. Visse teknikker f.eks. Failure Mode and Effect Analysis (FMEA) kræver, at der for hver potentiel afvigelsestilstand fortsættes til identifikation af virkningerne af afvigelsestilstanden på resten af systemet (inklusive systemer på øverste niveau, når der er tale om systemer af systemer) og på de potentielle brugere af systemet. Andre teknikker, f.eks. faremomentanalyse, kræver en forventning om kilden til risikoen. Se afsnittet 3.10 og i [Stamatis95], [Black02], [Craig02], [Gerrard02] for en beskrivelse af brugen af effekten af afvigelsestilstand, Failure Mode and Effect Analysis og Criticality Analysis.





3.9.2.2 Risikoanalyse

Mens risikoidentifikation handler om at identificere så mange relevante risici som muligt, er risikoanalyse studiet af disse identificerede risici. Mere specifikt, kategoriseringen af hver risiko og bestemmelsen af den sandsynlighed og effekt, der er knyttet til hver risiko. Kategorisering af risici betyder, at hver risiko placeres i en passende type. Typiske kvalitetsrisikotyper gennemgås i ISO 9126-standarden for kvalitetskarakteristika til klassificering af risici. Nogle organisationer har deres eget sæt af kvalitetskarakteristika. Bemærk, at når der anvendes checklister som grundlag for risikoidentifikation, sker valget af risikotypen ofte under identifikationen. Bestemmelse af risikoniveauet involverer typisk, at der for hvert risikoelement foretages en vurdering af sandsynligheden for, at risikoen indtræffer, og af effekten, hvis den skulle indtræffe. Sandsynligheden for, at risikoen indtræffer, fortolkes ofte som sandsynligheden for, at det potentielle problem eksisterer i systemet under testen. Den kommer med andre ord fra en teknisk risiko. Faktorer, der påvirker den tekniske risiko, inkluderer:

Kompleksiteten af teknologi og grupper

Personale og uddannelsesspørgsmål blandt forretningsanalytikere, designere og programmører

Konflikter i gruppen

Kontraktuelle problemer med leverandører

Geografisk fordeling af udviklingsorganisationen

Gamle systemer versus nye tilgange

Værktøjer og teknologi

Dårlig styringsmæssig eller teknisk ledelse

Tids-, ressource- og ledelsespres

Mangel på tidligere kvalitetssikring

Høje ændringshastigheder

Mange tidligere defekter

Grænseflade- og integrationsspørgsmål Effekten af at risikoen indtræder, fortolkes ofte som alvorligheden af effekten på brugerne, kunderne eller andre interessenter. Den kommer med andre ord fra en forretningsmæssig risiko. Faktorer, der påvirker den forretningsmæssige risiko, inkluderer:

Brugsfrekvensen af den berørte funktion

Skade på virksomhedens image

Tab af forretning

Potentielle finansielle, miljømæssige eller sociale tab eller ansvar

Civilretslige eller strafferetslige sanktioner

Tab af licens

Mangel på fornuftige omgåelser

Synligheden af afvigelse førende til negativ omtale. Testerne kan vælge enten at fastsætte risikoniveauet kvantitativt eller kvalitativt. Hvis sandsynlighed og effekt kan fastslås kvantitativt, kan man gange de to værdier med hinanden for at beregne omkostningen ved eksponering. Dette er det forventede tab i forbindelse med en bestemt risiko. Men typisk kan risikoniveauet kun fastslås kvalitativt. Det vil sige, at man taler om, at sandsynligheden er meget høj, høj, medium, lav eller meget lav. Men man kan ikke med sikkerhed sige, om sandsynligheden er 90 %, 75 %, 50 %, 25 % eller 10 %. Denne kvalitative metode skal ikke betragtes som værende mindre værd end kvantitative metoder. Faktisk er det sådan, at når kvantitative metoder bruges forkert, vildleder de interessenterne om, i hvilket omfang man faktisk kan forstå og styre risici. Uformelle metoder som dem, der er beskrevet i [vanVeenendaal02], [Craig02] og [Black07b], er ofte kvalitative og mindre rigoristiske.





Med mindre risikoanalysen er baseret på omfattende og statistisk pålidelige risikodata (som det er tilfældet i forsikringsbranchen), så vil den, uanset om der er tale om kvalitativ eller kvantitativ risikoanalyse, være baseret på den opfattede sandsynlighed og effekt. Det betyder, at personlige opfattelser og meninger om disse faktorer påvirker det fastlagte risikoniveau. Projektledere, programmører, brugere, forretningsanalytikere, systemarkitekter og testere har typisk forskellige opfattelser og derfor muligvis forskellige opfattelser af risikoniveauet for hvert risikoelement. Risikoanalyseprocessen bør indeholde en metode til opnåelse af konsensus om fastlæggelsen af risikoniveauet, i værste fald i form af et diktat. Ellers kan risikoniveauer ikke bruges som retningslinje for risikoreduktionsaktiviteter.

3.9.2.3 Risikoreduktion

Når en risiko først er blevet identificeret og analyseret, er der fire mulige måder, denne risiko kan håndteres på: 1. Reduktion af risikoen gennem forebyggende foranstaltninger, der reducerer sandsynligheden og/eller

effekten 2. Udarbejdelse af beredskabsplaner til reduktion af effekten, hvis risikoen bliver en realitet 3. Overførsel af risikoen til håndtering af andre parter 4. Ignorering og accept af risikoen.

Mulighederne for at vælge en af disse afhænger af de fordele og chancer, der skabes af hver valgmulighed, samt af de omkostninger og eventuelt den yderligere risiko, der er knyttet til hver valgmulighed.

Reduktionsstrategier

I de fleste risikobaserede teststrategier er risikoidentifikation, risikoanalyse og etableringen af aktiviteter til risikoreduktion grundlaget for hovedtestplanen og de andre testplaner. Det risikoniveau, der er knyttet til hvert risikoelement, bestemmer omfanget af det testarbejde (dvs. handlinger til reduktion), der udføres for at tage hånd om hver risiko. Nogle sikkerhedsrelaterede standarder (f.eks. FAA DO-178B/ED 12B, IEC 61508) foreskriver testteknikkerne og graden af dækning på basis af risikoniveauet.

Reduktion af projektrisiko

Hvis projektrisici er identificeret, er der muligvis behov for, at projektlederen får besked om dem, så vedkommende kan beslutte, hvad der skal ske. Det er ikke altid, at testorganisationen har mulighed for at reducere sådanne risici. Men nogle projektrisici kan og bør med held reduceres af den testansvarlige, som f.eks.:

Parathed af testmiljø og værktøjer

Teststabens tilgængelighed og kvalifikationer

Lav kvalitet af input til test

For mange ændringer af input til testen

Mangel på standarder og regler for og teknikker til testarbejdet. Metoderne til risikoreduktion omfatter tidlig forberedelse af testdelprodukter, forudgående test af testudstyr, forudgående test af tidligere versioner af produktet, skrappere startkriterier for testen, krav til testbarhed, deltagelse i reviews af tidligere projektresultater, deltagelse i problem- og ændringsstyring og overvågning af projektfremdrift og -kvalitet.

Reduktion af produktrisiko

Når man taler om en produktrisiko (kvalitetsrisiko), er test en form for reduktion af sådanne risici. I det omfang der findes defekter, kan testere reducere risikoen ved at gøre opmærksomhed på defekter og give mulighed for at gøre noget ved dem inden frigivelse. I det omfang testere ikke finder defekter, reducerer testen risikoen ved at sikre, at systemet fungerer korrekt under visse omstændigheder (dvs. under de testede betingelser). Produktrisici (kvalitetsrisici) kan reduceres gennem ikke-testaktiviteter. Hvis det f.eks. er fastslået, at kravene ikke er godt skrevet, kan det være en effektiv løsning at implementere grundige reviews som en reducerende handling, i stedet for at skrive og prioritere test, der vil blive kørt, når den dårligt skrevne software er blevet et design og en faktisk kode. Risikoniveauet bruges også til at prioritere test. I nogle tilfælde køres alle test med den højeste risiko før nogen af testene med en lavere risiko, og testene køres i en stram risikoorden (ofte kaldet "dybde først"). I andre tilfælde anvendes en stikprøvemetode til at indsamle et udvalg af test på tværs af alle identificerede risici, hvor risikoen bruges til at vælge det udvalgte, samtidig med at det sikres, at hver risiko er dækket mindst én gang (ofte kaldet "bredde først").





Andre risikoreducerende handlinger, der kan anvendes af testere, inkluderer:

Valg af en passende testdesignteknik

Reviews og inspektion

Reviews af testdesign

Uafhængighedsniveau

Den mest erfarne person

Den måde gentest udføres på

Regressionstest. I [Gerrard02] introduceres begrebet testeffektivitet til angivelse af (som en procentdel), hvor effektiv test forventes at være som et middel til risikoreduktion. Der kan være en tendens til ikke at anvende test til reduktion af risiko, når der er et lavt niveau af testeffektivitet. Uanset om risikobaseret test foregår som dybde-først eller bredde-først, er det muligt, at den afsatte testtid bruges, uden at alle test er kørt. Risikobaseret test giver testere mulighed for at rapportere til ledelsen i form af det udestående risikoniveau på dette tidspunkt, og det giver ledelsen mulighed for at beslutte, om testen skal udvides, eller om den udestående risiko skal overføres til brugerne, kunderne, helpdesk/teknisk support og/eller driftspersonalet.

Justering af test til yderligere testcyklusser

Hvis der er tid til overs til yderligere test, skal alle næste testcyklusser tilpasses til en ny risikoanalyse. Hovedfaktorerne her er alle helt nye eller meget ændrede produktrisici; ustabile eller defektsandsynlige områder, der er opdaget under testen; risici fra rettede defekter; forsøg på at koncentrere testen om typiske defekter, fundet under testen og muligvis undertestede områder (lav testdækning). Alle nye eller yderligere testcyklusser bør planlægges ved brug af en analyse, der har sådanne risici som input. Det er også en meget anbefalet praksis at udarbejde et opdateret risikoark ved hver projektmilepæl.

3.9.3 Risikostyring i livscyklussen Ideelt set sker risikostyring gennem hele livscyklussen. Hvis en organisation har et testpolitikdokument og/eller en teststrategi, så skal disse beskrive den generelle proces for styring af produkt- og projektrisici i test og vise, hvordan risikostyringen er integreret i og påvirker alle stadier af test. Risikoidentifikation og risikoanalyseaktiviteter kan begynde under projektets startfase, uanset hvilken softwareudviklingslivscyklusmodel, der følges. Risikoreduktionsaktiviteter kan planlægges og indplaceres i den overordnede testplanlægningsproces. I hovedtestplanen og/eller niveautestplanerne kan både projekt- og produktrisici håndteres. Risikotypen og -niveauet vil påvirke de testniveauer, hvori risiciene håndteres, omfanget af det arbejde der skal bruges til at reducere risikoen, den test og de andre teknikker, der skal anvendes for at reducere risikoen, og de kriterier, der skal anvendes til at bedømme tilstrækkeligheden af risikoreduktionen. Når planlægningen er afsluttet, bør risikostyring, herunder identifikation, analyse og reduktion, være en vedvarende del af projektet. Dette omfatter identifikation af nye risici, revurdering af niveauet for eksisterende risici og vurdering af effektiviteten af aktiviteter til risikoreduktion. For at tage et eksempel: hvis der blev gennemført en risikoidentifikation og -analyse på basis af kravspecifikationerne under kravfasen, bør der ske en revurdering af risiciene når designspecifikationen er afsluttet. Et andet eksempel kan være, at hvis det under testen registreres, at en komponent indeholder betydeligt flere end det forventede antal defekter, kan man konkludere, at sandsynligheden for defekter i dette område var højere end forventet, og man må derfor justere sandsynligheden og det overordnede risikoniveau opad. Dette kan resultere i en forøgelse af mængden af test, der skal udføres på denne komponent. Når de indledende risikoidentifikations og analyseaktiviteter er fuldført, og når reduktionsaktiviteterne er udført, kan man måle i hvilken grad risiciene er blevet reduceret. Dette kan ske ved at spore testcases og fundne defekter tilbage til deres tilhørende risici. I takt med at test køres, og der findes defekter, kan testerne vurdere det udestående risikoniveau. Dette understøtter brugen af risikobaseret test til bestemmelse af det rigtige tidspunkt for frigivelse. Et eksempel på rapportering af testresultater på basis af risikodækning findes i [Black03].





Testrapporteringen skal behandle de risici, der er dækket og stadig åbne, samt de fordele, der er opnået og endnu ikke opnået.

3.10 Failure Mode and Effect Analysis Failure Mode and Effect Analysis (FMEA) og en variant, der omfatter kritisk analyse (FMECA), er iterative aktiviteter, der er beregnet til at analysere effekterne og den kritiske betydning af afvigelsestilstande i et system. Anvendelse af disse analyser på software kaldes nogle gange SFMEA og SFMECA, hvor S'et står for software. I de følgende afsnit bruges kun begrebet FMEA, men informationen gælder også for de andre tre metoder. Testere skal være i stand til at bidrage til fremstillingen af FMEA-dokumentet. Dette inkluderer forståelsen af formålet med og anvendelsen af disse dokumenter, såvel som evnen til at anvende viden som en hjælp til bestemmelsen af risikofaktorer.

3.10.1 Anvendelsesområder FMEA skal anvendes:

hvor det skal analyseres, hvor kritisk den vurderede software eller det vurderede system er, for at reducere risikoen ved afvigelse (f.eks. sikkerhedskritiske systemer som systemer til flykontrol)

hvor der gælder obligatoriske eller lovmæssige krav (se også afsnit 1.3.2 Sikkerhedskritiske systemer)

til fjernelse af defekter på tidlige stadier

til at definere specielle testovervejelser, operationelle begrænsninger og designbeslutninger for sikkerhedskritiske systemer.

3.10.2 Implementeringstrin FMEA bør planlægges til at finde sted, så snart der er foreløbige oplysninger tilgængeligt på et højt niveau, og den skal udvides til lavere niveauer, efterhånden som flere oplysninger bliver tilgængelige. FMEA kan anvendes på alle niveauer af system- eller softwareopdelingen afhængigt af de oplysninger, der er tilgængelige, og kravene til et program. Iterativt for hver kritisk funktion, modul eller komponent:

Vælg en funktion, og bestem dens mulige afvigelsestilstande, f.eks. hvordan funktionen kan afvige fra det forventede

Definer de mulige årsager til disse afvigelser, deres effekter og designmekanismer til reduktion eller mildning af afvigelserne

3.10.3 Fordele og omkostninger FMEA giver følgende fordele:

Forventede systemafvigelser, forårsaget af softwareafvigelser eller anvendelsesfejltagelser, kan afsløres.

Systematisk brug kan bidrage til analysen af det overordnede systemniveau.

Resultater kan bruges til designbeslutninger og/eller -begrundelser.

Resultater kan bruges til at fokusere testen på specifikke (kritiske) områder af softwaren. Der skal foretages følgende overvejelser i forbindelse med anvendelsen af FMEA:

Sekvensen af afvigelser overvejes sjældent.

Fremstillingen af FMEA-tabeller kan være tidskrævende.

Det kan være svært at definere uafhængige funktioner.

Fejlmultiplikation er muligvis ikke let at identificere.





3.11 Teststyringsovervejelser

3.11.1 Teststyringsovervejelser for udforskende test Sessionsbaseret teststyring (SBTM) er et koncept til styring af udforskende test. En session er basisenheden i testarbejdet, hvor arbejdet foregår uforstyrret med fokus på et bestemt testobjekt og med et specifikt testformål (testbeskrivelsen). Ved afslutningen af den enkelte session udarbejdes en rapport, der typisk kaldes et sessionsark, om de aktiviteter, der er udført. SBTM fungerer inden for en dokumenteret processtruktur, og det resulterer i journaler, der komplementerer verificeringsdokumentationen. En testsession kan opdeles i tre faser:

Sessionsopsætning: Opsætning af testmiljøet og forbedring af produktforståelsen

Testdesign og testafvikling: Afsøgning af testobjektet på jagt efter problemer

Undersøgelse af defekter og rapportering: Begynder, når testeren finder noget, der ser ud til at være en afvigelse.

SBTM-sessionsarket består af følgende:

Sessionsbeskrivelse

Navn på tester/testere

Startdato og -klokkeslæt

Opgaveopdeling (sessioner)

Datafiler

Testnoter

Problemer

Defekter Ved afslutningen af hver session afholder den testansvarlige et afrapporteringsmøde med gruppen. I forbindelse med afrapporteringen gennemgår den testansvarlige sessionsarkene, forbedrer beskrivelserne, får feedback fra testerne samt estimerer og planlægger yderligere sessioner. Dagsordnen for afrapporteringssessionen kan forkortes til PROOF, der står for følgende:

Past (fortid): Hvad skete der under sessionen?

Results (resultater): Hvad blev der opnået under sessionen?

Outlook (fremtiden): Hvad mangler der stadig at blive gjort?

Obstacles (forhindringer): Hvad kom i vejen for god testning?

Feelings (følelser): Hvad mener testeren om det hele?

3.11.2 Teststyringsovervejelser for systemer af systemer Følgende overvejelser hører til teststyring af systemer af systemer:

Teststyringen er mere kompleks, fordi testningen af de individuelle systemer, der udgør systemerne af systemer, muligvis foretages forskellige steder, af forskellige organisationer og ved brug af forskellige livscyklusmodeller. Derfor implementerer hovedtestplanen for systemerne af systemer typisk en formel livscyklusmodel, der lægger vægt på styringsspørgsmål så som milepæle og kvalitetsmål. Der er ofte en formelt defineret kvalitetssikringsproces, der kan være defineret i en separat kvalitetsplan.

Støtteprocesser, så som konfigurationsstyring, ændringsstyring og releasestyring, skal være formelt defineret, og grænsefladerne til teststyring skal være aftalt. Disse processer er nødvendige for at sikre, at softwareleverancerne kontrolleres, at ændringer foretages på en styret måde, og at softwarebaselines, der testes, er defineret.

Konstruktionen og styringen af repræsentative testmiljøer, inklusive testdata, kan være en stor teknisk og organisatorisk udfordring.

Integrationsteststrategien kan kræve, at simulatorer skal konstrueres. Mens dette kan være relativt enkelt og billigt ved integrationstest på tidlige testniveauer, kan konstruktionen af simulatorer til hele systemer være kompleks og dyr på de højere niveauer af integrationstest, der findes i systemer af systemer. Planlægning, estimering og udvikling af simulatorer styres ofte som et separat projekt.





Afhængighederne mellem de forskellige dele ved test af systemer af systemer giver yderligere begrænsninger af system- og accepttestene. Det kræver også yderligere fokus på systemintegrationstest og de tilhørende testbasisdokumenter, f.eks. grænsefladespecifikationer.

3.11.3 Teststyringsovervejelser for sikkerhedskritiske systemer Følgende overvejelser hører til teststyring af sikkerhedskritiske systemer:

Branchespecifikke (domæne) standarder er normalt gældende (f.eks. inden for transportindustrien, medicinalindustrien og militæret). Disse kan gælde for udviklingsprocessen og den organisatoriske struktur, eller for det produkt, der udvikles. Se kapitel 6 for yderligere detaljer.

På grund af de ansvarsmæssige spørgsmål i forbindelse med sikkerhedskritiske systemer, kan formelle aspekter så som sporbarhed af krav, testdækningsniveauer, der skal opnås, acceptkriterier, der skal opnås, og krævet testdokumentation være nødvendige for at vise, at kravene er overholdt.

Til at vise overensstemmelse med den organisatoriske struktur og med udviklingsprocessen er det muligvis tilstrækkeligt med revision og organisationsdiagrammer.

En foruddefineret udviklingslivscyklus følges afhængigt af den gældende standard. Sådanne livscyklusser har typisk en sekventiel natur.

Hvis et system er blevet kategoriseret som "kritisk" af en organisation, skal følgende ikke-funktionelle forhold behandles i teststrategien og/eller testplanen:

o Pålidelighed (Reliability) o Tilgængelighed (Availability) o Vedligeholdelsesegnethed (Maintainability) o Personsikkerhed og datasikkerhed (Safety and security)

3.11.4 Andre teststyringsovervejelser Manglende planlægning af ikke-funktionelle test kan udgøre en væsentlig fare for et systems succes. Mange typer af ikke-funktionelle test er imidlertid forbundet med høje omkostninger, der skal afbalanceres i forhold til risiciene. Der er mange forskellige typer ikke-funktionelle test, hvoraf ikke alle nødvendigvis er gældende for et givet system. Følgende faktorer kan påvirke planlægningen og udførelsen af ikke-funktionelle test:

Interessentkrav

Krævede værktøjer

Krævet hardware

Organisatoriske faktorer

Kommunikation

Datasikkerhed.

3.11.4.1 Interessentkrav

De ikke-funktionelle krav er ofte dårligt specificeret eller endog ikke-eksisterende. På planlægningsstadiet skal testere være i stand til at indhente forventningsniveauer fra de berørte interessenter og evaluere de risici, disse repræsenterer. Det anbefales at indhente flere synspunkter, når der indsamles krav. Kravene skal være indsamlet fra interessenter så som kunder, brugere, driftspersonale og vedligeholdelsespersonale, ellers er der fare for, at nogle krav overses. De følgende hovedpunkter skal overvejes for at forbedre testbarheden af ikke-funktionelle krav:

Krav læses oftere, end de skrives. Det betaler sig næsten altid at investere i at specificere testbare krav. Brug et enkelt sprog, der er konsistent og præcist (dvs. brug det sprog, der er defineret i projektets data model). Specielt skal man være forsigtig med brugen af ord som "skal" (dvs. obligatorisk), "bør" (dvs. ønskeligt) og "må" (skal helst undgås eller bruges som et synonym for "skal").

Læserne af kravene kommer fra forskellige baggrunde.

Krav skal skrives klart og præcist for at undgå flere fortolkninger. Der skal bruges et standardformat til alle krav.





Specificer kravene kvantitativt, hvor det er muligt. Tag en beslutning om den passende metrik til at udtrykke en attribut (f.eks. performance målt i millisekunder), og angiv en båndbredde, inden for hvilken resultaterne kan evalueres som accepterede eller afviste. For bestemte ikke-funktionelle attributter (f.eks. brugbarhed) er det muligvis ikke let.

3.11.4.2 Nødvendige værktøjer

Kommercielle værktøjer eller simulatorer er specielt relevante for performance-, effektivitets- og nogle dele af sikkerhedstest. Testplanlægningen bør omfatte et estimat af omkostningerne og tidsplanerne for anvendelse af værktøjer. Når der bruges specialistværktøjer, skal planlægningen tage højde for indlæringskurverne for nye værktøjer eller omkostningen ved ansættelse af eksterne værktøjsspecialister. Udviklingen af en kompleks simulator kan være et udviklingsprojekt i sig selv, og det skal planlægges som et sådant. Specielt skal planlægningen af simulatorer til brug i sikkerhedskritiske programmer tage højde for accepttesten og en mulig certificering af simulatoren foretaget af en uafhængig instans.

3.11.4.3 Nødvendig hardware

Mange ikke-funktionelle tests kræver et produktionslignende testmiljø for at kunne levere realistiske måleresultater. Afhængig af størrelsen og kompleksiteten af det system, der skal testes, kan dette have en væsentlig indflydelse på planlægningen og finansiering af testene. Omkostningerne ved afvikling af ikke-funktionelle test kan være så høje, at der kun er en begrænset tid til rådighed til testafviklingen. F.eks. kan verifikation af kravene til skalerbarhed for et velbesøgt websted på internettet beyde, at der skal foretages en simulering af tusindvis af virtuelle brugere. Dette kan have en betydelig indflydelse på omkostningerne til hardware og værktøjer. Da disse omkostninger typisk minimeres gennem leje af (f.eks. "top-up") licenser til performanceværktøjer, er den tilgængelige tid til sådanne test begrænset. Udførelsen af brugbarhedstest kan kræver opstilling af skræddersyede laboratorier eller gennemførelse af omfattende spørgeskemaundersøgelser. Disse tests udføres typisk kun én gang i en udviklingslivscyklus. Mange andre typer af ikke-funktionelle test (f.eks. sikkerhedstest og performancetest) kræver et produktionslignende miljø til afvikling. Da omkostningen ved sådanne miljøer kan være høj, kan brugen af selve produktionsmiljøet være den eneste praktiske mulighed. Timingen af sådanne testafviklinger skal planlægges omhyggeligt, og det er meget sandsynligt, at de kun kan afvikles på bestemte tidspunkter (f.eks. om natten). Der skal være planlagt fremskaffelse af computere og kommunikationsbåndbredde til de tidspunkter, hvor effektivitetsrelaterede tests (f.eks. performance og belastning) skal udføres. Behovene afhænger primært af antallet af virtuelle brugere, der skal simuleres, og mængden af netværkstrafik, som de forventes at generere. Hvis der ikke tages højde for dette, kan det resultere i, at der foretages performancemålinger, der ikke er repræsentative.

3.11.4.4 Organisatoriske overvejelser

ikke-funktionelle test kan omfatte målingen af adfærden i adskillige komponenter i et komplet system (f.eks. servere, databaser og netværk). Hvis disse komponenter er distribueret på tværs af et antal forskellige websteder og organisationer, kan det kræve et betydeligt arbejde at planlægge og koordinere testene. Visse softwarekomponenter er f.eks. kun tilgængelige for systemtest på bestemte tidspunkter af dagen eller året, eller organisationer tilbyder kun support til test i et begrænset antal dage. Hvis man ikke sørger for at få bekræftet, at systemkomponenter og medarbejdere fra andre organisationer er parate "efter behov" til testformål, kan det resultere i alvorlige afbrydelser af de planlagte tests.

3.11.4.5 Overvejelser om kommunikation

Muligheden for at specificere og køre bestemte typer af ikke-funktionelle test (især effektivitetstest) kan afhænge af muligheden for at ændre specifikke kommunikationsprotokoller til testformål. På planlægningsstadiet skal man være omhyggelig med at sikre, at dette er muligt (f.eks. at værktøjerne giver den krævede kompatibilitet).

3.11.4.6 Overvejelser om datasikkerhed

Specifikke sikkerhedsforanstaltninger, der er implementeret i et system, skal tages i betragtning i testplanlægningsfasen for at sikre, at alle testaktiviteter er mulige. Brugen af datakryptering kan f.eks. gøre det vanskeligt at oprette testdata og kontrollere resultaterne.





Databeskyttelsespolitikker og -love kan gøre det umuligt at oprette virtuelle brugere på basis af produktionsdata. Arbejdet med at gøre testdata anonyme kan være en ikke-triviel opgave, der skal planlægges som en del af testimplementeringen.





4. Testteknikker

Termer: BS 7925-2, grænseværdianalyse (BVA), forgreningstest, årsags-/virkningstest, klassifikationstræmetode, betingelsestest, bestemmende betingelsestest, kontrolflowsanalyse, D-D-sti, dataflowanalyse, beslutningstabeltest, beslutningstest, fejlbaseret teknik, fejltaksonomi, dynamisk analyse, fejlgætning, ækvivalenspartitionering, udforskende test, erfaringsbaseret teknik, LCSAJ, hukommelseslæk, multibetingelsestest, parvis test, stitest, kravbaseret test, softwareangreb, specifikationsbaseret teknik, statisk analyse, instruktionstest, tilstandsovergangstest, strukturbaseret teknik, testcharter, usecasetest, vild pointer.

4.1 Introduktion De testdesignteknikker, der gennemgås i dette kapitel, omfatter følgende kategorier:

Specifikationsbaseret (eller adfærdsbaseret eller black-box)

Strukturbaseret (eller white-box)

Defektbaseret

Erfaringsbaseret. Disse teknikker er komplementære og kan bruges efter behov til alle givne testaktiviteter, uanset hvilket niveau testen udføres på. Mens alle disse teknikker kan anvendes af testanalytikere og tekniske testanalytikere, er der i denne syllabus foretaget følgende opdeling på basis af den mest almindelige anvendelse:

Specifikationsbaseret → Testanalytikere og tekniske testanalytikere

Strukturbaseret → Tekniske testanalytikere

Erfaringsbaseret → Testanalytikere og tekniske testanalytikere

Defektbaseret → Testanalytikere og tekniske testanalytikere Ud over disse områder indeholder dette kapitel også en diskussion af andre teknikker, så som angreb, statisk analyse og dynamisk analyse. Disse teknikker udføres normalt af tekniske testanalytikere. Bemærk, at specifikationsbaseret teknikker enten kan være funktionelle eller ikke-funktionelle. Ikke-funktionelle teknikker gennemgås i næste kapitel.

4.2 Specifikationsbaseret Specifikationsbaserede teknikker er en metode til at udlede og vælge testbetingelser eller testcases baseret på en analyse af testbasis-dokumentationen for en komponent eller et system uden reference til dens interne struktur. Fælles egenskaber for specifikationsbaserede teknikker:

Modeller, enten formelle eller uformelle, bruges til specifikation af det problem, der skal løses i softwaren eller dens komponenter.

Fra disse modeller kan der foretages en systematisk udledning af testcases. Nogle teknikker giver også dækningskriterier, der kan bruges til måling af testdesignopgaven. At dækningskriteriet er fuldstændigt opfyldt betyder ikke, at hele testsættet er komplet, men i stedet at modellen ikke længere foreslår nyttige test på basis af denne teknik. Specifikationsbaserede test er ofte kravbaserede test. Da kravspecifikationen skal specificere, hvordan systemet skal opføre sig, især vedr. funktionalitet, er udledning af tests fra kravene ofte en del af testen af systemets opførsel. De teknikker, der ernævnt tidligere i dette underafsnit, kan anvendes direkte til kravspecifikationen, idet modellen for systemopførselfremstilles ud fra teksten eller graferne i selve kravspecifikationen, og derefter følger testene, som tidligere beskrevet.





I denne syllabus for Advanced Level gennemgås følgende specifikationsbaserede testdesignteknikker: Navn Teknik Dækningskriterier

Ækvivalenspartitionering

Se en beskrivelse i ISTQB® Foundation Syllabus afsnit 4.3.1

Antal dækkede partitioner / totalt antal partitioner.

Grænseværdianalyse (BVA)

Se en beskrivelse i ISTQB® Foundation Syllabus afsnit 4.3.2. Bemærk, at BVA kan anvendes med brug af enten 2 eller 3 værdier. Beslutningen om, hvilken mulighed, der skal anvendes, er mest sandsynligt risikobaseret.

Antal dækkede særskilte grænseværdier / totalt antal grænseværdier

Beslutningstabeltest og årsags-/virkningsgraf

Se en beskrivelse af beslutningstabeltest i ISTQB® Foundation Syllabus afsnit 4.3.3 Ved beslutningstabeltest testes alle kombinationer af betingelser, relationer og begrænsninger. Udover beslutningstabeller kan der også bruges en grafisk teknik, der anvender en logisk notation; den hedder årsags-/virkningsgraf. Bemærk, at ved siden af test af alle kombinationer af betingelser, er det også muligt at anvende komprimerede tabeller. Beslutningen om brug af beslutningstabeller eller komprimerede beslutningstabeller er mest sandsynligt risikobaseret. [Copeland03]

Antal dækkede betingelseskombinationer / maksimalt antal betingelseskombinationer.

Tilstandsovergangstest


For enkelte overgange er dækningsmetrikken den procentdel af alle gyldige overgange, der er undersøgt under test. Dette er kendt som 0-switch dækning. For n overgange er dækningsmetrikken den procentdel af alle gyldige sekvenser af n overgange, der er undersøgt under test. Dette er kendt som (n-1)-switch dækning.

Klassifikationstræmetode, ortogonale arrays og tabeller med alle par

Faktorer eller variabler af interesse og de indstillinger eller værdier, disse kan antage, er identificeret, og enkeltværdier, par, tredobbelte værdier eller endnu højere kombinationer af disse indstillinger eller værdier er identificeret. [Copeland03] Klassifikationstræmetoden bruger en grafisk notation til at vise de testbetingelser (klasser) og kombinationer, der behandles af testcasene [Grochtmann94]

Afhænger af den anvendte teknik, f.eks. er parvis forskellig fra klassifikationstræer.





Usecase test


Der gælder ingen formelle kriterier.

Nogle gange kombineres teknikker for at fremstille tests. F.eks. kan de betingelser, der er angivet i en beslutningstabel, gennemgå en ækvivalenspartitionering for at fastlægge flere måder, en betingelse kan opfyldes på. Test dækker derved ikke kun alle betingelseskombinationer, men for de betingelser, der er blevet opdelt, vil der også blive genereret yderligere tests, der dækker ækvivalenspartitionerne.

4.3 Strukturbaseret En strukturbaseret testdesignteknik, der også er kendt som white-box eller kodebaseret testteknik, er en teknik, i hvilken koden, dataene, arkitekturen eller systemflowet bruges som basis for testdesign, og hvor tests afledes systematisk fra strukturen. Teknikken bestemmer de elementer i strukturen, der skal tages i betragtning. Teknikken giver også dækningskriterier, der fortæller, hvornår testafledningen kan stoppe. Disse kriterier betyder ikke, at hele testsættet er komplet, men i stedet, at den behandlede struktur ikke længere foreslår nogle nyttige test på basis af denne teknik. Hvert kriterium skal måltesog knyttets til et mål, der er defineret for hvert projekt eller virksomhed. Fælles egenskaber for strukturbaserede teknikker:

Oplysninger om, hvordan softwaren er opbygget, bruges til at udlede testcases, f.eks. kode og design.

Omfanget af dækningen af softwaren kan måles for eksisterende testcases, og yderligere testcases kan udledes systematisk for at forøge dækningen.

I denne syllabus for Advanced Level gennemgås følgende strukturbaserede testdesignteknikker: Navn

Teknik Dækningskriterium

Instruktionstest

De eksekverbare (ikke-kommentar, ikke-blanke) instruktioner identificeres.

Antal ueksekverede instruktioner / totalt antal instruktioner

Beslutningstest

Beslutningsinstruktionerne, så som if/else-, switch/case-, for- og while-instruktioner, identificerets

Antal ueksekverede beslutningsresultater / totalt antal beslutningsresultater.

Forgreningstest

Forgreningerne, så som if/else-, switch/case-, for- og while-instruktioner, identificeres. Bemærk, at beslutnings- og forgreningstest er det samme ved en dækning på 100 %, men kan være forskellige på lavere dækningsniveauer

Antal eksekverede forgreninger / totalt antal forgreninger

Betingelsestest True/false og case-labels identificeres Antal eksekverede booleske

operandværdier / totalt antal booleske operandværdier

Multibetingelsestest Alle mulige kombinationer af true/false betingelser

identificeres. Antal eksekverede kombinationer af booleske operandværdier / totalt antal kombinationer af booleske operandværdier

Bestemmende betingelsestest

Alle mulige kombinationer af true/false-betingelser, der kan påvirke beslutninger (forgreninger), identificeres.

Antal booleske operandværdier, der uafhængigt påvirker beslutninger / otalt





antal booleske operandværdier

LCSAJ (looptest)

De mulige betingelser, der kontrollerer loop-iteration, identificeres. LCSAJ (Linear Code Sequence and

Jump) bruges til at teste et specifikt afsnit af koden (en lineær sekvens af eksekverbar kode), der starter ved begyndelsen af et bestemt kontrolflow og ender i et spring til et andet kontrolflow eller et spring til slutningen af programmet. Disse kodefragmenter er også kendt som DD-stier (for decision-to-decision-sti). Denne teknik bruges til at definere specifikke testcases og de tilhørende testdata, der kræves for at eksekvere det valgte kontrolflow. Udarbejdelse af disse test kræver adgang til en model af kildekoden, der definerer springene i kontrolflowet. LCSAJ kan bruges som basis for måling af kodedækning.

Antal eksekverede LCSAJ'er / totalt antal LCSAJ'er

Stitest

De entydige sekvenser af instruktioner (stier) identificeres.

Antal eksekverede stier / totalt antal stier

En almindelig anvendelse af strukturel dækningskriterium er at måle hvor komplet eller mangelfuld et sæt af tests, der er designet ved brug af specifikationsbaserede og/eller erfaringsbaserede teknikker, er. Testværktøjer kaldet kodedækningsværktøjer bruges til at bestemme den strukturelle dækning, der opnås ved disse test. Hvis der registreres vigtige huller i den strukturelle dækning (eller hvis den dækning, der kræves af relevante standarder, ikke er nået), så tilføjes der tests, der kan lukke disse huller, ved brug af strukturelle teknikker og andre teknikker.

Dækningsanalyse

Der kan udføres dynamisk test ved brug af strukturbaserede teknikker eller andre teknikker for at bestemme, om der er opnået en bestemt kodedækning eller ej. Dette bruges som bevismateriale i forbindelse med kritiske systemer, hvor det kræves, at der opnås en specifik dækning (se også afsnit 1.3.2 Sikkerhedskritiske systemer). Resultaterne kan vise, at nogle sektioner af koden ikke er undersøgt, og det fører til, at der defineres yderligere testcases til undersøgelse af disse sektioner.





4.4 Defekt- og erfaringsbaseret

4.4.1 Defektbaserede teknikker En defektbaseret testdesignteknik er en teknik, i hvilken den søgte fejltype bruges som basis for testdesign, og hvor tests systematisk ud edes fra, hvad der vides om defekten. Teknikken giver også dækningskriterier, der bruges til at bestemme, hvornår testudledningen kan stoppe. I praksis er der en tendens til, at dækningskriterierne for defektbaserede teknikker er mindre systematiske, end de er for adfærdsbaserede og strukturbaserede teknikker, forstået på den måde at de generelle regler for dækning er givet, og den specifikke beslutning om, hvad der udgør grænsen for nyttig dækning, skønnes under testdesign eller testafvikling. Dækningskriteriet betyder ikke, at heke testsættet er komplet, men i stedet, at de overvejede defekter ikke længere foreslår nogle nyttige test på basis af denne teknik. I denne syllabus for Advanced Level gennemgås følgende defekbaserede testdesignteknikker: Navn Teknik Dækningskriterium

Taksonomier (kategorier og lister over potentielle defekter)

Testeren, der bruger taksonomieksempler fra listen, vælger et potentielt problem, der skal analyseres. Taksonomier kan opliste underliggende årsager, defekter og afvigelser. Defekttaksonomier oplister de mest almindelige defekter i softwaren under test. Listen bruges til at designe testcases.

Relevante datadefekter og defekttyper.

4.4.2 Erfaringsbaserede teknikker Der er andre testdesignteknikker, der tager hensyn til defekthistorikken, men ikke nødvendigvis har kriterier for systematisk dækning. Disse kategoriseres som erfaringsbaserede testteknikker Erfaringsbaserede test udnytter testernes evner og intuition sammen med deres erfaring med lignende programmer eller teknologier. Disse test er effektive til defektfinding, men ikke så egnede som andre teknikker, når det gælder om at opnå specifikke testdækningsniveauer eller at frembringe testprocedurer, der kan genbruges. Når der bruges dynamiske eller heuristiske metoder, har testere en tendens til at bruge erfaringsbaserede test, og testen er mere reaktiv i forhold til hændelser end tilgange, der er planlagt på forhånd. Desuden er afvikling og evaluering sideløbende opgaver. Nogle strukturerede tilgange til erfaringsbaseret test er ikke fuldstændig dynamiske, dvs. at testene ikke udelukkende fremstilles på samme tid, som de afvikles. Bemærk, at selv om der er præsenteret nogle ideer om dækning i den følgende tabel, så har erfaringsbaserede teknikker ikke formelle dækningskriterier.





Her!I denne syllabus gennemgås følgende erfaringsbaserede testdesignteknikker:

Navn Teknik Dækningskriterium

Fejlgætning

Testeren bruger erfaring til at gætte på potentielle fejl, der kan være begået, og bestemmer metoderne til at afsløre de resulterende defekter. Fejlgætning er også nyttig til identificering af potentielle afvigelsestilstande under risikoanalyse. [Myers97]

Når der bruges en taksonomi, passende datafejl og defekttyper. Uden en taksonomi begrænses dækningen af testerens erfaring og den tilgængelige tid.

Checklistebaseret Den erfarne test bruger en højniveau liste

med elementer der skal noteres, kontrolleres eller huskes, eller et sæt af regler eller kriterier, som et produkt skal kontrolleres i forhold til. Disse checklister er fremstillet på basis af et sæt af standarder, erfaring og andre overvejelser. En checkliste med brugergrænseflade- standarder anvendt som basis for test af et program, er et eksempel på en checklistebaseret test.

Hvert element på checklisten er dækket.

Udforskende

Testeren får viden om produktet og dets defekter, planlægger det testarbejde, der skal udføres, designer og afvikler testene og rapporterer resultaterne samtidig. Gode udforskende test ser planlagte, interaktive og kreative. Testeren justerer testmålene løbende under afviklingen og forbereder kun dokumentation i letvægtsklassen. [Veenendaal02]

Chartre, der specificerer opgaver, mål og leverancer kan fremstilles, og en udforskende testsession, der angiver, hvad der skal opnås, hvor der skal fokuseres, hvad der er omfattet og ikke omfattet, og hvilke ressourcer der skal afsættes planlægges. Desuden skal der overvejes, om der skal udarbejdes et sæt heuristikker om defekter og kvalitet.

Angreb Testeren foretager en styret og fokuseret

evaluering af systemkvaliteten ved at forsøge at få bestemte afvigelser til at opstå. Princippet for softwareangreb, som beskrevet i [Whittaker03], er baseret på interaktionerne mellem softwaren under test og det miljø den kører i. Dette omfatter brugergrænsefladen, operativsystem med systemkerne, API'erne og filsystemerne. Disse interaktioner er baseret på præcise udvekslinger af data. Enhver uoverensstemmelse i én (eller flere) af interaktionerne kan være årsag til en afvigelse.

De forskellige grænseflader i det testede program. Hovedgrænsefladerne er brugergrænsefladen, operativsystem, kerne, API'er og filsystem.

Defekt- og erfaringsbaserede teknikker anvender viden om defekter og andre erfaringer til at forøge afsløringen af defekter. De går fra "huritgtest”, hvor testeren ikke har nogle formelle, forudplanlagte aktiviteter at udføre over sessioner, der er planlagt på forhånd, til sessioner baseret på scripts. De er næsten altid nyttige, men har især værdi under følgende omstændigheder:

Der er ingen specifikationer tilgængelige.

Der er dårlig dokumentation af det testede system.

Der er ikke tildelt tilstrækkelig tid til at designe eller fremstille testprocedurer.

Testere har erfaring inden for området og/eller teknologien.





Der søges variation iforhold til script-baseret test.

Analyse af driftsmæssige afvigelser. Defektl- og erfaringsbaserede teknikker er også nyttige, når de bruges i sammenhæng med adfærds- og strukturbaserede teknikker, da de udfylder de huller i testdækningen, der stammer fra systematiske svagheder i disse teknikker.

4.5 Statisk analyse Statisk analyse handler om test uden at softwaren under test faktisk eksekveres , og kan være for koden eller systemarkitekturen.

4.5.1 Statisk analyse af kode Statisk analyse er enhver form for test eller undersøgelse, der kan foretages, uden at koden eksekveres. Der er et antal teknikker til statisk analyse, og disse gennemgås i dette afsnit.

4.5.1.1 Kontrolflowanalyse

Kontrolflowanalyse giver oplysninger om de logiske beslutningspunkter i softwaresystemet og kompleksiteten i deres struktur. Kontrolflowanalyse er beskrevet i ISTQB® Foundation Level Syllabus og i [Beizer95].

4.5.1.1 Dataflowanalyse

Dataflowanalyse er en struktureret testteknik, der tester stierne fra det sted, hvor en variabel er sat, til det sted, hvor den efterfølgende bruges. Disse stier betegnes definition-anvendelsespar (da-par) eller sæt-anvendelsespar. I denne metode genereres testsæt for at opnå 100 % dækning (hvor det er muligt) for hvert af disse par. Selv om denne teknik betegnes dataflowanalyse, behandler den også kontrolflowet i softwaren under test, da den følger sætningen og brugen af hver variabel og muligvis skal bevæge sig gennem kontrolflowet i softwaren. Se også [Beizer95]

4.5.1.3 Overholdelse af kodningsstandarder

Under statisk analyse kan overholdelsen af kodningsstandarder også evalueres. Kodningsstandarder dækker både de arkitekturmæssige aspekter og brugen (eller forbud mod brugen) af visse programmeringsstrukturer. Overholdelse af kodningsstandarder gør softwaren med vedligeholdelsesvenlig og testbar. Specifikke sprogkrav kan også kontrolleres ved brug af statisk test.

4.5.1.4 Generering af kodemetrikker

Kodemetrikker, der vil bidrage til en højere grad af vedligeholdelsesvenlighed eller pålidelighed i koden, kan genereres under statisk analyse. Eksempler på sådanne metrikker er:

Cyklomatisk kompleksitet

Størrelse

Kommentar frekvens

Antal hægtede niveauer

Antal funktionskald.

4.5.2 Statisk analyse af arkitektur

4.5.2.1 Statisk analyse af et websted

Arkitekturen af et websted kan også vurderes ved brug af statiske analyseværktøjer. Her er målet at kontrollere, om den trælignende struktur på webstedet er velafbalanceret, eller om der er en ubalance, der kan føre til:

Vanskeligere testopgaver

Forøget arbejdsbyrde for vedligeholdelse

Vanskelig navigation for brugeren.





Nogle specifikke testværktøjer, der omfatter et webspider-program, kan også ved hjælp af statisk analyse levere oplysninger om størrelsen af siderne, om den tid, der er nødvendig for at overføre dem, og om en side findes eller ej (dvs. HTTP-fejl 404). Dette giver nyttige oplysninger til udvikleren, webmasteren og testeren.

4.5.2.2 Kaldegrafer

Kaldegrafer kan bruges til flere forskellige formål:

Design af test, der kalder det specifikke modul

Fastlæggelse af det antal steder i softwaren, hvorfra modulet kaldes

Fremsættelse af et forslag til integrationsrækkefølgen (parvis og nabovis integration [Jorgensen02])

Evaluering af strukturen for den totale kode og dens arkitektur. Oplysninger om kaldende moduler kan også fås fra dynamisk analyse. De indhentede oplysninger refererer til antallet af gange et modul kaldes under kørsel. Ved at samle oplysningerne, der er hentet fra kaldegrafer fra statisk analyse, med de oplysninger, der er indhentet under dynamisk analyse, kan testeren fokusere på moduler, der kaldes ofte og/eller gentagne gange. Hvis sådanne moduler også er komplekse (se 1.3.2.2 Sikkerhedskritiske systemer og kompleksitet) er de primære kandidater for detaljeret og omfattende test.

4.6 Dynamisk analyse Princippet i dynamisk analyse er at analysere et program, mens det kører. Det kræver ofte en form for instrumentering, der indsættes i koden enten manuelt eller automatisk.

4.6.1 Oversigt Fejl, der ikke umiddelbart kan reproduceres, kan have betydelige konsekvenser for testarbejdet og for muligheden for at frigive softwaren eller bruge den produktivt. Sådanne fejl kan skyldes hukommelseslæk, forkert brug af pointere og andre beskadigelser (f.eks. af systemstakken) [Kaner02]. På grund af disse fejls natur, der kan omfatte gradvis forværring af systemets performance eller endog systemnedbrud, skal teststrategierne tage højde for de risici, der er knyttet til disse fejl, og når det er passende, udføre dynamisk analyse for at reducere dem (typisk ved brug af værktøjer). Dynamisk analyse udføres, mens softwaren eksekveres. Den kan anvendes for at:

• Forhindre afvigelser i at opstå ved at finde vilde pointere og tab af systemhukommelse • Analysere systemafvigelser, der ikke er lette at reproducere • Vurdere netværksadfærd • Forbedre systemperformance ved at indhente oplysninger om systemets adfærd under kørsel.

Dynamisk analyse kan udføres på alle testniveauer, men det er især nyttigt i komponent- og integrationstest. Der kræves tekniske og systemmæssige evner for at angive testmålene for dynamisk analyse og især for at analysere resultaterne.

4.6.2 Afdækning af hukommelseslæk En hukommelseslæk optræder, når hukommelsen (RAM), der er tilgængelig for programmet, allokeres af programmet, men efterfølgende ikke frigives på grund af programmeringsfejl. Programmet mister derved muligheden for at få adgang til dette stykke hukommelse og kan til sidst løbe tør for brugbar hukommelse. Hukommelseslæk kan forårsage problemer, der udvikler sig over tid og muligvis ikke altid er åbenlyse med det samme. Dette kan være tilfældet, hvis softwaren f.eks. er installeret for nylig, eller systemet er genstartet, hvilket ofte sker under test. Af disse årsager bemærkes de negative effekter af hukommelseslæk ofte først, når programmet er i produktion.





Symptomerne på hukommelseslæk er en stadig forværring af systemets svartid, der i sidste ende kan føre til systemafvigelse. Selv om sådanne afvigelser muligvis kan løses ved genstart (re-boot) af systemet, er dette ikke altid praktisk eller muligt. Værktøjer identificerer områder i koden, hvor der opstår hukommelseslæk, så de kan rettes. Enkle hukommelsesovervågningsprogrammer kan også bruges til at opnå et generelt indtryk af, om den tilgængelige hukommelse reduceres over tiden, selvom der stadig kræves en opfølgningsanalyse, hvis dette er tilfældet. Der er andre typer læk, der bør tages i betragtning. Det gælder f.eks. filhåndtag, flag og forbindelsegrupper for ressourcer.

4.6.3 Registrering af vilde pointere "Vilde" pointere i et program er pointere, der på en eller anden måde ikke er brugbare. De kan f.eks. have "mistet" det objekt eller den funktion, de skulle pege på, eller de peger ikke på det forventede område af hukommelsen (f.eks. ud over de allokerede grænser for et array). Når et program bruger vilde pointere, kan der opstå forskellige konsekvenser:

1. Programmet kører muligvis som forventet. Dette kan være tilfældet, når den vilde pointer har adgang til hukommelse, der i øjeblikket ikke bruges af programmet og teoretisk er "fri".

2. Programmet går muligvis ned. I dette tilfælde har den vilde pointer muligvis forårsaget, at der bruges en del af hukommelsen, der er kritisk for kørslen af programmet (f.eks. operativsystemet).

3. Programmet fungerer ikke korrekt, fordi der ikke er adgang til objekter, der kræves af programmet. Under disse omstændigheder fungerer programmet måske stadigvæk, selv om der kan være sendt en fejlmeddelelse.

4. Data kan væreødelagt af pointeren, og forkerte værdier Efterfølgende brugt. Bemærk, at alle ændringer, der foretages i et programs anvendelse af hukommelse (f.eks. et nyt build som følge af en softwareændring), kan udløse en hvilken som helst af de fire konsekvenser, der er listet ovenfor. Det er især kritisk, når programmet kører som forventet i starten på trods af anvendelsen af vilde pointere, og derefter uventet går ned (måske endda i produktion) efter en softwareændring. Det er vigtigt at bemærke, at sådanne afvigelser er symptomer på en underliggende defekt (dvs. den vilde pointer), men ikke selv er defekten. (Se mere i [Kaner02], "Lesson 74"). Værktøjer kan identificere vilde pointere, da de bruges af programmet uanset deres konsekvenser for programmets afvikling.

4.6.4 Analyse af performance Der kan udføres dynamisk analyse for at analysere programmets performance. Værktøjer hjælper med at identificere flaskehalse i performance, og de genererer en bred vifte af performancemetrikker, der kan bruges af udvikleren til at "tune" systemet. Det kaldes også "performanceprofilering”.





5. Test af softwarekarakteristika

Termer Adgangstest, nøjagtighedstest, effektivitetstest, heuristisk vurdering, tværoperationalitetstest, vedligeholdelsesegnethedstest, driftsaccepttest (OAT), operationel profil, flytbarhedstest, genoprettelsestest, model for pålidelighedsvækst, pålidelighedstest, sikkerhedstest, egnethedstest, SUMI, brugervenlighedstest

5.1 Introduktion Mens det tidligere kapitel beskrev de specifikke teknikker, der er tilgængelige for testeren, så beskriver dette kapitel anvendelsen af disse teknikker til vurdering af de hovedattributter, der bruges til at beskrive kvaliteten af softwareprogrammer eller systemer. I denne syllabus gennemgås de kvalitetsattributter, der kan blive vurderet af en testanalytiker og en teknisk testanalytiker i separate afsnit. Beskrivelsen af kvalitetsattributterne fra ISO 9126 bruges som rettesnor for beskrivelsen af attributterne. En forståelse af de forskellige kvalitetsattributter er et grundlæggende læringsmål i alle tre moduler. Afhængigt af den specifikke kvalitetsattribut, der dækkes, skabes en dybere forståelse enten i testanalytiker-modulet eller teknisk testanalytiker-modulet, så de typiske risici kan fastslås, passende teststrategier kan udvikles og testcases kan specificeres.

5.2 Kvalitetsattributter i domænetest Funktionel test fokuserer på, "hvad" produktet gør. Testgrundlaget for funktionel test er generelt et kravs- eller specifikationsdokument, specifik domæneviden eller et forudsat behov. Funktionelle tests varierer i forhold til det testniveau eller den testfase, de udføres på. F.eks. tester en funktionel test, der udføres under integrationstest, funktionaliteten i samarbejdende moduler, der tilsammen implementerer en enkelt defineret funktion. På systemniveau omfatter funktionelle tests en test af programmets funktionalitet som helhed. For systemer af systemer fokuserer funktionel test primært på test fra start til slut på tværs af integrerede systemer. Der anvendes et bredt udvalg af testteknikker under funktionel test (se afsnit 4). Funktionel test kan udføres af en dedikeret tester, en domæneekspert eller en udvikler (normalt på komponentniveau). Følgende kvalitetsattributter tages med i overvejelserne:

• Nøjagtighed • Egnethed • Tværoperationalitet • Funktionel sikkerhed • Brugervenlighed • Tilgængelighed

5.2.1 Nøjagtighedstest Funktionel nøjagtighed omfatter test af programmets overholdelse af de specificerede eller forudsatte krav og kan også omfatte beregningsmæssig nøjagtighed. Nøjagtighedstest anvender mange af de testteknikker, der er forklaret i kapitel 4.

5.2.2 Egnethedstest Egnethedstest omfatter evaluering og validering af hensigtsmæssigheden af et sæt af funktioner i forhold til de opgaver, de er tiltænkt at skulle løse. Denne test kan være baseret på usecases eller procedurer.





5.2.3 Tværoperationalitetstest Tværoperationalitetstest tester om et givet program kan fungere korrekt i alle tiltænkte slutmiljøer (hardware, software, middleware, operativsystem etc.). Specificering af test for tværoperationalitet kræver, at kombinationer af de tiltænkte slutmiljøer er identificeret, konfigureret og tilgængelige for testteamet. Disse miljøer testes derefter ved brug af et udvalg af funktionelle testcases, som aktiverer de forskellige komponenter, der er til stede i miljøet. Tværoperationalitet har at gøre med, hvordan forskellige softwaresystemer påvirker hinanden. Software, der har gode tværoperationelle egenskaber, kan let integreres med et antal andre systemer, uden at det kræver større ændringer. Antallet af ændringer og det arbejde, der kræves for at udføre disse ændringer, kan bruges som et mål for tværoperationalitet. Test af softwares tværoperationalitet kan f.eks. fokusere på følgende designegenskaber:

• Softwarens brug af industristandarder for kommunikation, så som XML • Softwarens evne til automatisk at registrere kommunikationsbehovene i de systemer, den arbejder

sammen med, og dens evne til at skifte tilsvarende. Tværoperationalitetstest kan være specielt vigtig for:

• virksomheder, der udvikler hyldesoftware (COTS - commercial off the shelf) og værktøjer udviklingen af systemer af systemer.

Denne form for test udføres primært i systemintegrationstest.

5.2.4 Funktionel sikkerhedstest Funktionel sikkerhedstest (indtrængningstest) fokuserer på softwarens evne til at forhindre uautoriseret adgang, uanset om det sker ved et uheld eller med forsæt, til funktioner og data. Brugerrettigheder, adgang og privilegier er indbefattet i denne test. Disse oplysninger skal være tilgængelige i systemets Specifikationer. Sikkerhedstest omfatter også et antal aspekter, der er mere relevante for tekniske testanalytikere, og som behandles i afsnit 5.3 nedenfor.

5.2.5 Brugervenlighedstest Det er vigtigt at forstå, hvorfor brugere kan have problemer med at bruge det foreslåede softwaresystem. For at gøre dette, er det først nødvendigt at forstå, at termen "bruger” kan gælde for en lang række forskellige persontyper, fra it-eksperter til børn eller personer med handicap. Nogle nationale institutioner (f.eks. British Royal National Institute for the Blind) anbefaler, at websider er tilgængelige for handicappede, blinde, personer med nedsat syn, personer med nedsat mobilitet, døve og brugere med nedsat opfattelsesevne. En kontrol af, at programmer og websteder er brugbare for de ovennævnte brugere, kunne også forbedre brugbarheden for alle andre. Brugervenlighedstest måler, hvor godt softwaren er tilpasset brugernes behov, og den er målrettet mod at måle følgende faktorer, som specificerede brugere kan opnå angivne mål for i bestemte miljøer og brugssammenhænge:

• Effektivitet: Softwarens evne til at give brugerne mulighed for at nå specificerede mål med nøjagtighed og fuldstændighed i en specificeret brugssammenhæng.

• Kosteffektivitet: Produktets evne til at sætte brugeren i stand til at anvende en passende mængde ressourcer i relation til den effektivitet, der er opnået i en specificeret brugssammenhæng.

• Tilfredshed: Softwareproduktets evne til at opfylde brugernes behov i en specificeret brugssammenhæng. De attributter, der kan måles, er følgende:

• Forståelighed: Attributter i softwaren, der påvirker den arbejdsindsats, der kræves af brugeren for at forstå det logiske koncept og dets anvendelighed.

• Læringsvenlighed: Attributter i softwaren, der påvirker den arbejdsindsats, der kræves af brugeren for at lære programmet at kende.

• Betjeningsvenlighed: Attributter i softwaren, der påvirker den arbejdsindsats, der kræves af brugeren for at udføre opgaver på en effektiv og besparende måde.

• Attraktivitet: Softwarens evne til at være populær hos brugeren. Evaluering af brugervenligheden har to formål:

• Fjernelse af brugervenlighedsdefekter (kaldes nogle gange formativ evaluering)





• Test i forhold til brugervenlighedskravene (kaldes nogle gange summativ evaluering). Testerens kvalifikationer skal omfatte ekspertise eller viden på følgende områder:

• Sociologi • Psykologi • Overholdelse af nationale standarder (f.eks. American Disabilities Act) • Ergonomi

Valideringen af den faktiske implementering bør foretages under omstændigheder, der er så tæt som muligt på de omstændigheder, som systemet skal bruges under. Dette kan involvere opsætningen af et brugervenlighedslaboratorium med videokameraer, attrapkontorer, review-paneler, brugere etc., så udviklingsmedarbejderne kan observere virkningen af det aktuelle system på virkelige personer. Mange brugervenlighedstest kan afvikles som en del af andre test, f.eks. under funktionel systemtest. For at opnå en konsistent tilgang til afdækning og rapporteringen af brugervenlighedsafvigelser på alle stadier af livscyklussen kan det være nyttigt med retningslinjer for brugervenlighed.

5.2.5.1 Specifikation af brugervenlighedstest

De principielle teknikker for brugervenlighedstest er følgende: • Inspektion, evaluering eller review • Gennemførelse af verificering og validering af den faktiske implementering • Gennemførelse af analyser og spørgeskemaundersøgelser.

Inspektion, evaluering eller review

Inspektion eller review af specifikationen og designsene ud fra et brugervenligheds synspunkt med forøget bruger- involveringsniveau, kan være en omkostningseffektiv måde at finde problemer ttidligt på. Heuristisk evaluering (systematisk inskektion af et brugergrænsefladedesign for brugervenlighed) kan bruges til at finde brugervenlighedsproblemer i designene, så de kan behandles som en del af den iterative designproces. Det betyder, at et lille antal evaluatorer undersøger brugergrænsefladen og afgør, om den overholder vedtagne brugervenlighedsprincipper ("heuristikker").

Validering af den faktiske implementering

Til udførelsen af validering af den faktiske implementering kan test, der er specificeret til funktionel systemtest, udvikles som testscenarier for brugervenlighedstest. Disse testscenarier måler specifikke brugervenlighedsattributter, f.eks. indlæringshastighed eller brugsegnethed, i stedet for det funktionelle resultat. Testscenarier for brugervenlighed kan udvikles, så de specifikt tester syntaks og semantik.

• Syntaks: strukturen eller grammatikken i brugergrænsefladen (f.eks. hvad kan der indtastes i et inputfelt) • Semantik: betydning og formål (f.eks. fornuftige og meningsfyldte systemmeddelelser og output til

brugeren). Teknikkerne, der kan bruges til at udvikle disse testscenarier kan omfatte:

• Black box-metoder, som beskrevet i f.eks. BS-7925-2 • Usecases, enten i ren tekst eller defineret med UML (Unified Modeling Language)

Testscenarier til brugervenlighedstest omfatter brugerinstruktioner, afsætter tid til interviews før og efter testen til at give instruktioner og modtage feedback samt en aftalt procedure for afviklingen af sessionerne. Denne procedureomfatter en beskrivelse af, hvordan testen skal udføres, tidsplaner, notetagning og sessionslogning og beskrivelse af de interview- og analysemetoder, der skal bruges.

Analyser og spørgeskemaundersøgelser

Teknikker til analyser og spørgeskemaundersøgelser kan anvendes til at indsamle observationer af brugernes adfærd i forhold til systemet i et brugervenlighedstestlaboratorium. Standardiserede og offentligt tilgængelige analyser som SUMI (Software Usability Measurement Inventory) og WAMMI (Website Analysis and MeasureMent Inventory) giver mulighed for benchmarking i forhold til en database over tidligere brugervenlighedsmåleresultater. Da SUMI giver konkrete måleresultater for brugervenlighed, giver det en god mulighed for at bruge disse som afslutnings-/acceptkriterier.





5.2.6 Tilgængelighedstest Det er vigtigt at vurdere softwarens tilgængelighed for dem med bestemte krav eller begrænsede muligheder for at bruge den. Dette omfatter personer med handicap. Der skal tages højde for de relevante standarder,så som Web Content Accessibility Guidelines, og for lovgivning, så som Disability Discrimination Acts (Storbritannien og Australien) og Section 508 (USA).

5.3 Kvalitetsattributter i teknisk test Kvalitetsattributter for tekniske testanalytikere fokuserer på, "hvordan" produktet fungerer, i stedet for på de funktionelle aspekter for, "hvad" programmet gør. Disse tests kan foretages på alle testniveauer, men de har speciel relevans for: Komponenttest (specielt realtidssystemer og indlejrede systemer)

• Benchmarkmåling af performance • Ressourceanvendelse

Systemtest og operationel accepttest (OAT)

• Omfatter alle de kvalitetsattributter og underattributter, der er nævnt nedenfor i forhold til risici og tilgængelige ressourcer

• T • Teknisk orienteret test på dette niveau er rettet mod test af et specifikt system, dvs. kombinationer af

hardware og software, herunder servere, klienter, databaser, netværk og andre ressourcer. Ofte fortsætter testene, efter at softwaren er gået i produktion, og de udføres ofte af en separat gruppe eller en separat organisation. Målleresultater for kvalitetsattributter, indsamlet under test før produktionen, kan danne grundlag for serviceniveauaftaler (SLA) mellem leverandøren og den organisation, der drifter softwaresystemet. Følgende kvalitetsattributter tages med i overvejelserne:

• Teknisk sikkerhed • Pålidelighed • Præstationsevne • Vedligeholdelsesegnethed • Flytbarhed.

5.3.1 Test af teknisk sikkerhed Sikkerhedstest afviger fra andre former for domæne eller teknisk test på to betydelige områder:

1. standardteknikker for valg af testinputdata rammer muligvis ikke vigtige sikkerhedsproblemer 2. symptomerne på sikkerhedsfejl er meget forskellige fra dem, der findes for andre typer test.

Mange sikkerhedssvagheder findes der, hvor softwaren ikke bare fungerer som designet, men også udfører ekstra handlinger, der ikke var tiltænkt. Disse sideeffekter udgør en af de største trusler mod softwaresikkerheden. En medieafspiller, der f.eks. afspiller lyd korrekt, men gør det ved at skrive filer ud på et ikke-krypteret temporært lager, udviser en sideeffekt, der muligvis kan udnyttes af softwarepirater. Hovedproblemet i forbindelse med sikkerhed er at forhindre, at uautoriserede personer kan få utilsigtet adgang til oplysninger. Sikkerhedstest forsøger at kompromittere et systems sikkerhedspolitik ved at vurdere systemets sårbarhed over for trusler, f.eks.:

• Uautoriseret kopiering af programmer eller data (f.eks. piratkopiering). • Uautoriseret adgangskontrol (f.eks. evnen til at udføre opgaver, som brugeren ikke har rettigheder til). • Bufferoverløb, der kan forårsages ved at indtaste ekstremt lange strenge i et inputfelt i

brugergrænsefladen. Når bufferoverløbet først er forårsaget, eksisterer der muligvis en mulighed for at køre skadelig kode.





• DoS (denial of service), der forhindrer brugerne i at kommunikere med et program (f.eks. ved at overbelaste en webserver med "plagsomme" forespørgsler).

• Afluring af dataoverførsler via netværk for at få fingre i følsomme oplysninger (f.eks. kreditkorttransaktioner).

• Brydning af de krypteringskoder, der bruges til at beskytte følsomme data. • Logiske bomber (nogen gange kaldet påskeæg i USA), der med skadelig hensigt er indsat i kode og som

kun aktiveres under bestemte betingelser (f.eks. på en bestemt dato). Når logiske bomber aktiveres, udfører de muligvis skadelige handlinger, som sletning af filer eller formatering af diske.

Bestemte sikkerhedsproblemer kan grupperes på følgende måde:

• Relateret til brugergrænsefladen o Uautoriseret adgang. o Skadelige input.

• Relateret til filsystemet o Adgang til følsomme data, der er gemt i filer eller lagre.

• Relateret til operativsystemet o Lagring af følsomme oplysninger, f.eks. adgangskoder, i ikke-krypteret form i hukommelsen.

Hvis et system går ned på grund af skadeligt input, kan det muligvis afsløre disse oplysninger. • Relateret til ekstern software

o Interaktioner, der muligvis kan forekomme mellem eksterne komponenter, som systemet bruger. Disse kan være på netværksniveauet (der sendes f.eks. forkerte pakker eller meddelelser) eller på softwarekomponentniveauet (f.eks. fejl i en softwarekomponent, som softwaren er afhængig af).

Det skal bemærkes, at forbedringer af sikkerheden i et system muligvis påvirker dets performance. Når der er foretaget forbedringer af sikkerheden, bør det overvejes at gentage testene af performance

5.3.1.1 Specifikation af sikkerhedstest

Der kan bruges følgende metode til udvikling af sikkerhedstest.

Udfør en indsamling af oplysninger Der konstrueres en profil eller et netværkskort over systemet ved brug af værktøjer, der er tilgængelige overalt. Disse oplysninger kan indeholde navne på ansatte, fysiske adresser, detaljer vedrørende de interne netværk, IP-numre, identiteten af den brugte software eller hardware og styresystemets version.

Udfør en sårbarhedsscanning. Systemet scannes med værktøjer, der er tilgængelige overalt. Sådanne værktøjer bruges ikke direkte til at kompromittere systemerne, men til at identificere sårbarheder, der er, eller som kan resultere i, brud på sikkerhedspolitikken. Specifikke sårbarheder kan også identificeres ved hjælp af checklister, f.eks. dem der findes på www.testingstandards.co.uk

Udform "angrebsplaner" (dvs. en plan for testhandlinger, der skal kompromittere et bestemt systems sikkerhedspolitik) ved hjælp af de indsamlede oplysninger. Der skal angives input via forskellige grænseflader (f.eks. brugergrænsefladen og filsystemet) i angrebsplanerne for at afsløre de alvorligste sikkerhedsfejl.

De forskellige "angreb", der er beskrevet i [Whittaker04] er en værdifuld kilde til teknikker, der er udviklet specielt til sikkerhedstest. Du kan finde flere oplysninger om "angreb" i afsnit 4.4.

5.3.2 Pålidelighedstest Målet med pålidelighedstesten er at overvåge en statistisk måling af softwarens modenhed over tid og sammenligne den med et ønsket pålidelighedsmål. Målingerne kan ske som gennemsnitstiden mellem fejl (MTBF), gennemsnitstiden mellem reparationer (MTTR) eller alle andre former for målinger af fejlintensiteter (f.eks. antallet af fejl pr. uge af en bestemt sværhedsgrad). Udviklingen af de målte værdier over tid kan udtrykkes som en model for pålidelighedsvækst. Pålidelighedstest kan have form af et gentaget sæt af forudbestemte test, tilfældige test, der er valgt fra en beholdning, eller testcases, der er genereret af en statistisk model. Som et resultat kan disse test tage betydelig tid (i antal dage). En analyse af målinger af softwarens modenhed over tid kan bruges som afslutningskriterier (f.eks. til produktionsudgivelse). Specifikke mål, f.eks. MTBF og MTTR, kan fastsættes som serviceniveauaftaler og overvåges i produktion.





SRET (Software Reliability Engineering and Testing) er en standardmetode til pålidelighedstest.

5.3.2.1 Test for robusthed

Mens funktionel test evaluerer softwarens tolerance over for fejl med hensyn til håndtering af uventede inputværdier (såkaldte negative test), så evaluerer teknisk orienterede test et systems tolerance over for fejl, der optræder uden for programmet under test. Sådanne fejl rapporteres typisk af operativsystemet (f.eks. disken er fuld, processen eller servicen er ikke tilgængelig, filen blev ikke fundet, hukommelsen er ikke tilgængelig). Test af fejltolerancer på systemniveau kan være understøttet af specifikke værktøjer.

5.3.2.2 Genoprettelsestest

Andre former for pålidelighedstest evaluerer softwaresystemets evne til at foretage genoprettelse efter hardware- eller softwarefejl på en forudbestemt måde, der efterfølgende tillader, at normal drift genoptages. Genoprettelsestest omfatter test af failover og test af sikkerhedskopiering og gendannelse. Failover-test udføres, når konsekvenserne af en softwarefejl er så store, at der er implementeret specifik hardware- og/eller softwareforanstaltninger for at sikre systemets drift, selv i tilfælde af en fejl. Failover-test kan f.eks. være relevante, hvor risikoen for finansielle tab er ekstreme, eller hvor der er kritiske sikkerhedsproblemer. Når fejlene muligvis er resultatet af katastrofale hændelser, kan denne type genoprettelsestest også kaldes test af "genoprettelse efter nedbrud". De typiske hardwareforanstaltninger kan omfatte belastningsudjævning over adskillige processorer, klyngedannelse af servere, processorer eller diske, så en anden enhed øjeblikkelig kan tage over, hvis der opstår fejl (f.eks. RAID (Redundant Array of Inexpensive Disks)). En typisk softwareforanstaltning kan være implementeringen af mere end én uafhængig forekomst af et softwaresystem (f.eks. flykontrolsystemet i en flyvemaskine) i såkaldte redundante, uens systemer. Redundante systemer består typisk af en kombination af software og hardware foranstaltninger og kan kaldes dobbelte, tredobbelte eller firdobbelte systemer afhængigt af antallet af uafhængige forekomster (henholdsvis 2, 3 eller 4). Den uens vinkel på softwaren opnås, når de samme softwarekrav sendes til to (eller flere) uafhængige og ikke forbundne udviklingsteams med det formål at få de samme ydelser leveret med forskellig software. Det beskytter de redundante uens systemer på den måde, at det samme fejlagtige input med mindre sandsynlighed giver det samme resultat. Disse forholdsregler, der er taget for at forbedre genoprettelsesevnen i et system, kan også direkte påvirke dets pålidelighed og skal muligvis også tages i betragtning, når der udføres pålidelighedstest. Failover-test er eksplicit designet til at teste sådanne systemer ved at simulere fejltilstande eller udføre dem i et kontrolleret miljø. Efter en fejl testes failover-mekanismen for at sikre, at data ikke er gået tabt eller er blevet forvansket, og at alle aftalte serviceniveauer er opretholdt (f.eks. funktioners tilgængelighed og svartid). Du kan få flere oplysninger om failover-test på www.testingstandards.co.uk. Test af sikkerhedskopiering og gendannelse fokuserer på de proceduremæssige foranstaltninger, der er sat i værk for at minimere effekten af en fejl. Disse test evaluerer procedurerne (normalt dokumenteret i en manual) for at foretage forskellige former for sikkerhedskopiering og gendannelse af data, hvis der skulle ske tab eller forvanskning af data. Testcases er designet for at sikre, at de kritiske veje gennem proceduren er dækket. Tekniske reviews kan udføres for at "simulere" disse scenarier og validere manualer i forhold til den faktiske installationsprocedure. Operationel accepttest (OAT) udfører scenarierne i et produktions- eller produktionslignende miljø for at validere deres faktiske brug. Målene for test af sikkerhedskopiering og gendannelse kan omfatte følgende:

• Den tid, det tager at udføre forskellige typer af sikkerhedskopiering (f.eks. fuld, trinvis). • Den tid, det tager at gendanne data. • Niveauer af garanteret datasikkerhedskopiering (f.eks. gendannelse af alle data, der ikke er mere end 24

timer gamle, gendannelse af specifikke transaktionsdata, der ikke er mere end en time gamle).

5.3.2.3 Specifikation af pålidelighedstest

Pålidelighedstest er for det meste baseret på brugsmønstre (nogle gange kaldet "Operationelle profiler") og kan udføres formelt eller i forhold til risiko. Testdata kan generes ved brug af tilfældigheds eller pseudo-tilfældighedsmetoder. Valget af pålidelighedsvækstkurven skal begrundes, og værktøjer kan bruges til at analysere et sæt af fejldata for at bestemme den pålidelighedsvækstkurve, der bedst passer til de aktuelt tilgængelige data. Pålidelighedstest kan specifikt søge efter hukommelseslæk. Specifikationen af sådanne test

http://www.testingstandards.co.uk/





kræver, at bestemte hukommelsesintensive handlinger udføres gentagne gange for at sikre, at den reserverede hukommelse frigives korrekt.

5.3.3 Effektivitetstest Attributten for effektivitetskvalitet evalueres ved at gennemføre test, der fokuserer på adfærden med hensyn til tid og ressourcer. Effektivitetstest med hensyn til tidsmæssig adfærd behandles nedenfor ud fra indfaldsvinklerne performance-, belastnings-, stress- og skalerbarhedstest.

5.3.3.1 Performancetest

Performancetest kan generelt kategoriseres i forskellige testtyper i henhold til de ikke-funktionelle krav, der fokuseres på. Testtyperne omfatter performance-, belastnings-, stress- og skalerbarhedstest. Den specifikke performancetest fokuserer på evnen i en komponent eller et system til at svare på brugerens eller systemets input inden for en angivet tid og under angivne betingelser (se også belastning og stress nedenfor). Performancemålingerne kan variere afhængigt af målene for testen. For individuelle softwarekomponenter kan performance måles i form af CPU-cyklusser, mens den for klientbaserede systemer kan måles i forhold til den tid, det tager at svare på en bestemt brugerforespørgsel. I systemer, hvis arkitekturer består af flere komponenter (f.eks. klienter, servere og databaser), foretages performancemålinger mellem individuelle komponenter, så "flaskehalse" i performance kan identificeres.

5.3.3.2 Belastningstest

Belastningstest fokuserer på et systems evne til at håndtere stigende niveauer af forventede realistiske belastninger, der er et resultat af de transaktionsforespørgsler, der genereres af en antal parallelle brugere. De gennemsnitlige svartider for brugere under forskellige scenarier med typisk anvendelse (operationelle profiler) kan måles og analyseres. Se også [Splaine01] Der er to undertyper af belastningstest, flerbruger (med et realistisk antal brugere) og volumentest (med et stort antal brugere). Belastningstest ser på både svartider og netværksoverførselshastighed.

5.3.3.3 Stresstest

Stresstest fokuserer på et systems evne til at håndtere spidsbelastninger ved eller over den maksimale kapacitet. Systemets performance skal forringes langsomt og forudsigeligt uden fejl, i takt med at stressniveauerne forøges. Specielt skal systemets funktionelle integritet testes, mens systemet er under stress, for at finde mulige fejl i den funktionelle behandling eller inkonsistens i data. Et muligt mål for stresstest er at fastlægge de grænser, hvor der rent faktisk opstår fejl i systemet, så det "svageste led i kæden" kan bestemmes. Stresstest giver mulighed for at tilføje yderligere komponenter til systemet i god tid (f.eks. hukommelse, CPU-ydelse, databaselager). I spidsbelastningstest udsættes systemet for simulerede kombinationer af betingelser, der kan resultere i pludselige ekstreme belastninger. I "springtest" udsættes systemet for flere af disse spidsbelastninger med perioder med lav belastning imellem. Disse test afgør, hvor godt systemet håndterer ændringer i belastningen, og om det er i stand til at reservere og frigive ressourcer efter behov. Se også [Splaine01].

5.3.3.4 Skalerbarhedstest

Skalerbarhedstest fokuserer på et systems evne til at imødekomme fremtidige effektivitetskrav, der muligvis går ud over de krav, der stilles i øjeblikket. Målet med testene er at bedømme systemets evne til at vokse (f.eks. med flere brugere, lagring af større mængde data), uden at det overstiger vedtagne grænser, eller der opstår fejl. Når disse grænser er kendt, kan der angives grænseværdier, der kan overvåges i produktion for at give en advarsel om overhængende problemer.

5.3.3.5 Test af ressourceudnyttelse

Effektivitetstest i relation til ressourceudnyttelse evaluerer udnyttelsen af systemets ressourcer (f.eks. hukommelsesområde, diskkapacitet og netværksbåndbredde). Disse sammenlignes under både normale belastninger og i stresssituationer, f.eks. høje transaktionsniveauer og store datavolumener. For indlejrede realtidssystemer spiller anvendelsen af hukommelsen (nogle gange kaldet “hukommelsesfodaftrykket”) en betydelig rolle i performancetesten.





5.3.3.6 Specifikation af effektivitetstest

Specifikationen af test til effektivitetstesttyper som f.eks. performance, belastning og stress er baseret på definitionen af operationelle profiler. Disse repræsenterer bestemte former for brugeradfærd i forbindelse med et program. Der kan være adskillige operationelle profiler til et givet program. Antallet af brugere pr. operationel profil kan hentes ved hjælp af overvågningsværktøjer (hvor det faktiske eller sammenlignelige program allerede findes) eller ved at foretage et skøn over anvendelsen. Sådanne skøn kan være baseret på algoritmer eller leveret af virksomhedsorganisationen, og de er specielt vigtige for angivelsen af den operationelle profil for test af skalerbarhed. Operationelle profiler danner basis for testcases, og de genereres typisk ved brug af testværktøjer. I dette tilfælde bruges termen "virtuel bruger" typisk til at repræsentere en simuleret bruger inden for den operationelle profil.

5.3.4 Vedligeholdelsesegnethedstest Generelt relaterer vedligeholdelsesegnethedstest sig til den lethed, hvormed software kan analyseres, ændres og testes. De relevante teknikker til vedligeholdelsesegnethedstest omfatter statisk analyse og checklister.

5.3.4.1 Dynamisk vedligeholdelsesegnethedstest

Dynamisk vedligeholdelsesegnethedstest fokuserer på de dokumenterede procedurer, der er udviklet til vedligeholdelse af et bestemt program (f.eks. til udførelse af softwareopgraderinger). Et udvalg af vedligeholdelsesscenarier bruges som testcases for at sikre, at de krævede serviceniveauer er opnåelige med de dokumenterede procedurer. Denne form for test er især relevant, hvor den underliggende infrastruktur er kompleks, og supportprocedurer muligvis involverer flere afdelinger/organisationer. Denne form for test kan eventuelt ske som en del af driftsaccepttest (OAT). [www.testingstandards.co.uk]

5.3.4.2 Analyseegnethed (korrigerende vedligeholdelse)

Denne form for vedligeholdelsestest fokuserer på måling af den tid, det tager at diagnosticere og udbedre problemer, der er registreret i et system. En enkelt mål kan være den gennemsnitlige tid, det tager at diagnosticere og udbedre en identificeret fejl.

5.3.4.3 Ændringsegnethed, stabilitet og testbarhed (adaptiv vedligeholdelse)

Et systems vedligeholdelsesegnethed kan også måles i form af den arbejdsindsats, der kræves for at foretage ændringer af systemet (f.eks. kodeændringer). Da arbejdsindsatsen afhænger af flere forskellige faktorer som softwaredesignmetoden (f.eks. objektorientering), programmeringsstandarder etc., udføres denne form for vedligeholdelsesegnethedstest også ved analyse eller review. Testbarhed relaterer sig specifikt til den arbejdsindsats, der kræves for at teste de foretagne ændringer. Stabilitet relaterer sig specifikt til systemets reaktion på ændringer. Systemer med lav stabilitet udviser et stort antal "banke på"-problemer (også kendt som "krusningseffekt"), hver gang der foretages en ændring. [ISO9126] [www.testingstandards.co.uk]

5.3.5 Flytbarhedstest Flytbarhedstest relaterer sig generelt til, hvor let det er at overføre softwaren til det tiltænkte miljø, enten fra starten eller fra et eksisterende miljø. Flytbarhedstest omfatter test af installerbarhed, sameksistens/kompatibilitet, tilpasningsegnethed og udskiftningsegnethed.

5.3.5.1 Installationstest

Installationstest udføres på den software, der bruges til at installere anden software på dets målmiljø. Dette kan f.eks. omfatte software, der er udviklet til at installere et operativsystem på en processor, eller en "installationsguide", der bruges til at installere et produkt på en klient-pc. Typiske mål for test af installerbarhed er bl.a.:

• Validering af, at softwaren kan installeres korrekt ved at følge instruktionerne i en installationsvejledning (herunder kørsel af alle installationsscripts) eller ved at bruge en installationsguide. Dette omfatter installation med installationsindstillinger til forskellige HW/SW-konfigurationer og med forskellige grader af installation (f.eks. fuldstændig eller delvis).

• Test af, om fejl, der opstår under installationen (f.eks. fejl under indlæsning af bestemte DLL'er), behandles korrekt af installationssoftwaren, uden af systemet efterlades i en udefineret tilstand (f.eks. med delvist installeret software og forkerte systemkonfigurationer).

• Test af, om en delvis installation/afinstallation kan færdiggøres.





• Test af, om en installationsguide kan foretage en korrekt identifikation af en ugyldig hardwareplatform eller af ugyldige konfigurationer af operativsystemet.

• Måling af, om installationsprocessen kan færdiggøres inden for et angivet antal minutter eller med mindre end et angivet antal trin.

• Validering af, at softwaren kan nedgraderes eller afinstalleres. Funktionalitetstest udføres normalt efter installationstesten for at registrere eventuelle fejl, der er introduceret ved installationen (f.eks. forkerte konfigurationer og funktioner, der ikke er tilgængelige). Brugervenlighedstest udføres normalt parallelt med test af installerbarhed (f.eks. for at validere, at brugere har fået forståelige instruktioner og feedback-/fejlmeddelelser under installationen).

5.3.5.2 Sameksistens

Computersystemer, der ikke har forbindelse til hinanden, siges at være kompatible, når de kan køre i det samme miljø (f.eks. på den samme hardware), uden at de påvirker hinandens adfærd (f.eks. ressourcekonflikter). Kompatibilitetstest kan udføres, f.eks. hvor ny eller opgraderet software installeres i miljøer (f.eks. servere), der allerede indeholder installerede programmer. Der kan muligvis opstå kompatibilitetsproblemer, når programmet testes i et miljø, hvor det er det eneste program, der er installeret (og hvor det ikke er muligt at registrere kompatibilitetsproblemer), og derefter installeres i et andet miljø (f.eks. produktion), der også kører andre programmer. Typiske mål for kompatibilitetstest er bl.a.:

• Evaluering af mulig negativ virkning på funktionaliteten, når programmerne indlæses i det samme miljø (f.eks. konflikt i ressourceanvendelsen når en server kører flere programmer).

• Evaluering af den påvirkning af andre programmer, der er resultatet af installation af systemrettelser og opgraderingen.

Kompatibilitetstest udføres normalt, når system- og brugeraccepttest er blevet færdiggjort korrekt.

5.3.5.3 Test af tilpasningsegnethed

Test af tilpasningsegnethed tester om et givet program fungerer korrekt i alle tiltænkte målmiljøer (hardware, software, middleware, operativsystem etc.). Angivelse af test af tilpasningsegnethed kræver, at kombinationer af de tiltænkte målmiljøer er identificeret, konfigureret og tilgængelige for testteamet. Disse miljøer testes derefter ved brug af et udvalg af funktionelle testcases, som undersøger de forskellige komponenter, der er til stede i miljøet. Tilpasningsegnethed er muligvis knyttet til softwarens evne til at blive flyttet til forskellige specificerede miljøer gennem udførelsen af en foruddefineret procedure. Der bruges muligvis test til at evaluere denne procedure. Test af tilpasningsegnethed kan udføres sammen med test af installerbarhed, og den følges typisk af funktionelle test, for at registrere alle fejl, der er blevet introduceret ved tilpasningen af softwaren til et andet miljø.

5.3.5.4 Udskiftningsegnethedstest

Udskiftningsegnethed fokuserer på muligheden for, at softwarekomponenter i systemer kan erstattes med andre. Det er især relevant for systemer, der bruger kommerciel hyldesoftware (COTS) til specifikke systemkomponenter. Udskiftningsegnethedstest kan udføres parallelt med test af funktionel integration, hvor der er mere end en alternativ komponent tilgængelig til integration i det færdige system. Udskiftningsegnethed kan evalueres gennem teknisk review eller undersøgelse, hvor der lægges vægt på den klare definition af grænseflader til potentielle erstatningskomponenter.





6. Reviews

Termer Revision, IEEE 1028, uformelt review, inspektion, inspektionsleder, ledelsesreview, moderator, review, reviewer, teknisk review og walkthrough.

6.1 Introduktion En vellykket reviewproces kræver planlægning, deltagelse og opfølgning. Uddannelsesleverandører skal sikre sig, at de testansvarlige forstår det ansvar, de har for planlægnings- og opfølgningsaktiviteterne. Testere skal være aktive deltagere i reviewprocessen og give udtryk for deres individuelle synspunkter. De bør have en formaliseret uddannelse, så de får en bedre forståelse af deres respektive roller i en hvilken som helst teknisk reviewproces. Alle reviewdeltagere skal være overbeviste om fordelene ved et veludført teknisk review. Når inspektioner gennemføres korrekt, så er de den største og mest omkostningseffektive bidragyder til den samlede leverede kvalitet. En international standard for reviews er IEEE 1028.

6.2 Principperne for reviews Et review er en type af statisk test. Et af hovedmålene med reviews er ofte at finde defekter. Reviewerne finder defekter ved direkte gennemgang af dokumenter. De grundlæggende reviewtyper er beskrevet i afsnit 3.2 i Foundation Level Syllabus (version 2005) og er listet nedenfor i kapitel 6.3. Alle typer review skal helst udføres, så snart de relevante kildedokumenter (dokumenter, der beskriver projektkravene) og standarder (som projektet skal overholde) er tilgængelige. Hvis et af dokumenterne eller standarderne mangler, kan afvigelser og inkonsistens på tværs af al dokumentationen ikke opdages. Kun det der optræder i det enkelte dokument, kan opdages. Reviewerne skal have adgang til det dokument, der skal foretages review af, i så god tid, at de kan blive fortrolige med indholdet af dokumentet. Alle dokumenttyper kan gøres til genstand for et review, f.eks. kildekode, kravspecifikationer, koncepter, testplaner, testdokumenter, osv. Dynamisk testning følger normalt efter et review af kildekoden. Den er beregnet til at finde defekter, der ikke kan findes ved en statisk undersøgelse. Et review kan føre til tre mulige resultater:

• Dokumentet kan bruges uændret eller med mindre ændringer. • Dokumentet skal ændres, men det er ikke nødvendigt med et yderligere review. • Der skal foretages omfattende ændringer af dokumentet, og det er nødvendigt med et yderligere review.

Rollerne og ansvarsområderne for dem, der er involveret i et typisk formelt review, er beskrevet i Foundation Syllabus, dvs. den ansvarlige, moderator eller leder, ophavsmand, reviewere og referent. Andre, der kan være involveret i reviews, inkluderer beslutningstagere eller interessenter og repræsentanter for kunder eller brugere. En yderligere valgfri rolle, der nogle gange bruges ved inspektioner, er en oplæser, hvis opgave det er at fortolke dele af arbejdsproduktet på mødet. Ud over reviewroller kan de enkelte reviewere blive tildelt en defekt-baseret rolle med det formål at lede efter bestemte typer defekter. Mere end en af reviewtyperne kan anvendes på et enkelt produkt. En gruppe kan f.eks. gennemføre et teknisk review for at beslutte, hvilken funktionalitet der skal implementeres til næste iteration. Der foretages derefter muligvis en inspektion af specifikationerne for de inkluderede funktionaliteter.





6.3 Reviewtyper Foundation Syllabus introducerede følgende typer review:

• Uformelt review • Walkthrough • Teknisk review • Inspektion.

I praksis kan der også forekomme hybrider af disse reviewtyper, f.eks. et teknisk review, der bruger regelsæt.

6.3.1 Ledelsesreview og revision Ud over de typer, der er nævnt i Foundation Syllabus, beskriver IEEE 1028 også følgende typer af review:

• Ledelsesreview • Revision.

Nøglekarakteristikaene ved et ledelsesreview er:

• Hovedformål: at overvåge fremdrift, vurdere status og tage beslutninger om fremtidige handlinger • Udføres af eller for chefer, der har direkte ansvar for projektet eller systemet • Udføres af eller for en interessent eller beslutningstager, f.eks. en chef på et højere niveau eller en

direktør • Kontroller konsistens med og afvigelser fra planer, eller tilstrækkeligheden af managementprocedurer • Inkluderer vurdering af projektrisici • Resultatet inkluderer handlingselementer og spørgsmål, der skal løses • Deltagere forventes at være forberedte, beslutninger dokumenteres.

Bemærk, at testansvarlige skal deltage i og kan tilskynde til, at der foretages ledelsesreview af testfremdriften. Revisioner er ekstremt formelle, og udføres normalt for at vise overholdelse af et sæt forventninger, højst sandsynligt en gældende standard eller en kontraktmæssig forpligtigelse. Som sådan er revisioner de mindst effektive til at afsløre defekter. Nøglekarakteristikaene ved en revision er:

• Hovedformål: at tilvejebringe en uafhængig vurdering af overholdelsen af processer, lovkrav, standarder etc.

• En ledende auditør er ansvarlig for revisionen og fungerer som moderator • Auditører indsamler dokumentation for overholdelse gennem interview, bevidning og gennemgang af

dokumenter • Resultatet inkluderer observationer, anbefalinger, korrigerende handlinger og en bestået/ikke-bestået

vurdering.

6.3.2 Review af bestemte arbejdsprodukter Review kan beskrives i form af de arbejdsprodukter eller aktiviteter, der er målet for reviewene, f.eks.:

Kontraktreview

Kravreview

Designreview o Foreløbigt designreview o Kritisk designreview

Acceptreview/kvalifikationsreview

Review af driftsmæssig parathed Et kontraktreview kan være forbundet med en kontraktmilepæl, og det kan typisk være et ledelsesreview af et sikkerhedskritisk eller sikkerhedsrelateret system. Det vil involvere ledere, kunder og teknisk personale.





Et kravreview kan være en walkthrough, et teknisk review eller en inspektion, og det kan omfatte sikkerheds- og afhængighedskrav, så vel som funktionelle og ikke funktionelle krav. Et kravreview kan inkludere acceptkriterier og testbetingelser. Designreviews er typisk tekniske reviews eller inspektioner, og de involverer teknisk personale og kunder eller interessenter. I det foreløbige designreview foreslås den indledende metode til nogle tekniske design og test. Det kritiske designreview dækker alle de foreslåede designløsninger, herunder testcases og procedurer. Acceptreview gennemføres for at opnå ledelsesgodkendelse af et system. Det kaldes også kvalifikationsreview, og det er normalt et ledelsesreview eller en revision.

6.3.3 Gennemførelse af et formelt review Foundation Syllabus beskriver seks faser i et formelt review: planlægning, kick-off, individuel forberedelse, reviewmøde, genbearbejdning og opfølgning. Det arbejdsprodukt, der skal foretages review af, skal passe til reviewerens kompetance, f.eks. en testplan til en testansvarlig, forretningsmæssige krav eller testdesign til en testanalytiker, eller funktionelle specifikationer, testcases eller testscript til tekniske testanalytikere.

6.4 Indførelse af reviews For at reviews kan anvendes med succes i en organisation, skal følgende trin gennemføres (ikke nødvendigvis i denne rækkefølge):

Sikring af support fra ledelsen

Uddannelse af ledere med hensyn til omkostninger, fordele og implementeringsspørgsmål

Valg og dokumentation af reviewprocedurer, former og infrastruktur (f.eks. database for reviewmetrikker)

Uddannelse i reviewteknikker og -procedurer

Opnåelse af støtte fra dem, der skal foretage reviews, og fra dem, der skal have foretaget review af deres arbejde

Udførelse af pilotreviews

Dokumentation af fordelen ved reviews gennem omkostningsbesparelser

Anvendelse af reviews på de vigtigste dokumenter, f.eks. krav, kontrakter, planer etc. Metrikker, f.eks. reduktion af eller undgåelse af omkostninger til rettelse af defekter og/eller deres konsekvenser, kan anvendes til at vurdere succesen ved introduktion af reviews. Besparelser kan også måles i den tid, der spares ved at finde og udbedre defekter tidligt. Reviewprocesser skal kontinuerligt overvåges og forbedres over tid. Ledere skal være opmærksomme på, at uddannelsen i brugen af en ny teknik er en investering – fordelene er ikke øjeblikkelige, men vil blive større over tid.





6.5 Succesfaktorer for reviews Der er et antal faktorer, der bidrager til vellykkede reviews. Det behøver ikke at være vanskeligt at gennemføre reviews, men de kan mislykkes på forskellige måder, hvis faktorer som disse ikke tages med i overvejelserne.

Tekniske faktorer

Kontrollér, at den definerede proces for den pågældende reviewtype følges nøje, specielt ved mere formelle typer af review, f.eks.inspektion.

Registrer omkostningerne ved reviews (herunder forbrugt tid) og de opnåede fordele.

Foretag review af tidlige udkast eller delvise dokumenter for at identificere defektmønstre, før de indarbejdes i hele dokumentet.

Kontrollér, at dokumenterne og de delvise dokumenter er klar til review, før en reviewproces startes (dvs. anvend startkriterier).

Brug organisationsspecifikke checklister for almindeligt forekommende defekter.

Brug mere end én type review, afhængigt af målene, f.eks. dokumentrettelse, teknisk forbedring, overførsel af information eller styring af fremdrift.

Foretag review eller inspektion af de dokumenter, der danner grundlag for vigtige beslutninger, foretag f.eks. inspektion af et tilbud, en kontrakt eller et krav på højt niveau, før et ledelsesreview godkender større udgifter på projektet.

Udvælg en begrænset del et dokument til vurdering, men ikke rettelse.

Tilskynd til, at de vigtigste defekter findes: fokuser på indhold ikke på format.

Foretag konstant forbedring af reviewprocessen.

Organisatoriske faktorer

Sørg for, at chefer afsætter tilstrækkelig tid til reviewaktiviteter, selv når der er pres fra deadlines.

Husk på, at den tid og de omkostninger, der bruges, ikke står i forhold til de defekter, der findes.

Tillad tilstrækkelig tid til genbearbejdning af de defekter, der er identificeret i reviews.

Brug aldrig metrikkerne fra reviews til vurdering af individuel indsats.

Sørg for, at de rigtige medarbejdere er involveret i de forskellige typer review.

Sørg for uddannelse i at udføre reviews, specielt de mere formelle reviewtyper.

Understøt et forum for reviewledere, hvor de kan dele erfaringer og ideer.

Sørg for, at alle deltager i review, og at alle får foretaget review af deres egne dokumenter.

Anvend de stærkeste reviewteknikker til de vigtigste dokumenter.

Sørg for en velafbalanceret reviewgruppe sammensat af medarbejdere med forskellige kvalifikationer og baggrunde.

Handlinger til forbedring af støtteprocessen skal understøttes for at håndtere systematiske problemer.

Anerkend de forbedringer, der opnås gennem reviewprocessen.

Medarbejderspørgsmål

Uddan interessenter, så de forventer, at der vil blive fundet defekter, og så de afsætter tid til genbearbejdning og fornyet review.

Sørg for, at reviewet er en positiv oplevelse for ophavsmanden.

Modtag identifikation af defekter i en ikke-bebrejdende atmosfære.

Sørg for, at kommentarer er konstruktive, nyttige og objektive, ikke subjektive.

Foretag ikke et review, hvis ophavsmanden ikke er enig eller ikke er villig.

Sørg for at opmuntre alle til at tænke indgående over de vigtigste aspekter ved de dokumenter, der foretages review af.

Mere information om reviews og inspektioner kan findes i [Gilb93] og [Weigers02].





7. Hændelseshåndtering

Termer IEEE 829, IEEE 1044, IEEE 1044.1, uregelmæssighed, configuration control board (CCB), defekt, fejl, hændelse, hændelsesregistrering, prioritet, analyse af underliggende årsag, alvorlighedsgrad

7.1 Introduktion Testansvarlige og testere skal være fortrolige med fejlhåndteringsprocessen. Testansvarlige fokuserer på processen, herunder metoder til at finde, følge og fjerne defekter. Testere er primært fokuseret på at foretage en korrekt registrering af de problemer, der findes inden for deres testområder. For hvert af trinene i livscyklussen, har testanalytikerne og de tekniske testanalytikere en forskellig orientering. Testanalytikerne evaluerer opførslen med hensyn til forretningsmæssige og brugermæssige behov, f.eks. ved en bruger, hvad der skal gøres, når vedkommende ser denne meddelelse eller opførsel. Den tekniske testanalytiker evaluerer opførslen af selve softwaren og vil højst sandsynligt foretage mere teknisk undersøgelse af problemet, f.eks. teste den samme fejl på forskellige platforme eller med forskellige hukommelsekonfigurationer.

7.2 Hvornår kan en fejl findes? En hændelse er en uventet begivenhed, der kræver yderligere undersøgelse. En hændelse er genkendelsen af en afvigelse, der skyldes en defekt. En hændelse resulterer muligvis og muligvis ikke i udarbejdelse af en defektrapport. En defekt er et faktisk problem, hvor det er fastslået, at der kræves en løsning gennem ændring af arbejdselementet. En defekt kan findes ved statisk test. En afvigelse kan kun findes ved dynamisk test. Hver fase af softwarelivscyklussen bør indeholde en metode til at finde og eliminere potentielle afvigelser. I udviklingsfasen f.eks. bør der anvendes kode- og designreview til at finde defekter. Under dynamisk test bruges testcases til at finde afvigelser. Jo tidligere en defekt findes og rettes, desto lavere bliver prisen for kvalitet for systemet som helhed. Der skal huskes på, at defekter både kan findes i test-delprodukter og i testobjektet.

7.3 Defektlivscyklus Alle defekter har en livscyklus, selvom nogle muligvis springer over nogle trin. En defektlivscyklus (som beskrevet i IEEE 1044-1993) består af fire trin:

• Trin 1: Erkendelse • Trin 2: Undersøgelse • Trin 3: Handling • Trin 4: Arkivering

Inden for hvert trin er der tre aktiviteter til indsamling af oplysninger:

• Registrering • Klassifikation • Identifikation af effekt

7.3.1 Trin 1: Erkendelse Erkendelsestrinnet optræder, når en potentiel defekt (hændelse) er opdaget. Dette kan ske i alle faser af softwarelivscyklussen. På opdagelsestidspunktet registreres de dataelementer, der identificerer defekten. Dette omfatter sådanne oplysninger som det miljø, defekten blev observeret i, den, der observerede defekten, beskrivelse, tidspunkt og leverandør (hvis det er relevant). Erkendelsen klassificeres gennem identifikation af visse attributter ved den potentielle defekt, herunder projektaktivitet, projektfase, den formodede årsag, muligheden for gentagelse, symptom(er) og produktstatus som resultat af uregelmæssigheden. Med disse oplysninger vurderes effekten ved at fastsætte alvorsgraden, effekt på projektplan og effekt på projektomkostningerne.





7.3.2 Trin 2: Undersøgelse Efter erkendelsen undersøges hver potentiel defekt. Dette trin bruges primært til at finde eventuelle relaterede spørgsmål og foreslå løsninger, hvilket kan omfatte ingen handling (en potentiel defekt betragtes f.eks. ikke længere som en faktisk defekt). Der registreres yderligere data på dette trin, ligesom der sker en revurdering af de klassifikations- og effektoplysninger, der blev givet i det forrige trin.

7.3.3 Trin 3: Handling På basis af resultaterne af undersøgelsen, begynder handlingstrinnet. Handlinger omfatter dem, der kræves for at udbedre defekten, samt eventuelle handlinger, angivet for rettelse//forbedring af processer og politikker for at forebygge tilsvarende defekter i fremtiden. Regressionstest og gentest samt progressionstest skal udføres for hver ændring. Der registreres yderligere data på dette trin, ligesom der sker en revurdering af de klassifikations- og effektoplysninger, der blev givet i det forrige trin.

7.3.4 Trin 4: Arkivering Uregelmæssigheden flytter derefter til arkiveringstrinnet, hvor alle yderligere dataelementer registreres, og arkiveringsklassifikationen sættes til enten lukket, udskudt, samlet eller overført til et andet projekt.

7.4 Defektfelter IEEE 1044-1993 angiver et sæt obligatoriske felter, der udfyldes på forskellige tidspunkter i defektens livscyklus. Der defineres også et stort antal valgfrie felter. Når IEEE 1044-1993 indføres, er det i følge IEEE 1044.1 acceptabelt at oprette en mapning mellem IEEE-termerne for defektfelter og tilsvarende navne, der bruges af den enkelte virksomhed. Dette muliggør overholdelse af IEEE 1044-1993, uden at det er nødvendigt at holde sig strengt til navngivningskonventionerne. IEEE-overholdelse muliggør sammenligning af defektloplysninger på tværs af flere virksomheder og organisationer. Uanset om IEEE-overholdelse er et mål, er det hensigten, at de felter, der givet for en defekt, giver tilstrækkelige oplysninger til, at der kan handles i forhold til defekten. En brugbar defektrapport er:

• Fuldstændig • Kortfattet • Præcis • Objektiv

Udover at løse den specifikke defekt, skal der også angives oplysninger til præcis klassifikation, risikoanalyse og procesforbedring.

7.5 Metrikker og hændelseshåndtering Defektoplysningerne skal indeholde tilstrækkelige oplysninger til at bistå overvågningen af testfremdriften, fejltæthedsanalyse, metrikker for fundne i forhold til udbedrede fejl og konvergensmetrikker (åbne i forhold til lukkede). Desuden skal fejloplysningerne understøtte initiativer til procesforbedringer gennem opfølgning af oplysninger om faseindeslutning, analyse af underliggende årsag og identifikation af fejltendenser, der kan bruges som input til justeringer af afhjælpning af strategiske risici.

7.6 Kommunikation af hændelser Hændelseshåndtering omfatter effektiv kommunikation, der er fri for beskyldninger og understøtter indsamlingen og tolkningen af objektive oplysninger. Præcisionen i hændelsesrapporterne, korrekt klassifikation og udvist objektivitet er afgørende for opretholdelsen af professionelle relationer mellem de medarbejdere, der rapporterer fejl, og de medarbejdere, der udbedrer fejl. Testere kan blive spurgt om den relative vigtighed af en fejl, og bør give tilgængelige objektive oplysninger. Der kan afholdes fejlrangordningsmøder som en hjælp til en korrekt prioritering. Et fejlopfølgningsværktøj bør ikke bruges som en erstatning for god kommunikation, og rangordningsmøder skal ikke bruges som en erstatning for ikke at bruge et godt fejlopfølgningsværktøj. Det er nødvendigt med både kommunikation og tilstrækkelig værktøjssupport for at få en effektiv fejlproces.





8. Standarder og Testforbedringsprocessen

Termer Capability Maturity Model (CMM), Capability Maturity Model Integration (CMMI), Test Maturity Model (TMM), Test Maturity Model integration (TMMi), Test Process Improvement (TPI).

8.1 Introduktion Støtte til etablering og forbedring af testprocesser kan komme fra en række kilder. Dette afsnit gennemgår først standarder som en nyttig (nogle gange obligatorisk) kilde til oplysninger om et antal testrelaterede emner. Viden om, hvilke standarder der findes, og hvor de kan anvendes, betragtes som et undervisningsmål for testansvarlige og testere. Undervisere skal fremhæve de specifikke standarder, som er specielt relevante for det modul, der undervises i. Når en testproces først er etableret, skal den undergå kontinuert forbedring. I afsnit 8.3 dækkes først generiske forbedringsemner, derefter følger en introduktion til nogle specifikke modeller, der kan bruges til forbedring af testprocessen. Testansvarlige skal forstå alt materiale i dette afsnit, men det er også vigtigt, at testanalytikere og tekniske testanalytikere, der er nøglespillere i implementeringen af forbedringer, har kendskab til de tilgængelige forbedringsmodeller.

8.2 Overvejelser om standarder I denne syllabus og i Foundation Level Syllabus er der nævnt nogle standarder. Der er standarder for et antal emner, der har relation til software, f.eks.:

• Softwareudviklingslivscyklusser • Softwaretest og metoder • Konfigurationsstyring af software • Softwarevedligeholdelse • Kvalitetssikring • Projektledelse • Krav • Softwaresprog • Softwaregrænseflader • Fejlhåndtering

Det er ikke formålet med denne syllabus at liste eller anbefale specifikke standarder. Testerne skal være opmærksomme på, hvordan standarder fremstilles, og hvordan de skal bruges i brugerens miljø. Standarder kan komme fra forskellige kilder:

• Internationale, eller med internationale mål • Nationale, f.eks. nationale anvendelser af internationale standarder • Domænespecifikke, f.eks. når internationale eller nationale standarder er tilpasset til bestemte domæner

eller udviklet til specifikke domæner. Der skal foretages nogle overvejelser i forbindelse med brugen af standarder. De er beskrevet yderligere i dette afsnit.

8.2.1 Generelle aspekter ved standarder

8.2.1.1 Kilder til standarder

Standarder fremstilles af grupper af fagfolk og afspejler den kollektive viden. Der er to hovedkilder til internationale standarder: IEEE og ISO. Nationale og domænespecifikke standarder er også vigtige og tilgængelige. Testere skal være opmærksomme på de standarder, der gælder for deres miljø og sammenhæng, hvad enten det drejer sig om formelle standarder (internationale, nationale eller domænespecifikke) eller om interne standarder og





anbefalede fremgangsmåder. Da standarder udvikler sig og ændres, er det nødvendigt at angive standardens version (udgivelsesdato) for at sikre, at der er opnået overensstemmelse. Hvis der refereres til en standard uden angivelse af dato eller version, regnes det som en reference til den seneste version.

8.2.1.2 Værdien af standarder

Standarder kan bruges som et værktøj til at fremme konstruktiv kvalitetssikring, der fokuserer på at minimere introducerede defekter, i stedet for at finde dem gennem test (analytisk kvalitetssikring). Ikke alle standarder kan anvendes til alle projekter. Oplysninger, der er angivet i en standard, kan være nyttige for et projekt eller kan være en hindring for det. Hvis man følger en standard bare for at følge en standard, hjælper det ikke testeren med at finde flere defekter i et arbejdsprodukt [Kaner02]. Men standarder kan give en referenceramme og danne basis for definition af testløsninger.

8.2.1.3 Sammenhæng og konflikter

Nogle standarder kan mangle sammenhæng med andre standarder eller indeholder endda definitioner, der er i modstrid med hinanden. Det er op til brugerne af standarderne at afgøre, hvor nyttige de forskellige standarder er i hans/hendes miljø og sammenhæng.

8.2.2 Internationale standarder

8.2.2.1 ISO

ISO [www.iso.org] står for International Standards Organization (der for nylig er ændret til International Organization for Standardization), og den er sammensat af medlemmer, der for hvert deres land repræsenterer den nationale enhed, der er mest repræsentativ med hensyn til standardisering. Den internationale enhed har fremført en række standarder, der er nyttige for softwaretestere, f.eks.:

ISO 9126:1998, der nu er splittet op i følgende standarder og tekniske rapporter (TR): o ISO/IEC 9126-1:2001 Software engineering – Product quality – Part 1: Kvalitetsmodel o ISO/IEC TR 9126-2:2003 Software engineering – Product quality – Part 2: Eksterne metrikker o ISO/IEC TR 9126-3:2003 Software engineering – Product quality – Part 3: Interne metrikker o ISO/IEC TR 9126-4:2004 Software engineering – Product quality – Part 4: Metrikker for

kvaliteten under brug

ISO 12207:1995/Amd 2:2004 Systems and Software Engineering – Processer for softwarelivscyklus

ISO/IEC 155041-2:2003 Information technology – Process assessment – Part 2: Udførelse af en

vurdering. Denne liste er ikke fyldestgørende, der kan muligvis være andre ISO-standarder, der gælder for en testers sammenhæng og miljø.

8.2.2.2 IEEE

IEEE [www.ieee.org] er Institute of Electrical and Electronics Engineer, der er en faglig organisation med basis i USA. Der er nationale repræsentanter til rådighed i mere end 100 lande. Organisationen har foreslået et antal standarder, der er nyttige for softwaretestere, så som:

• IEEE 610:1991 IEEE standard computer dictionary (standardcomputerleksikon). En samling af IEEE-standard computerleksika

• IEEE 829:1998 IEEE standard for software test documentation (standard for softwaretestdokumentation) • IEEE 1028:1997 IEEE standard for software reviews (standard for softwarereviews) • IEEE 1044:1995 IEEE guide to classification for software anomalies (vejledning i klassifikation af

softwareuregelmæssigheder). Denne liste er ikke fyldestgørende, der kan muligvis være andre IEEE-standarder, der gælder for jeres sammenhæng og miljø.

1ISO 15504, der også er kendt som SPICE, er afledt fra SPICE-projektet





8.2.3 Nationale standarder Mange lande har deres egne specifikke standarder. Nogle af disse standarder gælder for og/eller er nyttige for softwaretest. En sådan britisk standard er BS-7925-2:1998 "Software testing. Software component testing" der giver oplysninger om mange af de testteknikker, der er beskrevet i denne syllabus, herunder:

• Ækvivalenspartitionering • Grænseværdianalyse • Tilstandsovergangstest • Årsags-/virkningsgraf • Instruktionstest • Forgrenings-/beslutningstest • Betingelsestest • Tilfældig test.

BS-7925-2 indeholder også en procesbeskrivelse for komponenttest

8.2.4 Domænespecifikke standarder Standarder findes også i forskellige tekniske domæner. Nogle brancher skræddersyr andre standarder til deres specifikke tekniske domæner. Her er der også aspekter, der har interesse i forbindelse med softwaretest, softwarekvalitet og softwareudvikling.

8.2.4.1 Flyelektroniske systemer

RTCA DO-178B/ED 12B "Softwareovervejelser i luftbårne systemer og certificering af udstyr" gælder for software, der bruges i civile flyvemaskiner. Denne standard gælder også for software, der bruges til at udarbejde (eller kontrollere) den software, der bruges i flyvemaskiner. Til flyelektronisk software foreskriver den amerikanske FAA (Federal Aviation Administration) og den internationale JAA (Joint Aviation Authorities) kriterier for en bestemt strukturel dækning, der er baseret på niveauet for, hvor kritisk den testede software er:

Kritikalitetsniveau Potentiel effekt af fejl Krævet strukturel dækning

A Katastrofalt Forhindrer fortsat sikker flyvning og landing

Tilstandsbestemmelse,

beslutning og instruktion

B Farligt/

Meget alvorligt

Stor reduktion af sikkerhedsmargener for? funktionelle muligheder

Det kan ikke forventes, at besætningen kan udføre deres opgaver præcist eller fuldstændigt

Alvorlige eller fatale skader på et mindre antal af de ombordværende

Beslutning og instruktion

C Alvorligt Betydelig reduktion af sikkerhedsmargener

Betydelig forøgelse af besætningens arbejdsbelastning

Ubehag for de ombordværende, herunder mulighed for kvæstelser

Instruktion

D Mindre alvorligt Mindre reduktion af sikkerhedsmargenerne for flyvemaskinens funktionelle muligheder

Mindre forøgelse af besætningens arbejdsbelastning

Nogle gener for de

Ingen





ombordværende

E Ingen effekt Ingen påvirkning af flyvemaskinens muigheder

Ingen forøgelse af besætningens arbejdsbelastning

Ingen

Det passende niveau af strukturel dækning skal opnås i forhold til, hvilket kritisk niveau softwaren skal certificeres til ved brug i civil luftfart.

8.2.4.2 Rumfartsindustri

Nogle brancher skræddersyr andre standarder til deres specifikke domæner. Dette er tilfældet med rumfartsindustrien med ECSS (European Cooperation on Space Standardization) [www.ecss.org]. Afhængigt af hvor kritisk softwaren er, anbefaler ECSS metoder og teknikker, der er konsistente med ISTQB® Foundation og Advanced Syllabus, herunder:

• SFMECA – Software Failure Modes, Effects and Criticality Analysis (Analyse af softwarefejltilstande, effekter og kritisk tilstand)

• SFTA – Software Fault Tree Analysis (Softwarefejltræsanalyse) • HSIA – Hardware Software Interaction Analysis (Analyse af interaktion mellem hardware og software) • SCCFA – Software Common Cause Failure Analysis (Analyse af almindelige årsager til softwarefejl).

8.2.4.3 Administration af fødevarer og medicin

• Til medicinske systemer, der er underlagt Title 21 CFR Part 820, anbefaler United States Food and Drug Administration (FDA) bestemte strukturelle og funktionelle testteknikker.

FDA anbefaler også teststrategier og -principper, der er konsistente med ISTQB® Foundation og Advanced Level Syllabus.

8.2.5 Andre standarder Antallet af standarder, der er tilgængelige i forskellige brancher er meget stort. Nogle er tilpasninger til specifikke domæner eller brancher, nogle anvendes til specifikke opgaver eller giver en forklaring på, hvordan en standard anvendes. Det er op til testeren at være opmærksom på de forskellige standarder (herunder interne standarder, bedste fremgangsmåder etc.), der kan anvendes inden for domænet, branchen eller sammenhængen. Nogle gange er de anvendelige standarder angivet med den hierarkiske anvendelighed for specifikke kontrakter. Det er op til den testansvarlige at være opmærksom på de standarder, der skal overholdes, og sikre, at der opretholdes en passende overholdelse.

8.3 Testforbedringsproces På samme måde som test bruges til at forbedre software, vælges og bruges softwarekvalitetsprocesser til at forbedre softwareudviklingsprocessen (og de resulterende softwareprodukter). Der kan også ske procesforbedringer af testprocesserne. Der er forskellige måder og metoder tilgængelige til forbedring af test af software og af systemer, der indeholder software. Disse metoder sigter mod at forbedre processen (og derved de leverede produkter) ved hjælp af vejledninger og forbedringsområder. Test tegner sig ofte for en betydelig del af de totale projektomkostninger. Men der er kun begrænset opmærksomhed på testprocessen i de forskellige modeller til forbedring af softwareprocessen, f.eks. CMMI (se flere detaljer nedenfor). Testforbedringsmodeller, f.eks. Test Maturity Model (TMM), Systematic Test and Evaluation Process (STEP), Critical Testing Processes (CTP) og Test Process Improvement (TPI) blev udviklet for at dække dette aspekt. TPI og TMM indeholder en vis grad af tværorganisatoriske metrikker, der kan bruges til "benchmark"-sammenligninger. Der er mange forbedringsmodeller tilgængelig i branchen i dag. Ud over de modeller, der behandles i dette afsnit, bør Test Organization Maturity (TOM), Test Improvement Model (TIM) og Software Quality Rank (SQR) også tages med i overvejelserne. Der er også et stort antal regionale modeller i brug i dag.





Professionelle testere bør gennemgå alle tilgængelige modeller for at fastslå, hvad der passer bedst til deres situation. Når modellerne gennemgås i dette afsnit, skal det ikke ses som en anbefaling til at bruge netop dem, men som et forsøg på at give et repræsentativt overblik over, hvordan modellerne fungerer, og hvad der er inkluderet i dem.

8.3.1 Introduktion til procesforbedring Procesforbedringer er både relevante for softwareudviklingsprocessen og for testprocessen. At lære af sine egne fejltagelser, gør det muligt at forbedre den proces, organisationer bruger til at udvikle og teste software. Deming-forbedringscyklussen: Plan, Do, Check, Act (planlæg, udfør, kontroller, reager), er blevet brugt i mange årtier, og den er stadig relevant, når testere skal forbedre den proces, der bruges i dag. En forudsætning for procesforbedring er troen på, at kvaliteten i et system i høj grad påvirkes af kvaliteten af den proces, der bruges til at udvikle softwaren. Forbedret kvalitet i softwarebranchen reducerer behovet for ressourcer til at vedligeholde softwaren og giver derfor mere tid til udarbejdelse af flere og bedre løsninger i fremtiden. Procesmodeller giver et udgangspunkt for forbedringer gennem måling af organisationens modenhedsprocesser ved hjælp af modellen. Modellen udgør også en ramme for forbedring af organisationens processer på basis af resultatet af en vurdering. En procesvurdering fører til en bestemmelse af procesmuligheder, hvilket motiverer en procesforbedring. Dette kan afføde en senere procesvurdering til måling af effekten af forbedringen.

8.3.2 Typer af procesforbedring Der er to typer modeller: procesreferencemodeller og indholdsreferencemodeller.

1. Procesreferencemodellen bruges som en ramme, når der foretages en vurdering, for at evaluere en organisations evner i forhold til modellen, og for at evaluere organisationen inden for rammen.

2. Indholdsreferencemodellen bruges til at forbedre processen, når vurderingen er foretaget. Nogle modeller kan have begge dele indbygget, mens andre kun har én af delene.

8.4 Forbedring af testprocessen It-branchen er begyndt at arbejde med modeller til forbedring af testprocessen, da branchen ønsker at nå til et højere niveau af modenhed og professionalisme. Branchestandardmodeller hjælper med til at udvikle tværorganisatoriske metrikker og mål, der kan bruges til sammenligning. De trinvise modeller, som TMMi og CMMI, giver standarder til sammenligning på tværs af forskellige virksomheder og organisationer. De kontinuerte modeller giver en organisation mulighed for at løse de problemer, der har højest prioritet, i en mere fri implementeringsorden. Ud af behovet for procesforbedringer i testbranchen er der opstået adskillige standarder. Det omfatter bl.a. STEP, TMMi, TPI og CTP. Hver enkelt af disse gennemgås yderligere i dette afsnit. Alle fire at disse modeller til vurdering af testprocesser giver organisationer mulighed for at bestemme, hvor de befinder sig med hensyn til deres aktuelle testprocesser. Når der først er udført en vurdering, giver TMMi og TPI en foreskreven køreplan for forbedring af testprocessen. Derimod giver STEP og CTP organisationerne metoder til at bestemme, hvor de får det største afkast af investeringen i procesforbedringer, og overlader til organisationerne at vælge den passende køreplan. Når der er opnået enighed om, at testprocesserne skal gennemgås og forbedres, bør der bruges følgende procestrin til denne aktivitet:

• Initiering • Måling • Prioritering og planlægning • Definition og Redefinition • Spredning og Optagelse • Validering • Evolution





Igangsætning I denne aktivitet aftales interessenternes bekræftelse, formålene, målene, omfanget og dækningen af procesforbedringerne. Valget af den procesmodel, som forbedringerne skal identificeres i forhold til, sker også i denne aktivitet. Modellen kan enten vælges blandt dem, der er publiceret, eller den kan defineres individuelt. Før procesforbedringsaktiviteten starter, skal succeskriterierne defineres, og der skal implementeres en metode, som de kan måles efter under forbedringsaktiviteten. Måling Den aftalte vurderingsmetode anvendes, og det resulterer i en liste over mulige procesforbedringer. Prioritering og planlægning Listen over mulige procesforbedringer sættes i prioriteringsrækkefølge. Rækkefølgen kan være baseret på investeringsafkast, risici, overensstemmelse med organisatorisk strategi, målbare kvantitative eller kvalitative fordele. Når der er fastlagt en prioriteringsrækkefølge, bør der udarbejdes en plan for leveringen af forbedringerne, og den skal igangsættes. Definition og redefinition Ud fra de procesforbedringskrav, der er identificeret, skal ny processer defineres, hvor det er påkrævet, og hvor eksisterende processer kræver en opdatering, skal de redefineres og gøres klar til anvendelse. Spredning og optagelse Når procesforbedringerne er udarbejdet, skal de implementeres. Dette kan omfatte eventuelt påkrævet uddannelse eller oplæring, pilotanvendelse af processerne og endelig fuld implementering af disse. Validering Når procesforbedringerne er gennemført fuldt ud, er det vigtigt at alle fordele, der blev aftalt, før forbedringen eller forbedringerne blev foretaget, bliver valideret, f.eks. fordelsopnåelse. Det er også vigtigt, at eventuelle succeskriterier for procesforbedringsaktiviteten er opfyldt. Evolution Afhængigt af den anvendte procesmodel er det på dette trin i processen, at overvågningen af det næste modenhedsniveau starter, og der tages en beslutning om enten at starte forbedringsprocessen igen eller standse aktiviteten på dette punkt. Brugen af vurderingsmodeller er en normal metode til sikring af en standardiseret tilgang til forbedring af testprocesserne ved brug af afprøvede arbejdsmetoder, der er tillid til. Forbedringer af testprocessen kan også opnås uden brug af modeller, f.eks. ved anvendelse af analytiske metoder og afholdelse af retrospektive møder.

8.5 Forbedring af testprocessen med TMM TTM (Testing Maturity Model) er opbygget af fem niveauer og er ment som et supplement til CMM. Hvert af niveauerne indeholder definerede procesområder, der skal være fuldstændig opfyldt, før organisationen kan gå videre til næste niveau (dvs. trinvis repræsentation). TMM indeholder både en procesreferencemodel og en indholdsreferencemodel. TMM-niveauerne er: Niveau 1: Initielt

Startniveauet repræsenterer en tilstand, hvor der ikke er nogen formelt dokumenteret eller struktureret proces. Test udarbejdes på en ad-hoc-måde efter kodning, og test betragtes som det samme som debugning. Formålet med test forstås som at bevise, at softwaren fungerer.

Niveau 2: Definition





Det andet niveau kan nås ved at angive testpolitikker og -mål, introducere en proces for testplanlægning og implementere basale testteknikker og -metoder.

Niveau 3: Integration Det tredje niveau nås, når en testproces er integreret i softwareudviklingslivscyklussen, og den er dokumenteret i formelle standarder, procedurer og metoder. Der bør være en klar softwaretestfunktion, der kan kontrolleres og overvåges.

Niveau 4: Styring og måling Niveau fire er nået, når testprocessen kan måles på en effektiv måde, styres og tilpasses til specifikke projekter.

Niveau 5: Optimering Det endelige niveau repræsenterer en tilstand i testprocessens modenhed, hvor data fra testprocessen kan bruges som en hjælp til at forhindre defekter, og hvor fokus er på optimering af den etablerede proces.

For at nå til et bestemt niveau skal et antal foruddefinerede modenhedsmål og -undermål være nået. Disse mål er defineret i form af aktiviteter, opgaver og ansvar, og de vurderes i forhold til angivne "views" (synsvinkler) for ansvarlige, udviklere/testere og kunder/brugere. Flere oplysninger om TMM findes i [Burnstein03]. TMMi Foundation [se www.tmmifoundation.org for detaljer] har defineret efterfølgeren for TMM: TMMi. TMMi er en detaljeret model for testprocesforbedring, baseret på TMM-strukturen, som den er udviklet af Illinois Institute of Technology, og på praktiske erfaringer med brugen af TMM, og modellen er lanceret som et supplement til CMMI. Strukturen i TMMi er stort set baseret på strukturen i CMMI (f.eks. procesområder, generiske mål, generiske arbejdsmetoder, specifikke mål og specifikke arbejdsmetoder).

8.6 Forbedring af testprocessen med TPI TPI (Test Process Improvement) bruger en kontinuert repræsentation i stedet for den trinvise repræsentation i TMM. Optimeringsplanen for testprocessen, som den er beskrevet i [Koomen99], omfatter et sæt af nøgleområder, der er angivet inden for de fire hjørnesten: Livscyklus, Organisation, Infrastruktur og værktøjer og Teknikker. Nøgleområder kan evalueres på et niveau mellem A og D, hvor A er lavt. Det er også muligt for meget umodne områder, at de ikke kan opnå startniveauet A. Nogle nøgleområder kan kun vurderes som A eller B (f.eks. estimering og planlægning), mens andre (f.eks. metrikker) kan vurderes som A, B, C eller D. Det niveau, et givet nøgleområde har opnået, vurderes ved at evaluere kontrolpunkter, der er defineret i TPI-modellen. Hvis der f.eks. svares positivt på niveau A og B til alle kontrolpunkter inden for nøgleområdet "rapportering", så er niveau B opnået for dette nøgleområde. TPI-modellen definerer afhængigheder mellem de forskellige nøgleområder og niveauer. Disse afhængigheder sikrer, at testprocessen udvikles jævnt. Det er f.eks. ikke muligt at opnå niveau A på nøgleområdet "metrikker", uden at man også opnår niveau A på nøgleområdet "rapportering" (dvs. hvilken værdi har det at foretage målinger, hvis de ikke rapporteres). Brugen af afhængigheder er valgfri i TPI-modellen. TPI er primært en procesreferencemodel. Der er givet en testmodenhedsmatrice, der afbilder niveauerne (A, B, C eller D) for hvert nøgleområde til et overordnet modenhedsniveau for testprocessen. Disse overordnede niveauer er:

• Kontrolleret • Effektivt • Optimerende

I forbindelse med en TPI-vurdering bruges der kvantitative metrikker og kvalitative interview til at fastlægge niveauet af testprocesmodenhed.





8.7 Forbedring af testprocessen med CTP (CTP) Som beskrevet i [Black02] er den basale forudsætning for Critical Testing Process vurderingsmodellen at visse testprocesser er kritiske. Disse kritiske processer understøtter succesfulde testteams, hvis de udføres korrekt. Hvis disse aktiviteter omvendt udføres dårligt, er det svært for selv talentfulde individuelle testere og testansvarlige at få succes. Modellen identificerer tolv kritiske testprocesser. CTP er primært en indholdsreferencemodel. Modellen for de kritiske testprocesser er en kontekstafhængig tilgang, der tillader, at modellen skræddersys herunder:

• Identifikation af specifikke udfordringer • Erkendelse af attributter for gode processer • Valg af rækkefølgen og vigtigheden af implementering af procesforbedringer

Modellen for de kritiske testprocesser kan tilpasses inden for sammenhængen af alle livscyklusmodeller for softwareudvikling. Procesforbedringer ved brug af CTP begynder med en vurdering af den eksisterende testproces. Vurderingen identificerer, hvilken processer der er stærke, og hvilke der er svage, og giver prioriterede anbefalinger til forbedring baseret på organisatoriske behov. Selv om vurderingerne afhænger af den specifikke sammenhæng, de udføres i, undersøges følgende kvantitative metrikker normalt i forbindelse med en CTP-vurdering:

• Defect Detection Percentage • Afkast af testinvesteringen • Kravdækning og risikodækning • Ekstraomkostninger ved testfrigivelse • Afvisningshyppighed for fejlrapporter

Følgende kvalitative faktorer evalueres normalt i forbindelse med en CTP-vurdering:

• Testgruppens rolle og effektivitet • Testplanens anvendelighed • Testgruppens kvalifikationer inden for test, domænekendskab og teknologi • Fejlrapportanvendelighed • Anvendelighed af testresultatrapportering • Anvendelighed af og balance i ændringsstyringen.

Når en vurdering har identificeret svage områder, udarbejdes planer for forbedringer. Modellen indeholder generiske forbedringsplaner for hver af de kritiske testprocesser, men det forventes, at vurderingsgruppen foretager en kraftig skræddersyning af disse.

8.8 Forbedring af testprocessen med STEP I lighed med CTP, men i modsætning til TMMi og TPI, kræver STEP (Systematic Test and Evaluation Process) ikke, at forbedringer sker i en bestemt rækkefølge. De basale forudsætninger for metoden omfatter:

• En kravbaseret teststrategi • Test starter i begyndelsen af livscyklussen • Tests bruges som krav- og anvendelsesmodeller • Design af test-delprodukter kommer før softwaredesign • Defekter registreres tidligere, eller forhindres helt • Defekter analyseres systematisk • Testere og udviklere arbejder sammen.

STEP er primært en indholdsreferencemodel.





STEP-metoden er baseret på den ide, at test er en livscyklusaktivitet, der starter under formuleringen af krav og fortsætter indtil systemet trækkes tilbage. STEP-metoden lægger vægt på "test, derefter kodning" gennem anvendelse af en kravbaseret teststrategi, der skal sikre, at en tidlig oprettelse af testcases validerer kravspecifikationerne før design og kodning. Metoden fastlægger og fokuserer på forbedring af tre væsentlige faser ved test:

• Planlægning • Erhvervelse • Måling

Under en STEP-vurdering bruges der kvantitative metrikker og kvalitative interview. Kvantitative metrikker omfatter:

• Teststatus over tid • Testdækning af krav eller risici • Defekttendenser, herunder opdagelse, alvorlighedsgrad og klyngedannelse • Defekttæthed • Effektivitet i fjernelse af defekter • Defect Detection Percentagel • Defektintroduktions, opdagelses- og fjernelsesfaser • Omkostninger til test i form af tid, arbejdsindsats og penge

Kvantitative faktorer omfatter:

• Brug af defineret testproces • Kundetilfredshed.

I nogle tilfælde blandes STEP-vurderingsmodellen med TPI-modenhedsmodellen.

8.9 CMMI (Capability Maturity Model Integration) CMMI kan implementeres via to tilgange eller repræsentationer: den trinvise repræsentation eller den kontinuerte i den trinvise repræsentation er der fem "modenhedsniveauer", hvor hvert niveau bygger på de procesområder, der er etableret i de foregående niveauer. I den kontinuerte repræsentation har organisationen lov til at koncentrere sit forbedringsarbejde om sine egne primære behovsområder uden hensyn til foregående niveauer. Den trinvise repræsentation er primært inkluderet i CMMI for at sikre overensstemmelse med CMM, mens den kontinuerte repræsentation generelt betragtes som mere fleksibel. Inden for CMMI refererer procesområderne Validering og Verificering både til statiske og dynamiske testprocesser.





9. Testværktøjer og -automation

Termer Debugging-værktøj, dynamisk analyseværktøj, emulator, fejlplantningsværktøj, testværktøjer til hyperlinks, nøgleordsdrevet test, performancetestværktøj, simulator, statisk analysator, testafviklingsværktøj, teststyringsværktøj, testorakel

9.1 Introduktion Dette afsnit er udvidet i forhold til Foundation Level Syllabus, da det først dækker et antal generelle begreber og derefter gennemgår nogle specifikke værktøjer mere detaljeret. Selv om nogle af de begreber, der dækkes, muligvis er mere relevante for enten testansvarlige, testanalytikere eller tekniske testanalytikere, så kræves det, at alt testpersonale har en grundlæggende forståelse af begreberne. Denne grundlæggende forståelse kan udvides, hvor det er passende. Værktøjer kan grupperes på et antal forskellige måder, herunder en gruppering efter deres aktuelle bruger, f.eks. testansvarlige, testanalytikere og tekniske testanalytikere. Denne bestemte gruppering, der afspejler modulerne i denne syllabus, bruges i de resterende afsnit i dette kapitel. De værktøjer, der gennemgås i disse afsnit, er generelt primært relevante for specifikke moduler, selv om visse værktøjer (f.eks. teststyringsværktøjer) kan have en bredere relevans. Hvor dette er tilfældet, giver kursusudbyderen eksempler på værktøjets anvendelse i specifikke sammenhænge.

9.2 Testværktøjskoncepter Testværktøjer kan give en stor forbedring af effektiviteten og præcisionen af testarbejdet, men kun hvis de rigtige værktøjer implementeres på den rigtige måde. Testværktøjer skal styres som et andet aspekt i en velkørende testorganisation. Testautomatisering antages ofte at være synonym med testafvikling, med det meste manuelle arbejde har forskellige former for testautomation, hvilket betyder, at de fleste områder inden for test kunne automatiseres til en vis grad, hvis de rigtige værktøjer var til stede. Enhver testværktøjsversion, ethvert testscript eller enhver testsession skal som alt testgrundlag være under konfigurationsstyring og knyttet til en bestemt softwareversion, hvor den eller det er blevet anvendt. Ethvert testværktøj er en vigtig del af test-delprodukterne og skal styres i overensstemmelse med dette, f.eks. gennem:

• Oprettelse af en arkitektur før udarbejdelsen af testværktøjet • Sikring af korrekt konfigurationsstyring af script- og værktøjsversioner, rettelser etc., herunder

versionsoplysninger • Oprettelse og vedligeholdelse af biblioteker (genbrug af ensartede begreber i testcases), dokumentation

af testværktøjets indførelse (f.eks. hvordan værktøjet bruges og udnyttes i organisationen) • Planlægning af fremtiden gennem strukturering af testcases til fremtidig udvikling, f.eks. ved at

konstruere dem, så de kan udvides og vedligeholdes.

9.2.1 Cost-benefit og risici ved testværktøjer og automatisering Der skal altid udføres en cost-benefit-analyse, og den skal vise et væsentligt positivt afkast af investeringen. Hovedelementerne ved en cost-benefit-analyse skal omfatte følgende omkostningselementer ved sammenligning af de aktuelle omkostninger ved både manuel test (uden anvendelse af værktøj) og værktøjsanvendelse i form af omkostninger (timer oversat til omkostninger, direkte omkostninger, vedvarende og ikke-vedvarende omkostninger):

• Startomkostninger o Erhvervelse af viden (indlæringskurve for værktøj) o Evaluering (værktøjssammenligninger), hvor det er nødvendigt o Integration med andre værktøjer o Overvejelse af startomkostninger til indkøb, tilpasning eller udvikling af værktøj.

• Vedvarende omkostninger





o Omkostninger ved værktøjsejerskab (vedligeholdelse, licensgebyr, supportgebyr, opretholdelse af vidensniveau)

o Flytbarhed o Tilgængelighed og afhængigheder (hvis de mangler) o Kontinuerlig evaluering af omkostninger o Kvalitetsforbedring for at sikre optimal anvendelse af de valgte værktøjer.

Businesscases, der kun er baseret på pilotautomatiseringsprojekter, mangler ofte vigtige omkostninger som omkostningerne til vedligeholdelse, opdatering og udvidelse af testscriptene, når systemet ændres. En testcases holdbarhed er det tidsrum, hvor den forbliver gyldig uden ændring. Den tid, der kræves for at implementere den første version af automatiserede testscripts, er ofte langt større end den tid, det tager at køre dem manuelt. Men det giver samtidig mulighed for at oprette mange flere lignende testscripts meget hurtigere, og det er lettere at udvide antallet af gode testcases med tiden. Desuden vil der ske en betydelig forbedring af testdækningen og testeffektiviteten i forbindelse med fremtidige anvendelser af automationen efter implementeringsperioden. Businesscasen for værktøjsindførelse skal være baseret på den langsigtede businesscase. På et specifikt niveau skal hver testcase bedømmes, for at se, om det kan betale sig at automatisere den. Mange automationsprojekter er baseret på implementering af allerede tilgængelige manuelle testcases, uden at der er foretaget en vurdering af de faktiske fordele ved automation i hvert enkelt tilfælde. Det er sandsynligt, at alle givne sæt af testcases (en sekvens) kan indeholde manuelle, halvautomatiserede og fuldautomatiserede tests. Udover de emner, der er dækket i Foundation Level Syllabus, skal følgende emner overvejes: Yderligere fordele:

• Afviklingstiden for automatiseret test bliver mere forudsigelig. • Regressionstest og defektvalidering er hurtigere og sikrere sent i projektet, når testcasene er

automatiserede. • Brugen af automatiserede værktøjer kan forøge testerens eller testteamets status og tekniske vækst. • Automatisering kan bruges til parallel, iterativ og trinvis udvikling, så der opnås en bedre regressionstest

for hvert build. • Dækning af visse testtyper, der ikke kan dækkes manuelt (f.eks. performance og pålidelighed).

Yderligere risici:

• Ufuldstændig eller forkert manuel test automatiseres, som den er. • Test-delproduktet er vanskeligt at vedligeholde, og det kræver mange ændringer, når softwaren under

test ændres. • Tabet af testerens direkte involvering i afviklingen kan reducere defektregistreringen, da kun

automatiserede og scriptede test udføres.

9.2.2 Testværktøjsstrategier Testværktøjer skal normalt bruges til mere end ét bestemt projekt. Afhængigt af investeringens størrelse og længden af et projekt, giver det muligvis ikke et tilfredsstillende afkast i projektet, men gør det i forbindelse med efterfølgende versioner af softwaren. Da vedligeholdelsesfasen f.eks. ofte er testintensiv (for hver ændring skal der afvikles en større regressionssekvens), kan det nogle gange være en omkostningsmæssig fordel at automatisere et system, der er i vedligeholdelsesfasen, hvis systemets levetid gør det økonomisk attraktivt. I andre tilfælde er det let for personer at tage fejl under afvikling af manuel test (f.eks. tastefejl), derfor kan det omkostningsmæssigt være fordelagtigt at automatisere input af data og sammenligne outputdata med data fra et orakel (f.eks. sammenligning af testresultater med forventede resultater) i en testsekvens. For virksomheder, der bruger og er afhængige af mange testværktøjer (til forskellige faser og formål), er det anbefalelsesværdigt at have en langsigtet testværktøjsstrategi til støtte ved beslutninger om ind- og udfasning af forskellige værktøjsversioner og værktøjssupport. I større virksomheder med et værktøjsintensivt forretningsområde kan det være anbefalelsesværdigt at angive generelle retningslinjer for værktøjsanskaffelse, strategier, værktøjsparadigmer eller hvilket script-sprog, der skal anvendes.





9.2.3 Integration og informationsudveksling mellem værktøjer Normalt anvendes der mere end et testværktøj i testprocessen (og udviklingsprocessen). Lad os tage et eksempel med en virksomhed, der på samme tid bruger et statisk analyseværktøj, et teststyrings- og -rapporteringsværktøj, et konfigurationsstyringsværktøj, et hændelseshåndteringsværktøj og et testafviklingsværktøj. Det er vigtigt at overveje, om værktøjerne kan integreres og udveksle oplysninger med hinanden på en nyttig måde. Det vil f.eks. være nyttigt, hvis al status for testafvikling blev rapporteret direkte til teststyringssystemet for at opnå øjeblikkelig opdatering af fremdriften og direkte sporbarhed fra krav til en bestemt testcase. Det er et større arbejde og mere risikabelt at lagre testscripts både i en teststyringsdatabase og i konfigurationsstyringssystemet. Hvis en tester ønsker at starte en hændelsesrapport midt i afviklingen af en testcase, skal hændelseshåndterings- og teststyringssystemerne være integreret. Selv om statiske analyseværktøjer kan være adskilt fra de andre værktøjer, er det meget mere praktisk, hvis værktøjet kan rapportere hændelser, advarsler og feedback direkte til teststyringssystemet. Selvom man køber en række testværktøjer fra den samme leverandør, betyder det ikke automatisk, at værktøjerne arbejder sammen på denne måde, men det er et fornuftigt krav. Alle disse aspekter skal vurderes ud fra omkostningen ved at automatisere udvekslingen af oplysninger sammenlignet med risikoen ved at få ødelagt eller miste oplysninger gennem rent manuelt arbejde, under forudsætning af, at organisationen har den tid til arbejdet, som det kræver. Nye koncepter som de integrerede udviklingsmiljøer som Eclipse har til formål at lette integrationen og brugen af forskellige værktøjer i det samme miljø gennem et fælles interface til udviklings- og testværktøjer. En værktøjsleverandør kan blive Eclipse- "kompatibel" ved at oprette et plug-in til Eclipse-strukturen, der får det til at have samme udseende og betjening som alle andre værktøjer. Dette giver brugeren en god fordel. Bemærk: Selvom brugergrænsefladen er ensartet, betyder dette ikke automatisk, at værktøjerne er integrerede og kan udveksle oplysninger.

9.2.4 Automatiseringssprog: Scripts, scriptsprog Scripts og scriptsprog bruges nogle gange til at forbedre udarbejdelse og udvidelse af testbetingelser og testcases. Ved test af et websystem kan et script muligvis bruges til at omgå brugergrænsefladen for at opnå en bedre test af selve API (application programming interface). Et andet eksempel kan være det tilfælde, hvor testen af en brugergrænseflade er automatiseret for at tillade alle mulige kombinationer af input, hvilket ikke vil være muligt ved manuel test. Der er stor forskel på mulighederne i scriptsprog. Bemærk, at scriptsprog kan række fra normale programmeringssprog til meget specielle standardnotationer, f.eks. signalering til protokoller som TTCN-3.

9.2.5 Begrebet testorakler Testorakler bruges generelt til at bestemme forventede resultater. I denne funktion udfører de den samme funktion som softwaren under testede og er derfor sjældent tilgængelige. De kan dog bruges i situationer, hvor et gammelt system erstattes af et nyt system med samme funktionalitet, så det gamle system kan bruges som et orakel. Orakler kan også bruges, hvor performance er et vigtigt område for det leverede system. Et orakel med lav performance kan fremstilles eller bruges til at generere forventede resultater til den funktionelle test af den software med høj performance, der skal leveres.

9.2.6 Testværktøjsanvendelse Alle automatiserede værktøjer er selv software og kan have hardware- og softwareafhængigheder. Et værktøj skal selv være dokumenteret og testet, uanset om det er købt som det er, tilpasset eller hjemmelavet. Nogle værktøjer er mere integreret i miljøet, og andre værktøjer arbejder bedre som selvstændige værktøjer. Når systemet under test kører på proprietær hardware, operativsystemer, indlejret software eller bruger ikke-standardkonfigurationer, er det muligvis nødvendigt at oprette (udvikle) et værktøj eller tilpasse et værktøj, så det passer til det specifikke miljø. Det er altid tilrådeligt at foretage en cost-benefit-analyse, der omfatter den første indførelse samt langsigtet vedligeholdelse.





Under anvendelse af et testautomatiseringsværktøj er det ikke altid klogt at automatisere manuelle testcases, som de er, man skal i stedet redefinere testcasene for at få en bedre automatiseringsanvendelse. Dette omfatter formatering af testcasene, overvejelser om genbrugsmønstre, udvidelse af input ved brug af variabler i stedet for faste værdier og udnyttelse af fordelene ved testværktøjet, der har muligheder for at gennemløbe, gentage og ændre rækkefølgen, så der opnås bedre analyse- og rapporteringsfaciliteter. I forbindelse med mange testautomatiseringsværktøjer er det nødvendigt med programmeringsfærdigheder for at kunne oprette effektive testprogrammer (scripts) og testsekvenser. Det er almindeligt, at store testsekvenser er meget vanskelige at opdatere og styre, hvis de ikke er designet omhyggeligt. Det er værdifuldt med passende uddannelse i testværktøjer, programmerings- og designteknikker for at sikre at alle fordele ved værktøjerne udnyttes. Selv når manuelle testcases er blevet automatiseret, er det vigtigt af og til at afvikle testcasene manuelt for at opretholde en viden om, hvordan testen virker, og for at kontrollere, at den fungerer korrekt. Når et værktøj bliver brugt og antallet af testscripts vokser, er der muligvis behov for at tilføje funktioner, der kan leveres af andre værktøjer. Dette er ikke altid muligt, da værktøjer ikke altid har åbne grænseflader og nogle gange bruger proprietære ikke-standardiserede scriptsprog. Det er klogt at bruge værktøjer, der har plug-ins til åbne strukturer eller API (Application Programming Interface). Dette garanterer en bedre fremtidssikring af testscripts som test-delprodukter. Uanset i hvilken fase en værktøjstype skal bruges i, skal man for hver af dem overveje de karakteristika, der er angivet nedenfor. Disse karakteristika kan bruges både ved evaluering af værktøjer og i forbindelse med fremstillingen af et værktøj. På hvert af disse områder kan et værktøj være svagt eller stærkt. En liste som denne kan være nyttig ved sammenligning af mulighederne i ensartede værktøjer.

• Analyse (forståelse af begreber, input og oplysninger, der leveres manuelt eller automatisk) • Design (manuelt eller genereret automatisk) • Udvælgelse (manuel eller automatisk valg i forhold til en række kriterier, f.eks. dækning) • Afvikling (manuel, automatisk, drevet, genstartet etc.) • Evaluering (f.eks. testorakel) og præsentation. Dette refereres ofte til som lognings- eller

rapporteringsfunktioner (manuelle, automatiske f.eks. sammenlignende, i forhold til en formular, standard, oprettet ud fra et kriterium).

9.2.7 Brug af open source-testværktøjer Værktøjer, der bruges til at teste sikkerhedskritiske systemer, skal være certificeret til at overholde det tiltænkte formål i forhold til de tilhørende standarder. Det anbefales ikke at bruge open source-værktøjer i sikkerhedskritiske systemer, medmindre de har opnået det passende certificeringsniveau. Kvaliteten af open source-software er afhængig af eksponeringen, historikken og anvendelsen af den pågældende software, og skal ikke antages at være mere (eller mindre) præcis end kommercielle værktøjer. Der bør altid foretages en vurdering af kvaliteten af ethvert testværktøj for at vurdere værktøjets nøjagtighed. For nogle værktøjstyper er det lettere at forveksle et positivt evalueringsresultat med en forkert værktøjafvikling (værktøjet sprang f.eks. over tests uden at rapportere, at disse blev sprunget over). Man bør nøje overveje licensgebyrer. Der kan også være en forventning om, at kodeændringer, der udvider værktøjet, bliver delt.

9.2.8 Udvikling af egne testværktøjer Mange testværktøjer er udviklet på basis af en enkelt testers eller designers behov for at kunne arbejde hurtigere. Andre årsager til selvudviklede testværktøjer er manglen på passende kommercielle værktøjer eller brugen af proprietær hardware eller testmiljø. Disse værktøjer er ofte effektive til at udføre den opgave, de skal løse, men de er ofte meget afhængige af den person, der udarbejdede værktøjet. Disse værktøjer bør være dokumenteret på en måde, så de kan vedligeholdes af andre. Det er også vigtigt at gennemgå formålet, målet, fordelene og mulige ulemper, før værktøjet spredes ud over en organisation. Ofte bliver der stillet nye krav til disse værktøjer og de bliver udvidet langt ud over den oprindelige anvendelse, hvilket muligvis ikke er fordelagtigt.





9.2.9 Klassifikation af testværktøjer Udover en opdeling af værktøjer efter hvilken aktivitet de understøtter (der er det koncept, der anvendes på Foundation-niveauet), findes der andre værktøjsklassifikationssystemer, herunder:

• Værktøjer grupperet efter, hvilket testniveau der udføres (komponent, integration, system eller accept) • Værktøjer grupperet efter, hvilke afvigelser de behandler og understøtter • Værktøjer baseret på testtilgang eller testteknik (se yderligere diskussion nedenfor) • Værktøjer til forskellige testformål, f.eks. måling, drivere, logning og sammenligninger) • Værktøjer til specifikke forretningsområder, f.eks. trafiksimulering og -signalering, netværk, protokoller,

transaktioner, tv-skærme, ekspertsystemer • Værktøjer til support af forskellige områder inden for test, f.eks. datainput, miljø, konfiguration eller andre

begrebsmæssige områder • Værktøjer baseret på, hvordan værktøjet anvendes: Hyldevarer, rammeværk (til tilpasning), plug-in

tilpasning (dvs. Eclipse), standard- eller certificeringstestsekvens, intern udvikling af værktøjer. Og endelig kan værktøjer grupperes efter deres faktiske bruger, f.eks. testansvarlige, testanalytikere og tekniske testanalytikere. Denne gruppering, der afspejler modulerne i denne syllabus, bruges til de resterende afsnit i dette kapitel. Foundation Level Syllabus indeholder et afsnit om værktøjer. Afsnittene nedenfor er yderligere aspekter ved disse værktøjer.

9.3 Testværktøjskategorier Der er følgende mål med dette afsnit:

• at give yderligere oplysninger om de værktøjskategorier, der allerede er introduceret i ISTQB® Foundation Level Syllabus afsnit 6, f.eks. teststyringsværktøjer, testafviklingsværktøjer og performancetestværktøjer

• at introducere nye værktøjskategorier. Generelle oplysninger om andre værktøjskategorier, der ikke er indeholdt i dette afsnit, kan findes i afsnit 6 i ISTQB® Foundation Level Syllabus

9.3.1 Teststyringsværktøjer Generelle oplysninger om teststyringsværktøjer kan findes i afsnit 6.1.2 i ISTQB® Foundation Level Syllabus. Teststyringsværktøjer bør kunne følge op på følgende information:

Sporbarheden af testartefakter

Indsamling af testmiljødata i komplicerede miljøer

Data vedrørende afviklingen af samtidige testsekvenser i forskellige testmiljøer i den samme testsession på tværs af flere lokationer (testorganisationer)

Metrikker, så som: o Testbetingelser o Testcases o Tid til afvikling (f.eks. af en testcase, en sekvens, en regressionssekvens) og andre vigtige

tidsfaktorer, herunder gennemsnit, der kan bidrage til ledelsesbeslutninger o Antal af testcases, testartefakter og testmiljøer o Rater for bestået/fejlet o Antallet af udestående testcases (og årsagerne til, at de ikke afvikles) o Tendenser o Krav o Relationer og sporbarhed mellem testartefakter

Koncepter, der understøttes af teststyringsværktøjer, så som: o Organisering af testartefakter, lager og driver for testcases o Testbetingelser og testmiljøer o Regressionssekvenser, testsessioner o Logning og information om afvigelseshåndtering o Genstart af miljø (og re-initalisering) o Testmetrikker om testartifakterne (testdokumentation) til dokumentation af testfremdriften.





Teststyringsværktøjer bruges af testansvarlige, testanalytikere og tekniske testanalytikere.

9.3.2 Testafviklingsværktøj Generelle oplysninger om testafviklingsværktøj kan findes i afsnit 6.1.5 i ISTQB® Foundation Level Syllabus. Testafviklingsværktøj bruges mest af testanalytikere og tekniske testanalytikere på alle testniveauer til at køre test og til at kontrollere resultatet af testene. Formålet med at anvende et testafviklingsværktøj er normalt et af følgende:

at reducere omkostningerne (indsats eller tid)

at køre flere tests

at gøre tests lettere at gentage. Testafviklingsværktøj bruges oftest til at automatisere regressionstest. Testafviklingsværktøj fungerer ved udførelsen af et sæt instruktioner, der er skrevet i et programmeringssprog, der ofte kaldes et scriptsprog. Instruktionerne til værktøjet er på et meget detaljeret niveau, der angiver tryk på de enkelte knapper, tryk på taster og musebevægelser. Det gør de detaljerede scipts meget følsomme over for ændringer i softwaren under test (SUT), specielt over for ændringer i den grafiske brugergrænseflade (GUI). Udgangspunktet for et script er muligvis en optagelse (foretaget ved hjælp af afspilning af hentninger) eller et konstrueret eller redigeret script, der anvender eksisterende scripts, skabeloner eller nøgleord. Scripting er et program og fungerer præcist som enhver anden software. Hentning (eller optagelse) kan bruges til at optage et revisionsspor til ikke-systematisk test. De fleste testafviklingsværktøjer indeholder en sammenligner, en funktion til sammenligning af et faktisk resultat med et gemt forventet resultat. Tendensen i test (som i programmering) er en bevægelse fra detaljerede instruktioner på lavt niveau til sprog på et "højere niveau". Her benyttes igen biblioteker, makroer og underprogrammer. En serie instruktioner er forsynet med ét navn – i test kaldet nøgleords- eller handlingsordsdrevet. Den største fordel er adskillelsen af instruktioner og data. Det er det samme koncept, som når der anvendes skabeloner i forbindelsen med scripting for at minimere brugerindsatsen. Hovedårsagen til, at der opstår fejl i nogle værktøjer, er, at brugerne mangler programmeringsfærdigheder og forståelse for, at et testværktøj kun løser nogle af problemerne ved automatisering af testafvikling. Det er vigtigt at bemærke, at enhver automatisering af testafvikling kræver styring, arbejdsindsats, færdigheder og opmærksomhed, f.eks. testarkitektur og konfigurationsstyring. Det betyder også, at der kan være fejl i testscripts. Brugen af en arkitektur for testdelprodukter kan muligvis give uafhængighed af en bestemt værktøjsleverandør. Når et værktøj er anskaffet, er der en tendens til at mene, at dette værktøjs standarder skal følges, f.eks. med hensyn til strukturen og navngivningskonventionerne for scripts. Men automatiseringen af testopsætningen kan danne en grænseflade mellem din egen bedste måde at organisere test på og værktøjets krav til, hvor det skal finde dem for at kunne køre dem.

9.3.3 Debugging- og fejlfindingsværktøjer Ved fejlfinding kan der anvendes værktøjer til at indskrænke det område, hvor en fejl opstår. Dette kan der også være brug for i et system, hvor det ikke er klart, hvilken fejl, der forårsagede den pågældende afvigelse. Fejlfindingsværktøjer omfatter sporinger og simulerede miljøer, der bruges til at arbejde sammen med softwaren og udtrække oplysninger fra systemet for at indkredse placeringen af fejlen. Programmører genskaber fejl og undersøger programmernes tilstand ved brug af værktøjer til debugging og sporing. Debugging og sporing giver programmørerne mulighed for at:

køre programmerne linje for linje

stoppe programmet ved et hvilket som helst udtryk

angive og undersøge programvariabler. Det skal gøres klart, at debugging (og debuggingværktøjer) er forbundet med test, med det er ikke test (eller testværktøjer). Debugging og sporingsværktøjer kan bruges til fejlfindingsformål af testere, så de bedre kan lokalisere en fejlkilde og lettere kan bestemme, hvor en fejlrapport skal sendes hen. Debugging, sporing og fejlfindingsværktøjer bruges især af tekniske testanalytikere.





9.3.4 Fejlplantnings- og fejlindsættelsesværktøjer Fejlplantning og fejlindsættelse er to forskellige teknikker, der kan bruges ved test. Fejlplantning bruger et værktøj, der svarer til en compiler, til at oprette enkle eller begrænsede typer af kodefejl på en systematisk måde. Disse værktøjer bruges også ofte sammen med mutationstestteknikken og kaldes nogle gange mutationstestværktøjer. Målet med fejlindsættelse er at ændre den faktiske grænseflade til testkomponenter (når kildekoden ikke er tilgængelig), men det kan også være med overlæg at (gen)indsætte en bestemt fejl for at kontrollere, om 1) softwaren kan behandle den (fejltolerance), eller 2) for at evaluere om en test i en sekvens af testcases finder den fejl, der med overlæg er indsat. Fejlplantning og fejlindsættelsesværktøjer bruges hovedsagelig på kodeniveau af tekniske testanalytikere, men det er også muligt for en testanalytiker at ændre data i en database eller indsætte fejl i datastrømmen for at teste systemets adfærd.

9.3.5 Simulerings- og emuleringsværktøjer Simulatorer bruges til at understøtte test, hvor kode eller andre systemer ikke er tilgængelige, dyre eller upraktiske at bruge (f.eks. test af software til håndtering af nukleare nedsmeltninger). Nogle simulatorer og teststilladsværktøjer kan også understøtte eller efterligne fejladfærd, så fejltilstande eller fejlscenarier kan kontrolleres. Hovedrisikoen ved brug af disse værktøjer er, at ressourcerelaterede fejl som timingsproblemer muligvis ikke bliver fundet, hvilket er meget vigtigt for nogle typer af systemer. Emulatorer er en bestemt kategori simulatorer, og de består af software, der er skrevet til at efterligne hardwaren. Fordelen ved at bruge emulatorer er, at det muligvis er muligt at foretage en mere udførlig test. Én speciel fordel ved emulatorer er, at sporing, debugging og tidsafhængige årsager kan oprettes igen, hvilket muligvis ikke er muligt i et virkeligt system. Emulatorer er kostbare at oprette, men fordelen ved analyse, hvor systemet kan køres i "slow-motion", er uvurderlig for nogle parallelle, tidsafhængige og komplekse systemer. Testanalytikere og tekniske testanalytikere bruger disse værktøjer, afhængigt af den krævede emuleringstype.

9.3.6 Statiske og dynamiske analyseværktøjer Du kan finde generelle oplysninger om statiske og dynamiske testanalyseværktøjer i afsnit 6.1.6 "Værktøjsstøtte til performance og overvågning i ISTQB® Foundation Level Syllabus.

9.3.6.1 Statiske analyseværktøjer

Statiske analyseværktøjer kan bruges på et hvilket som helst tidspunkt i softwarens livscyklus og også på alle niveauer og i alle faser af softwareudviklingen afhængigt af de målinger, der leveres af værktøjet. Statiske analyseværktøjer rapporterer deres resultater i form af advarsler. Advarsler, der er ubegrundede, kaldes falske positive. Ægte positive advarsler er reelle fejl, der kan føre til afvigelser under udførelsen. Det kan være vanskeligt og tidskrævende at skelne falske advarsler fra ægte positive advarsler, da det kræver en korrekt fejlfinding. Flere nyere statiske analyseværktøjer kan bruge oplysninger i den dynamiske binding under kompilering, og de er derfor stærkere til at finde reelle fejl med færre falske positive. Tekniske testanalytikere bruger disse værktøjer.

9.3.6.2 Dynamiske analyseværktøjer

Dynamiske analyseværktøjer giver run-time-oplysninger om tilstanden af den kørende software. Disse værktøjer bruges oftest til at identificere ikke-tildelte pointere, aritmetik for kontrolpointere, overvågning af allokeringen, brugen og deallokeringen af hukommelse, til markering af hukommelseslæk og fremhævning af andre fejl, det er svært at finde "statisk". Hukommelsesværktøjer skal genbruges på mere end et niveau i store komplekse systemer, da hukommelsesproblemer skabes dynamisk. Bemærk, at forskellige kommercielle testværktøjer muligvis implementeres forskelligt og derfor er rettet mod og rapporterer forskellige typer af hukommelses- eller ressourceproblemer (stak, heap). Konklusionen er, at to forskellige hukommelsesværktøjer kan identificere forskellige problemer. Hukommelsesværktøjer er især nyttige i forbindelse med nogle programmeringssprog (C, C++), hvor styringen af hukommelsen er overladt til programmøren. Tekniske testanalytikere bruger disse værktøjer.





9.3.7 Nøgleordsdrevet testautomation Nøgleord (der nogen gange kaldes "handlingsord") bruges mest (men ikke udelukkende) til at repræsentere forretningsinteraktioner på højt niveau med et system (f.eks. "annuller ordre"). Hvert nøgleord bruges typisk til at repræsentere et antal detaljerede interaktioner med det system, der testes. Sekvenser af nøgleord (inklusive relevante testdata) bruges til at angive testcases.[Buwalda01] Ved testautomation implementeres et nøgleord som et eller flere eksekverbare testscripts. Værktøjer læser testcases, der er skrevet med nøgleord og kalder de tilhørende testscripts, der implementerer dem. Scripts er implementeret på en meget modulær måde, så det er let at lave mapping til specifikke nøgleord. Der kræves kendskab til programmering for at kunne implementere disse modulære scripts. De primære fordele ved nøgleordsdrevet testautomation er:

Nøgleord kan defineres af områdeeksperter, der har tilknytning til et bestemt program eller forretningsområde. Dette kan gøre arbejdet med specifikation af testcases mere effektivt.

En person med primær områdeekspertise kan drage fordel af automatisk udførelse af testcases (når nøgleordene først er blevet implementeret som scripts).

Testcases, der er skrevet med nøgleord, er lettere at vedligeholde, fordi det er mindre sandsynligt, at der skal foretages ændringer, hvis der er ændringer i den software, der testes.

Specifikationerne af testcases er uafhængige af deres implementering. Nøgleordene kan implementeres ved brug af forskellige scriptsprog og værktøjer.

Nøgleordsbaseret testautomation bruges især af områdeeksperter og testanalytikere.

9.3.8 Performancetestværktøjer Du kan finde generelle oplysninger om performancetestværktøjer i afsnit 6.1.6 "Værktøjsstøtte til performance og overvågning i ISTQB® Foundation Level Syllabus. Performancetestværktøjer har to hovedfunktioner:

belastningsgenerering

måling og analyse af systemets reaktion på en given belastning Belastningsgenerering udføres ved at implementere en foruddefineret operationel profil (se afsnit 5.3.3) som et script. Scriptet er muligvis oprindeligt indsamlet til en enkelt bruger (muligvis ved brug af et indsamlings-/afspilningsværktøj) og derefter implementeret for den angivne operationelle profil ved bruger af performancetestværktøjet. Denne implementering skal tage højde for variationen i data pr. transaktion (eller transaktionssæt). Performanceværktøjer genererer en belastning ved at simulere et stort antal brugere ("virtuelle" brugere) med specifikke mængder af inputdata. I sammenligning med indsamlings-/afspilningsværktøjer reproducerer mange performancetestscripts brugernes interaktion med systemet på kommunikationsprotokolniveau og ikke ved at simulere brugerinteraktion via et grafisk brugerinterface. Et begrænset antal af værktøjerne til belastningsgenerering kan generere en belastning ved at køre programmet ved brug af dets brugergrænseflade. Performancetestværktøjet tager en mængde målinger for at gøre det muligt at foretage analyser under eller efter afviklingen af testen. De typiske metrikker, der tages, og rapporter, der er til rådighed, omfatter:

antallet af simulerede brugere

antallet og typen af transaktioner, der er genereret af de simulerede brugere

svartiderne på bestemte transaktionsanmodning, der er foretaget af brugerne

rapporter baseret på testlogger, og grafer med belastning i forhold til svartider. Blandt de betydelige faktorer, der skal overvejes ved implementeringen af performancetestværktøjer, er:

Den hardware- og netværksbåndbredde, der kræves for at generere belastningen.

Værktøjets kompatibilitet med den kommunikationsprotokol, der anvendes af det system, der testes.

Værktøjets fleksibilitet med hensyn til at tillade, at forskellige operationelle profiler let implementeres.

De krævede overvågnings-, analyse- og rapporteringsfaciliteter.





Performancetestværktøjer købes typisk, fordi det kræver en stor arbejdsindsats at udvikle dem. Men det kan måske være relevant at udvikle et specifikt performanceværktøj, hvis tekniske restriktioner forhindrer, at et produkt bruges, eller hvis det er relativt let at angive belastningsprofilen og skaffe de nødvendige faciliteter. Performancetestværktøjer bruges typisk af tekniske testanalytikere. Bemærk: performancerelaterede fejl har ofte en stor indvirkning på softwaren under test. Når performancekravene er afgørende, er det ofte nyttigt at køre performancetest af de kritiske komponenter (via drivere og stubbe) i stedet for at vente på systemtest.

9.3.9 Webværktøjer Testværktøjer til hyperlinks bruges til at scanne for og kontrollere, at der ikke er nogle ødelagte eller manglende hyperlinks på et websted. Nogle værktøjer giver også yderligere oplysninger, f.eks. grafer over arkitekturen (webstedets træstruktur), hastigheden for og størrelsen af overførsler (pr. URL), hits og mængder. Disse værktøjer kan også være nyttige til at overvåge overholdelsen af serviceniveauaftaler (SLA). Testanalytikere og tekniske testanalytikere bruger disse værktøjer.





10. Personlige evner – gruppesammensætning

Termer Uafhængighed i test.

10.1 Introduktion Alle professionelle testere bør være opmærksomme på de individuelle evner, der kræves, for at de kan udføre deres specifikke opgaver godt. Dette afsnit fokuserer først på disse individuelle evner, og fortsætter derefter med et antal emner, der har speciel interesse for testansvarlige, så som gruppedynamik, organisation, motivation og kommunikation.

10.2 Individuelle evner En medarbejders evne til at teste software kan være opnået gennem erfaring eller ved uddannelse inden for forskellige arbejdsområder. Hvert af følgende punkter kan bidrage til testerens vidensbase:

Brug af softwaresystemer

Kendskab til domænet eller virksomheden

Aktiviteter i forskellige faser af softwareudviklingsprocessen, herunder analyse, udvikling og teknisk støttet

Aktiviteter i softwaretest. Brugerne af softwaresystemer kender brugersiden af systemet godt og har et godt kendskab til, hvordan systemet bruges, hvor afvigelser har den største effekt, og hvad systemets forventede reaktion er. Brugere, der har kendskab til domænet, ved, hvilke områder der er vigtigst for virksomheden, og hvordan disse områder påvirker virksomhedens evne til at opfylde sine krav. Denne viden kan bruges til at hjælpe med til at prioritere testaktiviteterne, oprette realistiske testdata og testcases og verificere eller udarbejde usecases. Kendskab til softwareudviklingsprocessen (kravsanalyse, design og kodning) giver indsigt i, hvordan defekter kan introduceres, hvor de kan findes, og hvordan det kan forhindres, at de introduceres. Erfaring med teknisk støtte giver viden om brugeroplevelsen, forventninger og krav til brugervenlighed. Erfaring med softwareudvikling er vigtig for brugen af avancerede testautomatiseringværktøjer, der kræver erfaring med programmering og design. Specifikke softwaretestevner inkluderer evnen til at analysere en specifikation, deltage i risikoanalyse, designe testcases og udvise påpasselighed ved kørsel af test og registreringen af resultaterne. Det er specielt vigtigt, at testansvarlige har viden om, evner inden for og erfaring med projektledelse, da teststyring svarer til at køre et projekt, f.eks. udarbejdelse af en plan, opfølgning på fremdrift og rapportering til interessenter. Mellemmenneskelige evner, så som at give og modtage kritik, påvirke andre og forhandle, er alle vigtige i forbindelse med testrollen. En teknisk kompetent tester risikerer at svigte i rollen, medmindre vedkommende besidder og anvender de nødvendige mellemmenneskelige evner. Ud over at arbejde effektivt med andre skal en succesfuld professionel tester også være velorganiseret, detaljeorienteret og have gode evner for både skriftlig og verbal kommunikation.

10.3 Testgruppedynamik Udvælgelse af medarbejdere er en af de vigtigste ledelsesopgaver i organisationen. Der er mange punkter, der skal overvejes i forbindelse med de specifikke individuelle evner krævet til jobbet. Når der udvælges enkeltpersoner til at være med i gruppen,, skal testgruppens dynamik overvejes. Komplementerer denne person de kvalifikationer og personlighedstyper, der allerede findes i testgruppen? Det er vigtigt at overveje fordelene ved at have forskellige personlighedstyper så vel som en blanding af forskellige tekniske evner i testgruppen. En stærk testgruppe er i stand til at håndtere flere projekter med varierende kompleksitet samtidig med, at den succesfuldt håndterer de mellemmenneskelige kontakter til andre projektgruppemedlemmer.





Nye gruppemedlemmer skal hurtigt optages i gruppen og få den tilstrækkelige vejledning. Hver person bør tildeles en defineret rolle i gruppen. Denne kan være baseret på en individuel vurderingsproces. Målet er at give hver enkeltperson en succesoplevelse som enkeltperson, samtidig med at vedkommende bidrager til gruppens overordnede succes. Dette sker i det store og hele ved at matche personlighedstyper gruppens roller og bygge på den enkeltes medfødte evner, samtidig med at man forøger deres samlede evner. Det er vigtigt at huske, at den perfekte enkeltperson sjældent er tilgængelig, men at der kan opbygges en stærk gruppe ved at afbalancere de enkeltes styrker og svagheder. Der kræves krydstræning i gruppen for at vedligeholde og opbygge gruppens viden og forøge fleksibiliteten.

10.4 Indpasning af test i en organisation Der er stor forskel på, hvordan test passer ind i den organisatoriske struktur i en organisation. Selv om kvalitet er alles ansvar igennem softwareudviklingslivscyklussen, kan en uafhængig testgruppe i høj grad bidrage til et kvalitetsprodukt. Testfunktionens uafhængighed varierer meget i praksis, som det kan ses af følgende liste, der er ordnet fra mindste til største uafhængighed:

Ingen uafhængige testere o I dette tilfælde er der ingen uafhængighed, og udvikleren tester sin egen kode. o Hvis udvikleren får tid til at foretage testen, vil han/hun afgøre, at koden fungerer som han/hun

regnede med, hvilket muligvis og muligvis ikke opfylder de faktiske krav. o Udvikleren kan hurtigt fikse alle fundne defekter.

Test foretages af en anden udvikler end den, der skrev koden o Der er lille uafhængighed mellem udvikleren og testeren. o En udvikler, der tester en anden udviklers kode, kan være tilbageholdende med at rapportere

defekter. o En udviklers indstilling til test er normalt fokuseret på positive testcases.

Test foretages af en tester (eller en testgruppe), der er en del af udviklingsgruppen o Testeren (eller testgruppen) rapporterer til projektledelsen. o Testeren er mest indstillet på at kontrollere, at kravene er overholdt. o Da testeren er medlem af udviklingsgruppen, kan han/hun have udviklingsansvar ud over

testansvar.

Testere fra forretningsorganisationen, brugergruppen eller andre tekniske organisationer, der ikke beskæftiger sig med udvikling

o Uafhængig rapportering til interessenterne. o Kvalitet er det vigtigste fokuspunkt for denne gruppe. o Udvikling af evner og uddannelse er fokuseret på test.

Eksterne testspecialister udfører test på specifikke testmål o Testmål kan være brugbarhed, sikkerhed eller performance. o Kvalitet bør være i fokus for disse enkeltpersoner, men det kan afhænge af

rapporteringsstrukturen.

Test foretages af en organisation, der er ekstern i forhold til virksomheden o Der opnås maksimal uafhængighed. o Overførsel af viden er muligvis ikke tilstrækkelig. o Der er behov for klare krav og en veldefineret kommunikationsstruktur. o Kvaliteten af den eksterne organisation skal revideres med jævne mellemrum.

Der er varierende grader af uafhængighed mellem udviklings- og testorganisationerne. Det er vigtigt at forstå, at der kan blive tale om et kompromis, hvor mere uafhængighed resulterer i mere isolation og mindre vidensoverførsel. Et lavere uafhængighedsniveau kan give forøget viden, men det kan også medføre mål, der er i konflikt med hinanden. Uafhængighedsniveauet bestemmes også af den softwareudviklingsmodel, der anvendes, f.eks. er testerne oftest en del af udviklingsgruppen ved agil udvikling. Alle de ovenfor nævnte muligheder kan blandes i en organisation. Der foretages måske test i udviklingsorganisationen såvel som af en uafhængig testorganisation, og der foretages måske en endelig certificering af en ekstern organisation. Det er vigtigt at forstå ansvarsfordelingen og forventningerne for hver testfase og at sætte disse krav, så kvaliteten af det færdige produkt maksimeres, samtidig med at arbejdet holdes inden for tidsplanen og budgetbegrænsningerne.





Outsourcing er en af de måder, hvorpå en ekstern organisation kan anvendes. Gruppen, der outsources til, kan være en anden virksomhed, der leverer testydelser, som kan foregå i virksomheden, eksternt i forhold til virksomheden, men i det pågældende land, eller i et andet land (nogle gange kaldet off-shore). Outsourcing giver udfordringer, specielt når den sker til et andet land. Nogle af de emner, der skal overvejes er følgende:

Kulturelle forskelle

Overvågning af outsourcingressourcerne

Overførsel af information, kommunikation

Beskyttelse af intellektuelle rettigheder

Evner, evneudvikling og træning

Medarbejderudskiftning

Præcis omkostningsestimering

Kvalitet.

10.5 Motivation En person, der arbejder med test, kan motiveres på mange måder. Disse omfatter bl.a.:

Anerkendelse af det udførte arbejde

Ros fra ledelsen

Respekt i projektgruppen og blandt ligemænd

Tilstrækkelig honorering for det foretagne arbejde (herunder aflønning, forøgelse af værdi og bonusser). Der er projektpåvirkninger, der kan gøre det vanskeligt at anvende disse motiveringsværktøjer. En tester kan f.eks. arbejde hårdt på et projekt, der har en umulig deadline. Testeren kan gøre alt, hvad der er i hans/hendes magt for at understøtte gruppens fokusering på kvalitet, arbejde ekstra timer og yde en ekstra arbejdsindsats, og alligevel kan produktet blive leveret, før det burde, på grund af eksterne påvirkninger. Resultatet kan være et produkt med en dårlig kvalitet på trods af, at testeren har ydet sit bedste. Dette kan let være demotiverende, hvis testerens bidrag ikke forstås og måles uanset om slutproduktet er en succes eller ej. Testgruppen skal sikre, at den registrerer de rigtige metrikker for at vise, at der blev gjort et godt stykke arbejde med at fuldføre testen, mildne risici og registrere resultaterne nøjagtigt. Hvis ikke disse data indsamles og vises, er det let for en gruppe at blive demotiveret, når den ikke modtage den anerkendelse, den føler er berettiget for et veludført arbejde. Anerkendelse bestemmes ikke kun af de uhåndgribelige begreber respekt og godkendelse, det er også synligt i forfremmelsesmuligheder, løntrin og karrieremuligheder. Hvis testgruppen ikke bliver respekteret, er disse muligheder måske ikke til stede. Anerkendelse og respekt opnås, når det er klart, at testeren bidrager til projektets stigende værdi. I et individuelt projekt opnås dette hurtigst ved at involvere testeren helt fra begyndelsen af projektet og opretholde denne involvering igennem livscyklussen. Som tiden går, vil testerne vinde anerkendelse og respekt for deres bidrag til den positive udvikling af projektet, men dette bidrag bør også kvantificeres som omkostningerne ved kvalitetsreduktioner og risikoreduktion.

10.6 Kommunikation Testgruppe-kommunikation sker primært på tre niveauer:

Dokumentation af testprodukter: teststrategi, testplan, testcases, testopsummeringsrapporter, hændelsesrapporter etc.

Feedback på reviewede dokumenter: krav, funktionelle specifikationer, use cases, komponenttestdokumentation etc.

Informationsindsamling og -spredning: samspil med udviklere, andre testgruppemedlemmer, ledelsen etc.

Al kommunikation skal være professionel, objektiv og effektiv for at kunne opbygge og vedligeholde respekten for testgruppen. Der kræves diplomati og objektivitet i forbindelse med feedback, specielt konstruktiv feedback, på andres arbejdsprodukter.





Al kommunikation skal fokusere på, at testmålene opnås, og på forbedring af kvaliteten både i produkterne og i de processer, der bruges til at producere softwaresystemerne. Testere kommunikerer med et bredt publikum, herunder brugere, projektgruppemedlemmer, ledelse, eksterne testgrupper og kunder. Kommunikationen skal være effektiv i forhold til målgruppen. F.eks. kan en rapport over defekttendenser, der er udarbejdet til udviklingsgruppen, være for detaljeret til at være passende til en ledelsesorientering.





11. Referencer

11.1 Standarder Dette afsnit indeholder en liste over de standarder, der er nævnt i denne syllabus.

11.1.1 Pr. kapitel De følgende kapitler refererer til disse 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 Alfabetisk De følgende standarder er nævnt i disse respektive kapitler [BS-7925-2] BS 7925-2 (1998) Software Component Testing Kapitel 2 og 4 [IEEE 829] IEEE Std 829™ (1998/2005) IEEE Standard for Software Test Documentation (i øjeblikket under revision) Kapitel 2 og 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 og 3





11.2 Bøger [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 Publishing, 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 Andre referencer De følgende referencer fører hen til oplysninger, der er tilgængelige på internettet. Selv om disse referencer blev kontrolleret, da denne Advanced Level Syllabus blev udgivet, kan ISTQB ikke gøres ansvarlig, hvis referencerne ikke er tilgængelige mere.

Kapitel 5 – www.testingstandards.co.uk

Kapitel 6 – Fejltaksonomi: www.testingeducation.org/a/bsct2.pdf – Eksempel på fejltaksonomi baseret på Boris Beizer’s arbejde: inet.uni2.dk/~vinter/bugtaxst.doc – God oversigt over forskellige taksonomier: testingeducation.org/a/bugtax.pdf – Heuristisk risikobaseret test af James Bach, interview på What IsTesting.com. www.whatistesting.com/interviews/jbach.htm – www.satisfice.com/articles/et-article.pdf – Fra "Exploratory & Risk-Based Testing (2004) www.testingeducation.org" – Udforskning af udforskende test, Cem Kaner and Andy Tikam , 2003 – Pettichord, Bret, "An Exploratory Testing Workshop Report", www.testingcraft.com/exploratorypettichord

Kapitel 9 – www.sei.cmu.edu/cmmi/adoption/pdf/cmmi-overview06.pdf – TMMi www.tmmifoundation.org/





12. Appendiks A – Baggrund for syllabussen

Målene med kvalifikationen Advanced Certificate At opnå anerkendelse af test som en væsentlig og professionel specialisering inden for softwarearbejdet.

At levere en standardramme for udviklingen af testeres karrierer.

At sætte professionelle uddannede testere i stand til at blive anerkendt af ansatte, kunder og kollegaer og at give testere en bedre profil.

At fremme konsistente og gode testfremgangsmåder inden for alle discipliner af softwarearbejdet.

At identificere testemner, der er relevante og af værdi for branchen.

At sætte softwareleverandører i stand til at ansætte certificerede testere og derved opnå en konkurrencemæssig fordel i forhold til konkurrenterne gennem offentliggørelse af deres politik for ansættelse af testere.

At give testere og dem, der har interesse i test, en mulighed for at opnå en international anerkendt kvalifikation inden for dette område.

Startkravene til denne kvalifikation Der er følgende startkriterier for at kunne tage softwaretesteksamenen til ISTQB Advanced Certificate:

Du skal have et Foundation Level-certifikat, der er udstedet af et eksamenspanel eller et medlemspanel, der er anerkendt af ISTQB.

Du skal have et passende antal års erfaring med softwaretest eller -udvikling, som det er bestemt af det eksamenspanel eller medlemspanel, der tildeler Advanced-certificeringen

Du skal tilslutte dig den etiske kodeks i denne syllabus. Det anbefales også, at kandidaterne gennemgår et kursus, der er blevet akkrediteret af et ISTQB-medlemspanel. Men der kræves ingen speciel uddannelse for at gå op til en ISTQB-eksamen. Et eksisterende Practitioner-certifikat eller et Advanced Certificate in Software Testing (fra et medlems- eller eksamenspanel, der er godkendt af ISTQB), der er udstedt, før dette International Certificate blev frigivet, anses for at svare til et International Certificate. Et Advanced Certificate udløber ikke, og det behøver ikke at blive fornyet. Udstedelsesdatoen fremgår af certifikatet. Inden for hvert deltagende land kontrolleres de lokale forhold af et medlemspanel, der er godkendt af ISTQB. Medlemspanelernes pligter er angivet af ISTQB, men er implementeret i hvert land. Medlemspanelernes pligter omfatter akkreditering af kursusudbydere og arrangering af eksamener, direkte eller indirekte, gennem et eller flere eksamenspaneler, der er kontrakt med.





13. Appendiks B – Bemærkninger til læserne

13.1 Eksamenspaneler Denne Advanced Level Syllabus kræver kendskab til indholdet af "Certified Tester Foundation Level Syllabus of the ISTQB", version 2005, med det kendskabsniveau, der er angivet i Foundation Level Syllabus. Eksaminationsenheder, der er godkendt af ISTQB, kan generere spørgsmål på basis af alle emner, der er nævnt i syllabussen. Det anbefales, at de spørgsmål, der er genereret, tildeles forskellige værdier i forhold til undervisningsmålene for de respektive emner. Som et eksempel: Et spørgsmål, der hører til et K1-kendskabsniveau, tildeles muligvis færre point end et spørgsmål, der hører til et K3-kendskabsniveau, mens et spørgsmål på et K4-kendskabsniveau får tildelt endnu flere point.

13.2 Kandidater og kursusudbydere For at kunne opnå Advanced level-certificering skal kandidaterne have certificering på grundlæggende niveau, og de skal kunne dokumentere over for det eksamenspanel, der eksaminerer dem, at de har tilstrækkelig praktisk erfaring til at være kvalificerede til Advanced level. Kontakt det relevante eksamenspanel for at få oplysninger om deres specifikke kriterier for praktisk erfaring. ISTQB foreslår, at man mindst skal have 5 års praktisk erfaring med softwareudvikling som forudsætning for certificering på Advanced level eller 3 års praktisk erfaring, hvis kandidaten har en bachelorgrad inden for naturvidenskab, økonomi eller teknik. Der kræves mere end blot kendskab til indholdet af denne syllabus for at opnå det færdighedsniveau, der kræves for at arbejde på Advanced Level inden for softwaretest. Kandidaterne og kursusudbyderne tilskyndes til at bruge mere tid til læsning og undersøgelser, er der er angivet i denne syllabus. Denne syllabus indeholder en oversigt over referencer, bøger og standarder, som kandidaterne og kursusudbyderne kan læse, hvis de ønsker at få en mere detaljeret indsigt i de angivne emner.





14. Appendiks C – Bemærkninger til kursusudbydere

14.1 Modularitet Denne syllabus omfatter indhold til tre moduler, der hedder henholdsvis:

Advanced level-testansvarlig

Advanced level-testanalytiker

Advanced level-teknisk testanalytiker Hvis kandidaten består alle moduler, giver det ret til opnå certificeringen "Full Advanced Level Testing Professional".

14.2 Uddannelsestider

14.2.1 Uddannelse pr. modul Der er følgende anbefalede uddannelsestider for hver af de tre forskellige roller:

Advanced level-testansvarlig 5 dage

Advanced level-testanalytiker 5 dage

Advanced level-teknisk testanalytiker 5 dage Varigheden er baseret på antallet af kapitler pr. modul og de specifikke undervisningsmål for hvert kapitel. Den specifikke minimumsvarighed er angivet for hvert kapitel, for hver rolle. Kursusudbydere bruger muligvis mere tid, end der er angivet, og kandidaterne kan igen bruge mere tid på at læse og undersøge. Et kursusforløb behøver ikke at følge den samme rækkefølge som syllabussen. Kurserne behøver ikke at bestå af sammenhængende dage. Kursusudbydere kan vælge at organisere deres kursus på en anden måde, f.eks. 3+2 dage til teststyring, eller 2 fælles dage fulgt af 3 dage til hvert af områderne testanalytikere og tekniske testanalytikere.

14.2.2 Sammenfald Kursusudbydere kan vælge kun at undervise én gang i fælles emner, så de reducerer totaltiden og undgår gentagelser. Kursusudbyderne skal også være opmærksomme på, at det samme emne nogle gange skal ses fra forskellige vinkler afhængigt af modulet.

14.2.3 Kilder Syllabussen indeholder referencer til etablerede standarder, der skal bruges ved udarbejdelsen af undervisningsmaterialet. Når der anvendes en standard, skal det være den version, der er anført i den aktuelle udgave af denne syllabus. Andre publikationer, skabeloner eller standarder, der ikke er angivet i denne syllabus, kan også bruges, og der kan henvises til dem, men der vil ikke blive eksamineret i dem.

14.3 Praktiske øvelser Der skal inddrages praktisk arbejde (korte øvelser) på alle de punkter, hvor det forventes, at kandidaterne anvender deres viden (Undervisningsmål på K3 eller højere). Forelæsningerne og øvelserne skal være baseret på undervisningsmålene og beskrivelsen af emnerne i indholdet af denne syllabus.





15. Appendiks D – Anbefalinger Da disse anbefalinger gælder for forskellige kapitler i denne syllabus, er de blevet samlet og anbragt i ét appendiks. Der kan eksamineres i de emner, der er anført nedenfor. Denne liste indeholder et antal nyttige anbefalinger til, hvordan man imødegår udfordringerne ved test, og den bygger på den liste med syv basale testprincipper, der blev introduceret på Foundation Level. Listen i dette appendiks er ikke udtømmende, men den giver i stedet et eksempel på "erfaringer", der skal tages med i overvejelserne. Undervisere skal vælge de punkter på listen, som er mest relevante for det modul, der undervises i.

15.1 Anbefalinger til automatisering I forbindelse med implementeringen af automatiserede test står man over for et antal udfordringer. Avancerede testere skal være i stand til at fokusere på de forskellige anbefalinger, der er beskrevet i denne syllabus, i forhold til den kontekst, der gælder for deres organisation, teams, opgaver og softwarekomponenter. De følgende liste anfører nogle områder, der har vist sig at have negativ indflydelse på testarbejdets performance. Bemærk, at det ikke er meningen, at denne liste skal være udtømmende.

Generer testplaner, der er orienteret mod funktionel test Fejl er ikke begrænset til funktionelle aspekter eller til kun en enkelt bruger. Interaktionen mellem flere brugere kan have indflydelse på softwaren, der testes.

Ikke tilstrækkelig konfigurationstest Hvis flere typer processorer, operativsystemer, virtuelle maskiner, browsere og eksterne enheder kan kombineres til mange mulige konfigurationer, så kan en test, der er begrænset til kun nogle få af disse konfigurationer, efterlade et stort antal uopdagede potentielle fejl.

Udskydelse af stress- og belastningstest til sidste øjeblik Resultaterne af stress- og belastningstest kræver muligvis større ændringer af softwaren (op til og inklusive basisarkitekturen). Da det kan kræve betydelige ressourcer at implementere, kan det være meget negativt for projektet, hvis disse test udføres lige før den planlagte produktionsstart.

Ingen test af dokumentationen Brugerne får leveret softwaren og dokumentationen. Hvis dokumentationen ikke stemme overens med softwaren, vil brugeren ikke være i stand til at udnytte det fulde potentiale i softwaren, eller brugeren kasserer måske helt softwaren.

Ingen test af installationsprocedurer Installationsprocedurer, samt backup- og gendannelsesprocedurer, foretages et meget begrænset antal gange. Men disse procedurer er imidlertid mere kritiske end softwaren. Hvis softwaren ikke kan installeres, vil den overhovedet ikke blive brugt.

Der insisteres på, at én testopgave skal være fuldstændig afsluttet, før den næste startes Selv om nogle livscyklusmodeller for softwareudvikling foreslår en sekventiel afvikling af opgaver, så er det i praksis ofte nødvendigt at udføre mange opgaver (i det mindst delvist) sideløbende.

Risikoområder identificeres ikke korrekt Nogle områder kan identificeres som risikofyldte, og de skal derfor muligvis testes grundigere. Men områder, hvor der kun er foretaget minimal eller ingen test, kan i sidste ende vise sig at udgøre en større risiko, end det oprindeligt blev vurderet.

Testinput og -procedurer angives for specifikt Hvis testerne ikke har tilstrækkeligt råderum til deres egne initiativer med hensyn til definition af testinput og -procedurer, så føler de sig måske ikke tilskyndet til at undersøge områder, der kan se lovende ud (med hensyn til mulig skjulte fejl)

Der lægges ikke mærke til "irrelevante" særheder, og de undersøges ikke Observationer eller resultater, der kan synes irrelevante, er ofte indikatorer for fejl, der (som isbjerge) gemmer sig under overfladen

Kontrol af at produktet gør, hvad det forventes at gøre, men at det ikke gør, hvad det ikke forventes at gøre





Hvis man begrænser sig til kun at undersøge, hvad produktet forventes at gøre, så er det muligt at overse forhold ved softwaren, som den ikke forventes at gøre (f.eks. yderligere, uønskede funktioner)

Sekvenser af testcases, der kun forstås af deres ejere Testerne kan flytte til andre ansvarsområder. Andre testere skal derefter kunne læse og forstå de test, der tidligere er specificeret. Hvis man ikke kan fremstille læsbare og forståelige testspecifikationer, kan det have en negativ indflydelse, fordi testmålene muligvis ikke kan forstås, eller fordi testen er blevet fjernet helt.

Der testes kun gennem den grænseflade, som brugeren ser Grænsefladerne til softwaren er ikke begrænset til brugergrænsefladen. Kommunikation mellem processer, batchkørsel og andre afbrydelser kan også interagere med softwaren og kan generere fejl.

Dårlig bugrapportering og konfigurationsstyring Hændelsesrapportering og -styring samt konfigurationsstyring er meget vigtige for at sikre succesen for det totale projekt (der omfatter udvikling og test). En succesfuld tester kan være den, der får fejl rettet, frem for den, der finder mange fejl, men ikke rapporterer dem godt nok til, at de kan blive rettet.

Der tilføjes kun regressionstest Udviklingen af sekvenser af testcases er ikke begrænset til kontrol af, at der ingen regressionsfejl opstår. Programkoden udvikler sig over tid, og der skal implementeres yderligere test til at dække disse nye funktioner, samt for at kontrollere for regressioner i andre områder af softwaren.

Der bliver ikke taget noter til det næste testarbejde Testopgaverne slutter ikke, når softwaren er leveret til brugeren eller distribueret til markedet. Der vil højst sandsynligt blive produceret en ny version eller udgave af softwaren, så den opsamlede viden skal gemmes og overføres til de testere, der er ansvarlige for det næste testarbejde.

Der gøres forsøg op at automatisere alle test Automation kan være en god ide, men automation er et udviklingsprojekt i sig selv. Ikke alle test kan automatiseres: Det er hurtigere at udføre nogle test manuelt, end at automatisere dem.

Det forventes, at alle manuelle test køres igen Når manuelle test køres igen, er det ofte urealistisk at forvente, at alle test køres igen. Testernes opmærksomhed ændrer sig, og de har en tendens til at fokusere på bestemte områder i softwaren, bevidst eller ej.

Der bruges GUI-automationsværktøjer til at reducere omkostningerne ved testoprettelse Et værktøj til GUI-indsamling/-afspilning er en vigtig startinvestering, og det skal kun bruges til at understøtte en defineret strategi, hvor alle tilknyttede omkostninger er kendte og evaluerede.

Der forventes, at regressionstest finder en høj andel af nye fejl Generelt findes der ikke en stor del af fejlene i forbindelse med regresssionstest, for det meste fordi der er tale om test, der allerede er kørt (f.eks. ved en tidligere version af samme software), og fejlene skulle være registreret i forbindelse med disse tidligere kørsler. Det betyder ikke, at regressionstest helt skal fjernes, men kun, at effektiviteten (kapacitet, der bruges til at registrere nye fejl) ved regressionstest er lavere end ved andre test.

Dækningen af programkoden sker ud fra den overbevisning, at kun simple tal kan inspirere Kodedækning og metrikker er måske meget interessante fra et ledelsessynspunkt, baseret på de leverede tal og grafer, men tallene afspejler ikke effektiviteten eller relevansen af en test. Eksempel: 100 % er et rart tal for kodedækning, men er det et realistisk tal, og er det et tilstrækkeligt tal (dvs. angiver det dækningen af instruktioner, betingelser eller MCDC)?

Test fjernes fra en sekvens af regressionstest, kun fordi de ikke forøger dækningen I en sekvens af regressionstest skal (bør) nogle test muligvis fjernes, og andre skal tilføjes. Fjernelsen skal ikke kun være baseret på, om testen giver øget dækning, da relevansen af en testcase (den type fejl, den kontrollerer for) muligvis ikke har nogen indflydelse på dækningen. Eksempel: Dækning af programkoden er ikke den eneste type dækning. Der kan være oprettet test af andre årsager (f.eks. specifikke værdier eller hændelsessekvenser) end den rene dækning.

Dækning som et performancemål for testere Dækning er et mål for omfanget og ikke et mål for medarbejdernes performance eller effektivitet. Der kan være defineret andre metrikker for evalueringen af testernes effektivitet i forhold til deres organisation og projekt. Brugen af sådanne metrikker skal tænkes meget omhyggeligt igennem for at undgå uønskede effekter ("funktionsforstyrrelser").

Måling af dækning undlades helt Der findes forskellige typer af dækning (f.eks. kodeinstruktioner, betingelser, moduler, funktioner etc.), og arbejdsbyrden ved at nå frem til en tilfredsstillende metrik kan være betydelig. Det er imidlertid ikke en grund til helt at undlade dækningsmetrikker, da de kan være nyttige for testopgaven.





Mange af disse punkter behandles inden for indholdet af specifikke afsnit i denne syllabus. I forbindelse med introduktionen af testforanstaltninger og -rutiner i organisationen, kan det være nyttig at overveje ikke kun de punkter, der er anført ovenfor, men også at støtte sig til yderligere informationskilder, f.eks.:

ISTQB-syllabusserne (Foundation og Advanced)

Bøgerne, der er medtaget i referencelisten i denne syllabus

Referencemodeller som dem, der er behandlet i afsnit 8.3.





16. Indeks

Certificeret tester Syllabus Advanced level Version 2007 ...

Documents

Transcript of Certificeret tester Syllabus Advanced level Version 2007 ...