Nye testteknikker fra ISTQB

- direkte fra hylderne

Ole Chr. Hansen

TestExpo

29. Januar 2015

© Capgemini Sogeti

Præsentation

Ole Chr. Hansen • Managing Consultant

• Fellow – SogetiLabs – Global Innovation Team

• Blog - http://ochansen.blogspot.com

• LinkedIn: www.linkedin.com/in/ochansen

• Twitter: www.twitter.com/Ole_Chr_Hansen

• ISTQB Accredited Trainer in Software Testing

• ISEB Practitioner Certificate in Software Testing

• ISTQB Foundation Certificate in Software Testing

• TMap NEXT® Test Engineer Certificate

• TPI NEXT® Foundation Certificate

• PRINCE2 Foundation Certificate

• Certified Scrum Master

• Certified Lead Assessor (ISO 9000)

• Sogeti, ATP, Nordea, BRFkredit, WM-data, CRI, LEC

• 15+ år inden for softwaretest, 10+ år inden for it-udvikling/projektledelse

2

© Capgemini Sogeti

Test teknikker – Testanalytikerens værktøjskasse

3

© Capgemini Sogeti

Hvad er nyt

Testteknik ISTQB ATA Pensum

2007 2012

Ækvivalenspartitionering X X

Grænseværdianalyse X X

Beslutningstabeller X X

Årsags-virkningstest X X

Tilstandsovergangstest X X

Klassifikationstræmetode X X

Parvis test X X

Ortogonale arrays (del af parvis test) X X

Usecase test X X

Userstory test X

Domæneanalyse X

4

Domæneanalyse

© Capgemini Sogeti

Domæneanalyse – Introduktion

Et domæne er et defineret sæt af værdier.

Lige som ækvivalenspartition – alle værdierne i en partition forventes at blive

håndteret på samme måde af systemet:

• Hvis en værdi fungerer – så fungerer alle

• Hvis en værdi fejler – så fejler alle

Endimensionelt domæne – en variabel.

Multidimensionelt domæne – to eller flere variable som interagerer.

Eksempel:

Mænd over 24 år og under 66 år, og med vægt over 69 kg og under 90 kg.

Præmis for at det er

en partition

6

© Capgemini Sogeti

Domæneanalyse – Fordele

Brug af ækvivalenspartitionering og grænseværdianalyse vil få antallet af testcases til

at stige eksponentielt.

Domæneanalyse:

• Har den fordel, at den kun vil give en liniær stigning i antal testcases.

• Vil kunne finde defekter i multidimensionelle domæner, som de større testsæt ikke vil

finde.

• Det kræver it-understøttelse at bestemme værdierne til testcases ved 3 eller flere

dimensioner.

7

© Capgemini Sogeti

Domæneanalyse – Anvendelighed

Anvendelighed:

• Kombinerer de teknikker, der anvendes for beslutningstabeller,

ækvivalenspartitionering og grænseværdianalyse.

• Identificerer et mindre antal testcases

• Dækker de vigtigste områder

• Sandsynlige fejlområder.

• Anvendes ofte, hvor beslutningstabeller bliver for store grundet et stort

antal variable/betingelser.

• Kan anvendes på alle testniveauer – mest integrations- og systemtest.

8

© Capgemini Sogeti

Domæneanalyse – Begrænsninger

Begrænsninger:

• Kræver en stærk forståelse af softwaren for at identificere

domænerne og den eventuelle interaktion mellem dissse.

• Hvis et domæne er uidentificeret kan testen blive

mangelfuld – men vil sandsynligvis blive fundet for nogle af

værdierne vil lande der.

• Mest anvendelig til partitioner der består af kontinuerte

værdier.

9

© Capgemini Sogeti

Domæneanalyse – Definition

Domæneanalyse – En black-box testdesignteknik, der bruges til at identificere

effektive og egnede testcases, når flere variabler kan eller bør testes sammen. Den

bygger på og generaliserer ækvivalenspartitionering og grænseværdianalyse. Se også

grænseværdianalyse, ækvivalenspartitionering.

Grænseværdianalyse - En black-box testdesignteknik, hvor testcases designes

baseret på grænseværdier.

Ækvivalenspartitionering - En black-box testdesignteknik, hvor testcases er designet til

at eksekvere repræsentanter fra ækvivalenspartitioner. I princippet designes testcases

til at dække hver partition mindst en gang.

Kilde: ISTQB Terminologiliste, version 2.2

10

© Capgemini Sogeti

Domæneanalyse – Typiske defekter

• Defekter omfatter

• funktionelle problemer inden for domænet

• grænseværdihåndtering

• problemer med interaktion mellem variable

• fejlhåndtering

