自動テストのFour Keys ~テストプロセスのソフトウェア化の4つの鍵~

© Kakaku.com Inc. All Rights Reserved.
自動テストのFour Keys
~テストプロセスのソフトウェア化の4つの鍵~
1
株式会社カカクコム食べログシステム本部品質管理室
SETチーム hagevvashi 渋谷優美
2023年04月18日

View Slide

© Kakaku.com Inc. All Rights Reserved. 2
自己紹介
@hagevvashi 所属
株式会社カカクコム
食べログシステム本部品質管理室
SETチーム
経歴
2018~ フロントエンド開発
2021~ テスト自動化
社外活動
DevOpsDays Tokyo実行委員
アジャイルSQC研究部会

View Slide

自己紹介
渋谷優美所属
株式会社カカクコム
食べログシステム本部品質管理室
SETチーム
経歴
2015~スーパーの子会社で発注システムの開発
2017~食べログにやってくる（運用チーム）
2019~この頃からテストの仕事を始める
2023~品質管理室SETチーム

View Slide

本日お持ち帰りいただきたいこと
4
・テストプロセスのプロセス品質
・自動テストのソフトウェア品質
を自動テストのFour Keysを元に分析・評価し作り込むことが重要
テスト自動化はテストプロセスの受け入れテスト作業のソフトウェア化
Lead time to
recover from
test failure
Testing
frequency
Testing failure
rate
Lead time for
testing
自動テストのFour Keysを提案

View Slide

アジェンダ 1. 背景：「DevOpsのFour Keys」と「自動テストのFour Keys」
2. 自動テストのFour Keys
3. 自動テストのFour Keysの品質ダッシュボード
4. 自動テストのFour Keys改善のための取り組み①
5. 自動テストのFour Keys改善のための取り組み②
6. まとめ

View Slide

6. まとめ

View Slide

食べログ品質管理室ミッションと3つの基本理念
7
お客様目線の品質を
ビジネス成功に
素早くリッチな
フィードバック
データ可視化と
徹底的な自動化
基本理念
お客様の「当たり前」を当たり前に満たせる
プロダクト品質をビジネス成功の鍵に
プロダクト品質を改善し続けるため、
開発・テストプロセスで学習フィードバックを
素早くリッチに回せるように
データ可視化による課題分析と自動化による効率化で
最高の開発体験を実現
学び続けるプロセスと最高の開発体験から高品質なプロダクトを

View Slide

食べログ品質管理室ミッション:学び続けるプロセスと最高の開発体験から高品質なプロダクトを
8
実装
分析/設計テストリリース
エンドユーザ
要
望
開発チーム
設計
仕様
整理
影響
分析
動作
確認
RSpec
結合
テスト
実機
テスト
VEX
高品質な
プロダクト
再発
防止策
障害
対応
最高の開発体験
学び続けるプロセス
プロダクト品質を継続的に改善するため
バリューストリームマップを改善する

View Slide

食べログ品質管理室の活動とソフトウェア開発プラクティスのトレンド
9
トヨタ
生産方式
TQC
QC活動
パイプライン
自動化
受け入れ
テスト自動化
クラウド IaC
ソフトウェア
オブジェクト
パターン
スクラム
XP
DevOps
継続的デリバリー
Developer
Productivity
リーン
プロセス改善
の手法
アジャイル
自動化(ソフトウェア化)
プロセス改善
ソフトウェア開発プラクティスの変遷
反復プロセス
メトリクスによる可視化
アジャイル：ソフトウェア開発を反復プロセスで管理
DevOps：反復開発プロセスの手作業をソフトウェア化
Developer Productivity：反復プロセスの継続的な改善

View Slide

背景：Four keysとは？
10
•デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度
•変更のリードタイム - commit から本番環境稼働までの所要時間
•変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%）
•サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間
出典：
https://cloud.google.com/blog/ja/products/gcp/using-the-
four-keys-to-measure-your-devops-performance
“ソフトウェア開発チームのパフォーマンスを示す4つの指標”
→CI/CDやクラウドなどのDevOpsの要素技術の活用による
ソフトウェア開発チームのパフォーマンスの向上を示すことができる

View Slide

