Vietnamese
Englishソフトウェア開発モデルにおけるテストの特徴
テストには共通の原則がありますが、ソフトウェア開発ライフサイクルモデルにより違いもあります。ここでは「シーケンシャル開発モデル」と「イテレーティブ・インクリメンタル開発モデル」に分けて、それぞれのテストの特徴を説明します。
シーケンシャル開発モデル
シーケンシャル開発モデルは、ソフトウェア開発の各活動を順番に進めるプロセスです。たとえば、要件定義が完了しないと次の設計フェーズに進めないという原則に従います。通常、コーディング完了後にテストを開始し、順序通りにコンポーネントテストから統合テストへと進みますが、実際にはフェーズが重複することもあります。この手法は「五月雨」や「刺身」とも呼ばれます。
ここでは、ソフトウェア開発モデルの基本であるウォーターフォールモデルとそれを基にしたV字モデルについて説明します。
ウォーターフォールモデル
「ウォーターフォールモデル」は、最も伝統的で一般的なソフトウェア開発モデルです。他にも多くの開発モデルが存在しますが、その多くはウォーターフォールモデルを基に改良されています。
このモデルでは、要件定義、設計、コーディング、テストといった各開発工程を順番に進め、各工程が完了してから次の工程に移ります。名前の「ウォーターフォール（滝）」の通り、開発の流れを水の流れに例えることが多く、初期段階の要件定義や設計を「上流」、後半のテスト工程を「下流」と呼ぶことがあります。
V字モデル
V字モデルは、ウォーターフォールモデルの上流工程と下流工程を対応させ、アルファベットの「V」字の形で表現したモデルです。テスト工程では、上流工程で定義された仕様や設計に沿ってシステムが動作するかを確認します。そのため、V字モデルの左側の上流工程を「品質を作り込む工程」、右側の下流工程（テスト）を「品質を確認する工程」と呼ぶことがあります。
V字モデルの利点は、上流の各工程が具体的にどのテストレベルに対応するかが明確であることです。たとえば、V字モデルでは、基本設計工程で作成された基本設計書をもとに統合テストの分析や設計が行われます。
また、上流工程での成果物が正しく記述されているかは、レビューによって確認されます。各工程では、前の工程で作成された成果物を基にして次の成果物を詳細化し、その過程で整合性や記述内容を検証して品質を高めます。また、ユーザーの要求に適しているかどうかも確認します。こうした検証と妥当性確認は「V&V（Verification & Validation）」と呼ばれます。
ウォーターフォールモデルの欠点
ウォーターフォールモデルでは、各工程の終了時にその成果物が問題ないことを確認してから次の工程に進みます。基本的に、滝のように順番に進むため、原則として後戻りはしません。しかし、後の工程で前の工程で見逃された問題が発覚することがあります。この場合、「手戻り」と呼ばれる、前の工程に戻って成果物や関連する他の成果物を修正する作業が必要となります。
例えば、システムテストで要件定義のミスが見つかった場合、要件定義の修正だけでなく、それに基づく設計やコーディングの修正も必要です。さらに、ユニットテストや統合テストも修正内容に応じてやり直す必要があります。
このように、ウォーターフォールモデルは仕様変更への対応が難しいという欠点があります。特に、開発初期に要件が固まらず、後の工程で仕様変更が多く発生するようなプロジェクトには不向きです。
Wモデルとシフトレフト
V字モデルには、上流工程とテストの対応が明確であるという利点がある一方で、テストが開発後半に実施されるように見えてしまう欠点があります。実際にはテストの一部が上流工程でも行われることが多いですが、モデルだけでは誤解を招く可能性があります。
そこで、上流工程と並行してテスト活動が行われることを明確化した「Wモデル」が提案されました。このモデルでは、上流工程と同時進行でテスト計画や設計が行われ、テストからのフィードバックによって成果物の品質向上が期待できます。また、テスト活動を早期に行うことで、開発期間の短縮も図れます。
さらに、Wモデルにモデル検査を取り入れると、上流工程でモデルの検査や実行が可能になり、テストを初期段階で実施する「シフトレフト」の一環として活用できます。
イテレーティブ開発モデルとインクリメンタル開発モデル
前述のシーケンシャル開発モデルでは、開発に数か月から数年を要するため、プロジェクトの完成までに時間がかかるという問題があります。この課題を解決し、短期間でプロジェクトを提供できるのがイテレーティブ開発モデルとインクリメンタル開発モデルです。これら二つのモデルは異なりますが、実際にはよく併用されます。それぞれの特徴について以下に説明します。
インクリメンタル開発モデル
「インクリメンタル」という言葉は「増加する」や「漸進的な」という意味を持ちます。したがって、インクリメンタル開発モデルは、段階的に機能を追加していく開発方法を指します。ここで言う「増やす」とは、ソフトウェアの「フィーチャー」を指します。フィーチャーは日本語で「機能」や「特徴」と訳されますが、英語のfunctionはメール機能や録画機能のような特定の機能を示すのに対し、featureは「メールにファイルを添付できる」「一度に多数の人にメールを送れる」といった具体的な特性を指します。開発するシステム全体を、いくつかのフィーチャーのグループに分け、それらを開発対象として要件の定義からテストまでを進めます。
イテレーティブ開発モデル
「イテレーティブ」とは「反復的な」という意味です。シーケンシャル開発モデルが要件定義からテストまでを一度で行うのに対し、イテレーティブ開発モデルは仕様化、設計、構築、テストを繰り返します。このプロセスを「イテレーション」と呼び、各イテレーションごとに動作するソフトウェアが生成されます。これらの開発モデルはしばしば併用されます。
主なイテレーティブ開発モデルには以下の4つがあります。
- ラショナル統一プロセス （RUP）：IBMが提唱する手法で、アプリケーション開発の全ライフサイクルをカバー。イテレーションは２〜３か月。
- スクラム：アジャイル開発手法の一つで、チームが一体となって目的に向かう。イテレーションは数日から数週間で、スプリントと呼ばれる。
- カンバン：トヨタの生産方式を基にした手法で、タスクを可視化して効率的に進める。イテレーションは必須ではない。
- スパイラル（プロトタイピング）：初期段階でプロトタイプを作成し、フィードバックをもとに仕様を確定する。フィーチャーを徐々に追加することが特徴。
イテレーティブ/インクリメンタル開発モデルとシフトレフト
これらの開発モデルを使用すると、ソフトウェアを小さな単位に分割し、各単位の開発を繰り返します。各イテレーションではテストが実施されるため、テストの時期が前倒しされ、シフトレフトが実現されます。図2.4には、V字モデルによる開発が示されていますが、実際には以下のようなケースもあります。
- 要件定義、設計、コーディング、テストが同時に行われる。
- ユニットテストと統合テストが並行または反復して実施される。
- システムテストや受け入れテストが独立したイテレーションとして実施される。
短期間のイテレーションでテストを繰り返すため、テストの自動化が望ましく、継続的インテグレーションや継続的デリバリーの環境を整えることが重要です。各イテレーション終了時にはいくつかのフィーチャーが作成されますが、リリースのタイミングは特に決まっていません。最低限のフィーチャーが揃った段階でリリースすることもあれば、すべてのフィーチャーが完成するまで待つこともあります。ただし、早期リリースを行い、顧客からのフィードバックを得ることが推奨されます。
状況に応じたソフトウェア開発ライフサイクルモデル
前項では、シーケンシャル、イテレーティブ、インクリメンタルの各開発モデルについて説明しました。では、どのモデルを選ぶべきかを決める際には、次の点を考慮する必要があります。
- プロジェクトのゴール
- 開発するプロダクトの種類
- ビジネス上の優先度（市場投入までの時間）
- 識別したプロダクトリスク
- 識別したプロジェクトリスク
リスクの低いシステム（例：企業内管理システム）と高いシステム（例：自動車のブレーキ制御システム）では、テストアプローチが異なります。イテレーティブ開発モデルを採用する際は、チームメンバー間の円滑なコミュニケーションが重要ですが、会社の文化や契約形態がそれを妨げる場合があります。
ソフトウェア開発ライフサイクルモデルの組み合わせ
前項で説明したインクリメンタル開発モデルでは、プロジェクト内で両方のモデルを使うこともあります。例えば、スマートフォンアプリの開発では、フロントエンドのユーザーインターフェース（UI）にイテレーティブとインクリメンタルモデルを使用し、迅速にリリースしますが、バックエンドの大規模システムにはシーケンシャルモデルを用います。
また、IoT（モノのインターネット）システムでは、さまざまなデバイスやサービスが個別に開発され、開発対象に応じたモデルが選ばれます。そのため、一部のデバイスが頻繁にバージョンアップする一方で、他のプロダクトは長期間変更されないことがあります。これにより、異なるバージョン間でシステムの連携に問題が生じる可能性があり、運用や更新、廃止フェーズでも相互運用性に注意が必要です。
※練習問題：