こちらは、ソフトウェアテストAdvent Calendar 2020の7日目です。 qiita.com
12/6は binnmtiさんの「自分のサービスにモブプログラミングでリグレッションテストを導入している話」でした。
12/5にソフトウェアテスト自動化エンジニアカンファレンスで 「E2Eテストのflakyと向き合う」というタイトルで発表させていただきました。 testautomationresearch.connpass.com
当日のスライド
当日の動画
登壇動画はYoutubeのテスト自動化研究会のチャンネルで公開されるそうなので、公開されたらコチラに掲載します。 昨年の動画もかなり充実していますので、初めて知った方はぜひ見てみることをオススメします。
テスト自動化におけるflakyとは
発表ポイントのまとめ
1. flakyは「不安定なテスト結果」のことで、テストケースに書いていない場所で起きている可能性がある
通常、自動テストがFailする原因は1. テストコードやテストデータが誤っている場合、と、2. テスト対象が誤っている（＝不具合）に分けられます。
しかしながら、E2Eテストの場合、例えば、画面の表示が遅れてくるせいで表示されないなどの原因によってFailしてしまうことがあります。
2. flakyが起きたら、放っておくと時間を浪費したり、不具合の徴候を見逃してしまう可能性があるよ
テスト実行という観点においては、テストをリトライすれば、リトライした回数だけ余計に実行時間がかかります。また、Failするごとに原因を確認することに依る時間もかかることでしょう。
さらに危険なのは不安定になることに慣れてしまって、手動テストであれば違和感として気づけるかもしれないシステムの問題の徴候を見逃すことになることがあることを理解しましょう。
3.flakyやテスト自動化全体を学びたい 初心者にオススメの書籍
テスト自動化を理解する上で基本の考え方である「テストピラミッド」について、とてもわかり易く説明しています。
また、flakyについても以下の章を割いて説明されています。個人的には日本語の入手可能な初心者向け書籍では断トツでオススメです。
- 8.6 不安定なテストの扱い方
- 8.6.1 テストを書き直す
- 8.6.2 テストをピラミッドの下の層へ移動させる
- 8.6.3 価値のないテストとみなし、テストを止める
発表で触れなかったけど言っておきたいこと、もう少し伝えたかったこと
1. 不安定性はゼロにはならないということ
flakyゼロ を目指して戦い続けると、チームとして疲弊してします。それは、ユーザのニーズや仕様が状況や時間経過によって変わっていくことによる影響を常に受け続けるシステムをテストしているという自動テストにおける宿命のようなものでしょう。
いわゆるユニットテストのカバレッジを50%から80%に上げるのと、80%から90%に上げるための労力は同じくらいかかるといった類の話と同等だと思います。
なので、重要度、緊急度を見極めた上で、優先度を見極めて行くほうが持続的な運用としては持続可能性は高いと思います。 80点あたりを目指していくのがベストかと経験的に思います。
2. flakyを予知することは難しい、プロトタイプを作って早くPDCAを回そう
プレゼンテーションでも述べたとおりいくつかの手がかりはあるものの、事前にどの辺が不安定になるかを完全に見極めるのは極めて難しいです。
そこで、テストケース1つで良いのでまず作って、毎日流してみることをオススメします。あなたのプロダクト（サービス）で動くものをベースに実際に確認することで、リスクの見極めやFailを通じて、どう手を打っていくかを見出していくのが何よりのグッドプラクティスになることでしょう。
3. テスト自動化が開発プロセスを整えるきっかけになるかもしれない
発表では、Flakyを事前に防ぐための取り組みとして、仕様を事前に確認しておくことや、テストアーキテクチャ自体を見直しましょうという話をしました。
E2Eテストがflakyになってしまう根本原因として、そもそもAPIテストやパフォーマンステストが不足しているプロジェクトをいくつも見てきました。
それでは、不足していることを悪だとみなしてE2Eテストまで捨ててしまうことが正解なのでしょうか。
(すべてのプロジェクトでできるとは思いませんが)不足しているのであれば、補完する取り組みをそこから始めていけば、学びを活かし、ひいては品質向上に繋がると考えています。
ということをルンバという例えで、非常にわかりやすく説明しているスライドがあるのでぜひ読んでみてください。
次回予告？
とある参加者の方😺から、こちらの論文を紹介していただいたので読んでみようと思います。
Modeling and ranking flaky tests at Apple
Abstructしか読んでいませんが、TestのFlakiness（不安定度）をランク付け可能な値と捉えて、信頼度をアサインして、モデルを構築して評価しました、という話だそうです。 誤検出に依る欠損が1%未満で、44%のFlakinessを削減できたとのことなのでこれは凄い。
おまけ
本発表では、どうやらテスト自動化経験者の皆様のあるあるを引き当てたらしいということを申し添えます。 （事例紹介を行った際の当日のDiscordチャット）
