Testerens værktøjsbælte - testdesignteknikker

Transkript

1 Testerens værktøjsbælte - testdesignteknikker

2 Indholdsfortegnelse 3 Indledning 4 Valg af testdesignteknikker 7 Procescyklustest 9 Datakombinationstest 11 Tilstandsovergangstest 14 Beslutningstabelstest 16 Elementær sammenligningstest 19 Udforskende test 21 Egne noter 24 Om forfatterne 02

3 Indledning I denne folder giver vi vores bud på, hvordan du på en let og overskuelig måde kan udvælge og anvende testdesignteknikker. Der findes mange testdesignteknikker, og i folderen har vi valgt at gennemgå dem, vi oftest anvender i forbindelse med vores eget arbejde med test. Folderen indledes med en illustration, der viser, hvordan processen for at udvælge testdesignteknikker kan gennemføres. Dernæst vil de designteknikker, som vi har valgt at fokusere på, blive beskrevet særskilt. Hver beskrivelse indeholder: Brugbarhed Testgrundlag Dækning Fejltype Vær opmærksom på Til hver testdesignteknik gennemgår vi desuden et kort eksempel på, hvordan teknikken kan anvendes til at identificere testcases. I eksemplerne forudsætter vi, at læseren har et grundlæggende kendskab til forskellige dækningstyper som ækvivalensklasser, grænseværdier m.m. Vi har valgt at kalde denne folder for Testerens Værktøjsbælte, da vi håber, at den vil kunne anvendes som en praktisk og overskuelig hjælp, når du skal planlægge dine testopgaver. God læselyst! Med venlig hilsen Anne Melsing, atasha Fugl Kehler, Steen ordsmark Skardhamar og Ole Chr. Hansen Vallensbæk, februar

4 Valg af testdesignteknikker Processen for at udvælge testdesignteknikker kan beskrives på flere måder. I figur 1 er der gengivet et eksempel på, hvordan man trin for trin kan udvælge testdesignteknikker, som sikrer, at der under udførelsen af test fokuseres på de mål og krav til kvalitet, der er opstillet for systemet. Referencerne til tabel 1 og tabel 2 henviser til de efterfølgende to oversigtstabeller. Figur 1: Proces til udvælgelses af testteknik 1 1 Aalst van der, Leo (2008): Test design techniques were not invented to bully testers, Testing Experience 04

