テスト自動化エンジニア向けベスト QA テスト
QA評価にとって「最高」が意味すること
すべての採用に機能する単一のQAテストはありません。しかし、機能するパターンがあります：テスト思考をコーディングスピードから、判断を知識から、アーキテクチャを構文から分離する多層評価です。
最高のQAテストは最も難しいものではありません。候補者が3年間テストスイートを維持しても燃え尽きないかどうかを明かす1つです。
理想的な評価構造
パート1：テストケース設計（記述、30～45分）
これは交渉不可能です。これが最初のフィルターです。
候補者に現実的な機能仕様を与えてください。「ログインをテストする」（曖昧すぎます）ではなく、「100のテストケースを書く」（多すぎます）でもなく。中間のもの：「CSVからユーザーデータをバルク入力する機能があります。チームに提案する8～12のテストケースを書いてください。」
採点内容：
- カバレッジ：境界ケース（空のファイル、100k行、特殊文字）を特定していますか？
- 明確性：他の人がそれらを呼ばずにこれらのテストを実行できますか？
- 判断：重要なケースを優先するか、すべてを等しく扱いますか？
- 現実性：制約（データセットアップ、環境）を認識していますか？
ルーブリックを使用：カバレッジ25%、明確性25%、判断25%、実行可能性25%。完全な客観性ではありませんが、一貫しています。
採点時間：候補者あたり10～15分。規模では、スコアリングをテンプレート化できます。
パート2：自動化コード（テイクホーム、2～3時間）
パート1に合格したら、テイクホームを送信します。「サンドボックスアプリケーションがあります。設計したばかりの4～5つのテストケースを選んで自動化してください。知っているフレームワークを使用してください。」
採点内容：
- コード品質：読みやすく、保守可能で、過度に巧妙ではない？
- フレームワーク流暢性：有効な構文、適切なアサーション、スマートな待機？
- 堅牢性：このテストは軽微なUI変更を生き残りますか、それとも脆弱ですか？
- アーキテクチャ：ページオブジェクト、データセットアップ、ティアダウンを使用していますか？
速度でスコアをつけないでください。同じ時間に2つの堅実なテストを2.5時間で書く候補者は、8つの急いで書いたテストを書く候補者より強いです。
無視すること：Seleniumを選んだかCypressを選んだかどうか、特定のライブラリを使用したかどうか。これらは好みです。テスト品質が重要です。
採点時間：15～20分。次を探してください：壊れないセレクター、意味のある待機、動作をテストするアサーション（DOMの状態だけではなく）、人間が読める可能なコード。
パート3：ライブプロセス面接（60分）
ここで判断が輝きます。2～3のシナリオを準備してください：
シナリオ1：「回帰スイートは3時間長いです。チームはより速い展開のロックを解除するために1時間に短縮したいと思っています。あなたの計画は何ですか？」
シナリオ2：「重大な本番バグがテストスイートで見落とされました。100回に1回発生するレース条件です。調査を歩いてください。」
シナリオ3：「機能は2週間で起動します。テストは終了していません。完全なカバレッジなしで出荷すると、データ損失リスクに露出します。何を提案しますか？」
これらは正しい答えを持っていません。あなたは次のことを聞いています：
- 彼らは明確化する質問をしていますか（チームサイズ、ユーザーへの影響、予算）？
- ヘッジすることなく、トレードオフを説明できますか？
- エンジニアのように考えていますか（リスク、ROI、メンテナンス）、またはテスト担当者のように思いますか（カバレッジ）？
- 彼らは制約について正直ですか？
時間：質問に20分、推論に10分、フォローアップと彼らがあなたへの質問に30分。
パート4（オプション）：コードレビュー演習（30～45分）
QAの役割にテストコードのレビューが含まれる場合は、これを追加してください。
3～5の問題を含むテストスイートを提供してください：不安定なセレクター、エラーハンドリングの欠如、過度に主張されたテスト、セットアップ/ティアダウンレース条件。問題を特定し、修正を提案するよう求めてください。
採点内容：
- コードを読んで批評できますか？
- 故障モードを理解していますか？
- 提案は現実的か理論的か？
これは、チームが実際にテストコードをレビューする場合のみ必要です。多くはそうではありません。
総時間投資
- パート1（記述）：45分の候補者時間、10～15分の採点
- パート2（テイクホーム）：2～3時間の候補者時間、15～20分の採点
- パート3（ライブ面接）：1時間の候補者時間、30分の面接、10分のメモ
- パート4（オプション）：30～45分の候補者時間、10分の採点
合計：4～5時間の候補者時間、候補者あたり1.5～2時間のリクルーター/面接官時間。これはシニア採用に適切です。
このアセスメント前のスクリーニング
テイクホームをすべてに送信しないでください。パート1（書かれたテストケース設計）をスクリーナーとして使用してください。
45分でコヒーレントなテストケースを設計できない場合、堅実な自動化コードを書きません。3時間のテイクホームを書いたラウンドに合格した候補者に保存してください。
大まかな合格率：書かれた提出の40～60%がテイクホームに進むことを目指してください。それがはるかに高い場合は、ルーブリックが寛容すぎる可能性があります。それより低い場合は、仕様が不明確な可能性があります。
採点キャリブレーション
採用する前に、「良い」が何に見えるかについてチームをキャリブレーションしてください。
チームから2～3人の既知の良い採用でアセスメントを実行してください。テストケースはどのように見えますか？彼らのコード品質は？これを参照標準として使用してください。
その後、2～3人の既知の悪い採用（うまくいかなかった人）を実行してください。彼らの提出の何が弱かったのですか？その負のスペースも重要です。
完全に客観的である必要はありません。一貫性を保つようにしてください。
パーツをスキップする時期
手動QAロールを採用（自動化ではなく探索的）：パート2とパート4をスキップしてください。パート1（テスト思考）とパート3（判断）に焦点を当ててください。
ポートフォリオが検証されたミッドレベルのエンジニアを採用：パート1（テスト設計）をスキップして、パート2（コード）とパート3（面接）に直接進むことができます。ただし、すでに実際のコードを見たことがある場合のみです。
大規模で初期段階で採用：パート1 +パート3（テイクホームをスキップ）で開始してください。より高速です。プロセスが安定したら、最終ラウンドのパート2を追加してください。
このストラクチャが代替案を打つ理由
Leetcode形式の問題より優れている：これらはプレッシャーの下でコーディングスピードをテストします。テスト思考やアーキテクチャではなく。
単一のライブコーディング面接より優れている：60分のライブセッションで誰かのテスト設計または保守コードの能力をスコアすることはできません。
ポートフォリオレビューより優れている：ポートフォリオは厳選されています。アセスメントは現在のスキルを示すもので、3年前の最高の仕事ではありません。
ストラクチャは機能します。テスト設計はコード品質が異なり、判断が異なります。3つすべてが必要です。
反対の考慮：多分あなたは採用方法を間違っています
一部のチームは、テストのみを知る専門家ではなく、テストを拾うことができる強いエンジニアを採用するべきだと主張しています。
エンジニアが十分に強い場合は公正です。しかし、「QAも行う」ために採用された強いエンジニアはしばしばそうしません。QAはそれらが恨む仕事になります。保守されていないテストと燃え尽きたエンジニアで終わります。
この規律を選んだ人を雇ってください。アセスメントはそれらを見つけるのに役立ちます。