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

Transkript

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

2 Grunnleggende nivå (Fundatin Level Syllabus) Internatinal Sftware Testing Qualificatins Bard Cpyright 2011 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. Versjn 2011.N2 (= engelsk 2011) Publisert Nrwegian Testing Bard - Internatinal Sftware Testing Qualificatins Bard Side 2 av 77

3 Grunnleggende nivå (Fundatin Level Syllabus) Internatinal Sftware Testing Qualificatins Bard Revisjnshistrie Versjn Dat Bemerkninger 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. Versjn 2011.N2 (= engelsk 2011) Publisert Nrwegian Testing Bard - Internatinal Sftware Testing Qualificatins Bard Side 3 av 77

4 Grunnleggende nivå (Fundatin Level Syllabus) Internatinal Sftware Testing Qualificatins Bard Innhldsfrtegnelse Innledning 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) Versjn 2011.N2 (= engelsk 2011) Publisert Nrwegian Testing Bard - Internatinal Sftware Testing Qualificatins Bard Side 4 av 77

5 Grunnleggende nivå (Fundatin Level Syllabus) Internatinal Sftware Testing Qualificatins Bard 4.2 Kategrier fr teknikker fr testdesign (K2) Spesifikasjnsbaserte (svart bks) teknikker (K3) Ekvivalensklasseinndeling (K3) 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 Versjn 2011.N2 (= engelsk 2011) Publisert Nrwegian Testing Bard - Internatinal Sftware Testing Qualificatins Bard Side 5 av 77

6 Grunnleggende nivå (Fundatin Level Syllabus) Internatinal Sftware Testing Qualificatins Bard 8.3 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) 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. Versjn 2011.N2 (= engelsk 2011) Publisert Nrwegian Testing Bard - Internatinal Sftware Testing Qualificatins Bard Side 6 av 77

7 Grunnleggende nivå (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). Versjn 2011.N2 (= engelsk 2011) Publisert Nrwegian Testing Bard - Internatinal Sftware Testing Qualificatins Bard Side 7 av 77

8 Grunnleggende nivå (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. Versjn 2011.N2 (= engelsk 2011) Publisert Nrwegian Testing Bard - Internatinal Sftware Testing Qualificatins Bard Side 8 av 77

9 Grunnleggende nivå (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. Versjn 2011.N2 (= engelsk 2011) Publisert Nrwegian Testing Bard - Internatinal Sftware Testing Qualificatins Bard Side 9 av 77

10 Grunnleggende nivå (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) Versjn 2011.N2 (= engelsk 2011) Publisert Nrwegian Testing Bard - Internatinal Sftware Testing Qualificatins Bard Side 10 av 77

11 Grunnleggende nivå (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), 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 ). 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. 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. Versjn 2011.N2 (= engelsk 2011) Publisert Nrwegian Testing Bard - Internatinal Sftware Testing Qualificatins Bard Side 11 av 77

12 Grunnleggende nivå (Fundatin Level Syllabus) Internatinal Sftware Testing Qualificatins Bard 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. Versjn 2011.N2 (= engelsk 2011) Publisert Nrwegian Testing Bard - Internatinal Sftware Testing Qualificatins Bard Side 12 av 77

13 Grunnleggende nivå (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 driftstesting er hvedfrmålet å evaluere systemets egenskaper, slik sm pålitelighet g tilgjengelighet. 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. Versjn 2011.N2 (= engelsk 2011) Publisert Nrwegian Testing Bard - Internatinal Sftware Testing Qualificatins Bard Side 13 av 77

14 Grunnleggende nivå (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. Versjn 2011.N2 (= engelsk 2011) Publisert Nrwegian Testing Bard - Internatinal Sftware Testing Qualificatins Bard Side 14 av 77

15 Grunnleggende nivå (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. Versjn 2011.N2 (= engelsk 2011) Publisert Nrwegian Testing Bard - Internatinal Sftware Testing Qualificatins Bard Side 15 av 77

16 Grunnleggende nivå (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. 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. Overlevering av testware til de sm er ansvarlige fr vedlikehld. Versjn 2011.N2 (= engelsk 2011) Publisert Nrwegian Testing Bard - Internatinal Sftware Testing Qualificatins Bard Side 16 av 77

17 Grunnleggende nivå (Fundatin Level Syllabus) Internatinal Sftware Testing Qualificatins Bard Analyse av erfaringer fr å bestemme endringer sm behøves ved fremtidige utgivelser g prsjekter. Bruk av infrmasjnen sm er samlet fr frbedring av testmdenhet. Versjn 2011.N2 (= engelsk 2011) Publisert Nrwegian Testing Bard - Internatinal Sftware Testing Qualificatins Bard Side 17 av 77

18 Grunnleggende nivå (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. Versjn 2011.N2 (= engelsk 2011) Publisert Nrwegian Testing Bard - Internatinal Sftware Testing Qualificatins Bard Side 18 av 77

19 Grunnleggende nivå (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 anseelsen 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 Versjn 2011.N2 (= engelsk 2011) Publisert Nrwegian Testing Bard - Internatinal Sftware Testing Qualificatins Bard Side 19 av 77

20 Grunnleggende nivå (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) Versjn 2011.N2 (= engelsk 2011) Publisert Nrwegian Testing Bard - Internatinal Sftware Testing Qualificatins Bard Side 20 av 77

21 Grunnleggende nivå (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. Versjn 2011.N2 (= engelsk 2011) Publisert Nrwegian Testing Bard - Internatinal Sftware Testing Qualificatins Bard Side 21 av 77

22 Grunnleggende nivå (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). Versjn 2011.N2 (= engelsk 2011) Publisert Nrwegian Testing Bard - Internatinal Sftware Testing Qualificatins Bard Side 22 av 77

23 Grunnleggende nivå (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. Versjn 2011.N2 (= engelsk 2011) Publisert Nrwegian Testing Bard - Internatinal Sftware Testing Qualificatins Bard Side 23 av 77

24 Grunnleggende nivå (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. Versjn 2011.N2 (= engelsk 2011) Publisert Nrwegian Testing Bard - Internatinal Sftware Testing Qualificatins Bard Side 24 av 77

25 Grunnleggende nivå (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 Versjn 2011.N2 (= engelsk 2011) Publisert Nrwegian Testing Bard - Internatinal Sftware Testing Qualificatins Bard Side 25 av 77