5 Tabel 1: Karakteristik, testintensitet og foreslåede testdesignteknik Karakteristika Testintensitet Let dækning Gennemsnitlig dækning Grundig dækning Håndterbarhed Tjekliste PCT-test dybde niveau 1 UCT-tjekliste DCoT-ækvivalensklasser POCT-test dybde niveau 2 ET DCoT-parvis test PCT-test dybde niveau 3 Sikkerhed Brugervenlighed Tjekliste UCT-tjekliste DCoT-ækvivalensklasser SEM-modificeret beslutningsbetingelses-dækning ET PCT-test dybde niveau 2 UCT-beslutningsveje DCoT-parvis test Indtrængningstest RLT-drifts-/belastningsprofil UCT-beslutningspunkt Kontinuitet RLT-drifts-/belastningsprofil ET RLT-drifts-/belastningsprofil Funktionalitet - detaljeret Funktionalitet - overordnet DTT- beslutningsbetingelses-dækning DCoT-ækvivalensklasser ECT- beslutningsbetingelses-dækning DCoT-ækvivalensklasser SY-tjekliste (afgrænset) UCT-tjekliste DCoT-parvis test ECT-modificeret beslutningsbetingelsesdækning ET DCoT parvis test DCyT (data livscyklus) CRUD DCyT (integritetsregler) beslutningsdækning PCT-test dybde niveau 2 SY (prioriteret liste) SEM-beslutningsbetingelsesdækning UCT-beslutningsveje ET DTT- multibetingelsesdækning (+ grænseværdier) DCoT--vis test ECT-multibetingelsesdækning DCoT--vis test DCyT (data livscyklus) CRUD (ekstra R) DCyT (integritetsregler) modificeret beslutningsbetingelsesdækning RLT-drifts-/belastningsprofiler SEM-modificeret beslutningsbetingelsesdækning UCT-beslutningspunkt Funktionalitet - godkendelse SY-tjekliste (afgrænset) SEM-beslutningsbetingelsesdækning SY (prioriteret liste) SEM- modificeret beslutningsbetingelsesdækning Brugervenlighed SY-tjekliste (afgrænset) PCT-test dybde niveau 2 SY (prioriteret liste) UCT-tjekliste Brugervenlighedstest (muligvis i laboratorium) Infrastruktur (egnethed til) RLT-drifts-/belastningsprofiler ET RLT- drifts-/belastningsprofiler Egnethed UCT-tjekliste DCoT-ækvivalensklasser PCT-test dybde niveau 1 UCT-tjekliste UCT-beslutningsveje PCT-test dybde niveau 2 DCoT-parvis test DCyT (data livscyklus) CRUD DCyT (integritetsregler) beslutningsdækning ET RLT- drifts-/belastningsprofiler UCT-beslutningspunkt DCoT--vis test DCyT (data livscyklus) CRUD (ekstra R) DCyT (integritetsregler) modificeret beslutningsbetingelsedækning PCT test dybde niveau 3 Ydeevne Flytbarhed Tjekliste Vilkårligt udvalgte funktionelle tests Vilkårligt udvalgte miljø-kombinationer RLT-drifts-/belastningsprofiler ET Funktionel regressionstest Vigtige miljøkombinationer ET RLT- drifts-/belastningsprofiler Alle funktionelle test Alle miljøkombinationer Effektivitet RLT-drifts-/belastningsprofiler ET RLT- drifts-/belastningsprofiler 05

6 Tabel 2: Det nødvendige testgrundlag til den foreslåede testdesignteknik Testgrundlag Teknik Alle typer testgrundlag Individuelle betingelses- eller beslutningstabeller, uden struktur Strukturet funktionel specifikation (pseudo code) CRUD matrisse, data integritetsregler Struktureret beskrivelse af forretnings- eller driftsprocesser driftsprofiler, belastningsprofiler Input og output specifikationer, forretningsregler Input og output specifikationer, karakteristikbeskrivelser Usecases Beslutningstabeltest (DTT) Brugervenlighedstest Datacyklustest (DCyT) Datakombinationstest (DCoT) Elementær sammenligningstest (ECT) Fejlgætning () Funktionel test Indtrængningstest Miljø kombinationer Procescyklustest (PCT) Real-life test (RLT) Semantisk test (SEM) Syntaktisk test (SY) Tjekliste Udforskende test (ET) Usecase test (UCT) 06

7 Procescyklustest (PCT) Brugbarhed: Denne teknik fokuserer på egnethed (suitability 2 ) og afprøver, om systemet understøtter og integrerer processer og arbejdsgange fra start til slut. Testgrundlag: Den dokumentation, som skal anvendes til at identificere testcases, er først og fremmest et flowdiagram over systemet. En beskrivelse af systemet kan også anvendes, hvis den er detaljeret nok til, at man kan skitsere et flowdiagram. Dækning: De identificerede test afprøver de stier (paths), som indgår i arbejdsgange eller flows igennem systemet. Den valgte testdybde afhænger af, hvor mange på hinanden følgende stier, man vil teste. Eksempelvis er testdybde 1 en måde at teste på, hvor man gennemfører test af alle enkeltstående stier minimum én gang. Testdybde 2 er derimod test af alle kombinationer af ind- og udgående stier i hvert beslutningspunkt. Fejltyper: De fejl, som lokaliseres ved hjælp af PCT-teknikken, skyldes uoverensstemmelse mellem forretningsprocessen og systemets understøttelse af processen. Vær opmærksom på: De testcases, som identificeres ved hjælp af PCT-designteknikken, fokuserer udelukkende på test af flows i systemet. Data bliver derfor som udgangspunkt ikke kvalitetssikret via PCT. Hvis data skal testes samtidig med test af systemets flows, skal PCT derfor kombineres med en datadreven testdesignteknik, eksempelvis Data Combination Test-teknikken, som også bliver gennemgået i denne folder. Eksempel: Figur 2: Flowdiagram 2 Integration mellem systemet og organisationens manuelle processer. 07

