手動テストと自動テスト: エンドツーエンドテストで手動テストが力不足になる理由

手動テストは人がアプリを手で確認すること、自動テストは人なしでそれを再生することです。リリースごとに繰り返す機能テストやエンドツーエンドの確認では、手動テストは力不足です: 遅く、テスターによって結果が変わり、ビルドごとには実行できません。

これは手動テスターを否定する記事ではありません。優れたテスターは、どのスクリプトも探さないようなバグを見つけます。問題は仕事のもう一方の部分です: 同じフォーム、同じメニュー、同じ購入手続きを、リリースのたびに、すべてのブラウザーとすべての言語でたどり直すことです。この部分は規模に合わせて増やせず、テスターの注意力の使い道としてふさわしかったことは一度もありません。

手動テストと自動テスト: その違い

回帰テストが初めてなら、回帰テストとはで、変更のたびに同じ確認が戻ってくる理由を説明しています。

手動テストが今も一番得意なこと

公平に比べるなら、まずどんなテストよりも人が得意なことから始めるべきで、そのリストは確かに存在します。

State of DevOps レポートを手がける研究プログラム DORA も同じことを言っています。そのテスト自動化のページは、探索的テストやユーザビリティテストといった手作業の活動を続けるよう勧め、テスターと QA チームは引き続き重要な役割を担うと述べています。

エンドツーエンドテストにおける手動テストの限界

手動テストは、一度だけ行う確認にはよく合います。以下は、同じ機能テストやエンドツーエンドの確認がリリースのたびに戻ってくるときに現れるデメリットです。

リリースのペースにも、AI が書くコードにもついていけない

手動の回帰確認は、シナリオのリストと同じ長さになり、そのリストは増える一方です。機能が増えるたびに確認が加わり、削られることはほとんどありません。

AI コーディングアシスタントはこの差をさらに広げます。2026 年のレポートで Faros AI は、22,000 人の開発者について AI の利用が少ない時期と多い時期を比べ、開発者が採用する AI 生成コードの割合が 20% から 60% に増え、開発者 1 人あたりのプルリクエストのマージが 16.2% 増えたことを示しました。テスターに届く変更は毎週増えますが、人が確認する速さは変わりません。

AI が生成したコードのテスト方法で、この問題を詳しく見ています。

繰り返しが見落としを生む

人は探しているものを見ます。同じフォームを 20 回目に確認するとき、テスターはテストケースに書かれた項目を確認し、そのすぐ横で消えたロゴを見落とします。

専門家も例外ではありません。Psychological Science に掲載された 2013 年の研究では、研究者が 24 人の放射線科医に CT 画像で肺結節を探すよう依頼し、最後の画像に結節の 48 倍の大きさのゴリラを入れました。83% がゴリラに気づかず、視線計測では、その大半がゴリラを真正面から見ていたことがわかりました。

注意深い検査にも上限があります。2015 年に Human Factors に掲載された訓練を受けた 82 人の検査員の研究では、不良品の 85% を見つけており、著者が業界平均として挙げる 80% に近い数字でした。不良を見つけることが仕事の人たちでも、およそ 7 個に 1 個は見逃したのです。

ブラウザー、デバイス、言語ごとに作業が倍増する

Chrome で確認したウェブアプリは、Firefox では確認されていません。英語で確認した画面は、ラベルがどれも長くなるドイツ語では確認されていません。手作業では、ブラウザー、画面サイズ、言語ごとに完全な確認がもう 1 回増えるので、チームは作業時間を何倍にも増やすか、黙って 1 つの組み合わせだけを確認することになります。

1 回の記録からのクロスブラウザーテストでは、1 つのウェブテストがブラウザー、デバイス、言語ごとのバージョンになる仕組みを紹介しています。

ビルドごとに実行できない

開発者は 1 日に 10 回ビルドできますが、テスターは 1 日に 10 回確認できません。そのため手動の確認はスプリントの終わりに行われ、木曜日に見つかったバグは月曜日に書かれたものです。DORA のテスト自動化のページははっきり述べています: 手動の回帰テストは実行に時間がかかりコストも高いためボトルネックになり、開発者はすばやいフィードバックを得られません。

証拠がほとんど残らない

手動の確認が終わったとき、記録はチェックマークのリストと、ときどき失敗のスクリーンショットがある程度です。合格した手順で画面がどう見えていたかを後から確かめることも、このリリースを前のものと比べることもできません。バグ報告に「昨日は動いていた」と書かれていても、どちらとも証明できません。

