LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

画面操作の自動テストを外部エンジニアに作ってもらったが、半年後には失敗が並んだまま誰も見なくなった。あるいは、範囲を決めないまま頼み、手作業のテストが減らなかった——。開発の現場では、E2Eテスト自動化を頼んだあとにこうした食い違いが起こりがちです。E2Eテストとは、利用者と同じように画面を操作し、入力から結果の表示までを端から端まで通して確かめるテストで、E2Eテスト自動化はその操作と結果の照合をツールに任せる取り組みを指します。

自動化が回れば、リリースごとに同じ操作を人が繰り返す手間は減ります。ただし万能ではなく、作ったあとに直す人がいなければ、テストはすぐに画面の現状と合わなくなります。本記事では、開発の現場を預かるマネージャに向けて、どこまで自動化するのか、作る人と使う人の分け方、保守の担い手、失敗したテストの扱い、引き継ぎで残すもの、そして外部に頼むときに確認したい点を、テスト体制の決め方として整理します。

E2Eテスト自動化とは

JSTQB（日本ソフトウェアテスト資格委員会）が公開している「Advanced Level シラバス テスト自動化エンジニア」（資格試験の範囲をまとめた文書）は、テスト自動化を、専用のツールでテストの事前条件を制御・設定すること、テストを実行すること、実行結果と期待結果を比較することの1つ以上を指すとしています。^*1 やり取りの方法にはAPIテストやGUIテストなどがあり、E2Eテスト自動化は主に画面を使うGUIテストにあたります。

同じJSTQBのFoundation Levelシラバスは、テストの粒度の違いをテストピラミッドという模型で説明しています。層が高いほどテストの粒度が粗く、テスト同士の分離が少なく、実行時間は遅くなり、最上位の層は複雑でハイレベルのエンドツーエンドテストを表すとされています。^*2 上の層のテストは大きな機能の一部をまとめて確かめるため、妥当なカバレッジ（確かめたい範囲のうち実際に確かめた割合）を得るのに必要なテストは、通常ほんの数個で足りるとも書かれています。

この模型に沿えば、細かな部品の確認は下の層のテストに任せ、E2Eテストは画面を通る主な流れに絞ることになります。シラバスは、テスト自動化には文書、テスト環境、テストデータを含むテストウェアの設計まで含まれるとも述べており、頼む範囲はスクリプトを書く作業だけでは終わりません。

どこまで自動化するのか

シラバスは「すべてのテストが自動化できるとは限らず、またすべてを自動化するべきでもない」と書いています。^*1 自動化で確かめられるのは、ツールが解釈できる結果と、あらかじめ定めた期待結果で判定できる結果だけで、探索的テスト（決まった手順を持たずに試しながら進めるテスト）は自動化に置き換えられないとされています。

自動化するかどうかを決める条件として、シラバスは使用頻度、自動化の複雑度、ツールの適合性とサポート、テストプロセスの成熟性、ライフサイクルの段階、自動化環境の持続可能性、テスト対象のシステムの操作特性の7つを挙げています。^*1 いちばん分かりやすいのは使用頻度です。リリースのたびに行うテストほど候補になりやすく、年に1度しか行わないテストは手動のほうが望ましい場合があるとされています。

時期も効きます。開発の初期は変更が早すぎて自動化が追いつかない場合があり、工程を順に進める大規模なシステムでは、システムが安定し中心の機能を組み込んだ時点で始めるのが望ましいとされています。使い終わりが近いシステムの自動化は勧められていません。

始め方としては、限られた範囲から着手し、自動化に手間がかからず価値の高いテストを選ぶよう勧めています。例に挙がっているのは、毎日のように実行される回帰テスト（変更がほかの部分に悪い影響を与えていないかを確かめるテスト）やスモークテスト（基本の動作が通るかを短時間で確かめるテスト）です。E2Eテスト自動化を頼むときも、最初はログインから主要な業務の完了までのように、毎回通す流れに絞ると、効果と手間の釣り合いを確かめやすくなります。

作る人と使う人の分け方

