テスト自動化エンジニアのスキルシートの書き方｜面談で評価される実績の見せ方

テスト自動化エンジニアのスキルシートは、使ったツールの名前を並べるより、自動化の「立ち上げ・拡充・立て直し」のどれを担ったか、単体・API・E2Eのどの層で確かめる設計にしたか、CIでどう回して安定させたかを書くのが基本です。読み手は、テストコードを書ける人かどうかだけでなく、そのテストが開発チームに信頼され、使われ続けたかを知りたいと考えています。

案件で求められるスキルの中身はテスト自動化エンジニアのスキルの記事、全体の構成はスキルシートの基本で扱っています。この記事では、テスト自動化ならではの書き方に絞って説明します。

「立ち上げ・拡充・立て直し」を書き分ける

テスト自動化の案件は、自動化がどの段階にあるかで、求められる経験が変わります。プロジェクト欄の冒頭に、自分が担った局面を書きましょう。

拡充の経験だけでも、案件は多くあります。ただ、立ち上げと立て直しは、判断の場面が多いぶん面談で深く聞かれます。担っていない局面を書かないことが大切です。

立て直しの経験は、ほかの職種のシートにはない、テスト自動化ならではの実績です。不安定なテストの原因を突き止め、消すものと直すものを分けた経緯は、1行でも書いておくと読まれます。

ツールの欄は「言語・枠組み・実行の場所」で区切る

テスト自動化のスキル一覧は、ツールの名前が並ぶだけになりやすい欄です。次のように区切ると、読み手が自分の案件に関係する部分を探しやすくなります。

ツールの名前には、新規に導入したのか、決まったものを使ったのかを括弧で添えます。複数のツールを比べて選んだ経験があれば、選んだ基準（チームの言語、保守のしやすさ、実行の速さなど）を担当内容に書くと評価されやすくなります。言語ごとの書き方はTypeScriptのスキルシートの記事やPythonのスキルシートの記事も参考になります。

層の分け方と、その理由を書く

テスト自動化の設計で最も読まれるのが、どの層で何を確かめるかの判断です。E2Eテストだけを大量に作った経歴は、実行に時間がかかり壊れやすい仕組みを作った、と受け取られることもあります。

スキルシートでは、次のように書きます。

• 層ごとの役割：「入力の組み合わせはAPIの層で、画面の流れは主要な操作だけE2Eで確かめる構成にした」
• 判断の理由：「画面の変更が多い機能は、E2Eを最小限にした」
• 開発チームとの分担：「単体テストは開発チームが書き、自分は結合の層と共通部品を担当した」

層の分け方の考え方そのものはテスト自動化エンジニアのスキルの記事にまとめています。スキルシートには、自分がその判断にどう関わったかを書くことに集中しましょう。

数字は「自動化率」より「速さ」と「安定」で書く

テスト自動化の成果を数字で示したいとき、「自動化率○%」と書く方が多くいます。ただ、自動化率は、何を分母にするかで大きく変わり、読み手には良し悪しが判断できません。数字だけが高くても、信頼されずに使われていない仕組みもあります。

成果の欄には、次のような観点で書くほうが伝わります。

• 速さ：CIでのテストの実行時間を、並列化や層の見直しで短くした
• 安定：失敗の原因がテスト側にある「不安定なテスト」を減らした
• 使われ方：開発者が変更のたびに結果を見て判断する状態になった
• 手間：リリースの前の手動の確認の作業を減らした

数字を書いてよいと確認できた場合も、「実行時間を半分程度に」のように相対で書くと、守秘義務に触れにくくなります。書かないほうがよい数字の考え方はスキルシートに書いてよいこと・いけないことをご覧ください。

公開しているコードの扱い

テスト自動化の分野では、公開しているテストコードや、共通部品のサンプルが、実力を示す材料になります。書くときは、次の点に気をつけます。

• 参画先のテストコードや共通部品を、個人のリポジトリに置かない
• 参画先の画面や接続先が分かる設定ファイルを、公開しない
• 公開するものは、架空の対象や公開されている練習用のサイトで作り直す

スキルシートには、実務の欄とは分けて「公開しているコード」として場所を書き、何を示すためのものか（ページの部品の分け方、待ち方の工夫など）を1行で添えます。テストコードの権利は、契約によって扱いが違うため、気になる場合は契約の内容を確かめてください。

プロジェクト欄の記入例

以下は書き方を示すための例で、実在の案件や実績ではありません。業界や規模はぼかしています。

期間：20XX年X月〜20XX年X月（1年）
案件概要：EC事業者向け 会員向けWebサービスのテスト自動化の立て直し
規模・立場：QAチーム4名、開発チーム十数名（自分は自動化の担当。後半は自動化の方針のとりまとめ）
局面：立て直し、その後の拡充
使用技術：TypeScript、ブラウザ操作の自動化ツール（別のツールから移行）、APIのテストの枠組み、CIのサービス、コンテナ
層の分け方：画面の流れは主要な購入と会員登録の操作に絞り、入力の組み合わせはAPIの層へ移した
担当内容：失敗の多いテストの原因を調べ、待ち方の問題、テストデータの共有、環境の不安定さに分けて対処した。消すテストと直すテストを開発チームと合意した
工夫・成果：テストデータをテストごとに作って消す形に変え、並列での実行を可能にした。失敗したテストの画面の記録を残し、原因の調査にかかる時間を短くした

「消すテストと直すテストを開発チームと合意した」の1行で、テストを信頼される状態に戻すために関係者と調整したことが伝わります。

QAの経験とのつなげ方

手動のテストやQAの仕事から自動化に広げてきた方は、その経緯がスキルシートの強みになります。何を自動化すべきかを判断するには、テストの観点を考えた経験が欠かせないためです。

• 要約で「テストの設計の経験をもとに、自動化の対象を選べる」ことを示す
• QAの経歴は短くまとめ、自動化の対象を選んだ場面と結びつけて書く
• 開発の経験がある方は、テストコードの設計（部品の分け方、レビューの受け方）を厚く書く

QAの仕事が中心の案件にも応募する場合は、シートを分けて、QAエンジニアのスキルシートの記事の書き方を参考にしてください。CIやインフラの改善に軸を広げたい方は、SREのスキルシートの記事も参考になります。

資格の書き方

JSTQBの認定テスト技術者資格には、2026年10月時点の公式サイトで、Advanced Levelのテスト自動化エンジニアの区分が案内されています。書く場合は、区分まで含めた正式な名称と取得年月を書きます。資格がなくても参画できる案件は多いため、実務での層の分け方や改善の経験とあわせて伝えることが大切です。区分の位置づけはテスト自動化エンジニアがフリーランスになるにはで整理しています。

よくある質問

自動化の経験が短く、手動のテストの経歴が長いです。どちらを上に書けばよいですか？

応募する案件に合わせます。テスト自動化の案件に応募するなら、要約で自動化の経験と、テストの設計の経験をもとに対象を選べることを先に書きます。経歴の並びは新しい順のままでかまいません。

個人で作ったテストコードだけでも、スキルシートに書けますか？

書けます。実務の欄とは分けて、何を対象に、どんな工夫を示すために作ったかを書きましょう。待ち方の工夫や、ページの部品の分け方など、実務で問われる点を意識して作ったものは、面談での説明の材料にもなります。

性能テストやセキュリティのテストの経験も書いたほうがよいですか？

書いておくと、検討される案件の幅が広がります。ただし、機能のテストの自動化とは分けて、何を対象に、どの程度担ったかを書きます。関わりが浅い場合は「計画の支援」「結果の確認」のように、関わり方をそのまま書きましょう。