手動テスト面接の質問：実践的な回答10選

まずはこの10の質問から始め、正直に説明できる仕事に合わせて回答例を調整しましょう。ソフトウェアテスト職の面接質問には、要件、入力、期待結果、選択理由を結び付けて答えます。

1. 数量フィールドをどうテストしますか？

回答例：「許容値と送信時の動作を確認してから、受け入れられる数量、拒否される数量、境界値をテストします。整数の範囲が1～10なら、期待結果を明確にしたうえで、0、1、10、11を含めます。」

2. 同値分割と境界値分析はどう違いますか？

「同値分割では、同様に扱われると予想される入力をグループに分けます。境界値分析では、順序のある分割の境界を狙います。数量なら、通常の有効値として5を選び、1と10の前後で受け入れ可否がどう変わるかを確認します。」

3. テストケースには何を含めますか？

「別のテスターが同じ確認を繰り返せるだけの情報が必要です。購入手続きなら、開始時のカート、アカウントの状態、数量、操作、期待する注文合計を指定し、テストしたビルドで観測した結果を記録します。」

4. 相互に関係するビジネスルールをどうテストしますか？

「組み合わせを選ぶ前に、条件と期待される動作を列挙します。購入手続きに在庫と承認済みの決済が必要なら、両方の条件を組み合わせて確認します。在庫がある商品に対して決済が拒否されるケースも含めます。」

5. 状態が重要になるのはどんなときですか？

「同じ操作を、開始時の状態を変えてテストします。購入可能なカートから注文を送信するのは有効かもしれません。一方、決済処理中に再度送信した場合は、合意した二重送信のルールに従うべきです。」

6. バグ修正後は何をテストしますか？

「確認テストでは修正を確かめ、回帰テストでは他の箇所に悪影響がないか確認します。数量10が拒否される問題を修正した後は、その失敗を再実行し、変更内容に応じて近い数量や購入手続きも確認します。」

7. 断続的に起きる失敗をどう報告しますか？

「条件、試行回数、時刻、証拠を記録します。10回の試行で購入手続きが2回失敗したなら、その観測結果を報告し、成功したときと失敗したときの手順を残します。原因の推測を確定した事実のようには示しません。」

8. 重大度と優先度はどう違いますか？

「重大度は影響の大きさ、優先度は修正する時期に関係します。影響を受ける購入の流れと利用できる回避策を説明し、最初に付けた評価を最終判断とせず、チームと修正時期を相談します。」

9. 要件が曖昧な場合はどうしますか？

「具体的に質問します。たとえば、2.0を入力した場合も整数の数量として扱うのでしょうか。合意した解釈を記録してテストの期待結果に使い、自分の好みで動作をひそかに決めることはしません。」

10. 時間が足りない場合はどうしますか？

「購入を妨げたり誤請求につながったりする失敗から確認し、未テストの範囲を説明します。進捗報告には、テストしたビルド、結果、未確認事項、推奨事項を挙げ、リリース責任者が判断できるようにします。」

テスト技法の名前を挙げる前に、範囲を観測可能な動作に置き換えましょう。要件の例：必須の数量フィールドでは、1から10までの整数を両端を含めて受け付けます。有効な値を送信すると、その数量が正確にカートへ追加されます。無効な値を送信すると、数量のバリデーションメッセージが表示され、カートは変わりません。各ケースの前に在庫は十分あり、カートは空だと仮定します。

この演習では、空欄、1.5のような小数、「二」のような文字列は拒否されると合意してください。2.0、先頭にゼロを付けた値、前後に空白がある値を受け付けるかどうかは、別途、書式のルールが必要です。こうした選択を、整数範囲の要件に含まれるものとしてひそかに扱わないでください。

数値を3つの同値分割に分けます。1未満の整数、1から10までの整数、10を超える整数です。代表値を選び、その後、受け入れ可否が変わる境界に注目します。次の表では、範囲内の値、境界の確認、入力形式の確認を組み合わせています。

回答例：「カートをリセットして10を入力し、1回送信して、商品が10個入っていることを確認します。次にもう一度リセットして11を試し、バリデーションが表示され、カートが変わらないことを期待します。これで、画面に表示された値と更新成功を混同せずに、上限の受け入れ境界を確認できます。」

画面で文字を入力できない場合は、その動作を記録し、サポートされている操作経路をテストしてください。入力できなかった値を送信したとは主張しないでください。面接官が在庫を8個に変更した場合は、いったん止めて、在庫ルールと数量上限がどう関係するのか確認します。