• specielt for de værdier, der ikke er i et gyldigt domæne

11

© Capgemini Sogeti

Domæneanalyse - Værdier

INDE: Repræsenterer en værdi, der er i partitionen/domænet.

UDE: Repræsenterer en værdi, der er uden for

partitionen/domænet/grænsen.

PÅ: Repræsenterer en værdi på grænsen af partitionen/domænet.

UDENFOR: Repræsenterer en værdi lige uden for partitionens/domænets

grænse – mindst mulige nominelle værdi.

Ved bestemmelse af disse værdier testes hver partition sammen med

dens grænsebetingelser.

Vær opmærksom på:

• LUKKEDE grænser (>=, <=, =) PÅ er i domænet

• ÅBNE grænser (<, >) PÅ er ikke i domænet

12

© Capgemini Sogeti

Domæneanalyse – Værdier / Optimere testen

50

50

100

100

150

150

200

200 X

Y

D1 D2

Optimering af testen – ingen

gentagelse af en test.

En INDE værdi for et domæne

er en UDE værdi for andet.

PÅ

UDENFOR

INDE – D2

UDE – D1

13

© Capgemini Sogeti

Domæneanalyse – Dækningskriterier

Dækning: Graden, udtrykt som en procentdel, af aktivering af et specificeret

dækningselement ud fra en sekvens af testcases.

Dækningselement: En enhed eller egenskab, der anvendes som grundlag for

testdækning.

Dækningskriterier for domæneanalyse:

Minimumsdækning for domæneanalyse vil være at have en test for hver INDE, UDE, PÅ og UDENFOR-værdi for hvert domæne.

Hvor der er overlap mellem værdierne, er der ingen grund til at gentage testen. Derfor

er der ofte færre end fire tests pr. domæne.

14

© Capgemini Sogeti

Domæneanalysematrix

Variabel Betingelse Type 1 2 3 4 5 N

V1 B1 PÅ

UDENFOR

B2 PÅ

UDENFOR

Bn PÅ

UDENFOR

Typisk INDE

Forventet resultat

Hver kolonne har præcis en værdi

pr. variabel

En værdi er i PÅ eller UDE – alle andre i INDE

15

© Capgemini Sogeti

Domæneanalysematrix

Domæneanalysematricen udfyldes som følger:

1. Udfyld variabelnavne

2. Udfyld betingelser

3. Tilføj TYPISK for hver variabel

4. Tilføj PÅ og UDE

5. Tilføj værdier til alle variable

6. Udfyld INDE værdien

7. Udfyldt næste kolonne – ved brug af PÅ og UDE rækkerne

16

© Capgemini Sogeti

Domæneanalyse - Eksempel

• Entre-billet til et arrangement koster 200 DKK.

• Kun hele DKK.

• Der kan betales kontant og/eller med kreditkort

• Kun kontant

• Kun kreditkort

• Kombination af kontant og kreditkort (summerer til

200 DKK)

17

© Capgemini Sogeti

Domæneanalyse - Eksempel

Domænet: Kontant

0

PÅ

Grænse

Kontantbetingelse:

X >= 0

45

INDE

Alle værdier mindre end 0

Alle værdier

større end 0

-1

UDENFOR

-155

UDE

18

© Capgemini Sogeti

Domæneanalyse - Eksempel

Domænet: Kreditkort

0

PÅ

Grænse

Kreditkortbetingelse:

X >= 0

155

INDE

Alle værdier mindre end 0

Alle værdier

større end 0

-1

UDENFOR

-12

UDE

19

© Capgemini Sogeti

Domæneanalyse - Eksempel

Domænet: Kombination af Kontant og Kreditkort

200

PÅ

Grænse

Betingelse:

Kontant + Kreditkort = 200 DKK 201

UDE

Alle værdier mindre end

200

Alle værdier

større end 200

199

UDENFOR

© Capgemini Sogeti

Domæneanalyse - Eksempel

50

50

100

100

150

150

200

200 Kreditkort

Kontant

© Capgemini Sogeti

Domæneanalyse - Eksempel

Variabel Betingelse Type 1 2 3 4 5 6 7

Kontant X >= 0 PÅ 0

UDENFOR -1

Typisk INDE 45 45

Kreditkort X >= 0 PÅ 0

UDENFOR -1

Typisk INDE 155 155

Kombineret K&KK X + Y = 200 PÅ 45/15

5

UDENFOR 159/4

0

UDENFOR 121/8

0

INDE

Forventet resultat Ej OK

Ej OK

Ej OK

Ej OK

OK Ej OK

Ej OK

© Capgemini Sogeti

Domæneanalyse - Multidimensionelt

Viste eksempel – to-dimensioner.

