1. テスト戦略とは何か
テスト戦略とは、どの品質を、どのレベルで、どんな方法で保証するかを先に決めておく仕組みです。
単なるバグ探しではなく、
・品質基準の共有
・開発速度の維持
・リグレッション防止
・属人的判断の削減
を目的として設計されます。
つまりテスト戦略は、「テスト工程の話」ではなく、開発全体の運用設計そのものです。
2. 品質保証の基本的な考え方
品質保証では、「問題が起きてから直す」のではなく、「問題が起きにくい構造」を作ります。
そのためには、要件定義段階から以下を整理する必要があります。
特に現代のWebアプリでは、「変更頻度」が高いため、変更時に壊れないことが極めて重要になります。
3. テストレベルの全体像
実務では、複数のレベルで品質を確認します。
すべてを同じ深さで実施するのではなく、「リスクが高い箇所」を重点的に保証するのが現実的です。
4. テストピラミッドの考え方
実務では、すべてをE2Eテストで確認するのは非効率です。E2Eは実行時間が長く、壊れやすく、保守コストも高いためです。
そこで、多くの現場では「テストピラミッド」を基準に責務を分散します。
基本方針は以下です。
・単体テストでロジックを広く保証
・APIテストでシステム間連携を確認
・E2Eは重要導線だけに限定
例えばECサイトでは、
のように役割を分けます。
5. 単体テスト戦略
単体テストは、もっとも高速で安定した品質保証手段です。
特に以下を重点的に確認します。
・計算ロジック
・条件分岐
・バリデーション
・権限制御
・日付処理
一方で、DBや外部APIへ直接依存するとテストが壊れやすくなります。
そのため実務では、
のように責務分離を行い、Service層を独立検証できる構造を作ります。
これにより、
・テスト速度向上
・変更容易性向上
・バグ局所化
が実現しやすくなります。
6. 結合テストとAPIテスト
大規模開発では、「モジュール間のズレ」が障害原因になることが多くあります。
特に発生しやすいのは以下です。
・APIレスポンス変更
・型不一致
・nullable変更
・認証仕様変更
これを防ぐために重要なのがAPIテストです。
例えば以下のレスポンス仕様を固定します。
さらにOpenAPIやTypeScript型生成を使うと、
・型自動生成
・スキーマ検証
・モック生成
まで自動化できます。
この仕組みにより、フロントエンドとバックエンドの認識ズレを減らせます。
7. E2Eテストの実践
E2Eテストは、実際のユーザー操作を再現するテストです。
代表例：
・ログイン
・商品購入
・決済
・会員登録
・パスワード再設定
ただしE2Eは万能ではありません。
問題点：
・実行時間が長い
・不安定になりやすい
・UI変更で壊れる
・保守コストが高い
そのため実務では、
・売上導線
・認証
・決済
・重大障害につながる機能
など、重要箇所に限定します。
近年はPlaywright採用が増えており、
・並列実行
・クロスブラウザ
・Trace確認
などによって運用しやすくなっています。
8. フロントエンドテストの重要性
ReactやVueでは、状態管理と非同期通信の複雑化によって、UI品質の重要性が大きく上がっています。
特に確認すべきなのは以下です。
・ローディング状態
・エラー表示
・空データUI
・再試行処理
・権限別表示
例えばAPI失敗時に何も表示されないと、ユーザー視点では「壊れている」のと同じです。
代表的な構成：
特にComponent Testでは、「UIがどう見えるか」ではなく、「ユーザーがどう操作するか」を基準に設計することが重要です。
9. 契約テストと型安全
フロントエンドとバックエンドを別チームで開発すると、API仕様ズレが頻発します。
例えば：
・name → fullName変更
・string → number変更
・null許容変更
こうした事故を防ぐのが契約テスト（Contract Test）です。
契約テストでは、
・API仕様
・リクエスト形式
・レスポンス形式
を固定し、変更時にCIで検知します。
特にTypeScript + OpenAPI環境では、型安全性によって不整合をかなり減らせます。
10. CI/CDと品質ゲート
実務では、「テストを書く」だけでは品質は維持できません。重要なのは、壊れたコードをmainへ入れない仕組みです。
代表的なCIフロー：
例えば以下を必須条件にします。
・ESLintエラーゼロ
・TypeScriptエラーゼロ
・テスト成功
・Build成功
これにより、人間レビューだけでは防げないミスを自動検知できます。
11. 非機能テストの重要性
実際の障害原因は、機能不備より非機能要件にあるケースが非常に多いです。
重要なのは以下です。
例えば通常時は動作していても、アクセス急増時にDB接続枯渇で停止するケースは珍しくありません。
そのため、
・キャッシュ
・Queue
・Connection Pool
・Circuit Breaker
などを含めて検証します。
12. 実務でよくある失敗
品質が崩れるプロジェクトには共通点があります。
・テスト責務が曖昧
・E2Eへ依存しすぎる
・テストが遅い
・CIが形骸化
・モックと本番仕様がズレる
・テストコードが放置される
特に危険なのは、「テスト数が多い＝安全」と誤解することです。
重要なのは量ではなく、
・どのリスクを減らすか
・どこを重点保証するか
を明確にすることです。
現代のテスト戦略は、「不具合を見つける作業」から、「安全に変更できるシステムを維持する仕組み」へ進化しています。そのためには、単体テスト・APIテスト・E2E・CI/CD・監視を分断せず、一体の品質保証プロセスとして設計することが重要です。特にWebアプリ開発では、変更頻度とリリース速度が高いため、「速く直せる」「壊れても検知できる」「安全に改善できる」構造そのものが品質になります。強い開発組織ほど、テストを書くことよりも、「品質が自然に守られる開発プロセス」を作ることに力を使っています。
