[DevDojo] メルペイの品質保証ポリシー

安心安全に早い開発サイクルでサービスを持続的に提供していくためには、Quality Assuaranceは非常に大切です。このコンテンツでは、どのようなQAのプロセス、ツール、テクニックで問題を迅速に特定し、解決しているのかを解説しています。

Transcript

1. 1
   Quality Assurance Policy
   Masami Yajiri
   Merpay QA Team / QA Engineer
   

   View Slide

2. 2
   Quick intro!
   Masami Yajiri / @myajiri
   QA Engineer at Merpay
   ● QA(9y)● 経験社数：メルペイで 7社目
   ● QA-Leadとして与信・決済システムの品質保証を担当
   ● このQA Policyの発起人
   ● 趣味：マラソン🏃＆トレラン🏔＋温泉♨
   ● 余談：ITエンジニアになる前は神主さんでした ⛩
   

   View Slide

3. 3
   QA Policyの目的
   

   View Slide

4. 4
   Mission
   

   View Slide

5. 5
   なめらかな社会とは、

   複雑な社会を複雑なまま、

   境界なく繋がって生きていける社会

   

   View Slide

6. 6
   安心・安全が脅かされると、

   社会は単純化や境界を作ることで
   反応してしまう

   

   View Slide

7. 7
   なめらかな社会を実現するため、

   安心・安全を脅かす脅威と闘う。

   

   

   View Slide

8. 8
   QA Policyの目的

   チームの接着剤になりたい

   品質や価値のためにあらゆることをしたい

   プロダクトやプロジェクトについて対話したい

   01
   02
   03
   アジャイルQAがしたいこと

   

   View Slide

9. 9
   品質とは何か

   全てのプロジェクトで品質の定義は常に変化する。

   
 条件により常に変化する品質の中でベストプラクティスを追求する 

   お客様にとっての「価値」 

   変化しない定義：「品質」とは「誰かにとっての価値」

   Whats Quality?

   ❓ 👍
   ✨
   

   View Slide

10. 10
    All for Oneな状態

    全員品質：役割を越境し全員で立ち向かう

    サイロ化している状態 

    PM Engineer QA
    KPI KPI KPI
    価値

    Delivery
    

    View Slide

11. 11
    役割を超えて全員で立ち向かう「全員品質」

    ルッサーの法則

    R
    s
    ・・・プロダクト全体の信頼性
    r
    n
    ・・・各コンポーネントの信頼性
    

    特定の工程(例:テスト)に依存せず、

    「全プロセス(全員)」で信頼性の総和を向上させるアプローチ

    90%^10＝35％(↓)
    各コンポーネントがベストな品質を目指す＝信頼できるプロダクト

    

    View Slide

12. 12
    アジャイルテストとは
    

    View Slide

13. 13
    私たちが大切にすること

    最後にテストする
    よりも
    ずっとテストしよう
    バグを発見する
    よりも
    バグを防止しよう
    機能性のチェック
    よりも
    価値をテストしよう
    システムを破壊する
    よりも
    最高のシステムにしよう
    「誰の責任？」
    よりも
    「チームの責任！」
    引
    用:https://www.growingagile.co.za/2015
    /04/the-testing-manifesto/ 

    The TESTING Manifesto
    

    View Slide

14. 14
    ずっとテストしよう

    デリバリーの全プロセスがテストの対象！
    引用:

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

    

    

    View Slide

15. 15
    「テスト」と「品質」
    

    View Slide

16. 16
    リリースするために

    「十分なテスト」をしよう

    重大インシデントを引き起こす欠陥がないこと

    01
    現在の状態で十分に価値を出せること

    02
    プロダクトの価値が残存リスクを上回ること

    03
    リリースする利益が遅らせる損害を上回ること

    04
    プロダクト(または機能)が本番環境で要求通りに動作し、価値を提供し、利益を得るために十分に
    働いている根拠があるとき、プロダクトをリリースすることができます。 

    

    View Slide

17. 17
    「テスト」とは？

    プロダクトを学習し探索すること 

    [参考]Testing and Checking Refined

    要求や仕様通りに動作すること 

    

    View Slide

18. 18
    「価値」と「リスク」
    [出典]日科技連「狩野モデルと商品企画」より 

    アップサイド

    (価値)

    ダウンサイド

    リスク

    

    View Slide

19. 19
    「価値」と「リスク」
    リスク
    種別

    狩野モデル
 内容
 例
 結果
 指標(仮)

    ダウン
    サイド

    当たり前品質

    不充足だと不満、充
    足されて当たり前

    サービス停止や機能
    不全

    インシデント
 I/R Ratio

    一元的品質

    不充足だと不満、充
    足されると満足

    優れた操作性や応答
    性能

    顕在的な不満や離脱
    
 お問い合わせ

    逆評価品質

    存在が不満を招くも
    の

    過剰な広告/冗長な
    チュートリアル/難解な
    規約

    潜在的な不満/レピュ
    テーションリスク

    口コミ

    アップ
    サイド

    魅力的品質

    なくても不満はない
    が差別化に繋がる
    もの

    画期的な新機能や
    サービス/お得なキャ
    ンペーン

    お客さまの満足/ワクワ
    ク/利益

    プロダクト成長指標
    (MAU/MPU/GPVなど)
    

    その他
 無関心品質

    あってもなくてもよい
    もの

    誰にも使われていない
    機能

    サンクコスト
 -

    

    View Slide

20. 20
    テスト自動化戦略
    

    View Slide

21. 21
    自動テストのROI

    低 ROI 高
    テスト数

    テストを実行する 

    アプリケーション 

    の量

    

    View Slide

22. 22
    開発手法とテストタイプ

    スクラム型

    (アジャイル)

    ウォーター

    フォール型

    

    View Slide

23. 23
    開発位手法とテストタイプ
    スクラム型

    (アジャイル)

    

    View Slide

24. 24
    開発手法とテストタイプ
    ウォーター

    フォール型

    

    View Slide

25. 私たちと最高のプロダクトを作りましょう！

    25
    

    View Slide

26. 26
    Thank you!
    

    View Slide