[MagicPod] 指摘を減らす旅に出た私はJSTQB TAEシラバスにたどり着いた。

はじめに

Commune Developers Advent Calendar 2025 シリーズ2 の4日目の記事です。
こんにちは、コミューン株式会社でQAエンジニアを担当しています、KOYOです。

皆さんは、自動テストのコードレビューで「動いているのになぜ修正が必要なの？」と疑問に思ったことはありませんか？
今回は、私がレビューを受けて感じていたモヤモヤと、ある「答え」に出会って視界が開けた体験について書きたいと思います。

前提

現在、私のチームでは今年から「MagicPod」を導入してテスト自動化を進めています。基本的な実装フローは以下の通りです。

1. 私がテストケースを実装する
2. 上司にレビューを依頼する
3. 指摘事項を修正する
4. 定期実行に載せる

課題

上司にフィードバックをいただきながら作成する過程は順調に見えます。一方で、私は下記のような漠然とした不安を抱えるようになりました。

1. 属人化への懸念
   品質が「上司のレビュー」に完全に依存してしまっている。もし上司が異動や退職をしたら、私はこの品質を維持できるのだろうか？

2. 成長の限界
   指摘された箇所を直しながら補う形式になっており、いつになったら上司の知識・経験を上回れるのだろうか？

3. 手戻りコストの高さ
   レビューを受けて都度修正するよりも、最初から正解を知れた方がコストも減らせるのでは？

指摘内容

今回、実際に私が指摘を受けた5点を恥を忍んで公開します。
当時は「動けばいいのでは？」と思うこともありました。

1. 上司「画面遷移しないことの確認のために『画面全体描画まで待機』を追加した方がいい」

視点	状況
背景	ある条件下ではリンクが非活性になり、画面遷移しなくなることを確認したい
当時の実装	リンクをクリックした後、URLが変わっていないことだけをチェックしていた
私の心の声	「遷移しないことを確認するだけなら、URL確認だけで問題ないのでは？」

2. 上司「不要なステップは削除した方がいい」

視点	状況
背景	テスト作成時の試行錯誤の跡や、念のための確認ステップが残っていた
当時の実装	必須ではないアサーションやコメント、意味のない空行が含まれていた
私の心の声	「確かに美しくはないけど、念のため残しておいても害はないな...」

3. 上司「ボタンクリック処理の前にボタンの状態を確認する条件分岐があると安定する」

視点	状況
背景	いいねボタンを押下するテストを行いたい
当時の実装	いいねボタンは必ず未押下である前提で、クリック処理を書いていた
私の心の声	「このテスト以外で使用しないのだからいいねボタンは押されていないはず...」

4. 上司「テストデータがわかりにくいので質問毎に文言や画像を変更した方がいい」

視点	状況
背景	アンケートフォームの入力テストを行いたい
当時の実装	データ準備を簡略化するため、全ての質問や選択肢に「テスト」という文言や同じ画像を入力していた
私の心の声	「テストが通ればデータの中身は何でも良いはず。準備を早く終わらせたい」

5. 上司「アサーション時のUI要素名は適切な名称に変更した方がいい」

視点	状況
背景	テストツール上のUI要素（ロケーター）の登録名について
当時の実装	自動生成されたIDや、適当につけた名前（例: 領域1）のままにしていた
私の心の声	「ロケーターさえ正しければテストは動くから、名称は考慮しなくてもいいのでは？」

発見

当時の私は二度と同じ指摘をされないために、指摘内容と改善策を簡単に蓄積していました。

しかし、「指摘事項をメモして再発防止を徹底」を繰り返すでは限界があると感じていました。
もっと体系的に「自動テストの正解」を学ぶ方法はないだろうか？
こうして私は理想的な書き方を探す旅に出かけたのです。
道中で見つけたものは、JSTQB Advanced Level テスト自動化エンジニア（TAE）^[1] のシラバス（Version 2016.J01）でした。

「資格試験用のドキュメントだろうな...」と分量も多く気が重かったのですが、中身を読んで驚愕しました。私が上司から受けていた数々の指摘が、そのままシラバスに書いてあったのです。

答え合わせ

上司の指摘は「経験則」によるものだと思っていましたが、実は「標準的なエンジニアリングの原則」でした。指摘内容とシラバスからの学びとを照らし合わせてみます。

シラバス原文ではなく、私がシラバスを読んで解釈した学びを書いています

1. 上司「画面遷移しないことの確認のために『画面全体描画まで待機』を追加した方がいい」

視点	状況
背景	ある条件下ではリンクが非活性になり、画面遷移しなくなることを確認したい
当時の実装	リンクをクリックした後、URLが変わっていないことだけをチェックしていた
私の心の声	「遷移しないことを確認するだけなら、URL確認だけで問題ないのでは？」
シラバスからの学び	「動的待機（ポーリング）」の重要性

固定時間待つのではなく、「ある状態（描画完了など）になるまで待つ」という処理を入れることが推奨されています。処理が完了したことを確実に検知してから検証しないと、タイミングによって結果が変わる「誤検知」の原因になります。
今回の例では、クリック後の処理が完了するまで待ってからURLを確認しないと、「まだ処理中でURLが変わっていないだけ（これから変わる）」なのか、「正しく遷移しなかった」のか区別がつかず、バグを見逃す恐れがあります。

