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

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

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

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

mercari
PRO

May 26, 2023
Tweet

More Decks by mercari

Other Decks in Technology

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