Sertifisert Tester. Pensum for grunn-nivå. ("Foundation Level")

Transkript

1 Sertifisert Tester Pensum fr grunn-nivå ("Fundatin Level") Engelsk Versjn Nrsk Versjn 2011.N Nrwegian Testing Bard Internatinal Sftware Testing Qualificatins Bard

2 Cpyright 2012 frfatterne av den nrske versettelsen (Hans Schaefer, Skule Jhansen, Jürgen Richter, Thmas Brchsenius, Ragnhild Egtvedt, Berit Kristine Hatten, Kjersti Frthun, Ernst vn Düring). Cpyright 2008 frfatterne av den nrske versettelsen (Hans Schaefer, Mnika Stöcklein- Olsen, Skule Jhansen, Kjersti Frthun, Lillann Slberg, Jürgen Richter). Cpyright 2010 frfatterne fr ppdateringen 2010 (Thmas Müller (frmann)) Cpyright 2007 frfatterne fr ppdateringen 2007 (Thmas Müller (frmann), Drthy Graham, Debra Friedenberg g Erik van Veendendal) Cpyright 2005 frfatterne (Thmas Müller (frmann), Rex Black, Sigrid Eldh, Drthy Graham, Klaus Olsen, Maaret Pyhäjärvi, Geff Thmpsn g Erik van Veendendal) Alle rettigheter frbehldt. Frfatterne verfører sin cpyright til Internatinal Sftware Testing Qualificatins Bard (ISTQB). Frfatterne (sm nå har cpyright) g ISTQB (sm i framtiden har cpyright) er enige m følgende betingelser fr bruk av dette dkument: 1) Enhver persn eller pplæringsfirma kan bruke dette pensum sm grunnlag fr kurs, hvis frfatterne g ISTQB blir anerkjent sm kilde g eiere av cpyright av dette pensum (syllabus) g under frutsetning av at hver annnsering eller markedsføring av et slikt kurs kan nevne dette pensum bare etter at kursmaterialet er levert til ffisiell akkreditering til et av ISTQB anerkjent nasjnalt Bard. 2) Enhver persn eller gruppe av persner kan bruke dette pensum sm basis fr artikler, bøker eller annen type skrevet materiale hvis frfatterne g ISTQB blir anerkjent g nevnt sm kilde g eiere av cpyright av dette dkument. 3) Alle ISTQB-anerkjente nasjnale Bard kan versette dette pensum g gi lisens på dette materiale (eller dets versettelse) videre til andre grupper.

3 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Revisjnshistrie Versjn Dat Bemerkninger 2011.N Henvisning til nye internasjnale standarder lagt inn (ikke relevant fr eksamen) 2011.N Bedre frklaring på test i drift i Kap 1.2, lagt i sprbarhet (manglet) under test implementering g strøket begrepet spesifikasjnsbasert testing (i samsvar med engelsk versjn) 2011.N Endring av rd sm kan misfrstås, innhldsmessig ingen endring N Vedlikehldsrelease mindre endringer, se appendix E release ntes 2010.N Full gjennmgang av HS mt ffisiell 2010-versjn på engelsk. Publisert av NTB. Nrwegian Testing 03-Sept-2008 Første nrske versjn Bard 2008 ISTQB engelsk 01-May-2007 Certified Tester Fundatin Level Syllabus Maintenance Release Earlier English versins mentined in that dcument. Versin 2011 Page 3 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

4 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard InnhldsfrtegnelseInnledning Frmål med dette dkument Sertifisert tester på grunnivå (Fundatin Level) i prgramvaretesting Læremål / kunnskapsnivå Eksamen Akkreditering Detaljnivå Hvrdan dette pensum er rganisert Frklaring av spesiell terminlgibruk på nrsk Grunnlag fr testingen (K2) Hvrfr er test nødvendig (K2) Prgramvaresystemer i en større sammenheng (K1) Grunner til prgramvarefeil (K2) Testingens rlle ved prgramvareutvikling, vedlikehld g drift (K2) Testing g kvalitet (K2) Hvr mye testing er nk? (K2) Hva er testing? (K2) Syv testprinsipper (K2) Den grunnleggende testprsessen (K1) Testplanlegging g -styring (K1) Testanalyse g -design (K1) Testimplementering g -utførelse (K1) Evaluering av sluttkriterier g rapprtering (K1) Avslutningsaktiviteter (K1) Testingens psyklgi (K2) Etikk fr testeren (K2) Testing gjennm livssyklusen (K2) Utviklingsmdeller fr prgramvare(k2) V-mdellen (sekvensiell utviklingsmdell) (K2) Iterativ-inkrementell utviklingsmdeller (K2) Testing i en livssyklusmdell (K2) Testnivåer (K2) Kmpnenttesting (K2) Integrasjnstesting (K2) Systemtesting (K2) Akseptansetesting (K2) Testtyper (K2) Testing av funksjnalitet (funksjnell testing) (K2) Testing av ikke-funksjnelle egenskaper av prgramvaren (ikke-funksjnell testing) (K2) Testing av prgramvarens struktur/arkitektur (strukturell testing, hvit bks testing) (K2) Testing relatert til endringer (re-testing g regresjnstesting) (K2) Testing i vedlikehld (K2) Statiske teknikker (K2) Statiske teknikker g testprsessen (K2) Granskningsprsessen (K2) Faser i en frmell granskning (K1) Rller g ansvar (K1) Granskningstyper (K2) Suksessfaktrer fr granskninger (K2) Statisk analyse med verktøy (K2) Teknikker fr testdesign (K3) Testutviklingsprsessen (K3) Kategrier fr teknikker fr testdesign (K2) Spesifikasjnsbaserte (svart bks) teknikker (K3) Ekvivalensklasseinndeling (K3) Versin 2011 Page 4 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

5 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Grenseverdianalyse (K3) Beslutningstabelltesting (K3) Tilstandsbasert testing (K3) Brukstilfelle (use case) testing (K2) Strukturbaserte (hvit bks) teknikker (K4) Prgraminstruksjnstesting g dekning (statement testing and cverage) (K3) Frgrenings- / Beslutningstesting g dekning (branch r decisin testing and cverage) (K3) Andre strukturbaserte teknikker (K1) Erfaringsbaserte teknikker (K2) Valg av testteknikker (K2) Testledelse (K3) Testrganisasjn (K2) Testrganisasjn g uavhengighet (K2) Testerens g testlederens ppgaver (K1) Test planlegging g estimering (K3) Testplanlegging (K2) Testplanleggingsaktiviteter (K2) Startkriterier (K2) Sluttkriterier (K2) Testestimering (K2) Teststrategier g testmetder (K2) Overvåking g kntrll av testframdriften (K2) Oppfølging av testframdrift (K1) Testrapprtering (K2) Teststyring (K2) Knfigurasjnsstyring (K2) Risik g testing (K2) Prsjektrisiker (K2) Prduktrisiker (K2) Hendelses- g feilhåndtering (K3) Verktøystøtte til test (K2) Typer testverktøy (K2) Frstå mål g mening med verktøystøtte fr testing (K2) Klassifisering av testverktøy (K2) Verktøystøtte fr administrasjn av testing g tester (K1) Verktøystøtte fr statisk testing (K1) Verktøystøtte fr testspesifikasjn (K1) Verktøystøtte fr testutføring g lgging (K1) Verktøystøtte til ytelse g vervåkning (K1) Verktøystøtte fr spesifikke testbehv (K1) Effektiv bruk av verktøy: mulige frdeler g risiker (K2) Mulige frdeler g risiker ved verktøystøtte til testing (fr alle verktøy) (K2) Spesielle hensyn fr nen typer verktøy (K1) Intrduksjn av et verktøy i en rganisasjn (K1) Referanser Standarder Bøker Vedlegg A Bakgrunn til pensum Histrien til dette dkumentet Mål med kvalifikasjnen med Fundatin Certificate Mål med den internasjnale kvalifikasjnen (tatt fra ISTQB møte på Sllentuna, nvember 2001) Startkrav fr denne kvalifikasjnen Bakgrunn g histrie fr grunnsertifikatet (Fundatin Certificate in Sftware Testing) Versin 2011 Page 5 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

6 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 9 Vedlegg B Læremål / kunnskapsnivå Nivå 1: Husk (K1) Nivå 2: Frstå (K2) Nivå 3: Bruke (K3) Nivå 4: Analysere (K4) Vedlegg C Regler sm er brukt av ISTQB Grunnivå-pensum (Fundatin syllabus) Generelle regler Aktuelt innhld Læremål Ttalstruktur Vedlegg D Infrmasjn til kurshldere Vedlegg E Release Ntes Syllabus 2007 engelsk versjn Indeks... Feil! Bkmerke er ikke definert. Versin 2011 Page 6 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

7 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Takk Internatinal Sftware Testing Qualificatins Bard Wrking Grup Fundatin Level (Versjn 2011): Thmas Müller (chair), Debra Friedenberg. Takk til review teamet (Dan Almg, Armin Beer, Rex Black, Julie Gardiner, Judy McKay, Tuula Pääkkönen, Eric Riu du Csquier Hans Schaefer, Stephanie Ulrich, Erik van Veenendaal) g alle nasjnale Bards fr deres frslag til den nåverende versjnen av pensum Internatinal Sftware Testing Qualificatins Bard - arbeidsgruppe Fundatin Level (utgave 2010): Thmas Müller (frmann) Internatinal Sftware Testing Qualificatins Bard - arbeidsgruppe Fundatin Level (utgave 2007): Thmas Müller (frmann), Drthy Graham, Debra Friedenberg g Erik van Veendendal. Frfatterne takker de sm har gjennmgått den engelske riginalteksten (Hans Schaefer, Stephanie Ulrich, Meile Psthuma, Anders Petterssn g Wnil Kwn) g alle nasjnale Bards fr deres frslag til den nåværende versjnen av pensum. Internatinal Sftware Testing Qualificatins Bard - arbeidsgruppe Fundatin Level (utgave 2005): Thmas Müller (frmann), Rex Black, Sigrid Eldh, Drthy Graham, Klaus Olsen, Maaret Pyhäjärvi, Geff Thmpsn g Erik van Veendendal. Frfatterne takker de sm har gjennmgått teksten g alle nasjnale Bards fr deres frslag til det aktuelle pensum. Oversettelsen er utført av medlemmer i Nrwegian Testing Bard. I tillegg har Le Eliassen levert verdifulle kmmentarer. Disse er spesialister i sftwaretesting, men ikke prfesjnelle versettere. Oversettelsen er gjrt på dugnad. Oversettelsen hlder seg tett til den engelske riginalen, frdi denne blir brukt i den internasjnale sertifiseringen, g vi vil sikre at versettelsen dekker alle aspekter g nyanser ved riginalen. Vi er klar ver at språket derfr delvis virker ne tungt. Vi er takknemlige fr all tilbakemelding. Vi skal gså besvare spørsmål du måtte ha innen rimelig tid. Kmmentarer til Hans Schaefer (hans.schaefer@ieee.rg). Versin 2011 Page 7 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

8 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Innledning 1.1 Frmål med dette dkument Dette pensum er grunnlaget fr Internatinal Sftware Testing Qualificatin på grunnivå (Fundatin Level). Internatinal Sftware Testing Qualificatins Bard (ISTQB) gir det til de nasjnale Bards fr å akkreditere kurshldere g fr å lage eksamensspørsmål på deres nasjnale språk. Kurshlderne lager kursmateriale g bestemmer passende læringsmetder fr akkreditering, g dette pensum vil hjelpe kandidater i deres frberedelse til eksamen. Infrmasjn m histrie g bakgrunn fr dette pensum finnes i vedlegg A. 1.2 Sertifisert tester på grunnivå (Fundatin Level) i prgramvaretesting Målgruppen fr sertifiseringen på grunnivå (Fundatin Level) er enhver sm er invlvert i test av prgramvare. Dette mfatter persner i rller sm testere, testutviklere, testingeniører, testknsulenter, testledere, brukere sm akseptansetestere g prgramvareutviklere. Grunnivåsertifiseringen er gså passende fr den sm vil ha en grunnleggende frståelse av test av prgramvare, sm fr eksempel prsjektledere, kvalitetsledere, utviklingsledere fr prgramvare, frretningsanalytikere, IT-direktører g ledelsesknsulenter. De sm innehar dette sertifikat kan så gå videre til en kvalifikasjn på test av prgramvare på et høyere nivå. 1.3 Læremål / kunnskapsnivå Kunnskapsnivå blir gitt fr hvert avsnitt i dette dkument g klassifiseres sm følgende;: K1: huske K2: frstå K3: anvende K4: analysere Mer detaljer g eksempler av læremål er gitt i vedlegg B. Alle uttrykk under verskriften Begreper rett under hver kapittelverskrift skal huskes (K1), selv m de ikke blir uttrykkelig nevnt i læremålene. De er frklart i ISTQB Glssary. 1.4 Eksamen Eksamen på grunnivå vil bli basert på dette pensum. Svar til eksamensspørsmål kan kreve bruk av materiale fra mer enn ett avsnitt i dette pensum. Alle deler av pensum kan brukes til eksamen. Eksamensfrmat er flervalg (multiple chice). Eksamen kan tas sm del av et akkreditert kurs eller uavhengig av kurs etter avtale med Nrwegian Testing Bard. Det stilles ikke krav til gjennmført akkreditert kurs fr å stille til eksamen. 1.5 Akkreditering Kurshldere g deres kursmateriale sm følger dette pensum, kan akkrediteres av et nasjnalt Bard anerkjent av ISTQB. Retningslinjer fr akkreditering bør hentes fra det nasjnale Bard eller det Bard sm fretar akkreditering. Et akkreditert kurs sm er anerkjent i samsvar med dette pensum g sm hldes av akkreditert instruktør, har tillatelse til å få arrangert en ISTQB-eksamen sm del av kurset. Videre veiledning til kurshldere er gitt i vedlegg D. Versin 2011 Page 8 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

9 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 1.6 Detaljnivå Detaljnivået i dette pensum tillater internasjnalt sammenlignbar læring g prøver. Fr å få dette til, består det av: Generelle læremål sm beskriver frmålet med grunnivået (Fundatin Level). En liste med infrmasjn sm skal læres brt, inklusive en beskrivelse g referanser til ekstra kilder hvis nødvendig. Læremål fr hvert kunnskapsmråde, sm beskriver hva flk skal kunne g frstå. En liste med begreper sm kandidatene må kunne gjenta g ha frstått. En beskrivelse av nøkkelknsepter sm skal læres, inklusive kilder sm alminnelig akseptert litteratur g standarder. Pensums innhld er ikke en beskrivelse av hele kunnskapsmrådet til testing av prgramvare. Det beskriver bare detaljnivået sm skal dekkes i grunnleggende kurs. 1.7 Hvrdan dette pensum er rganisert Det er seks hvedkapitler. Hvedverskriften viser høyeste nivå av læremålene sm er dekket i kapitlet g spesifiserer kurstiden fr kapitlet. Fr eksempel: 2. Testing gjennm livssyklusen (K2) 115 minutter Denne verskriften viser at kapittel 2 har læremål på nivå K1 (implisert når et høyere nivå er vist) g K2 (men ikke K3), g burde ta 115 minutter fr å lære brt materiellet i kapitlet. Innenfr hvert kapittel er et antall avsnitt. Hvert avsnitt har gså læremål g en tidsmengde sm er påkrevd. Underavsnitt har ikke ne tid allkert g er innbefattet i tiden fr avsnittet. 1.8 Frklaring av spesiell terminlgibruk på nrsk I en del situasjner er det vanskelig å finne treffende begreper på nrsk, eller det er brukt alternative frmuleringer. I dette avsnitt er slike språklige prblemer frklart Test vs. Testing: De t rdene er brukt med samme betydning i pensum. Feil: På engelsk finnes begrepene errr, mistake, fault, defect, prblem, failure. På nrsk bruker vi samme rd fr alle disse begrepene, nemlig feil. Fr å kunne skille mellm årsaken til en feil, selve feilen g de følgene en feil har når den blir utført, brukes de engelske uttrykk i den nrske eksamen. White bx testing: Her har vi valgt å bruke de engelske begrepene på ulike testmetder g dekningsgrader sammen med de nrske. Review g granskning: Begge rd er bruk i samme betydning. Versin 2011 Page 9 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

10 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 1 Grunnlag fr testingen (K2) 155 minutter Læremål Målene identifiserer hva du skal kunne etter fullførelsen av hver mdul. 1.1 Hvrfr er test nødvendig (K2) LO Beskriv med eksempler hvrdan en feil kan skade en persn, miljøet eller en bedrift. (K2) LO Skill mellm årsaken til en feil g feilens følger. (K2) LO Begrunn hvrfr det er nødvendig å utføre test ved å gi eksempler. (K2) LO Beskriv hvrfr test er en del av kvalitetssikringen g gi eksempler på hvrdan test hjelper med å øke kvaliteten. (K2) LO Frklar g sammenlign begrepene feil (engelsk: errr, mistake, bug, defect, failure, fault). (K2) 1.2 Hva er testing (K2) LO Husk de vanlige frmål fr test. (K1) LO Gi eksempler fr målsetningen fr testing i ulike faser i livssyklusmdellen fr prgramvare. (K2) LO Skill mellm testing g debugging (K2) 1.3 Syv testprinsipper (K2) LO Frklar de syv prinsippene ved testing. (K2) 1.4 Den grunnleggende testprsessen (K1) LO Husk de fem grunnleggende testaktivitetene g tilhørende ppgaver fra planlegging til avslutning. (K1) 1.5 Testingens psyklgi (K2) LO Husk de psyklgiske faktrene sm har innflytelse på testsuksess. (K1) LO Still testerens g utviklerens hldninger pp mt hverandre. (K2) Versin 2011 Page 10 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

11 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 1.1 Hvrfr er test nødvendig (K2) 20 minutter Begreper Feil, systemfeil, feiltakelse, kvalitet, risik De engelske begrepene bug, defect, errr, failure, fault, mistake Prgramvaresystemer i en større sammenheng (K1) Prgramvaresystemer er en vanlig del av hverdagen, fra frretningsløsninger (f. eks. i bankbransjen) til frbrukerprdukter (f. eks. biler). Flk flest har pplevd at prgramvare ikke fungerer sm frventet. Prgramvare sm ikke fungerer krrekt kan føre til mange prblemer, inkludert tap av penger, tid eller frretningsmdømme, g kan til g med medføre menneskelig skade eller død Grunner til prgramvarefeil (K2) Et menneske kan gjøre en feil (mistake, errr), sm fører til en feil (defect, fault eller bug) i prgramkden, eller i et dkument. Hvis en feil i kden innføres, vil systemet ikke gjøre hva det skal (eller det kan gjøre ne det ikke burde), ne sm kan føre til feil (failure). Feil i prgramvare, systemer eller dkumenter kan føre til prblemer (failures), men ikke alle feil gjør dette. Feil inntreffer frdi mennesker generelt begår feil g på grunn av tidspress, kmpleks kde, sammensatt infrastruktur, teknlgiendringer, g/eller mye interaksjn mellm flere systemer. Systemfeil kan gså frårsakes av miljøfaktrer: Fr eksempel stråling, magnetisme, elektrniske felt g frurensning kan frårsake feil i firmware eller påvirke prgramvaren ved å frandre maskinvarefrhldene Testingens rlle ved prgramvareutvikling, vedlikehld g drift (K2) Grundig testing av systemer g tilhørende dkumentasjn kan redusere risiken fr at prblemer inntreffer i drift. Dette kan gså bidra til å høyne kvaliteten av et prgramvaresystem, men frutsetningen er at de feil sm er funnet blir rettet før systemet blir frigitt til drift. Prgramvaretesting er gså fte påkrevd ifølge kntrakter, eller andre juridiske krav, eller industrispesifikke standarder Testing g kvalitet (K2) Ved hjelp av testing er det mulig å måle prgramvarekvaliteten ved å referere til feil sm er funnet, fr både funksjnelle g ikke-funksjnelle prgramvarekrav g -egenskaper (f. eks. pålitelighet, brukervennlighet, effektivitet, vedlikehldbarhet g prtabilitet). Fr ytterligere infrmasjn m ikkefunksjnell testing, se kapittel 2; fr mer infrmasjn m prgramvareegenskaper, se Sftware Engineering Sftware Prduct Quality (ISO ) 1. Testing kan gi tillit til prgramvarekvaliteten hvis få eller ingen feil blir påvist. En velknstruert test sm systemet takler kan redusere risiken i et system. Hvis en test påviser feil, blir systemets kvalitet frbedret når disse feilene blir rettet. 1 Standarden ISO er tatt ut av bruk g erstattet av ISO/IEC 25010:2011, Systems and sftware engineering Systems and sftware Quality Requirements and Evaluatin (SQuaRE) System and sftware quality mdels. I eksamen er dg bare de egenskapene relevant sm er beskrevet i denne syllabus. Versin 2011 Page 11 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

