2. Målsetninger
med
foredraget
1. Dele
våre
erfaringer
med
å
ta
i
bruk
risikobasert
tes,ng
(RBT)
i
et
reelt
prosjekt.
2. Våre
vurderinger
på
om
RBT
gir
økt
verdi
for
virksomheten
seS
fra
– Forretning
– TesTagfolk
3. ”Take-‐aways”
2
3. Om
foredragsholdere
Minh
Nguyen
Sjefskonsulent
/
Partner
www.knowit.no
1200
IT 400
Design
&
Digital 200
Management
§ Nordisk
konsulentselskap
§ 3
virksomhetsområder
§ 400
spesialister
i
Norge
-‐
kontorer
i
Oslo,
Bergen,
Stavanger
og
Kris,ansand
§ Minh
kommer
fra
IT
–
Test
og
Kvalitetssikring
enhet.
4. Om
Strex
Arild
Tarjei
Nygaard
COO
www.strex.no
§ Strex
er
eid
av
mobiloperatørene
Telenor,
NetCom
og
Tele2
(like
eierandeler)
§ Strex
skal
levere
betalingstjenester
,l
alle
som
har
en
mobiltelefon
uavhengig
av
hvilke
operatør
de
benySer
seg
av.
§ I
1999
startet
mobiloperatørene
med
betalingstjenester
– Startet
med
spill,
bakgrunnsbilder,
ringetoner,
og
TV-‐vo,ng
etc
§ Ca.
800.000
unike
brukere
i
måneden.
§ SniS
transaksjon
på
20,-‐
NOK
§ BruSo
brukerstedomsetning
på
1
milliard
NOK
i
2013
§ Har
konsesjon
som
e-‐pengeforetak
(jf.
finansieringsvirksomhetsloven
kap
4
C)
5. Om
prosjektet
§ Mandat:
– Konsolidere
4
eksisterende
betalingsløsninger
for
mobiloperatører
– Implementere
nye
tjenester
og
betalingskilder
§ Teknologi:
– Sky-‐basert
SaaS
§ Project
organisasjon
– Prosjektmedlemmer
spredt
rundt
(India,
Singapore,
SeaSle
and
Melbourne)
– Akseptansetes,ng
i
Norge
6. Krav
,l
den
nye
plaaormen
§ Krav
– Funksjonalitet
–
E-‐penge
kon,,
Web
portal,
SeSlement,
Repor,ng.
– Lovkrav
–
Konsesjon,
Hvitvaskingsloven,
Finansavtaleloven
mm.
– Ytelse–
Skalerbar
med
utgangspunkt
i
dagens
løsning.
– Brukervennlighet
–
Minst
mulig
friksjon
som
er
mulig
å
oppnå.
– Sikkerhet
–
Sikkerhet
rundt
brukerinformasjon
og
transaksjonsinformasjon.
– Tilgjengelighet
–
24/7/365
– Integrasjon
–
4
operatører
+
mange
flere.
6
7. UTordringer
og
mo,vasjon
§ UTordringer
– Antall
krav
i
forespørsel:
270
– Høyt
antall
forretningsregler
–
antall
mulige
permutasjoner
466.560
– Antall
integrasjoner:
15
per
mobiloperatør
§ Mo,vasjon
– ”Risikobasert
tes,ng
gjør
tes,ng
virkningsfull
ved
å
teste
rik,ge
,ngene”
– Er
det
virkelig
sant?
13. Risikoanalyse
Sannsynlighet
(S)
§ Foretrekker
kvalita,v
vurdering
basert
på:
– Leverandør
tekstdokumenter
– Løsningsdesign
13
Forretningsmessig
konsekvens
(K)
§ Baseres
på
consensus
,lnærming
Risikoprioritet
=
helhetsvurdering
av
S
og
K
• Kri,sk,
Alvorlig
og
Normal
• Blir
rangert
i
forhold
,l
hverandre
15. 15
Innblikk
i
arbeidsdokumentet…
• Completeness
• Accuracy
• Efficiency
• Interoperabiity
• Concurrency
• Data diversity
• Extensibility
16. Erfaringer
med
testplanlegging
i
RBT
§ Interessentenes
forpliktelse
og
engasjement
er
vik,g.
§ Enklere
å
kommunisere
risiko
mht
forretningsmessige
konsekvenser.
§ Gjør
risikoeier
ansvarlige.
§ Nyrg
,lnærming
for
å
iden,fisere
”problem-‐områder”.
§ Foretrekker
kvalita,v
fremfor
kvan,ta,v
,lnærming.
16
17. Risikostyringsprosess
i
samspill
med
testprosess
Test-planlegging
Test-
Rapportering
Identifisere
Analysere
Korrigere
Gjennomføre Definere tiltak
Test-design
Test-gjennomføring
18. Testdesign
§ Bruker
Jira
for
å
administrere
og
linker
risikoer
sammen
med
test
cases
og
defekter.
§ Definerer
test
cases
iht
risikoprioritering
§ Testene
kan
gjennomføres
før
all
test
cases
er
ferdig
definert
18
20. Erfaring
med
testdesign
i
RBT
§ Risikoprioritering
gir
en
reSesnor
for
testdesign
mht.
§ Detaljering
§ Kombinasjoner
av
forretningsregler
§ Rekkefølge
av
ferdigs,llelse
§ Kan
leS
bli
overfokusert
på
risikoer
og
glemmer
de
opplagte
kravene
som
også
trenger
å
bli
testet.
§ Tungvint
med
å
vedlikeholde
koplinger
mellom
risiko
og
test
cases
i
Jira.
22. Testgjennomføring
og
-‐rapportering
§ Gjennomføre
test
cases
som
er
knySet
,l
de
høyt
prioriterte
risikoene
først.
§ Samle
inn
relevante
metrikker
for
revurdering
av
risiko
og
igangserng
,ltak
22
24. Eksempler
på
,ltak
,l
R-‐C3
basert
på
metrikker
§ Tester
sammen
med
leverandør
,dlig.
§ Flere
testere.
§ Manuell
,l
automa,sert
test.
§ SeSe
deler
av
leveranse
i
produksjon.
25. Erfaring
med
testgjennomføring
og
-‐rapportering
§ Nyrg
å
ha
måledataene
for
å
styre
testgjennomføringen.
§ Tidskrevende
datainnsamling
i
større
kontekst
–
Trenger
bedre
verktøystøSe.
§ Vik,g
å
holde
interessenter
fokusert
og
bruker
dataene
,l
å
ta
beslutninger.
26. Målsetninger
med
foredraget
1. Dele
våre
erfaringer
med
å
ta
i
bruk
risikobasert
tes,ng
(RBT)
i
et
reelt
prosjekt.
2. Våre
vurderinger
på
om
RBT
gir
økt
verdi
for
virksomheten
seS
fra
– Forretning
– TesTagfolk
3. ”Take-‐aways”
26
27. Forretningens
vurdering
av
RBT
§ Økt
bevissthet
på
risiko.
§ Skil
av
fokus
fra
funksjonalitet
,l
”business
impact”.
– Fokusere
på
de
områder
som
påvirker
forretningens
virksomhetskri,ske
prosesser
§ Konsentrere
om
”de
reSe
,ngene”
når
det
stormer.
§ Foreta
beslutninger
basert
på
fakta
§ Konstant
dialog
med
oppdragsgiver
–
hva
som
gir
«business
impact»
kan
endre
seg
underveis
28. RBT
–
Fungerer
det?
§ RBT
nødvendig
men
ikke
,lstrekkelig.
§ Størst
gevinst
i
testplanlegging
og
testgjennomføring/-‐rapportering.
§ Kan
man
komme
frem
,l
samme
,ltak/beslutninger
uten
RBT?
– Tja
–
men
er
,lfeldig
og
personavhengig
– Med
RBT
er
beslutninger
velfunderte,
forankret,
rasjonelle
og
fakta-‐basert.
§ Vil
jeg
bruke
det
i
neste
prosjekt?
– JA
J
28
29. Målsetninger
med
foredraget
1. Dele
våre
erfaringer
med
å
ta
i
bruk
risikobasert
tes,ng
(RBT)
i
et
reelt
prosjekt.
2. Våre
vurderinger
på
om
RBT
gir
økt
verdi
for
virksomheten
seS
fra
– Forretning
– TesTagfolk
3. ”Take-‐aways”
29
30. Take-‐aways
• Sikre
at
forutsetninger
er
,lstede
• SeSe
mål
og
forventning
• Sikre
god
støSe
fra
interessenter
• Gjøre
risikoeiere
ansvarlige
• Tenk
stort
men
start
småS
31. Referanser
§ ISO
9126
Solware
Quality
Characteris,cs
and
James
Bach
(CRUCSPIC)
– hSp://thetesteye.com/posters/TheTestEye_SolwareQualityCharacteris,cs.pdf
– hSp://www.kvalitetsentusiastene.no/?p=131868
(oversaS
,l
norsk)
§ PRISMA
Approach
–
Erik
van
Veenendaal
§ James
Bach
–
Risk
based
tes,ng
– hSp://nilachakra.org/documents/material/L%20-‐%20RiskAnalysis.pdf
§ Hans
Schaefer
–
Risk
based
tes,ng
– hSp://www.cs.tut.fi/tapahtumat/testaus04/schaefer.pdf