Slide 1

Slide 1 text

JaSST’25 Tokyo 事例発表資料 SaaSプロダクト開発におけるバグの 早期検出のためのAcceptance Testの 取り組み Tommy (@TomitaHiroshi_)/ Knowledge Work

Slide 2

Slide 2 text

© Knowledge Work Inc. ⾃⼰紹介 2 2 株式会社 ナレッジワーク QA Engineer 冨⽥ 浩史 (Tomita Hiroshi) Tommy 共通基盤‧プロダクトのQAを担当 経歴 他業種からQAエンジニアにジョブチェンジし、 スマートフォンや医療関連などのQAを経験した後、 2023年10⽉にナレッジワークにQAエンジニアとして⼊社 趣味 ラーメン(⾷べる&作る)

Slide 3

Slide 3 text

会社紹介

Slide 4

Slide 4 text

© Knowledge Work Inc. Profile 会社概要 4 創業日  2020年4月1日 代表者  麻野 耕司 資本金  61.3億円(資本準備金等含む) 事業内容  ナレッジワークの開発・提供 主な株主  グロービス・キャピタル・パートナーズ、DNX Ventures、WiL  One Capital、ANRI、XTech、Salesforce Ventures  ユーザベース、フォースタートアップス、Sansan

Slide 5

Slide 5 text

© Knowledge Work Inc. 5 できる喜びが巡る日々を届ける Deliver the joy of enablement 「昨日できなかった仕事が今日できるようになった」 「今日うまく進められなかった仕事も明日はうまくできるかもしれない」 そんな想いで働ければ、仕事に希望が持てるはずです。 しかし、世の中の多くの人が「上司に恵まれない」「職場に恵まれない」 「会社の仕組みに恵まれない」などの理由で、 「努力しても成長できない」「努力しても成果が出ない」つまりは 「努力しても報われない」という環境で仕事をしています。 私たちは『イネーブルメント』を実現するプロダクトを提供することで 世の中の人たちが仕事にできるようになることを支援し、 働く喜びが巡る日々を届けます。

Slide 6

Slide 6 text

© Knowledge Work Inc. ナレッジワーク 製品紹介 6 みんなが売れる営業になる セールスイネーブルメント AIなら ナレッジワーク 営業担当の支援をするプロダクト 「ナレッジワーク」を提供しています

Slide 7

Slide 7 text

本発表のスコープ

Slide 8

Slide 8 text

© Knowledge Work Inc. 本発表のスコープ 8 システム設計 実装 開発者 テスト QAエンジニア テスト 本発表スコープ

Slide 9

Slide 9 text

本発表のサマリー

Slide 10

Slide 10 text

© Knowledge Work Inc. 本発表のサマリー 10 10 本発表ではQAエンジニアのテストで⾒つかる 簡単なバグを早期に検出するために、 Acceptance Test(受け⼊れテスト)を導⼊し、 その取り組みと効果を検証した事例を紹介します

Slide 11

Slide 11 text

本発表の⽬的

Slide 12

Slide 12 text

© Knowledge Work Inc. 本発表の⽬的 12 12 本発表を通じて、開発者テストの課題を抱える チームや企業の⽅々に対し、 開発プロセスの改善につながる具体的なヒントを 持ち帰っていただくことを⽬的とします

Slide 13

Slide 13 text

© Knowledge Work Inc. Agenda 目次 • 背景と問題 • 問題整理‧課題 • 対策検討 • 取り組み • 効果検証‧考察 • まとめと今後の課題 13

Slide 14

Slide 14 text

背景

Slide 15

Slide 15 text

© Knowledge Work Inc. はじめに 15 15 皆さんのチームでも経験はありませんか? 実装完了後に開発者テストを実施したはずなのに、 QAエンジニアのテストで簡単にバグが発⽣する

Slide 16

Slide 16 text

ナレッジワークの開発体制‧開発プロセス

Slide 17

Slide 17 text

© Knowledge Work Inc. 17 ナレッジワークの開発体制 Product PdM Eng Designer Frontend Engineer Backend Engineer QA Engineer プロダクト 開発 アジャイル開発を進めています

Slide 18

Slide 18 text

© Knowledge Work Inc. 18 開発プロセス PdM Designer Frontend Engineer Backend Engineer QA Engineer 実装 Design Doc Product Requirements Document Design 開発者 テスト テスト分析 / 設計‧テストケース テスト実⾏ 実装 Design Doc 開発者 テスト

Slide 19

Slide 19 text

問題

Slide 20

Slide 20 text

© Knowledge Work Inc. 発⽣していた問題 20 20 開発者テストが終わった後のQAエンジニアのテストで 開発者テストで検出できそうなバグが発⽣したこと

Slide 21

Slide 21 text

