ウォーターフォール開発におけるQAの重要性とテスト技法の活用法

ウォーターフォール開発でQAが最も効くのは、テスト工程ではなく要件定義・設計工程です。 テストフェーズに入ってから見つけた欠陥は、そのほとんどが上流の曖昧さに由来しており、その時点では直すコストが跳ね上がっているからです。

ウォーターフォールは工程が順番に進むため、不具合の発見が構造的に遅れます。この遅れを埋める方法は2つしかありません。ひとつはV字モデルの考え方で、各工程の成果物に対応するテストを同時に設計すること。もうひとつはテスト技法を設計レビューの道具として使うことです。

この記事では、現場で実際に起きる5つの課題と、それぞれに対して具体的にどう動くかを、テスト技法の使い方まで含めて整理します。

ウォーターフォールでQAが後回しになる構造的な理由

ウォーターフォール開発は、要件定義 → 基本設計 → 詳細設計 → 実装 → テスト → リリース、と一方向に進みます。「テスト」という名前の工程が後半に1つだけあるため、QAの仕事もそこに集中していると誤解されがちです。

しかし実際には、テストフェーズで見つかる欠陥の多くは実装ミスではなく、要件の解釈違いや仕様の抜けです。これらは上流で作り込まれ、下流で発見されます。発見が遅れるほど修正コストが増えるのは、影響範囲が設計・実装・他機能へと広がっているためです。

V字モデルで考える

ウォーターフォールを折り返して並べたV字モデルで見ると、各工程の成果物には、対応するテストレベルがあることが分かります。

重要なのは「テストの実行」ではなく「テストの設計」を左に寄せることです。テストケースを書こうとすると、仕様の曖昧さが必ず表面化します。それを実装前に潰すのがQAの最大の貢献です。

課題1：手戻りが大きい

症状：テストフェーズで仕様の解釈違いが見つかり、設計からやり直しになる。

対処：設計レビューに、テスト観点を持ち込んだ状態で参加します。ただ「レビューに出る」だけでは意味がなく、具体的な問いの形にして持っていくことが重要です。

• 「この項目が未入力のときの挙動はどこに書かれていますか」
• 「上限値ちょうどのときはエラーですか、許可ですか」
• 「この処理の途中でタイムアウトした場合、データはどの状態で残りますか」
• 「既存のこの機能と同時に使われたとき、どちらが優先されますか」

これらの問いは、後述するテスト技法をそのまま設計レビューに転用したものです。答えられない問いが1つ見つかるたびに、テストフェーズでの手戻りが1件減ります。

課題2：仕様変更への追従が難しい

症状：後半に仕様変更が入り、どのテストケースを直せばいいのか分からなくなる。

対処：テストケースと要件をひも付けた対応表（トレーサビリティマトリクス）を最初から作っておきます。 要件IDとテストケースIDの対応が取れていれば、変更された要件から影響範囲を機械的に引けます。

あわせて、テストケース自体を操作手順ではなく判断の根拠で書くと、画面が変わっても書き直しが不要になります。「ボタンAを押す」ではなく「上限を1超える値で申請する」と書いておけば、UIの変更に耐えます。この考え方はテストケースに手順は書くべきか？で詳しく書いています。

課題3：工程間のコミュニケーション不足

症状：設計の意図が伝わっておらず、実装とテストで前提がずれている。

対処：仕様の解釈を「表」にして共有するのが最も速いです。文章で確認すると解釈が割れますが、条件と結果の表にすれば、認識のずれがその場で可視化されます。後述するデシジョンテーブルはこの用途に最適です。

定例会を増やすより、成果物の形を変えた方が効果があります。会議で口頭確認した内容は、翌週には全員の記憶から消えています。

課題4：テストが後半に集中し、期間が圧迫される

症状：実装が遅れた分がそのままテスト期間の削減になり、消化しきれない。

対処：これは進行管理の問題であり、QAだけでは解決できません。現実的にできるのは優先順位を先に決めておくことです。

リスクベースドテストの考え方で、「発生確率 × 影響度」でテスト対象を序列化しておきます。期間が削られたとき、何を落とすかを感覚ではなく事前の合意で決められます。

「削れない」と主張するより、「これを削ります」と提示できる方が交渉になります。