12 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Erfaring bør pparbeides fra tidligere prsjekter. Ved å frstå årsaken til feil sm er funnet i andre prsjekter, kan prsesser frbedres, ne sm burde frhindre at slike feil frekmmer på nytt. På denne måten får man en frbedring av kvaliteten til fremtidige systemer. Dette er en del av kvalitetssikringen. Testing bør integreres sm en av kvalitetssikringsaktivitetene (dvs. ved siden av utviklingsstandarder, pplæring g feilanalyse) Hvr mye testing er nk? (K2) Beslutningsprsessen m hvr mye testing sm bør fretas bør ta hensyn til risiknivå, inkludert teknisk, sikkerhets- g frretningsrelatert risik, g prsjektbegrensinger slik sm tid g budsjett. (Risik er ytterligere behandlet i kapittel 5). Testing bør gi tilstrekkelig infrmasjn til invlverte parter slik at de kan freta infrmerte beslutninger m frigivelsen av prgramvaren sm testes, fr det neste utviklingstrinnet eller fr verlevering til kunder. Versin 2011 Page 12 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

13 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 1.2 Hva er testing? (K2) 30 minutter Begreper Debugging, krav, granskning (review), testtilfelle, testing, testmål. Bakgrunn En vanlig frståelse av testing er at det bare dreier seg m kjøring av tester, dvs. utføring av prgramvaren. Dette er en del av testingen, men det finnes flere testaktiviteter. Testaktiviteter eksisterer før g etter selve utførelsen av testen. Disse aktiviteter mfatter planlegging g styring, valg av testbetingelser, knstruksjn g utføring av testtilfelle, kntrll av resultater, evaluering av sluttkriterier, rapprtering m testprsessen g systemet under test, g ferdigstilling eller avslutning etter at en testfase er gjennmført. Testing mfatter gså granskning av dkumenter (inkludert kildekde) g å utføre statisk analyse. Både dynamisk g statisk testing kan benyttes fr å ppnå liknende frmål, g vil gi infrmasjn sm kan brukes til å frbedre både systemet sm testes g utviklings- g testprsessene. Det finnes frskjellige testfrmål: finne feil få tillit til kvalitetsnivået gi infrmasjn fr å skaffe seg et beslutningsgrunnlag frebygge feil. Tankeprsessen g aktivitetene sm utføres ved å knstruere tester tidlig i livssyklusen (verifikasjn av testgrunnlaget via testdesign) kan hjelpe til å frhindre at feil blir intrdusert i kden. Granskning av dkumenter (f.eks. krav) samt identifisering g løsning av prblemer hjelper gså til å frhindre feil i kden. Ulike perspektiv i testingen reflekterer ulike frmål. I utviklingstesting (f. eks. kmpnent-, integrasjns- g systemtester), kan hvedmålet være å frårsake så mange systemfeil sm mulig slik at feil i systemet kan identifiseres g rettes. I akseptansetesting er hvedfrmålet sm ftest å bekrefte at systemet fungerer sm frventet, g få tillit til at systemet har innfridd kravene. I nen tilfeller er hvedfrmålet ved testingen å vurdere prgramvarekvaliteten (uten hensikt å rette eventuelle feil), fr å gi infrmasjn til de invlverte parter angående eventuell risik sm er knyttet til frigivelse av systemet til en gitt tidspunkt. Vedlikehldstesting inkluderer fte testing av at ingen nye feil har blitt intrdusert mens endringer har blitt fretatt. Ved testing i prøvedrift kan hvedfrmålet være å evaluere driftstekniske funksjner g egenskaper samt å evaluere systemets egenskaper, slik sm pålitelighet g tilgjengelighet {Denne setningen klargjør hva sm egentlig er ment i den engelske versjnen}. Debugging g testing er t frskjellige ting. Dynamisk testing kan identifisere feil (eng.: failures). Debugging er den utviklingsaktiviteten sm finner g analyserer feilen g fjerner årsaken til feilen (failure) (reparerer den). Re-testing sjekker at feilen faktisk er krrigert. Ansvaret fr disse aktivitetene er vanligvis frskjellig plassert, dvs. ftest er det slik: testere tester g utviklere debugger. Testprsessen g dens aktiviteter er frklart i avsnitt 1.4. Versin 2011 Page 13 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

14 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 1.3 Syv testprinsipper (K2) 35 minutter Begreper Fullstendig testing. Prinsipper Et antall testprinsipper har blitt freslått de siste 40 årene; disse gir generelle retningslinjer sm gjelder fr alle typer testing. Prinsipp 1 Test viser tilstedeværelsen av feil Testing kan påvise feil, men kan ikke bevise fravær av feil. Testing reduserer sannsynligheten fr at prgramvaren innehlder skjulte feil, men selv m ingen feil kan identifiseres er ikke det et bevis fr krrekthet. Prinsipp 2 Fullstendig test er umulig Fullstendig test (alle kmbinasjner av inndata g frbetingelser) er ikke mulig unntatt i trivielle tilfeller. I stedet fr fullstendig (uttømmende) test, bør risikanalyse g priritering benyttes fr å fkusere testingen. Prinsipp 3 Tidlig testing Fr å finne feil tidlig, bør testaktivitetene starte så tidlig sm mulig i prgramvarens eller systemets utviklingslivssyklus, g de bør fkuseres på veldefinerte mål. Prinsipp 4 Klyngedannelse av feil Testarbeidet bør bli fkusert prprsjnalt til frventet g senere bservert feiltetthet i mduler. Et mindre antall mduler innehlder vanligvis mesteparten av feilene sm blir funnet i testen før frigivelsen, eller er ansvarlige fr de fleste feilene i drift. Prinsipp 5 Pesticid-paradks Hvis de samme testene gjentas m g m igjen, vil de etter hvert ikke finne nye feil. Fr å frhindre en slik situasjn, må testtilfellene regelmessig gjennmgås g revideres, g nye, frskjellige tester må utarbeides fr å teste frskjellige deler av prgramvaren eller systemet fr å finne mulige flere feil. Prinsipp 6 Test er avhengig av knteksten Testing utføres på ulike måter i ulike kntekster. Fr eksempel testes sikkerhetskritisk prgramvare på en annen måte enn netthandelsprgramvare. Prinsipp 7 Feiltakelse vedr. Fravær av feil Det hjelper lite å identifisere g rette feil hvis systemet er ubrukelig g ikke ppfyller brukernes behv g frventninger. Versin 2011 Page 14 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

15 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 1.4 Den grunnleggende testprsessen (K1) 35 minutter Begreper Re-testing, sluttkriterier, hendelse, regresjnstesting, testgrunnlag, testbetingelse, testdekning, testdata, testutførelse, testlgg, testplan, testprsedyre, testplicy, testsuite, testsluttrapprt, testware. Bakgrunn Den mest synlige delen av testprsessen er utførelsen av tester. Fr at en testplan skal være både effektiv g virkningsfull, bør imidlertid testplaner gså ta med tid sm skal brukes til planlegging av testen, design av testtilfelle, frberedelse av utførelsen g evaluering av resultater. Den grunnleggende testprsessen består av følgende hvedaktiviteter: Testplanlegging g teststyring Analyse g design av test Implementering g utførelse av test Evaluering av sluttkriterier g rapprtering Avslutningsaktiviteter Selv m denne listen følger lgisk rekkefølge, er det fte slik at aktiviteter verlapper eller finner sted samtidig. Vanligvis kreves det tilpasning av disse hvedaktivitetene til systemet g/eller prsjektet Testplanlegging g -styring (K1) Testplanlegging er den aktiviteten sm består av å definere testens frmål g spesifisere testaktivitetene fr å ppfylle frmål g ppdrag. Teststyring er den kntinuerlige sammenligningen av virkelig fremdrift ift. planen, samt rapprtering av status g avvik ift. planen. Det innebærer gså å gjennmføre tiltak fr å ppfylle prsjektets ppdrag g frmål. Fr å kunne styre testingen, bør hele testaktivitetene vervåkes nøye gjennm hele prsjektet. Testplanlegging tar med i betraktning tilbakemelding fra vervåkings- g styringsaktiviteter. Testplanleggings- g styringsaktiviteter er definert i kapittel 5 i dette pensum Testanalyse g -design (K1) Testanalyse g -design er aktiviteten der de generelle testfrmålene blir mfrmet til knkrete testbetingelser g testtilfelle. Testanalyse g -design har følgene hvedppgaver: Granskning av testgrunnlaget (slik sm krav, kritikalitetsnivå (risiknivå), rapprter fra risikanalyse, arkitektur, design, grensesnittspesifikasjner). Evaluering av testbarheten av testgrunnlaget g testbjektene. Identifisering g priritering av testbetingelsene basert på en analyse av testbjektene, spesifikasjnen, atferd g struktur av prgramvaren. Utarbeidelse g priritering av høynivå testtilfelle. Identifisering av nødvendige testdata fr å støtte testbetingelsene g testtilfellene. Design av testmiljøet g identifisering av nødvendig infrastruktur g verktøy. Å skape sprbarhet i begge retninger mellm testbasis g testtilfelle. Versin 2011 Page 15 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

16 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Testimplementering g -utførelse (K1) Testimplementering g -utførelse er aktiviteten der testprsedyrer g scripts spesifiseres ved å kmbinere testtilfelle i særskilt rden g inkludere all annen infrmasjn sm behøves fr utførelsen av testen, g der testmiljøet settes pp g testene utføres. Testimplementering g -utførelse har følgende hvedppgaver: Ferdigstilling, implementering g priritering av testtilfelle (inklusive identifikasjn av testdata). Utvikling g priritering av testprsedyrer, utarbeidelse av testdata, g hvis det er behv, frberedelse av testrammer g skriving av autmatiske testscripts. Prduksjn av testsuiter fra testprsedyrene fr å muliggjøre effektiv testutførelse. Verifisering av at testmiljøet har blitt satt pp på krrekt måte. Verifisering g ppdatering av tsidig sprbarhet mellm testbasis g testtilfelle. Utførelse av testprsedyrer, enten manuelt eller ved bruk av testverktøy, ifølge en planlagt sekvens Lgging av resultater fra testutføringen g registrering av identiteter g versjner av prgramvaren under test, testverktøy g testware. Sammenligning av faktiske resultater med frventede resultater. Rapprtering av avvik sm hendelser g analyse av disse fr å identifisere årsak (f. eks. en feil i kden, i spesifiserte testdata, i et testdkument, eller en feiltakelse i måten testen ble utført). Gjentakelse av testaktiviteter sm følge av tiltak sm ble utført i frbindelse med avvik. Fr eksempel, gjennmføring av en test sm tidligere ikke lyktes fr å bekrefte en feilrettelse (re-testing), utførelse av en krrigert test g/eller utførelse av tester fr å kntrllere at feil ikke har blitt intrdusert i uendrede mråder av prgramvaren eller at en feilretting ikke avslørte andre feil (regresjnstesting) Evaluering av sluttkriterier g rapprtering (K1) Evaluering av sluttkriterier er den aktiviteten der testutførelsen blir vurdert i frhld til de definerte testfrmålene. Dette bør gjøres fr hvert testnivå (se kapittel 2.2). Evaluering av avslutningskriterier g rapprtering har følgende hvedppgaver: Kntrll av testlgger mt sluttkriteriene sm ble spesifisert i testplanleggingen. Vurdering m flere tester behøves eller m sluttkriteriene bør frandres. Utarbeidelse av testsluttrapprten fr de invlverte parter Avslutningsaktiviteter (K1) Her samles det inn data fra avsluttede testaktiviteter fr å samle erfaring, testware, fakta g tall. Slike aktiviteter gjøres ved prsjektmilepeler fr eksempel når et prgramvaresystem frigis, når et testprsjekt er ferdig (eller avbrytes), når en milepæl har blitt ppnådd, eller når en vedlikehldsfrigivelse har blitt fullført. Testingsavslutningsaktiviteter mfatter følgende hvedppgaver: Kntrll av hvilke av de planlagte ppgavene er utført g testartefaktene sm har blitt levert. Lukking av hendelsesrapprter eller pprettelse av endringsregistreringer fr de sm frtsatt er åpne. Dkumentasjn på at systemet er blitt gdkjent eller underkjent. Ferdigstilling g arkivering av testmaterialet, testmiljøet g testinfrastrukturen fr fremtidig gjenbruk. Versin 2011 Page 16 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

17 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Overlevering av testware til de sm er ansvarlige fr vedlikehld. Analyse av erfaringer fr å bestemme endringer sm behøves ved fremtidige utgivelser g prsjekter. Bruk av infrmasjnen sm er samlet fr frbedring av testmdenhet. Versin 2011 Page 17 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

18 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 1.5 Testingens psyklgi (K2) 35 minutter Begreper Feilgjetting, uavhengighet. Bakgrunn Innstillingen sm bør benyttes ved testing g granskning er annerledes enn den sm behøves under utviklingen av prgramvaren. Med den rette innstillingen under testing g granskning kan utviklere teste sin egen kde, men ansvar fr testen blir ftest verført til en tester. Dette blir gjrt fr å fkusere prsessen g fr å få ytterligere frdeler, sm et uavhengig synspunkt fra spesielt pplærte g prfesjnelle testressurser. Uavhengig testing kan utføres på alle nivå av testen. En viss grad av uavhengighet (fr å unngå frfatterens inhabilitet) er fte mer effektivt fr å identifisere feil. Uavhengighet er derimt ikke en erstatning fr inngående kjennskap, g utviklere kan fte raskt identifisere feil i sin egen kde. Flere nivåer av uavhengighet kan spesifiseres fra lavt til høyt: Tester utarbeidet av den persnen/ de persnene sm har laget prgramvaren sm testes (lav grad av uavhengighet). Tester utarbeidet av en annen persn/ andre persner (f. eks. fra utviklingsteamet). Tester utarbeidet av en persn/ persner fra en annen rganisasjnsgruppe (f. eks. et uavhengig testteam) eller testspesialister (f. eks. spesialisert på brukervennlighet eller ytelse). Tester utarbeidet av en persn/ persner fra en annen rganisasjn eller firma (f. eks. utsurcing eller sertifisering av en ekstern rganisasjn). Mennesker g prsjekter er drevet av frmål. Flk pleier å tilpasse sine egne planer til de frmålene sm deres verrdnede eller andre interesserte parter har satt pp, f. eks. å finne feil eller bekrefte at prgramvaren fungerer. Det er derfr viktig å frmidle testingens frmål på en tydelig måte. Identifisering av feil under testingen kan ppfattes sm kritikk mt prduktet g mt prduktets skaper. Testing ppfattes derfr fte sm en negativ aktivitet, selv m det j er en svært knstruktiv del av behandlingen av prduktrisik. Å lete etter systemfeil i et prdukt krever nysgjerrighet, prfesjnell pessimisme, en kritisk innstilling, et øye fr detaljer, gde kmmunikasjnsevner verfr utviklerne sm man samarbeider med g erfaring fr å gjette hva sm kan være feil. Hvis feil kmmuniseres på en knstruktiv måte, kan dårlige følelser mellm testeren g analytikerne, designerne g utviklerne unngås. Dette gjelder granskning så vel sm testing. Testeren g testlederen må ha gde evner i mellmmenneskelig kmmunikasjn fr å kunne kmmunisere infrmasjn m feil, fremgang g risik på en knstruktiv måte. Infrmasjn m feil kan hjelpe frfatteren av prgramvaren eller et dkument i å frbedre sine ferdigheter. Feil sm blir identifisert g krrigert i testingen vil spare tid g penger senere i prsessen, samt redusere risik. Kmmunikasjnsprblemer kan ppstå, spesielt dersm testerne kun blir sett på sm budbringere av ubedt infrmasjn m feil g mangler. Imidlertid er det mange måter man kan frbedre kmmunikasjnen g frhldene mellm testerne g andre: Start med samarbeid, ikke knflikt minn alle på at de har det samme hvedmålet (et system med bedre kvalitet) Kmmuniser resultater på en nøytral, faktafkusert måte uten å kritisere de sm har skapt prduktet, skriv bjektive g faktabaserte hendelsesrapprter g granskningsrapprter. Prøv å frstå hva de andre føler g hvrfr de reagerer sm de gjør. Sikre deg at de andre har frstått det du har sagt g at du frstår det de sier. Versin 2011 Page 18 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

19 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 1.6 Etikk fr testeren 10 minutter Invlvering i prgramvaretesting gjør det mulig fr den enkelte å få tak i knfidensiell g privilegert infrmasjn. Etiske regler er nødvendig fr blant annet å sikre at infrmasjnen ikke brukes upassende. Ved å erkjenne ACM g IEEE sine etiske regler fr ingeniører vil ISTQB fremheve følgende etiske regler OFFENTLIG - Sertifiserte testere skal ppføre seg i samsvar med ffentlige interesser. KLIENT OG ARBEIDSGIVER - Sertifiserte testere skal handle på en måte sm er til beste fr sine klienter g arbeidsgivere, g i samsvar med ffentlige interesser. PRODUKT - Sertifiserte testere skal sikre at leveransene de tilbyr (fr prduktet g systemet de tester) møter høyest mulige prfesjnelle standarder. VURDERING - Sertifiserte testere skal passe på integritet g uavhengighet i deres prfesjnelle vurderinger. LEDELSE - Sertifiserte testledere g ledere skal søke g fremme en etisk framgangsmåte fr ledelse av prgramvaretesting. PROFESJON - Sertifiserte testere skal øke integritet g mdømme av prfesjnen i samsvar med ffentlige interesser. KOLLEGER - Sertifiserte testere skal være rettferdig g støtte deres klleger g fremme samarbeid med prgramvareutviklere. SELV - Sertifiserte testere skal delta I livslang læring vedrørende utøvelsen av sin prfesjn g de skal fremme en etisk framgangsmåte til utførelsen av jbben. Referanser Black, 2001, Kaner, Beizer, 1990, Black, 2001, Myers, Beizer, 1990, Hetzel, 1988, Myers, Hetzel, Black, 2001, Craig, Black, 2001, Hetzel, 1988 Versin 2011 Page 19 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

20 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 2 Testing gjennm livssyklusen (K2) 115 minutter Læremål fr testing gjennm prgramvarens livssyklus Målene identifiserer hva du skal kunne etter å ha gjennmgått hver mdul. 2.1 Utviklingsmdeller fr prgramvare (K2) LO LO LO Frklar sammenhengen mellm utvikling, testaktiviteter g arbeidsprdukter i utviklingslivssyklusen ved å gi eksempler basert på kntekst g egenskaper av prsjekt g prdukt. (K2) Erkjenne at utviklingsmdeller må tilpasses prsjektets kntekst g prduktets egenskaper. (K1) Huske karakteristiske egenskaper fr gd testing i enhver livssyklusmdell. (K1) 2.2 Testnivåer (K2) LO Testtyper (K2) LO LO LO LO LO Sammenligne de ulike testnivåene: hvedmål, typiske testbjekter, typiske mål fr testingen (fr eksempel funksjnell eller strukturell) g relaterte arbeidsprdukter, persnale sm tester g feiltyper sm skal finnes. (K2) Sammenligne de fire testtypene (funksjnell, ikke-funksjnell, strukturell g endringsrelatert) ved å gi eksempler. (K2) Erkjenne at funksjnelle g strukturelle tester kan være del av ethvert testnivå. (K1) Identifisere g beskrive ikke-funksjnelle testtyper basert på ikke-funksjnelle krav. (K2) Identifisere g beskrive testtyper basert på analyse av systemstrukturen eller arkitekturen. (K2) Beskrive målet med gjentatt testing g regresjnstesting. (K2) 2.4 Testing i vedlikehld (K2) LO LO LO Sammenligne vedlikehldstesting (testing på et eksisterende system) med testing av en ny applikasjn angående testtyper, hva sm utløser testing g mfanget av testing. (K2) Identifisere grunner fr vedlikehldstesting (endring, migrering g at et system blir tatt ut av bruk). (K1) Beskrive rllen regresjnstesting g knsekvensanalyse har i vedlikehld. (K2) Versin 2011 Page 20 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

