SaaSプロダクト開発におけるバグの早期検出のためのAcceptance testの取り組み

冨田 浩史（株式会社ナレッジワーク）

※2025/3/28 JaSST '25 Tokyoでの登壇資料です
https://jasst.jp/tokyo/25-timetable/

当社の開発プロセスでは実装完了後に実装担当者が動作確認をおこなっている。しかし、動作確認が完了しているにもかかわらず、QAエンジニアがテスト開始後に単純な操作でバグが検出される問題が発生していた。動作確認に関しては、開発者の判断に委ねられておこなわれていたため、どのような動作を確認すれば完了なのか明確ではなかった。そこで、動作確認の方法に対してAcceptance testを導入した。本事例発表では施策の内容とその効果を報告する。

Transcript

1. JaSST’25 Tokyo 事例発表資料 SaaSプロダクト開発におけるバグの 早期検出のためのAcceptance Testの 取り組み Tommy (@TomitaHiroshi_)/ Knowledge Work
2. © Knowledge Work Inc. ⾃⼰紹介 2 2 株式会社 ナレッジワーク QA Engineer 冨⽥ 浩史 (Tomita Hiroshi) Tommy 共通基盤‧プロダクトのQAを担当 経歴 他業種からQAエンジニアにジョブチェンジし、 スマートフォンや医療関連などのQAを経験した後、 2023年10⽉にナレッジワークにQAエンジニアとして⼊社 趣味 ラーメン（⾷べる&作る）
3. 会社紹介
4. © Knowledge Work Inc. Profile 会社概要 4 創業日 　2020年4月1日 代表者 　麻野 耕司 資本金 　61.3億円（資本準備金等含む） 事業内容 　ナレッジワークの開発・提供 主な株主 　グロービス・キャピタル・パートナーズ、DNX Ventures、WiL 　One Capital、ANRI、XTech、Salesforce Ventures 　ユーザベース、フォースタートアップス、Sansan
5. © Knowledge Work Inc. 5 できる喜びが巡る日々を届ける Deliver the joy of enablement 「昨日できなかった仕事が今日できるようになった」 「今日うまく進められなかった仕事も明日はうまくできるかもしれない」 そんな想いで働ければ、仕事に希望が持てるはずです。 しかし、世の中の多くの人が「上司に恵まれない」「職場に恵まれない」 「会社の仕組みに恵まれない」などの理由で、 「努力しても成長できない」「努力しても成果が出ない」つまりは 「努力しても報われない」という環境で仕事をしています。 私たちは『イネーブルメント』を実現するプロダクトを提供することで 世の中の人たちが仕事にできるようになることを支援し、 働く喜びが巡る日々を届けます。
6. © Knowledge Work Inc. ナレッジワーク 製品紹介 6 みんなが売れる営業になる セールスイネーブルメント AIなら ナレッジワーク 営業担当の支援をするプロダクト 「ナレッジワーク」を提供しています
7. 本発表のスコープ
8. © Knowledge Work Inc. 本発表のスコープ 8 システム設計 実装 開発者 テスト QAエンジニア テスト 本発表スコープ
9. 本発表のサマリー
10. © Knowledge Work Inc. 本発表のサマリー 10 10 本発表ではQAエンジニアのテストで⾒つかる 簡単なバグを早期に検出するために、 Acceptance Test（受け⼊れテスト）を導⼊し、 その取り組みと効果を検証した事例を紹介します
11. 本発表の⽬的
12. © Knowledge Work Inc. 本発表の⽬的 12 12 本発表を通じて、開発者テストの課題を抱える チームや企業の⽅々に対し、 開発プロセスの改善につながる具体的なヒントを 持ち帰っていただくことを⽬的とします
13. © Knowledge Work Inc. Agenda 目次 • 背景と問題 • 問題整理‧課題 • 対策検討 • 取り組み • 効果検証‧考察 • まとめと今後の課題 13
14. 背景
15. © Knowledge Work Inc. はじめに 15 15 皆さんのチームでも経験はありませんか？ 実装完了後に開発者テストを実施したはずなのに、 QAエンジニアのテストで簡単にバグが発⽣する
16. ナレッジワークの開発体制‧開発プロセス
17. © Knowledge Work Inc. 17 ナレッジワークの開発体制 Product PdM Eng Designer Frontend Engineer Backend Engineer QA Engineer プロダクト 開発 アジャイル開発を進めています
18. © Knowledge Work Inc. 18 開発プロセス PdM Designer Frontend Engineer Backend Engineer QA Engineer 実装 Design Doc Product Requirements Document Design 開発者 テスト テスト分析 / 設計‧テストケース テスト実⾏ 実装 Design Doc 開発者 テスト
19. 問題
20. © Knowledge Work Inc. 発⽣していた問題 20 20 開発者テストが終わった後のQAエンジニアのテストで 開発者テストで検出できそうなバグが発⽣したこと
21. © Knowledge Work Inc. バグの具体例：完了ボタンを押すと意図しないダイアログが表⽰される 21 21 • 操作：外部設定管理画⾯で完了ボタンを押下 外部設定管理画⾯ 完了ボタン ブラウザダイアログ 予期せぬエラーが発⽣しました。 再度お試しください。 期待結果 URL：無効なURL エラーメッセージ 実際の結果
22. © Knowledge Work Inc. バグの具体例：⾮表⽰にすべきメニューが表⽰される 22 22 • 操作：メニューボタンを押下 期待結果 実際の結果 ファイル送信 ファイル送信管理 *** ファイル送信済 ファイル送信 ファイル送信管理 ***
23. © Knowledge Work Inc. 問題がもたらした影響 23 23 • ⼿戻りが発⽣し、開発‧QAの⼯数が増加したこと • 開発スピードが低下したこと • メンバーの負担が⼤きくなったこと
24. © Knowledge Work Inc. なぜこの問題が発⽣するのか 24 24 開発者は意図的に 開発者テストを怠っていない
25. © Knowledge Work Inc. なぜこの問題が発⽣するのか 25 25 開発者テストには 3つのパターンがある
26. © Knowledge Work Inc. 開発者テストパターン① 26 26 基本動作のみをテストする • 「ボタンを押したら機能が動いた。じゃあOK」 • 「期待した画⾯に遷移した。問題なし！」 結果 • 細かいUIのバグやエラーハンドリングのバグが⾒逃さ れる可能性がある
27. © Knowledge Work Inc. 開発者テストパターン② 27 27 ⾃分が実装した範囲内でのみテストする • ⾃分が実装したコードの範囲ではバグがないことを確認 結果 • 関連する他の機能への影響やバックエンドとフロントエ ンドの連携部分のバグは⾒落とされやすい
28. © Knowledge Work Inc. 開発者テストパターン③ 28 28 経験‧勘‧思いつきでテストする • 気になる箇所のみテストしてしまう • 業務の割り込みが発⽣すると、どこまでテストしたの かを忘れてしまう‧わからなくなる 結果 • 基本動作で⾒つけられそうなバグが⾒落とされるリス クがある
29. © Knowledge Work Inc. 開発者担当者が原因で問題は発⽣していない 29 29 開発者が意図的に 開発者テストを怠っていない
30. © Knowledge Work Inc. 原因は 30 30 開発者テストの進め⽅‧やり⽅
31. © Knowledge Work Inc. 問題を解決するためには 31 31 どうすればよいのか
32. © Knowledge Work Inc. Agenda 目次 • 背景と問題 ➡問題整理‧課題 • 対策検討 • 取り組み • 効果検証‧考察 • まとめと今後の課題 32
33. 問題整理
34. © Knowledge Work Inc. 問題整理 34 34 開発者テストが暗黙的に⾏われている • 何をテストすれば開発者テストがOKなのか明確になって いない 第三者のテスト観点が反映されていないため、実装担 当者に閉じたテストになっている • 開発担当者が⼗分に開発者テストをしたつもりでも、 テスト観点がカバーされていない可能性が⾼い 開発者テスト⽤のテストケースがない • テスト実⾏時にテスト漏れが発⽣するリスクがある
35. 課題
36. © Knowledge Work Inc. 課題：開発者テストを明確に⾏える仕組みを構築すること 36 36 • 開発者テストが明確に⾏われていること • 第三者のテスト観点がテストに反映されていること • 開発者テスト⽤のテストケースがあること
37. © Knowledge Work Inc. Agenda 目次 • 背景と問題 • 問題整理‧課題 ➡対策検討 • 取り組み • 効果検証‧考察 • まとめと今後の課題 37
38. 対策検討
39. © Knowledge Work Inc. 本質的な課題 39 39 開発者テストを 明確に⾏える仕組みを構築すること
40. © Knowledge Work Inc. 対策検討 40 40 Acceptance Criteria（受け⼊れ基準）を調査
41. © Knowledge Work Inc. Acceptance Criteria（受け⼊れ基準）とは 41 41 ユーザー、顧客、その他の認可団体が、コンポーネントやシ ステムを受け⼊れる場合、満たさねばならない基準 引⽤：ISTQB ⽤語集
42. © Knowledge Work Inc. Acceptance Criteria（受け⼊れ基準）によってできること‧できないこと 42 42 できること • 開発チームとステークホルダー間の共通認識を明確にし、認識 のズレを防ぐことができる できないこと • Acceptance Criteriaは、この機能が満たすべき基準を定める ものであり、 どのように開発者テストを⾏うかまでは適⽤できない
43. © Knowledge Work Inc. 検討結果 43 43 Acceptance Criteria（受け⼊れ基準）は 課題を根本的に解決することは難しいと判断しました
44. © Knowledge Work Inc. ここまでのまとめ 44 44 問題 • 開発者テストが終わった後のQAエンジニアのテストで 開発者テストで検出できそうなバグが発⽣したこと 課題 • 開発者テストを明確に⾏える仕組みを構築すること • 開発者テストが明確に⾏われていること • 第三者のテスト観点がテストに反映されていること • 開発者テスト⽤のテストケースがあること 対策検討 • [⾒送り]Acceptance Criteria（受け⼊れ基準）
45. © Knowledge Work Inc. Agenda 目次 • 背景と問題 • 問題分析‧課題 • 対策検討 ➡取り組み • 効果検証‧考察 • まとめと今後の課題 45
46. 取り組み
47. © Knowledge Work Inc. 発⽣していた問題 47 47 開発者テストが終わった後のQAエンジニアのテストで 開発者テストで検出できそうなバグが発⽣したこと
48. © Knowledge Work Inc. 実現できていないこと 48 48 開発者テストが完了したが、 QAエンジニアがテストを開始できる状態ではなかったこと
49. © Knowledge Work Inc. Acceptance Testing（受け⼊れテスト） 49 49 システムが、ユーザーのニーズ、要件、ビジネスプロセスを 満⾜するかをチェックするための公式なテスト。このテスト により、システムが受け⼊れ基準を満たしているかどうかを 判定したり、ユーザー、顧客、その他の認可団体がシステム を受け⼊れるかどうかを判定したりすることができる 引⽤：ISTQB ⽤語集
50. © Knowledge Work Inc. 実現したいこと 50 50 開発者テスト完了 ＝ QAエンジニアがテストを開始できる状態
51. © Knowledge Work Inc. 施策 51 51 Acceptance Test
52. © Knowledge Work Inc. Acceptance Testとは 52 52 開発担当者が開発者テストの拠り所として 設計されたテストケースを指す
53. © Knowledge Work Inc. Acceptance Testの運⽤パターン 53 53 パターン① • QAE設計 → 開発担当者レビュー → 開発担当者実施 パターン② • 開発担当者設計 → QAEレビュー → 開発担当者実施 本事例は運⽤パターン①
54. © Knowledge Work Inc. Acceptance Testの運⽤プロセス 54 AT 設計 AT PRD：Product Requirements Document DD:Design Doc AT：Acceptance Test Frontend Engineer Backend Engineer QA Engineer PRD DD レビュー 開発者 テスト 実施 チェック PRD・Des ign 設計 （DD） この辺でAT実施有無を議論 実装・開発者テスト
55. © Knowledge Work Inc. 具体例①：ファイルをダウンロードする機能 55 55 •操作⼿順：ホーム画⾯からファイルボタンを押下、ファイ ル画⾯のダウンロードボタンを押下 ◻期待結果： • ダウンロードが完了すること • ファイルのタイトルが「ファイル_yyyymmdd.pdf」になって いること
56. © Knowledge Work Inc. 具体例②：新機能の画⾯表⽰ 56 56 •画⾯遷移  ◻画⾯遷移図の全パスで遷移すること •0件表⽰  ◻検索結果が0件のとき、ドキュメントに定義された表⽰になること • エラー表⽰  ◻検索実⾏時にエラーが発⽣した場合、適切にエラー表⽰されること
57. © Knowledge Work Inc. 具体例③：共通基盤をリファクタリング 57 57 •データを作成  ◻データを作成し、詳細画⾯に作成したデータが表⽰されること •E2E(⾃動テスト)  ◻tests/specs/xxxxxxのテストがpassすること
58. © Knowledge Work Inc. 具体例：共通基盤をリファクタリング（テスト実施後） 58 58 •データを作成  ◻データを作成し、詳細画⾯に作成したデータが表⽰されること •E2E(⾃動テスト)  ◻tests/specs/xxxxxxのテストがpassすること ✔ ✔
59. © Knowledge Work Inc. Acceptance Testで課題解決できたこと 59 59 開発者テストを明確に⾏える仕組みを構築できた • 開発者テストが明確に⾏われていること →何をテストすれば完了なのか明確になった • 第三者のテスト観点がテストに反映されていること →テストケースに第三者の視点‧テスト観点の反映が可能に なった • 開発者テスト⽤のテストケースがあること →テスト漏れが発⽣するリスクを軽減できるようになった
60. © Knowledge Work Inc. Acceptance Testで実現できたこと 60 60 AT完了 ＝ QAエンジニアがテストを開始できる状態 AT：Acceptance Test
61. © Knowledge Work Inc. 定量的な効果 61 61 Acceptance Test導⼊による 定量的な効果はあったのか
62. © Knowledge Work Inc. Agenda 目次 • 背景と問題 • 問題分析‧課題 • 取り組み • 対策検討 ➡効果検証‧考察 • まとめと今後の課題 62
63. 効果検証
64. © Knowledge Work Inc. 発⽣していた問題 64 64 開発者テストが終わった後のQAエンジニアのテストで 開発者テストで検出できそうなバグが発⽣したこと
65. © Knowledge Work Inc. 効果検証の指標 65 65 開発者テストで どれくらいバグの流出を防⽌できたのか
66. © Knowledge Work Inc. 効果検証のスコープ 66 66 対象バグ • 開発者テスト中に検出したバグ • QAエンジニアのテスト期間中に検出したバグ • 対象：開発者テストで検出したいバグのみ • 対象外：特殊な条件/複雑なバグ 対象機能開発 • 新機能：1案件 • 機能追加：2案件 • 実装担当者は運⽤開始前後でほぼ同じ ⽐較対象 • Acceptance Test運⽤開始前後
67. © Knowledge Work Inc. 67 67 効果検証：機能開発毎の比較 運用開始前 （開発者テストで検出したいバグ） 運用開始後
68. © Knowledge Work Inc. 68 68 開発者テスト中に 検出したバグ数 QAエンジニアのテスト 期間中に検出したバグ数 （開発者テストで検出したいバグ） 開発者テストの バグ流出防⽌率 運⽤開始前 2件 9件 18% 運⽤開始後 14件 9件 60% 効果検証：運用開始前後の全体比較
69. 考察
70. © Knowledge Work Inc. 考察 70 70 • Acceptance Testの定量効果 • 開発状況によって検出されるバグの数は常に⼀定とは限 らない • Acceptance Testでバグを検出できたことは事実であり、 Acceptance Testの導⼊は、バグを早期検出という点にお いて⼀定の効果があったと考えられる • Acceptance Testの導⼊がQAエンジニアに与えた影響 • 開発者がテストにかける時間は増加したものの、バグの 早期検出が進んだことで、開発担当者とQA間のコミュニ ケーションコストが削減された • QAエンジニアはスクリプトテスト以外のテストに時間を 割けるようになった
71. © Knowledge Work Inc. Agenda 目次 • 背景と問題 • 問題分析‧課題 • 取り組み • 対策検討 • 効果検証‧考察 ➡まとめと今後の課題 71
72. まとめと今後の課題
73. © Knowledge Work Inc. まとめ 73 73 問題 • 開発者テストが終わった後のQAエンジニアのテストで 開発者テストで検出できそうなバグが発⽣したこと 取り組み • Acceptance Testを導⼊ 成果 • 暗黙的な開発者テストを明確にしたことにより、 開発者テストのバグ流出防⽌率が向上
74. © Knowledge Work Inc. 今後の課題 74 74 開発者テストで検出したいバグの原因を分析する • Acceptance Testを導⼊してもQA期間中に開発者テストで 検出したいバグが検出されている点については、原因分析 が必要である Acceptance Testのナレッジを作成する • Acceptance Testのナレッジがないため、 個⼈によってAcceptance Testの内容にばらつきが⽣じ、 開発者テストで検出すべきバグが増加するリスクがある
75. © Knowledge Work Inc. 参考⽂献 75 75 ISTQB⽤語集 https://glossary.istqb.org/ja_JP/
76. © Knowledge Work Inc. 最後に 76 76 ご清聴ありがとうございました