面接の全体像と答え方

課題・施策・巻き込み・結果の順に話します。例えば、リリース直前に不具合が大量に見つかり、毎回リリースが遅れるという課題があったとします。振り返ると、テストがリリース前にまとめて行われ、仕様のあいまいさが実装後に発覚していることが多い、と分かったとします。

施策として、チケットごとに受け入れ条件を書き、実装前に開発者・PdM・QA の3人で短く確認する場を作ります。あわせて主要な流れの E2E テストを CI に入れ、壊れたらその日のうちに分かるようにします。巻き込みでは、まず1つのチームで試し、手戻りの件数を数字で見せてから他のチームに広げます。開発者の手間を増やさないよう、受け入れ条件の型も用意します。

結果は、リリース直前に見つかる不具合の件数やリリースの遅れの回数など、前後で比べられる数字で話します。実際の面接では、自分の経験に置き換え、うまくいかなかった点とそこから学んだことも添えると説得力が増します。

まず仕様を質問します。何階建てか、何台あるか、定員や重さの上限、非常ボタンや停電時の動きなどです。そのうえで観点ごとに考えます。

正常系は、呼んだ階に来る、行き先の階で止まる、扉が開いて閉まる。境界値は、最上階と最下階、定員ちょうどと 1 人超え（重さの上限）。状態としては、上がっている途中で下の階から呼ばれたとき、同時に複数の階から呼ばれたときの止まる順、扉が閉まる途中で人が挟まりそうなときに開き直るか。異常系では、停電、非常ボタン、ボタンの連打、存在しない階の指定（地下がない建物で地下を押す）。ほかに、点字や音声案内、車いすで届くボタンの位置といった使いやすさもあります。

優先順位は、人の安全に関わる「重さの上限・扉の挟み込み・非常時」を最初にし、その次に正しい階に行くことを確かめます。

結論から言い、例を1つ添えて話します。例えば「仕様の段階で抜けを見つけることが強みです」と言い、「前の現場では仕様レビューで『同時に2人が同じ商品を買ったら在庫はどうなるか』を質問して、実装前に在庫の扱いを決められた」のような具体的な場面を続けます。

QA の強みとして評価されやすいのは、テスト設計の力、リスクで優先順位を付ける判断、自動化の技術、開発者や PdM との調整です。応募先の求人が自動化中心なら自動化の経験を、手動や仕様に近い役割ならテスト設計や調整の経験を前に出すと、相手の知りたいことと合います。弱みを聞かれたときも、改善のために何をしているかを合わせて話します。

入社後の働き方と、品質への考え方が分かる質問をします。例えば「QA は開発のどの段階から関わっていますか」「自動テストは誰が書いて、CI でどう流していますか」「本番で不具合が出たとき、どう振り返っていますか」「開発者と QA の人数の比はどれくらいですか」などです。

これらの答えから、QA がテストの実行担当なのか、品質の仕組み作りまで任されるのかが分かり、自分のやりたいことと合うかを判断できます。調べればすぐ分かることや、給与・待遇だけの質問は、この場では避けるのが無難です。