【Test Engineers Meetup #4】食べログのソフトウェアテスト自動化デザインパターン

© Kakaku.com Inc. All Rights Reserved. 1
⾷べログのソフトウェアテスト⾃動化
デザインパターン
株式会社カカクコム⾷べログシステム本部技術部
Developer Productivityチーム hagevvashi
2022年03⽉30⽇

View Slide

⾃⼰紹介
@hagevvashi 所属
株式会社カカクコム
⾷べログシステム本部技術部
Developer Productivityチーム
経歴
2018~ フロントエンド開発
2021~ テスト⾃動化

View Slide

⽬次 1. はじめに
2. ⾷べログのソフトウェアテスト⾃動化
デザインパターン概要
3. ⾷べログのテスト⾃動化基盤
4. パターン詳細
5. まとめ
6. 参考⽂献・クレジット

View Slide

5. まとめ

View Slide

はじめに
今⽇の話
・テスト⾃動化で気をつけるポイント
・パターン化した解決策の紹介
背景: QA専⾨組織の不在
⾷べログではリリースから17年間
開発者が開発とQAをしてきた
課題: テスト負担の増加
・コード修正後のフィードバックが遅い
・テストが再利⽤できない
解決: テスト⾃動化
環境の専有、デプロイ、テスト実⾏など
テストに必要なアクションをコード化
テスト実⾏毎にテスト結果が同⼀か
テストケースの追加は簡単か
テスト⾃動化で
気をつけるポイント
3選
最初から成功率100%を⽬指してないか

View Slide

DevOpsからDeveloper Productivity Engineeringへ
DevOpsの⾼度な⾃動化と、リーンによってメトリクスが取れるようになって品質改善に
役⽴てるようになった
Developer Productivity とは、⽇本の品質技術が海外で発展して再輸⼊されたもの

View Slide

⾷べログのDeveloper Productivityチームのミッション
「開発サイクルのフィードバックを素早く、リッチにすることで最⾼の開発・テスト体験を実現する」

View Slide

5. まとめ

View Slide

⾷べログのソフトウェアテスト⾃動化デザインパターン概要
ゆもつよ
メソッド
テスト観点表のセルで
並列実⾏
選べる
テスト実⾏単位
Page
Object
賢すぎない
Page Object
データ駆動
テスト
JSONデータ駆動
テスト
Component
Object
Browser
Automation API
Wrapper
StepにWait処理を
書かない
アクセシビリティ向上
アトミックな
デプロイとテストの実⾏
ログインユーザのプール
メンテナビリティ
ファースト
⽣産性の実証
ACL Proxy
Black Hole
Proxy
振り分け
プロキシ
Credential付与
プロキシ
実⾏環境単位で
レポート出⼒
テスト成功率の
しきい値95%
メッセージ
キューデプロイ
ログインタグ
テスト要求分析パターン⾔語・ツール選定のパターン
フレームワーク設計パターン
アーキテクチャ設計パターン
パイプライン設計パターン
テストケース⾃動化パターンインフラ設計パターン
課題
テスト⾃動化の⽬的の
早期のフィードバック、
テストの再利⽤の品質が低い
パターン適⽤後の結果
• コード修正後20分以内の
フィードバック
• 1⽇10回実⾏して成功率90%
• 要件追従が2、3⽇でできる
凡例
パターン
パターン
⾷べログオリジナル
引⽤
適⽤順序
A B

View Slide

5. まとめ

View Slide

⾷べログのテスト⾃動化基盤概要

View Slide

⾷べログのテスト⾃動化基盤全体像
プロダクト
SCM
メッセージ
キュー
⾃動
デプロイ
要求
テスト
⾃動化基盤
⾃動デプロイ
マネージャ
⾃動
テスト
実⾏要求
デプロイ
要求
待ち受け
認証プロキシ
テスト環境
⾃動
デプロイ
実⾏
⾃動
テスト
実⾏
Internal Network
プロジェクト
ソースコード
変更
※1
※2
※3 ※4

View Slide

⾷べログのテスト⾃動化基盤
テスト
ランナー
ブラウザ操作
⾃動化
ツール
ブラウザ
リクエスト
振り分け
Proxy
認証情報
付与
Proxy
外部ドメインへの
リクエスト
（広告・計測 etc）
認証
プロキシ
認証情報
付与済み
テスト環境への
リクエスト
Feature Step Page Object
テスト観点表
テスト
環境
⾃動テスト
実⾏要求
SET
テスト⾃動化基盤
Chrome™
Microsoft
Edge
※5
ゆもつよ
メソッド
Internal Network
Internet

