ソフトウェア開発ライフサイクルにおけるテスト

ソフトウェア開発ライフサイクル (SDLC) における役割

テスト戦略を定義する際、テストアナリストはSDLC全体を考慮する必要があります。開発モデルによって、テストアナリストが関与するタイミングや方法は大きく異なります。

また、テストアナリストは他の関連組織へ以下のような情報を提供します。

要求エンジニアリング: 要件レビューのフィードバック
プロジェクトマネジメント: スケジュールに対する入力
ソフトウェア開発: 検出された欠陥の通知

開発モデルによるアプローチの違い

シーケンシャルモデル (V字モデルなど): プロジェクト計画と同時にテスト計画を始め、システム要件仕様や設計仕様に沿ってテスト分析および設計を行います。
アジャイルソフトウェア開発: 開発初期からテストを行い、チーム全体で協力してテストを実施します。包括的なドキュメント作成よりも、日々の頻繁なコミュニケーションを重視します。

補足

シラバスの記載は、「ソフトウェアの開発手法（SDLC：ソフトウェア開発ライフサイクル）が違えば、テストアナリストがいつ・どのようにテスト活動を行うか（タイミングや関わり方）も変わる」ということを説明しています。

全体をひとことで言うと、 「テストアナリストは『決められた役割』に固執するのではなく、プロジェクトの開発手法に合わせて柔軟に動き方を変えましょう」 というメッセージです。

シラバスで挙げられている3つの代表的な開発モデルについて、図解を交えながらわかりやすく解説します。

【図解】開発モデルごとのテスト活動のタイミング

1. シーケンシャル（V字）モデル： フェーズごとに順番に進む
[要件定義] ──── [ハイレベル設計] ──── [ローレベル設計] ──── [コーディング]
    │                 │                   │                  │
テスト計画        テスト分析              テスト設計           テスト実装(環境構築)
    │                 │                   │                  │
    └─────────────────┴───────────────────┴──────────────────→ [テスト実行] ─→ [テスト完了]


2. イテレーティブ（反復）／インクリメンタル（漸進）モデル： 小さなサイクルを繰り返す
[プロジェクト全体の計画]
   │
   ├─ [ イテレーション 1 ] (要件確認→設計→開発 ＋ テスト分析・設計・実装・実行)
   │
   ├─ [ イテレーション 2 ] (要件確認→設計→開発 ＋ テスト分析・設計・実装・実行)
   │
[プロジェクト全体の完了]


3. アジャイルソフトウェア開発： 常に同時並行で進む
[プロジェクト開始] ══════════════════════════════════════════════════ [リリース]
  開発の初期段階から、設計・コーディング・テストが常に同時並行で継続的に行われる。
  （テストアナリストも最初から最後までチームと密にコミュニケーションを取りながら活動する）

各モデルの詳しい解説

1. シーケンシャルなV字モデルの場合

水が上から下へ流れるように、開発が順番に進む昔ながらのモデルです。テスト実行自体は後半に行われますが、テストの「準備」は開発と並行して早い段階から行います。

テスト計画: プロジェクト計画が始まったら、同時にテストの計画も始め、最後までコントロールし続けます。
テスト分析・設計: 「要件仕様書」や「設計書」などのドキュメントが出来上がってきたら、それに沿ってテストの分析や設計を行います。
テスト実装（環境構築など）: システム設計の段階で着手することもありますが、メインの作業はプログラマーが「コーディング」をしている裏で並行して行います。テスト実行の数日前までバタバタと環境構築が続くこともよくあります。
テスト実行: 前段階のテスト（コンポーネントテストなど）が終わり、テスト開始基準を満たしたら実行を始めます。

2. イテレーティブモデル・インクリメンタルモデルの場合

ソフトウェア全体を一度に作るのではなく、小さな単位（イテレーション）に分けて、作ってはテストする、を繰り返すモデルです。

活動の繰り返し: 全体の「計画」は最初に行い、「完了」活動は最後に行いますが、テストのコア活動である「分析・設計・実装・実行」のセットは、各イテレーションの中で毎回繰り返されます。

3. アジャイルソフトウェア開発（およびハイブリッド）の場合

要件が変化することを前提に、関係者と密にコミュニケーションを取りながら進める最も柔軟なモデルです。

最初からテストを行う: 開発者が最初のアーキテクチャや設計を考え始めた「一番最初」の時点からテスト活動を始めます。
ドキュメントよりコミュニケーション: 分厚いテスト仕様書を作ることは少なく、手短で頻繁なコミュニケーションでテストを進めます。
役割の境界が曖昧: 「テストアナリスト」という専任の役割が明確にないこともあり、チーム全体で協力してテストタスクをこなします。
ハイブリッドの場合: V字モデルとアジャイルを組み合わせたようなプロジェクトでは、テストアナリストは最初は「計画や設計」にしっかり関与し、開発が進むにつれてチームと密に連携する「対話的（インタラクティブ）」な役割へと動き方を変えていく必要があります。