21 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 2.1 Utviklingsmdeller fr prgramvare(k2) 20 minutter Begreper Standardsystem, iterativ-inkrementell utviklingsmdell, validering, verifikasjn, V-mdell. Bakgrunn Testing eksisterer ikke islert. Testaktiviteter henger sammen med utviklingsaktivitetene. Ulike utviklingsmdeller behøver ulike teststrategier V-mdellen (sekvensiell utviklingsmdell) (K2) Selv m det finnes varianter av V-mdellen, bruker en vanlig type V-mdell fire testnivåer sm hører sammen med de fire utviklingsnivåene. De fire testnivåer i dette pensum er: kmpnent (enhets) testing; integrasjnstesting; systemtesting; akseptansetesting. I praksis kan en V-mdell ha flere, færre eller ulike nivåer av utvikling g testing. Dette avhenger av prsjekt g prdukt. Fr eksempel kan en ha kmpnentintegrasjnstesting etter kmpnenttesting, g systemintegrasjnstesting etter systemtesting. Prgramvarens arbeidsprdukter (sm frretningsscenarier eller brukstilfelle (use case), kravspesifikasjner, designdkumenter g kde) sm er laget under utviklingen er fte basis fr testingen i et eller flere testnivåer. Referanser fr generiske arbeidsprdukter mfatter Capability Maturity Mdel Integratin (CMMI) eller Sftware life cycle prcesses (IEEE/IEC 12207). Verifikasjn g validering (g tidlig testutvikling) kan utføres under utvikling av prgramvarens arbeidsprdukter Iterativ-inkrementell utviklingsmdeller (K2) Iterativ-inkrementell utvikling er prsessen med å etablere krav, knstruere, bygge g teste et system sm en serie av krtere utviklingssykluser. Eksempler er: Prttyping, rask applikasjnsutvikling (RAD), Ratinal Unified Prcess (RUP) g agile (smidige) utviklingsmdeller. Et system sm er prdusert ved bruk av disse mdellene, kan testes på flere nivåer sm del av dens utvikling i iterasjnen. Et nytt delsystem sm legges til de andre sm er utviklet før utgjør et vksende delvis utviklet system, g det bør gså testes. Regresjnstesting blir stadig mer viktig etter den første iterasjnen. Verifikasjn g validering kan utføres fr hvert inkrement Testing i en livssyklusmdell (K2) I enhver livssyklusmdell er gd testing karakterisert ved følgende: Fr hver utviklingsaktivitet er det en tilsvarende testaktivitet. Hvert testnivå har bestemte testmål. Analyse g design av testene fr et gitt testnivå bør starte når den tilsvarende utviklingsaktiviteten utføres. Testere bør delta i gjennmgang av dkumenter så snart utkast er tilgjengelig. Versin 2011 Page 21 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

22 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Testnivåer kan kmbineres eller rerganiseres avhengig av prsjektets egenskaper eller systemarkitekturen. Fr eksempel: fr å integrere et innkjøpt standardprdukt i et system kan kunden utføre integrasjnstesting på systemnivå (dvs. integrasjn med infrastrukturen g andre systemer, eller distribusjn g implementering av systemet) g akseptansetesting (funksjnelt g ikke-funksjnelt samt brukerakseptansetesting g driftsakseptansetesting). Versin 2011 Page 22 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

23 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 2.2 Testnivåer (K2) 40 minutter Begreper Alfatesting, betatesting, kmpnenttesting (gså kjent sm enhets-, mdul- eller prgramtesting), driver, felttesting, funksjnelt krav, integrasjn, integrasjnstesting, ikke-funksjnelt krav, rbusthetstesting, stubb, systemtesting, testnivå, testdrevet utvikling, testmiljø, brukerakseptansetesting. Bakgrunn Fr hvert testnivå kan en identifisere følgende: De generiske mål, arbeidsprdukt(ene) en bruker fr å knstruere testtilfelle (testgrunnlag), testbjektet (dvs. hva en tester), typiske feil sm skal finnes, krav til testramme g verktøystøtte samt spesifikke strategier g ansvarsfrhld. Å teste knfigurasjnsdata til et system skal vurderes under testplanlegging Kmpnenttesting (K2) Test basis: Krav til kmpnenten Detaljdesign Kde Typiske testbjekter: Kmpnenter Prgrammer Dataknverterings- / migrasjnsprgrammer Databasemduler Kmpnenttesting (gså kjent sm enhets- eller mdultesting) søker feil g verifiserer prgramvare sm kan testes separat (sm mduler, prgrammer, bjekter, klasser etc.). Dette kan skje islert fra resten av systemet, avhengig av hvrdan utviklingen er rganisert g hva slags system det er. Stubber, drivere g simulatrer kan brukes. Kmpnenttesting kan mfatte testing av funksjnalitet g spesifikke ikke-funksjnelle egenskaper, sm ressursbruk (fr eksempel minnelekkasjer) eller rbusthet. Kmpnenttesting kan gså mfatte hvit bks testing. Testtilfeller utvikles ved å analysere arbeidsprdukter sm kmpnentspesifikasjner, prgrammets design eller datamdellen. Typisk skjer kmpnenttesting med tilgang til kden sm testes g med støtte av utviklingsmiljøet, sm et rammeverk fr enhetstest eller debuggingsverktøy. I praksis blir det fte gjrt av den sm skrev kden. Feil rettes vanligvis med en gang etter at de har blitt funnet uten frmell feilhåndtering. En framgangsmåte fr kmpnenttesting er å frberede g autmatisere testtilfeller før kdingen. Dette kalles test først metden eller testdrevet utvikling. Denne metden er i høy grad iterativ g er basert på sykluser der en først utvikler testtilfeller, g så bygger g integrerer små deler av kden, g så utfører kmpnenttester g så retter feil g gjentar prsessen inntil kden virker. Versin 2011 Page 23 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

24 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Integrasjnstesting (K2) Testbasis: Sftware- g systemdesign Arkitektur Arbeidsflyt Brukstilfeller (Use cases) Typiske testbjekter: Delsystemer Databaseimplementasjn Infrastruktur Grensesnitt Systemknfigurasjn Og knfigurasjnsdata Integrasjnstesting tester grensesnitt mellm kmpnenter g kmmunikasjn mellm ulike deler av systemet. Disse kan være perativsystem, filsystem, hardware eller grensesnitt mellm systemer. Det kan finnes flere integrasjnstestnivåer g de kan bli utført på testbjekter av ulik størrelse. Fr eksempel: 1. Kmpnentintegrasjnstesting tester kmmunikasjnen mellm kmpnenter g blir gjrt etter kmpnenttesting; 2. Systemintegrasjnstesting tester interaksjnen mellm ulike systemer g mellm hardware g sftware g kan bli gjrt etter systemtesting. I dette tilfelle kan det hande at utviklingsrganisasjnen bare styrer den ene siden av et grensesnitt. Dette kan utgjøre en egen risik. 3. Test av frretningsprsesser kan mfatte test av en hel serie av systemer. 4. Integrasjnstesting kan gså undersøke verganger mellm frskjellige plattfrmer. J større mfanget av integrasjnen er, j vanskeligere blir det å islere feil til en bestemt kmpnent eller et bestemt system. Dette kan føre til økt risik g ekstra tidsbruk fr å håndtere trøbbel. Systematiske integrasjnsstrategier kan være basert på systemarkitekturen (sm venfra ned eller nedenfra pp), på gjennmgående funksjner, transaksjnsprsessering eller andre aspekter ved kmpnentene eller systemet. Fr å lette feilislering g fr å finne feil tidlig bør en vanligvis heller integrere trinnvis enn alt på en gang ( big bang ). Integrasjnstesting kan gså mfatte testing av bestemte ikke-funksjnelle egenskaper (fr eksempel ytelse). På hvert integrasjnstrinn knsentrerer testerne seg bare m integrasjnen selv. Fr eksempel, hvis de integrerer mdul A med mdul B, så er de interessert i å teste kmmunikasjnen mellm mdulene, ikke funksjnaliteten i den ene eller annen mdul, frdi dette ble gjrt i kmpnenttestingen. Både funksjnelle (svart bks) g strukturelle (hvit bks) strategier er aktuelle. Versin 2011 Page 24 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

25 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Det er best hvis testerne frstår arkitekturen g har innflytelse på integrasjnsleggingen. Hvis integrasjnstester er planlagt før kmpnentene eller systemene bygges, kan disse bygges i en bestemt rekkefølge slik at testingen blir mest mulig effektiv Systemtesting (K2) Testbasis: System- g sftware kravspesifikasjn Use cases (brukstilfelle) Funksjnell spesifikasjn Risikanalyserapprter Typiske testbjekter: System-, bruker- g driftsmanualer Systemknfigurasjn g knfigurasjnsdata Systemtesting gjelder ppførselen av hele systemet eller prduktet, altså hele mfanget av et prsjekt eller prgram. Testingens mfang skal klart uttrykkes i den verrdnete testplanen g/eller planen fr systemtesting. I systemtestingen bør testmgivelsen stemme så gdt sm mulig verens med det endelige målmiljøet eller prduksjnsmiljøet fr å minimere risiken fr at miljøavhengige feil verlever testingen. Systemtesting kan mfatte tester basert på risikanalyser g/eller kravspesifikasjner, frretningsprsesser, brukstilfeller (use cases) eller andre høynivåbeskrivelser eller mdeller av systemets ppførsel, interaksjner med perativsystemet g systemressurser. Systemtesting bør mfatte både funksjnelle g ikke-funksjnelle krav til systemet g krav m datakvalitet. Krav kan eksistere sm tekster g/eller mdeller. Testere må gså håndtere ufullstendige eller udkumenterte krav. Systemtesting av funksjnelle krav starter ved at man bruker de mest egnede spesifikasjnsbaserte (svart bks) teknikker fr det aspekt ved systemet en skal teste. Fr eksempel kan en lage en beslutningstabell fr kmbinasjner av resultater beskrevet i frretningsreglene. Strukturbaserte teknikker (hvit bks) kan etterpå brukes fr å sjekke grundigheten av testingen mht. strukturelementer sm en menystruktur eller navigeringen i en webside. (Se kapittel 4.) Ofte utfører en uavhengig testgruppe systemtesten Akseptansetesting (K2) Testbasis: Brukerkrav Systemkrav Brukstilfeller (Use cases) Frretningsprsesser Risikanalyserapprter Versin 2011 Page 25 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

26 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Typiske testbjekter: Frretningsprsesser på det fullt integrerte systemet Drifts- g vedlikehldsprsesser Bruksprsedyrer Frmularer Rapprter Knfigurasjnsdata Akseptansetesting er fte et ansvarsmråde fr kundene eller brukerne av et system. Andre interessenter kan gså bli invlvert. Målet med akseptansetestingen er å etablere tillit til systemet, delsystemet eller spesifikke ikkefunksjnelle egenskaper av et system. Å finne feil er ikke hvedfkus i akseptansetestingen. Akseptansetesting kan bedømme m et system er klart fr å bli installert g brukt, selv m det ikke nødvendigvis er siste testnivå. Fr eksempel, en systemintegrasjnstest i str skala kan kmme etter akseptansetesten fr et system Akseptansetesting kan skje på flere ulike tider i livssyklusen, fr eksempel: Et standardprdukt kan bli akseptansetestet når det blir installert eller integrert. Akseptansetesting av brukbarheten av en kmpnent kan bli utført under kmpnenttesting. Akseptansetesting av en ny funksjnell frbedring kan kmme før systemtesting. Typiske frmer fr akseptansetesting mfatter de følgende: Brukerakseptansetesting Typisk verifiserer denne testen m systemet er klar til bruk fr virkelige brukere. Drifts(akseptanse)testing Driftstesting i akseptansetestingen av peratør g/eller administratr, inklusive: sikkerhetskpiering g gjenpprettelse, håndtering av katastrfer, administrasjn av brukere, vedlikehldsppgaver, datainnlasting g migreringsppgaver, peridisk sjekk av sikkerhetshull. Akseptansetesting vedrørende kntrakter eller frskrifter Denne typen akseptansetesting blir gjrt i frhld til en kntrakts akseptansekriterier fr å prdusere spesielt utviklet prgramvare. Akseptansekriterier bør defineres når kntrakten blir inngått. Akseptansetesting angående frskrifter blir utført i frhld til hvilke sm helst frskrifter sm må ppfylles, sm statlige, juridiske eller sikkerhetsmessige. Alfa g betatesting eller felttesting Utviklere av standardprgrammer vil fte ønske å få tilbakemelding fra ptensielle eller eksisterende kunder i deres marked før et prgramvareprdukt blir tilbudt fr kmmersielt salg. Alfatesting blir utført på utviklingsrganisasjnens sted, men ikke av utviklingsgruppen. Betatesting eller felttesting blir utført av kunder eller ptensielle kunder på deres egne plattfrmer. Versin 2011 Page 26 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

27 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Organisasjner kan gså bruke andre betegnelser, sm fr eksempel factry acceptance testing g site acceptance testing fr systemer sm blir testet før g etter at de blir flyttet til en kundeinstallasjn. Versin 2011 Page 27 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

28 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 2.3 Testtyper (K2) 40 minutter Begreper Funksjnell testing, Black-bx testing, svart bks testing, kdedekning, interperabilitetstesting, belastningstesting, vedlikehldbarhetstesting, ytelsestesting, prtabilitetstesting, pålitelighetstesting, sikkerhetstesting, stresstesting, brukbarhetstesting, strukturell testing, white-bx testing, hvit bks testing. Bakgrunn En gruppe testaktiviteter kan ha sm mål å verifisere prgramsystemet (eller delen av et system) med grunnlag i en bestemt begrunnelse eller et bestemt testmål. En testtype er fkusert på et bestemt testmål, sm kan være en av følgende: test av en funksjn, sm prgrammet skal utføre en ikke-funksjnell kvalitetsegenskap, sm fr eksempel pålitelighet eller brukbarhet, strukturen eller arkitekturen til prgrammet eller systemet relatert til endringer, dvs. sikring at feil har blitt rettet (re-testing) g kntrll mt utilsiktede bivirkninger (regresjnstesting). Man kan utvikle eller bruke en mdell av prgramvaren fr strukturell testing (fr eksempel en kntrllflytmdell eller mdell av menystrukturen), ikke-funksjnell testing (fr eksempel en mdell fr ytelse eller brukervennlighet, en trusselmdell fr sikkerhet), g fr funksjnell testing (fr eksempel en prsessflytmdell, tilstandsmdell eller en spesifikasjn i naturlig språk) Testing av funksjnalitet (funksjnell testing) (K2) Funksjnen et system, delsystem eller en kmpnent skal utføre kan være beskrevet i arbeidsprdukter sm fr eksempel en kravspesifikasjn, brukstilfelle (use case), eller en funksjnell spesifikasjn, eller de kan være udkumentert (underfrstått). Funksjnene er hva systemet gjør. Funksjnelle tester er basert på funksjner g features (beskrevet i dkumenter eller kjent av testerne) g deres interaksjn med spesifikke systemer, g kan utføres på alle testnivåer (tester fr kmpnenter kan fr eksempel baseres på kmpnentspesifikasjnen). Spesifikasjnsbaserte teknikker kan brukes fr å utlede testbetingelser g testtilfelle fra prgramvarens eller systemets funksjnalitet. (Se kapittel 4). Funksjnell testing er pptatt av den eksternt synlige ppførselen av prgramvaren (svart bks testing). En type funksjnell testing, sikkerhetstesting, undersøker funksjnene (/fr eksempel en brannmur) relatert til ppdagelsen av trusler, sm fr eksempel virus g angrep fra ndsinnede utenfrstående. En annen type funksjnell testing, testing av interperabilitet, evaluerer prgramvareprduktets evne til å samvirke med en eller flere spesifiserte kmpnenter eller systemer Testing av ikke-funksjnelle egenskaper av prgramvaren (ikkefunksjnell testing) (K2) Ikke-funksjnell testing mfatter, men er ikke begrenset til, ytelsestesting, belastningstesting, stresstesting, brukbarhetstesting, vedlikehldbarhetstesting, pålitelighetstesting g prtabilitetstesting. Dette er testing av hvrdan systemet virker. Versin 2011 Page 28 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

29 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Ikke-funksjnell testing kan utføres på alle testnivåer. Begrepet ikke-funksjnell testing beskriver testene sm kreves fr å måle egenskaper av systemer g prgramvare sm kan kvantifiseres på en variabel skala, sm fr eksempel svartider fr ytelsestesting. Disse testene kan referere til en kvalitetsmdell sm den sm er definert i standarden Sftware Engineering Sftware Prduct Quality (ISO ) 2. Ikke-funksjnell testing ser på den eksternt synlige ppførselen av prgramvaren g bruker fr det meste svart bks teknikker fr testdesign Testing av prgramvarens struktur/arkitektur (strukturell testing, hvit bks testing) (K2) Strukturell (hvit bks) testing kan utføres på alle testnivå. Strukturelle teknikker blir best brukt etter spesifikasjnsbaserte teknikker, fr hjelp til å måle grundigheten av testingen. Dette gjøres ved å bedømme dekningen av diverse typer struktur. Dekningsgraden fr en struktur sm er blitt testet, uttrykkes ved andel fullførte tester i prsent av alle de mulige testene fr det valgte dekningskriteriet. Dekningsgraden er altså graden sm en struktur har blitt utført gjennm en testsuite, uttrykt sm en prsent. Hvis dekningen ikke er 100%, kan en lage flere tester fr å teste de ting sm manglet, g dermed øke dekningsgraden. Slike teknikker er beskrevet i kapittel 4. En kan bruke verktøy fr å måle dekningsgraden mt kde av de elementene sm testes, på alle testnivåer, men spesielt i kmpnenttestingen g i kmpnentintegrasjnstestingen. Eksempel på slike elementer er prgraminstruksjner g frgreninger. Strukturell testing kan gså baseres på arkitekturen av et system, sm fr eksempel kallhierarkiet. Strukturelle testteknikker kan gså brukes på nivåene systemtest, systemintegrasjnstest g akseptansetest (fr eksempel mt mdeller av frretningsgangen eller menystrukturer) Testing relatert til endringer (re-testing g regresjnstesting) (K2) Etter at en feil er funnet g rettet, bør prgramvaren re-testes fr å bekrefte at den pprinnelige feilen er rettet riktig. Dette kalles fr bekreftelse (re-testing). Debugging (lkalisering av feil g feilretting) er en utviklingsaktivitet, ikke en testaktivitet. Regresjnstesting er ny testing av et tidligere testet prgram etter mdifikasjner. Dette gjøres fr å sikre at feil ikke er blitt intrdusert i uendrede mråder i prduktet. Regresjnstest tjener gså til å ppdage feil sm lå skult i uendrede mråder i prduktet, men sm blir tilgjengelige etter endringen. Regresjnstest blir utført etter endringer i prgramvaren eller mgivelsen. Disse feilene kan enten være i prgramvaren sm testes eller i en annen relatert eller urelatert prgramvarekmpnent. Regresjnstesting utføres når prgramvaren eller dens mgivelse blir endret. Omfanget av regresjnstesting baseres på risiken fr å ikke finne feil i prgramvaren sm virket før. Tester bør være mulig å gjenta hvis de skal brukes til re-testing g fr å hjelpe regresjnstestingen. Regresjnstesting kan utføres på alle testnivåer g mfatter funksjnell, ikke-funksjnell g strukturell testing. Regresjnstestsuiter kjøres mange ganger g utvikler seg generelt langsmt. Dette betyr at regresjnstesting er en sterk kandidat fr autmatisering. 2 Standarden er erstattet av Standarden ISO/IEC 25010:2011, sm er dg ikke relevant fr eksamen. Versin 2011 Page 29 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

30 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 2.4 Testing i vedlikehld (K2) 15 minutter Begreper Knsekvensanalyse, vedlikehldstesting. Bakgrunn Når et prgramvaresystem er satt i drift, er det fte i drift fr år eller tiår. I løpet av denne tiden blir systemet, dets knfigurasjnsdata eller dets mgivelse fte krrigert, endret eller utvidet. Fr suksess i vedlikehldstesting er det avgjørende at frigivelser blir planlagt på frhånd. En må skille mellm planlagte frigivelser g nødsendringer. Vedlikehldstesting blir gjrt på et eksisterende system i drift, g blir utløst av endringer i mgivelsen, endringer, migrasjn eller avvikling av prgramvaren eller systemet. Endringer mfatter planlagte frbedringer (fr eksempel ved nye frigivelser), krreksjner g nødsendringer av prgramvaren eller systemet. Det mfatter gså endringer i mgivelsen slik sm planlagte ppgraderinger av perativ- g databasesystem, planlagte ppgraderinger av standardsystemer, eller patcher fr å krrigere nye sårbarheter av perativsystemet sm er funnet eller blitt kjent. Vedlikehldstesting fr migrasjn (fr eksempel fra en plattfrm til en annen) bør mfatte driftstester av den nye mgivelsen g av den endrete prgramvaren. Migrasjnstesting (knverteringstesting) trengs gså når data fra en annen applikasjn skal migreres inn i systemet sm vedlikehldes. Vedlikehldstesting fr avvikling av et system kan mfatte testing av datamigrasjn eller arkivering hvis data må ppbevares i lang tid. I tillegg til testing av det sm er blitt endret, mfatter vedlikehldstesting regresjnstesting av de deler av systemet sm ikke er blitt endret. Omfanget av vedlikehldstesting henger sammen med risiken med endringen, størrelsen på det eksisterende systemet g størrelsen på endringen. Avhengig av endringene kan vedlikehldstesting gjøres på et eller alle testnivåer g fr en eller alle testtyper. Å avgjøre hvrdan endringer kan ha følger fr det eksisterende system, kalles knsekvensanalyse. Denne brukes til å beslutte hvr mye regresjnstesting en skal gjøre. Knsekvensanalyse kan brukes fr å avgjøre hva sm skal være med i en regresjnstestsuite. Vedlikehldstesting kan være vanskelig hvis spesifikasjnene er avleggs, de ikke finnes eller en ikke har testere sm har kunnskap til bruksmrådet. Referanser CMMI, Craig, 2002, Hetzel, 1988, IEEE Hetzel, Cpeland, 2004, Myers, Beizer, 1990, Black, 2001, Cpeland, Black, 2001, ISO Beizer, 1990, Cpeland, 2004, Hetzel, Hetzel, 1988, IEEE Black, 2001, Craig, 2002, Hetzel, 1988, IEEE Versin 2011 Page 30 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