シラバスは、テスト自動化は全員が参画できる活動にすべきだが、全員が同じ役割を担うわけではないとしています。^*1 自動テスト環境の設計・実装・保守は本質的に技術的な作業なので、プログラミングの技能に強い人を割り当てます。一方、何を確かめるテストスクリプトを書くかには、業務の専門性とテストの技能を持つ人が要るとされています。

結果の読み方も分かれます。業務の専門家はレポートで機能を確かめ、技術の専門家は自動化の環境が正しく動いていることを受け持つ、という整理です。外部エンジニアに頼みやすいのは技術側の役割です。何を確かめるかと、失敗が業務上の問題かどうかの判断は、仕様を知る社内に置きます。

開発チームとの連携も欠かせません。シラバスは、選んだ自動化ツールと適合しない画面部品を開発担当者が選ぶ可能性を例に挙げ、開発担当者とテストの担当者がより密接に連携して作業する必要があるとしています。GUIテストについては、画面の操作やデータをできる限り画面の構成から切り離して設計する必要があるとも述べています。画面の部品に自動テスト用の目印を付けるかどうかといった取り決めは、自動化を受け持つ人と開発チームが最初に話しておく事柄です。

保守を誰が担うのか

E2Eテスト自動化で後から効いてくるのが保守です。シラバスは、テスト自動化のコードの保守は煩雑になる可能性があり、テスト用のコードの量がテスト対象のシステムのコードと同程度になることも珍しくないとしています。^*1 保守の手間は、システムに加える変更の規模に比例するのが望ましいとも書いています。

保守の種類として挙がっているのは4つです。より多くのテストの種類や新しい対象に対応させる予防保守、自動化の仕組みの故障を直す修正保守、性能や使いやすさを高める完成度を高めるための保守、新しいOSやWebブラウザなどに合わせる適応保守です。画面を操作するテストでは、ブラウザの更新と画面の変更に合わせた手直しが繰り返し発生します。

初めて導入するときの基本の手順として、シラバスは、仕組みを動かす基盤の定義と構築に加えて、仕組みと基盤の保守手順の作成、テストスイート（まとめて実行するテストの一式）の保守手順の作成を挙げています。保守の手順を書くところまでが、作る段階の仕事に入るということです。保守を契約の終わりとともに止めるのか、社内の誰かが引き取るのか、続けて外部エンジニアに頼むのかは、作り始める前にテスト体制の中で決めておきます。

避けたい作り方も示されています。画面やAPIの重要でない部分の変更で壊れるスクリプト、特定のデータ値に大きく依存するテスト、日付や時刻など実行環境の条件に左右される自動化環境は作らない、というものです。成果物を受け取るときは、この3点に当たる作りがないかを見ておきます。

失敗したテストの扱い

自動テストが失敗したとき、原因は1つではありません。シラバスは、テストが失敗する理由を、テスト対象のシステムで見つかった故障、自動化の仕組みで見つかった故障、テスト自身またはテスト環境の問題の3つに分けています。^*1 失敗の報告を受けたら、まずこの3つのどれにあたるかを切り分ける人を決めておくことが、テスト体制の要になります。

新しい要件や変更された要件によってテストが失敗した場合は「失敗したテストを無効にするのではなく、修正する」とされています。^*1 止めたまま放っておくと、確かめている範囲が知らないうちに縮みます。

結果が安定しないテストの扱いも書かれています。繰り返し実行したときに結果が変わるテストは、実行中の自動テストスイートから移して個別に分析し、根本原因を調べることができ、そうしないと実行のたびに問題の分析に時間を使うことになるという趣旨です。

外部エンジニアに頼むときは、失敗を誰が最初に見るか、何日以内に3つの原因のどれかに振り分けるか、スイートから外したテストを誰が戻すかまで、テスト体制の表に書いておきます。

引き継ぎで残すもの

作った本人が離れても自動テストを回し続けるために、シラバスは保守を効率よく行う手法として、導入手順と使用方法の文書化、外部の部品への依存・欠点・既知の問題の文書化、テストスクリプトとフレームワークの分離、仕組み・環境・テストスイート・テストウェアを構成管理（版を記録し、変更を追えるようにする管理）の対象にすることなどを挙げています。^*1