8 Testdybde 1: Testdybde 1 udføres som nævnt på alle enkeltstående stier minimum én gang. På baggrund af ovenstående figur 2 kan man udlede følgende to logiske testcases: TC1: TC2: Testdybde 2: Testdybde 2 udføres ved at kombinere ind- og udgående stier ved hver beslutningspunkt i processen. I ovenstående figur 2 er der 3 beslutningspunkter: A, B og C. En kortlægning af processens beslutningspunkter og tilhørende ind- og udgående stier skal opstilles på følgende måde: A: Ind 1,5 Ud 2,3 B: Ind 2,3 Ud 5,4 C: Ind 4 Ud 6,7 Herefter skal der ved alle beslutningspunkter ske identifikation af par-kombinationer. Disse dannes ved at kombinere ind- og udgående stier som vist nedenfor i figur 3. Figur 3: Par-kombinationer A B C Til sidst skal de logiske testcases udarbejdes. Dette sker ved at kombinere de identificerede parkombinationer på følgende måde: Vælg først den par-kombination, som indeholder stien, der udgår fra flowdiagrammets start. Kombiner derefter den valgte par-kombination med en anden par-kombination, som starter med det samme tal som den første par-kombination sluttede med (f.eks. 1-2, 2-5 ). Fortsæt indtil alle par-kombinationer er anvendt. Ved at kombinere par-kombinationerne i tabellen i figur 3 fås følgende logiske testcases: TC1: TC2: Læg mærke til, at ovenstående testcases alle starter med 1 (den udgående sti fra flowdiagrammets start) og slutter med 6 eller 7 (de indgående stier til flowdiagrammets slut). 08

9 Datakombinationstest (DCoT) Brugbarhed: Denne teknik tester systemets funktionalitet og skaber herudover et visuelt overblik over de data, som har indflydelse på den funktionalitet, der bliver testet. Teknikken kan både teste funktionalitet på et overordnet niveau og på et mere detaljeret niveau. Testgrundlag: Testcases kan identificeres ud fra den formelle systemdokumentation, men kan også identificeres ved at anvende forretningsspecifik viden hos medarbejdere og andre specialister. Denne tilgang er især nyttig, når testgrundlaget ikke er fyldestgørende nok til at udlede testcases af. Dækning: DCoT-teknikken har fokus på de dataattributter, som påvirker funktionaliteten i systemet. Selve testdækningen skal dog som udgangspunkt aftales med forretningen, da DCoT ikke har en foruddefineret testdækningstype. Afhængig af den ønskede testdækning kan DCoT anvendes med f.eks. ækvivalensklasser, grænseværdier eller pairwise-test. Fejltyper: Ved brug af ækvivalensklasser finder du de fejl, der opstår når flere ækvivalensklasser bliver kombineret. I eksemplet nedenfor kunne en kombination f.eks. være aldersgruppe kombineret med forestillingstidspunktet. Vær opmærksom på: Hvis din test tager udgangspunkt i forretningsviden som testgrundlag, skal du være opmærksom på, at testens dækning vil være afgrænset til den viden forretningen har. Eksempel: I dette eksempel bliver DCoT anvendt i sammenhæng med ækvivalensklasser til at teste de grupperinger af værdier, hvor den systemmæssige adfærd forventes at være den samme. Ækvivalensklasserne er opstillet i et klassifikationstræ. Prisen på biografbilletter afhænger af, hvilken aldersgruppe personen tilhører, forestillingstidspunktet, og om personen er studerende og kan fremvise gyldig legitimation. Dataattributter og tilhørende ækvivalensklasser ses af nedenstående tabel (figur 4): Figur 4: Dataattributter og ækvivalensklasser Dataattributter Aldersgruppe Forestillingstidspunktet Studerende med gyldig legitimation 09 Ækvivalensklasser Barn (100 kr.): Under 18 år Voksen (200 kr.): Mellem 18 år og 67 år Pensionist (50 kr.): Over 67 år Formiddag (rabat på 10 % af prisen, beregnet ud fra aldersgruppe): Før kl. 12 Eftermiddag (aldersgruppepris): Mellem kl. 12 og kl. 18 Aften (plus 10 % oven i prisen, beregnet ud fra aldersgruppe): Efter kl. 18 a (rabat på 10 % af prisen, beregnet ud fra aldersgruppe og forestillingstidspunktet) ej (ingen rabat)