31 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 3 Statiske teknikker (K2) 60 minutter Læremål fr statiske teknikker Læremålene identifiserer hva du skal være i stand til å gjøre når du har gjennmgått hver mdul. 3.1 Statiske teknikker g testprsessen (K2) LO LO LO Gjenkjenne arbeidsresultater ved prgramvare sm kan sjekkes ved ulike statiske teknikker. (K1) Beskrive viktigheten g verdien av statiske teknikker fr bedømmelse av arbeidsprdukter ved prgramvare. (K2) Frklare frskjellen mellm statiske g dynamiske teknikker ved å vurdere målsetningene, typer av feil sm kan identifiseres, g rllen av disse teknikkene i livssyklusen av prgramvare. (K2) 3.2 Granskningsprsessen (K2) LO LO LO Kjenne fasene, rller g ansvarsfrhld ved en typisk frmell granskning. (K1) Frklare frskjellen mellm ulike typer granskninger: ufrmell granskning, teknisk gjennmgang, walkthrugh g inspeksjn. (K2) Frklare faktrene fr suksessfull utføring av granskninger. (K2) 3.3 Statisk analyse med verktøy (K2) LO LO LO Gjenkjenne typiske feil sm identifiseres av statisk analyse g sammenlikne dem med granskninger g dynamisk testing. (K1) Beskrive ved eksempler typiske nytteeffekter av statisk analyse. (K2) Liste pp typiske kde- g designfeil sm kan identifiseres ved bruk av verktøy fr statisk analyse. (K1) Versin 2011 Page 31 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

32 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 3.1 Statiske teknikker g testprsessen (K2) 15 minutter Begreper Dynamisk testing, statisk testing. De t rdene granskning g review brukes i samme betydning. Bakgrunn Til frskjell fra dynamisk testing sm krever utføring av prgrammet, baserer statiske testteknikker seg på manuell kntrll (reviews, granskninger) g autmatisk analyse (statisk analyse) av kden eller annen prsjektdkumentasjn uten at kden blir utført. Granskning er en måte å teste arbeidsprdukter ved prgramvare (inklusive kde) g kan utføres lenge før en utfører dynamisk test. Feil funnet i granskninger tidlig i livssyklusen er fte mye billigere å rette enn de en ppdager når en utfører tester (fr eksempel feil funnet i kravene). En granskning kan utføres helt manuelt, men gså med verktøystøtte. Den i hvedsak manuelle aktiviteten er å kntrllere et arbeidsprdukt g kmmentere det. Hvilket sm helst arbeidsprdukt kan gjennmgås, inklusive kravspesifikasjner, designspesifikasjner, kde, testplaner, testspesifikasjner, testtilfelle, testskripter, brukermanualer eller websider. Frdeler med granskninger mfatter at en finner g retter feil tidlig, at prduktiviteten i utviklingen øker, utviklingen går frtere, g at testingens kstnad g tidsbruk minsker. Kstnaden i løpet av hele livstiden til et prgram blir redusert, det blir færre feil g frbedret kmmunikasjn. Granskninger kan finne uteglemte ting, fr eksempel i krav, sm er vanskelig å finne i dynamisk testing. Granskninger, statisk analyse g dynamisk testing har same mål å identifisere feil. Teknikkene utfyller hverandre: de ulike teknikkene kan finne ulike typer feil på en effektiv g prduktiv måte. Sammenlignet med dynamisk testing, finner statiske teknikker årsaken til prblemer (altså feilen selv), ikke bare symptmene. Typiske feil sm er lettere å finne i granskninger enn i dynamisk testing er: avvik fra standarder, feilaktige krav, feil i design, utilstrekkelig vedlikehldbarhet g feilaktige grensesnittspesifikasjner. Versin 2011 Page 32 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

33 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 3.2 Granskningsprsessen (K2) 25 minutter Begreper Inngangskriterier, frmell granskning, ufrmell granskning, inspeksjn, måling, mderatr/inspeksjnsleder, peer review, revisr, reviewer, prtkllant, teknisk gjennmgang, walkthrugh. Begrepene strukturert gjennmgang g walkthrugh er brukt i samme betydning. Bakgrunn De ulike typer granskninger varierer fra meget ufrmell (fr eksempel ingen nedskrevne instruksjner fr de sm gjennmgår) til meget frmell (dvs. medvirkning fra hele gruppen, dkumenterte resultater g dkumenterte prsedyrer fr å hlde en granskning). Frmaliteten til en granskningsprsess henger sammen med faktrer sm utviklingsprsessens mdenhet, krav i lver eller frskrifter eller behvet fr sprbarhet. Måten en granskning utføres på avhenger av målet sm en er blitt enig m fr granskningen (dvs. finne feil, frstå prblemmrådet, pplæring av testere eller nye medarbeidere eller diskusjn g beslutning ved hjelp av knsensus) Faser i en frmell granskning (K1) En typisk frmell granskning har følgende hvedfaser: 1. Planlegging: Definere granskningskriterier velge persnene tildele rller definere start- g sluttkriterier fr mer frmelle granskninger (sm inspeksjner) g sjekke startkriteriene velge hvilke deler av dkumentet en skal se på 2. Oppstart: dele ut dkumentene frklare målsetningene, prsess g dkumentene til deltakerne 3. Individuell frberedelse: arbeid sm gjøres av hver deltaker alene før granskningsmøte frberede seg fr granskningsmøtet ved å gjennmgå dkumentet / dkumentene 4. Granskningsmøte: diskutere eller lggføre, med dkumenterte resultater eller prtkll (fr mer frmelle granskningstyper). ntere feil, gjøre anbefalinger fr å håndtere dem eller gjøre beslutninger m feilene. gjennmgang, evaluering g nedskriving av anmerkninger. Dette kan skje i gruppemøtet eller gjennm elektrniske midler. 5. Retting: rette de feil sm er funnet, vanligvis gjrt av frfatteren. lggføre endret status av feilene (i frmelle granskninger) 6. Oppfølging: kntrllere at feilene er gjrt ne med samle måledata sjekke at sluttkriteriene er ppfylt (fr mer frmelle granskningstyper). Versin 2011 Page 33 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

34 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Rller g ansvar (K1) En typisk frmell granskning har følgende rller: Manager: Beslutter m granskninger skal gjøres, setter av tid i prsjektplaner g bestemmer m målene til en granskning er blitt ppnådd. Granskningsleder / Mderatr: Persnen sm leder granskningen av dkumentet eller samlingen dkumenter. Dette mfatter planlegging av granskningen, møteledelse g ppfølging etter møtet. Hvis nødvendig kan mderatren megle mellm de ulike synspunktene. Mderatren er fte avgjørende fr suksessen av en granskning. Frfatter: Den sm har skrevet dkumentet (eller dkumentene) eller har hvedansvaret fr det sm skal gjennmgås. Reviewere / Revisrer: Persner med spesifikk teknisk eller anvendelsesbakgrunn (de blir gså kalt kntrllører eller inspektører) sm, etter nødvendig frberedelse, identifiserer g beskriver saker de finner (fr eksempel feil) i prduktet sm gjennmgås. Revisrer bør velges slik at de kan representere ulike perspektiver g rller i granskningsprsessen, g bør delta i granskningsmøtene. Prtkllant (eller sekretær): Dkumenterer alle anmerkninger, prblemer g åpne punkter sm blir identifisert i møtet. Å se på prgramvareprdukter eller relaterte arbeidsresultater (dkumenter) fra ulike perspektiver g å bruke sjekklister kan gjøre granskninger mer effektive. Fr eksempel: en sjekkliste basert på ulike perspektiver sm bruker, vedlikehldsansvarlig, tester eller driftsansvarlig, eller en sjekkliste bestående av typiske prblemer med krav, kan hjelpe til med å finne hittil versette prblemer Granskningstyper (K2) Et enkelt dkument kan utsettes fr mer enn en granskning. Hvis mer enn en type granskning blir brukt, kan rekkefølgen på granskningene variere. Fr eksempel kan en først utføre en ufrmell granskning, så en teknisk gjennmgang. En inspeksjn kan utføres på en kravspesifikasjn før en walkthrugh med kunder. Hvedegenskapene, mulighetene g målsetningene av de vanlige granskningstyper er: Ufrmell granskning Hvedegenskaper: Ingen frmell prsess; Dette kan være parprgrammering eller at en teknisk ekspert går gjennm design g kde; Kan (men må ikke) være dkumentert; Nytteverdien kan variere avhengig av hvem sm gjennmgår; Hvedfrmål: En billig måte å få nyttig feedback. Strukturert gjennmgang / Walkthrugh Hvedegenskaper: Møte ledes av frfatteren; Scenarier, tørrkjøring, gruppe av arbeidsklleger; Møtet har åpen dagsrden; Mulighet fr at deltakerne frbereder seg før møtet, g mulighet fr granskningsrapprt, liste av hva sm er funnet g mulighet fr en prtkllant (sm ikke er frfatter); Kan i praksis variere fra meget ufrmell til meget frmell; Hvedfrmål: Å lære, å få frståelse fr dkumentet, å finne feil. Versin 2011 Page 34 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

35 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Teknisk gjennmgang Hvedegenskaper: Dkumentert, definert prsess fr å finne feil. Den inkluderer arbeidsklleger g tekniske eksperter. Lederne kan delta, dersm de har ne verdi å tilføye. Kan utføres sm en peer review uten at ledelsen deltar; I idealtilfelle ledet av en pplært møteleder (mderatr), ikke av frfatteren; Reviewerne frbereder seg før møtet; Valgfri bruk av sjekklister Utarbeidelse av en granskningsrapprt sm mfatter en liste av hva sm er funnet g utsagn m prduktet ppfyller sine krav g, der det behøves, anbefalinger vedrørende de ting sm er funnet. Kan i praksis variere fra meget ufrmell til meget frmell; Hvedfrmål: Å diskutere, gjøre beslutninger, evaluere alternativer, finne feil, løse tekniske prblemer g sjekke samsvar med spesifikasjner, planer, frskrifter g standarder. Inspeksjn Hvedegenskaper: Ledet av en pplært møteleder (mderatr), ikke av frfatteren; Vanligvis sjekking ved hjelp av arbeidsklleger; Definerte rller; Samling g bruk av måledata; Frmell prsess basert på regler g sjekklister; Spesifiserte inngangs- g utgangskriterier fr å gdkjenne prduktet; Frberedelse før møtet; Inspeksjnsrapprt med liste av anmerkninger; Frmell ppfølgingsprsess (med valgfri bruk av data til prsessfrbedring) Valgfri bruk av en leser; Hvedfrmålet er å finne feil. Walkthrughs, tekniske gjennmganger g inspeksjner kan utføres i en gruppe av klleger på samme rganisatriske nivå. Denne typen granskning kalles kllegagjennmgang Suksessfaktrer fr granskninger (K2) Suksessfaktrer fr granskninger mfatter: Hver granskning har et klart g på frhånd definert mål. De rette mennesker fr disse målsetninger er med. Testerne blir verdsatt sm deltakere sm bidrar til en review g lærer m prduktet, ne sm gjør det mulig fr dem å frberede testene tidligere. Feilene sm finnes er velkmne g de rapprteres bjektivt. Prblemer mht. invlverte persner g psyklgiske aspekter blir håndtert på rett måte (dvs. at en granskning blir til en psitiv pplevelse fr frfatterne g de andre deltakere). Granskningsteknikker sm er egnet fr å ppnå målsetningen g type g nivå av prgramvareprdukter g deltakere blir brukt. Sjekklister eller rller brukes hvis passende fr å øke effektiviteten med å finne feil. Deltakerne er pplært i granskningsteknikker, spesielt når det gjelder de mer frmelle teknikker, sm inspeksjn. Ledelsen støtter en gd granskningsprsess (fr eksempel ved å avsette nk tid i prsjektplaner fr granskningsaktiviteter). Det legges vekt på læring g prsessfrbedring. Versin 2011 Page 35 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

36 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 3.3 Statisk analyse med verktøy (K2) 20 minutter Begreper Kmpilatr, kmpleksitet, kntrllflyt, dataflyt, statisk analyse. Bakgrunn Målet med statisk analyse er å finne feil i kildekde g mdeller fr prgramvaren. Statisk analyse gjøres uten å utføre det sm analyseres; det analyseres med verktøy. Dynamisk testing utfører kden. Statisk analyse kan lkalisere feil sm er vanskelige å finne i (dynamisk) testing. Sm ved granskninger finner statisk analyse feilene direkte istedenfr via symptmer. Statiske analyseverktøy analyserer prgramkde (dvs. kntrll- g dataflyt), men gså generert utput sm HTML g XML. Verdien av statisk analyse er: Tidlig ppdagelse av feil før testutføring. Tidlig varsel m mistenkelige egenskaper ved kden eller designet ved å beregne måleverdier, sm høy kmpleksitet. Identifisering av feil sm dynamisk testing ikke finner så lett. Oppdagelse av avhengigheter g selvmtsigelser i sftware-mdeller; fr eksempel linker. Frbedret vedlikehldbarhet av kde g design. Frebygging av feil, hvis en lærer av feilene under utvikling. Typiske feil sm statiske analyseverktøy finner mfatter: Å referere en variabel med en udefinert verdi; Avvik i grensesnitt mellm mduler g kmpnenter; Variabel sm aldri brukes eller er feildeklarert; Kde sm ikke kan utføres (død kde); Manglende g feil lgikk, fr eksempel uendelige løkker; Fr kmpliserte knstruksjner; Avvik fra prgrammeringsstandarder; Sårbarheter (sikkerhet); Feil syntaks på kde g prgramvaremdeller. Statiske analyseverktøy blir typisk brukt av utviklere (fr å sjekke mt frhåndsdefinerte regler g prgrammeringsstandarder) før g under kmpnent- g integrasjnstesting eller når de sjekker inn kde i knfigurasjnsstyringsverktøy, g av designere under mdellering av prgramvaren. Statiske analyseverktøy kan prdusere et strt antall advarsler, g disse må styres gdt fr at verktøyene kan bli brukt effektivt. Kmpilatrer kan gså støtte statisk analyse, inklusive beregning av måleverdier. Referanser 3.2 IEEE Gilb, 1993, van Veenendal, Gilb, 1993, IEEE van Veenendal, 2004 Versin 2011 Page 36 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

37 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 4 Teknikker fr testdesign (K3) 285 minutter Læremål fr teknikker fr testdesign. Læremålene viser hva du skal kunne etter fullførelsen av hver mdul. 4.1 Testutviklingsprsessen. (K3) LO LO LO Skill mellm en testdesign spesifikasjn, testtilfelle spesifikasjn g testprsedyre. (K2) Sammenligne begrepene testbetingelse, testtilfelle g testprsedyre. (K2) Evaluere kvaliteten på testtilfeller. Innehlder de: tydelig sprbarhet til kravene frventet resultat (K2)? LO Oversette testtilfeller til en velstrukturert testprsedyre på et detaljnivå tilpasset testernes kunnskaper. (K3) 4.2 Kategrier av teknikker fr testdesign (K2) LO LO Begrunn at både spesifikasjnsbaserte (svart bks) g strukturbaserte (hvit bks) angrepsvinkler er nyttige til design av testtilfeller, samt nevn de vanligste teknikkene fr hver av dem. (K1) Frklar egenskapene til g likhetene g frskjellene mellm spesifikasjnsbasert testing, strukturbasert testing g erfaringsbasert testing. (K2) 4.3 Spesifikasjnsbaserte eller svart bks teknikker (K3) LO Skriv testtilfeller fra en gitt sftware mdell ved å bruke følgende testteknikker: (K3) ekvivalensklasseinndeling grenseverdianalyse beslutningstabelltesting tilstandsbasert testing LO LO Frklar hvedmålet med hver av de fire teknikkene, hvilket nivå g type testing sm kan bruke teknikken, g hvrdan dekning kan måles. (K2) Frklar hvedpunktene i g frdelene med brukstilfelletesting (use case testing). (K2) 4.4 Strukturbaserte eller hvit bks teknikker (K4) LO LO LO Beskriv hvedpunktene i g verdien av kdedekning. (K2) Frklar hvedpunktene i prgraminstruksjnsdekning g beslutningsdekning, samt frstå at disse teknikkene gså kan bli brukt på andre testnivåer enn kmpnenttesting (f. eks på frretningsprsedyrer på systemnivå). (K2) Skriv testtilfeller fra gitte kntrllflyt ved hjelp av å bruke følgende testteknikker: prgraminstruksjnstesting beslutningstesting. (K3) Versin 2011 Page 37 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

38 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard LO Vurder dekningsgraden til prgraminstruksjns- g beslutningsdekning i.hht. hvr fullstendig testingen er i frhld til definerte sluttkriterier. (K4) 4.5 Erfaringsbasert teknikk (K2) LO LO Gjengi grunner fr å skrive testtilfeller basert på intuisjn, erfaring g kjennskap til vanlige feil. (K1) Sammenlign erfaringsbasert teknikk med spesifikasjnsbaserte test teknikker. (K2) 4.6 Valg av test teknikker (K2) LO Klassifiser testteknikker mht. hvr egnet de er fr en gitt kntekst, sm f. eks. fr en testbasis, frskjellige mdeller g prgramvareegenskaper. (K2) Versin 2011 Page 38 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

39 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 4.1 Testutviklingsprsessen (K3) 15 minutter Begreper Spesifikasjn av testtilfelle, testdesign, kjøreplan, testprsedyre, testskript, sprbarhet. Bakgrunn Testutviklingsprsessen sm er beskrevet i denne seksjnen kan utføres på frskjellige måter, fra meget ufrmell med lite eller ingen dkumentasjn, til meget frmell (sm beskrevet under). Frmalitetsnivået er avhengig av testingens kntekst, inkludert mdenhetsnivået på testingen g utviklingsprsessen, tidsbegrensninger, sikkerhetskrav eller myndighetskrav g de invlverte persnene. Under testanalysen analyseres dkumentasjnen av testgrunnlaget fr å avklare hva sm skal testes, dvs. identifisere testbetingelsene. En testbetingelse er definert sm et bjekt eller del av bjekt sm kan bli verifisert med et eller flere testtilfeller (dvs. en funksjn, transaksjn, kvalitetsegenskap eller strukturelement). Etablering av sprbarhet fra testtilfellet tilbake til spesifikasjn g krav muliggjør både effektiv knsekvensanalyse når krav endres, samt mulighet til å fastslå dekning av krav fr et sett med tester. Under testanalysen blir den detaljerte angrepsvinkelen fr testen implementert, fr å velge den eller de testdesign teknikkene sm skal brukes basert på bl.a. identifisert risik (Se kapittel 5 fr mer m risikanalyse). Under testutviklingen blir testtilfeller g testdata skapt g spesifisert. Et testtilfelle består av et sett med inputverdier, krav til frhåndstilstand, frventede resultater g krav til avslutningstilstand definert fr å dekke utvalgte testmål eller testbetingelse(r). IEEE standarden ( Standard fr Sftware Test Dcumentatin ) beskriver innhldet av testdesignspesifikasjner (inkludert testbetingelser) g testtilfellespesifikasjn. Frventede resultater bør prduseres sm en del av spesifikasjnen til et testtilfelle g inkludere utdata (utput), endringer på data g status, g alle andre knsekvenser av testen. Hvis frventet resultat ikke er definert kan et plausibelt men feilaktig resultat bli tlket sm det krrekte. Frventet resultat skal ideelt være definert før testutførelsen. Under testimplementasjnen blir testtilfeller utviklet, implementert, priritert g rganisert i en testprsedyrespesifikasjn (IEEE ). Testprsedyren (eller manuelt testskript) spesifiserer rekkefølgen av punkter fr utførelsen av en test. Dersm tester kjøres med bruk av autmatiserte verktøy, er sekvensen av punkter spesifisert i testskript (sm er en autmatisert testprsedyre). De frskjellige testprsedyrene g autmatiserte testskripter blir deretter samlet i en kjøreplan, sm definerer den rekkefølgen de frskjellige testprsedyrene g eventuelle autmatiserte testskripter blir kjørt, når de skal kjøres g av hvem. Kjøreplanen må ta høyde fr faktrer sm regresjnstester, priritering g tekniske g lgiske avhengigheter. Versin 2011 Page 39 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

