こんにちは。食べログシステム本部の品質管理室のSET(Software Engineer in Test)チームで自動テストの仕事をしている渋谷です。 この記事では可視化を通して自動テストが改善した話と、その話を先日開催されたDevOpsDays Tokyo 2023で発表した経験から得られたことについて書いています。
DevOpsDays Tokyo 2023登壇のきっかけ
今回の記事の内容は4月18日、19日に開催されたDevOpsDays Tokyo 2023のセッションで登壇した際に話した内容の一部になります。
DevOpsDays Tokyo 2023で、SETチームリーダーの@hagevvashiがメインスピーカー、私渋谷がサブスピーカーという形でセッションで登壇しました。
タイトルは「自動テストのFour Keys 〜テストプロセスのソフトウェア化の4つの鍵〜 」です。
私が話した今回記事にした改善の部分については当初は発表する予定はなく、Fun/Done/Learnのふりかえりで私が出した感想がきっかけで@hagevvashiが誘ってくれてサブスピーカーとして話すことになりました。
セッションの様子
すごく緊張したのですが思いのほかリアクションをもらいチャレンジしてみて本当に良かったと思いました。 誘ってくれて準備を進めてくれた@hagevvashiに大感謝です。
（張り切って食べログカラーのオレンジの靴下を履いていったのですが誰にも気づかれず）
食べログの自動テスト
品質管理室の前身であるDeveloperProductivityチーム時代から、自動テストの導入に取り組んできました。
テスト基盤の構築、ゆもつよメソッドを使ったテスト要求分析により自動テストは完成し、POCとして食べログの開発チーム1チームに導入しました。
食べログのソフトウェアテスト自動化デザインパターン より
実はボロボロだった自動テスト
どのくらい安定しているのか誰も分からない
無事自動テストが完成し導入も完了しましたが、自動テストの品質に関する認識がSETチーム内で揃っていないような気がしていました。 それまでflakyテスト(同じコードに対してテスト結果が成功したり失敗したり不安定なテスト)はなく安定していると思っているメンバーもいれば、かなり不安定なのでは、と思っているメンバーもいる状況でした。 自動テストケース(約350件)の成功率の目標を90%とし、Flakyテストの割合が10%以下になるように運用する計画でした。 ですが、全ての実行結果を確認しているわけではなかったので、自動テストが90%以上の成功率をキープできており、エンジニアがデグレードに気がつけるような品質なのかは誰も分かりませんでした。
まずはCircleCI Insightsを使えるようにしてみた
そこで、自動テストをトリガーして実行しているCircleCI Insights ダッシュボードを使えるようにしてみました。
CircleCI Insights ダッシュボードとはテストの成功率、実行時間などの情報を一覧で確認できる機能です。
このダッシュボードで過去1ヶ月分の自動テスト実行結果履歴を一覧にして確認することができます。
これで過去1ヶ月の自動テストの実行のうちどれくらいが成功率90%を上回っていて、どのくらいが下回っているかを確認することができるようになりました。
全てのテストケース（約350件）のうち成功したテストケースの割合が90%を下回ると赤い棒になり、90%を超えると緑の棒になります。
めっちゃ90%を下回っとるやんけ
赤い棒が圧倒的に多いので、多くの実行結果が90%の閾値を下回っていることが分かります。 以前は「なんとなく自動テストが原因で失敗しているテストケースが多い気がする..でも全部見てないから分からない」という状況でしたが、全部の実行結果を見ると一目瞭然でした。 ここでチーム全体で「自動テストの成功率が目標の90%を下回っている」という共通認識ができたのでチーム一丸となって改善活動を始めました。
テストケースの実行結果が不安定だった原因
まずはInsightsの結果を確認しながら、失敗しているテストの分類を行いました。 以下が分類の結果です。
- テストケースが新しい仕様に追従できていない
flakyテストかpushされたコードのデグレードが原因か見分けがつけづらく、発見が遅れていて対応ができていない状態でした - データメンテナンスができていない
テストデータを管理しきれておらず、データのメンテナンスができていませんでした - 実行結果が不安定なコードがある
コードやログから失敗原因の調査が必要なケースです
改善活動開始！！
原因分類の結果から1つ1つ対応をしていきました
- masterブランチでの定期実行結果をInsightsで確認できるようにする
テストの修正にあたって、flakyテストとデグレードによる失敗を切り分けられるようにしました - テストケースが新しい仕様に追従できていない・データメンテナンスができていない -> テスト修正・テストデータマスタ化
失敗原因が特定できるテストの修正とテストデータのマスタ化を進めました - 実行結果が不安定なコードがある -> 失敗原因が不明なテストの原因調査
何度もデバッグできる環境ができたので、失敗原因が不明なテストの調査にも乗り出しました
改善の結果
改善の結果、テスト成功率は97~98%ほどを維持するようになりました。
「masterブランチでの定期実行結果をInsightsで確認できるようにする」対応の結果、時間がかかっていたflakyテストの発見と修正がすぐにできるようになりました。
新たなflakyテストを発見してもすぐに対応できるようになり、発見から修正のサイクルが早くなりました。
可視化が役立ったポイント
(1) チームみんなで見る
まずは朝会でチームみんなでInsightsの結果を確認するようになりました。 それぞれ実行したテスト結果を各々で確認することはありましたが、全員で定期的に確認する活動はこれが初めてでした。 ここでまず、テストの成功率、デグレードではなくテストコードやテストデータの不備で発生しているテストケース失敗の存在について共通の認識が生まれました。
(2) 知っていることを共有する
このInsights確認のタイミングで発生しているflakyテストの対応チケットを起票することにしました。 ここで、なぜ失敗しているのか、どうしたら修正できるのかについて各々機能に詳しい人、実装した人、データに詳しい人が意見を出し合い解決策の共有ができるようになりました。 テスト修正に必要な知識はそれぞれ持っていましたが、共有する機会は少なく、修正に詰まってしまった後に「あ、それ知ってるよ！」というようなことがあり勿体無い感じでした。 全員がいる場で修正方針が立てられるようになり、起票した時点で誰でもどのチケットでも対応できる状況になりました。
(3) 改善後の結果を確認しあう
最後に、メンバーの対応がマージされると翌日のInsights確認のタイミングで改善した事をみんなで確認できます。 今まではそれぞれのメンバーが片手間で修正して、ひっそりと自分で結果を確認するのみでしたが、メンバー全員で確認できるようになり成果も共有できてちょっとハッピーな気持ちも増えました。
DevOpsDays Tokyo 2023で改善活動の話をしてみて
セッションに対してもらったコメント
- 自分の会社でも可視化をしたいので、セッションの話を参考にしたい
- 食べログでやっているFour Keysの活動について詳しく聞きたい
- 可視化は認識の違いを埋めるのに重要だと改めて気づいた
- 孤独だったテスト修正がチームの活動になったのはいい話だった
最初は社外の人にシェアするなど恐れ多いと思いながらセッションに臨みましたが、自分が思っていた以上にリアクションをもらえました。
今回は実際にチョットツライがみんなハッピーに変わった事例で、自分にとって思い入れのある改善テーマだったので良いリアクションやコメントをいただけて本当に嬉しかったです。
ブースやdiscordでコメントをくださった皆様本当にありがとうございました。
同じように自動テストの改善を頑張っている企業の担当者さんとお話しできた
これも初めての経験でした。 同じ日に自動テストの改善についての他企業さんのセッションがあったので、思い切ってブースに質問をしにいきました。 根掘り葉掘りと質問してしまったのですが、同じように自動テスト改善を頑張っている企業さんのお話を聞けて大変刺激になりました。 刺激になっただけではなく、セッションや質問で得たことを後日チームメンバー各々持ち帰り、今期のチーム目標に落とし込むことができました。 スピーカーとしてだけではなくリスナーとしてもいい経験をすることができました。
自分達の活動に自信を持てた
社内でだけ自動テストの活動をしているとどうしても視野が狭くなってしまい自分達が、結構イケてるのかイケてないのか分からなくなってしまいます。 今回改善活動を通して、自分の中では大変満足していたのですが、セッションで登壇してお話ししてフィードバックをもらうことで客観的にもいい感じなのか！と大変自信になりました。 Four Keysもそうですが、客観的に自分達がどの位置にいるのか測れる指標があるように、セッションの発表を通してフィードバックという客観的な感想やコメントをもらえたことで自分達の今の状態を確認することができました。
最後に
今回の改善は可視化が大きな役割を果たしました。
発表したセッションのタイトルも「自動テストのFour Keys 〜テストプロセスのソフトウェア化の4つの鍵〜 」だったのですが、今可視化界隈は激アツです。
可視化が重要なことは私自身も頭で認識していましたが、実際に使ってみると可視化された情報という共通認識のもとチームで議論できるようになったことが一番のポイントだったように思います。
個人に閉じていたテスト修正の対応が、チーム全体でナレッジや、対応の負担、直った喜びをシェアできるようになりました。
今回そんな実感の伴った経験を共有することで、少しでもDevOps業界に貢献できたら嬉しいです。
「自動テストのFour Keys 〜テストプロセスのソフトウェア化の4つの鍵〜 」 ではテスト成功率の改善だけではなく、テスト実行時間を半分にした話もしています。ぜひご一読いただけると嬉しいです。
食べログでは一緒に働いてくれるSoftware Engineer in Test（SET）【食べログ】を大募集しております。是非ご応募お待ちしています。
最後まで読んでいただき、ありがとうございました。
