「QAエンジニア」と一口で言っても、その背景や専門性は多岐にわたります。
前回の連載では、自身の経験がブリコラージュのように結びつき、現在の土台となっていることについてお話ししました。
本連載は新たに、「Connecting the dots」というテーマを扱います。
本連載では、今まで現場やコミュニティの中で出会ってきた専門家の皆様と、往復書簡のような形で意見を交換していきます。
ひとりひとり独立した専門家という「点」を、技術や関心ごとといった共通点で繋ぎ、連載を形作ります。
本シリーズ最初の話題は「E2Eテスト自動化」を取り扱いたいと思います。
お相手は同じくSqripterの伊藤由貴さんで、2回程度の往復（全5回）を予定しています。
本記事では、私の視点から「E2Eテスト自動化のいまむかし」について振り返りつつ、伊藤さんへバトンを渡したいと思います。
※これ以降、単に「テスト自動化」と表現するものは「E2Eテスト自動化」を指します。
テスト自動化との出会い
私が「テスト自動化」というものに本格的に触れる機会があったのは2021年ごろです。
第三者検証会社での「テスト自動化トレーニング」という1ヶ月ほどのフルタイムの研修に通った時期でした。
当時の私はターミナルがインターフェースとなる製品にしか携わったことがありませんでした。
テスト自動化の技術が公に議論されているWebの分野については全くの未経験であり、どこか蚊帳の外にいるような感覚がありました。
Seleniumを主として、複数のツールを使ってE2Eテスト実装の体験をしました。
2020年にもJSTQBのワーキンググループからテスト自動化エンジニアのシラバスが翻訳されたこともあり、「テスト自動化」という技術が「特別な経験者が持つスキル」から「勉強すればアクセスできるスキル」という位置付けに変わってきたタイミングだったなと今では思います。
現在隆盛を誇っているPlaywrightを触り始めたのもこのタイミングであり、当時は後発のツールであるPlaywrightがどんな思想で、どんな優位性を持っているかという、初期段階の構想を調べたことがあります。
この体験がきっかけとなって、テスト自動化カンファレンスで発表するアイデアが生まれたことなど、今振り返ると、感慨深いものがあります。
余談：伊藤さんとの不思議なご縁
この連載を始めるときに全く意識していなかったのですが、この研修コースを企画・運営している課の課長が伊藤さんでした。
また、現在私は主に”QAエンジニア”と呼ばれるロール、あるいはテストや品質保証に関する明確な専門家がいない現場を支援することがあります。いわゆる「一人目QA」のような立場で支援を行っています。
当時は（今もですが）雲の上のような存在でしたが、今でもこうして伊藤さんから多くを学びつつ、親しく交流させていただいていることに、不思議なご縁を感じています。
テスト自動化の現在
2026年現在、私がテスト自動化を学んでから5年程度が経ちましたが、特にWeb分野のテストエンジニアのスキルセットとして、その位置づけが大きく変化してきたように感じます。
5年前は「テスト自動化ができる環境をセットアップしてコードが書ける」というだけでも重宝されていた記憶があります。
一方、今ではテスト自動化という分野は採用において前提条件となっていたり、当たり前の技術になっていると強く感じます。
特にPlaywrightについてはプロダクトコードを書くエンジニア、いわゆる”開発者”が詳しく知っているような現場に何度か出会いました。
生成AIによるコード生成
こういったテスト自動化のやりやすさは生成AIの登場により、ますます顕著になったと考えます。
（個人的にはあまり推奨したくない表現ですが）いわゆる「エンジニア経験のないQA」であっても、自然な日本語を使ってテスト自動化フレームワークが動作する環境を作り、開発環境をセットアップし、テストコードを書くことができるようになったためです。
テスト自動化をどう考えるか
テスト自動化の成果物、つまりテストコードが簡単に書けるようになって、「何を自動テストにするか」というテスト計画・設計・分析といった知見の必要性が強くなってきたことも感じます。
一見これは生成AIによるプロダクトコードと同様の論点に聞こえます。
しかしながら、テストはプロダクトコードと違い、ユーザーの使われ方や売り上げといった、効果測定や仮説検証がしづらい課題があると考えています。
こうしたテストコード特有の落とし穴は想像以上に根深く、AIを活用してテストコードを生成する際に、その課題の大きさを痛感させられます。
テスト自動化ではなく自動テスト
ここで一言言及しておきたい考えがあります。
「テスト自動化ではなく自動テスト」という考え方です。
「テストを自動化する」ではなく「自動化に適したテストを自動テストとして捉え直す」という提言はSqripterでもある末村さんが2020年にすでに言及されています。
私も、本記事では「テスト自動化」という言葉を使っていますが、普段は文脈により「テスト自動化」と「自動テスト」は使い分けるようにしています。
そして、可能な限り後者の表現が適した活動になるよう日々心がけています。
参考：テストを自動化するのをやめ、自動テストを作ろう（Speaker Deck）／Takuya Suemura
AIテストツールの現在は？
生成AIが爆発的に流行する以前にあった、いわゆる「ノーコードテスト自動化ツール」はどうでしょうか。
実のところ、私は過去にノーコードテスト自動化ツールに対して苦手意識を持っていました。
2021年にMagicPodをはじめとしたテスト自動化ツールを触りましたが、率直な感想として「ノーコードよりもコードを書いた方が実装者としていい体験ができる」という感覚を持った覚えがあります。
そうした背景から、ノーコードテスト自動化ツールに関しては自発的に学習する意欲を保つのが難しい時期がありました。
そのため、テスト自動化ツールの知識はテスト自動化実装担当者として手を動かさなくなってから、アップデートされていないのが実情です。
私がツール選定に関わる立場になっても、これらのツールを積極的に採用する機会に恵まれませんでした。
一方で現在では、PlaywrightのCodeGenのように、コードベースのツールでもノーコードツールと同等の機能が簡単に実現できるようになっています。
また、PlaywrightCLIなど、生成AIを効果的に使いながらさまざまな運用が可能になっていますね。
なにより、テストコードの自動修正など、機能レベル（あるいはカタログスペックとして）で同等のことが簡単にできるようになったとも考えます。
伊藤さんへのバトン
ぜひ伊藤さんに聞いてみたいことがあります。
私はテスト自動化が「当たり前の技術」となり、だからこそ慎重に「自動テスト」について考えるような、手動テストの設計時と同様に、冷静な視点が必要だと感じています。この点について、ぜひ見解をお聞きしたいです。
そして、生成AIの登場でノーコードのテスト自動化ツールがどのような影響を受けるのか。
現在MagicPodのエヴァンジェリストをされている伊藤さんがこの状況をどう捉えておられるか、ぜひ見解をお聞かせいただきたいです。
