はじめに

実務でテストケースを300件以上作成した結果、かえって品質を落としてしまった経験があります。

QAエンジニアとして開発に関わる中で、「網羅性を追求すること」と「品質を担保すること」は必ずしも一致しないと気づきました。

本記事では、その経験をもとに、テスト設計における課題と改善ポイントを紹介します。

実際に直面した課題

ケース①：網羅性を重視しすぎたテストケースの肥大化

プロジェクト初期に「漏れをなくすこと」を最優先に考え、すべてのパターンを洗い出した結果、300件以上のテストケースを作成しました。

その結果、以下の問題が発生しました。

テスト実行に2日以上かかり、スケジュールを圧迫
軽微な確認と重要機能が同列に並び、優先順位が不明確
仕様変更のたびに修正コストが増大（1回あたり30分以上）

結果として、重要なテストが未実施のままリリース直前を迎える状況となりました。

ケース②：期待値の曖昧さによる不具合の見逃し

以下のような曖昧な期待結果により、不具合の検知漏れが発生しました。

❌ 正常に表示されること

実際には以下の問題が存在していました：

UIレイアウトの崩れ（要素の重なり）
特定条件下でのデータ不整合
表示されるべきボタンの欠落

判断基準が曖昧なため、「問題なし」と判断してしまうケースがありました。

課題の本質：リスクベース設計の欠如

これらの問題の根本原因は、

すべての機能を同じ優先度で扱ってしまったこと

にあります。

テスト設計では、以下の観点でリスクを評価することが重要です。

#	観点	内容
1	ビジネスインパクト	障害発生時の影響
2	発生確率	複雑性・過去の不具合実績
3	影響範囲	他機能への波及

改善して学んだ6つのポイント

1. テストケースは「最小単位」で設計する

1ケース1目的とすることで、

失敗箇所の特定が容易
修正コストの低減
可読性の向上

につながりました。

2. リスクベースで優先度を決定する

以下の観点で優先度を整理しています。

優先度	対象
🔴 高	メイン動線、決済、データ整合性
🟡 中	頻繁に利用される機能、入力バリデーション
🟢 低	表示文言、発生頻度の低いケース

重要な箇所にリソースを集中できるようになりました。

3. 期待結果は「客観的事実」で記述する

❌ NG：正しく表示される

✅ OK：
  - ダッシュボードに売上金額がカンマ区切りで表示される
  - ユーザー名がヘッダー右上に表示される
  - APIレスポンスの status が "success" である

4. API・DB観点での検証を取り入れる

UIだけでなく、以下の観点で検証を行います。

APIステータスコード（200 / 400 / 500）
レスポンスデータの整合性
DBに保存された値の正確性

「見た目が正しい＝正しい」とは限らない点に注意が必要です。

5. 異常系・準正常系を重視する

不具合の多くは想定外の操作で発生します。

入力不備
タイムアウト
APIエラー

正常系と同等、またはそれ以上の優先度で設計します。

6. BDD形式の記述を活用する

振る舞いベースで記述することで、認識齟齬を防ぎます。

Scenario: パスワード未入力でのログイン失敗
  Given ログイン画面を開いている
  When IDのみ入力しログインボタンをクリックする
  Then 「パスワードを入力してください」と表示される

改善後の効果

設計の見直しにより、以下の改善が見られました。

項目	改善前	改善後
テストケース数	300件	約120件
テスト実行時間	2日	半日
重要バグ検出精度	中	向上

テストの「量」ではなく 「優先度と質」 が重要であることを実感しました。

まとめ

QAの役割は単なるテスト実行ではなく、

「品質リスクを最小化すること」 です。

ケースは多ければ良いわけではない
リスクベースで優先度をつける
期待結果は具体的に記述する
異常系とAPI/DB観点を重視する

おわりに

テストは「疑うこと」から始まりますが、テスト設計は**「信頼できる結果を生み出す仕組み」**を作ることだと考えています。

単にバグを見つけるだけでなく、「このテストを通ればリリースして大丈夫」とチーム全体が確信を持てる状態を目指しています。

今後は、APIテストの自動化やDB検証の効率化など、より技術的な観点でのテスト設計についても発信していきたいと考えています。

ここまでお読みいただきありがとうございました。