Risiko basert testing i praksis

1. Risikobasert tes,ng (RBT) – Fungerer det i praksis? Minh Nguyen – Knowit Arild Tarjei Nygaard – Strex 24.9.2014 – Testdagen ODIN

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?

8. Risikostyringsprosess Identifisere Analysere Korrigere Gjennomføre Definere tiltak

9. Risikostyringsprosess i samspill med testprosess Test-planlegging Test- Rapportering Identifisere Analysere Korrigere Gjennomføre Definere tiltak Test-design Test-gjennomføring

11. 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

12. 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 • Hardware compatibility • OS compatibility • Application compatibility • Configuration compatibility • Backward compatibility • Forward compatibility • Sustainability • Standards Conformance • System requirements • Installability • Upgrades • Uninstallation • Configuration • Deployability • Maintainability • Testability • Capacity • Resource Utilization • Responsiveness • Availability • Throughput • Endurance • Fedback • Scalability

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

14. 14 Innblikk i arbeidsdokumentet…

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

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

19. Kopling av test cases ,l risiko i Jira… 19

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.

21. Risikostyringsprosess samspill med testprosess Test-planlegging Test- Rapportering Identifisere Analysere Korrigere Gjennomføre Definere tiltak Test-design Test-gjennomføring

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

23. 23

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.

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

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

32. Takk for oss… Spørsmål & Tilbakemelding

Risiko basert testing i praksis

Vous êtes en train de lire un aperçu.

Consultez-les par la suite

Risiko basert testing i praksis

Plus De Contenu Connexe

Les utilisateurs ont également aimé (20)

Similaire à Risiko basert testing i praksis (20)

Plus par Minh Nguyen (7)