10 I dette eksempel skal testen dække alle kombinationer inden for dataattributterne: Aldersgruppe og Forestillingstidspunktet. Samtidig skal dataattributten Studerende være dækket minimum én gang i hver aldersgruppe. Ud fra denne testdækning kan sammenhængen mellem dataattributterne og ækvivalensklasserne i figur 4 opstilles i et klassifikationstræ som vist nedenfor i figur 5. Figur 5: Klassifikationstræ Biografbillet, pris Aldersgruppe Forestillingstidspunktet Studerende TC 1 < 18 år 18 år og 67 år > 67 år < kl. 12 kl. 12 og kl. 18 > kl. 18 a ej TC 2 TC 3 TC 4 TC 5 TC 6 TC 7 TC 8 TC 9 Klassifikationstræet viser de logiske testcases, der dækker ovenstående krav til testdækning. Et eksempel på, hvordan de logiske testcases kan konkretiseres i fysiske testcases, ses af nedenstående tabel (figur 6). I tabellen er der valgt tre logiske testcases fra klassifikationstræet én per aldersgruppe. Figur 6: Fysiske testcases TC 2 TC 6 TC 8 Alder 13 år 18 år 70 år Forestillingstidspunkt Kl. 11 Kl. 19 Kl. 12 Studerende med gyldig legitimation Pris ej a ej 90 kr. 198 kr. 50 kr. 10

11 Tilstandsovergangstest (STT) Brugbarhed: Tilstandsovergangstest (eller State Transition Testing) er endnu en af de testteknikker, der er ideel til fastlæggelse af testsituationer, når der er brug for test af forretningslogik f.eks. skærmbilleder og skift mellem disse eller forskellige statusobjekter, f.eks. en kundetype, der skifter fra Y til BASIS eller fra BASIS til FORDEL m.m. Testgrundlag: Tilstandsdiagram og/eller strukturerede informationer om objektets forskellige tilstande, og hvad der trigger ændringer i disse. Dækning: Det generelle dækningskriterie er -switch dækning. 0-switch dækning: Her testes alle enkeltovergange. 1-switch dækning: Her testes alle overgangspar. Fejltyper: Typiske defekter er: Manglende eller ekstra tilstand Forkerte overgange Forkerte resultater (output) Tilstande der er identiske, men ikke skal være det Tilstande der er forskellige, men ikke skal være det Tilstande der er døde Tilstande der ikke kan nås. Vær opmærksom på: Ved mange tilstande og overgange mellem disse, kan tilstandsdiagrammet blive svær at overskue. Derfor anbefales det at opdele tilstandsdiagrammet i flere del-diagrammer, hvis det er muligt. Eksempel: Vi vil nu gennemgå et eksempel med en spillemaskine, som er designet til at emulere en gammeldags en-armet-tyveknægt. Spillet er designet som en tilstandsmaskine og har kun følgende mulige tilstande og overgange: Tilstande: 1. VET spillemaskinen er inaktiv, og venter på at der indkastes en mønt. Træk i håndtaget har ingen effekt. 2. KLAR en mønt (gyldig) er blevet indkastet, eller et gratis spil er blevet vundet som et resultat af et foregående spil. 3. SPIL spillet var klar, og der er trukket i håndtaget. 11