40 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 4.2 Kategrier fr teknikker fr testdesign (K2) 15 minutter Begreper Svart bks teknikk, erfaringsbasert teknikk, spesifikasjnsbasert teknikk, strukturell teknikk (hvit bks teknikk). Bakgrunn Hensikten med en testdesignteknikk er å identifisere testbetingelser, testtilfeller g testdata. Man mtaler vanligvis testdesignteknikker sm svart bks eller hvit bks (strukturell). Svart bks teknikker (gså kalt spesifikasjnsbaserte teknikker) er en måte å identifisere g velge testbetingelser eller testtilfeller basert på en analyse av dkumentasjnen av det sm skal testes. Det kan mfatte både funksjnell g ikke-funksjnell testing. Svart bks teknikker bruker ifølge sin definisjn ikke ne infrmasjn m den interne strukturen fr en kmpnent eller et system sm skal testes. Hvit bks teknikker (gså kjent sm strukturelle eller strukturbaserte teknikker) er basert på en analyse av strukturen til kmpnenten eller systemet. Både svart bks g hvit bks teknikker kan gså kmbineres med bruk av erfaringsbasert teknikker fr å utnytte erfaringene til utviklerne, testerne g brukerne fr å bestemme hva sm skal testes. Nen teknikker er tydelig innen kun en kategri; andre har elementer fra begge kategriene. Dette pensum refererer til spesifikasjnsbaserte angrepsvinkler sm svart bks teknikker g strukturbaserte sm hvit bks teknikker. I tillegg dekker det erfaringsbaserte teknikker. Vanlige egenskaper fr spesifikasjnsbaserte teknikker mfatter: Mdeller, enten frmelle eller ufrmelle, brukes fr spesifisering av prblemet sm skal løses, prgramvaren eller dens kmpnenter. Testtilfeller kan systematisk bli tatt ut fra disse mdellene. Vanlige egenskaper fr strukturbaserte teknikker mfatter: Infrmasjn m hvrdan prgramvaren er knstruert er brukt fr å ta ut testtilfeller, fr eksempel fra kde g detaljdesign. Dekningsgrad av prgramvaren kan måles fr eksisterende testtilfeller, g ekstra testtilfeller kan planlegges fr systematisk å øke dekningsgraden. Vanlige egenskaper fr erfaringsbasert teknikker mfatter: Kunnskap g erfaring til mennesker brukes fr å definere testtilfeller. Kunnskapen testere, utviklere, brukere g andre interessenter har m prgramvaren, dens bruk g miljø er en infrmasjnskilde. Kunnskap m sannsynlige feil g hvr de befinner seg er en annen infrmasjnskilde. Versin 2011 Page 40 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

41 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 4.3 Spesifikasjnsbaserte (svart bks) teknikker (K3) 150 minutter Begreper Grenseverdianalyse, beslutningstabelltesting, ekvivalensklasseinndeling, tilstandsbasert testing, brukstilfelle (use case) testing. Ordene brukstilfelle g use case er brukt i samme betydning Ekvivalensklasseinndeling (K3) Input til prgramvaren eller systemet blir delt inn i grupper sm frventes å ha lik ppførsel, g dermed sannsynligvis blir prsessert på samme måte. Ekvivalensklasser kan defineres fr både gyldige data g ugyldige data, dvs. verdier sm frventes gdtatt hhv. å bli frkastet. Ekvivalensklasser kan gså identifiseres fr utdata (utput), interne verdier, tidsrelaterte verdier (f. eks før eller etter en hendelse) g fr grensesnittparametere (altså under integrasjnstesting). Tester kan utvikles fr å dekke alle gyldige g ugyldige ekvivalensklasser. Ekvivalensklasseinndeling kan benyttes på alle nivåer av testing. Ekvivalensklasseinndeling sm en teknikk kan brukes fr å ppnå dekningsmål på inndata (input) g utdata (utput). Den kan benyttes fr menneskelig input, input via grensesnitt mt systemet, eller grensesnittparametere under integrasjnstesting Grenseverdianalyse (K3) Behandling av data sm befinner seg i grensemrådene til ekvivalensklassene har større sannsynlighet fr å være feil, så grenseverdier er et mråde der testing sannsynligvis vil finne feil. Maksimum g minimum verdier av en klasse er den klassens grenseverdier. En grenseverdi fr en gyldig klasse er en gyldig grenseverdi; grenseverdien til en ugyldig klasse er en ugyldig grenseverdi. Tester kan utvikles fr å dekke både gyldige g ugyldige grenseverdier. Når man utvikler testtilfeller, velger man en test fr hver grenseverdi. Grenseverdianalyse kan benyttes på alle testnivåer. Det er relativt enkelt å bruke g har høy sannsynlighet fr å finne feil. Detaljerte spesifikasjner er verdifulle fr å bestemme interessante grenser. Denne teknikken er fte ansett sm en utvidelse av ekvivalensklasseteknikken eller andre svart bks teknikker. Den kan brukes på ekvivalensklasser fr brukerinput på skjerm i tillegg til f.eks. på tidsintervaller (f. eks tidsavbrudd, krav til transaksjnshastighet) eller tabellintervaller (f. eks. tabellens størrelse er 256*256) Beslutningstabelltesting (K3) Beslutningstabeller er en gd måte å fange systemkrav sm innehlder lgiske valg, g fr å dkumentere intern systemdesign. De kan bli brukt til å beskrive kmplekse fretningsregler sm et system skal implementere. Spesifikasjnen blir analysert g betingelsene g handlingene blir ftest beskrevet på en slik måte at de kan enten være sann eller usann. Beslutningstabellen innehlder det utløsende valget, fte kmbinasjner av sant g usant fr alle inputvalg g de resulterende funksjnene fr hver kmbinasjn av valg. Hver klnne av tabellen tilsvarer en fretningsregel sm definerer en unik kmbinasjn av valg, sm resulterer i utførelsen av de funksjnene sm er frbundet med den spesifikke regelen. Standarden fr dekningsgrad vanligvis brukt fr beslutningstabelltesting er å ha minst en test per klnne, sm typisk medfører at en dekker alle kmbinasjner av utløsende valg. Versin 2011 Page 41 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

42 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Styrken til beslutningstabelltesting er at den lager kmbinasjner av valg sm kanskje ellers ikke ville blitt benyttet under testing. Den kan benyttes i alle situasjner der prgramvarens funksjn er avhengig av flere lgiske beslutninger Tilstandsbasert testing (K3) Et system kan ppføre seg frskjellig avhengig av nåværende tilstand eller tidligere histrie (tilstanden). I dette tilfellet kan dette aspektet av systemet illustreres sm et tilstandsdiagram. Det gjør at testeren kan vurdere prgramvaren sett ut fra dens tilstand, vergang mellm tilstander, inputverdier eller hendelser sm medfører tilstandsendringer (verganger) g de stegene sm kan resultere fra disse verganger. Tilstandene til systemet eller bjektet under test er individuelle, identifiserbare g endelige i antall. Et tilstandsdiagram viser frhldet mellm tilstand g input, g kan belyse mulige ugyldige verganger. Tester kan knstrueres fr å dekke en typisk sekvens av tilstander, fr å dekke hver eneste tilstand, fr å utføre hver vergang, fr å utføre spesielle sekvenser av verganger eller fr å teste ugyldige verganger. Tilstandsbasert testing er mye benyttet innen innebygd prgramvare g generelt innen teknisk autmatisering. Men teknikken er gså egnet fr å mdellere et fretningsmråde sm har spesifikke tilstander eller fr å teste flyten i en skjermdialg (f.eks. fr internettapplikasjner eller frretningssituasjner) Brukstilfelle (use case) testing (K2) Tester kan bli spesifisert på bakgrunn av brukstilfelle (use case). Et brukstilfelle (use case) beskriver samhandlingen mellm deltagere (brukere g subsystemer), sm prduserer et resultat av verdi til en systembruker eller kunde. Brukstilfelle kan beskrives enten på et abstrakt nivå: Frretningstilfelle, uten å nevne teknlgi, frretningsflytnivå eller på systemnivå: Brukstilfelle fr bruken av systemet på nivået til systemets funksjnalitet. Hvert brukstilfelle har frhåndsbetingelser (frutsetninger) sm må ppfylles fr at brukstilfellet skal virke rett. Hvert brukstilfelle avsluttes med en avslutningstilstand sm er det bserverbare resultatet g slutt-tilstanden til systemet etter at brukstilfellet er utført. Et brukstilfelle har vanligvis en hvedflyt (dvs. den mest sannsynlige) g alternative flyter. Brukstilfelle beskriver prsessflyten gjennm et system basert på dens faktiske sannsynlige bruk, så testtilfeller basert på dem er mest nyttige fr å avdekke feil i prsessflyten ved faktisk bruk av systemet. Brukstilfeller, fte referert til sm scenarier, er meget nyttige fr å utvikle akseptansetester med deltagelse fra kunde/bruker. De er gså nyttige fr å avdekke integrasjnsfeil frårsaket av interaksjn g innblanding fra frskjellige kmpnenter, sm testing av de individuelle kmpnentene ikke vil ppdage. En kan kmbinere knstruksjn av testtilfelle fra brukstilfelle med andre spesifikasjnsbaserte testteknikker. Versin 2011 Page 42 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

43 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 4.4 Strukturbaserte (hvit bks) teknikker (K4) 60 minutter Begreper Kdedekning, beslutnings-/frgreningsdekning, prgraminstruksjnsdekning, strukturbasert testing. Vi bruker i tillegg til de nrske de tilsvarende engelske begrepene statement cverage g branch/decisin cverage. Bakgrunn Strukturbasert testing (hvitbks testing) er basert på en identifisert struktur i prgramvaren eller systemet, slik sm i følgende eksempler: Kmpnentnivå: Strukturen i kden selv, f. eks prgraminstruksjner, beslutninger eller frgreninger eller til g med bestemte stier gjennm prgrammet. Integrasjnsnivå: Strukturen kan være et kallhierarki (et diagram der mduler kaller pp andre mduler). Systemnivå: Strukturen kan være en menystruktur, fretningsprsess eller nettsidestruktur. I dette avsnitt diskuteres t kderelaterte strukturbaserte teknikker fr kdedekning, basert på prgraminstruksjner g beslutninger. Fr beslutningstesting kan man benytte et kntrllflytdiagram fr å visualisere alternativene fr hver beslutning Prgraminstruksjnstesting g dekning (statement testing and cverage) (K3) I mdultesting er prgraminstruksjnsdekning måling av prsenten av kjørbare prgraminstruksjner sm har blitt utført av en testsuite. Prgraminstruksjnstesting utleder testtilfeller sm utfører spesifikke prgraminstruksjner, nrmalt fr å øke prgraminstruksjnsdekningen. Prgraminstruksjnsdekning beregnes ved å dele antall utførbare instruksjner dekket av knstruerte eller utførte testtilfelle med antallet av alle utførbare instruksjner i kden under test Frgrenings- / Beslutningstesting g dekning (branch r decisin testing and cverage) (K3) Beslutningsdekning, det samme sm frgreningstesting, er måling av prsenten av beslutningsresultat (dvs. Sant g Usant mulighetene i en IF-setning) sm har blitt utført av en testsuite. Beslutningstesting utleder testtilfeller sm utfører spesifikke beslutningsresultat, nrmalt fr å øke beslutningsdekningen g fr å vise kntrllflyten i de ulike stedene i kden.. Beslutningsdekning beregnes ved å dele antall beslutningsresultater dekket av knstruerte eller utførte testtilfelle med antallet av alle beslutningsresultater i kden under test. Beslutningstesting er en frm fr kntrllflyttesting siden den genererer en spesifikk kntrllflyt gjennm beslutningspunktene. Beslutningsdekning er bedre enn prgraminstruksjnsdekning:100 % beslutningsdekning garanterer 100 % prgraminstruksjnsdekning, men ikke mtsatt Andre strukturbaserte teknikker (K1) Det finnes høyere nivåer fr strukturdekning utver beslutningsdekning, f. eks betingelsesdekning (cnditin cverage) g sammensatt betingelsesdekning (multiple cnditin cverage). Versin 2011 Page 43 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

44 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Knseptet med dekningsgrad kan gså benyttes på andre testnivåer (sm på integrasjnsnivå) der prsenten av mduler, kmpnenter eller klasser sm har blitt utført av en testsuite kan bli uttrykt sm mdul-, kmpnent- eller klassedekning. Støtteverktøy er nyttige fr strukturbasert testing av kden. Versin 2011 Page 44 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

45 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 4.5 Erfaringsbaserte teknikker (K2) 30 minutter Begreper Eksplrativ testing (ufrskende testing), eng. fault attack. Bakgrunn Erfaringsbasert testing er når testene blir utledet basert på testernes kunnskap g intuisjn g deres erfaringer med lignende applikasjner g teknlgier. Når teknikken blir brukt i tillegg til systematiske teknikker kan den være nyttig fr å identifisere spesielle tester sm ikke så lett blir fanget pp av frmelle teknikker, spesielt når erfaringsbasert testing blir anvendt i tillegg til mer frmelle metder. Denne teknikken kan likevel gi en meget varierende grad av effektivitet avhengig av testernes erfaringer. En vanlig brukt erfaringsbasert teknikk er feilgjetting. Generelt frutser testere feil basert på erfaring. En strukturert tilnærmingsmåte til feilgjettingsteknikken er å spesifisere en liste av mulige feil g lage testtilfeller sm angriper disse feilene. Denne systematiske tilnærmingsmåten kalles fault attack. Disse listene ver prblemer g feil kan lages basert på erfaringer, tilgjengelige feildata g fra vanlig kunnskap m hvrfr prgramvare feiler. Eksplrativ testing er samtidig testdesign, testutførelse, testlgging g læring, basert på en testppgave sm innehlder testmål g sm utføres i fast bestemte tidsintervaller. Denne tilnærmingsmåten er mest nyttig når man har få eller mangelfulle spesifikasjner g meget strt tidspress, eller fr å supplere annen, mer frmell testing. Den kan fungere sm en sjekk på testprsessen, fr å sikre at de mest alvrlige feil blir funnet. Versin 2011 Page 45 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

46 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 4.6 Valg av testteknikker (K2) 15 minutter Begreper Ingen spesifikke begreper. Bakgrunn Valg av testteknikker er avhengig av flere faktrer, inkludert typen system, pålagte standarder, kunde- eller kntraktskrav, risiknivå, typen risik, testmål, tilgjengelig dkumentasjn, kunnskapen til testerne, tid g budsjett, utviklingslivssyklus, brukstilfelle (use case) mdeller g tidligere erfaringer med feiltypene sm finnes. Nen teknikker er mer egnet i spesielle situasjner g testnivåer; andre kan benyttes på alle testnivåer. Testere bruker vanligvis en kmbinasjn av testteknikker når de lager testtilfelle. De bruker prsessdrevne, regeldrevne g datadrevne teknikker fr å sikre passende dekning av testbjektet. Referanser 4.1 Craig, 2002, Hetzel, 1988, IEEE Standard Beizer, 1990, Cpeland, Cpeland, 2004, Myers, Cpeland, 2004, Myers, Beizer, 1990, Cpeland, Beizer, 1990, Cpeland, Cpeland, Beizer, 1990, Cpeland, Kaner, Beizer, 1990, Cpeland, 2004 Versin 2011 Page 46 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

47 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 5 Testledelse (K3) 170 minutter Læremål fr testledelse Målene identifiserer hva du skal være i stand til etter å ha gjennmgått hver mdul. 5.1 Testrganisasjn (K2) LO LO LO LO Vite m viktigheten av uavhengig testing. (K1) Liste pp frdelene g ulempene med uavhengig testing i en rganisasjn. (K2) Kjenne til de ulike typer medarbeidere en behøver fr å sette sammen en testgruppe. (K1) Kjenne de typiske ppgavene fr en testleder g tester. (K1) 5.2 Testplanlegging g estimering (K3) LO LO LO LO LO LO LO LO LO Kjenne de ulike nivåer g mål av testplanlegging. (K1) Oppsummere frmål g innhld av en testplan, testdesignspesifikasjn g testprsedyredkumenter i samsvar med Standard fr Sftware Test Dcumentatin (IEEE ). (K2) Skille mellm knseptuelt ulike teststrategier, sm analytisk, mdellbasert, metdisk, i samsvar med prsess/standard, dynamisk/heuristisk, knsultativ g regresjnsbekjempende. (K2) Skille mellm testplanleggingen fr et system g tidsplanleggingen fr testutførelsen. (K2) Skrive en tidsplan fr testutførelse fr et gitt sett med testtilfeller, ved å ta hensyn til priritering g tekniske g lgiske avhengigheter. (K3) Liste testfrberedelses- g utførelsesaktiviteter sm bør vurderes under testplanlegging. (K1) Kjenne typiske faktrer sm har innflytelse på arbeidsmengden til testing. (K1) Skille mellm t knseptuelt ulike estimeringsmetder: basert på måledata g basert på ekspertviten. (K2) Kjenne til/begrunne passende sluttkriterier fr spesifikke testnivåer g grupper av testtilfeller (fr eksempel fr integrasjnstesting, akseptansetesting eller testtilfelle fr brukbarhetstesting). (K2) 5.3 Overvåking g kntrll av testfremdrift (K2) LO LO LO Kjenne til vanlige måledata brukt fr å følge pp testfrberedelse g utførelse. (K1) Frstå g tlke måledata fra testing fr testrapprtering g styring av testingen (fr eksempel feil funnet g rettet, g tester sm gikk bra eller ikke) relatert til målsetninger g bruk. (K2) Oppsummere mål med g innhld i en testsluttrapprt i henhld til Standard fr Sftware Test Dcumentatin (IEEE ). (K2) 5.4 Knfigurasjnsstyring (K2) LO Oppsummere hvrdan knfigurasjnsstyring understøtter testing. (K2) 5.5 Risik g testing (K2) LO LO LO LO Beskrive en risik sm et mulig prblem sm ville true ppnåelsen av en eller flere interessenters mål med prsjektet. (K2) Huske at risiker er bestemt ved sannsynlighet fr en hendelse g dens følger (skade sm følge av at det skjer). (K1) Skille mellm prsjektrisiker g prduktrisiker. (K2) Kjenne typiske prsjektrisiker g prduktrisiker. (K1) Versin 2011 Page 47 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

48 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard LO Beskrive ved hjelp av eksempler, hvrdan risikanalyse g risikstyring kan brukes under planlegging av testingen. (K2) 5.6 Hendelses- g feilstyring (K3) LO LO Kjenne innhldet i en hendelsesrapprt i samsvar med Standard fr Sftware Test Dcumentatin (IEEE ). (K1) Skrive en hendelsesrapprt ved ppdagelsen av en feil under testing. (K3) Versin 2011 Page 48 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

49 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 5.1 Testrganisasjn (K2) 30 minutter Begreper Tester, testleder Testrganisasjn g uavhengighet (K2) En kan øke effektiviteten med å finne feil under test g granskninger ved å bruke uavhengige testere. Ulike grader av uavhengighet er: Ingen uavhengige testere. Utviklere tester sin egen kde. Uavhengige testere innenfr utviklingsgrupper. Uavhengig testgruppe i rganisasjnen med rapprtering til prsjektledelse eller linjeledelse. Uavhengige testere fra frretningsrganisasjnen eller brukergruppen. Uavhengige testspesialister fr spesifikke testmål sm brukbarhetstestere, sikkerhetstestere eller sertifiseringstestere (sm sertifiserer et prgramvareprdukt mt standarder g regler). Uavhengige testere sm er underleverandører eller eksterne i frhld til rganisasjnen. Fr stre, kmplekse eller sikkerhetskritiske prsjekter er det vanligvis best å ha flere nivå av testing, hvr nen eller alle nivå utføres av uavhengige testere. Utviklingspersnale kan delta i testingen, spesielt på de lavere nivåene, men deres mangel på bjektivitet begrenser fte deres effektivitet. Uavhengige testere kan ha autriteten til å kreve, g definere, testprsesser, standarder g regler. Testere bør dg ikke ta slike prsessrelaterte rller med mindre et klart mandat fra ledelsen er tilstede. Frdelene med uavhengighet mfatter: Uavhengige testere ser andre g ulike feil, g er ikke frutinntatt. En uavhengig tester kan verifisere antagelser sm flk gjrde under spesifikasjn g implementasjn av systemet. Ulemper mfatter: Islasjn fra utviklingsgruppen (hvis testerne blir behandlet sm ttalt uavhengige). Uavhengige testere kan bli ansett sm en flaskehals dersm de er siste sjekkpunkt, g de kan bli beskyldt fr å frsinke frigivelsen. Utviklere kan miste ansvarsfølelsen fr kvaliteten. Uavhengige testere må lære seg systemet g/eller fagfeltet (dette punktet er ikke nevnt i den engelske versjnen av pensum). Testppgaver kan utføres av flk i en spesiell testrlle eller av persner i andre rller, sm fr eksempel prsjektleder, kvalitetsleder, utvikler, frretnings- eller anvendelsesekspert eller av flk i IT-drift eller infrastruktur Testerens g testlederens ppgaver (K1) I dette pensum dekkes t testrller, testleder g tester. Aktivitetene g ppgavene sm persner i disse t rller utfører, avhenger av prsjektets g prduktets kntekst, persnene i rllene g rganisasjnen. Nen ganger blir testlederen kalt testmanager eller testkrdinatr. Testlederrllen kan utføres av en prsjektleder, utviklingsleder, kvalitetsleder eller lederen fr en testgruppe. I stre prsjekter kan Versin 2011 Page 49 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

