Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Risiko basert testing i praksis

633 views

Published on

Erfaringer fra bruk av Riskobasert testing fra et implementeringsprosjekt - Foredrag på Testdagen ODIN 23.09.2014 - Radisson Hotel i Nydalen

Published in: Software
  • Be the first to comment

Risiko basert testing i praksis

  1. 1. Risikobasert tes,ng (RBT) – Fungerer det i praksis? Minh Nguyen – Knowit Arild Tarjei Nygaard – Strex 24.9.2014 – Testdagen ODIN
  2. 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. 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. 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. 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. 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. 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. 8. Risikostyringsprosess Identifisere Analysere Korrigere Gjennomføre Definere tiltak
  9. 9. Risikostyringsprosess i samspill med testprosess Test-planlegging Test- Rapportering Identifisere Analysere Korrigere Gjennomføre Definere tiltak Test-design Test-gjennomføring
  10. 10. Risikostyringsprosess i samspill med testprosess Test-planlegging Test- Rapportering Identifisere Analysere Korrigere Gjennomføre Definere tiltak Test-design Test-gjennomføring
  11. 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. 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. 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. 14 Innblikk i arbeidsdokumentet…
  15. 15. 15 Innblikk i arbeidsdokumentet… • Completeness • Accuracy • Efficiency • Interoperabiity • Concurrency • Data diversity • Extensibility
  16. 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. 17. Risikostyringsprosess i samspill med testprosess Test-planlegging Test- Rapportering Identifisere Analysere Korrigere Gjennomføre Definere tiltak Test-design Test-gjennomføring
  18. 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. 19. Kopling av test cases ,l risiko i Jira… 19
  20. 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. 21. Risikostyringsprosess samspill med testprosess Test-planlegging Test- Rapportering Identifisere Analysere Korrigere Gjennomføre Definere tiltak Test-design Test-gjennomføring
  22. 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. 23
  24. 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. 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. 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. 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. 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. 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. 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. 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. 32. Takk for oss… Spørsmål & Tilbakemelding

×