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

食べログが挑む!飲食店ネット予約システムで自動テスト無双して手動テストゼロを実現する戦略

 食べログが挑む!飲食店ネット予約システムで自動テスト無双して手動テストゼロを実現する戦略

ハゲワシ

April 14, 2025
Tweet

More Decks by ハゲワシ

Other Decks in Technology

Transcript

  1. © Kakaku.com Inc. All Rights Reserved. 1 食べログが挑む! 飲食店ネット予約システムで 自動テスト無双して

    手動テストゼロを実現する戦略 食べログ開発本部 品質管理部 SETチーム hagevvashi 2025年04月15(火)
  2. © Kakaku.com Inc. All Rights Reserved. 2 自己紹介 株式会社カカクコム 食べログ開発本部

    品質管理部 SETチーム 経歴 2018~ フロントエンド開発 2021~ テスト自動化 社外活動 DevOpsDays Tokyo実行委員 所属 @hagevvashi
  3. © Kakaku.com Inc. All Rights Reserved. 3 お持ち帰りいただきたいこと 1 手動テストゼロでリリースできる案件を探す戦略

    手動テストゼロでのリリースをするためには、 手動テストゼロの恐怖を乗り越える必要がある 自動化とAIだけでテストを完了していいプロジェクトと 人間がしっかりテストした方がいいプロジェクトを 切り分けていくことが自動化AI時代には大切 2
  4. © Kakaku.com Inc. All Rights Reserved. 4 アジェンダ 1. 予約のテスト、件数多すぎ問題

    2. プロジェクトによっては自動化だけで賄えるのでは? 3. テスト戦略の策定 4. 自動テストの実装 5. 自動テストだけでリリースする勇気・元気・やる気
  5. © Kakaku.com Inc. All Rights Reserved. 6 背景 2025年3月期 第3四半期

    決算説明資料 より 食べログのビジネスは飲食店予約を中心に絶好調
  6. © Kakaku.com Inc. All Rights Reserved. 7 課題 0 2000

    4000 6000 8000 10000 12000 14000 16000 18000 0 2 4 6 8 10 12 FY23 1Q FY23 2Q FY23 3Q FY23 4Q FY24 1Q FY24 2Q FY24 3Q テストケース数 案件数 案件数 テストケース数 食べログの品質管理部で担当している予約の戦略案件数の増加に伴い テストケース数が増えている
  7. © Kakaku.com Inc. All Rights Reserved. 8 テ ス ト

    ケ ー ス 数 が 増 え て い る どんなプロジェクトとテストが増えているのか分析しました
  8. © Kakaku.com Inc. All Rights Reserved. 10 分析結果 1. 過去の案件を分析して2タイプに分類

    2. 四半期毎に2タイプの件数を集計 下記の2タイプが増えている バグが潜んでいるため、 テストをするとバグが見つかる バグが潜んでいないため、 テストをしてもバグは見つからない どんな案件が増えているのかを確認 0 2 4 6 8 10 12 FY23 3Q FY23 4Q FY24 1Q FY24 2Q FY24 3Q 四半期毎の対応案件数 四半期毎のタイプ別対応案件数 0 2 4 6 8 10 12 FY23 3Q FY23 4Q FY24 1Q FY24 2Q FY24 3Q タイプA タイプB 目的 方法 結果 タイプA タイプB
  9. © Kakaku.com Inc. All Rights Reserved. 11 分析詳細 0 0.001

    0.002 0.003 0.004 0.005 0.006 0.007 0 0.2 0.4 0.6 0.8 1 1.2 バグ検出効率 バグ検出率 バグ検出効率と検出率の比較分析 タイプB タイプA 過去の案件のバグ検出率、バグ検出効率の 分布を調査 分析方法 バグ検出率 = 検出バグの数/(本番障害の数 + 検出バグの数) バグ検出効率 = 検出バグの数/テストケースの数 分析に用いた指標 タイプA タイプB バグ検出率0.6~1 バグ検出効率0.001以上 バグ検出効率0.001未満
  10. © Kakaku.com Inc. All Rights Reserved. 12 戦略 0 0.001

    0.002 0.003 0.004 0.005 0.006 0.007 0 0.2 0.4 0.6 0.8 1 1.2 バグ検出効率 バグ検出率 バグ検出効率と検出率の比較分析 タイプB タイプA 四半期毎のタイプ別対応案件数 0 5 10 15 FY23 3Q FY23 4Q FY24 1Q FY24 2Q FY24 3Q タイプA タイプB バグ検出率を下げずにバグ検出効率を上げるために テストピラミッドを正常化 タイプA: 人間がしっかりテストした方がいいプロジェクト 安心したリリースのための手動テスト工数を最小化するために 自動テストを整備 タイプB: 自動化とAIだけでテストを完了していいプロジェクト 自動化とAIだけでテストを完了していいプロジェクトと 人間がしっかりテストした方がいいプロジェクトを 切り分けていくことが自動化AI時代には大切
  11. © Kakaku.com Inc. All Rights Reserved. 14 テストピラミッドの正常化 概要 凡

    例 … 手動E2Eテスト … 自動E2Eテスト … 自動単体テスト AsIs ToBe 全てのテストを 手動E2Eで実施している 手動E2Eテストを最小限にするため、下記3つに整理 ①手動E2Eとして残るテスト ②E2Eレベルで自動化するテスト ③単体レベルで自動化するテスト
  12. © Kakaku.com Inc. All Rights Reserved. 15 テストピラミッドの正常化 詳細 1.

    単体テストを増やすため、単体テストから分類できるように設計 2. 残ったE2Eの内、自動化できるところを分類できるように設計 テストピラミッド テストカテゴリ 組み合わせ網羅 モジュールをまたがない 単純なテスト操作 仕様が固まっている 手動E2E 新機能ユースケース 画面単体、入力 (異常系) リリース跨ぎ 自動E2E 店舗アカウント • • 予約経路 • テストの事前準備 • 画面単体、入力 (正常系) • 実行環境(OS/ブラウザ) • 自動単体 在庫 • • 配席 • •
  13. © Kakaku.com Inc. All Rights Reserved. 17 実装概要① テストピラミッド テストカテゴリ

    組み合わせ網羅 モジュールをまたがない 単純なテスト操作 仕様が固まっている 手動E2E 新機能ユースケース 画面単体、入力 (異常系) リリース跨ぎ 自動E2E 店舗アカウント • • 予約経路 • テストの事前準備 • 画面単体、入力 (正常系) • 実行環境(OS/ブラウザ) • 自動単体 在庫 • • 配席 • • 組み合わせ爆発するため、単体テストできるように 在庫ドメインを整理
  14. © Kakaku.com Inc. All Rights Reserved. 18 単体テストできるように在庫ドメインを整理 在庫を構成する要素が、 ソースコードの色々な箇所に散在

    AsIs: E2Eでしかテストできない ユーザー用 コース情報 在庫用 コース情報 店舗管理画面 予約台帳画面 同期 ToBe: 単体テストできる コース、卓、営業時間、の3つのモジュールに整理 例: コース コースの 在庫を作成 コース 登録/変更/削除 店舗管理画面 予約台帳画面 例: コース コースモジュール コースの 在庫を作成 コース 登録/変更/削除 テストエンジニアが在庫機能をテストするために 画面(モジュール含む)を立ち上げる必要がある RSpecがモジュール単体でテストできる テストエンジニア RSpec
  15. © Kakaku.com Inc. All Rights Reserved. 19 画面数が多いため、画面数に対してスケールするように 自動テストのモジュールを整理 実装概要②

    テストピラミッド テストカテゴリ 組み合わせ網羅 モジュールをまたがない 単純なテスト操作 仕様が固まっている 手動E2E 新機能ユースケース 画面単体、入力 (異常系) リリース跨ぎ 自動E2E 店舗アカウント • • 予約経路 • テストの事前準備 • 画面単体、入力 (正常系) • 実行環境(OS/ブラウザ) • 自動単体 在庫 • • 配席 • •
  16. © Kakaku.com Inc. All Rights Reserved. ウェブ画面の 一般的な仕様テンプレート 下記3つを分けて管理できるように自動テストシステムのモジュールを整理 ウェブ画面一般的な操作ロジックは全画面で共有のものなので、

    モジュールとして切り出すことで画面(要素)数に対してスケール "都道府県入力欄": '//input[@name="pref"]' "送信ボタン": '//button[text()="送信する"]' "削除ボタン": '//button[text()="削除する"]' 静的な仕様 動的な仕様 プ ロ ダ ク ト の 編集ページMap 検索ページMap 1つのページオブジェクトを複数のFeatureで共有 When( "{string}"の"{string}"に"{string}"を入力する, (pageName, uiParts, testData) => { input( Page[pageName][uiParts], testData ) } ) "店舗名入力欄": '//input[@name="rst_name"]' "検索ボタン": '//button[text()="検索する"]' "編集ボタン": '//li[1]//button[text()]' Scenario: 店舗を削除する Given "検索ページ"の"店舗名入力欄"に"店舗001"を入力する And "検索ページ"の"検索ボタン"をクリックする And "検索ページ"の"編集ボタン"をクリックする When "編集ページ"の"削除ボタン"をクリックする Scenario: 店舗を編集する Given "検索ページ"の"店舗名入力欄"に"店舗001"を入力する And "検索ページ"の"検索ボタン"をクリックする And "検索ページ"の"編集ボタン"をクリックする When "編集ページ"の"都道府県入力欄"に"神奈川県"を入力する And "編集ページ"の"送信ボタン"をクリックする When( "{string}"の"{string}"をクリックする, (pageName, uiParts) => { click( Page[pageName][uiParts] ) } ) 1つのStepを 複数のページオブジェクトで共有 ①テスト手順、②画面固有要素、③ウェブ画面一般的な操作ロジック 画面数に対してスケールするようにテストの自動テストのモジュールを整理 20 ②画面固有要素(ページオブジェクト) ③ウェブ画面一般的な 操作ロジック(Step) ①テスト手順(Feature)
  17. © Kakaku.com Inc. All Rights Reserved. 21 データがモジュールをまたぐので、 予約のデータライフサイクル全体に対してスケールするように 予約のデータライフサイクル

    を整理 実装概要③ テストピラミッド テストカテゴリ 組み合わせ網羅 モジュールをまたがない 単純なテスト操作 仕様が固まっている 手動E2E 新機能ユースケース 画面単体、入力 (異常系) リリース跨ぎ 自動E2E 店舗アカウント • • 予約経路 • テストの事前準備 • 画面単体、入力 (正常系) • 実行環境(OS/ブラウザ) • 自動単体 在庫 • • 配席 • •
  18. © Kakaku.com Inc. All Rights Reserved. 22 データライフサイクル全体に対してスケールするように予約のデータライフサイクルを整理 入力フォーマット 入力フォーマット

    入力フォーマット 予約登録 予約確認 予約 キャンセル ユーザーの予約確認画面 店舗向け予約台帳画面 ユーザーの予約変更画面 店舗向け予約変更画面 予約情報 複数のユースケース、複数のモジュールで共通の「予約情報」概念を定義 → ユースケース×モジュール の組み合わせに対してスケール 予約経路のプロダクトのユースケースやアーキテクチャを考慮して自動テストを設計 プロダクトのユースケースやアーキテクチャ 自動テスト設計 複数の入力フォーマットに 対応できるように変換 データオブジェクト ・Featureファイルには共通の「予約情報」を記載 ・予約情報のルールに対するバリデーションを一箇所で実施 データオブジェクト Featureファイル
  19. © Kakaku.com Inc. All Rights Reserved. 2025年1月~3月の結果 24 バグ検出率を下げずにバグ検出効率を上げるために テストピラミッドを正常化

    タイプA: 人間がしっかりテストした方がいいプロジェクト 安心したリリースのための手動テスト工数を最小化するために 自動テストを整備 タイプB: 自動化とAIだけでテストを完了していいプロジェクト 手動テストゼロリリースに向けてどう乗り越えていくかは 次回の DevOpsDays Tokyo に乞うご期待! タイプBの案件は 手動テストゼロでリリースできる準備ができたが 「自動テストのみでリリースするのはまだ怖い」という議論も生まれている 手動テストの7割が タイプAに集中できるように なりそう 2025年1月~3月では 3件の案件を通して リグレッションテストの 自動化カバレッジを100%まで増加 4月から1部のタイプBテストで 手動テストゼロリリースを 開始予定