Risiko basert testing i praksis

Risikobasert tes,ng (RBT) – Fungerer det i praksis?

Minh Nguyen – Knowit Arild Tarjei Nygaard – Strex 24.9.2014 – Testdagen ODIN

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

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.

Om Strex

§  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)

Arild Tarjei Nygaard COO www.strex.no

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

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

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?

Risikostyringsprosess

Identifisere

Analysere

Definere tiltak Gjennomføre

Korrigere

Test- planlegging

Test- design

Test- gjennomføring

Test- Rapportering

Risikostyringsprosess i samspill med testprosess

Identifisere

Analysere


Korrigere

Test- planlegging

Test- design


Test- Rapportering


Identifisere

Analysere


Korrigere

Testplanlegging

§  Innsalg

§  Involvere interessenter med relevante ansvarsområder: –  Produkt, Salg, Arkitektur, Dril, Finans og Compliance

§  Idedugnad –  Iden,fisere og rangere ”produkt-‐risikoer” –  Ansvarliggjøre risikoeiere

11

ISO-‐9126 – SW Quality Characteris,cs som sjekkliste…

• Completeness • Accuracy • Efficiency • Interoperabiity • Concurrency • Data diversity • Extensibility

• Stability • Robustness • Stress handling • Recoverability • Data Integrity • Safety • Disaster Recovery • Trustworthiness

• Affordance • Intuitiveness • Minimalism • Learnability • Memorability • Discoverability • Operability • Interactivity • Control • Clarity • Erros • Consistency • Tailorability • Accessibility • Documentation

• Uniqueness • Satisfaction • Professionalism • Attractiveness • Curiosity • Entrancement • Hype • Expectancy • Attitude • Directness • Story

• Authentication • Authorization • Privacy • Security • Secrecy • Invulnerability • Virus-free • Piracy Resistance • Compliance

• Capacity • Resource Utilization • Responsiveness • Availability • Throughput • Endurance • Fedback • Scalability

• System requirements • Installability • Upgrades • Uninstallation • Configuration • Deployability • Maintainability • Testability

• Hardware compatibility • OS compatibility • Application compatibility • Configuration compatibility • Backward compatibility • Forward compatibility • Sustainability • Standards Conformance

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

14

Innblikk i arbeidsdokumentet…

15

Innblikk i arbeidsdokumentet…

• Completeness • Accuracy • Efficiency • Interoperabiity • Concurrency • Data diversity • Extensibility

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

Test- planlegging

Test- design


Test- Rapportering


Identifisere

Analysere


Korrigere

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

Kopling av test cases ,l risiko i Jira…

19

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.

Test- planlegging

Test- design


Test- Rapportering

Risikostyringsprosess samspill med testprosess

Identifisere

Analysere


Korrigere

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

23

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.

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

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

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

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

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

Spørsmål & Tilbakemelding

Takk for oss…

Software

Risiko basert testing i praksis