QAエンジニアになるための学習ロードマップ — 何をどの順で学ぶか
2026-05-31
※ステマ規制への対応方針: 当サイトの運営にあたっては、実体験を元に公平性/客観性を心掛け、読者の皆様を第一に取り組んでいます。商品提供や広告依頼を受け、広告/PRの内容が含まれることもありますが、コンテンツの基準や判断軸には一切関与させておりません。
1. このロードマップの読み方
未経験〜浅経験の方が QAエンジニアを目指す際に、ぶつかりやすい壁の一つが「何をどの順で学べばよいか分からない」というものです。教材も書籍も豊富にある一方で、全体像が見えないと「とりあえず1冊読んでみたが、次に何をすればいいか分からない」という状態になりがちです。
この記事では、QAエンジニア採用の現場で求められる観点を踏まえて、未経験者が押さえておくと有利になる学習領域を、フェーズに分けて整理します。
先にお伝えしておきたい前提が2つあります。
- 全部を完璧に習得する必要はありません。各フェーズには「ここまで触れていれば次に進める」というゆるい合格ラインがあります。最初から100点を目指すと、いつまでも次のフェーズに進めなくなりがちです
- 学習と転職活動は別の話です。本記事は「学習面のフロー」に絞ります。1社目の選び方(テスター職/教育付きSES/自社開発QA の使い分け)については 未経験からQAエンジニアになる3つのルート を別途お読みください
それでは、全体マップから順に見ていきます。
2. 全体マップ:5つのフェーズで俯瞰する
QAエンジニアになるための学習領域は、おおまかに次の5フェーズに整理できます。
| フェーズ | 領域 | 期間の目安(あくまで一例) |
|---|---|---|
| Phase 0 | QAエンジニアという職種の理解 | 数時間〜数日 |
| Phase 1 | ソフトウェアテストの基礎技法 | 2〜4週間 |
| Phase 2 | Web/ソフトウェアの仕組み | 3〜6週間 |
| Phase 3 | テスト自動化の入り口 | 1〜3週間 |
| Phase 4 | ポートフォリオを1つ作る | 2〜4週間 |
期間は本業や家庭の状況、学習に充てられる時間によって大きく前後します。「平日1時間・土日3時間ペース」を1つの目安として置いていますが、自分のペースに置き換えてください。
各フェーズの位置づけを、ざっくり次のように整理しておきます。
- Phase 0〜2 は「実務に入る前に最低限触れておくと差別化されやすい」レイヤー
- Phase 3〜4 は「触れていると応募時の評価が一段上がる」レイヤー
Phase 0〜2 を一通り押さえた段階で動き出しても遅すぎることはなく、Phase 3〜4 は時間に余裕があれば積み増す、というイメージで構いません。
3. Phase 0:QAエンジニアという職種を知る
最初のフェーズは、職種そのものの理解です。
「QAエンジニア」と「テスター」では、求人票での扱われ方も、現場で期待される役割も異なります。テスト戦略の立案・テスト設計・自動化基盤の整備・開発プロセスへの品質観点の組み込み——QAエンジニアという職種が扱う領域は、職種名のイメージより広く、入社後の伸び方もここに依存します。
この職種の全体像は別記事で詳しく扱っているので、まだ読まれていない方は先にこちらに目を通してみてください。
→ QAエンジニアとは何か — 仕事内容・テスターとの違い・必要とされる理由
3.1 動画で仕事を疑似体験する
文章で職種を理解した上で、「実際の作業感覚を掴んでみたい」と感じる方は、動画で擬似体験する選択肢もあります。qa-dojo では、バグの混じった EC サイトを操作しながら QAエンジニアの仕事を体験できる動画講座を Udemy で公開しています。
→ はじめての QA エンジニア入門(Udemy 講座の紹介ページ)
Phase 0 の合格ライン:「QAエンジニアとテスターの役割の違い」「QAエンジニアが扱う領域」を、自分の言葉で他人に説明できる。
4. Phase 1:ソフトウェアテストの基礎技法
職種の輪郭が見えたら、次はソフトウェアテストの基礎技法を押さえます。
4.1 なぜ「技法」から学ぶのか
テスト設計の現場では、「思いついたケースをひたすら書き出す」のではなく、入力空間や状態空間を整理して、限られた時間で重要なリスクを押さえるという発想が前提になります。この発想を支えるのが、ソフトウェアテストの基礎技法です。
技法を知らないままテストケースを書き始めると、「同じ性質のテストを似たような条件で何度も書いてしまう」「重要な境目のテストが抜ける」といったことが起こりやすくなります。逆に、技法の意図を理解した上でテストを設計すると、ケースの数を絞りつつ重要なリスクを押さえる組み立てができるようになります。
4.2 まず触れるべき4つの技法
| 技法 | 概要 |
|---|---|
| 同値分割 | 同じ性質を持つ入力をひとまとめにし、代表値だけテストする |
| 境界値分析 | 仕様の境目(最小値・最大値・しきい値前後)に注目する |
| 状態遷移テスト | 画面や機能の状態の組み合わせを網羅する |
| 決定表テスト | 条件と結果の対応関係を表形式で整理する |
これら4つは、未経験者向けの面接でも「同値分割って何ですか?」「境界値分析の意図は?」と聞かれることがある定番技法です。
4.3 JSTQB Foundation シラバスを土台にする
これらの技法を体系的に学ぶ際に活用したいのが、JSTQB Foundation Level シラバスです。日本語版が JSTQB 公式サイト で無料公開されており、ソフトウェアテストの用語・原則・代表的な技法が一通りまとまっています。
資格取得まで踏み込むかどうかは、目的次第です。取得しておくと「最低限の学習をしてきた」という証明にはなりますが、それだけで内定が決まるわけではないので、優先度はご自身の状況で判断してかまいません。シラバスを通読して、各技法の意図と使いどころを理解する——この水準であれば、応募時の話に十分耐えます。
Phase 1 の合格ライン:4つの技法(同値分割・境界値分析・状態遷移・決定表)の意図を、自分の言葉で説明できる。簡単な仕様書を読んで、どの技法をどこに適用するかを考えられる。
5. Phase 2:Web/ソフトウェアの仕組み
テスト技法を押さえたら、次は テスト対象の側 の理解です。
5.1 「コードを書けなくてもいい、ただし仕組みは知っておく」のレベル感
QAエンジニアの未経験採用で、応募者にいきなり Webアプリケーションを書き上げてもらうことはあまりありません。ただし、テスト設計や不具合の切り分けでは、「画面の裏側で何が起きているか」をある程度イメージできる必要があります。
たとえば、次のような問いに答えられるレベル感をイメージしてください。
- 画面の入力フォームから「登録」ボタンを押したあと、どのレイヤーを情報が通っていくのか
- データベースに保存される前に、どのような検証が走っている(はずな)のか
- API から返ってきたエラーレスポンスを、画面はどう扱っている(はずな)のか
書ける必要はないのですが、「どこで何が起きているか」をイメージできているかどうか が、テスト設計の解像度に直結します。
5.2 押さえておきたい4領域
| 領域 | ゴールライン |
|---|---|
| HTML / CSS | DevTools(ブラウザの開発者ツール)で要素を選択でき、簡単な構造を読める |
| データベース / SQL | SELECT・WHERE・JOIN の基本を読み書きできる |
| API(HTTP) | リクエスト・レスポンスの構造、ステータスコードの意味が分かる |
| Git | ブランチ・コミット・プルリクエストの基本概念を理解できる |
「読める」「分かる」レベルで十分で、自分でゼロからプロダクトを構築できる水準を目指す必要はありません。
5.3 ハンズオンで学ぶのが効率的
このレイヤーは、本を読むだけでは「分かったつもり」になりやすい領域です。実際にブラウザやコマンドラインで手を動かしながら学んだほうが、定着しやすい傾向があります。
qa-dojo では、登録不要で取り組めるハンズオン教材を用意しています。Webアプリの3層構造・DBの基礎・SQL・API までを、ブラウザだけで動かしながら学べる構成です。
ハンズオン教材を一周して、5.2 の表に書いた「ゴールライン」が一通り手を動かしてできれば、このフェーズは合格です。
Phase 2 の合格ライン:DevTools で画面の要素を確認できる。簡単な SELECT 文を書ける。API のリクエスト・レスポンスを読める。
6. Phase 3:テスト自動化の入り口
ここから先は「触れていると応募時の評価が一段上がる」レイヤーです。
6.1 自動化ツールはどれか1つを触ってみる
ブラウザ操作の自動化ツールには、いくつか選択肢があります。代表的なものとして次のようなものがあります。
- Selenium:歴史が長く、求人票でも頻出。学習リソースが豊富
- Playwright:比較的新しいツール。書きやすさと安定性で支持を集めている
- Cypress:フロントエンド開発者と相性が良い
未経験段階では、どれか1つを選んで「ローカルで動かせる」状態にすることを目指します。複数を比較して使い分ける段階は、業務で必要が出てきてからで十分です。
6.2 ゴールライン:自分のPCで、簡単なテストが動く
自動化のフレームワーク全体を理解する必要はありません。
- 公式チュートリアルに従って環境構築できる
- ログイン → 何かを操作する → 結果を検証する、までの簡単なシナリオが動く
- テストが失敗したとき、ログやスクリーンショットから原因を推測できる
ここまでできれば、面接で「自動化を触ったことはありますか?」と聞かれたときに、具体的な経験として話せます。
Phase 3 の合格ライン:選んだ自動化ツールで、簡単なテストシナリオがローカルで動く。
7. Phase 4:ポートフォリオを1つ作る
最後のフェーズは、ここまでに学んだことを 目に見える形 にする段階です。
7.1 未経験者にとってポートフォリオが効きやすい理由
採用する側から見たとき、未経験者の応募書類は「学習履歴の自己申告」がほとんどです。「Udemy のコースを修了しました」「ソフトウェアテストの本を読みました」と書かれていても、それがどの程度実務に近いところまで届いているかは、書類だけでは判別がつきません。
ここで、自分なりに手を動かした成果物を1つ持っているかどうかで、書類選考や1次面接の印象が変わってきます。「学んだことを手元で実際に試している」という事実そのもの が、評価の差を生みやすいポイントです。
7.2 ポートフォリオの3段階
難易度順に3段階で書きます。全部やる必要はなく、★ ひとつでも十分な差別化材料になります。
★ 既存のWebサービスに対してテスト設計をする
身近に使っている Webサービス(予約サイト、SaaS のフリープランなど)を題材に、テスト観点とテストケースをまとめます。
大事なのは、テストケースの一覧を作ることそのものではなく、「なぜこのテスト設計にしたのか」を論理的に説明できること です。
- このサービスのどの機能に注目し、なぜそれを選んだのか
- どんなリスクを想定して、どこにテストの重みを置いたのか
- どの技法(Phase 1 で学んだもの)を、どこに適用したのか
これが説明できれば、面接で「テスト設計の思考プロセスを持っている方だ」と評価されやすくなります。
★★ 自分で簡単な Webアプリを作り、それに対してテスト設計・実行する
ハードルは上がりますが、Phase 2 のハンズオンを経験したあとなら、生成AIツール(ChatGPT・Claude など)を補助に使えば、シンプルな Webアプリを組み上げることは現実的な選択肢になっています。ローカル環境で動くもので十分です。
自分で作ったアプリに対してテスト設計をすると、「開発側の事情も踏まえてテストを設計できる」という評価につながりやすくなります。テスト対象の内部構造を理解した上で観点を立てられる、というのは現場でも歓迎されやすい姿勢です。
★★★ ★★ にテスト自動化(Phase 3 の応用)を加える
自分で作ったアプリに対して、Selenium または Playwright で自動化スクリプトを書きます。ここまでやれば、未経験とは思えない水準の成果物になります。
繰り返しになりますが、ここまで踏み込まなくても ★ だけで十分に差別化はできます。「やれそうなところから1つ」で始めるのが現実的です。
Phase 4 の合格ライン:★ のテスト設計成果物(テスト観点・テストケース・設計判断の理由)が1つ、誰かに見せられる状態になっている。
8. 同じ時間を使うなら:30日アクションプラン
ここまでの5フェーズを、自分でスケジュールに落とすのが難しいと感じる方もいるかもしれません。「Phase 1 を何日でやって、Phase 2 はどこから手を付けて……」という日単位の組み立ては、独学だと意外と詰まりがちです。
qa-dojo では、本記事のフェーズを 1日単位のアクションに落とし込んだ「QAエンジニア 30日アクションプラン」PDF を、無料で配布しています。受け取るとそのまま Day 1 から動き始められる構成です。
→ QAエンジニア 30日アクションプラン PDF(無料・ニュースレター登録で受け取る)
教材は道具で、ゴールは「QAエンジニアになること」です。同じ時間を使うなら、もう少しゴールに直接向かう走り方があるかもしれません。日割りで道筋が見えていたほうが動きやすそうだと感じる方は、検討してみてください。
9. 学習と並行して「1社目」をどう取るか
学習を進めるのと並行して、いずれ向き合うことになるのが「最初の1社をどうやって取るか」という選択です。
未経験から QAエンジニアになる現実的なルートは、大きく次の3つに分けられます。
- ルートA:自社開発企業の QAエンジニア職に直接応募する
- ルートB:テスター職(派遣・契約・正社員)から実務に入る
- ルートC:教育付き SES の研修プログラムを経由して現場に出る
それぞれに、応募ハードル・成長スピード・キャリアの選択肢のトレードオフがあります。ご自身の状況(独学を続けられるか/早く現場に入りたいか/研修付きで底上げしたいか)によって、どのルートが近いかは変わります。
3つのルートの構造的な違いと、どれが今の自分に近いかの判断軸は、別記事にまとめています。
学習を進めながら、1社目のルートも並行して検討しておくと、いざ応募の段階に来たときに迷いが少なくなります。
10. まとめ
ここまで、QAエンジニアになるための学習領域を5つのフェーズに分けて整理しました。
- Phase 0:QAエンジニアという職種そのものを理解する(→ QAエンジニアとは何か)
- Phase 1:ソフトウェアテストの基礎技法(同値分割・境界値分析・状態遷移・決定表)を JSTQB Foundation シラバスで押さえる
- Phase 2:HTML/CSS・DB/SQL・API・Git の仕組みを、手を動かしながら読めるレベルにする(→ ハンズオン教材)
- Phase 3:Selenium または Playwright で簡単なテストシナリオを動かしてみる
- Phase 4:テスト設計のポートフォリオを1つ作って、誰かに見せられる状態にする
全部を完璧に習得する必要はなく、各フェーズの「合格ライン」を一通りクリアした段階で次に進む——というイメージで進めてみてください。
学習だけで半年・1年が過ぎてしまう前に、いま自分はどのフェーズにいて、次の一歩がどこにあるか。いったん立ち止まって振り返ってみる価値はあると思います。