2. 上司「不要なステップは削除した方がいい」

視点	状況
背景	テスト作成時の試行錯誤の跡や、念のための確認ステップが残っていた
当時の実装	必須ではないアサーションやコメント、意味のない空行が含まれていた
私の心の声	「確かに美しくはないけど、念のため残しておいても害はないな...」
シラバスからの学び	「付加価値のないスクリプト」の削除

価値を生まないステップやスクリプトは維持管理のコストになるだけです。シラバスでも削除が推奨されており、複雑さを減らし保守性を高めるために積極的に整理すべきでしょう。
今回の例では、その1ステップに十分な価値が認められないのであれば、削除しておくことでスクリプトの可読性が上がり、将来のメンテナンスも楽になります。

3. 上司「ボタンクリック処理の前にボタンの状態を確認する条件分岐があると安定する」

視点	状況
背景	いいねボタンを押下するテストを行いたい
当時の実装	いいねボタンは必ず未押下である前提で、クリック処理を書いていた
私の心の声	「このテスト以外で使用しないのだからいいねボタンは押されていないはず...」
シラバスからの学び	「エラー回復」と「事前条件」の設計

テスト実行中に予期せぬ状態（ボタンが押されているなど）になっても、そこから回復して処理を継続できるようにする「エラー回復プロセス」や、常に同じ状態でテストを開始できる「事前条件」の確立が重要です。
今回の例では、「もしいいねボタンが押されていれば解除する」という条件分岐を追加することで、前のテストが失敗してボタンが押されたままになっていても、このテストは正しく動作するようになります。

4. 上司「テストデータがわかりにくいので質問毎に文言や画像を変更した方がいい」

視点	状況
背景	アンケートフォームの入力テストを行いたい
当時の実装	データ準備を簡略化するため、全ての質問や選択肢に「テスト」という文言や同じ画像を設定していた
私の心の声	「テストが通ればデータの中身は何でも良いはず。準備を早く終わらせたい」
シラバスからの学び	「使いやすさ」

MagicPodで作るテストケース自体も「使われるソフトウェア」であり、使いやすさが求められます。失敗した時にログを見て「どのステップで落ちたか」が一目で分かるように「実用的なレポート」を意識するといいでしょう。
今回の例では、アンケートのどの質問形式で、何問目の質問で落ちたのかを明確にしたテストデータを準備しておくと、失敗の原因を特定するまでの時間短縮が期待できます。

5. 上司「アサーション時のUI要素名は適切な名称に変更した方がいい」

視点	状況
背景	テストツール上のUI要素（ロケーター）の登録名について
当時の実装	自動生成されたIDや、適当につけた名前（例: 領域1）のままにしていた
私の心の声	「ロケーターさえ正しければテストは動くから、名称は考慮しなくてもいいのでは？」
シラバスからの学び	「解析のしやすさ」と「命名規約」

ログやレポートは、故障解析のための重要な情報源です。要素名が適切でないと解析に時間がかかってしまいます。読みやすく、保守しやすい状態を保つために、命名規約などの標準を守ることが推奨されています。
今回の例では、AIがつけた名前ではなく、社内でルール化してある適切な名前（例: 画面_いいねボタン）を設定することで、ログを見ただけで直感的に場所が分かるようになります。

結論

今回の「答え合わせ」を通じて得た結論は一つです。
「質の高いテストを書くためにも、巨人の肩の上（シラバス）に立つべき」

上司への依存に不安を感じていましたが、上司の脳内にある基準はシラバスに言語化されていました。つまり、シラバスを理解することは、上司の思考プロセスをインストールすることと同義だったのです。

これを知っていれば、以下のメリットが生まれます。

1. レビュー指摘数の減少: 最初から「正解」に近いコードが書ける
2. メンテナンスコストの低下: 壊れにくく、直しやすいテストが作れる
3. 自信: 「なんとなく」ではなく「根拠」を持って実装できる

実際に資格取得を目指すかどうかはさておき、「自動テスト実装時の辞書」として手元に置いておく価値は十分にあります。

おわりに

いかがだったでしょうか？
今まで「動けばOK」と思っていた私の自動テストの視座が、一段階上がった気がします。今後は、現場での実装（MagicPod）と理論（シラバス）を行き来しながら、より堅牢で価値のある自動テストを書いていきたいです。

もし私と同じようにレビュー指摘で悩んでいる方がいたら、ぜひ一度JSTQB TAEのシラバスを覗いてみてください。そこには「答え」が書いてあるかもしれません。

---

脚注

1. JSTQB認定テスト技術者資格の「Advanced Level Specialistテスト自動化エンジニア(TAE)試験」のこと。テスト自動化の分野に特化した専門知識とスキルを証明する資格です。
   シラバスリンク: https://jstqb.jp/dl/JSTQB-Syllabus.Advanced_TAE_Version2016.J01.pdf