QEインターンの面接で聞かれること：練習用の面接 質問と初学者向け回答

小さく、理由を説明できるテスト上の判断を示せる面接 質問から練習しましょう。定義を長々と暗記するのではなく、以下の問いから始めます。それぞれについて、最初に簡潔に答え、具体例を1つ用意してください。

要件と期待される動作

• 登録フォームをテストする前に、何を質問しますか？
• 要件に「有効なパスワードを受け付ける」としか書かれていなかったら、どう進めますか？
• 文書に書かれた要件と画面の例が食い違っていたら、どうしますか？

テスト案と優先順位

• 簡単なフォームでは、どの確認を先に行いますか？その理由は何ですか？
• 明記された入力上限の近くで、どのような例を選びますか？
• 確認に2つしか時間を使えない場合、何を優先しますか？

再現と報告

• チームメイトが、送信ボタンは時々動かないと言っています。どの情報を求めますか？
• ほかの人が手順を追える報告を、どう書きますか？
• 自分の端末では問題が起きなかった場合、何と伝えますか？

協力と学習

• プロジェクトチームで予想外の動作を見つけた経験を教えてください。
• それがバグかどうかで意見が分かれたら、どう対応しますか？
• 使ったことのないテストツールを、どうやって学びますか？

最初の練習では、各グループから1つずつ問いを選びましょう。専門用語を加える前に、聞かれたことに答えてください。たとえば優先順位について聞かれたら、考えられる入力を列挙するだけでなく、最初の確認を選ぶ理由が必要です。

求人票に特定のコーディング作業やツールが挙げられている場合は、それらを別に準備してください。より広い内容を扱うエンジニアリング職インターン面接ガイドも、その準備に役立ちます。このガイドではソフトウェア品質に関する作業の説明に焦点を当てます。最初の練習を終えたら、例をもっと明確にする必要がある回答に印を付けましょう。

よい初学者の回答は、状況を述べ、自分がしたことを説明し、観察したことか妥当な次のステップで締めくくります。本番環境で起きた障害について説明する必要はありません。以下の2つの例では、限られた経験を具体的なテスト作業に結び付ける方法を示します。

例：授業課題での貢献を説明する

質問：「プロジェクトの品質確認を手伝った経験を教えてください。」

「授業のプロジェクトで、私たちのグループはタスクリストを作りました。私は編集の流れを確認する担当でした。チームメイトと期待される動作を書き出し、タスク名の変更、空欄にする操作、編集のキャンセルを試しました。キャンセルしても表示名が変わることに気付きました。手順を記録し、キャンセルと保存の違いを示しました。チームメイトが編集処理を変更し、私は同じ確認を繰り返しました。そのバージョンでは、キャンセルすると元の名前が保たれました。次に、ほかの編集可能な項目も同じように動作するか確認したいです。」

範囲に注目してください。話し手は、自分の貢献を1つ、観察した結果を1つ挙げています。アプリケーション全体をテストしたとは主張していません。実際に自分が行った作業に合わせて、この構成を応用しましょう。STARメソッドは経験についての回答を整理するのに役立ちますが、行動の説明は自分の役割に即した具体的なものにしてください。

例：登録フォームについて考えを声に出して説明する

質問：「この登録フォームをどうテストしますか？」

「まず、登録が成功したと判断する条件と、必須項目を確認します。合意したルールが、パスワードは8文字以上というものだとします。ほかの情報は有効にしたまま、まず8文字のパスワードを試し、次に7文字の場合と比べます。画面が変わったかだけで判断せず、メッセージとアカウントが作成されたかを確認します。すでに登録済みのメールアドレスを使った場合にどうなるべきかも質問します。時間が限られていたら、主な登録の流れと必須項目の確認を優先し、未確認の項目を説明します。」

前提は例を挙げる前に明示しているので、面接官はそれを変更できます。「なぜ8文字なのですか？」と聞かれたら、普遍的なパスワード規則だからではなく、仮定した要件に基づくと答えましょう。回答全体を最初からやり直さずに、この追加質問に答える練習をしてください。

