技術を土台にして自分なりのQAエンジニアを目指す本連載、第6回のテーマは「テスト自動化」です。
前回の記事をご覧いただいた方はご存じだと思いますが、私は文系大学出身で、キャリアのスタートは営業職でした。 実務で、商用のプロダクトコードを書いた経験は、今もありません。
もっと言えば、かつての私は「Pythonの環境構築」をするためだけに、1カ月以上も躊躇して手が動かなくなるような人間でした。当時の上司から「Python興味あるんだったらなんで入れないの？」「やらないってことは興味ないってことじゃん」と言われた記憶があります。 私が上司だったらそんなことは言わないですが、そう思う気持ちはすごくわかります。
当時は本当に何もわからずに、「Anaconda」がいいのか、「仮想環境」がいいのか、公式からインストールできるPythonがいいのか。 そもそもPCにPythonを入れてしまって、壊してしまうかどうかも不安でした。
そんな私が、どのようにしてテスト自動化という領域に自信を持ち、それをQAエンジニアとしての土台に変えていったのか。 今回は、ツールを動かすことの先にある「設計原則」への理解と、そこから得られた視点についてお話しします。
記事一覧：技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合
本稿におけるテスト自動化
本題に入る前に、この記事で扱う「テスト自動化」について定義しておきます。
一般的にテスト自動化といえば、「ツールを使ってテスト実行を自動化すること」と捉えられがちです。 しかし、AIによるコーディングが当たり前になった現代において、私はより広い意味を定義したいと思います。
「テストという活動を構造化し、実行可能な『ソフトウェアシステム』として設計・構築・運用する技術」
テストにおいて、単にスクリプトを書くことと、システムとして構築することは似て非なるものです。 前者は時に手順の翻訳となってしまいますが、後者にはアーキテクチャが必要で、保守性への配慮も必要であり、なにより「テストそのものへの深い理解」が必要です。
かつてはテスト自動化スクリプトを書くだけでも立派な「テスト自動化エンジニア」でした。
しかし、2026年1月現在、AIはスクリプトを書くことはできますが、プロジェクトのコンテキストに適した「テストシステム」の青写真を人間の補助なしに、プロジェクトに最適化された形で描くことはできません。 この「テストシステムを設計する技術」こそが、本稿で伝えたいテスト自動化の本質です。
ツールを通して「普遍的な課題」を学ぶ
私がテスト自動化を学び始めた当初、関心は「どうやって動かすか」というHowにありました。 当初は書いたコードがすぐ壊れる辛さや、朝になったら自動テストが動いてない悲しみを味わっていたことを覚えています。そこから、Page Object ModelやCIの学習を深め、Playwrightなどのモダンなツールの設計思想に触れるにつれて、視点が変わっていきました。
自動化ツールやデザインパターンは、単なる便利な機能の寄せ集めではありません。 それらは、テスト活動が抱える「普遍的な課題」への解決方法そのものでした。
例えば、WebのE2Eテストでは「待機処理」が頻繁に課題になります。 これは、テスト実行環境やネットワークの「不確実性」といかに向き合うかという、Webの自動テストにおける難しいテーマです。 また、UI変更のたびにテスト修正に追われた経験や、Flakyなテストへの対応は、まさに「保守性」の課題そのものでした。
優れたツールには、こうした課題に対する一貫した問題意識や思想が込められています。 「なぜ、この機能があるのか？」「なぜ、この設計なのか？」 その背景にある思想を理解することは、単にツールの使い方を覚えるだけでなく、テストそのものに対する解像度を一気に高めてくれます。
自動化技術を学ぶことは、コーディングスキルを磨くだけでなく、こうしたテストの構造的な課題を深く理解するプロセスでもあります。 これはE2Eテストツールを通じて、自分ごととなる課題と、それをソフトウェアで解決するということをリアルに感じた瞬間でした。
「設計原則」が技術的な自信をくれた
プロダクトコードを書いたことのない私が、技術的な議論に加われるようになった最大の要因は、「設計原則」を知ったことです。
自動テストを書いていくうちに、「動けばいい」だけのコードに限界を感じ、気がつきました。自動テストのコードもまた、ソフトウェアだということです。 そこにはソフトウェア設計の原理原則が適用されます。特に重要だったのが「関心の分離」や「単一責任の原則」といった概念です。
テストコードの良し悪しを言語化できる
これらの原則を意識するようになったことで、私はコードを「なんとなく動く」ではなく「構造」や「意味」で捉えられるようになりました。
例えば、表面的な理解しかしていない私では、生成AIや他者が書いたテストコードに対し、「動いているからOK」としか言えなかったと思います。 しかし今は、違和感を自分自身で言語化し、「テストの保守性」や「意図」という観点からレビューができるようになりました。
「このアサーションはこのテストで本当に確認したい内容でしょうか？」
「このコードは分離して共通化することが可能ではないでしょうか？」
「ツールが目指す方向性に合っているか」「良い構造か、将来の変更に耐えうるか」を判断するための視点は、ツールの思想や、設計原則を学ぶことで養えます。 この視点を持てたことが、私の技術的な自信の源泉となりました。
自動化を「当たり前の選択肢」にする
設計原則を知り、技術的な見通しが立つようになると、テスト自動化に対する心理的なハードルが消え去りました。 そして、テスト自動化は特別な領域ではなく、「当たり前の選択肢」の一つになっていることに気がつきました。
「選択できる」という強み
今の私は、簡単なスクリプトであれば構成を考えてサッと自分で書くことができます。(今では生成AIを使いますが)
あるいは、複雑なテストであっても、その構造を読み解き、保守のリスクを見積もることができます。
重要なのは「全てを自動化すること」ではありません。 「ここは手動でやるべきか、自動化すべきか」という問いに対し、技術的な裏付けを持った上で自信を持って検討できる状態にあることです。 自動化もできるし、手動もできる。「今回はこちらがベターな選択だ」と根拠を持って説明できること。 これが、QAエンジニアとしての幅を広げていると考えています。
専門性の組み合わせ
最後に、この技術が他の専門性とどう結びつくか触れておきます。
テスト設計との組み合わせ
自動化の構造（アーキテクチャ）を理解することで、テスト設計の質が変わります。
まず私が強く感じているのは、自動テストを書くことによってテストケースの性質を理解できるようになったことです。自動化しやすいテストケースは、往々にして「前提条件が明確」で「責務が単一」な、人間にとっても分かりやすいテストケースです。 「関心の分離」という思考の補助線は、自動・手動を問わず、堅牢なテスト設計を行うための強力な武器になります。
テストマネジメント
テストマネジメントにおいては、ROIの判断や戦略的に自動化を取り入れるかどうかの判断が、より精緻になると考えています。自動化コードの「保守コスト」や「技術的負債」のリスクを実体験に基づいて理解しているため、過度な期待も悲観もせず、プロジェクトの状況に合わせて適切なタイミングで自動化という選択肢を選べるようになりました。
おわりに
かつての私のように、「文系だし」「環境構築すら怖い」と尻込みしている方も多いかもしれません。
私にとって、テスト自動化を学ぶことは、ある意味で「プログラマーになること」と同義でした。 しかし、そのハードルは、想像していたよりもずっと低いものでした。
そしてそのハードルを飛び越えることによって、プログラマーとして「プロ」であることの困難さと、その凄みを目の当たりにしました。
勇気を出してその一歩を踏み出してみれば、そこにはシステムが動く仕組みや、先人たちが築き上げたソフトウェア設計や原則が、複雑な現実を生き抜くための「道しるべ」となってくれるはずです。
テスト自動化を学ぶことは、その「道しるべ」を発見する最高のきっかけになるはずです。
その小さな一歩が、あなたのQAエンジニアとしての強固な土台となると考えています。