用語は、Foundation Levelシラバスチームが作成したISTQB CTFL v4.0.1シラバスに従っています。ここではISTQBとシラバスの著者を出典および著作権者として明記します。このガイドの要件と回答は、面接用の例です。

結果を決める条件と、そこに至るまでの順序を分けて考えます。仮定の例：カートには有効な商品が1つあります。在庫は決済より先に確認します。在庫がある場合に限り決済を要求します。注文は決済が承認された後にのみ確定します。決済が拒否された場合、再試行できるようカートは利用可能なままです。

簡潔な決定表では、決済が実行されない場合に「未要求」と記します。実現不可能な組み合わせにもテスト結果が必要だと思わせずに済みます。

次に、状態を説明します。「準備完了」「決済処理中」「決済失敗」「確定済み」です。「準備完了 → 決済処理中 → 決済失敗 → 決済処理中 → 確定済み」の順にたどります。各段階で、表示される状態と注文が存在するかを確認します。

決済処理中の2回目のクリックには、個別のルールが必要です。合意した動作は、処理中であることを表示しながら二重送信を無視するものと仮定します。期待結果は、決済の試行が1回で、最終的な注文が1件になることです。2件ではありません。提供されたテスト環境でその結果を確認するために必要な証拠を説明してください。ボタンが無効になったことだけでは、後続処理で何が起きたかは分かりません。

ソフトウェアテスト職の面接質問に答えるときは、この依存関係を明確にしましょう。条件表は選択肢を整理し、状態の順序は先行するイベントに依存する動作を明らかにします。結果をバグと判断する前に、再試行と二重送信に関する期待を面接官に確認してください。

まず元の失敗を挙げ、次に変更の影響が広がる可能性を説明します。例：要件では許容されているのに、ビルドQ-17は数量10を拒否します。ビルドQ-18には修正が含まれています。記録した手順を同じ開始条件でQ-18上で繰り返し、エラーメッセージが消えただけでなく、カートの結果も確認します。

次に、範囲を絞った回帰テストを選びます。

• 受け入れられる端点として1と10を、拒否される隣接値として0と11を確認します。
• 端点だけを誤って受け入れる修正になっていないか、5を確認します。
• 既存のカート行の数量を9から10に変更し、数量と合計を確認します。
• カート行を削除してから再追加し、関連するカートの操作経路を確認します。
• 合意した購入手続きを数量10で完了し、注文の数量を確認します。

開発者がカート編集と共有するバリデーターを変更した場合は、その操作経路にも注意が必要です。変更範囲が限られているなら、失敗の影響を考慮したうえで、より小さなテスト選択について相談します。チケットのタイトルから推測せず、変更されたコンポーネントを確認してください。

各確認の結果を記録し、修正とビルドに関連付けます。数量10が動作するようになっても11まで成功するなら、新たな失敗として報告します。元の症状が消えたことだけでは、すべてのテストを終了する根拠になりません。回答の最後に、残っている範囲と、実行できなかった確認を述べます。

面接官に、チームメンバーへそのまま渡せる報告例を示しましょう。バグ報告の例：数量の要件は引き続き1～10の両端を含みますが、テスト環境では上限値が拒否されます。以下の識別子と観測内容は、この例に固有のものです。

ID：QTY-24
タイトル：在庫のある商品の追加時に数量10が拒否される
観測日：2026-11-05
報告者：Alex、手動テスター
状態：未対応
ビルド：Q-17
環境：QAストアフロント、デスクトップブラウザー。正確なバージョンは添付
参照：要件QTY-01、テストケースQTY-BOUNDARY-10
前提条件：空のカート、サインイン済みテストアカウント、商品在庫20個
データ：数量10、商品TEST-MUG

手順：
1. TEST-MUGの商品ページを開く。
2. 数量に10を入力する。
3. 「カートに追加」を1回選択する。
4. バリデーションメッセージとカートを確認する。

期待結果：数量のバリデーションエラーは表示されず、カートにTEST-MUGが10個入る。
実際の結果：数量のバリデーションエラーが表示され、カートは空のまま。
再現状況：カートを毎回リセットして3回試行し、3回とも失敗。
影響：顧客は、許可された最大数量を1回の操作で追加できない。
確認した回避策：5個ずつ2回追加すると、カート内の数量は10個になる。
重大度の提案：このチームの影響度尺度では「中」。
優先度の提案：まとめ買いプロモーション前のトリアージで検討。
証拠：メッセージのスクリーンショット、セッション録画、時刻を添付。

実際の報告では、環境の仮置き情報を置き換え、参照した証拠を添付してください。アカウント情報や録画は、チームの取り扱いルールに沿って管理します。原因の推測は分けて記載します。「上限値の比較に問題がある可能性」は調査の手がかりであり、観測結果ではありません。