背景：プロセスとソフトウェア面から見たFour Keys
11
プロセス
プロセス
入力出力
①プロセスの
実施回数
②プロセスの
リードタイム
③誤出力率
④誤出力からの
回復時間
ソフトウェア
ソフトウェア
入力出力
①スループット ②レイテンシー
③誤出力率
④誤出力からの
回復時間
•デプロイの頻度- 組織による正常な本番環境へのリリースの頻度
•変更のリードタイム- commit から本番環境稼働までの所要時間
•変更障害率- デプロイが原因で本番環境で障害が発生する割合（%）
•サービス復元時間- 組織が本番環境での障害から回復するのにかかる時間
DevOpsの活動によってソフトウェア化される手作業が含まれるプロセスの
プロセス品質とソフトウェア品質の両者を共通して分析・評価

View Slide

背景：DevOpsのFour Keysと自動テストのFour Keys
12
Lead time for
changes
Deployment
frequency
Change failure
rate
Lead time to recover
from test failure
DevOpsのFour Keys （パイプライン全体が対象）
Lead time for
testing
Testing
frequency
Testing failure
rate
自動テストのFour Keys （テストプロセスが対象）
Lead time to
recover

View Slide

背景：DevOpsのFour Keysと自動テストのFour Keys
13
Lead time for
changes
Deployment
frequency
Change failure
rate
from test failure
DevOpsのFour Keys （パイプライン全体が対象）
自動テストのFour Keysはテストプロセスを対象としているが、
DevOpsではパイプラインの繰り返し頻度が多いため、
自動テストのFour Keysの改善の影響はパイプライン全体に及ぶ
ビルドテストデプロイ
Lead time for
testing
Testing
frequency
Testing failure
rate
パイプライン
自動テストのFour Keys （テストプロセスが対象）
Lead time to
recover

View Slide


View Slide

自動テストのFour Keys
15
自動テストがトリガー ※されてからレポート出力されるまでの所要時間
自動テストがトリガーされる頻度
※コード変更や手動実行、スケジュール実行などによるテスト実行要求
自動テストが失敗する割合(%)
Flakyテストが発生してから修復完了までに要する時間
Lead time to
recover from test
failure
Testing
frequency
Testing failure
rate
Lead time for
testing
自動テスト開発チームのパフォーマンスを示す4つの指標
受け入れテストをソフトウェア化するテストプロセスの
プロセス品質とソフトウェア品質の両者を共通して分析・評価

View Slide

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

View Slide

食べログのテスト自動化基盤: 受け入れテストを自動実行するためにソフトウェア化
17
テスト
ランナー
ブラウザ操作
自動化
ツール
ブラウザ
リクエスト
振り分け
Proxy
認証情報
付与
Proxy
リクエスト
認証
プロキシ
認証情報
付与済み
リクエスト
テスト観点表
テスト
環境
自動テスト
実行要求
SET
Chrome™
Microsoft
Edge
※4
ゆもつよ
メソッド
Internal Network
Internet
自動テストのソフトウェア群
※1
※2 ※3

View Slide

自動テストのFour Keysによって食べログのテスト自動化基盤をプロセス、ソフトウェア面から評価
18
テスト
ランナー
ブラウザ操作
自動化
ツール
ブラウザ
リクエスト
振り分け
Proxy
認証情報
付与
Proxy
リクエスト
認証
プロキシ
認証情報
付与済み
リクエスト
テスト観点表
テスト
環境
自動テスト
実行要求
SET
Chrome™
Microsoft
Edge
ゆもつよ
メソッド
Internal Network
Internet
Testing
frequency
Lead time for
testing
Lead time to
recover from
test failure
Testing failure
rate

View Slide

自動テストのFour Keysの因数分解
19
A. Lead time for testing B. Testing frequency C. Testing failure rate
D. Lead time to recover
from test failure
パイプライン
実行時間
デプロイ実
行時間
テスト
実行時間
テスト
セットアップ時間
テストケース
実行時間
テスト環境上限
失敗率
デプロイ
成功率
テストJob
成功率
Flaky修正
リードタイム
セットアップ
成功率
テストケース
成功率
トリアージ
リードタイム
パイプライン
実行回数
パイプライン
成功率
凡例
KPI
自動テストFour Keys
影響先

View Slide

自動テストのFour Keysの暗黙的な影響
20
from test failure
パイプライン
実行時間
デプロイ実
行時間
テスト
実行時間
テスト
テストケース
実行時間
失敗率
デプロイ
成功率
テストJob
成功率
Flaky修正
リードタイム
セットアップ
成功率
テストケース
成功率
トリアージ
リードタイム
パイプライン
実行回数
パイプライン
成功率
凡例
KPI
影響先
Lead time for testingが短くなると、
デバッグが楽になり
Lead time to recover form test failureが短くなる