12 Overgange: 1. Indkast gyldig mønt den mønt, der indkastes, er valid, og spillemaskinen er derefter klar til brug. 2. Ugyldig mønt/returner den mønt der indkastes, er ikke valid. Mønten returneres og spillemaskinen afventer fortsat. 3. Fortryd/returner mønt der trykkes på knappen fortryd, og mønten returneres, og spillemaskinen afventer. 4. Træk i håndtag der trækkes i håndtaget, og maskinen starter spillet. 5. Vind frit spil genereres tilfældigt, og vinderen får mulighed for et frit spil eller mønten tilbage. 6. Taber spil genereres tilfældigt, og spillemaskinen afventer. På baggrund af ovenstående kan der opstilles et tilstandsdiagram (figur 7) og en tilstandstabel (figur 8). Figur 9 indeholder de testcases, som omfatter 1-switch dækning. Figur 7: Tilstandsdiagram Ugyldig mønt / returner Indkast gyldig mønt VET Fortryd / Returner mønt KLAR Træk i håndtag Taber spil SPIL Vind frit spil 12

13 Figur 8: Tilstandstabel (0-switch dækning): Input Starttilstand Gyldig mønt Ugyldig mønt Fortryd Træk i håndtag Vind Tab Spil Spil Figur 9: Testcases ved 1-switch dækning: Testcase Starttilstand Input Mellemtilstand Input Sluttilstand 1 Ugyldig mønt Ugyldig mønt 2 Ugyldig mønt Gyldig mønt 3 Ugyldig mønt Fortryd 4 Gyldig mønt Træk Spil 5 Fortryd Ugyldig mønt 6 Fortryd Gyldig mønt 7 Træk Spil Tab 8 Træk Spil Vind 9 Spil Tab Ugyldig mønt 10 Spil Tab Gyldig mønt 11 Spil Vind Træk Spil 12 Spil Vind Fortryd 13

14 Beslutningstabeltest (DTT) Brugbarhed: Ved at anvende denne teknik kan du teste funktionalitet 3 bestående af kombinationer af logiske betingelser. Teknikken finder ofte kombinationer af logiske betingelser, som ikke umiddelbart er indlysende for testeren. Testgrundlag: Testgrundlaget til DTT skal indeholde informationer om systemets handlinger og betingelser. Dækning: Ved MCC (Multiple Condition Coverage) er formlen for at finde frem til antal kombinationer, der skal testes, 2 n (n er antal logiske betingelser). Eksempelvis vil 4 betingelser give 16 kombinationer. Ved MCDC (Modified Condition Decision Coverage) reduceres dette til 5, da formlen for MCDC er n+1. Fejltyper: De fejl, som du finder ved hjælp af denne teknik, skyldes fejl, der opstår i forbindelse med, at systemet fortolker kombinationer og tilhørende handling. Vær opmærksom på: Denne teknik kan resultere i et stort antal testcases, hvis der er mange betingelser i spil. Det anbefales generelt maksimalt at have 32 kombinationer, hvilket svarer til 5 betingelser. En betingelse kan enten være sand eller falsk, og antallet af testcases forøges betydeligt, når antallet af betingelser stiger. Herudover er visse kombinationer ikke forenelige, eksempelvis ved betingelser, som udelukker hinanden (en person kan ikke både være over 25 og under 15 år). Kombinationer, der ikke er forenelige, vil ikke kunne testes samtidig og reducerer derfor antallet af testcases. Eksempel: Et luftfartsselskab har et kundeloyalitetsprogram med 3 medlemsklasser: Blå, Sølv og Guld. Blå giver adgang til for-booking af sæder, Sølv giver adgang til for-booking af sæder samt opgraderinger for 200 kr., og Guld giver adgang til for-booking af sæder, gratis opgradering og adgang til privat lounge. Adgang til den private lounge er også tilgængelig for Blå og Sølv medlemmer, som har mere end point. 3 Den type funktionalitet, som er i fokus her, er graden af, hvor korrekt og komplet systemet processerer information. 14

