QAEがflakyテストを修正する意味

こんにちは！
SODA社QAエンジニアのmachiです！

今日はQAエンジニア（以下、QAE）がflakyテストを修正するに至った意図や、その活動内容をお話ししたいと思います。

※"flakyテスト"という言葉は、世の中に数多くの記事やお話があるのでそれ自体の説明は割愛します。

本記事は弊社VPoTの発表を受けての記事でもあります。
https://speakerdeck.com/rinchsan/qaekasheng-cheng-aitoyue-eru-sohutoueakai-fa-nojing-jie-xian

Whyから考える

たまに投げかけられる疑問にこのようなものがあります。

なんでQAEがflakyテストを修正するんですか？

これに対して特に何の感情もなく、「え、やれる人がやったらよくないですか？」と答えるわけですし、本当にそう考えています。

なぜそう思うのかを考えると、根源が2つあるように思います。

私のQAEとしての恩師からは

品質のことなら何でもしていきましょうよ

今は亡きにしさん（西康晴さん）は

QAは、開発者に「お？腕前が上がったな？」と感じさせることができたら成功なんですよ

というお話を聞き、確かにそうだよなあ〜そこから始めたいよなあ〜という気持ちがあるのです。

例えば今回のflakyテストが修正されたらきっと日頃の小さなストレスから解放されて、開発組織というよりは
「チームのみんながより良いものを素早く作れるようになりそうだな！」
「余計なことにマインドシェアを奪われずにプロダクトに向き合いながら開発できそう！」
などと考えるわけです。

だから私は、徹底的に開発環境を改善してよりよい開発体験を生み出したいし、遠回りでもそれが品質になっていくと思っているのです。
ここでいう品質とは、直接的にはプロダクトコードの質、開発者体験の質を指し、それらが向上した先にプロダクトとしての質であり、雑に品質特性で言えば保守性や機能性、信頼性、理解性などがあると考えています。

不安定なテストが開発を止める

ここからが本題です。

CIで回っているテストの失敗がローカルでは再現せず、前回は通ったのに今回は失敗する。変更箇所と関係ないのに！
これは世の開発組織あるあるですよね！（と思っている）
そうです。我々もCIが不定期に落ちるようになっていました。

flakyテストが増えると、CIの信頼性が下がり、チームの開発リズムが乱れていきます。
多くの場合、再実行すれば通るため一見問題はないように見えます。が、その再実行には時間がかかります。1回あたり数分でも、チーム全体で積み重なると大きな損失になります。CIの料金もバカにならないし、ユーザーにすぐ価値を届けられないしで誰も幸せになりません。

最初のうちは「仕方ない」と受け流していましたが、発生頻度が増えるにつれて開発効率が明らかに低下しました。リリース前にCIが赤くなり、担当者が原因を調べる。そのたびに流れが止まります。再現性がないため根本原因を特定しづらく、結果としてretryで逃げるようになります。
リリース担当者からすると不安でしょうがないはずです。

この状況を抜け出すために、まずflakyの実態を正確に把握する必要がありました。

可視化とAIによる修正支援

とにかくじゃんじゃん修正していこう！というやる気も重要なのですが、我々はまずCIの失敗通知をSlackに集約し、テスト名と発生回数を集計する仕組みを導入しました。
これにより、どのテストがどのくらい不安定なのかが一覧で分かるようになりました。
flakyテストを「感覚」ではなく「データ」で捉えられるようになったことは大きな前進でした。

次に、収集したログをもとにAIに解析を依頼しました。
非同期処理の待機不足、テストデータの初期化漏れ、時刻依存、並列実行による副作用など、AIが原因の候補を提示してくれます。
AIに感謝！

プロダクトコードにさほど明るくなく、かつこれまでコードを書いてこなかった私のようなQAEでもログを読み解くより速く仮説を立てられるため、修正サイクルを短く保てました。
AIに感謝！！

もちろんAIがすべてを解決してくれるわけではありません。
再現性のない問題に対して方向性を示してくれることは大きな助けになります。修正を繰り返すうちに、チーム内でも「不安定になりやすい書き方」への共通理解が生まれていきました。

flakyテストを監視し、防止する

flakyテストを修正して終わりにしないために、ダッシュボードを作成し、継続的に監視するようにしました。発生件数をグラフ化し、どの期間で増減があるかを追跡します。

flakyテストダッシュボード

さらに、flakyテストを防止するためのAI用のsteering（ガイドライン）を整備しました。
非同期処理では待機条件を明示する、外部リソースに依存しないようにする、状態を共有しない設計を徹底するなど、再発防止策を文書化しました。このsteeringは、AI修正支援を通して得られた知見をチーム全体に共有するための仕組みでもあります。

実際のsteeringファイルの内容の一部

まとめ

flakyテストは、CIの信頼性を損ない、チームの集中とスピード感を奪います。
まず現状を可視化し、AIの支援を受けながら原因を一つずつ取り除くことで、問題の構造が見えてきます。
ダッシュボードとsteeringを組み合わせることで、修正だけでなく「再発しない仕組み」を作ることができました。

flakyテストと向き合うことは、単なる不具合対応ではなく、開発環境の安定性を高め開発体験を向上するための継続的な改善活動だと考えています。
そして捉えにくい品質という謎のものに対して直接的でなくても、向上させていけるなら、向上させる可能性があるなら何でもやっていきたいですよね。