View Slide

Cucumberとは
Cucumberとは:
BDDをサポートしているテスティングフレームワーク
特徴:
⾃然⾔語でテストをプログラムできる
メリット:
・開発者以外にも分かりやすい
・⽣きた仕様ドキュメントとなる
構成要素:
Featureファイル
Stepファイル
・Featureファイル
→要求仕様やテスト⼿順を⾃然⾔語で表現したもの
→Given(事前条件),When(テスト条件),Then(期待結果)
を⽤いて表現する
・Stepファイル
→Featureファイルで表現された要求仕様や
テスト⼿順をプログラミング⾔語で実装したもの
→Given,When,Thenに書かれた⾃然⾔語に
マッチさせて実装する
マッチ

View Slide

5. まとめ

View Slide

テスト⾃動化で気をつけるポイント
3選
テストケースの追加は簡単かテスト実⾏毎にテスト結果が同⼀か

View Slide

本⽇ご紹介するパターン
ゆもつよ
メソッド
並列実⾏
選べる
Page
Object
賢すぎない
Page Object
データ駆動
テスト
JSONデータ駆動
テスト
Component
Object
Browser
Automation API
Wrapper
書かない
アトミックな
ファースト
⽣産性の実証
ACL Proxy
Black Hole
Proxy
振り分け
プロキシ
Credential付与
プロキシ
レポート出⼒
しきい値95%
メッセージ
ログインタグ
①
②
③
①
いきなり100%を⽬指さない
②
容易なテスト実装、
変更に強い
フレームワーク設計
③
安定したテストのための
テストケース⾃動化設計

View Slide

パターン概要1: いきなり100%を⽬指さない
ゆもつよ
メソッド
並列実⾏
選べる
Page
Object
賢すぎない
Page Object
データ駆動
テスト
JSONデータ駆動
テスト
Component
Object
Browser
Automation API
Wrapper
書かない
アトミックな
ファースト
⽣産性の実証
ACL Proxy
Black Hole
Proxy
振り分け
プロキシ
Credential付与
プロキシ
レポート出⼒
しきい値95%
メッセージ
ログインタグ
コンテキスト
さぁテスト⾃動化をはじめよう
ROIの⾼い⾃動テスト開発
※ありがちなテスト⾃動化失敗の例
最初から100%にこだわると
テスト⾃動化が原因で
開発の⽣産性が低下することもある

View Slide

テスト成功率のしきい値95%
課題:
⾃動テストをできるだけ早く
プロジェクトで実⽤的に
使い始めたい
解決:
• 最初のスプリントで95%の成功率を
⽬指す
• 次からのスプリントで
テスト成功率95%から改善する
スプリント
テスト成功率
95%
1 2 3

View Slide

「テスト成功率95%から改善する」仕組み: テスト⾃動化品質ダッシュボード
低
失敗率
CircleCIのinsightsより
※モニタリングにはCircleCIのstore_test_results APIを使⽤
https://circleci.com/docs/2.0/collect-test-data/
特徴
• 過去のテストの統計データを可視化
• テストのStep数の推移
• 実⾏ごとのテスト失敗率
• テスト実⾏時間
• 過去の全てのテスト実施結果から
テスト失敗率を計算、可視化
• テスト失敗率に基づいて
Stepをソートして可視化
メリット
Flaky Testの特定が簡単にできる

View Slide

パターン概要2: 容易なテスト実装、変更に強いフレームワーク設計
ゆもつよ
メソッド
並列実⾏
選べる
Page
Object
賢すぎない
Page Object
データ駆動
テスト
JSONデータ駆動
テスト
Component
Object
Browser
Automation API
Wrapper
書かない
アトミックな
ファースト
⽣産性の実証
ACL Proxy
Black Hole
Proxy
振り分け
プロキシ
Credential付与
プロキシ
レポート出⼒
しきい値95%
メッセージ
ログインタグ
コンテキスト
要求分析、ツール選定、
アーキテクチャ設計が完了し、
⾃動テストのデモができている
効率的にテストを
保守できるようになっている

View Slide

