テスト自動化の考え方

テストピラミッドは、テストの種類ごとの「量の配分」の目安です。下ほど速く安く安定しているので数を多く、上ほど遅く壊れやすいので数を絞ります。

上が太い「アイスクリームコーン型」（E2E と手動ばかり）になると、テストが遅く、壊れやすく、直すのが大変になります。E2E で見つけた不具合は「下の層で見つけられなかったか」を考えます。

自動テストは何でも作ればよいわけではありません。繰り返す回数と作って直し続ける手間を比べて決めます。

自動テストは、作る手間に加えて直し続ける手間がかかります。目安として、「手動でかかる時間 × 実行する回数」が「作る時間＋直し続ける時間」より大きいなら自動化する価値があります。たとえば手動で 30 分かかる確認を毎週行うなら年に 26 時間ほど（30 分 × 52 週）になり、数時間で作れて安定して動くなら自動化する価値があります。逆に、すぐ壊れて誰も直さないテストは、信頼されず無視されるようになり、ない方がましなこともあります。

判断のこつ：まずリスクの高い主要な流れ（ログイン・購入など）の回帰テストから自動化し、成功率と実行時間を見ながら広げます。

テストする部品が、外部のサービスや DB に頼っていると、テストが遅く不安定になります。そこで、本物の代わりに差し替える偽物を使います。まとめてテストダブル（映画のスタントの代役から）と呼びます。

現場では全部まとめて「モック」と呼ぶことも多いです。注意：モックを使いすぎると、本物との食い違い（API の形が変わった）を見逃します。モックで速く確かめつつ、本物とつなぐ結合テストや契約テストを少し残します。

テストコードは「読めば何を確かめているか分かる」ことが大事です。基本の形は準備・実行・確認の3段（英語の頭文字で AAA）です。

test('在庫が 0 の商品はカートに入れられない', async () => {
  // 準備
  const item = await createItem({ stock: 0 });
  // 実行
  const res = await api.post('/cart', { itemId: item.id, quantity: 1 });
  // 確認
  expect(res.status).toBe(409);
});

カバレッジは、テストを流したときにコードのどれだけが実行されたかの割合です。テストが通っていない場所を見つけるのに役立ちます。

カバレッジが高い＝よくテストされている、ではありません。確認（assert）の弱いテストでも、コードを通ればカバレッジは上がるからです。数値を目標にしすぎず、「カバレッジが低い所＝確実にテストされていない所」を見つける道具として使います。

テスタビリティは「テストのしやすさ」です。自動テストが作りにくい・不安定になる原因の多くは、テストの側ではなく作りの側にあります。QA が設計の段階で次のような提案をすると、テストが速く安定します。

「テストしにくい」と感じたら、テストで無理に頑張る前に、開発者に作りの側の変更を相談します。シフトレフトの具体的な形の1つです。

自動テストは作って終わりではなく、製品と一緒に直し続けるものです。手入れをやめると、落ちたまま放置され、誰も結果を信じなくなります。

「テストを消す」ことも保守の一部です。価値の低いテストを消して実行時間を短くすると、残りのテストが速く回り、信頼されます。

道具は、製品の言語と、チームがすでに使っているものに合わせて選ぶのが基本です。代表的なものを並べます。

道具の名前より、「なぜその道具を選んだか（チームの言語・速さ・並列実行・デバッグのしやすさ）」を説明できることが面接では大事です。