課題5：テストケースの粒度がばらつく

症状：担当者によってテストの細かさが違い、抜けと重複が同時に起きる。

対処：テスト技法を明示的に使うことです。技法は「網羅の基準」を言語化したものなので、使う技法を決めれば粒度が揃います。 次の章で具体的に見ていきます。

設計レビューで使えるテスト技法4つ

ここで挙げる技法は、テスト実行のためだけのものではありません。仕様の抜けを見つける道具として、設計段階で使うのが本題です。

1. 同値分割と境界値分析

用途：数値・日付・文字数の仕様が曖昧なまま実装に進むのを防ぐ。

「1〜100を入力可能」という仕様に対して、境界を並べて確認します。

「100まで」という日本語は、100を含むかどうかが確定しません。 この1点を実装前に確認するだけで、後工程の1件が消えます。詳しくは同値分割と境界値分析にまとめています。

2. デシジョンテーブルテスト

用途：条件が複数絡む業務ロジックの、組み合わせの抜けを見つける。

「会員種別」「購入金額」「クーポン有無」で送料が変わる、といった仕様を表にします。

全ての組み合わせを機械的に並べると、仕様書に書かれていないマスが浮かび上がります。「送料550円」と書いてあるのか、それとも誰も決めていないのか。ここで気づけるかどうかが分かれ目です。詳細は決定表テストの効果的な活用法を参照してください。

3. 状態遷移テスト

用途：ワークフローや承認フローで、「起きてはいけない遷移」を洗い出す。

申請 → 承認 → 完了、というフローがあるとき、正常系の矢印だけでなく、書かれていない矢印を確認します。

• 「完了」から「申請中」に戻せてしまわないか
• 承認者が2人同時に承認したらどうなるか
• 承認待ちのまま申請者が退職（アカウント削除）したらどうなるか
• ブラウザの戻るボタンで前の状態の画面から操作されたら

状態遷移図で「空白のマス」に該当するのが、本番で最も痛い不具合になります。 実践方法は状態遷移テストの実践的な手法にまとめました。

4. ペアワイズテスト

用途：設定項目が多く、全組み合わせを試せないときにケース数を現実的な規模に落とす。

OS 3種 × ブラウザ 3種 × 会員種別 2種 × 通貨 2種 なら全部で36通りですが、2因子間の組み合わせをすべて含むように選ぶと10件前後まで減らせます。不具合の多くは2つの要因の組み合わせで起きる、という経験則に基づく技法です。

期間が削られたときの現実的な削減手段として有効です。詳しくはペアワイズテストの基本と実践方法をどうぞ。

ウォーターフォールでQAが持つべき視点

QAの役割を「不具合を見つける人」と定義すると、ウォーターフォールでは必ず後手に回ります。「仕様が決まっているかを確認する人」と定義し直すと、動ける工程が一気に前に広がります。

具体的には、次の3つを意識して動くと効果があります。

• 「決まっていない」ことを見つけて報告する：バグ票と同じ重さで扱う
• 判断の根拠を残す：なぜこのテストをやり、なぜあれをやらなかったのかを記録する。期間削減の交渉材料になる
• リリース後の情報を上流に戻す：本番で起きた不具合が、どの工程で作り込まれたかを分類する。次のプロジェクトのレビュー観点になる

なお、アジャイル開発ではQAの関わり方が変わります。そちらはアジャイル開発におけるQAの役割に別途まとめています。

まとめ

• ウォーターフォールでは不具合の発見が構造的に遅れる。テストの「設計」を上流に寄せることでしか埋められない
• V字モデルで、各工程の成果物に対応するテストを同時に設計する
• 設計レビューには具体的な問いの形で持ち込む。「未入力のときは？」「上限ちょうどは？」
• 仕様変更に備えて、要件とテストケースの対応表を最初から作る
• 認識のずれは会議ではなく表で潰す（デシジョンテーブル）
• 期間が削られる前に、リスクで優先順位を合意しておく
• テスト技法は設計の抜けを見つける道具として上流で使う

ウォーターフォールだからQAは後工程、と諦める必要はありません。テストケースを書くという行為そのものが、仕様の曖昧さを検出する最も強力な手段です。実装が始まる前にそれをやれば、後半の消耗はかなり減らせます。