View Slide

自動テストのFour Keysの暗黙的な影響
21
from test failure
パイプライン
実行時間
デプロイ実
行時間
テスト
実行時間
テスト
テストケース
実行時間
失敗率
デプロイ
成功率
テストJob
成功率
Flaky修正
リードタイム
セットアップ
成功率
テストケース
成功率
トリアージ
リードタイム
パイプライン
実行回数
パイプライン
成功率
凡例
KPI
影響先
Lead time to recover form test failureが短くなると
Flakyテストがたまりにくくなるので
Testing failure rateが低くなる

View Slide


View Slide

自動テストのFour Keysの因数分解
23
from test failure
パイプライン
実行時間
デプロイ実
行時間
テスト
実行時間
テスト
テストケース
実行時間
失敗率
デプロイ
成功率
テストJob
成功率
Flaky修正
リードタイム
セットアップ
成功率
テストケース
成功率
トリアージ
リードタイム
パイプライン
実行回数
パイプライン
成功率
凡例
KPI
影響先

View Slide

食べログの自動テスト品質ダッシュボード
24
パイプライン
実行時間
パイプライン
実行回数
パイプライン
成功率
失敗率
デプロイ
成功率
テストJob
成功率
デプロイ
実行時間
テスト
実行時間

View Slide

自動テスト品質ダッシュボードの改善: 目的は"チームメンバー一人一人が意思決定できる”こと
25
引用元: https://www.slideshare.net/smorisaki/3-153533840
”ソフトウェア開発活動のデータとアナリティクスの３原則”, 森崎修司

View Slide

自動テスト品質ダッシュボードの改善
26
As-Is CircleCI Insights(品質ダッシュボード)
To-Be CircleCI Insights(品質ダッシュボード)
情報が不適切
分析が不可能
行動に移せない
情報が適切
分析が可能
行動に移せる
複数の異なる目的のテスト実行結果が混ざってしまっている
• 最新バージョンのプロダクトのテスト
• 安定バージョンのプロダクトのテスト
• SETチームによるデバッグ
テスト実行の目的毎にダッシュボードを分離
安定バージョンのプロダクトのテスト実行最新バージョンのプロダクトのテスト実行

View Slide

自動テスト品質ダッシュボード改善の取り組み
27
CircleCI
開発者
SET
スケジューラー
安定版への
定期実行
GitHub
CircleCI Insights(品質ダッシュボード)を3つに分離することで
プロダクトバグ・自動テストバグ・インフラ起因のテスト失敗を切り分けられるように
プロダクト
コード
変更
テスト
コード
変更
自動テスト実行
プロダクト
バグ
自動テスト
バグ
インフラ起因
テスト失敗
自動テスト実行
CircleCI Insights
(品質ダッシュボード)

View Slide

6. まとめ

View Slide

取り組み① Lead time for testingの改善
29
from test failure
パイプライン
実行時間
デプロイ実
行時間
テスト
実行時間
テスト
テストケース
実行時間
失敗率
デプロイ
成功率
テストJob
成功率
Flaky修正
リードタイム
セットアップ
成功率
テストケース
成功率
トリアージ
リードタイム
パイプライン
実行回数
パイプライン
成功率
凡例
KPI
影響先

View Slide

30
取り組みによるFour Keysの結果とアクション
A. Lead time for
testing
パイプライン
実行時間
デプロイ実
行時間
テスト
実行時間
テスト
テストケース
実行時間
55分→20分
37分→11分
18分→9分
3分→2分 34分→9分
アクション①
Jobの並列実行
アクション③
ビルド処理のローカル化
アクション②
テストデータクリーンアップ
方法のCLI化
アクション④
テストケース分散方法の均一化
Lead time for testingが長いことによる問題
・プロダクトバグの発生に気づくのが遅れる

View Slide

31
テスト
ランナー
ブラウザ操作
自動化
ツール
ブラウザ
リクエスト
振り分け
Proxy
認証情報
付与
Proxy
リクエスト
認証
プロキシ
認証情報
付与済み
リクエスト
テスト観点表
テスト
環境
自動テスト
実行要求
SET
Chrome™
Microsoft
Edge
ゆもつよ
メソッド
Internal Network
Internet
プロセスのリードタイムを改善するために
ソフトウェア設計を改善

View Slide