テスターによって結果が変わる

テストケースに「注文の概要を確認する」と書いてあるとします。あるテスターは合計を読み、別のテスターはすべての行を読み、3 人目は日付まで確認します。どれも正しく、それぞれの確認は別のものを確かめています。同じテスターでも、金曜日の午後と月曜日の朝では同じではありません。

コストがリリースごとに増える

手動の確認は、実行するたびに同じ時間がかかり、それが永遠に続きます。自動テストは作成に一度だけ時間がかかり、アプリを意図的に変えたときに少し手入れが必要ですが、その後はマシンの時間だけで実行されます。製品が長く続くほど、その差は広がります。

手動の回帰テストに時間がかかりすぎる理由

この掛け算は過小評価されがちなので、きりのよい数字で示します。リリース前に確認したいシナリオが 40 あり、手作業で 1 つ約 10 分かかる、ごく普通のウェブアプリを考えます。

これらの数字は説明のための例で、調査結果ではありません: あなたのシナリオは 5 分かもしれないし 30 分かもしれません。大事なのは形です。ブラウザー、言語、リリースのたびに時間は掛け算で増え、テスターの人数は変わりません。

だから手動の回帰テストはリリースのボトルネックになります。チームは確認が終わるのを待つか、終わらないまま出荷します。

手動テストと自動テスト、作業ごとの比較

公平な答えは「すべて自動化する」ではありません。作業の種類ごとに、より良いやり方があります。

テストを自動化するとき、手動のまま残すとき

QA チームがもっと早く自動化しなかった理由

繰り返しの確認には自動化のほうが優れているなら、なぜ多くのチームはいまだに手でやっているのでしょうか？ 主な理由は、これまで自動化が意味してきたもの、つまりコードです。

Playwright、Selenium、Cypress、Appium、WinAppDriver といったコードで書くフレームワークでは、テストはプログラムです。誰かがプログラミング言語で書き、すべての要素をセレクターで見つけ、ページが変わればそのセレクターを直します: Playwright 自身のドキュメントも、CSS や XPath のセレクターはページの構造が変わると壊れることがあると注意しています。

こうして手動のテストケースは手動のまま残りました: いちばんよく知っている人は自動化できず、自動化できる人はほかの仕事で手一杯だったのです。それでもスイートが書かれた場合、不安定なテストと誤検知で説明しているように、保守の手間と不安定な結果がしばしばそれを疲弊させました。

手動のテストケースを自動テストに変える方法

Windows でエンドツーエンドテストを自動化する GUI Test Studio は、シナリオをすでに知っている人のために作られました。今日手でやっているのと同じやり方でテストを一度行えば、それがひとりでに実行されるテストになります。デスクトップアプリ、ウェブアプリ、ゲーム、Android スマートフォンで使えます。

1. 1

   リリースのたびに繰り返すテストケースを選ぶ

   ログイン、検索、注文など、チームがリリースの前に毎回手で確認しているワークフローから始めましょう。繰り返す回数が多いほど、自動テストは早く元が取れます。

2. 2

   開始地点を書き留める

   テストは、あなたが始めた場所から、あなたが行ったとおりのことを正確に再生します。シナリオが始まる画面、アカウント、データを書き留め、実行の前には毎回アプリをその状態に戻しましょう。

3. 3

   一度記録するか、プロンプトで説明する

   GUI Test Runner-Recorder で「記録」をクリックし、普段のペースで自分でシナリオを行います。または手動テストケースの手順をプロンプトに貼り付ければ、AI アシスタントが GUI Test Studio を通して手順を実行し、テストを保存します。

4. 4

   何を検証するか選ぶ

   記録が止まると、アプリはこのテストで何を検証するかを尋ねます: ビジュアル要素、テキスト、そして画面に現れるものです。確認はテストの保存時に、使った要素ごとに 1 つずつ作られます。

5. 5

   一度実行してから仕上げる

   アプリをテストが始まる状態に戻し、「テストを実行」をクリックします。それから GUI Test Studio で開き、重要な手順に名前を付けたり、記録で作られなかった確認を加えたり、待機を調整したりします。

6. 6

   ビルドごとに実行する

   コマンドラインのランナーである gtr-cli をパイプラインに加えます。「テストを実行」ボタンと同じようにテストを実行し、CI ツールに終了コードと JUnit ファイルを渡します。

