Upgrade to Pro — share decks privately, control downloads, hide ads and more …

[DevDojo] Quality Assurance Policy

[DevDojo] Quality Assurance Policy

Quality Assurance (QA) is vital for consistently delivering services in a safe and secure manner within fast development cycles. In this course, we will explain the QA processes, tools, and techniques used to efficiently identify and resolve problems.

mercari

May 26, 2023
Tweet

More Decks by mercari

Other Decks in Technology

Transcript

  1. 2 Quick intro! Masami Yajiri / @myajiri QA Engineer at

    Merpay • QA(9y)<PreSales&Consultant(7y)<???(7y) • Number of experienced:7 Companies • As QA-Lead, I am in charge of quality assurance of payment systems (QR code, online payment). • Initiator of QA Policy • Hobbies: marathon🏃 & trail running🏔 + hot springs ♨ • Side note: I was a Shinto priest before I became an IT engineer.⛩
  2. 5 A seamless society is one where the world is

    allowed to stay complicated and in which people can live connected, without being separated by borders.
  3. 6 When people's safety and security is threatened, society responds

    by growing more simplified and putting up new borders.
  4. 7 To create a seamless society, we need to fight

    anything that would threaten that safety and security.
  5. 8 Goal of the QA Policy QA becomes the glue

    holding teams together. QA does everything for the sake of quality and value. QA has dialogue with teams about the product and projects. 01 02 03 We want to achieve agile QA.
  6. 9 What is “quality”? On every project, the meaning of

    “quality” is constantly changing. QA aims to implement the best practices amidst a definition of quality that is always changing depending on the conditions at that time. Value for the user The immutable definition: “Quality” means value for the user. What’s quality?
  7. 10 All for One
 Siloing
 PM Engineer QA KPI KPI

    KPI 
 
 Values
 Delivery QA for Everyone: Everyone works to ensure quality, regardless of role
  8. 11 “QA for Everyone,” where everyone works to ensure quality

    regardless of role Lusser’s Law R s ・・・Reliability of the overall product r n ・・・Reliability of the individual components
 An approach that raises the total reliability of QA by leveraging the sum total processes of the company (everybody) rather than relying solely on specific processes (tests, etc.) 90%^10=35%(↓) Aiming to ensure all components are as good as they can be = reliable product
  9. 13 What we care about It’s more about constantly running

    tests rather than running tests right at the end. It’s more about preventing bugs from occurring than finding bugs. It’s more about testing value rather than checking functionality. It’s more about creating the best system possible than aiming to break it. It’s more about proactively taking responsibility as a team rather than standing around and wondering whose responsibility it is. Ref) :https://www.growingagile.co.za/2015/0 4/the-testing-manifesto/ 
 The TESTING Manifesto
  10. 14 Always be testing All delivery processes require testing! Ref)

    https://danashby.co.uk/2016/10/19/c ontinuous-testing-in-devops/ 
 

  11. 16 Implementing adequate testing for release No failures capable of

    causing a major incident 01 Creates sufficient value as-is 02 Product value exceeds residual risk 03 Gains from a timely release would exceed damage from a delayed release 04 Once the team has the groundwork in place enabling them to sufficiently ensure the product (or feature) operates in the production environment according to the acceptance criteria, provides value, and generates profit, they can finally release the product.
  12. 17 What is testing? Studying the product and exploring what

    it does [Ref] Testing and Checking Refined The product operates just as described by criteria and in the specs
  13. 18 Value and risk [Source] From The Union of Japanese

    Scientists and Engineers’ The Kano Model and Product Planning Upside (Value) Downside Risk
  14. 19 Value and risk Risk Category
 The Kano Model
 Details


    Examples
 Results
 Metrics (TBD)
 Downside
 Must-be Quality
 Quality customers expect; very dissatisfied if unmet
 Service suspensions and malfunctions
 Incidents
 I/R Ratio
 One-dimensional Quality
 Satisfied if met; dissatisfied if unmet
 Exceptional operability and response performance
 Latent dissatisfaction and disengagement
 Inquiries
 Reverse Quality
 Attributes whose very existence creates dissatisfaction
 Over-advertising, redundant tutorials, difficult to understand terms of service
 Latent dissatisfaction/reputation risk
 Word of mouth
 Upside
 Attractive Quality
 No dissatisfaction if unmet, but helps differentiate the product
 New state-of-the-art features and services/promotional campaigns
 User satisfaction/excitement/p rofit
 Product growth metrics (MAU/MPU/GPV, etc.)
 Other
 Indifferent Quality
 No impact on satisfaction.
 Features that no one uses
 Sunk cost
 -

  15. 21 Automated Testing ROI Low—ROI—High Number of tests Volume of

    applications for which you are running the test