まず期待される動作を確認し、面接官が続けるよう求める場合は、一時的な前提を明示します。「すべてテストします」では、何から始めるのか分かりません。理由を添えた小さな例なら、話し合いや修正がしやすくなります。

「ユーザー名欄をテストしてください」のような問いには、以下の順序を使いましょう。これは問題について口頭で考えを説明するための例であり、技術的なテスト項目を網羅するものではありません。

予想外の結果を、実際に見ていない人にも理解できるよう伝える機会になります。原因を提案する前に、操作、期待される動作、実際に観察した動作を述べましょう。

バグ報告の文脈でバグを登録するために書かれたMozillaのバグ報告ガイドは、正確な再現手順、期待される結果と実際の結果を示し、観察と推測を分けることを勧めています。この面接課題にも、その報告の原則を活用しましょう。

例：タスク編集の報告

タイトル：タスク名の編集をキャンセルすると、表示名が変わる
状況：授業のタスクリストプロジェクト、確認中のバージョン
開始状態：「第2章を読む」というタスクがある
手順：
1. そのタスクの編集フォームを開く。
2. 名前を「第3章を読む」に変更する。
3. 「キャンセル」を選択する。
期待される結果：タスクには「第2章を読む」と表示される。
実際の結果：タスクには「第3章を読む」と表示される。
観察した範囲：上記の手順の後、このセッションで確認。
未確認：ページを開き直した後も変更が残るかどうか。

期待の根拠を説明しましょう。この課題では、保存していない編集は「キャンセル」によって破棄されるとチームで合意しています。その合意がなければ、要件違反と判断する前に、「キャンセル」がどのような動作をすべきか確認してください。

原因の推測は、観察と分けておきます。「キャンセル後に表示名が変わった」は観察です。「アプリケーションが早すぎる段階で保存した」は調査が必要な可能性のある説明です。面接官から仮説を求められたら、確認すべき仮説として提示し、それを裏付けたり否定したりする証拠も挙げましょう。

効果的な報告では、頻度について曖昧な主張を避けます。手順を一度試しただけなら、そのように伝えましょう。別の試行で動作が異なった場合は、その違いと関連する条件を記録します。調査していない修正を約束するのではなく、ページを開き直すなど次に役立つ確認を提案して回答を締めくくりましょう。

試したことを説明し、不足している状況の情報を求めましょう。再現を試みて失敗しても、観察の範囲が狭まるだけで、最初の報告が正しかったかどうかは決まりません。

例：自分の環境では問題が起きない。 こう伝えます。「手元のバージョンで記載された手順を試したところ、ボタンからフォームが送信されました。開始状態、入力内容、バージョンを比べてから、同じ手順を一緒に試せますか？」最初に報告した人が別の環境を使っていた場合、複数の条件を変える前に、その違いを記録します。

不足している情報に応じて、次の対応を選びます。

• 手順が不明確： 直前に何が起きたかも含め、手順を示してもらいます。
• 開始状態が異なる： 共通の開始状態を決め、手順をもう一度試します。
• 動作が不定期： 発生しなかった試行も含め、試行回数と条件を記録します。
• アクセスできない： その制限を説明し、関連する証拠を確認できる人を尋ねます。

例：チームメイトと期待される動作について意見が違う。 こう伝えます。「フォームが入力を受け付ける点では合意しています。意見が違うのは、受け付けるべきかどうかです。要件を確認するか、その判断を担当する人に聞けますか？」チームメイトへの非難に話を向けず、必要な判断を明確にできます。

開発者から詳細を求められたら、その依頼に直接答えましょう。たとえば、「手順と画面上のメッセージは記録しましたが、再読み込み後にどうなるかは確認していません。その観察を追加できます」と伝えられます。最初に想定した動作が誤りだったと分かったら、報告を修正し、理解がどう変わったかを説明します。

技術用語が分からないときは、簡潔に答えましょう。「それはまだ使ったことがありません。これを使ってどのような作業をしてほしいのか、説明していただけますか？」必要であれば、その後、自分が理解していることと結び付けます。答えられないことを、確かなことのように推測して埋めてはいけません。

