第6部 面接の実践・第15章
QA の面接で出る、テストケースを作る実技と自動テストのコードレビューの進め方を、回答例と一緒に押さえる。
QA の実技面接では、「〇〇のテストケースを考えてください」「このテストコードをレビューしてください」のような課題が出ます。見られているのは答えの量ではなく、考えの進め方です。
| 段 | すること |
|---|---|
| 仕様の確認 | いきなり書き始めず、前提・範囲・優先したいことを質問する |
| 観点の洗い出し | 機能・入力・状態・権限・非機能…と観点で分けて、全体の地図を見せる |
| ケースの具体化 | 同値分割・境界値などの技法で、具体的な値と期待結果を言う |
| 優先順位と自動化 | 時間が限られたらどれから、どれを自動化するかを理由つきで |
| 質疑 | 「他には？」「どれを削る？」に、観点の地図に戻って答える |
考えていることは声に出し、ホワイトボードや共有の画面に観点を書きながら進めると、面接官が途中で助け船を出しやすくなります。
最初の質問の質が、そのまま評価になります。次の分類で2〜4個に絞って聞きます。答えがなければ「〜と仮定して進めます」と前提を置きます。
| 分類 | 質問の例 |
|---|---|
| 利用者と目的 | 誰が・何のために使う機能か。いちばん困るのはどんな失敗か |
| 入力と範囲 | 入力の種類・上限・必須か。0 件や上限のときはどうなるか |
| 状態と権限 | ログインは必要か。役割によって動きが変わるか |
| 環境 | Web かアプリか。対応するブラウザ・端末 |
| 非機能 | 利用者の数・速さの目標・セキュリティの要求 |
| 範囲 | 今回テストしてよい範囲（画面だけか、API や DB も見るか）、使える時間 |
観点を先に並べてから中身を埋めると、抜けが減り、面接官にも全体が伝わります。次の一覧を頭に入れておき、お題に合わせて選びます。
| 観点 | 問いかけ | 例（検索欄） |
|---|---|---|
| 機能（正常系） | 仕様どおりに動くか | キーワードで該当の商品が出る |
| 入力（異常系） | 同値分割・境界値・エラー推測 | 空・空白だけ・とても長い・記号・絵文字 |
| 状態・順序 | 状態遷移・操作の順 | 検索中に再検索、戻るボタンで条件が残るか |
| データ | 0 件・1 件・とても多い | 0 件の表示、ページ送りの境目 |
| 権限 | 誰が見られる・できるか | 非公開の商品が出ない |
| 同時・中断 | 二度押し・通信の切断 | 連打しても結果が崩れない |
| 性能 | 多い・速い | 応答時間の目標、多い件数での速さ |
| セキュリティ | インジェクション・XSS | <script> が文字として表示される |
| 互換性・アクセシビリティ | 環境・誰でも使えるか | スマホ、キーボードで検索できる |
実技面接では、「全部でいくつになりますか」「どれくらい時間がかかりますか」と数字を聞かれることがあります。次の計算を素早くできると、判断に説得力が出ます。
| 計算 | 例 | 使いどころ |
|---|---|---|
| 組み合わせの数 | 3つの値を持つ因子が4つ → 3×3×3×3＝81 通り | 全部は無理だと示す |
| ペアワイズで減らす | 上の 81 通り → 9 通りで2つずつの組み合わせはすべて出せる | 現実的な数に絞る |
| 条件の組み合わせ | はい・いいえの条件が4つ → 2 の 4 乗＝16 通り | デシジョンテーブルの大きさ |
| 自動テストの時間 | 1本 12 秒×200 本＝40 分 → 4 分割で約 10 分 | 並列化の効果を説明する |
| flaky の影響 | 1本 1% で落ちるテストが 200 本 → 全部通る確率は 0.99 の 200 乗＝約 13% | flaky を放置できない理由 |
| 自動化の元 | 手動 30 分×毎週＝年に約 26 時間 | 自動化する価値の判断 |
flaky の計算は特に効果的です。1本ずつは「たまに落ちるだけ」でも、数が増えるとほぼ毎回どれかが落ちる状態になることを数字で示せます。
| お題 | 狙われる観点 | 外せないポイント |
|---|---|---|
| ログイン画面 | 入力・認証・セキュリティ | ロックの回数、エラー文言で登録の有無が分からないか |
| 自動販売機・エレベーター | 状態遷移・境界・同時 | お金の境界、状態と操作の組み合わせ |
| 検索欄 | 入力・データの件数・性能 | 0 件・ページ送り・特殊な文字 |
| ファイルのアップロード | 大きさ・形式・中断・セキュリティ | 上限ちょうど、拡張子の偽装、途中の切断 |
| EC の購入・クーポン | デシジョンテーブル・お金・二重処理 | 割引の組み合わせ、二度押し、在庫の境界 |
| 新機能のテスト戦略 | リスクと配分、自動化 | しないことと、その補い方 |
| テストコードのレビュー | 待ち方・独立・ロケーター・確認 | 固定の sleep、データの共有、確認がない |
お題：メールアドレスとパスワードでログインする画面のテストケースを考えてください。
確認する質問：何回間違えるとロックされますか／「ログインしたままにする」はありますか／対応する端末は。→「5 回でロック、ロックは 30 分、Web のみ」と仮定。
| 観点 | ケース（例） | 優先度 |
|---|---|---|
| 認証（正常） | 正しい組み合わせでログインでき、マイページに移る | 高 |
| 認証（異常） | パスワード違い・未登録のメール → 同じエラー文言（登録の有無が分からない） | 高 |
| 状態 | 4 回失敗の後に成功できる、5 回でロック、30 分後に解除 | 高 |
| 入力 | 空欄、メールの形式違い、前後の空白、大文字小文字、上限の長さ | 中 |
| セキュリティ | パスワードが画面・URL・ログに出ない、ログアウト後に戻れない | 高 |
| その他 | Enter で送信できる、二度押し、遅い回線、キーボードだけで操作 | 中 |
締め：「時間が限られるなら、高の行を先に。認証とロックは API の自動テストに、ログインの流れは E2E に1本入れます」と優先順位と自動化まで言って終えます。
お題：EC サイトに「会員ランクとクーポンを組み合わせて割引する」機能を追加します。リリースまで2週間。テスト戦略を説明してください。
考え方：お金にかかわり、条件の組み合わせが多いので、リスクは高。計算は下の層で網羅し、画面は主要な流れと探索的テストに絞ります。
| リスク | 確かめ方 | 担当 |
|---|---|---|
| 割引の計算の誤り（併用・端数・上限） | デシジョンテーブルで組み合わせを作り、単体・API の自動テストで網羅 | 開発者と QA |
| 二重適用・二重の注文 | 同じクーポンの再利用、二度押し、2タブの同時購入 | QA（API と手動） |
| 期限・利用回数の境界 | 期限の直前・直後、残り1回 | QA（時刻を差し替えて自動化） |
| 画面の流れ | 適用 → 数量変更 → 削除 → 購入を E2E で1〜2本 | QA |
| 想定外の使い方 | 探索的テスト 2 セッション（戻る・再読み込み・別端末） | QA |
| リリース後 | 機能フラグで社内 → 10% → 全員。割引額の合計を監視 | SRE・PdM と |
しないこと：既存の決済の画面は変更がないので、自動の回帰テストのみ。終了基準：割引の組み合わせの自動テストがすべて通り、重大・高の不具合が 0。
お題：次の E2E テストをレビューしてください。
test('カート', async ({ page }) => {
await page.goto('/login');
await page.fill('#email', 'qa@example.com');
await page.fill('#pass', 'password');
await page.click('.btn-primary');
await page.waitForTimeout(5000);
await page.goto('/items/1');
await page.click('div.sc-a1 > button:nth-child(2)');
await page.goto('/cart');
});| 指摘 | 理由 | 直し方 |
|---|---|---|
| 確認（expect）がない | 何も確かめておらず、壊れていても通る | カートに商品と金額が表示されることを確かめる |
| テスト名があいまい | 落ちたとき何が壊れたか分からない | 「商品をカートに入れると小計に表示される」 |
| 固定の 5 秒待ち | 遅い日は落ち、速い日はむだ | 画面の表示や通信の完了を待つ（自動待機・expect） |
| 壊れやすい要素の指定 | クラス名や順番は見た目の変更で壊れる | getByRole・getByLabel・data-testid |
| 毎回画面からログイン | 遅く、ログイン画面の不具合で全部落ちる | 保存したログイン状態を使う |
| 固定の商品 ID・共有のアカウント | 他のテストやデータの変更で結果が変わる | テストごとにデータを API で作る |
指摘は影響の大きい順（確認がない → 待ち方 → データ）に話し、「まずこれだけは直したい」と優先順位を付けると、レビューの経験が伝わります。
| 失敗 | どうすればよいか |
|---|---|
| いきなりケースを書き始める | 最初に2〜4個の質問で前提をそろえる |
| 正常系だけ、または思いつきの異常系だけ | 観点の一覧で地図を作ってから埋める |
| 「正しく動く」のようなあいまいな期待結果 | 数値・文言・状態で言う |
| ケースを並べて終わる | 優先順位と、何を自動化するかまで言う |
| 「全部テストします」 | しないことと、その補い方（監視・段階的な公開）を言う |
| 黙って考え込む | 考えていることを声に出す。迷ったら観点の一覧に戻る |
まず答えを見ずに声に出して答え、そのあと開いて比べる。
模範回答
まず前提を確かめます。キーワードは部分一致か、複数の語は AND か、並び順と1ページの件数は、を聞き、答えがなければ「部分一致・AND・20 件ずつ」と仮定します。
観点で分けると、正常系は該当の商品が出ること、入力は空・空白だけ・とても長い語・記号・全角半角・絵文字、データは 0 件・1 件・20 件と 21 件のページの境目、権限は非公開や削除済みの商品が出ないこと、セキュリティはタグを入れても文字として表示されること、性能は件数の多いときの応答時間です。時間が限られるなら、0 件とページの境目、非公開の商品を先に確かめ、検索の結果は API の自動テストで網羅します。
深掘りされたら
見られているポイント前提の確認、観点の網羅、優先順位
模範回答
前提として、許可する形式と大きさの上限、複数のファイルを送れるか、誰が見られるかを確かめます。仮に「JPEG と PNG、10MB まで、本人だけが見られる」とします。
観点は、大きさの境界（0 バイト・10MB ちょうど・少し超える）、形式（許可の形式、許可しない形式、拡張子だけ変えた偽装ファイル）、ファイル名（日本語・とても長い・記号）、中断（アップロードの途中で通信を切る・画面を離れる）、同時（二度押し）、権限（他人がファイルの URL を開けない）、セキュリティ（画像に見せかけたスクリプトが実行されない）です。お金や個人情報にかかわるので、権限と偽装を優先します。
深掘りされたら
見られているポイント境界・形式・中断・権限・セキュリティの観点
模範回答
お金にかかわり外部サービスと連携するので、リスクは高いと考えます。まず外部サービスとの約束（API の仕様と、テスト用の環境があるか）を確かめます。
計算と状態は下の層で網羅します。支払いの状態遷移（申込み・承認・否認・取消し）を表にして、API の自動テストで正しい遷移と許されない遷移を確かめます。外部の応答は、成功・否認・タイムアウトをモックで作り、二重の申込みや通信の切断も試します。画面は主要な流れを E2E で1〜2本、使い勝手は探索的テストで見ます。リリースは機能フラグで社内から段階的に広げ、決済の成功率と金額の合計を監視します。既存の決済には変更がないので、自動の回帰テストに任せます。
深掘りされたら
見られているポイントリスクにもとづく配分、外部連携と状態遷移、リリース後の備え
模範回答
2つとも flaky の主な原因なので、優先して直すよう指摘します。固定の sleep は、速い日はむだに待ち、遅い日は待ち足りずに落ちます。表示や通信の完了を待つ、Playwright なら自動待機と expect の再試行に任せる形に直します。
同じアカウントの共有は、テストの順番や並列に流したときに、他のテストが変えたデータで結果が変わります。テストごとに API でユーザーとデータを作るか、テストごとに専用のアカウントを割り当てます。あわせて、確認の抜けや、壊れやすい要素の指定がないかも見ます。
深掘りされたら
見られているポイントflaky の原因の理解と、具体的な直し方
模範回答
まず、仕様の代わりになる情報を集めます。PdM に目的と「いちばん困る失敗」を聞き、開発者に作りと変えた所を聞き、似た既存の機能や競合の動きも参考にします。
そのうえで、探索的テストのチャーターを決めて触り、動きを観察しながら「こうなるべきでは」という疑問を一覧にして PdM に確かめます。確かめた答えは受け入れ条件として残し、それをもとにテストケースと自動テストを作ります。仕様の抜けを見つけて文書にすること自体を、QA の成果として示します。
深掘りされたら
見られているポイント情報の集め方、探索的テストの使い方、仕様を固める貢献
模範回答
リスクで削ります。壊れたときの影響（お金・個人情報・多くの人が使う・元に戻せない）と、壊れやすさ（今回変えた所・複雑な所・過去に不具合が多い所）が両方低いものから削ります。
あわせて、同じ同値クラスの代表が複数あるものは1つにまとめ、組み合わせはペアワイズで減らし、下の層の自動テストで確かめられているものは画面のテストから外します。削ったものは「しないこと」として理由と一緒に残し、リリース後の監視や段階的な公開で補えるかも伝えます。
深掘りされたら
見られているポイントリスクにもとづく判断と、削ったことの扱い