QA・テストエンジニア転職ガイド

品質の求人は、同じ「QA」でも、手順どおりに確認する人、自動で繰り返し確認する人、何を確認するかを設計する人で翌日が違います。バグをたくさん見つけた、という話より、何を合格条件にしたかが伝わる材料になります。確認できない件数は書かないでください。

手動試験

手順書や探索で画面と業務を確認します。再現手順の精度と、仕様の穴を言語化する力が問われます。

自動試験

回帰をコードやツールで回します。壊れやすい箇所の選定、実行基盤、失敗時の切り分けが仕事です。

テスト設計

何を試し、何を試さないかを決めます。境界、組み合わせ、リスク、終了条件が成果物になります。

SDET

Software Development Engineer in Test と呼ばれる求人では、試験をプロダクトの一部として実装する比重が高いことがあります。会社によって定義は違います。

厚生労働省の職業情報提供サイト（job tag）では、IT・通信の仕事の中でテストエンジニアが、システム開発の他職種とは別に整理され得ます。求人サイトの「QA」「品質保証」「テスター」は、この分類と一致しないことがあります。応募時は、公的分類名より、その会社の成果物と権限を優先してください。

SDET求人は、自動試験の実装、テスト容易性の提案、CIへの組み込みが中心になりやすいです。QA求人は、リスクの説明、探索、リリース会議、プロセス改善が中心になりやすいです。どちらが上ということはなく、成果物が違います。年収との関係は企業ごとに異なるため書きません。

• 開発出身の活かし方

  再現しやすい最小コード、ログの読み方、修正案の現実味が強みです。テストを軽視していた、という自己否定は不要です。

• 手動中心の活かし方

  業務フローの抜け、用語の揺れ、例外操作が強みです。自動へ移るなら、何を自動化しないかの判断も話します。

• マネジメント志向

  人数を持つことが品質の仕事のゴールではありません。専門職の等級があるかは面談で確認します。

• ドメイン知識

  決済、医療、業務システムなど、試し方の制約がドメインで変わります。業界名だけで専門性を名乗らないでください。

品質求人は、ツール名と「品質向上」という言葉が多くなります。ツールは入口です。見るべきは、誰がリリースを止められるか、自動の失敗を誰が直すか、設計書の更新義務があるかです。

• 試験対象（Web、API、モバイル、業務）が書いてある
• 環境（専用、本番相当、データマスキング）が分かる、または面談で確認できる
• バグ票の定義と、重複の扱いが空欄のままになっていない
• 「品質向上」だけで工程も権限も書いていない求人は詳細を確認する
• 最新の勤務条件は求人票と公式サイトで確認する

見つけた不具合の件数は、報告ルールが会社ごとに違うため比較になりません。再現手順、影響、見逃しの理由、次に変えた設計の方が、転職先では使えます。

1. 01
   対象プロダクトを1つ書く

   誰が使い、何が止まると困るか。ユーザー数は根拠があるものだけです。分からなければ書きません。

2. 02
   合格条件を一文にする

   何が満たされたら出荷したかを書きます。「重大バグがない」だけでは定義が足りません。重大の決め方を添えます。

3. 03
   見逃した話を1件用意する

   本番や次工程で見つかったものを、非難せず時系列で話します。再発防止が手順か自動か設計かを分けます。

4. 04
   自分で決めた範囲を分ける

   項目の追加、自動化対象、リリース延期の進言のうち、自分が判断したことだけを強調します。

全部自動、は通常は現実的ではありません。変わる画面、探索が要る業務、データ依存の確認は、手動や設計の方が安いことがあります。面接では自動化率を創作せず、何を自動にし、何を人の目に残したかを話します。

品質の求人は、事業会社、受託検証、開発会社のQA室、コンサルに分散します。1社の提案だけで市場を判断しない方が安全です。開発に近い相談と、検証プロセスに近い相談を併用すると、SDETと実行中心の差が見えます。

• IT領域に詳しいサービスで技術と工程を確認する
• 同じ求人の重複応募が起きないよう一覧を作る
• 最新の募集条件は各公式サイトと面談で確認する