自分の作業とグループ全体の作業を区別できる例を使いましょう。授業課題、個人アプリ、ボランティアで作ったウェブサイトも題材になります。作業内容を正直に説明し、実際に行った確認を述べてください。

面接前に、1つのプロジェクトについて、証拠を簡潔にメモしましょう。

• どの動作を確認していましたか？
• 自分で行ったことは何ですか？
• 何を観察または記録しましたか？
• 時間やアクセスがもっとあれば、次に何を確認しますか？

まだ適切な経験がない場合は、自分が所有しているか、テストを許可されているプロジェクトで、小さな練習をしてみましょう。期待される動作を書き、通常の入力と無効な入力を1つずつ試し、結果を記録します。話すときは、練習として行ったことを明確に伝えましょう。短時間の確認を、リリース済み製品の品質管理を担当したという主張に変えてはいけません。

面接の終わりには、インターンがどう学び、貢献するかが分かる質問をしましょう。

• 「チームではインターンのテスト案やバグ報告を、どのようにレビューしますか？」
• 「最初にどのツールを学びますか？また、オンボーディングはどのようにサポートされますか？」
• 「要件が不明確な場合、インターンの解決を誰が手助けしますか？」
• 「最初の貢献として、どのようなものが役立ちますか？」

面接官がすでに説明した内容を踏まえて、2つ選びましょう。先ほどメンタリングの話が出ていたなら、その話題を掘り下げます。「報告書を一緒に作成するとおっしゃっていましたが、レビューでは通常どこを確認しますか？」こうしたやり取りの準備には、インターン面接の準備方法を参考にしてください。一般的な締めくくりの質問をそのまま並べるのではなく、職務に関連する質問をしましょう。

SayNow AIを使って、自分の考えを声に出して説明する練習をしましょう。AI模擬面接では、AIが音声での会話で面接官役を務め、追加質問をし、終了時にスコアと文章での提案を提供します。フィードバックの対象は、流暢さ、内容の構成、シナリオとの適合度、目標の達成度です。技術的な回答が正しいかどうかは確認しません。

一般的な就職面接のシナリオから始め、プロジェクトでの貢献を紹介する練習をしましょう。声に出して答え、追加質問に応じたら、自分の行動を分かりやすく伝えることだけを目標に、フィードバックを読みます。冒頭を短くし、最後に観察内容をより明確に述べる形で、回答を繰り返しましょう。

修正した構成を、QEの面接練習の質問に取り入れてください。説明の練習を活用しながら、技術的な詳細は授業の経験、明示された要件、または適切な確認者に照らして確かめましょう。

就職面接シナリオで、声に出して答える練習をする。

同じ回答を暗記したように聞こえるまで繰り返すのではなく、課題を変えながら短い模擬面接を行いましょう。まず、経験についての質問、曖昧な要件についての質問、説明が必要な報告を1つずつ用意します。

1. プロジェクトの例を挙げ、自分の貢献を明確にします。
2. 要件について確認の質問をし、必要なら前提を述べます。
3. テスト案を2つ選び、期待する結果を説明します。
4. 手順、期待される動作、観察内容を使って、予想外の結果を説明します。
5. 時間が少ない場合や開始状態が異なる場合など、条件が1つ変わる追加質問に答えます。
6. チームのレビュー手順と学習支援について質問を2つして、締めくくります。

回答が問いに答えなくなる箇所に注意しましょう。アプリケーションの説明に大半の時間を使っているなら、自分の判断を冒頭に移します。ピラミッド原則を使うと、回答の詳しい説明より先に要点を述べられます。志望動機や勤務可能時期についても練習したい場合は、より幅広いインターン面接の質問集を参考にしてください。

QEインターンの面接 質問には、どの回答でも1つの判断を明確に示すことを目指しましょう。何を確認するか、なぜ重要か、結果から何が分かるかを伝えます。今日の練習を終える前に、最も分かりにくい回答を一度改善し、これから勉強する必要のある技術的な質問を書き留めましょう。