パターン概要2: 容易なテスト実装、変更に強いフレームワーク設計
Feature Step World
Page
Object
Component
Object
責務:
○ページが受け付ける
ブラウザ操作
責務:
○テスト⼿順を実⾏コードに変換
✖テスト⼿順と振る舞い
✖ページが受け付けるブラウザ操作
✖UIパーツが受け付けるブラウザ操作
✖ライブラリ依存部分の集約
責務:
○UIパーツが受け付ける
ブラウザ操作
責務:
○ライブラリ依存部分の集約
責務:
○テスト⼿順と振る舞い
Step の責務からページやUIパーツ、ライブラリ依存の責務を別のオブジェクトに分割
Chrome™
ブラウザ
操作
テスト
アクション

View Slide

© Kakaku.com Inc. All Rights Reserved.
Step
23
Browser Automation API Wrapper
コンテキスト:
ブラウザ操作を⾃動化するテストでは、
テストアクションに機能追加したいことが多い
課題:
ブラウザ操作⾃動化ライブラリに
機能追加が簡単にできない
解決:
Wrapperオブジェクトを⽤意することで、
テストアクションに機能を追加する
結果:
アクションが1つの箇所に集まり、
⾒つけやすく、変更しやすく、DRYになる
World
focus
screenshot
click
Step
Before
After
focus
click
screenshot
focus
click
screenshot
focus
click
screenshot
テストアクション
click
wrapper
Wrapper
凡例

View Slide

Page Object / Component Object
課題:
画⾯仕様の変更の際に、
ありとあらゆる要素を
保守変更する必要がある
原因:
ページ、UIパーツ固有の
ブラウザ操作の実装が
分散してしまっている
①要素の特定
③要素の特定
④クリック
②ホバー
⑥クリック
⑤要素の特定
Step
①
⑤
③ ①
⑤
③
①
⑤
③
①
⑤
③
①
⑤
③
画⾯仕様変更の際
変更箇所が多い

View Slide

Page Object / Component Object
解決:
ページ、UIパーツ
固有の情報を集約した
オブジェクトを⽤意
①サイドナビ
からエリアで
検索
②並び順が⼀番⽬の店舗
の詳細ページに遷移
Step
結果:
画⾯仕様の変更時に
対象オブジェクトを
修正するのみで、
済むようになった
Page
Object
Component
Object

View Slide

パターン概要3: 安定したテストのためのテストケース⾃動化設計
ゆもつよ
メソッド
並列実⾏
選べる
Page
Object
賢すぎない
Page Object
データ駆動
テスト
JSONデータ駆動
テスト
Component
Object
Browser
Automation API
Wrapper
書かない
アトミックな
ファースト
⽣産性の実証
ACL Proxy
Black Hole
Proxy
振り分け
プロキシ
Credential付与
プロキシ
レポート出⼒
しきい値95%
メッセージ
ログインタグ
コンテキスト
フレームワーク設計が完了し、
効率的にテストを
保守できるようになっている
Flakyテストを減らし、
安定したテスト実装が
できるようになる

View Slide

パターン概要3: 安定したテストのためのテストケース⾃動化設計
JSONデータ駆動テスト StepにWait処理を書かないログインタグ
When 都道府県を<都道府県>に設定して検索
Examples:
| 都道府県 |
| 東京都 |
⁝
When ジャンルを<ジャンル>に設定して検索
Examples:
| ジャンル |
| 和⾷ |
異なるテスト⼊⼒毎に、
別のテスト⼿順を⽤意
When 検索条件を<検索条件>に設定して検索
Examples:
| 検索条件 |
| ʼ{ “都道府県”: “東京都” }ʼ |
| ʻ{ “ジャンル”: “和⾷” }ʼ |
After
Before
Feature: ネット予約
@reservation @login
Scenario Outline: ネット予約する
Given ログイン状態である
Given xxページにいる
When xxページでネット予約する
Then 予約の条件がxxである
Before
After
Before
After
JSONデータによって異なるテスト
⼊⼒のテスト⼿順を共通化
Wait処理の実装忘れを防ぎ、テストの
安定性を向上
事前条件で絞り込めるようになる
When(“xxxx”, async function() {
const page = new RestaurantPage();
await this.driver.wait(/* 要素１を待つ */);
page.menu.doSomething();
await this.driver.wait(/* 要素2を待つ */);
});
When(“xxxx”, async function() {
const page = await this.getPage(“レストラ
ンページ”);
await page.menu.doSomething();
});
Wait処理を忘れると、ブラウザがクラッ
シュしたりする
勝⼿に要素の表⽰を待ってくれる
Feature: ネット予約
@reservation @login
Scenario Outline: ネット予約する
Given xxページにいる
When xxページでネット予約する
Then 予約の条件がxxである
事前条件で絞り込めると便利
タグのみになると更に便利

View Slide

