QAテスター向けテスト問題例：技術面接で聞くべきこと
標準的なQA質問が採用に失敗する理由
多くのQA面接質問は2つの罠に陥っています。1つは「テストとQAの違いは何か」といった一般的すぎる質問で、資格試験に合格した誰もが答えられるもの。もう1つはテックスタックに特化しすぎた質問で、考える力ではなくフレームワークの知識を試すものです。テストの用語を丸暗記した候補者は有能に見えます。しかし実際にソフトウェアを壊して改善できる人材は目に見えません。
優れたQA質問は、テスト用語ではなくテスト「戦略」を測定します。候補者がテスト計画なしで実際に何をするのかを明らかにします。構造化されたQAおよびテスト自動化評価は、語彙ではなく現実的な不具合発見作業で候補者をスコア化し、両方のギャップを埋めます。
質問例#1：バグレポートシナリオ
「eコマースのチェックアウトフローをテストしています。決済ゲートウェイが時々重複トランザクションを受け入れます。同じオーダーID、同じ金額、5秒以内に発生します。これはおおよそ50回に1回の頻度で起こります。これをどのように調査し、文書化するか説明してください。」
測定対象：
- 明確にするための質問をするか（決済方法は？ブラウザは？ネットワーク環境は？）
- バグの再現、根本原因、範囲を区別できるか（彼らのコードの問題か、ゲートウェイの問題か）
- それを再度キャッチするテストケースを明確に説明できるか
- エスカレーションするか、まず自分で再現しようとするか
これにより、エンジニアのように考える人（根本原因、範囲、防止）か、単なる報告者のように考える人（症状、スクリーンショット、チケット）かが明らかになります。
質問例#2：自動化のトレードオフ
「エンドツーエンドで実行に2時間かかるテストスイートがあります。チームは1日1回実行します。同僚が画像アップロード用のUIフローの自動化を提案しています。Seleniumで約40行、四半期ごとに15分のメンテナンスが必要です。実施しますか。その理由を説明してください。」
測定対象：
- ROI（自動化のコストと手動再テストのコスト）について考えるか
- 自動化が効率ではなくオーバーヘッドになる場合を知っているか
- メンテナンス負荷を誠実に見積もれるか
- 脆性とフォルスポジティブを考慮するか
「すべてを自動化する」または「UIテストは不安定だ」と言う候補者は要点を逃しています。正しい答えは通常「それが何を検出し、どのくらい頻繁に壊れるかによる」です。
質問例#3：テスト設計チャレンジ
「ユーザーデータをCSVにエクスポートする機能を構築しています。ファイルは10行から100,000行になります。何をテストしますか。何をテストしない、そしてなぜですか？」
測定対象：
- 優先順位をつけられるか（CSV形式、行数のエッジケース、特殊文字）とノイズ（ボタンの色は重要か）を区別できるか
- 何を自動化する価値があり、何をスポットチェックすべきかを知っているか
- リスク（データ漏洩、フォーマット破損）と好みを区別して説明できるか
優れたQAエンジニアは範囲について徹底的です。彼らはすべてをテストしません。ビジネスに害を及ぼす可能性があるものをテストします。
質問例#4：回帰リスク
「チームがユーザープロフィールページのデータベースクエリをリファクタリングしました。スキーマの変更はありませんでしたが、単にコードをクリーンアップしました。テスト戦略は何ですか。信頼度レベルは？」
測定対象：
- フルリグレッションスイートを実行したいか、それとも批判的に考えるか
- 何が壊れる可能性があるかを特定できるか（N+1クエリ、間違ったデータバインディング）
- 「コードが変わった」と「リスクが変わった」の違いを理解しているか
これがアナリストからエンジニアを分けます。エンジニアは「何が変わり、何が重要か」と聞きます。アナリストは関係なくフルスイートを実行します。
質問例#5：クロスブラウザ質問（ひねりあり）
「Chrome、Firefox、Safariで新しいUIコンポーネントをテストしています。すべての場所で正しくレンダリングされます。IE11でテストしますか？モバイルChromeで？EdgeなどのChromiumベースブラウザで？トレードオフを判断してください。」
測定対象：
- ユーザーベースを知っているか（すべての製品がIE11サポートを必要とするわけではない）
- ブラウザカバレッジとテストコストを見積もれるか
- 実際のブラウザと偽のカバレッジの違いを知っているか
ここでは意見が重要です。「IE11をサポートしていないのでいいえ」は「すべてをテストすべき」より強いです。
質問例#6：ライブコーディング面接（簡潔版）
「最も知っているフレームワークでテストケースを書いてください。シンプルな関数を提供します：validateEmail(email)。有効なメールアドレスならtrueを、そうでなければfalseを返します。テストを書いてください。関数は書かないでください。」
測定対象：
- エッジケース（空文字列、@がない、複数の@、スペース）について考えられるか
- 読みやすいテストを書くか、それとも難解なテストを書くか
- テストフレームワークを知っているか（アサーション、セットアップ/ティアダウン）
- 動作とは別に実装をテストしているか
これは10分で完了し、言語の流暢さ、テスト構造、思考を明らかにするライブコーディング面接です。
機能する方法
これら6つの質問すべてに同じ構造があります。実際（または現実的な）状況を提示し、候補者にそれについて推論するように求め、キーワードの想起ではなく判断を聞く。答えが正しいか間違っているわけではありません。答えが明らかにするのです。
覚えている面接は、候補者があなたに一呼吸置く質問をする面接です。それが信号です。それが採用です。
書面による評価を使用する場合
すべてのQA採用者が記録されたライブコーディング面接を必要とするわけではありません。テイクホーム型のテストケース課題は同様に有用です。「機能仕様があります。チームに提案したい10～15のテストケースを書いてください。優先順位を説明してください」と言い、次のラウンドで推論について追加質問をしましょう。これは成果物の品質と言葉での防御を組み合わせます。
採用のスケーリングのために、テストケースカバレッジ、アサーション品質、エッジケース思考を採点できる評価プラットフォームは、ライブラウンドをより効率的にします。
反対意見
一部のチームは、テストの専門用語を使わずに動作優先の面接を好みます。「驚いたバグを見つけた話をしてください」または「テストが完了していないという理由で期限に異を唱えた最後の時を説明してください」です。これも機能します。特に、テスターである人ではなく、品質を所有する人を採用する場合です。
質問よりも哲学が重要です。記憶ではなく思考を測定しています。他はすべてそこから派生します。