名前の付け方の取り決めも引き継ぎに効きます。変数やファイル、テストシナリオの名前をそろえておけば、新しい人員がテスト自動化のプロジェクトに参画しやすくなるとされ、こうした規約はプロジェクトの開始時にすべて合意し、文書化しておかなければならないとされています。

文書の扱いについては、開発の手順の一部に文書作成を組み込み、「文書の作成または更新が行われるまでは、タスクは完了したとはみなされない」とする考え方が挙がっています。^*1 頼む作業の完了条件に、手順書と既知の問題の一覧の更新を入れておくと、離任の直前にまとめて書いてもらう事態を避けられます。

外部に委託するときに確認しておきたい点

E2Eテスト自動化を外部エンジニアに頼む前に、社内で決めておきたいのは4つです。どの業務の流れを自動化するか、確かめる中身と結果の判断を誰が持つか、保守をいつまで誰が担うか、失敗したテストを誰がどう振り分けるかです。ここまで決まれば、求める経験も具体的に書けます。

依頼の文面の成果物に、テストスクリプトのほか、環境を用意する手順、保守の手順、既知の問題の一覧、名前の付け方の取り決めを入れておくと、引き継ぎの範囲がはっきりします。シラバスは、テストツールとテスト対象のシステムの適合の度合いを十分に理解しないまま始めると、深刻な結果になることがあると注意しています。ツールを先に決めるより、対象の画面や技術と合うかを最初に確かめてもらうほうが、後戻りを減らせます。

部品をつないだ段階のテストで役割を分ける話は外部エンジニアと進める結合テスト、テスト体制に書く4つの役割にまとめました。

手作業のテストを受け持つ人を加える場合はリリース前のテスト要員と開発要員の違い、分ける作業と判定を参考にしてください。

離任のときに何を残してもらうかは業務委託エンジニアの離任で引き継ぎが漏れる理由と防ぎ方で整理しています。

まとめ：E2Eテストで確かめる3つの点

E2Eテスト自動化を外部エンジニアと進めるうえで、確かめておきたい点は3つに整理できます。第一に、すべてを自動化の対象にせず、リリースのたびに通す主な業務の流れに範囲を絞ること。第二に、スクリプトを作る人、確かめる中身と結果を判断する人、保守を担う人を、テスト体制の中で分けて書くこと。第三に、失敗したテストを3つの原因に振り分ける担当と、引き継ぎで残す文書を、作り始める前に決めておくことです。この3点を踏まえておけば、「自動テストは作ったのに、失敗の表示が並んだまま誰も見なくなった」という事態を避けやすくなります。保守を受け持てる人が社内にいないなど、体制づくりに迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：JSTQB（日本ソフトウェアテスト資格委員会）「テスト技術者資格制度 Advanced Level シラバス テスト自動化エンジニア Version 2016.J01」（PDF）（https://www.jstqb.jp/wordpress/wp-content/uploads/2026/03/JSTQB-Syllabus.Advanced_TAE_Version2016.J01.pdf）。出典：ISTQB Advanced Level Test Automation Engineer Syllabus 2016の日本語翻訳版（2020年9月30日）。1.1（テスト自動化の目的）、1.2（テスト自動化の成功要因）、4.2（リスクアセスメントと軽減戦略のうち初回導入と更新）、4.3（テスト自動化の保守）、6.1（自動化の移行条件）、6.2（回帰を自動化する際に必要な手順の特定）、7.2（自動テストスイートの検証）を参照（2026年9月確認）
2. *2　参考：JSTQB（日本ソフトウェアテスト資格委員会）「テスト技術者資格制度 Foundation Levelシラバス Version 2023V4.0.J02」（PDF）（https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf）。出典：ISTQB Foundation Level Syllabus v4.0の日本語翻訳版。5.1.6（テストピラミッド）を参照（2026年9月確認）
3. *3　参考：JSTQB「シラバス」（公開ページ）（https://www.jstqb.jp/syllabus）。各シラバスが公開されていることの確認として（2026年9月確認）

Tweet