JSONデータ駆動テスト
課題:
その制限に対するワークアラウンドとして、
似たようなStep関数を量産してしまう
コンテキスト:
⼀般的なデータ駆動テストで⽤いられる
2次元の表形式では、テンプレートから
柔軟な表現ができないという制限がある
解決:
テストの⼊⼒値と期待結果は
json（オブジェクト）で表現する
結果:
データの種類の追加削除の際に、
テスト⼿順の変更をせずに済む
検索条件が増えたらWhenやThenのパターンが増える
2次元の表形式ではパターンの増減に対応できない
JSON構造で表現することでパターンの増減に対応
検索条件が増えてもWhenやThenのパターンは増えない

View Slide

StepにWait処理を書かない
課題:
Flaky Testを避けるための
要素表⽰を待つ処理が
バラバラに実装されてしまう
解決:
ページオブジェクトや
コンポーネントオブジェクトで
要素表⽰を待つ実装をする
結果:
表⽰を待つ処理の実装漏れによる
Flaky Testの作り込みを防げる
Stepファイル
ページオブジェクト
ページオブジェクトFactory
コンポーネントオブジェクト
要素表⽰を待つ処理

View Slide

ログインタグ
課題:
Cucumberでは実⾏単位が
Featureファイルであり、
Featureファイルをまたいだ
事前条件などで絞り込みができない
解決:
事前条件をタグとして設定する
結果:
事前条件で
絞り込みができるようになった
事前条件で絞り込みできると便利
タグのみになると更に便利
タグで
ログイン・ログアウトを
実装
Given, After で
ログイン・ログアウトを
実装

View Slide

5. まとめ

View Slide

まとめ
3選
テストケースの追加は簡単かテスト実⾏毎にテスト結果が同⼀か

View Slide

5. まとめ

View Slide

参考⽂献
・湯本剛『ゆもつよメソッドによるテスト分析の成り⽴ちと狙い』 (2020)
http://jasst.jp/symposium/jasst20kansai/pdf/S5.pdf
・Dima Kovalenko. Selenium Design Patterns and Best Practices. (ディマ・コヴァレンコ⽟川紘⼦・太⽥
健⼀郎(監訳)、笹井崇司(訳). Seleniumデザインパターン & ベストプラクティス株式会社オライリー・ジャ
パン) (2015)
・Graham Dorothy, Fewster Mark. Software Test Automation. (フュースター・マーク、グラハム・ドロ
シーテスト⾃動化研究会(訳). システムテスト⾃動化標準ガイド株式会社翔泳社) (2014)
・Vaughn Vernon. Implementing domain-driven design. (ボーン・ヴァーノン⾼⽊正弘(訳). 実践ドメイン駆
動設計 : エリック・エヴァンスが確⽴した理論を実際の設計に応⽤する株式会社翔泳社) (2015)
・渋川よしき『アクセシビリティ情報を使った壊れにくいE2Eテスト』 (2021)
https://docs.google.com/presentation/d/e/2PACX-
1vShjxNOc81VhSwY5vDmH2pY6Opc05ZJuY3aemnQ0dmLc10ppBYxJYfKK9DcHLVxp_dQ0u6FUgaL_I_o/em
bed

View Slide

クレジット
※3 Cucumber is a registered trademark of Cucumber Ltd.
※2 Squid NOW icon - copyright Squid Project
※1 Jenkins® is a registered trademark of LF Charities Inc.
※5 Mozilla、Firefoxの商標およびロゴは、Mozilla Foundationの⽶国およびその他の国における登録商標また
は商標です。
※4 Selenium is a registered trademark of Software Freedom Conservancy, Inc.

View Slide

付録

View Slide

パターン関係図
ゆもつよ
メソッド
並列実⾏
選べる
Page
Object
賢すぎない
Page Object
データ駆動
テスト
JSONデータ駆動
テスト
Component
Object
Browser
Automation API
Wrapper
書かない
アトミックな
ファースト
⽣産性の実証
ACL Proxy
Blackhole
Proxy
振り分け
プロキシ
Credential付与
プロキシ
レポート出⼒
しきい値95%
メッセージ
ログインタグ
インフラ設計パターン
テストケース⾃動化パターン

View Slide

【Test Engineers Meetup #4】食べログのソフトウェアテスト自動化デザインパターン

【Test Engineers Meetup #4】食べログのソフトウェアテスト自動化デザインパターン

ハゲワシ

More Decks by ハゲワシ

Other Decks in Programming

Featured

Transcript