15 En beslutningstabel, som dækker ovenstående eksempel, vil have kunne illustreres på følgende måde (læg mærke til, at uforenelige kombinationer er undladt. En uforenelig kombination er f.eks., at et medlem ikke både kan tilhøre medlemsklasse Blå og Sølv på samme tid. Tabellen indeholder derfor kun de forenelige kombinationer.): Figur 10: Beslutningstabel BETIGELSER REL Klasse Blå Klasse Sølv Klasse Guld > Points HADLIGER For-Booking Opgradering 200 DKK Opgradering Gratis Privat Lounge Du skal som minimum teste 1 testcase pr. kolonne. 15

16 Elementær sammenligningstest (ECT) Brugbarhed: Ved hjælp af denne teknik kan du foretage en detaljeret test af systemets funktionalitet, da teknikken dækker alle beslutningspunkter grundigt. Testgrundlag: Testgrundlaget skal være pseudo-kode eller være tilstrækkeligt detaljeret til at kunne omskrives til pseudo-kode. Dækning: Som udgangspunkt anvendes MCDC. Dækningen kan dog gøres mere eller mindre omfattende ved brug af flere dækningsniveauer. Ved at anvende MCDC sikrer du, at hver enkel betingelse har været den bestemmende faktor i en testcase, og at denne faktor både har været repræsenteret som sand og falsk i det samlede resultat. Fejltyper: De fejl, som du finder ved hjælp af denne teknik, skyldes fejl i implementeringen af betingelser og de tilhørende resultater. Vær opmærksom på: år der er mange beslutningspunkter, kan det være svært at bevare overblikket uden de fornødne hjælpemidler. Du bør derfor anvende værktøjer. Eksempel: I dette eksempel benytter vi MCDC. D1 IF name = Frank OR city = Amsterdam THE pocket money := 5,00 ELSE pocket money := 3,50 EDIF D2 IF age > 10 AD work = Yes THE pocket money := pocket money + 1,00 D3 ELSE IF name = Frank THE pocket money := pocket money + 0,50 EDIF EDIF 16

17 Testsituationerne i MCDC For at identificere testsituationerne skal du først finde den bestemmende faktor og dernæst de neutrale værdier for de enkelte betingelser. Dette udføres på følgende måde: Start med den bestemmende faktor; hvis udfaldet skal være sandt, skal den bestemmende faktor være tallet 1, hvis udfaldet skal være falsk, skal den bestemmende faktor være tallet 0. år du har fundet den bestemmende faktor, skal de neutrale værdier udfyldes. Den neutrale værdi for AD er 1 og den neutrale værdi for OR er 0. Den bestemmende faktor for de enkelte testsituationer er understreget i eksemplet i figur 12. Værdierne for den bestemmende faktor og den neutrale værdi ses af nedenstående tabel (figur 11). Figur 11: Bestemmende faktor og neutral værdi Bestemmende faktor Sandt 1 Falsk 0 eutral værdi AD OR 1 0 Figur 12: Detaljerede testsituationer D1: A OR B A: name = Frank 1 pocket money = 5, (1) pocket money = 3,50 B: city = Amsterdam 0 1 (2) 0 0 (3) D2: A AD B 1 pocket money + 1,00 0 A: age > (1) 0 1 (2) B: work = Yes (3) D3: A 1 pocket money + 0,50 0 A: name = Frank 1 (1) 0 (2) 17

18 Figur 13: Graf over testsituationer De betingelser, som gensidigt udelukker hinanden: D1.1 D3.2 Er udelukket, idet navnet i D1.1 er Frank, og i D3.2 er ikke Frank D1.2 D3.1 Er udelukket, idet navnet i D1.2 er ikke Frank, og i D3.1 er Frank D1.3 D3.1 Er udelukket, idet navnet i D1.3 er ikke Frank, og i D3.1 er Frank 18

