QAエンジニアの方々との壁打ちを通して見えてきたプロダクト品質保証方針

QAエンジニアの方々との壁打ちを通して見えてきたプロダクト品質保証方針 @ JaSST nano vol.38 彌冨輝彦

2 ３自己紹介はじめにプロダクトのテストの現状 1 4 壁打ちして見えてきた今後の方針 5 まとめ
2 アジェンダ QAエンジニアの方々との壁打ちを通して見えてきたプロダクト品質保証方針

3 自己紹介 QAエンジニアの方々との壁打ちを通して見えてきたプロダクト品質保証方針彌冨輝彦 (Teruhiko Yatomi)   Twitter: trhk_ytm
  Github: teruhiky   趣味: スキー・スノボ・登山・資産運用　最近は韓国語を学習中   2022 ~ 現在: サプライチェーンのリスク管理 SaaSを提供する「 Resilire」に開発組織の立ち上げメンバーとして参画テックリードとして、開発全般や開発組織について広く従事 2018 ~ 2022: 建設業界向けの SaaSを提供する「 ANDPAD」に参画 ANDPAD受発注を0から設計・開発・運用して、成長を牽引 2012 ~ 2018: 外資証券会社モルガン・スタンレーにて、株や FX等の電子取引システムの開発・運用に従事 JaSST nano初LTです、よろしくお願いします！

5 はじめに QAエンジニアの方々との壁打ちを通して見えてきたプロダクト品質保証方針本発表は、QAエンジニアの方々との壁打ちを通して得られた、  ”弊社における”品質保証方針の一例になります。    各業態ごとの特性に応じたアプローチがあると思いますので、  本アプローチがベストプラクティスとは思っておりません。   
その上で、さらにブラッシュアップできるフィードバックは  いつでもウェルカムですのでよろしくお願いします。 

7 プロダクトのテストの現状 - 開発プロセス QAエンジニアの方々との壁打ちを通して見えてきたプロダクト品質保証方針 PRD  デザイン  レビュー会  キックオフ  タスク分解 
リリース  ロードマップPJ 実装・  自動テスト実装  手動テスト  リリース  実装・  自動テスト実装  手動テスト  リリース  実装・  自動テスト実装  手動テスト  ページ構成 PRD デザイン [参加者] PRD ~ レビュー会: PdM, Designer, Lead Engineer キックオフ: PdM, 担当Engineer, (必要に応じて) Designer, Lead Engineer [特徴] 段階的リリースを行いリリースインパクトを限定する反面、リグレッションテストが重要

8 プロダクトのテストの現状 - 自動テストの現状 QAエンジニアの方々との壁打ちを通して見えてきたプロダクト品質保証方針 • E2E Test ◦ Non-Prod環境
定期実行によるリグレッションテスト ◦ Prod環境ログインテストのみ　※ リリース社内公開時に主要導線テストを実行する予定 • Front ◦ Integration Test 各機能開発と併せて実装 ◦ VRT (デザインシステム導入前なので割愛 ) ◦ Unit Test 重要ロジックのみ ◦ Static Test TypeScriptCompilerによる型チェック、EsLintを実施 • BFF/Backend ◦ Integration Test BFF + Backend + DBで結合テスト　※ 現状テストカバレッジには含まれない ◦ Unit Test 重要ロジックのみ

9 プロダクトのテストの現状 - 課題 QAエンジニアの方々との壁打ちを通して見えてきたプロダクト品質保証方針 • 全体を通して・・・ ◦ PdMがQAも兼務 ◦
災害が発生しないとテストできない ◦ リリース後に不具合が見つかりやすい • E2E Test ◦ Autifyだとツリー・マップ画面が難しい ◦ E2Eテスト偏重になるリスク • BFF+Backend+DB Integration Test ◦ 各テストのDBデータ初期化が難しい

11 壁打ちして見えてきた今後の方針 QAエンジニアの方々との壁打ちを通して見えてきたプロダクト品質保証方針 • QAがプロダクト品質保証のOwnershipをもち、チーム全体で協働して品質保証を実現していく方針へ ◦ 今まで ▪ Unit, Integrationテストはエンジニア、E2E/手動テストはPdM(QA)のように役割分担
◦ これから ▪ Unit/Integraion/E2E/手動テストのどこで品質担保するべきかを判断してチームで推進 ◦ メリット ▪ 戦略的にテストを作成していくことで必要なテスト実装・保守していける ▪ E2E・手動テストが無駄に増えない ▪ エンジニアもUnitテストからE2Eテストまでのカバレッジが求められ必要なドメインの理解が広がる ▪ テストカバレッジに縛られないKPI設計 ◦ デメリット ▪ チームで品質保証を推進するため、QAの採用ハードルが上がる

12 壁打ちして見えてきた今後の方針 - 実現するために考えていること QAエンジニアの方々との壁打ちを通して見えてきたプロダクト品質保証方針 • 方針： ◦ QAがプロダクト品質保証のOwnershipをもち、チーム全体で協働して品質保証を実現していく方針へ •
考えていること： ◦ E2Eで担保するべきと判断したテストを実装できるように応用がきくようにしないといけない ◦ 品質担保するためのフォーマット・開発プロセスの見直し ▪ レビューの時点で品質保証観点を加える必要がある ▪ キックオフ〜リリースの間に用意するテストケースのフォーマット定義 ◦ 障害・不具合・リリース前のテストで見つかった不具合について、分析・フィードバックするサイクルを構築 ◦ プロダクトテスト品質を担保するためのKPI設計 ◦ Unit, Integration, E2Eテストの環境を整備する ◦ 主要導線としてのユースケースの定義・テストケース作成

• E2EテストをAutifyからPlaywrightへ ◦ ツリー・マップなどUIがリッチな場合も応用をきかせて自動テストを計画できる ◦ 短期的には効果が出にくいので、一定体制が整うまで現状のAutifyのテストは維持する • Asana上で障害・不具合分析の体制を構築 ◦ リリース前/後の不具合タスクのそれぞれがどうあれば防げたのかを見て効率良く防ぐ
不具合タスクデータ 13 壁打ちして見えてきた今後の方針 - 具体的な対応 QAエンジニアの方々との壁打ちを通して見えてきたプロダクト品質保証方針起票 PdM Eng QA 分析情報入力

15 まとめ QAエンジニアの方々との壁打ちを通して見えてきたプロダクト品質保証方針データでサプライチェーンをアップデートする本発表は、現状の方針になりますが今後実際に組織的にもシステム的にも体制を整えていきます。  その際には運用知見や反省点など、改めて共有させていただければと思います。    本方針を今後も引き続きブラッシュアップしながら体制構築していこうと思っておりますので、  ぜひ壁打ちさせていただける方、ご連絡ください！  彌冨
輝彦 (Teruhiko Yatomi)   Twitter: trhk_ytm   Github: teruhiky  

QAエンジニアの方々との壁打ちを通して見えてきたプロダクト品質保証方針

QAエンジニアの方々との壁打ちを通して見えてきたプロダクト品質保証方針

teruhiky

More Decks by teruhiky

Featured

Transcript