影響と修正時期は、状況を踏まえて話し合います。回避策は当面の支障を軽減するかもしれませんが、予定されているプロモーションによって修正の緊急性が高まる可能性もあります。チームによって評価ラベルは異なるかもしれません。顧客への影響と時期を先に説明し、次に自チームの尺度へ当てはめます。開発者が再現できない場合は、チケットの状態を変える前に、ビルド、データ、アカウント、手順をまとめて比較します。

不確実な点を、具体的な判断を求める質問に変えます。例：「チケットには顧客が決済を再試行できるとありますが、決済が拒否された後もカートの在庫予約が維持されるかは書かれていません。再試行時に在庫を再確認しますか？」回答を要件の横に記録し、期待結果を更新します。それまでは、その期待を解決済みとして扱わず、未確定と記録します。

期限がある場合は、想定される損害と影響を受ける機能に沿って順番を提案します。購入手続きの例なら、注文の作成、決済失敗、二重送信、数量の合計を先に確認します。時間が残れば、影響の小さい表示上の細部を確認します。設定の依存関係が高リスクの確認を妨げる場合は、役立つ独立したテストを進めながら、その阻害要因を報告します。

簡潔なリリース報告は、何をテストしたか、何が起きたか、何が不明か、どんな判断が必要かの4点で構成します。

例：「Q-18では、受け入れられる数量と拒否される数量の確認に合格し、決済が承認された購入手続き1件で期待どおりの注文が作成されました。テスト用決済の設定が利用できないため、決済拒否後の再試行は実行できていません。リリース前に設定を復旧し、再試行を確認することを推奨します。今リリースする場合、再試行の経路はリリース責任者が受け入れるべき明示的なリスクとして残ります。」

「実行した確認で失敗がなかった」を「システムにバグはない」に置き換えないでください。合格、失敗、実行不可、未実施の確認を区別します。意見の相違に関するソフトウェアテスト職の面接質問では、開発者と証拠を照らし合わせ、未解決のビジネス上の動作を適切な判断者に確認する方法を説明します。最後に、不足している設定の手配や再試行ルールの明確化など、実務的な次の行動を示します。

SayNow AIを使って、テストに関する判断を明確に話す練習をしましょう。AI模擬面接では、質問と追加質問を含む音声での会話ができ、その後、流暢さ、内容の構成、シナリオへの適合度、目標達成度についてスコアと提案を受け取れます。

このガイドから技術的な確認を済ませた例を1つ準備してから、就職面接のシナリオを開きましょう。口頭での回答では、まず判断を伝え、関係する要件を説明し、期待結果を示します。過去の経験、たとえば意見が分かれたバグの調査にはSTARを使います。会話で曖昧な点を掘り下げられたら、話を最初からやり直さず、質問に直接答えましょう。

練習後は、フィードバックから変更点を1つ選びます。期待結果を先に述べる、背景説明を短くする、または自分自身の行動をより明確にする、といった変更です。その点を意識してもう一度練習しましょう。SayNow AIは技術的な正しさを確認しません。要件を基準にし、知識のあるテスターにも相談して、自分のテスト判断を別途見直してください。話し方のスコアは、あくまで練習のためのフィードバックとして受け止めましょう。

就職面接のシナリオで回答を練習する。

すべての文を暗記するのではなく、条件を変えて最後の練習を1回行います。練習相手に、数量の上限を変える、回避策をなくす、または報告した失敗を裏付ける証拠は何か質問してもらいます。あなたはテストの期待結果を調整し、その影響を説明します。

このチェックリストで回答を見直しましょう。

• 聞き手は要件と前提条件を把握できますか？
• 具体的なテストデータと、観測できる期待結果を示しましたか？
• 記載した開始条件から、別の人がバグ報告を再現できますか？
• 変更後に選んだテストがなぜ重要か説明しましたか？
• 観測した結果、原因の推測、未解決の質問を分けましたか？
• 次の行動と、その情報を必要とする人を示しましたか？

ソフトウェアテスト職の面接質問に備えるなら、技術的な例と合わせて、プロジェクトでの経験を1つ用意します。自分が担当したことと、実際に観測した結果を説明してください。関連する行動面接ガイドやSTARガイドを使うと、話の焦点を保てます。

手動テスト職の面接質問に対するよい回答は、明確な要件を、意図を持った入力、期待結果、根拠のある次の判断に結び付けます。数量の例を練習し、正直に話せる経験に合わせてバグ報告を調整し、選んだ確認の後にも残るリスクを説明しましょう。