7. 7

   失敗したらレポートを読む

   実行のたびに信頼度レポートが書き出されます: 判定、すべての手順、そして失敗した確認ごとに、期待した画像と見つかったものを並べたものと、実行の動画です。

記録: 手動のテストケースを一度だけ行う

記録とは、手動の確認を最後にもう一度行うことです。記録をクリックし、画面全体、アプリ、ウェブアプリ、領域、スマートフォンのいずれかを選んで、ユーザーと同じようにシナリオを行います。終わったら停止キーを押します。テストを記録するではすべての手順を、最初のテストでは練習用ページを数分でたどる方法を紹介しています。

プロンプト: いつも書いているとおりのテストケース

テストケースがすでに書かれているなら、プロンプトのほうが早いかもしれません。手順をプロンプトでテストを作成または編集ウィンドウに貼り付け、AI アシスタントに送ります: Claude、Codex 付きの ChatGPT、またはローカルの AI モデル(私たちが提供するものでも、お持ちのものでも)です。アシスタントは GUI Test Studio を通して手順を実行し、頼まれたことを確認して、テストを保存します。プロンプトからテストを作成するを参照してください。

拡大

何を検証するか選ぶ

手動テスターは何を見るかを自分で決めます。記録も同じです: 停止すると、このテストで何を検証するかを尋ねます。ビジュアル要素を検証はクリックや入力をしたすべての要素を、テキストを検証は文言を、表示される内容を検証はクリックなしで現れるメニュー、ダイアログ、メッセージを確認します。何を検証するかで、それぞれの選択肢を説明しています。

拡大

どの確認も、アプリの作られ方ではなく、ユーザーに見えるものを対象にします。各要素を見つけるために、GTS Engine + AI はまずアプリケーションに問い合わせ、アプリケーションが答えないときは見た目で要素を見つけます。書くべきセレクターも、最新に保つべきセレクターもありません。

ビルドごとに実行する

コマンドラインのランナーである gtr-cli は、「テストを実行」ボタンとまったく同じようにテストを実行し、パイプラインに必要なものを加えます: 終了コード、JUnit ファイル、そして失敗の証拠一式を 1 つのフォルダーにまとめたものです。どの CI/CD ツールでも使えます。パイプラインでテストを実行するに、すべてのオプションがあります。

gtr-cli run tests --junit results\junit.xml

拡大

自動実行が返してくれるもの

ここで自動テストは、手動の確認のいちばんの弱点に答えます。実行のたびに信頼度レポートが書き出され、テストと一緒に保存されます。

拡大

そこからバグレポートを使えば、失敗を記入済みのレポートや、画像を添付した Jira 課題にできます。信頼度レポートのガイドで読み方を説明しています。

手動テストはもう終わりなのか?

いいえ、終わるべきでもありません。終わろうとしているのは手動の回帰テストです: 決められた同じ確認を、リリースのたびに手でたどることです。その仕事をしてきたテスターこそ、どのシナリオが重要かを知っており、それはまさに自動テストに必要なものです。

繰り返しの確認を自動化すれば、QA チームは探索的テスト、新しい機能、人にしかできない問いに時間を使えます。テストはビルドごとに実行され、テスターはその結果を見直します。

ツールは初めてですか？ GUI Test Studio を始めるで、最初のテストを最初から最後まで紹介しています。

要点

• 1手動テストと自動テストは違う仕事をします: 人は探索して判断し、自動テストは同じ確認を毎回同じやり方で繰り返します。
• 2手動の機能テストとエンドツーエンドの確認は、繰り返すと力不足になります: リリース、ブラウザー、言語が増えるたびに遅くなり、ビルドごとには実行できません。
• 3繰り返しは見落としを生みます: 専門家でも探していないものは見落とし、同じテストケースでも 2 人のテスターは違うやり方で確認します。
• 4コードが多くの QA チームを自動化から遠ざけてきました: コードで書くフレームワークでは、テストは書いて保守するセレクター付きのプログラムです。
• 5GUI Test Studio は手動のシナリオをテストに変えます: 一度記録するかプロンプトで説明し、gtr-cli でビルドごとに実行して、画像と動画付きのレポートを読みます。

よくある質問

Playwright、Selenium、Cypress、Appium、WinAppDriver、Chrome、Edge、Firefox、Claude、ChatGPT、Codex、Jira、Windows は、それぞれの所有者の商標です。