インプロセスQAにおいて大事にしていること / In-process QA Meetup

「インプロセスQA Meetup! - みんなで語ろう!開発におけるQAの役割とこれから」(https://layerx.connpass.com/event/349533/) での発表資料です。
(一部内容を編集しています)

Transcript

1. インプロセスQAにおいて⼤事にしていること 2025/4/18 インプロセスQA Meetup
2. はじめに 自己紹介 米山 允章 (ヨネヤマ ヨシアキ）/ 株式会社メドレー QAファンネル的な経歴 • フェーズゲートQA (スプリットTE/PE/QA) :6年 • QAプロモーター? :2年 • QAコーチ :2年 • インプロセスQA :10年 • 現所属チームではインプロセスQA、所属外のチームに対してはQAコーチ的な活動 をしています • 昨年よりQAマネージャ業務を兼任 • インプロセスQAが好きです
3. はじめに プロダクトの紹介
4. はじめに 🔍インプロセスQAとは ソフトウェア開発におけるインプロセスQAとは、開発プロセスの 最中、つまり設計・実装・テストの進行中に品質保証活動を取り 入れるアプローチです。 従来の「完成してからテストする」という考え方とは異なり、品 質を後から検証するのではなく、最初から作り込むことを重視し ます。 by GPT 要はシフトレフト
5. はじめに サッカーで例えると フェーズゲートQA (スプリットTE) インプロセスQA ゴールキーパー ボランチ (守備的MF)
6. この発表について はじめに • インプロセスQAと言っても、取り組み方は各社様々です • この時間ではQAプロセスを各フェーズに分けた上で、QAエンジニア の関わり方としてある選択肢を考えてみます • そして各選択肢をQCD観点で評価してみます (主観) • 現チームではどの選択肢をどんな理由で選んでいるかをご紹介しま す • 皆さんはどうしてますか？をぜひこの後の交流会で聞かせてくださ い！
7. タイプ分類 QAプロセス [いのちだいじに型]: コストは気にせず品質重視型 [バッチリがんばれ型]: QCDのバランス重視型 [いろいろやろうぜ型]: 出来る限り自動化を進めるコスト重視型 [ガンガンいこうぜ型]: 何よりまずはデリバリー重視型 いのちだいじに バッチリがんばれ ガンガンいこうぜ いろいろやろうぜ
8. 各社で違いが出る所はどこか QAプロセス 以下のフェーズ毎に考えてみます 1. 要件定義フェーズ 2. テスト計画/設計フェーズ 3. テスト実施フェーズ 4. リグレッションテスト(手動テスト) 5. リグレッションテスト(自動テスト) 6. リリース後の運用フェーズ
9. QAEの関わり⽅としてどんなパターンがある? 要件定義フェーズ 関わり方 Pros/Cons Q C D A 仕様が決まったら共有してもらい、 テスト計画に入る [Pros] 仕様が決まるまでは他のタスクに集中できる [Cons] 仕様に考慮もれがあったとしても検知できるタイ ミングが遅れることで手戻りが発生する × × B 仕様のレビュープロセスに入る / 一緒に検討する [Pros] FBを仕様に反映できる (手戻りを防げる) [Pros] 背景が理解でき、納得感を持てる [Cons] ドメイン理解は必要 ⭕ ⭕ バッチリがんばれ
10. 要件定義フェーズ 不具合の検知フェーズと修正コスト 1. 要件定義フェーズ（修正コスト 1倍） 文書や仕様書の変更だけで済むことが多い (例：業務フローの誤解、ユーザー要求の誤認識) 2. 設計フェーズ（修正コスト 5倍） 設計レベルで問題を発見できれば、コードを書く前に修正できるため、コストは抑えられる。 ただし、影響範囲の分析が必要になり、手戻りが発生することも。(例：I/F仕様の不整合) 3. 実装（コーディング）フェーズ（修正コスト 10倍） プログラムを書いた後にバグを発見すると、修正には再テストが必要になる。 設計の見直しが必要な場合、コストはさらに増大 (例：ロジックのミス、例外処理の欠如) 4. 単体テスト・結合テストフェーズ（修正コスト 20倍） テストで問題が発覚すると、修正だけでなく再テストや影響範囲の確認が必要になる。 5. システムテスト・受け入れテストフェーズ（修正コスト 50倍） システム全体が完成した後の修正は、テスト計画の変更や影響範囲の広さからコストが大きくなる。 6. 運用フェーズ（修正コスト 100倍以上） 運用後に問題が発覚すると、顧客やユーザーに影響が及ぶため、修正コストが最も高くなる。 システム停止による機会損失や信用の低下といった影響もある。
11. 要件定義フェーズ 不具合はどこで生まれるか 1. 設計ミス（要件定義・設計の誤り）:30〜50% 2. コーディングミス（プログラミングの誤り）:20〜40% 3. テスト不足（検証プロセスの問題）:10〜20% 4. 環境依存の問題（インフラ・外部システムとの連携etc）:10〜20% 5. 運用時のヒューマンエラー: 5〜10%
12. 要件定義フェーズ 開発プロセス キックオフ & 要件定義後の2回実施
13. 要件定義フェーズ QAEとして意識していること 日頃から意識すること 1. プロダクト仕様の理解 (前提) 2. ユーザの理解 3. 競合他社の理解 4. 自プロダクトの立ち位置を理解 仕様レビューで意識すること 1. 事前にしっかり読み込む 2. 懸念点があれば事前にコメントを残しておく 3. Feedbackは建設的に、何をどうすれば良いのか明確に 4. 不具合が出そうな部分をクリアに マインド 1. 単に仕様の共有を受ける場として捉えない
14. テスト計画フェーズ QAEの関わり⽅としてどんなパターンがある? 関わり方 Pros/Cons Q C D A テスト計画を行う (計画書を用意する) [Pros] 検証範囲も含めて計画が可視化される ※業務委託の方にも入って頂く場合は必須か [Cons] 特にアジャイルだと計画後に変更が入ることも頻繁 にある ◎ ⭕ B ドキュメントは用意しないが、 QA スケジュールを策定する [Pros] スケジュールは可視化される [Cons] テスト範囲が可視化されない ⭕ ⭕ C テスト計画は行わない (QA/修正が終わった時点でリリー スを行う) [Pros] 計画に対する工数はかからない [Cons] QAスケジュールが見えないため、リリースス ケジュールも立てづらい ⭕ バッチリがんばれ いのちだいじに ガンガンいこうぜ
15. 関わり方 Pros/Cons Q C D A テスト設計は行う / レビューも行う [Pros] 観点の抜け漏れを防ぐ確率が高まる [Pros] 属人化防止の効果もある [Cons]レビュー工数/時間がかかる ◎ × 🔺 B テスト設計は行う / レビューはスキップ [Pros] テストケースを開発者に共有できる [Pros] 実施は他の方にお願いすることもできる [Cons]設計の工数はかかる ⭕ 🔺 ⭕ C AIでテスト設計 / 担当者がレビュー [Pros] 迅速且つ機械的に観点を抽出できる [Cons] AIに対するインプットを用意する必要がある ⭕ ⭕ ⭕ D Acceptance Criteriaのみ作成 [Pros] リリースまでに必要なことが可視化される [Pros] 開発者もACを踏まえた実装ができる [Cons]粒度がテストケースよりは荒い 🔺 ⭕ ⭕ E テスト設計は行わない (探索的テストで担保する ) [Pros] 実施前の工数がかからない [Cons] 観点が抜け漏れる可能性は Aより高い 🔺 ◎ ⭕ テスト設計フェーズ QAEの関わり⽅としてどんなパターンがある? いのちだいじに ガンガンいこうぜ バッチリがんばれ バッチリがんばれ ❓
16. 関わり方 Pros/Cons Q C D A 業務委託の方に依頼する [Pros] QAE自身のコストは削減できる [Cons] 環境の準備や問題の切り分けでフォローが必要 [Cons] 人月分のコストがかかる [Cons] あらかじめ依頼時期の調整が必要 ⭕ × 🔺 B QAエンジニアが実施する [Pros] 仕様も手順も把握しているため早い [Pros] UX的な観点等でもFeedbackができる [Cons] 案件が重なった場合に優先度判断が必要 [Cons] QAEがブロッカーになり得る ◎ 🔺 ⭕ C PdM職が実施する [Pros] 修正要否の判断を自ら行うことができる [Cons] 次の企画等のタスク進捗が止まる ⭕ 🔺 ⭕ D 開発者が実施する [Pros] 品質への意識をより高く持つことができる [Pros] テストまでコンテキストスイッチがかからない [Cons] 実装時に抜けていた観点はテストでも見落とす 🔺 ⭕ ⭕ E チームで実施する [Pros] 開発チーム全体で品質担保する意識が醸成される [Cons] 体系的なケースではないので観点が落ちるリスク 🔺 ⭕ ⭕ テスト実施フェーズ QAEの関わり⽅としてどんなパターンがある? いのちだいじに ガンガンいこうぜ ガンガンいこうぜ ガンガンいこうぜ バッチリがんばれ
17. 関わり方 Pros/Cons Q C D A 業務委託の方に依頼する [Pros] QAE自身のコストは削減できる [Cons] 実施環境の準備や問題の切り分けでフォローが必要 [Cons] 人月分のコストがかかる [Cons] あらかじめ依頼時期の調整が必要 ⭕ 🔺 🔺 B QAエンジニアが実施する [Pros] 仕様も手順も把握しているため早い [Pros] 細かなバグでも気付きやすい [Cons] QAEがブロッカーになり得る ⭕ 🔺 🔺 C 開発チーム全体で実施する [Pros] リグレッションテストを誰でも通すことが出来る [Pros] チーム全体で品質担保する意識が醸成される [Pros] テストを通して最新の仕様をキャッチアップできる [Cons] 担当者の工数は一定取られる ⭕ ⭕ ⭕ D 手動でのテストは行わない (自動テストで担保) [Pros] 工数はかからない [Cons] 自動テストの実装/メンテナンスコストはかかる 🔺 ⭕ ⭕ E 手動でのテストは行わない (自動テストもない) [Pros] リリース前の工数はかからない [Cons] リリース後にデグレを検知すると結局コストは嵩む ✖ 🔺 ⭕ リグレッションテスト (手動テスト ) QAEの関わり⽅としてどんなパターンがある? いのちだいじに いのちだいじに ガンガンいこうぜ ガンガンいこうぜ いろいろやろうぜ
18. 関わり方 Pros/Cons Q C D A 業務委託の方に依頼する [Pros] QAE自身のコストは削減できる [Cons] 実施環境の準備や問題の切り分けでフォローが必要 [Cons] 人月分のコストがかかる [Cons] あらかじめ依頼時期の調整が必要 ⭕ ⭕ ⭕ B QAEが実装/運用する [Pros] 仕様も手順も把握しているため早い [Pros] 細かなバグでも気付きやすい [Cons] テストが落ちた場合の対応が QAEに依存する ⭕ 🔺 ⭕ C 開発チームで実装/運用する [Pros] 開発と並行してテストもメンテナンスできる [Cons] 特に0>1の構築部分は工数がかかる ⭕ 🔺 ⭕ D 自動テストがない (全て手動で確認) [Pros] 自動テストの運用コストはかからない [Cons] リグレッションテストが発生する度に実施工数がかかる [Cons] デグレを検知するまでのタイムラグが長くなる 🔺 ✖ ✖ リグレッションテストの自動化 QAEの関わり⽅としてどんなパターンがある? いのちだいじに いのちだいじに いろいろやろうぜ バッチリがんばれ
19. 関わり方 Pros/Cons Q C D A APIテスト+E2Eテストを 実装 [Pros] カバレッジが高く、問題も特定しやすい [Cons] 実装/メンテナンスコスト ◎ 🔺 ◎ B E2Eテストをコードベース で実装 [Pros] 実装のPRと連動してテストも修正しやすい [Cons] 0>1の構築に少し時間がかかる [Cons] ライブラリアップデート等の対応は定常的に発生する ◎ 🔺 ⭕ C E2Eテストをノーコード ツールで実装 [Pros] 0>1の構築コストは非常に低い [Pros] 誰でも実装できる [Cons] 実装側のPRと連動することが難しい [Cons] テストのレビューが難しい ◎ ⭕ ⭕ D コードベース×AIで実装 [Pros] 実装側の変更と連動してテストも修正できれば低コスト [Cons] AIのインプットなど環境構築のコストが必要 [Cons] AIのサジェストが適切かどうか確認できるスキルは必要 ⭕ ⭕ ◎ リグレッションテストの自動化 QAEの関わり⽅としてどんなパターンがある? ❓ いろいろやろうぜ いろいろやろうぜ バッチリがんばれ バッチリがんばれ
20. 関わり方 Pros/Cons Q C D A 特に役割なし [Pros] 次のタスクに集中できる - ⭕ - B 問い合わせを確認 [Pros] 顧客の声から改善ネタを生み出せる [Pros] 問題があった場合の初動が早まる [Pros] 仕様を把握しているため切り分けがスムーズ [Cons] 工数 ⭕ ⭕ ⭕ C クラッシュやエラーログを 確認 [Pros] 問題を検知して改修まで繋げることができる [Cons] ログから原因や再現手順を特定するのは困難な ケースも多い ⭕ 🔺 🔺 D 障害/不具合分析を行う [Pros] 今後に向けた改善アイデアが生まれる [Cons] 一定数の不具合がなければ分析の意味が成さない ⭕ 🔺 🔺 リリース後の運用フェーズ QAEの関わり⽅としてどんなことがある? いのちだいじに いのちだいじに ガンガンいこうぜ バッチリがんばれ
21. まとめ QAEの関わり⽅として⼤事にしたいこと 1. インプロセスQAは単に品質が良ければOKではない (事業がうまくいかければ解散!) 2. 事業目標を達成するためにQCD全てが高いプロセスを目指す a. 品質は当たり前だとして、生産性とデリバリーへの意識も高く持って行動する 3. 事業や市場理解は日頃から意識して行動する 4. プロダクトチームの一員として、QAEの役割を決めすぎない(越境歓迎) 5. 他の職種の方と会話する時は相手の目線で話す 6. 100%不具合を検知することは不可能だが、少なくともHotfixが必要な障害は未然に防ぐ 7. 他社の取り組みも参考にして、引き出しのアップデートを続ける
22. ご清聴ありがとうございました！
23. さいごに ご案内 私たちのチームでQAエンジニア募集中です！ https://open.talentio.com/r/1/c/medley/pages/105574 もしご興味あればぜひカジュアルにでもお話しましょう！