50 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard testlederrllen være ppdelt i flere nivåer. Typisk vil en testleder planlegge, følge pp g styre testaktivitetene sm er definert i avsnitt 1.4. Typiske testlederppgaver kan mfatte: Krdinere teststrategi g plan med prsjektledere g andre. Skrive eller gjennmgå en teststrategi fr prsjektet, g testplicy fr rganisasjnen. Bidra med testperspektivet til andre prsjektaktiviteter, sm integrasjnsplanlegging. Planlegge testene ved å ta hensyn til kntekst, testmålsetninger g risiker inklusive å velge teststrategier, å estimere tiden, arbeidsmengden g kstnaden av testing, å få tak i ressurser, å definere testnivåer g testsykluser, g å planlegge hendelseshåndteringen. Starte pp spesifikasjn, frberedelse, implementering g utføringen av tester, vervåke testresultater g sjekke sluttkriterier. Tilpasse planleggingen på basis av testresultater g framdrift (nen ganger dkumentert i statusrapprter) g freta enhver handling sm behøves fr å mtvirke prblemer. Sette pp passende knfigurasjnsstyring av testmateriale fr sprbarhet. Innføre passende måledata fr å måle testframdrift g fr å evaluere kvaliteten av testingen g prduktet. Beslutte hva sm skal bli autmatisert, i hvilken utstrekning g hvrdan. Velge ut verktøy fr å støtte testingen g rganisere enhver pplæring i bruk av verktøy fr testerne. Ta beslutninger mkring implementeringen av testmiljøet. Skrive sluttrapprter fra testingen basert på infrmasjn sm er samlet under testing. Typiske ppgaver fr en tester kan mfatte: Gjennmgå g bidra til testplaner. Analysere, gjennmgå g bedømme brukerkrav, spesifikasjner g mdeller vedrørende testbarhet. Lage testspesifikasjner. Sette pp testmiljø (fte krdinert med systemfrvaltning g nettverksadministrasjn). Frberede g fremskaffe testdata. Implementere tester på alle nivåer, utføre g lgge disse, evaluere resultater g dkumentere avvik fra frventede resultater. Bruke verktøy fr testadministrasjn eller testledelse samt verktøy fr ppfølging av testingen sm påkrevd. Autmatisere tester (dette kan være støttet av en utvikler eller en autmatiseringsekspert). Måle ytelse av kmpnenter g system (hvr det passer). Gjennmgå tester sm er utviklet av andre. Persner sm arbeider med testanalyse, testdesign, spesifikke testtyper eller testautmatisering kan være spesialisert i disse rllene. Avhengig av testnivå g risik ved prdukt g prsjekt kan ulike persner verta rllen sm testere, med ulike grader av uavhengighet. Typiske testere på kmpnent- g integrasjnsnivå er utviklere, testere på akseptansetestnivå er eksperter på anvendelsesmråde g brukere, g testere fr driftsakseptansetesting er peratører.. Versin 2011 Page 50 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

51 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 5.2 Test planlegging g estimering (K3) 40 minutter Begreper Testmetde, teststrategi Testplanlegging (K2) Dette avsnitt dekker testplanleggingens frmål i utviklings- g implementeringsprsjekter, g fr vedlikehldsaktiviteter. Planlegging kan dkumenteres i en verrdnet testplan, g i separate testplaner fr de enkelte testnivåene sm systemtesting eller akseptansetesting. Maler til innhld i testplaner er gitt i Standard fr Sftware Test Dcumentatin (IEEE ). En rganisasjns testplitikk, testingens mfang, mål, risiker, begrensninger, kritikalitet, testbarhet g tilgjengelighet til ressurser har innflytelse på dens testplanlegging. J mer prsjektet g testplanleggingen skrider fram, dest mer infrmasjn er tilgjengelig g dest mer detaljer kan inkluderes i planen. Testplanlegging er en kntinuerlig aktivitet g blir utført i alle livssyklusprsesser g aktiviteter. Tilbakemelding fra testaktiviteter blir brukt fr å ppfatte endringer i risikbildet slik at planleggingen kan tilpasses Testplanleggingsaktiviteter (K2) Testplanlegging fr et helt system eller et delsystem kan mfatte: Å bestemme mfang g risik, g identifisere målene fr testingen. Å definere den ttale strategien eller metden fr testingen, inklusive definisjnen av testnivåer, samt start- g sluttkriterier. Å integrere g krdinere testaktivitetene med livssyklusaktivitetene til prgramvaren: Kjøp, leveranse, utvikling, drift g vedlikehld. Å beslutte hva en skal teste, hvilke rller sm skal utføre testaktivitetene, hvrdan disse bør utføres g hvrdan en skal evaluere testresultater. Å planlegge tidspunkt fr testanalyse g designaktiviteter. Å planlegge tidspunkter fr testimplementering, utførelse g evaluering. Å tildele ressurser til de ulike definerte aktivitetene. Å definere mfang, detaljnivå, struktur g maler fr testdkumentasjn. A velge måledata fr å følge pp g styre testfrberedelse g utførelse, feilretting g risik. Å sette detaljnivået fr testprsedyrer fr å gi nk infrmasjn til å understøtte reprduserbar testfrberedelse g utføring Startkriterier (K2) Startkriterier definerer når en kan starte testingen, sm fr eksempel et testnivå eller når en samling tester er klar fr utføring. Typisk kan startkriterier dekke følgende: At testmiljø er klart g tilgjengelig At testverktøy er klare i testmiljøet At testbar kde er tilgjenglig At testdata er tilgjengelige Versin 2011 Page 51 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

52 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Sluttkriterier (K2) Hensikten med sluttkriterier er å definere når en kan avslutte testingen, sm fr eksempel på slutten av et testnivå eller når en samling tester har ppnådd et spesifikt mål. Typiske sluttkriterier kan bestå av: Grundighetsmål, sm kdedekning, funksjnsdekning eller risik. Estimater av feiltetthet eller pålitelighetsmål. Kstnad. Gjenværende risiker, sm ikke rettede feil eller mangel på testdekning i visse mråder. Tidsplaner sm er basert på prduksjnssettingsdat Testestimering (K2) T metder fr estimering av testarbeidet er dekket i pensum: Basert på måledata: Å estimere testarbeidet på grunnlag av måledata fra tidligere eller liknende prsjekter eller basert på typiske verdier, Ekspertbasert: Å estimere ppgavene ved at den sm skal ha ansvaret fr ppgavene eller eksperter estimerer. Når testarbeidet er estimert kan en identifisere ressurser g lage en tidsplan. Testarbeidets mfang kan avhenge av en rekke faktrer, inklusive: Prduktegenskaper: Kvaliteten til spesifikasjnen g annen infrmasjn sm brukes fr testmdellene (dvs. testgrunnlaget), prduktets størrelse, prblemmrådets kmpleksitet, kravene til pålitelighet g sikkerhet, g krav til dkumentasjn. Utviklingsprsessens egenskaper: Organisasjnens stabilitet, verktøy sm blir brukt, testprsessen, medarbeidernes ferdigheter, g tidspress. Testresultatet: Antall feil g mfang av gjentatt arbeid sm kreves Teststrategier g testmetder (K2) Testmetden er realiseringen av teststrategien fr et spesifikt prsjekt. Testmetden blir definert g detaljert i testplanene g testdesign. Typisk innehlder den beslutningene sm er tatt på grunnlag av prsjektets mål g risikbedømmelse. Den er utgangspunkt fr å planlegge testprsessen, fr å velge teknikker fr testdesign g testtyper sm skal brukes g fr å definere start- g sluttkriterier. Metden sm velges avhenger av sammenhengen g en kan ta hensyn til risik, farer g sikkerhet, tilgjengelige ressurser g evner, teknlgi, systemets natur (fr eksempel spesielt bygget eller standardsystem), testmål g lver g frskrifter. Typiske metder mfatter følgende metder: Analytiske metder, sm risikbasert testing der testing blir rettet mt mrådene med størst risik. Mdellbaserte metder, sm fr eksempel tilfeldig stikkprøvetesting ved bruk av statistisk infrmasjn m feilrater (sm pålitelighetsmdeller) eller bruk (sm bruksprfiler). Metdiske metder, sm feilbasert (inkludert feilgjetting g angrep basert på feil), erfaringsbasert, sjekklistebasert g kvalitetsegenskapsbasert. Prsess- eller standardknfrme metder, sm de sm er spesifisert i bransjestandarder. Versin 2011 Page 52 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

53 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Dynamiske eller heuristiske metder, sm eksplrativ testing (ufrskende testing) eller ulike agile metder der testing er mer reaktiv til hendelser enn planlagt på frhånd, g der utføring g evaluering skjer samtidig. Knsultative metder, sm slike der testdekning er frtrinnsvis drevet av råd g veiledning fra teknlgiske eksperter g/eller frretningseksperter utenfr testgruppen. Regresjnsbekjempende metder, sm de sm mfatter gjenbruk av eksisterende testmateriale, mfattende autmatisering av funksjnelle regresjnstester, g standard testsuiter. Ulike metder kan kmbineres, fr eksempel, en risikbasert dynamisk metde. Versin 2011 Page 53 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

54 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 5.3 Overvåking g kntrll av testframdriften (K2) 20 minutter Begreper Feiltetthet, feilrate, teststyring, testppfølging, testrapprt Oppfølging av testframdrift (K1) Frmålet med å følge pp testen er å gi tilbakemelding g synlighet mkring testaktiviteter. Infrmasjnen sm skal følges pp kan samles manuelt eller autmatisk g kan brukes fr å måle sluttkriterier sm fr eksempel testdekning. Måledata g metrikker kan gså brukes til å bedømme framdrift i frhld til tidsplan g budsjett. Vanlige måledata mfatter: Prsent arbeid utført i frberedelse av testtilfelle (eller prsent av planlagte testtilfelle frberedt). Prsent arbeid utført i frberedelse av testmiljø. Utføring av testtilfelle (fr eksempel antall testtilfelle utført eller ikke g antall testtilfelle kjørt med rett eller feil resultat). Infrmasjn m feil (fr eksempel feiltetthet, feil funnet g rettet, feilrate g resultatene av frnyet test). Testdekning mt krav eller andre parameter. Testernes subjektive tillit til prduktet. Dat fr testmilepæler. Testkstnader, inklusive kstnad sammenlignet med nytteverdien av å finne den neste feilen eller å kjøre den neste testen Testrapprtering (K2) Testrapprtering dreier seg m å ppsummere infrmasjn m testingen, inklusive: Hva skjedde under testingen, sm dat når sluttkriterier ble ppfylt. Analysert infrmasjn g måledata fr å støtte anbefalinger g beslutninger m framtidige handlinger, sm å bedømme feil sm er igjen, den øknmiske nytten av frtsatt testing, frtsatt eksisterende risiker, g tiltren til den testede prgramvaren. Innhldsfrtegnelsen til en sluttrapprt fra testingen er gitt i Standard fr Sftware Test Dcumentatin (IEEE ). Måledata bør samles under testingen g ved slutten av et testnivå fr å bedømme: Om testmålene til testnivået var passende. Om tilnærmingen til testen var passende. Effektiviteten av testingen mht. dens mål Teststyring (K2) Teststyring beskriver enhver beslutning eller endring gjrt sm et resultat av infrmasjn g måledata sm er samlet g rapprtert. Handlingene kan gjelde enhver testaktivitet g kan ha innflytelse på enhver annen livssyklusaktivitet eller ppgave fr prgramvaren. Eksempler fr teststyringshandlinger er: Å ta beslutninger basert på infrmasjn fra testppfølgingen. Å mpriritere tester når en identifisert risik ppstår (fr eksempel at prgramvaren blir levert frsinket). Å endre tidsplanen fr testingen på grunn av (u)tilgjengeligheten til et testmiljø. Versin 2011 Page 54 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

55 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Å sette et startkriterium sm krever at feilrettinger har blitt testet m igjen av en utvikler før de blir akseptert i en build (bygg). Versin 2011 Page 55 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

56 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 5.4 Knfigurasjnsstyring (K2) 10 minutter Begreper Knfigurasjnsstyring, versjnskntrll Bakgrunn Målet med knfigurasjnsstyring er å etablere g vedlikehlde integriteten til prduktene (kmpnentene, data g dkumentasjn) sm tilhører prgramvaren eller systemet gjennm prsjektets eller prduktets livssyklus. Fr testing kan knfigurasjnsstyring bety at: alle deler av testmateriale er identifisert g underlagt versjnskntrll, at endringer er styrt, at det finnes infrmasjn m hvrdan delene hører til hverandre g til det sm er utviklet (testbjektene), slik at sprbarhet kan ppretthldes gjennm testprsessen. alle identifiserte dkumenter g utviklingsprdukter er entydig identifisert i testdkumentasjnen. Fr testeren hjelper knfigurasjnsstyring å entydig identifisere g reprdusere hva sm er testet, testdkumentene, testene g testrammen(e). Prsedyrer g infrastruktur (verktøy) fr knfigurasjnsstyring bør velges, dkumenteres g implementeres under testplanleggingen. Versin 2011 Page 56 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

57 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 5.5 Risik g testing (K2) 30 minutter Begreper Prduktrisik, prsjektrisik, risik, risikbasert testing Bakgrunn Risik kan defineres sm muligheten fr at en hendelse, fare, trussel eller situasjn vil inntre samt dens uønskede knsekvenser, altså et mulig prblem. Risiknivået bestemmes av sannsynligheten fr at en negativ hendelse inntrer g følgen av denne Prsjektrisiker (K2) Prsjektrisiker er de risikelementene sm kan påvirke et prsjekts evne til å levere dets mål, sm fr eksempel: Organisatriske faktrer: Knapphet på kunnskap, pplæring, persnale g evner; Prblemer med persnale; Plitiske prblemer sm fr eksempel Prblemer fr testere å frmidle deres behv g testenes resultater; Ingen ppfølging av infrmasjn funnet under test g granskninger (fr eksempel ingen frbedring av utviklings- eller testpraksis). Dårlig hldning eller feil frventning til testing (fr eksempel å ikke se verdien av at feil blir funnet under testing). Tekniske faktrer: Prblemer med å definere de riktige krav; Hvr vidt kravene ikke kan ppfylles under gitte mstendigheter g restriksjner; Testmgivelsen er ikke ferdig tidlig nk; Fr sen dataknvertering, planlegging av migrering g verktøy fr å knvertere eller migrere data til utvikling g test; Kvaliteten av design, kde, testdata g testtilfeller. Leverandørfaktrer: Prblemer hs en tredje part (underleverandør); Prblemer med kntrakter. Ved analyse, styring g behandling av slike risiker følger testlederen veletablerte prinsipper fr prsjektledelse. Standarden IEEE Standard fr Sftware Test Dcumentatin krever at risiker g aksjner fr å behandle dem blir nevnt Prduktrisiker (K2) Ptensielle mråder sm kan feile (negative hendelser i framtiden eller farer) i prgramvaren eller systemet er kjent sm prduktrisiker, frdi de er en risik til prduktkvaliteten, sm fr eksempel: Feilbefengt prgramvare sm er levert. Muligheten fr at prgramvaren/plattfrmen kan frvlde skade på persn eller bedrift. Dårlige prgramvareegenskaper (sm funksjnalitet, pålitelighet, brukbarhet g ytelse). Dårlig dataintegritet g kvalitet (fr eksempel prblemer med datamigrering, knvertering, transprt, avvik fra datastandarder) Prgramvare sm ikke ufører de ønskede funksjner. Versin 2011 Page 57 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

58 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Risiker blir brukt fr å beslutte hvr en skal starte testingen g hvr en skal teste mer eller mindre. Testingen brukes til å redusere risiken fr at en negativ hendelse skjer, eller til å redusere effekten av en slik hendelse. Prduktrisiker er en spesiell type risik fr prsjektets suksess. Testing sm risikstyring gir tilbakemelding på den resterende risiken ved å måle effekten av at kritiske feil fjernes g av alternative planer sm er brukt. En risikbasert tilnærming til testing gir praktive muligheter til å redusere nivået av prduktrisik, g den kan begynne ved prsjektppstart. Den mfatter identifikasjn av prduktrisiker til bruk fr å lede planlegging g styring, spesifikasjn, frberedelse g utføring av testene. Ved en risikbasert tilnærming kan de identifiserte risiker brukes til å: Bestemme testteknikkene sm skal brukes. Bestemme hvr mye test sm skal utføres. Priritere testingen i et frsøk på å finne de kritiske feil så tidlig sm mulig. Bestemme m aktiviteter sm ikke er del av testingen kan brukes til å redusere risiken (fr eksempel å sørge fr pplæring til uerfarne utviklere). Risikbasert testing trekker på den kllektive kunnskapen til de invlverte i et prsjekt fr å bestemme risiker g hvr mye testing sm kreves fr å møte disse risiker. Fr å sikre at sannsynligheten fr at prsjektet mislykkes blir minimert, gir risikstyringsaktiviteter en disiplinert tilnærming til å: bedømme (g bedømme m igjen regelmessig) hva sm kan gå galt (risik). bestemme hvilke risiker sm er viktige å håndtere. gjennmføre tiltak fr å håndtere disse risiker. I tillegg kan testing hjelpe med å identifisere nye risiker, hvilke risiker sm burde reduseres, g redusere usikkerheten mkring risiker. Versin 2011 Page 58 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

59 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 5.6 Hendelses- g feilhåndtering (K3) 40 minutter Begreper Hendelsesregistrering, feilregistrering, feilhåndtering, hendelseshåndtering, hendelsesrapprt Bakgrunn Frdi et av målene med testingen er å finne feil, må avvikene mellm virkelige g frventede utdata g tilstander registreres sm hendelser. En hendelse må undersøkes g kan da vise seg å være en feil. Passende tiltak fr å behandle hendelser g feil må defineres. Hendelser g feil må frfølges fra de blir ppdaget g klassifisert til de er krrigert g løsningen er kntrllert g funnet rett. Fr å kunne håndtere alle hendelser til de er avsluttet bør en rganisasjn etablere en prsess fr hendelseshåndtering g regler fr klassifisering. Hendelser kan registreres under utvikling, granskning, testing eller bruk av prgramvareprduktet. De kan registreres fr saker i kden eller systemet, eller i enhver type dkumentasjn sm mfatter krav, utviklingsdkumenter, testdkumenter g brukerinfrmasjn sm hjelp eller installasjnsveiledning. Hendelsesrapprter har følgende mål: Å gi tilbakemelding til utviklere g andre invlverte m et prblem fr å muliggjøre identifikasjn, islering g retting sm nødvendig. Å gi testledere en mulighet til å følge pp kvaliteten til systemet under test g testingens framskritt. Å gi ideer til frbedring av testprsessen. Bemerkning (bare i nrsk versjn av denne pensumlisten): Ordet hendelse brukes fr å betegne en sak sm behøver undersøkelse, men der en ikke er sikker på m det er en feil. Det kan gså være et prblem i f.eks. testmaterialet. Detaljer i en hendelsesrapprt kan mfatte: Dat, rganisasjn g frfatter sm skriver rapprten. Frventede g virkelige resultater. Identifikasjn av testbjektet (knfigurasjnselementet) g mgivelsen. Sftware- eller systemlivssyklusprsess sm hendelsen ble bservert i. Beskrivelsen av hendelsen fr å muliggjøre gjenskapelse g retting, ne sm kan inkludere lgger, kpier av databasen eller kpier av skjermbilder. Omfang eller virkning på den rapprterende parts eller andres interesser. Alvrligheten av feilens følger fr systemet. Hvr mye det haster med rettelsen. Status av hendelsen (fr eksempel åpen, utsatt, duplisert, venter på rettelse, rettet men ikke retestet, lukket). Slutninger, anbefalinger g gdkjenninger. Glbale frhld, sm fr eksempel at endringen sm kmmer fra en hendelse kan ha virkninger på andre mråder. Endringshistrie, sm viser rekkefølgen av handlingene fretatt av prsjektgruppens medlemmer med hensyn til hendelsen fr å islere, rette g sjekke den, g vise at den er rettet. Referanser, inklusive identifikasjnen av testtilfelle(ne) sm avslørte prblemet. Strukturen til en hendelsesrapprt er gså dekket i Standard fr Sftware Test Dcumentatin (IEEE ). Versin 2011 Page 59 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

60 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Referanser Black, 2001, Hetzel, Black, 2001, Hetzel, Black, 2001, Craig, 2002, IEEE , Kaner Black, 2001, Craig, 2002, Hetzel, 1988, IEEE Craig, Black, 2001, IEEE Black, 2001, IEEE Versin 2011 Page 60 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