19 Udforskende test (ET) Brugbarhed: De test, som udføres med afsæt i denne teknik, bliver designet samtidig med, at testen gennemføres. Teknikken er derfor afhængig af den konkrete viden, som testeren har om systemet og til det forretningsområde, som systemet understøtter. ET er på den måde et dynamisk sammenspil mellem læring, design og testafvikling, som illustreret i nedenstående figur 14. Figur 14: ET Læring Testdesign Testafvikling Dækning: Teknikkens dækning afhænger af testerens kendskab til det forrentningsområde, som systemet understøtter og til testdesignteknikker. Dækningen afhænger også af beskrivelsen af den ønskede test, som kan angives i et charter, som vist nedenfor i eksemplet. Hvilke fejl findes: Se beskrivelsen under ovenstående afsnit vedrørende dækning. Vær opmærksom på: De test, der udføres med ET-teknikken, sker med udgangspunkt i det leverede system, og rammerne for testen afgøres derfor af systemets tilstand. Teknikken er erfaringsbaseret, og testens kvalitet er derfor afhængig af testerens egen erfaring inden for forretningsområdet, systemet og test. Testgrundlag: Test i ET udføres ikke ud fra opstillede testcases, men tager udgangspunkt i det leverede system, samt det formål, som er opstillet for en session, der er defineret i et sessionscharter. Eksempel: Der findes flere forskellige tilgange til ET. I dette eksempel har vi valgt at fokusere på sessionsbaseret ET, hvor der benyttes charteres. I sessionsbaseret ET udfylder testeren et charter, som anvendes til at styre testen. I figur 15 er en liste over emner, som kan indgå i et sessionscharter. 19

20 Figur 15: Sessionscharter Eksempler til indhold i session charters ID Formål avn på tester Dato Varighed / Time box Forudsætninger Funktionalitets område1 Funktionalitets område 2 Testideer Orakelnoter Identifikation af dokument Formål med test i forbindelse med dette charter avn på udførende testere d.d. Det anbefales at fastsætte en tidsramme for udførslen af det enkelte charter. Anbefalingen er mellem ½-2 timer Forudsætninger for at testen kan udføres Et område hvor testen skal udføres Et område hvor testen skal udføres Ustruktureret liste af testideer der kan være med til at afdække funktionalitetsområdet Eventuelle input fra en forretningsspecialist om systemets forventede adfærd Referencer: TMap ext Testteknikker i praksis, Leo van der Aalst ISTQB Advanced Test Analyst Kursusmateriale fra Capgemini Sogeti Danmark A/S TMap ET Test Engineer Kursusmateriale fra Capgemini Sogeti Danmark A/S 20

21 Egne noter 21

22 Egne noter 22

23 Egne noter 23

24 Om forfatterne Om Ole Chr. Hansen: Ole Chr. Hansen er Managing Consultant hos Capgemini Sogeti Danmark A/S. Har arbejdet med testrådgivning og -ledelse i mere end 15 år, og har også arbejdet som projektleder, it-analytiker m.m. Er ISTQB godkendt underviser på både foundation og avanceret niveau, og er ISEB Practitioner Certified, TMap ET Test Engineer Certified, TPI ET Foundation Certified, PRICE2 Foundation Certified, Certified Scrum Master og Certified Lead Assessor (ISO 9000). Om Anne Melsing: Anne Melsing er test management konsulent hos Capgemini Sogeti Danmark A/S. I sit virke som konsulent hos Capgemini Sogeti, har Anne arbejdet med test og procesforbedringer. Hun er oprindeligt uddannet Cand. Soc. og er certificeret i TMap ET Test Engineer, ISTQB Foundation, TPI ET Foundation og CAT (Certified Agile Tester). Om Steen Skardhamar: Steen Skardhamar er teknisk tester hos Capgemini Sogeti Danmark A/S. Arbejder med automatiseret test på mobile enheder, desktop browsere og API. Har erfaring med opsætning og drift af cloudbaseret automatiseret test med speciale i automatiseret test på ios og Android samt cucumber og selenium webdriver. Om atasha Kehler: atasha Kehler er certificeret i TMap ET Test Engineer hos Capgemini Sogeti Danmark A/S. atasha har arbejdet med kravspecificering og test af især offentlige it-systemer. atasha har således et stort kendskab til kvalitetssikring af lovbaserede it-systemer.