© Knowledge Work Inc. バグの具体例:完了ボタンを押すと意図しないダイアログが表⽰される 21 21 • 操作:外部設定管理画⾯で完了ボタンを押下 外部設定管理画⾯ 完了ボタン ブラウザダイアログ 予期せぬエラーが発⽣しました。 再度お試しください。 期待結果 URL:無効なURL エラーメッセージ 実際の結果

Slide 22

Slide 22 text

© Knowledge Work Inc. バグの具体例:⾮表⽰にすべきメニューが表⽰される 22 22 • 操作:メニューボタンを押下 期待結果 実際の結果 ファイル送信 ファイル送信管理 *** ファイル送信済 ファイル送信 ファイル送信管理 ***

Slide 23

Slide 23 text

© Knowledge Work Inc. 問題がもたらした影響 23 23 • ⼿戻りが発⽣し、開発‧QAの⼯数が増加したこと • 開発スピードが低下したこと • メンバーの負担が⼤きくなったこと

Slide 24

Slide 24 text

© Knowledge Work Inc. なぜこの問題が発⽣するのか 24 24 開発者は意図的に 開発者テストを怠っていない

Slide 25

Slide 25 text

© Knowledge Work Inc. なぜこの問題が発⽣するのか 25 25 開発者テストには 3つのパターンがある

Slide 26

Slide 26 text

© Knowledge Work Inc. 開発者テストパターン① 26 26 基本動作のみをテストする • 「ボタンを押したら機能が動いた。じゃあOK」 • 「期待した画⾯に遷移した。問題なし!」 結果 • 細かいUIのバグやエラーハンドリングのバグが⾒逃さ れる可能性がある

Slide 27

Slide 27 text

© Knowledge Work Inc. 開発者テストパターン② 27 27 ⾃分が実装した範囲内でのみテストする • ⾃分が実装したコードの範囲ではバグがないことを確認 結果 • 関連する他の機能への影響やバックエンドとフロントエ ンドの連携部分のバグは⾒落とされやすい

Slide 28

Slide 28 text

© Knowledge Work Inc. 開発者テストパターン③ 28 28 経験‧勘‧思いつきでテストする • 気になる箇所のみテストしてしまう • 業務の割り込みが発⽣すると、どこまでテストしたの かを忘れてしまう‧わからなくなる 結果 • 基本動作で⾒つけられそうなバグが⾒落とされるリス クがある

Slide 29

Slide 29 text

© Knowledge Work Inc. 開発者担当者が原因で問題は発⽣していない 29 29 開発者が意図的に 開発者テストを怠っていない

Slide 30

Slide 30 text

© Knowledge Work Inc. 原因は 30 30 開発者テストの進め⽅‧やり⽅

Slide 31

Slide 31 text

© Knowledge Work Inc. 問題を解決するためには 31 31 どうすればよいのか

Slide 32

Slide 32 text

© Knowledge Work Inc. Agenda 目次 • 背景と問題 ➡問題整理‧課題 • 対策検討 • 取り組み • 効果検証‧考察 • まとめと今後の課題 32

Slide 33

Slide 33 text

問題整理

Slide 34

Slide 34 text

© Knowledge Work Inc. 問題整理 34 34 開発者テストが暗黙的に⾏われている • 何をテストすれば開発者テストがOKなのか明確になって いない 第三者のテスト観点が反映されていないため、実装担 当者に閉じたテストになっている • 開発担当者が⼗分に開発者テストをしたつもりでも、 テスト観点がカバーされていない可能性が⾼い 開発者テスト⽤のテストケースがない • テスト実⾏時にテスト漏れが発⽣するリスクがある

Slide 35

Slide 35 text

課題

Slide 36

Slide 36 text

© Knowledge Work Inc. 課題:開発者テストを明確に⾏える仕組みを構築すること 36 36 • 開発者テストが明確に⾏われていること • 第三者のテスト観点がテストに反映されていること • 開発者テスト⽤のテストケースがあること

Slide 37

Slide 37 text

© Knowledge Work Inc. Agenda 目次 • 背景と問題 • 問題整理‧課題 ➡対策検討 • 取り組み • 効果検証‧考察 • まとめと今後の課題 37

Slide 38

Slide 38 text

対策検討

Slide 39

Slide 39 text

© Knowledge Work Inc. 本質的な課題 39 39 開発者テストを 明確に⾏える仕組みを構築すること

Slide 40

Slide 40 text

© Knowledge Work Inc. 対策検討 40 40 Acceptance Criteria(受け⼊れ基準)を調査

Slide 41

Slide 41 text

© Knowledge Work Inc. Acceptance Criteria(受け⼊れ基準)とは 41 41 ユーザー、顧客、その他の認可団体が、コンポーネントやシ ステムを受け⼊れる場合、満たさねばならない基準 引⽤:ISTQB ⽤語集

