3月初旬に開催されたJaSST'18の参加レポートです。 [読了時間 8分]
JaSST Tokyo とは 国内最大級の ソフトウェアテスト シンポジウムです。
JaSST'18 Tokyo JaSST Tokyo の昨年と今年のベストスピーカ―賞の傾向（ 2017年 、 2018年 ）から、プロセス改善に注目が集まっている感もありますが、今回の JaSST'18 Tokyoの目玉はやはりなんといっても、 Google ジョン・ミッコ氏の Flaky Test だと思います。
以下では、ミッコ氏による２つのセッション
を取り上げて、今回参加できなかった方でも、 Google 社の先進的な取り組みについて概要を把握できるよう、ポイントを絞ってお伝えしたいと思います。（ブログに掲載することについては、ミッコ氏の許可を得ております。ありがとうございます！）
基調講演 セッション A1「Advances in Continuous Integration Testing at Google 」、基調講演者 チュートリアル G5「How to identify test flakiness in your test result data テスト結果からテストの不安定性(test flakiness) を読み解く」 講演資料 が公開されていますが、 語彙の事前知識や質疑できる場などがないとなかなか理解しにくい箇所もあると思います。 まず、趣旨（引用）とキーワードを簡単に整理した後に、セッションの要点をお伝えします。
趣旨 より効果的なテストのスケジューリングとは コストの削減方法 不安定な自動テストへの対処（Flaky Test） キーワード SETI (Software Engineer, Tools and Infrastructure) RTS (Regression Test Selection) Transition テスト結果がPASS→FAIL または FAIL→PASSへと状態遷移すること Edge テスト結果がPASS→FAIL または FAIL→PASSへと状態遷移したチェンジリストの断片 Greenish テスト成功（グリーン）のような状態 確信ではなく確率 Flaky Test 不安定なテストのこと テスト結果が非決定論的 同じコードリビジョン、同じ入力と設定、においてテストが成功したり失敗したりする 420万の独立したテスト 1日あたり1億5000万のテスト実行数 1万3000以上のチーム テスト実施の99%は成功する テスト結果がPASS→FAILに遷移したテストのうち、84%はFlaky テストの 1.23% だけがソフトウェアの欠陥を見つけている 変更頻度が多いファイルは欠陥が埋め込まれやすい 開発者が3人以上修正したソースは欠陥が埋め込まれやすい 言語によって欠陥の埋め込まれ度合いが異なる なんというか規模が桁違いですね！
テスト実行数を削減するため
テスト実行の99.8%は、テスト結果の遷移を引き起こさない テスト結果の遷移を引き起こすような0.2%のテスト実行だけで十分なことになる もし完璧な アルゴリズム があれば、すべてのテストを流し続ける必要はない Greenishという概念がなぜ必要か テストの量、実行回数ともに莫大で、全てを実行しきれないため
RTS だけでは問題が多い 依存関係グラフを元にした 回帰テスト 対象の選定（ RTS ）を行っても、コアモジュールへの些細な修正がほぼ全体に影響するため、一定期間の マイルストーン でのスケジューリングにおいて全テストを実行することになりがち マイルストーン 間は、プロジェクトの状態は決定的ではない（inconclusive） 全テストを実行することによる「グリーンの確信」に代わり、「グリーンの確率」を提供している
図1. Greenish 図1で、大きい緑●が「グリーンの確信」 図1で、モ スグリ ーン四角が「グリーンの確率」 チームにとってはリスクを持ってリリースすることになる 遷移を見つけるまでの時間を節約することを重視 しているようです。１日経てば「過去」であり内容を忘れている、と。
Flakyという概念がなぜ重要か テスト結果が成功から失敗に状態遷移したときでも、その84%が 誤報 であるため
システムの問題なのに、開発者にテストが不合格だったと通知がくることで調査する時間が無駄になる マシンリソースの 2～16%をFlaky Testのために消費している 全てグリーンでないとリリースしないため、リリースの妨げになる 無視すべきでないときもある 図2. Flaky 図2で、Flakesはテスト結果が非決定論的に成功したり失敗したりするFlaky Test Flakyなテストがあると、 テスト失敗が常に欠陥を意味するとは限らなくなってしまう のです。狼少年のような存在ですね。
Flaky Testへの対処 Flaky Testを検出することで、開発者にはテスト結果に添えて「Flakyである」という旨も一緒に伝えることで、調査コストを抑える
Flakyさは不可避（Inevitable）との見解 Flakyさを除去するのと同程度には新たなFlakyさが埋め込まれる Flaky なテストを単に無視したり削除するという考え方について、休憩時間にミッコ氏に直接尋ねることができました。不安定なテストはまだバグを捕まえるために価値があるので無視したり削除したりしてはならない（意訳）とのことでした。
Flaky Testの検出方法 テスト結果（PASS/FAILのバイナリ値のみ！）を残すだけで、Flaky Testへの洞察が得られるそうです。 特殊な操作は必要なく、単純なクエリで推定できるところがポイントです。
Google では テスト結果を2年間記録を残し続けている PASS/FAILのバイナリ値のみ Google では *unit.xml ファイルは残していない（が残しても構わない） テスト結果の遷移であるTransitionやEdgeに着目して、経験則を育てている 図3. Edge 履歴を共有（同じタイミングで成功・失敗すること）する他のテストの数が多い場合はFlakyではない テスト結果の遷移が多いテストは、Flakyと判断できる 例えば、1日に30回もテスト結果が遷移するテストがあった場合に、開発者がそれほど頻繁に直したり壊したりをしたとは到底考えられない チュートリアル で Flaky Test の検出を実際に Google BigQuery を使って行いましたが、とても簡単でした。
感想
自動テストへの長年の取り組みの成果として、もし自動テストを全て流せるなら「確信（100% Confident）」があるという土壌があった上で、 テスト実行の運用をいかに効果的に行うか？ という次元のお話でした。 確信（100% Confident）に代わる何かが必要な状況で、 ビッグデータ 解析を活用するところがグーグルらしいですね。 クロージングパネルでも話されていた「アメリカでは大企業、中堅企業において自動テストは既に当たり前であり、より効果的な運用についてその興味が移っている」といった言説が印象的でした。
/assets/images/13591618/original/8ae0fb88-7dbe-4a0e-8a4c-8bae31320ae2?1686812597)
/assets/images/3039984/original/a0a33bf9-4e97-45f6-b2c6-9591063a1269.gif?1534903761)
/assets/images/13591618/original/8ae0fb88-7dbe-4a0e-8a4c-8bae31320ae2?1686812597){kind=avatar}
