技術を土台にして自分なりの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テストツールを通じて、自分ごととなる課題と、それをソフトウェアで解決するということをリアルに感じた瞬間でした。
「設計原則」が技術的な自信をくれた
プロダクトコードを書いたことのない私が、技術的な議論に加われるようになった最大の要因は、「設計原則」を知ったことです。
自動テストを書いていくうちに、「動けばいい」だけのコードに限界を感じ、気がつきました。自動テストのコードもまた、ソフトウェアだということです。 そこにはソフトウェア設計の原理原則が適用されます。特に重要だったのが「関心の分離」や「単一責任の原則」といった概念です。
テストコードの良し悪しを言語化できる
続きを読むにはログインが必要です。
ご利用は無料ですので、ぜひご登録ください。
