Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Risiko basert testing i praksis

704 vues

Publié le

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

Publié dans : Logiciels
  • Soyez le premier à commenter

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

×