• 件数で勝負する

  報告ルールが違う会社間では比較になりません。再現と影響を話します。

• 開発を敵にする話し方

  品質は対立ではなく、出荷判断の共同作業です。衝突のエピソードは事実と合意形成に限定します。

• ツール信仰

  特定製品が使えない環境でも、設計と記録は転用できます。製品名だけに依存しないでください。

• 希望職種を広げすぎる

  QAもSDETも開発も全部希望にすると、提案が散らばります。今回の軸は1つにします。

見逃しは能力不足の証明ではありません。どこで終了条件が甘かったかを言語化できる人が、品質の仕事では早く信頼されます。確認できない市場のバグ統計は使わないでください。

テスト容易性が低いコードに、後から自動を足すのは高いことがあります。境界を嫌うより、設計レビューで何を頼むかを具体化した方が機能します。次の一手は、必ずしも開発職への転向ではありません。性能、セキュリティ試験、品質マネジメント、プラットフォームの試験基盤など、品質側で深める道もあります。

終了条件

いつ試験を終えるか。消化率ではなく、残リスクと未実施の理由が残っているかが実務的です。

リリース判定

出す・出さないを誰が決めるか。QAが止める権限を持つか、意見だけかは求人で差が大きいです。

テスト容易性

境目、待ち、データ、ログが試験しやすいか。開発への提案材料になります。

評価制度は会社によります。人数を持つことが昇格条件の会社も、専門職の等級がある会社もあります。求人票の等級名だけで判断せず、評価項目を面談で確認してください。

探索的テストは、時間を区切って疑う視点を変える仕事です。漫然と触る時間ではありません。終了条件は、消化率ではなく、残リスクと未実施の理由が残っているかが実務的です。面接では、何を疑ったかと、なぜそこで止めたかをセットで話してください。自動化率やバグ件数は、定義が会社ごとに違うため比較になりません。

SDETを希望するなら、探索の記録をコードやCIにどう戻したかを厚くします。QAを希望するなら、出荷判断の会議で何を根拠にしたかを厚くします。両方を同じ分量で書くと、提案が散らばります。今回の応募軸は1つにします。手動中心から移る人は、再現手順の精度と終了条件の決め方を先に書き、ツール名は後段に置いてください。確認できないバグ件数は使わず、最新の応募条件は公式サイトでご確認ください。

品質の経歴は、バグ件数より先に合格条件を置きます。何をもって出荷したか、誰が止める権限を持っていたかが分からないと、手動とSDETのどちらに近いか判断できません。厚生労働省の職業情報ではテストエンジニアが別に整理され得るため、会社の用語だけに合わせず、成果物を先に書いてください。

1. 01
   見逃しを1件、非難せず書く

   見つかった場所、影響、当時の終了条件、次に変えた手順を書きます。件数競争にしないでください。

2. 02
   コードを書く割合を数字ではなく作業で書く

   フレームワークを実装したのか、シナリオを増やしただけなのかを分けます。SDET希望なら実装の話を厚くします。

3. 03
   権限を一文にする

   リリースを止められたのか、意見だけだったのか。求人比較の軸になります。

1. 01
   対象と合格条件を1枚にする

   誰の何を、どの条件で通したかを四角で描きます。ツール名は後回しで構いません。

2. 02
   見逃しまたは延期提案を1件深掘りする

   事実、影響、自分の権限、次に変えた手順を各3行で書きます。件数は根拠がなければ書きません。

3. 03
   手動・自動・設計から希望を1つ選ぶ

   今の応募軸を1つに絞り、隣接は会話できる範囲として添えます。

4. 04
   SDETかQAかを言葉で分ける

   コードを書く割合と、出荷判定の割合を自分の希望として書きます。会社の用語に無理に合わせないでください。

5. 05
   相談先を2系統用意する

   開発に近い品質職の相談と、検証プロセス寄りの相談を分けます。条件の最終確認は公式サイトで最新情報をご確認ください。

QA・テストエンジニア転職は、華やかな自動化率より、合格条件と再現手順の話で差がつきます。何を試し、何を残し、誰が止めるか。この3点を自分の言葉で説明できると、求人比較も面接も具体になります。内定や年収の保証はありません。