Kunne være multi-dimensionelt: Anvendelse af flere kreditkort.

23

User story test

© Capgemini Sogeti

Agile…….

Agile metoder – f.eks. Scrum forberedes kravene i form af

user stories, som beskriver små funktionelle enheder, der kan designes,

udvikles, testes og demonstreres i en enkelt iteration.

25

© Capgemini Sogeti

User story test

• User story:

– Titel og nummer

– Som________

– Vil jeg____________

– Med det formål at_____________

– Værdi, Risiko, Estimat, Acceptkriterier

26

© Capgemini Sogeti

User story test – Definition

User story test – En black-box testdesignteknik hvor testcases designes med

udgangspunkt i user stories for at kontrollere at disse er korrekt implementeret. Se også user story.

User story - Et høj-niveau bruger- eller forretningskrav, almindeligvis anvendt i agil softwareudvikling, typisk

bestående af en eller flere sætninger i hverdags- eller forretningssprog, og som beskriver hvilken funktionalitet en

bruger behøver, eventuelle ikke-funktionelle kriterier, samt godkendelseskriterier. Se også agil softwareudvikling,

krav.

Agil softwareudvikling - En gruppe af softwareudviklingsmetodikker baseret på iterativ inkrementel udvikling, hvor

krav og løsninger udvikles gennem et samarbejde mellem selvorganiserende tværfunktionelle teams.

Krav - En betingelse eller evne, som en bruger behøver for at løse et problem eller opnå et mål, der skal opfyldes

af - eller være indeholdt i - systemet eller systemkomponenten for at opfylde en kontrakt, standard, specifikation

eller andet formelt indført dokument. [Efter IEEE 610]

Kilde: ISTQB Terminologiliste, version 2.2

27

© Capgemini Sogeti

User story test – Typiske defekter

• Defekter er normalt funktionelle

• der leveres ikke den specificerede funktionalitet

• integrationsproblemer med funktionaliteten der allerede er

implementeret ses også

• Stories udvikles uafhængigt

• der kan forekomme performance-, interface- og

fejlhåndteringsproblemer

• Vigtigt at teste både den leverede funktionalitet og

integrationen ved frigivelse af en ny story.

28

© Capgemini Sogeti

User story test – Dækningskriterier

Dækning: Graden, udtrykt som en procentdel, af aktivering af et specificeret

dækningselement ud fra en sekvens af testcases.

Dækningselement: En enhed eller egenskab, der anvendes som grundlag for

testdækning.

Dækningskriterier for user story test:

Minimum dækning af en user story er at verificere, at hvert af de

specificerede acceptkriterier er blevet opfyldt.

29

© Capgemini Sogeti

User story test – Anvendelse

Anvendelse

• Anvendes primært i agile og tilsvarende iterative og inkrementelle

miljøer

• Både funktionel og ikke-funktionel test

• Test på alle niveauer

• Udvikleren demonstrerer user storyens implementerede

funktionalitet for teamet.

30

© Capgemini Sogeti

User story test – Begrænsninger

Begrænsninger

• Små forøgelser af funktionalitet

• Udvikle og bruge stubbe og drivere

• Bruge API-værktøjer

• Normalt udviklerens opgave og ansvar

• Kontinuert integrationsmodel – ses ofte i agile projekter

• Behovet for stubbe og drivere minimaliseret

• F.eks. Først laves en succes-scenarie denne kode kan dermed

anvendes af andre udviklere i stedet for stubbe/drivere.

• Der mangler fortsat fejlhåndtering, afvisning af ugyldige værdier m.m.,

hvilket leveres senere.

• HUSK: Behovet for regressionstest vil øges for alle iterationer efter den

første.

31

© Capgemini Sogeti

User story test – Eksempel

Testcases gængse kreditkort: Dankort, VISA, Mastercard, Diners, Amex…..

Kreditmax tjek: Inden for kreditmax, på kreditmax, overskreden kreditmax

……..

– User story: 1 – Køb med kreditkort

– Som KUNDE

– Vil jeg KUNNE BETALE MED KREDITKORT

– Med det formål at KØBE PRODUKTER

– Acceptkriterier:

– Alle gængse kreditkort

– Kreditmax tjek

– ……

32

Afslutning

© Capgemini Sogeti

Hvad er nyt

Testteknik ISTQB ATA Pensum

2007 2012

Ækvivalenspartitionering X X

Grænseværdianalyse X X

Beslutningstabeller X X

Årsags-virkningstest X X

Tilstandsovergangstest X X

Klassifikationstræmetode X X

Parvis test X X

Ortogonale arrays (del af parvis test) X X

Usecase test X X

Userstory test X

Domæneanalyse X

34

© Capgemini Sogeti

Spørgsmål

35