GUI
取り組み① 解決のための4つのアクション
32
JS
Build
CSS
Build
JS
Build
CSS
Build
デプロイ
実行時間
テスト実行
パッケージ取得
パッケー
ジ取得
解凍テスト実行
テストセットアップ時間
As-Is
To-Be
As-Is
To-Be
テスト実行
CLI
テストデータ
クリーンアップ時間
シナリオ数
As-Is
To-Be
As-Is
To-Be
テスト
テストケース
実行時間
テストケース
実行時間
テスト実行
アクション①
Jobの並列実行
アクション③
ビルド処理のローカル化
アクション②
方法のCLI化
アクション④

View Slide

アクション② テストデータクリーンアップ方法のCLI化
33
課題
原因 1. 一回のテスト実行で数十件のデータを作成
2. 画面操作では一括でデータをクリーンアッ
プできない
解決策
テストデータをクリーンアップするbatchを作成
自動テスト実行毎にbatchを実行
テストデータクリーンアップ時間が長い
GUI テスト実行
CLI
テストデータ
クリーンアップ時間
As-Is
To-Be テスト実行
アクション②
方法のCLI化
パイプライン
実行時間

View Slide

アクション④ テストケース分散方法の均一化
34
課題
原因
解決策
シナリオ数
As-Is
To-Be
テストケース
実行時間
アクション④
テスト実行時に
Example1行毎にFeatureファイルを分割する
テストケース数の偏り
1. テストケース実行時間短縮化のため
テストケースを並列実行
2. Cucumberでは
FeatureファイルのScenario Outlineの
Examplesがすべて実行される
→cucumberとCircleCIの仕様のアンマッチのため
cucumberをハックする必要があった

View Slide

アクション④ CucumberとCircleCIの仕様のアンマッチ
35
アンマッチ1
CucumberとCircleCIで自動テストの分散方法
xml
テストレポート
Cucumber
過去のテストレポートの
テスト実行時間に基づいて
Cucumberへテストケース分配
Featureファイル１
Featureファイル３
Featureファイル２
アンマッチ2
CircleCI
Cucumber
Cucumber
Cucumber
AsIs ToBe
CircleCIで利用されている
xUnitの概念
cucumberの実行単位修正後のcucumberの実行単位
実行ファイル Featureファイル "Feature+シナリオ"
ファイル
testsuites なしなし
testsuite シナリオなし
testcase ステップ Feature+シナリオ
アンマッチ2
アンマッチ1

View Slide

アクション④ 実装の工夫 ASTを用いたFeatureの構造変換
36
Feature AST 分割後のAST
1
2
3
4
1
2
3
4
1
2
3
4
実はツリー構造になっているので、
プログラムで非正規化が可能
自然言語だから
一見すると構造がなさそうに見える
AST
変換
Examples分解
非正規化

View Slide

6. まとめ

View Slide

取り組み② Lead time to recover from failureの改善
38
from test failure
パイプライン
実行時間
デプロイ実
行時間
テスト
実行時間
テスト
テストケース
実行時間
失敗率
デプロイ
成功率
テストJob
成功率
Flaky修正
リードタイム
セットアップ
成功率
テストケース
成功率
トリアージ
リードタイム
パイプライン
実行回数
パイプライン
成功率
凡例
KPI
影響先

View Slide

取り組み② Lead time to recover from failureの改善
39
from test failure
Flaky修正
リードタイム
Flakyテストのトリアージ
リードタイム
1. 品質ダッシュボードの改善
2. パイプライン成功率の改善
3. 朝会でのダッシュボード確認
4. flakyテストの見える化
5週間→1週間
- Lead time for testingの改善
- SET向けデバッグ用workflow構築
①トリアージリードタイム改善のアクション ②パイプライン実行時間改善のアクション
取り組みによるFour Keysの結果とアクション
Lead time to recover from test failureが長いことによる問題
• 未解決のflakyテストがたまり、テストケース成功率が低下する

View Slide

取り組み① Lead time for recover from testing failureの改善
40
テスト
ランナー
ブラウザ操作
自動化
ツール
ブラウザ
リクエスト
振り分け
Proxy
認証情報
付与
Proxy
リクエスト
認証
プロキシ
認証情報
付与済み
リクエスト
テスト観点表
テスト
環境
自動テスト
実行要求
SET
Chrome™
Microsoft
Edge
ゆもつよ
メソッド
Internal Network
Internet
プロセスのリードタイム改善のために
ソフトウェアの運用方法を改善