61 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 6 Verktøystøtte til test (K2) 80 minutter Læremål fr verktøystøtte til test Læremålene viser hva du skal være i stand til etter fullførelsen av hver mdul. 6.1 Typer testverktøy (K2) LO LO Klassifisere frskjellige typer testverktøy i henhld til deres ppgaver g aktivitetene i den fundamentale testprsessen g i prgramvarens livssyklus. (K2) Frklare termen testverktøy g frmålet med verktøystøtte i testing. (K2) 6.2 Effektiv bruk av verktøy: mulige frdeler g risiker (K2) LO LO Oppsummere mulige nytteeffekter g risiker ved testautmatisering g verktøystøtte fr testing. (K2) Huske spesielle vurderinger fr verktøy fr testutføring, statisk analyse, testadministrasjn g testledelse. (K1) 6.3 Intrduksjn av et verktøy i en rganisasjn (K1) LO LO LO Oppgi hvedprinsippene fr å intrdusere et verktøy i en rganisasjn. (K1) Oppgi målene fr prf-f-cncept fr verktøyevaluering, g fr piltfasen fr å implementere/driftsette verktøyet. (K1) Vite at det kreves mer enn anskaffelse av et verktøy fr å ppnå gd verktøystøtte. (K1) Versin 2011 Page 61 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

62 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 6.1 Typer testverktøy (K2) 45 minutter Begreper Knfigurasjnsstyringsverktøy, dekningsverktøy, debuggings-/avlusningsverktøy, dynamisk analyseverktøy, hendelses-/feilhåndteringsverktøy, lasttestverktøy, mdelleringsverktøy, vervåkningsverktøy, ytelsestestverktøy, prbeeffekt/instrumenteringseffekt/verktøyeffekt, kravhåndteringsverktøy, granskningsverktøy, sikkerhetsverktøy, statisk analyseverktøy, stresstestingsverktøy, sammenligningsverktøy, testdata frberedelsesverktøy, testdesignverktøy, testramme (stubber, drivere), testutføringsverktøy, testadministrasjnsverktøy, testrammeverktøy fr kmpnenttest Frstå mål g mening med verktøystøtte fr testing (K2) Testverktøy kan benyttes i flere testrelaterte aktiviteter. Slike verktøy kan være: 1. Verktøy sm direkte benyttes til testing, sm testutføringsverktøy, verktøy fr å generere testdata g sammenligningsverktøy. 2. Verktøy sm hjelper til å administrere testprsessen, slik sm å håndtere tester, testresultater, data, krav, hendelser, defekter etc. g fr å rapprtere g vervåke testutføringen. 3. Verktøy sm er brukt i rekgnsering, eller utfrsking g leting (fr eksempel verktøy sm vervåker filaktiviteten til en applikasjn). 4. Ethvert verktøy sm er et hjelpemiddel i testingen (et regneark er gså et testverktøy i denne sammenheng). Verktøystøtte til testing kan ha ett eller flere frmål avhengig av knteksten: Frbedre effektiviteten av testaktivitetene ved å autmatisere gjentagende ppgaver eller å støtte manuelle testaktiviteter sm testplanlegging, testdesign, testrapprtering g vervåking. Autmatisere aktiviteter sm krever vesentlige ressurser når de utføres manuelt (fr eksempel statisk testing). Autmatisere aktiviteter sm ikke kan utføres manuelt (fr eksempel strskala ytelsestesting av klient-tjener applikasjner). Øke pålitelighet av testingen (fr eksempel ved å autmatisere stre datasammenligninger eller å simulere en ppførsel). Fr dette pensumet benyttes testrammeverk iht. punktene Testutføringsverktøy g Testrammeverktøy/Rammeverk fr enhetstest (U) sm beskrevet i seksjn Fr øvrig bruker industrien termen testrammeverk gså til minst tre andre frmål: Gjenbrukbare g utvidbare testbiblitek sm kan bli benyttet til å bygge testverktøy (gså kalt testramme) En type av design av autmatiserte tester (fr eksempel datadrevet, nøkkelrddrevet) Samlet prsess fr utføring av tester Klassifisering av testverktøy (K2) Det finnes en rekke verktøy sm støtter frskjellige aspekter ved testing. Verktøy kan klassifiseres basert på frskjellige kriterier sm frmål, lisensiering (kmmersiell / gratis / pen-surce / shareware), brukt teknlgi sv. I dette pensumet er verktøy klassifisert i henhld til de testaktiviteter verktøyene støtter. Nen verktøy støtter tydelig én bestemt aktivitet, andre kan støtte flere aktiviteter. De blir klassifisert under den aktivitet de er nærmest asssiert med. Verktøy fra en enkel leverandør, spesielt de verktøy sm er designet til å fungere sammen, kan bli samlet i en felles verktøypakke/suite. Versin 2011 Page 62 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

63 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Nen typer verktøy kan være invaderende, eller påtrengende, ved at verktøyet selv har effekt på testresultatet. Fr eksempel kan utførelsestidspunkter være frskjellig pga. ekstra kde sm utføres av verktøyet, eller en kan få ulike verdier fr kdedekning avhengig av hva slags verktøy fr dekningsmåling en bruker. Knsekvensen av påtrengende verktøy kalles verktøyeffekten eller instrumenteringseffekten. Nen verktøy tilbyr støtte mer tilpasset utviklere (fr eksempel ved kmpnent g kmpnent integrasjns testing). Slike verktøy er merket med (U) i listen under Verktøystøtte fr administrasjn av testing g tester (K1) Administrasjnsverktøy støtter alle testaktiviteter gjennm hele prgramvarens livssyklus. Testadministrasjnsverktøy Disse verktøyene tilbyr grensesnitt fr å utføre tester, spre feil g håndtere krav samtidig med å støtte kvantitativ analyse g rapprtering av testbjektene. De støtter gså det å spre testbjektene til kravspesifikasjnene g kan ha uavhengig mulighet fr versjnskntrll eller et grensesnitt til et eksternt verktøy fr versjnskntrll. Kravhåndteringsverktøy Disse verktøyene lagrer kravbeskrivelser, lagrer attributter til krav (inklusive priritet), tilbyr unike identifikatrer g støtter spring av krav til individuelle tester. Disse verktøyene kan gså hjelpe til å identifisere inknsistente eller manglende krav. Feil-/Hendelseshåndteringsverktøy Disse verktøyene lagrer g håndterer avviks-/hendelsesrapprter, dvs. defekter, feil, endringsønsker eller antatte prblemer g anmalier/avvik, g hjelper til i å håndtere livssyklusen til hendelsene, med mulig støtte til statistisk analyse. Knfigurasjnsstyringsverktøy Selv m disse ikke er direkte testverktøy så er disse verktøyene nødvendig fr å lagre g styre versjnering av testware g relatert prgramvare spesielt ved knfigurering av mer enn ett maskinvare/prgramvare miljø i frm av versjn av perativsystem, kmpilatrer, weblesere, etc Verktøystøtte fr statisk testing (K1) Verktøy fr statisk testing tilbyr en kstnadseffektiv måte å finne flere defekter på i en tidlig fase i utviklingsprsessen. Granskningsverktøy Disse verktøyene gir støtte til granskningsprsessen, sjekklister, guider fr granskningen g er brukt til å lagre g kmmunisere granskningskmmentarer, rapprtere avvik g innsats/frbruk. De kan i tillegg hjelpe til å støtte nline granskninger fr stre eller gegrafisk atskilte team. Statiske analyseverktøy (U) Disse verktøyene hjelper utviklere g testere til å finne defekter før dynamisk testing ved å tilby støtte til å håndheve kdestandarder (inkludert sikker kding), analyse av strukturer g avhengigheter. De kan gså hjelpe i planlegging eller risikanalyse ved å tilby metrikker fr kden (fr eksempel kmpleksitet). Mdelleringsverktøy (U) Disse verktøyene er brukt til å validere prgramvaremdeller (fr eksempel fysiske datamdeller (PDM) fr en relasjnsdatabase), ved å liste pp inknsistenser g å finne defekter. Disse verktøyene kan fte hjelpe til å generere testtilfelle basert på mdellen. Versin 2011 Page 63 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

64 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Verktøystøtte fr testspesifikasjn (K1) Testdesignverktøy Disse verktøyene brukes til å generere inputdata til tester eller eksekverbare tester g/eller testrakler fra krav, grafiske brukergrensesnitt, designmdeller (tilstand, data eller bjekt) eller kde. Verktøy sm hjelper med frberedelse av testdata Slike verktøy manipulerer databaser, filer eller dataverføringer fr å sette pp testdata til bruk i utføring av tester fr blant annet å verne m sikkerhet gjennm annymiserte data Verktøystøtte fr testutføring g lgging (K1) Testutføringsverktøy Testutføringsverktøy gjør det mulig å utføre tester helt eller delvis autmatisk ved bruk av lagrede inputdata g frventede resultater med et skriptspråk g tilbyr vanligvis en testlgg fr hver testkjøring. De kan gså benyttes til å gjøre pptak av en test g tilbyr nrmalt et skriptspråk eller en GUI-basert knfigurering g parameterisering av data g annen tilpasning av testene. Testrammeverktøy/Rammeverk fr enhetstest (U) En testramme eller testrammeverk frenkler testing av kmpnenter eller deler av et system ved å simulere miljøet sm bjektet kjører i med bruk av mck -bjekter sm stubber g drivere. Sammenligningsverktøy Slike verktøy viser frskjell mellm filer, databaser eller testresultater. Testutføringsverktøy mfatter typisk dynamisk sammenligning, men sammenligning etter testutføring kan gså bli utført av et eget verktøy. Et sammenligningsverktøy kan bruke et testrakel, spesielt m det er autmatisert. Dekningsmålingsverktøy (U) Dekningsmålingsverktøy kan med invaderende eller ikke-invaderende teknikker måle prsentdelen av spesifikke typer av kdestrukturer sm har blitt utført (kdelinjer, beslutninger eller frgreninger g mdul- eller funksjnskall) ved hjelp av et sett av tester. Verktøy fr sikkerhetstesting Disse verktøyene brukes til å evaluere sikkerhetsegenskaper i prgramvare. Dette mfatter evaluering av prgramvarens evne til å beskytte dataknfidensialitet, integritet, autentisering, autrisasjn, tilgjengelighet g ikke-frnekting (nn-repudiatin). Verktøy fr sikkerhetstester er fte fkusert på bestemte teknlgier, plattfrmer g frmål Verktøystøtte til ytelse g vervåkning (K1) Dynamiske analyseverktøy (U) Dynamiske analyseverktøy finner feil, sm bare åpenbares når prgramvaren utføres, slik sm tidsavhengigheter g minnelekkasjer. De benyttes typisk i kmpnent- g kmpnentintegrasjnstest g ved test av mellmvare. Ytelses- / last- / stresstestverktøy Ytelsestestverktøy vervåker g rapprterer hvrdan et system ppfører seg under varierte simulerte brukssituasjner i frm av antall samtidige brukere, deres ramp-up (økning i antall brukere) mønster, frekvens g relativ prsentfrdeling av transaksjner. Simulering av last ppnås ved å anvende virtuelle brukere sm utfører utvalgte transaksjner, spredd på frskjellige testmaskiner nrmalt kjent sm lastgeneratrer. Versin 2011 Page 64 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

65 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Overvåkningsverktøy Overvåkningsverktøy analyserer, verifiserer g rapprterer kntinuerlig bruken av spesifikke systemressurser, g gir advarsel ved mulige ressurs- eller tjenesteprblemer Verktøystøtte fr spesifikke testbehv (K1) Bedømmelse / vurdering av datakvalitet Data er i sentrum fr enkelte prsjekter slik sm dataknverterings- g migreringsprsjekter g i applikasjner sm datavarehus. Dataenes attributter kan variere i frm av kritikalitet g vlum. I en slik sammenheng trenger man verktøy fr å bedømme datakvalitet fr å granske g verifisere regler fr dataknvertering g migrering fr å sikre at de prsesserte data er krrekte, kmplette g samsvarer med en frhåndsdefinert kntekstspesifikk standard. Det brukes andre verktøy fr testing av brukbarhet. Versin 2011 Page 65 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

66 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 6.2 Effektiv bruk av verktøy: mulige frdeler g risiker (K2) 20 minutter Begreper Datadrevet testing, nøkkelrddrevet testing, skriptspråk Mulige frdeler g risiker ved verktøystøtte til testing (fr alle verktøy) (K2) Bare det å kjøpe eller leie et verktøy garanterer ikke suksess ved bruk av verktøyet. Hver type verktøy kan kreve ytterligere innsats fr å ppnå reelle g varige frdeler. Det er ptensielle frdeler g muligheter ved bruk av verktøy i testing, men det er gså risiker. Ptensielle frdeler ved å benytte et verktøy mfatter: Repeterende arbeid reduseres (f.eks. å kjøre regresjnstest, ppgi de samme testdata på nytt g sjekke mt kdestandarder). Bedre knsistens g repeterbarhet (f.eks. test utført med et verktøy i samme rekkefølge g frekvens, g tester utledet fra krav). Objektiv vurdering (f.eks. statiske målinger, dekning) Enkel tilgang til infrmasjn m tester eller testingen (f.eks. statistikk g grafer m testframdrift, hendelsesfrekvens g ytelse). Risiker ved bruk av verktøy mfatter: Urealistiske frventinger til verktøyet (inkludert funksjnalitet g hvr lett det er å bruke) Undervurdering av tid, kstnader g innsats til intrduksjn av et verktøy (inkludert pplæring g ekstern ekspertise). Undervurdering av tid g innsats sm kreves fr å ppnå betydelige g kntinuerlige frdeler fra verktøyet (inkludert behv fr endringer i testprsessen g kntinuerlig frbedring i hvrdan verktøyet benyttes). Undervurdering av innsatsen sm kreves fr å vedlikehlde testartefaktene prdusert av verktøyet. Fr str tillit til verktøyet (erstatning fr testdesign eller bruk av autmatiserte tester der manuelle tester ville være bedre). Neglisjering av versjnskntrll av testartefakter i g generert av verktøyet. Neglisjering av prblemer med relasjner g interperabilitet mellm kritiske verktøy, sm kravhåndteringsverktøy, versjnskntrll, feilhåndteringsverktøy, feilfrvaltningsverktøy g verktøy fra frskjellige leverandører. Risik fr at leverandør går knkurs, slutter med verktøyet eller selger verktøyet til en annen leverandør. Dårlig respns fra leverandør på supprt/støtte, ppgraderinger g feilrettinger. Ufrutsette risiker, sm at det ikke støtter nye plattfrmer. Risik fr at pen-surce eller freeware-prsjekter avsluttes Spesielle hensyn fr nen typer verktøy (K1) Testutføringsverktøy Testutføringsverktøy utfører tester på testbjekter ved å bruke autmatiserte skript. Denne type verktøy krever fte en str innsats fr å få vesentlig nytte. Versin 2011 Page 66 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

67 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Å lage tester ved å gjøre pptak av manuelle tester virker attraktivt, men er en framgangsmåte sm ikke skalerer til et strt antall autmatiserte testskript. Et testpptak er en lineær representasjn med spesifikke data g aksjner sm en del av skriptet. Denne type skript kan bli ustabil når uventede hendelse inntreffer. En datadrevet framgangsmåte separerer ut inputdata, vanligvis i et regneark, g bruker et mer generisk testskript sm kan lese inputdata g utføre det samme testskriptet med frskjellige data. Testere sm ikke er kjent med skriptspråket kan da lage testdata fr disse predefinerte skriptene. Det finnes andre teknikker sm kan benyttes i datadrevet teknikk. En mulighet er hardkdede datakmbinasjner i et regneark. En annen mulighet er generering av data ved hjelp av algritmer basert på knfigurerbare parametere sm ved utføring gis sm input til applikasjnen. Fr eksempel kan et verktøy bruke en algritme sm genererer en tilfeldig bruker-id, g fr å få repeterbarhet i et mønster, blir en startverdi (seed) benyttet fr å kntrllere tilfeldighet. I en nøkkelrddrevet framgangsmåte innehlder regnearket nøkkelrd sm beskriver aksjnene sm skal utføres (gså kalt aksjnsrd engelsk actin wrds ) g testdata. Testere (gså m de ikke er kjent med skriptspråket) kan da definere tester ved bruk av nøkkelrd, sm kan skreddersys til applikasjnen sm skal testes. Teknisk ekspertise i skriptspråket er nødvendig fr alle framgangsmåter (enten av testere eller av spesialister i testautmatisering). Uavhengig av skriptteknikk sm benyttes, så må det frventede resultatet fr hver test lagres fr senere sammenligning. Statiske analyseverktøy Statiske analyseverktøy sm benyttes på kildekde, kan håndheve kdestandarder, men m de anvendes på eksisterende kde kan det generere mange meldinger. Advarselsmeldinger stpper ikke kden i å bli versatt til et utførbart prgram, men skal ideelt sett bli behandlet slik at vedlikehld av kden blir lettere i framtiden. En gradvis implementasjn med innledende filtre fr å ekskludere nen meldinger vil være en effektiv framgangsmåte. Testadministrasjnsverktøy Testadministrasjnsverktøy må integreres med andre verktøy eller regneark fr å kunne prdusere infrmasjn på et frmat sm rganisasjnen trenger. Versin 2011 Page 67 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

68 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 6.3 Intrduksjn av et verktøy i en rganisasjn (K1) 15 minutter Begreper Ingen spesifikke begreper. Bakgrunn Hvedvurderingene i å velge et verktøy fr en rganisasjn mfatter: Vurdering av en rganisasjns mdenhet, styrker g svakheter g å identifisere muligheter fr en frbedret testprsess støttet av verktøy. Vurdering pp mt klare krav g bjektive kriterier. En test (prf-f-cncept) ved å bruke testverktøyet under evalueringsfasen fr å vurdere m det fungerer effektivt med prgramvaren sm skal testes g med den eksisterende infrastrukturen, eller fr å identifisere endringer sm behøves i infrastrukturen fr å kunne utnytte verktøyet effektivt. Evaluering av leverandøren (inkludert pplæring, støtte g kmmersielle aspekter) eller av tjenesteleverandørene dersm det ikke er et kmmersielt verktøy. Identifisering av interne krav til pplæring, støtte g ppfølging i å bruke verktøyet. Evaluering av pplæringsbehv i frhld til det nåværende testteamets autmatiseringskunnskaper. Estimering av kst-nytte frhld basert på knkrete frretningsmål. Å intrdusere det valgte verktøyet i en rganisasjn starter med et piltprsjekt, sm har følgende mål: Lære flere detaljer m verktøyet. Vurdere m verktøyet passer til eksisterende prsesser g praksis, g bestemme hva sm må endres. Bestemme standard måter å bruke, administrere, lagre g vedlikehlde verktøyet g testmaterialet. (f.eks. bestemme navneknvensjner fr filer g tester, lage bibliteker g definere mdulariteten av testsuiter). Vurdere m frdelene vil ppnås til en akseptabel kstnad. Suksessfaktrer fr å ta i bruk et verktøy i en rganisasjn er blant annet: Trinnvis utrulling av verktøyet til resten av rganisasjnen. Tilpasse g frbedre prsessene fr å passe med bruk av verktøyet. Gi undervisning g pplæring/støtte/ppfølging til nye brukere. Definere retningslinjer fr bruk. Implementere en måte å lære av bruken av verktøyet. Overvåke verktøybruken g frdeler. Gi støtte til testteamet fr et gitt verktøy. Dele erfaringer med alle team. Referanser Buwalda, 2001, Fewster, Fewster, 1999 Versin 2011 Page 68 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

69 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 7 Referanser 7.1 Standarder ISTQB Glssary f terms used in Sftware Testing Versin 2.0 (Nrwegian Testing Bard nrskengelsk versjn) [CMMI] Chrissis, M.B., Knrad, M. and Shrum, S. (2004) CMMI, Guidelines fr Prcess Integratin and Prduct Imprvement, Addisn Wesley: Reading, MA Se avsnitt 2.1 [IEEE 829] IEEE Std 829 (1998/2008) IEEE Standard fr Sftware Test Dcumentatin (ny endret utgave er kmmet i Eksamensrelevant er dg bare det sm er beskrevet i denne syllabus.) Se avsnitt 2.3, 2.4, 4.1, 5.2, 5.3, 5.5, 5.6 [IEEE 1028] IEEE Std 1028 (1997) IEEE Standard fr Sftware Reviews (ny endret utgave er kmmet i Eksamensrelevant er dg bare det sm er beskrevet i denne syllabus.) Se avsnitt 3.2 [IEEE 12207] IEEE 12207/ISO/IEC , Sftware Life Cycle Prcesses Se avsnitt 2.1 [ISO 9126] ISO/IEC :2001, Sftware Engineering Sftware Prduct Quality. Standarden ISO er tatt ut av bruk g erstattet av ISO/IEC 25010:2011, Systems and sftware engineering Systems and sftware Quality Requirements and Evaluatin (SQuaRE) System and sftware quality mdels. I eksamen er dg bare de egenskapene relevant sm er beskrevet i denne syllabus. Se avsnitt 2.3 [ISO 29119] ISO/IEC/IEEE serien: Sftware testing er en serie standarder publisert siden Ikke relevant fr eksamen, men fr praktisk bruk. Følgende standarder er tilgjengelige: ISO/IEC/IEEE : Cncepts & Definitins, publisert September 2013 ISO/IEC/IEEE : Test Prcesses, publisert September 2013 ISO/IEC/IEEE : Test Dcumentatin, publisert September 2013 ISO/IEC/IEEE : Test Techniques, publisert Desember 2015 ISO/IEC/IEEE : Keywrd Driven Testing, publisert Nvember Bøker [Beizer, 1990] Beizer, B. (1990) Sftware Testing Techniques (2nd editin), Van Nstrand Reinhld: Bstn Se avsnitt 1.2, 1.3, 2.3, 4.2, 4.3, 4.4, 4.6 [Black, 2001] Black, R. (2001) Managing the Testing Prcess (2nd editin), Jhn Wiley & Sns: New Yrk Se avsnitt 1.1, 1.2, 1.4, 1.5, 2.3, 2.4, 5.1, 5.2, 5.3, 5.5, 5.6 [Buwalda, 2001] Buwalda, H. et al. (2001) Integrated Test Design and Autmatin, Addisn Wesley: Reading, MA Se avsnitt 6.2 Versin 2011 Page 69 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