Slide 42

Slide 42 text

© Knowledge Work Inc. Acceptance Criteria(受け⼊れ基準)によってできること‧できないこと 42 42 できること • 開発チームとステークホルダー間の共通認識を明確にし、認識 のズレを防ぐことができる できないこと • Acceptance Criteriaは、この機能が満たすべき基準を定める ものであり、 どのように開発者テストを⾏うかまでは適⽤できない

Slide 43

Slide 43 text

© Knowledge Work Inc. 検討結果 43 43 Acceptance Criteria(受け⼊れ基準)は 課題を根本的に解決することは難しいと判断しました

Slide 44

Slide 44 text

© Knowledge Work Inc. ここまでのまとめ 44 44 問題 • 開発者テストが終わった後のQAエンジニアのテストで 開発者テストで検出できそうなバグが発⽣したこと 課題 • 開発者テストを明確に⾏える仕組みを構築すること • 開発者テストが明確に⾏われていること • 第三者のテスト観点がテストに反映されていること • 開発者テスト⽤のテストケースがあること 対策検討 • [⾒送り]Acceptance Criteria(受け⼊れ基準)

Slide 45

Slide 45 text

© Knowledge Work Inc. Agenda 目次 • 背景と問題 • 問題分析‧課題 • 対策検討 ➡取り組み • 効果検証‧考察 • まとめと今後の課題 45

Slide 46

Slide 46 text

取り組み

Slide 47

Slide 47 text

© Knowledge Work Inc. 発⽣していた問題 47 47 開発者テストが終わった後のQAエンジニアのテストで 開発者テストで検出できそうなバグが発⽣したこと

Slide 48

Slide 48 text

© Knowledge Work Inc. 実現できていないこと 48 48 開発者テストが完了したが、 QAエンジニアがテストを開始できる状態ではなかったこと

Slide 49

Slide 49 text

© Knowledge Work Inc. Acceptance Testing(受け⼊れテスト) 49 49 システムが、ユーザーのニーズ、要件、ビジネスプロセスを 満⾜するかをチェックするための公式なテスト。このテスト により、システムが受け⼊れ基準を満たしているかどうかを 判定したり、ユーザー、顧客、その他の認可団体がシステム を受け⼊れるかどうかを判定したりすることができる 引⽤:ISTQB ⽤語集

Slide 50

Slide 50 text

© Knowledge Work Inc. 実現したいこと 50 50 開発者テスト完了 = QAエンジニアがテストを開始できる状態

Slide 51

Slide 51 text

© Knowledge Work Inc. 施策 51 51 Acceptance Test

Slide 52

Slide 52 text

© Knowledge Work Inc. Acceptance Testとは 52 52 開発担当者が開発者テストの拠り所として 設計されたテストケースを指す

Slide 53

Slide 53 text

© Knowledge Work Inc. Acceptance Testの運⽤パターン 53 53 パターン① • QAE設計 → 開発担当者レビュー → 開発担当者実施 パターン② • 開発担当者設計 → QAEレビュー → 開発担当者実施 本事例は運⽤パターン①

Slide 54

Slide 54 text

© 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実施有無を議論 実装・開発者テスト

Slide 55

Slide 55 text

© Knowledge Work Inc. 具体例①:ファイルをダウンロードする機能 55 55 ●操作⼿順:ホーム画⾯からファイルボタンを押下、ファイ ル画⾯のダウンロードボタンを押下 ◻期待結果: • ダウンロードが完了すること • ファイルのタイトルが「ファイル_yyyymmdd.pdf」になって いること

Slide 56

Slide 56 text

© Knowledge Work Inc. 具体例②:新機能の画⾯表⽰ 56 56 ●画⾯遷移  ◻画⾯遷移図の全パスで遷移すること ●0件表⽰  ◻検索結果が0件のとき、ドキュメントに定義された表⽰になること ● エラー表⽰  ◻検索実⾏時にエラーが発⽣した場合、適切にエラー表⽰されること

Slide 57

Slide 57 text

© Knowledge Work Inc. 具体例③:共通基盤をリファクタリング 57 57 ●データを作成  ◻データを作成し、詳細画⾯に作成したデータが表⽰されること ●E2E(⾃動テスト)  ◻tests/specs/xxxxxxのテストがpassすること

Slide 58

Slide 58 text

© Knowledge Work Inc. 具体例:共通基盤をリファクタリング(テスト実施後) 58 58 ●データを作成  ◻データを作成し、詳細画⾯に作成したデータが表⽰されること ●E2E(⾃動テスト)  ◻tests/specs/xxxxxxのテストがpassすること ✔ ✔

Slide 59

Slide 59 text

