日本語MagicPod Autopilotにテストスメルを教えて自動テストをレビューさせてみた
こんにちは。MagicPodでエバンジェリストをしているYoshiki Itoです。
今回はMagicPod Advent Calendar 2025 - Adventarの3日目の記事として、MagicPod Autopilotの活用例紹介＆テストスメルについての回です。
テストスメルって何？
テストスメル（Test Smell）とは、もともと単体テストを主な対象としたことばで、大まかに言うと「テストの設計や実装としてダメな状態のものの特徴をまとめたもの」です。アンチパターン集、のほうがイメージがつきやすいかもしれません。
詳しくはSoftware Unit Test Smellsという名称そのままのサイトなどがありますので、こちらを見てみてください。
一般に「テストスメル」と言うと、単体テストコードに対するものを指す場合がほとんどです。しかし、GUIを操作して行うようなインタラクティブなテストのテストスメルに関する論文もあります。
Smells in System User Interactive Tests
この論文中では、GUI操作を伴うテストをSystem User Interactive Tests(SUIT)と表現しています。このSUITのテストスメルに関して、学術面や各種ブログ等のアウトプットを調査しています。
詳細は読んでいただくとして、本論文中で書かれているようなテストスメルを自動で検知して「直したほうがいいよ！」と指摘してくれたら嬉しいですよね。
ということでMagicPod Autopilotを使って自動テストの保守性を損なっている部分を指摘してもらいましょう。
Autopilotに、テストの保守性を損なうステップを指摘してもらう
前準備として、論文中からテストスメルを抜き出してきます。本来は35個のテストスメルが挙げられているのですが、自動で検出できるかどうか、MagicPodでの自動テストに関係するかどうかを考慮して、今回は以下の11に絞りました。また簡単な対策も併記しています。
| No. | テストスメルの名称 | 概要 (Description) | 対策 |
|---|---|---|---|
| 1 | Army of Clones (AoC) - クローンの群れ | 異なるテストが類似した操作や実装を行い、テストコードの重複が発生している状態です。これによりメンテナンスの労力が増加します。 | 共通する処理は共有ステップにまとめて、呼び出す |
| 2 | Conditional Assertions (CA) - 条件付きアサーション | テストが、実行ごとに変化する可能性のある環境に依存して、異なるプロパティを検証している状態です。 | AIで確認コマンドを使う |
| 3 | Hardcoded Environment (HE) - ハードコードされた環境 | 異なるテスト環境で実行する必要があるにもかかわらず、テストが環境設定（例：ブラウザ設定）をハードコードされた参照として含んでいます。 | 変数等を用いて、ハードコードをやめる |
| 4 | Long Test Steps (LTS) - 長いテストステップ | 1つまたは複数のテストステップが非常に長く、SUTに対して多数のアクションを実行しています。これによりテストが脆弱になります。 | 適切なステップ数に分割する |
| 5 | Missing Assertion (MA) - アサーションの欠如 | テストが明示的なアサーションを欠いています。将来の読者がテストの意図を理解するのに苦労します。 | 適切なアサーションを使用する |
| 6 | Noisy Logging (NL) - 騒がしいロギング | テストがフィクスチャの状態をログに出力しています。出力にノイズが多くなり、テストの分析が煩雑になります。 | ログを減らす |
| 7 | Obscure Test (OT) - 曖昧なテスト (Hardcoded Values) | テストの振る舞いが理解しにくい。特に、変数を介さずにハードコードされた値が過剰に使用されている場合に焦点を当てています。 | 変数や共有ステップを適切に使用する |
| 8 | On the Fly (OtF) - その場での計算 | テストが事前に計算された値ではなく、実行中に期待される結果を計算しています。アサーションにビジネスルールが埋め込まれます。 | 事前に計算された値を使用する |
| 9 | Over-Checking (OC) - 過剰なチェック | テストがそのスコープにとって関連性のない多数のアサーションを実行しています。アサーションとSUTへのアクションの比率が高いです。 | E2Eテストに適した粒度のアサーションに変更する |
| 10 | Sensitive Locators (SL) - 脆弱なロケーター | テストがUI要素を識別するために、長いチェーンを持つ複雑なロケーター（例：複雑なXPath、CSSセレクター）を使用しています。UIのわずかな変更でテストが壊れやすくなります。 | 壊れにくいロケータを用いる |
| 11 | Stinky Synchronization (SS) - 臭い同期 | テストがSUTとの適切な同期ポイントを使用しておらず、明示的で固定された待機時間（例：Sleep）を使用しています。 | 固定時間の待機ではなく、特定の処理や画面表示を待つように変更する |
テスト対象はおなじみHOTEL PLANISPHERE - テスト自動化練習サイトです。
MagicPodで特別な工夫をせずに自動テストを作ったうえで、一部の要素のロケータをxpathにするなどあえて悪いほうに変更をしてみました。
MagicPod Autopilotだけでレビュー
まずは特別な指定をせず、Autopilotに単純に「テストが不安定になりそうなステップの作り方があったら指摘して」と依頼してみましょう。
プロンプト
既存のテストステップの内容を精査し、テストが不安定になりそうなステップやテストの保守性が低下する原因となっているステップがあればリストアップし、
それぞれに対する改善案を提示してほしいです。
修正自体はまだ行わなず、改善案を次回このプロンプトに貼り付け可能な形のテキストとして出力してください。
特別な指定は行わず、単純に問題点のリストアップをしてもらいました。 一度に修正まで行ってしまうと、期待と異なる変更がなされる恐れがあります。そうした事態を避けるため、まずは修正点を挙げるだけにとどめています。
Autopilotによる応答
指示に対する応答は以下の通りです。
## テストの不安定性・保守性に関する問題点と改善案
### 【問題1】ステップ5: 固定された日付の使用
**該当ステップ:** ステップ5 - 「宿泊日」入力エリアに「2025/12/05」を入力
**問題点:**
- 固定日付を使用しているため、過去の日付になると予約できなくなり、テストが失敗する可能性が高い
- テストの実行タイミングによって結果が変わる不安定なテストになっている
**改善案:**
date_calculationコマンドを使用して、現在日付から相対的に未来の日付を計算して変数に格納し、その変数を使用する。例えば「今日から30日後」のような指定にすることで、いつ実行しても有効な日付を入力できる。
---
### 【問題2】ステップ12: 期待値と実際の表示が不一致
**該当ステップ:** ステップ12 - 7,000円の要素に対して8,000円をアサート
**問題点:**
- UI要素名が「7,000円」なのに期待値が「8,000円」となっており、明らかに不一致
- このステップは常に失敗するか、または意図しない要素を検証している可能性がある
- テストの信頼性を著しく低下させる
**改善案:**
正しい期待値を確認し、朝食バイキング込みの正しい合計金額（おそらく8,000円）をアサートするように修正する。また、UI要素の再キャプチャを行い、正しい金額表示の要素を特定する必要がある。
---
### 【問題3】ステップ14: 期待値と実際の表示が不一致
**該当ステップ:** ステップ14 - 「合計7,000円(税込み)」の要素に対して「合計 8,000円（税込み）」をアサート
**問題点:**
- ステップ12と同様、UI要素名と期待値が不一致
- 確認画面での金額検証が正しく機能していない可能性が高い
**改善案:**
正しい金額表示の要素をキャプチャし直し、期待値を正確に設定する。朝食バイキングを含めた正しい合計金額を検証できるようにする。
---
### 【問題4】ステップ15: クリックすべきでない要素をクリック
**該当ステップ:** ステップ15 - 「2025年12月2日 〜 2025年12月3日 1泊」をクリック
**問題点:**
- 日付の表示要素をクリックしているが、この要素はクリック可能な要素ではない可能性が高い
- しかもステップ5で入力した日付（12/5）と表示されている日付（12/2-12/3）が異なっており、データの整合性が取れていない
- 不要なクリック操作がテストの不安定性を招く
**改善案:**
このステップを削除する。日付の確認が必要であれば、assert_contains_valueなどで表示内容を検証するに留める。また、日付の不一致も解消する必要がある。
---
### 【問題5】全体: コメントや区切りがなく可読性が低い
**該当箇所:** テストケース全体
**問題点:**
- 17ステップが連続して並んでおり、どこからどこまでがどの処理なのか分かりにくい
- 保守する際に該当箇所を見つけにくく、変更の影響範囲も把握しづらい
**改善案:**
commentコマンドやblank_lineコマンドを使用して、テストを論理的なセクションに分割する。例えば:
- トップページからプラン選択まで
- 予約情報の入力
- 金額の確認
- 予約確認画面での検証
- 予約完了
---
### 【問題6】ステップ6: カレンダーUIの閉じる操作
**該当ステップ:** ステップ6 - 「閉じる」ボタンをクリック
**問題点:**
- カレンダーUIが表示されている前提で閉じるボタンをクリックしているが、環境やタイミングによってはカレンダーが自動的に閉じている可能性がある
- その場合、要素が見つからずテストが失敗する
**改善案:**
if_existsコマンドで「閉じる」ボタンの存在を確認してから、存在する場合のみクリックするように条件分岐を追加する。これにより、カレンダーが既に閉じている場合でもテストが継続できる。
---
### 【優先度の高い改善項目まとめ】
1. **最優先:** 問題2と問題3の金額アサートの修正（テストが正しく機能していない）
2. **高優先:** 問題1の固定日付の修正（テストの寿命に直結）
3. **中優先:** 問題4の不要なクリック操作の削除
4. **中優先:** 問題6のカレンダー閉じる処理の条件分岐化
5. **低優先:** 問題5のコメント追加による可読性向上
---
以上の改善案をご確認ください。修正を進める場合は、このテキストを次回のプロンプトに貼り付けていただければ、具体的な修正作業を行います。
5点挙げてくれました。おおむね指摘の内容は正しいように見えます。 カレンダーUIの閉じる操作、については意見がわかれるところかもしれません。 環境やタイミングによっては閉じているかも、という指摘がなされていますが、ここはテスト対象の挙動が変わることは考えにくいので、私だったら閉じるボタンの操作はそのままにすると思います。（閉じる操作に失敗してテスト結果も失敗になるのであれば変化に気づけますし。）
テストスメルありの場合
プロンプト
テストスメル情報なしの場合に加えて、前述のテストスメル表をもとに箇条書きの形で情報を与えました。
既存のテストステップの内容を精査し、テストが不安定になりそうなステップやテストの保守性が低下する原因となっているステップがあればリストアップし、
それぞれに対する改善案を提示してほしいです。
リストアップにあたって、下部に記載した「テストスメル一覧」を参考にしてください。
修正自体はまだ行わなず、改善案を次回このプロンプトに貼り付け可能な形のテキストとして出力してください。
## テストスメル一覧
- **Army of Clones (AoC) - クローンの群れ**
- 異なるテストが類似した操作や実装を行い、テストコードの重複が発生している状態です。これによりメンテナンスの労力が増加します。
- 共通する処理は共有ステップにまとめて、呼び出す
- **Conditional Assertions (CA) - 条件付きアサーション**
- テストが、実行ごとに変化する可能性のある環境に依存して、異なるプロパティを検証している状態です。
- AIで確認コマンドを使う
- **Hardcoded Environment (HE) - ハードコードされた環境**
- 異なるテスト環境で実行する必要があるにもかかわらず、テストが環境設定（例：ブラウザ設定）をハードコードされた参照として含んでいます。
- 変数等を用いて、ハードコードをやめる
- **Long Test Steps (LTS) - 長いテストステップ**
- 1つまたは複数のテストステップが非常に長く、SUTに対して多数のアクションを実行しています。これによりテストが脆弱になります。
- 適切なステップ数に分割する
- **Missing Assertion (MA) - アサーションの欠如**
- テストが明示的なアサーションを欠いています。将来の読者がテストの意図を理解するのに苦労します。
- 適切なアサーションを使用する
- **Noisy Logging (NL) - 騒がしいロギング**
- テストがフィクスチャの状態をログに出力しています。出力にノイズが多くなり、テストの分析が煩雑になります。
- ログを減らす
- **Obscure Test (OT) - 曖昧なテスト (Hardcoded Values)**
- テストの振る舞いが理解しにくい。特に、変数を介さずにハードコードされた値が過剰に使用されている場合に焦点を当てています。
- 変数や共有ステップを適切に使用する
- **On the Fly (OtF) - その場での計算**
- テストが事前に計算された値ではなく、実行中に期待される結果を計算しています。アサーションにビジネスルールが埋め込まれます。
- 事前に計算された値を使用する
- **Over-Checking (OC) - 過剰なチェック**
- テストがそのスコープにとって関連性のない多数のアサーションを実行しています。アサーションとSUTへのアクションの比率が高いです。
- E2Eテストに適した粒度のアサーションに変更する
- **Sensitive Locators (SL) - 脆弱なロケーター**
- テストがUI要素を識別するために、長いチェーンを持つ複雑なロケーター（例：複雑なXPath、CSSセレクター）を使用しています。UIのわずかな変更でテストが壊れやすくなります。
- 壊れにくいロケータを用いる
- **Stinky Synchronization (SS) - 臭い同期**
- テストがSUTとの適切な同期ポイントを使用しておらず、明示的で固定された待機時間（例：Sleep）を使用しています。
- 固定時間の待機ではなく、特定の処理や画面表示を待つように変更する
Autopilotからの応答
以下のようなレビューをしてくれました。
## テストスメル分析結果
### 1. **Hardcoded Environment (HE) - ハードコードされた環境**
**該当ステップ:**
- ステップ1: URLのハードコード
- ステップ5: 宿泊日「2025/12/05」のハードコード
- ステップ12: 金額「8,000円」のハードコード
- ステップ14: 金額「合計 8,000円(税込み)」のハードコード
**問題点:**
URLや日付、金額が直接コードに埋め込まれており、環境変更や時間経過により柔軟な対応ができません。
**改善案:**
- URLは共有変数または変数として定義
- 宿泊日は「日付計算」コマンドを使用して現在日から相対的に設定(例:今日+30日)
- 金額は変数として定義し、計算や確認に使用
---
### 2. **Stinky Synchronization (SS) - 臭い同期**
**該当ステップ:**
- ステップ6: カレンダーの「閉じる」ボタンをクリック
**問題点:**
カレンダーポップアップが表示されるタイミングが不安定な場合、このステップが失敗する可能性があります。MagicPodは自動待機しますが、カレンダーのアニメーション等により不安定になることがあります。
**改善案:**
- 「if_visible」コマンドで条件分岐を追加し、「閉じる」ボタンが表示されている場合のみクリック
- または「wait_visible」コマンドで明示的にボタンの表示を待機
---
### 3. **Obscure Test (OT) - 曖昧なテスト**
**該当ステップ:**
- ステップ5〜11: 各入力値がハードコードされており、テストの意図が不明瞭
**問題点:**
「2025/12/05」「1泊」「1人」「テスト太郎」などの値が直接入力されており、なぜその値なのかが不明です。
**改善案:**
- 各入力値を変数として定義し、変数名で意図を明確化
- 例: checkInDate, numberOfNights, numberOfGuests, guestName
- テストの冒頭にコメントでテストシナリオを記載
---
### 4. **Over-Checking (OC) - 過剰なチェック / Missing Assertion (MA) - アサーションの欠如**
**該当ステップ:**
- ステップ12: 金額確認が入力フェーズで実施
- ステップ14: 確認画面での日付クリック(ステップ15)の意図が不明
**問題点:**
- 入力中の金額確認(ステップ12)は不要な可能性があります
- 確認画面の日付をクリックする操作(ステップ15)の目的が不明で、不要なアクションの可能性
- 予約完了までの間に、入力内容の確認アサーションが不足
**改善案:**
- 入力フェーズの金額確認は削除し、確認画面でまとめて検証
- 日付クリック(ステップ15)が不要であれば削除
- 確認画面で以下を検証:
- 宿泊日、宿泊数、人数
- オプション(朝食バイキング)
- 氏名
- 合計金額
---
### 5. **Long Test Steps (LTS) - 長いテストステップ**
**該当ステップ:**
- テスト全体(17ステップ)
**問題点:**
1つのテストケースに予約フローの全工程が含まれており、どこで失敗したのか分かりにくい状態です。
**改善案:**
以下のように論理的なセクションに分割し、コメントで明示:
1. トップページからプラン選択まで(ステップ1〜4)
2. 予約情報入力(ステップ5〜11)
3. 入力内容確認(ステップ12〜14)
4. 予約完了確認(ステップ15〜17)
各セクションの冒頭に「comment」コマンドでセクション名を追加
---
### 6. **Sensitive Locators (SL) - 脆弱なロケーター**
**該当ステップ:**
- ステップ12: 金額表示「7,000円」(UI要素名のみ)
- ステップ14: 「合計7,000円(税込み)」(UI要素名と検証値の不一致)
**問題点:**
UI要素名「7,000円」と検証値「8,000円」が一致しておらず、混乱を招きます。また、金額のような動的な値をUI要素名にすると、価格変更時にロケーターが壊れる可能性があります。
**改善案:**
- UI要素名をより汎用的な名前に変更
- 例: 「合計金額表示エリア」「料金詳細テキスト」
- 金額部分の検証には、部分一致(contains)を使用することも検討
---
## 改善提案サマリー(優先順位順)
**高優先度:**
1. 日付のハードコードを「日付計算」コマンドで動的生成に変更
2. 不要なステップ15(日付クリック)の削除または意図の明確化
3. UI要素名の改善(金額表示エリアなど)
4. 条件分岐でカレンダー閉じるボタンの処理を安定化
**中優先度:**
5. 入力値を変数化して可読性向上
6. セクションごとにコメントを追加して構造を明確化
7. 確認画面でのアサーション追加(宿泊日、人数、氏名など)
**低優先度:**
8. URLの共有変数化
9. 金額の変数化と計算ロジックの整理
---
このテキストを次回のプロンプトにコピー&ペーストして、具体的な修正指示をいただければ、順次対応させていただきます。どの改善案から着手されたいかお知らせください。
テストスメルに関する情報がなかったときと比べて、指摘の件数自体は増えています。また指摘の内容自体も粒度が細かくなっているように見えるので、テストスメルに関する情報を与えたことによる変化は見て取れます。
一方で、有効な指摘が大きく増えたかというと必ずしもそうではないようです。たとえば「長いテストステップ」などは、17ステップという長さはMagicPodでE2Eテストを行ううえで決して長いとは言えず、過剰な指摘になっています。
まとめ
今回簡単なサンプルで比較してみました。テストスメルに関する情報をMagicPod Autopilotに渡してレビューをさせることは一定有効そうにも見えます。しかし、クリティカルでない指摘が増える可能性もあります。
もし自動テスト作成時のプロセスの中にAutopilotによるレビューを組み込むという場合は、テストスメルに限らず自組織における重要なポイントを渡すなど、状況にあわせたプロンプトの作成を行うことが必須になりそうです。
一方、追加の情報がない場合でも「保守性が低くなりそうな点を指摘して」と指示するだけでMagicPod Autopilotが指摘項目を挙げてくれます。個人的にはひとまずシンプルな指示でレビューをさせて、自動テストの質を高めていただくのがオススメです。
特に月末等でAIクレジットが余っている、というときには既存のテストをレビューさせて、指摘事項に対応してみてはいかがでしょうか。