70 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard [Cpeland, 2004] Cpeland, L. (2004) A Practitiner s Guide t Sftware Test Design, Artech Huse: Nrwd, MA Se avsnitt 2.2, 2.3, 4.2, 4.3, 4.4, 4.6 [Craig, 2002] Craig, Rick D. and Jaskiel, Stefan P. (2002) Systematic Sftware Testing, Artech Huse: Nrwd, MA Se avsnitt 1.4.5, 2.1.3, 2.4, 4.1, 5.2.5, 5.3, 5.4 [Fewster, 1999] Fewster, M. and Graham, D. (1999) Sftware Test Autmatin, Addisn Wesley: Reading, MA Se avsnitt 6.2, 6.3 [Gilb, 1993]: Gilb, Tm and Graham, Drthy (1993) Sftware Inspectin, Addisn Wesley: Reading, MA Se avsnitt 3.2.2, [Hetzel, 1988] Hetzel, W. (1988) Cmplete Guide t Sftware Testing, QED: Wellesley, MA Se avsnitt 1.3, 1.4, 1.5, 2.1, 2.2, 2.3, 2.4, 4.1, 5.1, 5.3 [Kaner, 2002] Kaner, C., Bach, J. and Pettticrd, B. (2002) Lessns Learned in Sftware Testing, Jhn Wiley & Sns: New Yrk Se avsnitt 1.1, 4.5, 5.2 [Myers 1979] Myers, Glenfrd J. (1979) The Art f Sftware Testing, Jhn Wiley & Sns: New Yrk Se avsnitt 1.2, 1.3, 2.2, 4.3 [van Veenendal, 2004] van Veenendal, E. (ed.) (2004) The Testing Practitiner (Chapters 6, 8, 10), UTN Publishers: The Netherlands Se avsnitt 3.2, 3.3 Versin 2011 Page 70 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

71 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 8 Vedlegg A Bakgrunn til pensum 8.1 Histrien til dette dkumentet Dette dkument ble utviklet mellm 2004 g 2011 av en arbeidsgruppe bestående av medlemmer sm var utpekt av Internatinal Sftware Testing Qualificatins Bard (ISTQB). Opprinnelig ble det gransket av en utvalgt granskningsgruppe, g så av representanter fra de sm internasjnalt arbeider med test av prgramvare. Reglene sm er brukt under prduksjn av dette dkument er vist i vedlegg C. Dette dkument er pensum fr grunnivået i Internatinal Fundatin Certificate in Sftware Testing, g første nivå av internasjnal kvalifikasjn sm er anerkjent av ISTQB ( 8.2 Mål med kvalifikasjnen med Fundatin Certificate Å få anerkjennelse fr testing sm et nødvendig g prfesjnelt spesialfelt innen prgramvareutvikling. Å gi et standard rammeverk fr utviklingen av en testers karriere. Å bidra til at prfesjnelt kvalifiserte testere blir anerkjent av arbeidsgivere, kunder g arbeidsklleger, g å øke testernes synlighet. Å sørge fr utbredelse av sammenlignbar g gd testpraksis innen alle mråder av prgramvareutvikling. Å identifisere tema innen testing sm er relevante g har en verdi i prgramvaremiljø. Å muliggjøre fr firma sm utvikler prgramvare å ansette sertifiserte testere g dermed å få kmmersielle frdeler ver deres knkurrenter ved at de annnserer deres ansettelseskrav fr testere. Å gi en mulighet fr testere g de sm har interesse fr testing å få en internasjnalt anerkjent kvalifikasjn i fagmrådet. 8.3 Mål med den internasjnale kvalifikasjnen (tatt fra ISTQB møte på Sllentuna, nvember 2001) Å kunne sammenligne evner innen testing mellm frskjellige land. Å muliggjøre fr testere å enklere flytte seg mellm land. Å muliggjøre at multinasjnale/internasjnale prsjekter har en felles frståelse av utfrdringer innen testing. Å øke antallet kvalifiserte testere i verden. Å ha større gjennmslagskraft g verdi sm et internasjnalt basert initiativ enn sm et initiativ basert på et enkelt land. Å utvikle en felles internasjnal samling av frståelse g kunnskap m testing gjennm pensum g terminlgilisten, g å øke kunnskapsnivået m testing fr alle deltakere. Å tilby testing sm et prfesjnelt yrke i flere land. Å muliggjøre fr testere å få en anerkjent kvalifikasjn på sine nasjnale språk. Å muliggjøre deling av kunnskap g ressurser ver landegrenser. Å sørge fr internasjnal anerkjennelse av testere g denne kvalifiseringen gjennm deltakelse fra mange land. 8.4 Startkrav fr denne kvalifikasjnen Startkriteriet fr å ta eksamen fr ISTQB Fundatin Certificate in Sftware Testing er at kandidaten har en interesse fr test av prgramvare. Men det anbefales på det sterkeste at kandidater gså: Versin 2011 Page 71 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

72 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Har i hvert fall en minimal bakgrunn enten i utvikling av prgramvare eller i testing av prgramvare, sm fr eksempel seks måneders erfaring sm system- eller akseptansetester eller sm utvikler av prgramvare. Tar et kurs sm har blitt akkreditert i henhld til ISTQBs standarder (av et av de ISTQBanerkjente nasjnale Bards). 8.5 Bakgrunn g histrie fr grunnsertifikatet (Fundatin Certificate in Sftware Testing) Uavhengig sertifisering av testere av prgramvare startet i Strbritannia med British Cmputer Sciety Infrmatin Systems Examinatin Bard (ISEB). Et Sftware Testing Bard ble pprettet i 1998 ( I 2002 tk ASQF i Tyskland initiativ til en tysk sertifisering av prgramvaretestere ( Pensum i dette dkumentet er basert på ISEB g ASQF sine; den inkluderer rerganisert, ppdatert g ne nytt innhld, g vekten er lagt på de tema sm gir mest praktisk nytteverdi g hjelp fr testere. Et eksisterende grunnlagssertifikat (Fundatin Certificate) fra fr eksempel ISEB, ASQF eller et ISTQB-anerkjent nasjnalt Bard, sm er gitt før dette internasjnale sertifikat ble utgitt, blir ansett sm ekvivalent til det internasjnale sertifikatet. Grunnlagssertifikatet (Fundatin Certificate) utløper ikke g krever ikke frnyelse. Daten et sertifikat ble gitt er vist på sertifikatet. I hvert deltakende land blir lkale frhld tatt hensyn til av et nasjnalt ISTQB-anerkjent Sftware Testing Bard. Frpliktelsene disse nasjnale Bards skal ppfylle, er spesifisert av ISTQB, men er implementert av hvert nasjnale Bard. Frpliktelsene til et lands Bard innehlder akkreditering av kurshldere g arrangering av eksamen. Versin 2011 Page 72 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

73 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 9 Vedlegg B Læremål / kunnskapsnivå Følgende læremål er definert sm tilhørende dette pensum. Hvert tema i pensum kan bli prøvd i eksamen tilsvarende sitt læremål. 9.1 Nivå 1: Husk (K1) Kandidaten gjenkjenner, husker eller kan gjenta en term eller et knsept. Stikkrd: Huske, gjenkjenne, gjenta, bservere, vite Eksempel Kan gjenkjenne definisjnen failure sm: Avvik eller fravikelse av en kmpnent eller et system fra dens frventede resultat, tjeneste eller utput. Hendelse der systemet eller kmpnenten ikke klarer å utføre sin spesifiserte funksjn eller å utføre den innenfr de begrensninger sm er spesifisert. 9.2 Nivå 2: Frstå (K2) Kandidaten kan velge begrunnelsene eller erklæringene fr påstander m dette tema g kan ppsummere, sammenligne, klassifisere, kategrisere g gi eksempler fr dette testknseptet. Stikkrd: ppsummere, generalisere, abstrahere, klassifisere, sammenligne, kartlegge, kntrastere, eksemplifisere, tlke, versette, representere, trekke slutninger, knkludere, kategrisere, knstruere mdeller Eksempler Kan frklare grunnen til hvrfr testene bør bli utviklet så tidlig sm mulig: Fr å finne feil når de er billigere å ta brt. Fr å finne de viktigste feilene først. Kan frklare likhetene g frskjellene mellm integrasjn g systemtesting: Likheter: tester mer enn en kmpnent g kan teste ikke-funksjnelle aspekter. Frskjeller: integrasjnstesting knsentrerer seg m grensesnitt g interaksjner, mens systemtesting knsentrerer seg m aspektene sm vedrører hele systemet, sm prsessering fra start til slutt. 9.3 Nivå 3: Bruke (K3) Kandidaten kan velge den rette anvendelsen av et knsept eller en teknikk g anvende den fr en gitt ppgave. Stikkrd: Implementere, utføre, bruke, følge en prsedyre, tilføre en prsedyre Eksempel Kan identifisere grenseverdier fr gyldige g ugyldige partisjner. Kan velge testtilfeller fr et gitt tilstandsdiagram fr å dekke alle verganger. 9.4 Nivå 4: Analysere (K4) Kandidaten kan separere infrmasjn relatert til en prsedyre eller teknikk til dens bestanddeler fr bedre frståelse g kan skille mellm fakta g frstyrrende elementer. Dette vil typisk innebære å Versin 2011 Page 73 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

74 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard analysere et dkument, en prgramvare eller en prsjektsituasjn g freslå passende aktiviteter fr å løse et prblem eller en ppgave. Stikkrd: Analysere, rganisere, finne sammenheng, integrere, angi hvedpunktene, analysere syntaktisk, strukturere, finne kjennetegn, deknstruere, differensiere, se frskjell på, finne frskjeller, fkusere, velge Eksempel Analysere prduktrisik g freslå frebyggende g krrigerende migrasjnsaktiviteter Beskrive hvilke deler av en hendelsesrapprt sm er fakta g hvilke sm avviker fra resultater Referanser (Fr de kgnitive nivåer av læremål) Andersn, L. W. and Krathwhl, D. R. (eds) (2001) A Taxnmy fr Learning, Teaching, and Assessing: A Revisin f Blm's Taxnmy f Educatinal Objectives, Allyn & Bacn: Versin 2011 Page 74 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

75 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 10 Vedlegg C Regler sm er brukt av ISTQB Grunnivå-pensum (Fundatin syllabus) Reglene listet pp her ble brukt under utvikling g granskning av dette pensum. En TAG er vist etter hver regel sm en krt kde av regelen.) Generelle regler SG1. Pensum bør være frståelig g lærbar fr persner med 0 til 6 måneder (eller mer) erfaring i testing. (6-MONTH) SG2. Pensum bør være praktisk heller enn teretisk. (PRACTICAL) SG3. Pensum bør være klart g entydig fr dens planlagte lesere. (CLEAR) SG4. Pensum bør være frståelig fr persner fra ulike land, g lett å versette til ulike språk. (TRANSLATABLE) SG5. Det riginale pensum (syllabus) skal bruke Amerikansk Engelsk. (AMERICAN-ENGLISH) Aktuelt innhld SC1. Pensum bør innehlde mderne testknsepter g bør reflektere aktuell beste praksis i test av prgramvare der dette er generelt akseptert. Pensum skal ppdateres hvert tredje til femte år. (RECENT) SC2. Pensum bør minimere nåtidsrelaterte ting, sm dagens markedssituasjn, fr å muliggjøre at det frtsatt er aktuelt etter tre til fem år (SHELF-LIFE) Læremål LO1. Læremål bør skille mellm ting sm skal gjenkjennes/huskes (kgnitivt nivå K1), ting kandidaten skal frstå knseptet av (K2), ting sm kandidaten skal kunne anvende (K3) g ting sm kandidaten skal kunne bruke fr å analysere et dkument, prgramvare eller prsjektsituasjn i sin sammenheng (K4). (KNOWLEDGE-LEVEL) LO2. Beskrivelsen av innhldet bør være sammenhengende med læremålene. (LO-CONSISTENT) LO3. Fr å illustrere læremålene, bør eksempler på eksamensspørsmål publiseres sammen med pensum. (LO-EXAM) Ttalstruktur ST1. Strukturen til pensum bør være klar g tillate kryssreferering til g fra andre deler, fra eksamensspørsmål g fra andre relevante dkumenter. (CROSS-REF) ST2. Overlapp mellm avsnitt i pensum avsnitt bør være minimale. (OVERLAP) ST3. Hvert avsnitt i pensum bør ha samme struktur. (STRUCTURE-CONSISTENT) ST4. Pensum bør innehlde versjn, publiseringsdat g sidenummer på hver side. (VERSION) ST5. Pensum bør inkludere retningslinjer fr hvr mye tid sm skal brukes fr hvert avsnitt i løpet av et kurs (fr å vise den relative viktigheten av hvert tema). (TIME-SPENT) Referanser SR1. Kilder g referanser blir gitt fr hvert knsept i pensum fr å hjelpe kurshldere til å finne mer infrmasjn m temaet. (REFS) SR2. Der det ikke er direkte identifiserte g klare kilder, skal pensum innehlde mer detaljer. Fr eksempel: definisjner er i terminlgilisten, derfr blir bare begrepene listet i pensum. (NON-REF DETAIL) Infrmasjnskilder Versin 2011 Page 75 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

76 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard Begreper brukt i dette pensum er definert i ISTQB Glssary Of Terms Used In Sftware Testing. En versjn av denne er tilgjengelig på engelsk på (websidene til ISTQB). En nrskengelsk versjn er tilgjengelig på En liste ver anbefalte bøker m test av prgramvare blir gså distribuert parallelt til dette pensum. Disse bøkene ligger i referanselisten i dette dkumentet. Versin 2011 Page 76 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

77 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 11 Vedlegg D Infrmasjn til kurshldere Hvert hvedkapittel i pensum er tildelt et tidsrm i minutter. Målet med dette er både å gi veiledning angående den relative andelen tid sm skal brukes fr hver del av et akkreditert kurs, g å gi en mtrentlig minimaltid fr læringen av hvert kapittel. Kurshldere kan bruke mer tid enn vist, g kandidater kan igjen bruke mer tid fr å lese g utfrske mrådet. Et kurs behøver heller ikke følge samme rekkefølgen sm dette pensum. Pensum innehlder referanser til etablerte standarder sm skal brukes under frberedelsen av pplæringsmateriellet. Hver standard må siteres med angivelse av versjn. Andre publikasjner, maler eller standarder sm ikke er referert i dette pensum, kan gså brukes g refereres, men de vil ikke bli grunnlag fr eksamen. Versin 2011 Page 77 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

78 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 12 Appendix E Release Ntes Release Changes t Learning Objectives (LO) include sme clarificatin a. Wrding changed fr the fllwing LOs (cntent and level f LO remains unchanged): LO-1.2.2, LO-1.3.1, LO-1.4.1, LO-1.5.1, LO-2.1.1, LO-2.1.3, LO , LO-4.1.3, LO-4.2.1, LO-4.2.2, LO-4.3.1, LO-4.3.2, LO-4.3.3, LO-4.4.1, LO-4.4.2, LO-4.4.3, LO-4.6.1, LO-5.1.2, LO-5.2.2, LO-5.3.2, LO-5.3.3, LO , LO-5.6.1, LO-6.1.1, LO-6.2.2, LO b. LO has been rewrded and upgraded t K2. Because a cmparisn f terms f defect related terms can be expected. c. LO (K2) has been added. The cntent was already cvered in the 2007 syllabus. d. LO (K2) nw cmbines the cntent f LO and LO e. LO has been remved frm the 2010 syllabus, as it is partially redundant with LO f. LO has been rewrded fr cnsistency with the 2010 syllabus cntent. g. LO has been mdified, and its level has been changed frm K1 t K2, fr cnsistency with LO h. LO has been mdified fr clarity, and has been changed frm a K3 t a K4. Reasn: LO had already been written in a K4 manner. i. LO (K1) was drpped frm the 2010 syllabus and was replaced with LO (K2). There is n LO in the 2010 syllabus. 2. Cnsistent use fr test apprach accrding t the definitin in the glssary. The term test strategy will nt be required as term t recall. 3. Chapter 1.4 nw cntains the cncept f traceability between test basis and test cases. 4. Chapter 2.x nw cntains test bjects and test basis. 5. Re-testing is nw the main term in the glssary instead f cnfirmatin testing. 6. The aspect data quality and testing has been added at several lcatins in the syllabus: data quality and risk in Chapter 2.2, 5.5, Chapter Entry Criteria are added as a new subchapter. Reasn: Cnsistency t Exit Criteria (-> entry criteria added t LO-5.2.9). 2. Cnsistent use f the terms test strategy and test apprach with their definitin in the glssary. 3. Chapter 6.1 shrtened because the tl descriptins were t large fr a 45 minute lessn. 4. IEEE Std 829:2008 has been released. This versin f the syllabus des nt yet cnsider this new editin. Sectin 5.2 refers t the dcument Master Test Plan. The cntent f the Master Test Plan is cvered by the cncept that the dcument Test Plan cvers different levels f planning: Test plans fr the test levels can be created as well as a test plan n the prject level cvering multiple test levels. Latter is named Master Test Plan in this syllabus and in the ISTQB Glssary. 5. Cde f Ethics has been mved frm the CTAL t CTFL. Release 2011 Changes made with the maintenance release General: Wrking Party replaced by Wrking Grup 2. Replaced pst-cnditins by pstcnditins in rder t be cnsistent with the ISTQB Glssary First ccurrence: ISTQB replaced by ISTQB Versin 2011 Page 78 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard

79 Fundatin Level Syllabus Internatinal Sftware Testing Qualificatins Bard 4. Feil! Fant ikke referansekilden.: Descriptins f Cgnitive Levels f Knwledge remved, because this was redundant t Appendix B. 5. Sectin 1.6: Because the intent was nt t define a Learning Objective fr the Cde f Ethics, the cgnitive level fr the sectin has been remved. 6. Sectin 2.2.1, 2.2.2, and 2.2.4, 3.2.3: Fixed frmatting issues in lists. 7. Sectin The wrd failure was nt crrect fr islate failures t a specific cmpnent. Therefre replaced with defect in that sentence. 8. Sectin 2.3: Crrected frmatting f bullet list f test bjectives related t test terms in sectin Feil! Fant ikke referansekilden.. 9. Sectin 2.3.4: Updated descriptin f debugging t be cnsistent with Versin 2.1 f the ISTQB Glssary. 10. Sectin 2.4 remved wrd extensive frm includes extensive regressin testing, because the extensive depends n the change (size, risks, value, etc.) as written in the next sentence. 11. Sectin 3.2: The wrd including has been remved t clarify the sentence. 12. Sectin 3.2.1: Because the activities f a frmal review had been incrrectly frmatted, the review prcess had 12 main activities instead f six, as intended. It has been changed back t six, which makes this sectin cmpliant with the Syllabus 2007 and the ISTQB Advanced Level Syllabus Sectin 4: Wrd develped replaced by defined because test cases get defined and nt develped. 14. Sectin 4.2: Text change t clarify hw black-bx and white-bx testing culd be used in cnjunctin with experience-based techniques. 15. Sectin text change..between actrs, including users and the system.. t between actrs (users r systems),. 16. Sectin alternative path replaced by alternative scenari. 17. Sectin Feil! Fant ikke referansekilden..2: In rder t clarify the term branch testing in the text f Sectin Feil! Fant ikke referansekilden., a sentence t clarify the fcus f branch testing has been changed. 18. Sectin 4.5, Sectin 5.2.6: The term experienced-based testing has been replaced by the crrect term experience-based. 19. Sectin 6.1: Heading Understanding the Meaning and Purpse f Tl Supprt fr Testing (K2) replaced by Tl Supprt fr Testing (K2). 20. Sectin 7 / Bks: The 3rd editin f [Black,2001] listed, replacing 2 nd editin. 21. Appendix D: Chapters requiring exercises have been replaced by the generic requirement that all Learning Objectives K3 and higher require exercises. This is a requirement specified in the ISTQB Accreditatin Prcess (Versin 1.26). 22. Appendix E: The changed learning bjectives between Versin 2007 and 2010 are nw crrectly listed. Versin 2011 Page 79 f Apr-2007 Internatinal Sftware Testing Qualificatins Bard