© Knowledge Work Inc. Acceptance Testで課題解決できたこと 59 59 開発者テストを明確に⾏える仕組みを構築できた • 開発者テストが明確に⾏われていること →何をテストすれば完了なのか明確になった • 第三者のテスト観点がテストに反映されていること →テストケースに第三者の視点‧テスト観点の反映が可能に なった • 開発者テスト⽤のテストケースがあること →テスト漏れが発⽣するリスクを軽減できるようになった

Slide 60

Slide 60 text

© Knowledge Work Inc. Acceptance Testで実現できたこと 60 60 AT完了 = QAエンジニアがテストを開始できる状態 AT:Acceptance Test

Slide 61

Slide 61 text

© Knowledge Work Inc. 定量的な効果 61 61 Acceptance Test導⼊による 定量的な効果はあったのか

Slide 62

Slide 62 text

© Knowledge Work Inc. Agenda 目次 • 背景と問題 • 問題分析‧課題 • 取り組み • 対策検討 ➡効果検証‧考察 • まとめと今後の課題 62

Slide 63

Slide 63 text

効果検証

Slide 64

Slide 64 text

© Knowledge Work Inc. 発⽣していた問題 64 64 開発者テストが終わった後のQAエンジニアのテストで 開発者テストで検出できそうなバグが発⽣したこと

Slide 65

Slide 65 text

© Knowledge Work Inc. 効果検証の指標 65 65 開発者テストで どれくらいバグの流出を防⽌できたのか

Slide 66

Slide 66 text

© Knowledge Work Inc. 効果検証のスコープ 66 66 対象バグ • 開発者テスト中に検出したバグ • QAエンジニアのテスト期間中に検出したバグ • 対象:開発者テストで検出したいバグのみ • 対象外:特殊な条件/複雑なバグ 対象機能開発 • 新機能:1案件 • 機能追加:2案件 • 実装担当者は運⽤開始前後でほぼ同じ ⽐較対象 • Acceptance Test運⽤開始前後

Slide 67

Slide 67 text

© Knowledge Work Inc. 67 67 効果検証:機能開発毎の比較 運用開始前 (開発者テストで検出したいバグ) 運用開始後

Slide 68

Slide 68 text

© Knowledge Work Inc. 68 68 開発者テスト中に 検出したバグ数 QAエンジニアのテスト 期間中に検出したバグ数 (開発者テストで検出したいバグ) 開発者テストの バグ流出防⽌率 運⽤開始前 2件 9件 18% 運⽤開始後 14件 9件 60% 効果検証:運用開始前後の全体比較

Slide 69

Slide 69 text

考察

Slide 70

Slide 70 text

© Knowledge Work Inc. 考察 70 70 • Acceptance Testの定量効果 • 開発状況によって検出されるバグの数は常に⼀定とは限 らない • Acceptance Testでバグを検出できたことは事実であり、 Acceptance Testの導⼊は、バグを早期検出という点にお いて⼀定の効果があったと考えられる • Acceptance Testの導⼊がQAエンジニアに与えた影響 • 開発者がテストにかける時間は増加したものの、バグの 早期検出が進んだことで、開発担当者とQA間のコミュニ ケーションコストが削減された • QAエンジニアはスクリプトテスト以外のテストに時間を 割けるようになった

Slide 71

Slide 71 text

© Knowledge Work Inc. Agenda 目次 • 背景と問題 • 問題分析‧課題 • 取り組み • 対策検討 • 効果検証‧考察 ➡まとめと今後の課題 71

Slide 72

Slide 72 text

まとめと今後の課題

Slide 73

Slide 73 text

© Knowledge Work Inc. まとめ 73 73 問題 • 開発者テストが終わった後のQAエンジニアのテストで 開発者テストで検出できそうなバグが発⽣したこと 取り組み • Acceptance Testを導⼊ 成果 • 暗黙的な開発者テストを明確にしたことにより、 開発者テストのバグ流出防⽌率が向上

Slide 74

Slide 74 text

© Knowledge Work Inc. 今後の課題 74 74 開発者テストで検出したいバグの原因を分析する • Acceptance Testを導⼊してもQA期間中に開発者テストで 検出したいバグが検出されている点については、原因分析 が必要である Acceptance Testのナレッジを作成する • Acceptance Testのナレッジがないため、 個⼈によってAcceptance Testの内容にばらつきが⽣じ、 開発者テストで検出すべきバグが増加するリスクがある

Slide 75

Slide 75 text

© Knowledge Work Inc. 参考⽂献 75 75 ISTQB⽤語集 https://glossary.istqb.org/ja_JP/

Slide 76

Slide 76 text

© Knowledge Work Inc. 最後に 76 76 ご清聴ありがとうございました

Slide 77

Slide 77 text

No content