はじめに
Commune Developers Advent Calendar 2025 シリーズ2 の19日目の記事です。
こんにちは、コミューン株式会社でQAエンジニアを担当しています、KOYOです。
皆さんは、自動テスト実装時にはすべてのアサーションは通ったのに、定期実行で失敗するテストケースに出会ったことはありませんか？
今回は、メンテナンス時の疑問を経て、より安定したテストにするには本質的な裏側の理解が必要だと感じたことについて書きます。
前提
現在、私のチームでは今年から「MagicPod」を導入してテスト自動化を進めています。基本的な実装フローは以下の通りです。
- 私がテストケースを実装する
- 上司にレビューを依頼する
- 指摘事項を修正する
- 定期実行に載せる
- 失敗したら原因を分析・修正する
課題
- 失敗したら原因を分析・修正する
失敗したケースを確認すると、「期待するUI要素が表示される前にアサーションが走る」ことがほとんどでした。
ですので、UI要素が表示されるまで待機させればいいのだと考え、「待機ステップ」を追加する修正をしました。これにより安定的にテストは成功するようにはなったのですが、ある疑問が生まれます。
- なぜ実装時には問題なく成功したの？
- どの待機ステップが適しているの？
私は答えを見つける旅に再び出かけたのでした。
前回の旅路はこちら
発見
道中あらゆる文献を読み漁りました。が、どの道を辿ろうと結局はJSTQB Foundation Levelシラバス（Version 2023V4.0.J02）[1]に落ち着きました。
答え合わせ
疑問１
- なぜ実装時には問題なく成功したの？
この失敗の原因は、アプリケーションのバグではなく、「環境条件による故障」に分類されそうです。実装時に該当テストのみ実行させて挙動を確認した場合と、並列実行を設定した定期実行した場合とでは、マシンスペック、ネットワーク速度、実行時のリソース利用状況が全く異なります。
JSTQB FLシラバス（1.2.3 エラー、欠陥、および故障）にも、故障はコード内の欠陥だけでなく、環境条件によって起きることもあると示唆されています。クラウド環境という特定の「環境条件」が、テストの失敗を引き起こしていたと考えられます。
人間なら画面が重くても「ちょっと待とう」と判断できますが、自動テストはプログラムされた速度で容赦なく進みます。この「環境の揺らぎ」を吸収する「待機ステップ」が欠けていたことが、不安定なテストの根本原因と言えるでしょう。
疑問2
- どの待機ステップが適しているの？
待機ステップが必要なのはわかりました。でも、コマンド一覧を見ると「待機」と名のつくものがたくさんあるのです、、、。
（心の声） 「どれを選んでも『止まって待つ』のは同じでしょ？」
しかし、調べていくうちに、これこそがテストを壊す原因だと気づかされたのです。
1. n秒間待つ
仕組み： 単にテスト実行を指定された秒数間、強制的に停止する
評価： ⭐️
いわゆる「静的待機（Static Wait）」です。画面の状態を見ないため、例えば「通信が早く終わっても指定時間は絶対に待つ」という無駄が発生します。逆に、通信が指定時間を1秒でも超えるとエラーになるため「環境の揺らぎ」に非常に弱く、テストが壊れる大きな原因となります。
2. 画面全体の描画が終わるまで待つ
仕組み： HTMLの解析、DOM構築、および一定時間の画面変化停止を検知する
評価： ⭐️
「変化が止まるまで待つ」という仕様上、ローディングが長いページや動き続ける要素があるページでは、不必要に待ちすぎ可能性があります。「画面全体」というマクロな視点での待機は、特定のボタンを操作したいだけの時には非効率になりがちです。
MagicPod社のドキュメントでも待機ステップについて言及があります。
画面全体の描画が終わるまで待つコマンドは、画面に一定時間変化がないことを基準として、描画の完了を検知します。
そのため、以下のように画面が継続的に変化するWebページでは、描画完了を正しく検知できない可能性があるため、本コマンドは非推奨です。
・動画が埋め込まれているページ
・数秒おきにバナー画像が切り替わるページ など
3. UI要素が存在するまで待つ
仕組み： 対象のUI要素がDOM上に現れるのを待つ
評価： ⭐️⭐️
「DOMの中にその要素が現れたか」のみをチェックします。しかし「DOMには存在するが、まだ透明（opacity:0）だったり、他の要素に隠れていてクリックできない」という状態が頻繁に起こります。「あるはずなのに押せない」というエラーを招く一因です。
UI要素が存在するまで待つコマンドは、対象のUI要素がUIツリー上に存在していること（UI要素が存在しなくなるまで待つコマンドについては存在していないこと）を検出できるまで待機します。このとき、対象の要素が表示されているかどうかは検出判定に影響しません。
4. UI要素が表示されるまで待つ
仕組み： 要素がDOMツリーに存在し、かつ人間の目に見える（操作可能）状態になるまで待つ
評価： ⭐️⭐️⭐️
Selenium等の内部ロジックで言う「Explicit Wait（明示的待機）」に相当します。存在だけでなく「人間の目に見えるか」までを確認するため、操作ミスのリスクが最も低い最強の待機方法です。条件を満たした瞬間に次へ進むため、実行時間の最適化と安定性を両立できます。
UI要素が表示されるまで待つコマンドは、対象のUI要素が表示されているかどうかを検出できるまで待機します。このため、対象のUI要素がUIツリー上に存在していても、以下のような非表示状態である場合は検出されません。
・display: none;
・visibility: hidden;
・opacity: 0;
反対に、UI要素が表示しなくなるまで待つコマンドについては上記のような非表示状態である場合に検出されます。
このため、基本的には「UI要素が表示されるまで待つ」コマンドの方が、UI要素が表示状態になるまで正確に待機してくれることから、より安定しており、推奨されます。
結論
今回の「答え合わせ」を通じて得た結論は一つです。
「ノーコードツールといえども、裏側のロジックを理解して実装するべき」
MagicPodの「待機ステップ」という一行には、緻密な条件待機ロジックが詰まっていました。裏側を理解して実装することで得られる2つの武器があります。
- 安定性:
「環境の揺らぎ」という敵の正体を知ることで、場当たり的な待機ステップを卒業し、長期間壊れないテストを設計できます。 - 効率性:
ロジックを正しく選べば、テストは「最短かつ確実」に終わります。これは開発サイクルを加速させる大きな貢献です。
おわりに
いかがだったでしょうか？
今まで「とりあえず待機すればいいんだ」と思っていましたが、 今では目的を持ってコマンドを選択できています。ツールのおかげで、実装する「速度」は以前より格段に速くなったかもしれません。しかし、肝心なロジックの理解が疎かなままでは、長期的に安定したテストは望めません。
今回取り上げた「待機ステップ」に限らず、裏側ではどんな処理がされているのか覗いてみると、より質の高いテストが書けるかもしれません。
-
「JSTQB認定テスト技術者資格 Foundation Level」の略称で、ソフトウェアテストに関する入門レベルの基礎知識を問う国際的な資格試験です。
シラバスはこちら：https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf ↩︎
Discussion