View Slide

取り組み② Flakyテストのトリアージリードタイム改善の4つのステップ
41
flaky
flaky
①ダッシュボード
改善
flaky
Flakyテスト結構
あるんじゃね？安定してるな
思ったより
失敗してる
Flakyテスト結構
ある
flaky
flaky
FlakyテストX
直し方わからん
flaky
FlakyテストY
急いだ方がいい
②パイプライン
成功率改善
④Flakyテスト撲滅
プロジェクト化
flaky
手が空いたから
FlakyテストY
潰そう
FlakyテストXは
私が直す
flaky
Flakyテストに対するSETチームのケイパビリティ
発見トリアージ修正修正リードタイム
できるできない放置計測不可能
できないできない放置計測不可能
できるできる放置計測不可能
できるできるする 5週間 ⇨ 1週間
Flakyテストに対するSETチームのケイパビリティ Flakyテストに対するSETチームのケイパビリティ
FlakyテストX
こう直せばいい

View Slide

昨日flakyテスト修正の
PRマージしたから成功
率上がっているね
取り組み② Flakyテストのトリアージリードタイム改善後のチームの振り返り
42
自動テスト品質ダッシュボード
Flakyテストカンバンボード
新たなflakyテストが発
生していないか
課金ページのリニュー
アルが入ったから文言
が変わってテストが落
ちているね
デグレが発生している
PRはあるか
施設一覧を修正してい
るPRで、デグレが原因
で施設一覧のテストが
軒並み落ちているね
実行時間が伸びていな
いか
テスト実行時間は問題
ないけど、デプロイに
時間がかかることがあ
るね
環境トラブル（デプロ
イ失敗やテスト実行準
備トラブル）は発生し
ていないか
QAサーバの容量がカツ
カツで
disk fullになることが
あるね
テスト実行時間短くす
るPRマージされたから、
実行時間が20分になっ
たね
Insightで
みんなが自動テストの
状況をすぐ認識できる
ようになった
Insightsにより可視化さ
れて、やったことの成果
が数値でわかるのは良い
Flaky修正用のAsanaボー
ド作成していただきあり
がとうございます。
自動テストのトラブルを
asanaで管理するように
なって、状況の見える化
ができた
Sprintのタスクヘルプ形
が
うまくいっているようだ
改善後のチームの振り返りの付箋

View Slide

取り組み② flaky修正リードタイム改善のアクション
43
SET向けデバッグ用workflowの構築
Lead time for testing の改善
テスト実行時に
シナリオを指定できる
特定のシナリオだけだから
テストがすぐ終わる

View Slide

6. まとめ

View Slide

まとめ①
45
-自動テストのFour keysを計測することで自動テスト開発チームのパフォーマンスを示せる
・“自動テストのFour Keys”を提案
Lead time for testing Testing frequency Testing failure rate
from test failure
-チームメンバーが意思決定できるように品質ダッシュボードを改善
-自動テストソフトウェアの設計を改善することでLead time for testingを改善
-自動テストソフトウェアの運用を改善することでLead time to recover from test failureを改善
・自動テストのFour Keys改善のための食べログでの取り組み

View Slide

まとめ②
46
実装
分析/設計テストリリース
エンドユーザ
要
望
開発チーム
設計
仕様
整理
影響
分析
動作
確認
RSpec
結合
テスト
実機
テスト
VEX
高品質な
プロダクト
再発
防止策
障害
対応
最高の開発体験
学び続けるプロセス
食べログの品質管理室ではバリューストリームマップの最適化のための
“学び続けるプロセス”をデータ可視化と徹底的な自動化によって実現しています

View Slide

クレジット

View Slide

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

View Slide

自動テストのFour Keys ~テストプロセスのソフトウェア化の4つの鍵~

自動テストのFour Keys ~テストプロセスのソフトウェア化の4つの鍵~

ハゲワシ

More Decks by ハゲワシ

Other Decks in Programming

Featured

Transcript

自動テストのFour Keys​ ~テストプロセスのソフトウェア化の4つの鍵~​

自動テストのFour Keys​ ~テストプロセスのソフトウェア化の4つの鍵~​

ハゲワシ

More Decks by ハゲワシ

Other Decks in Programming

Featured

Transcript

自動テストのFour Keys ~テストプロセスのソフトウェア化の4つの鍵~

自動テストのFour Keys ~テストプロセスのソフトウェア化の4つの鍵~