テスト自動化が運用フェーズに入ってある程度時間が経つと、テスト自動化の環境や結果が不安定になるという経験があるのではないでしょうか？
不安定になる事象として以下のようなことが挙げられます。
- プロダクトのソースコードなどは変更を加えていない。しかし、なぜかテストの結果が成功と失敗を交互に繰り返す。
- テストはずっと成功を続けている。しかし、なぜかテスト実行時間が徐々に長くなってきて、テスト全体の時間がかかるようになってきている。
- テスト実行時に、作成したはずのテストデータがなくなっており、そのステップでテスト失敗してしまう。
- パソコンやスマートフォンの不意なポップアップなどでテストが妨害されてしまう。
このような不安定な状態が恒常的に発生すると、運用する人にとっては、たまったものではありません。プロダクトの品質は問題が起きていないのに、運用者にとってつまらない調査工数ばかりが増えてしまいます。
そこで、第３回である今回は、テスト実行が不安定になる事例とそれを取り除く運用について解説します。
- もくじ
1．ソースコードを変更していないのにテスト結果が不安定（＝Flaky Test）
プロダクトのソースコードを変更していません。テスト自動化を何回か実行すると、成功と失敗の結果を出すことがあります。
これをテスト結果が不安定といいます。(Flaky Test ※）
※ 出典：「Advances in Continuous Integration Testing at Google」JaSSTソフトウェアテストシンポジウム-JaSST'18 Tokyo-セッション概要
下図に３種類のテストケースを８回実行したものになります。
テストケースAはすべて成功しています。問題ありません。
テストケースCは３回目以降すべて失敗しています。２回目と３回目の間に不具合が混入したのでしょう。プロダクトに問題はありますが、テスト自動化のスクリプトとしては安定しています。
テストケースBは成功と失敗が交互に発生しています。これはなんらかの不安定な状態で、正常にテストできないことが起きていると考えられます。これをFlaky Test（フレーキーテスト）といいます。
このFlaky Testは、テストを実行するたびに結果が変わるため、プロダクトに不具合があるのか判断できません。またこの原因特定するための調査工数もかかってしまいます。
そのため、このようなFlaky Testを減らすことが、テスト自動化の運用改善につながります。
Flaky Testのいくつかの原因と改善策を順番に解説します。
1-1 タイミング問題
まず考えられる原因として、タイミングの問題があります。例えば画面表示後、JavaScriptでAPIをCALLしてデータを取得し、一部のUIを非同期で作成したとします。
この非同期の時間が実行毎にまちまちで、場合によって数秒待たされることで、テスト自動化は要素がないと判断して失敗してしまう可能性があります。
数秒待たされる例として、検索結果のレイアウトは表示されているが、検索結果の詳細が読み込み中で表示されていない状態の場合です。
また、各種ボタンなどは表示されているが、Loadingのモーダルがoverlapされていて、どのボタンもクリックできないケースもあります。モーダルが消えるまで処理を進めることができません。
このような、タイミングの問題が、Flaky Testを引き起こします。
タイミングの問題に対して、簡単な改善方法はwaitをいれることです。
ただ、waitをどれだけ入れればいいのか不明確なまま、長くwaitをいれると、その分テスト自動化の実行時間が長くなってしまうため、望ましくありません。
上記の例では、Loadingの表示が消えるまで待つ処理を入れれば、改善します。このように、wait以外で改善する方法を探すのが良いですが、どうしても難しい場合はwaitも選択肢ではあります。
