1.ソフトウェア開発ライフサイクルがテストに与える影響

2.ソフトウェア開発ライフサイクルとよい実践例

3.テストが主導するソフトウェア開発

テストレベルは、系統的にまとめ、マネジメントしていくテスト活動のグループである。各テストレベルは、個々のコンポーネント単位から完成したシステムまで、または必要に応じてシステムオブシステムズまでの開発段階に応じたテストプロセスのインスタンスである。

テストレベルは SDLC 内の他の活動と関連付けられる。シーケンシャルな SDLC モデルでは、テストレベルは、あるレベルの終了基準が次のレベルの開始基準の一部であるように定義されることが多い。いくつかのイテレーティブなモデルにおいては、これは適用されないかもしれない。開発活動は、複数のテストレベルにまたがることがある。テストレベルは、時間的に重なることがある。

テストタイプは、特定の品質特性に関連するテスト活動のグループであり、それらのテスト活動のほとんどは、すべてのテストレベルで実行することができる。

1.テストレベル

本シラバスでは以下の 5 つのテストレベルを説明する：

コンポーネントテスト（ユニットテストとも呼ばれる）は、コンポーネントを単独でテストすることに焦点を当てる。コンポーネントテストは、テストハーネス、またはユニットテストフレームワークのような特定のサポートを必要とすることが多い。コンポーネントテストは、通常、開発者が開発環境で行う。

コンポーネント統合テスト（ユニット統合テストとも呼ばれる）は、コンポーネント間のインターフェース、および相互処理に焦点を当てる。コンポーネント統合テストは、ボトムアップ、トップダウン、ビッグバンといった統合戦略のアプローチに大きく依存する。

システムテストは、多くの場合、エンドツーエンドのタスクに対する機能テストや品質特性に対する非機能テストといったシステムやプロダクト全体の振る舞いや能力の全般に焦点を当てる。一部の非機能品質特性については、本番相当のテスト環境において、すべて揃ったシステムでテストすることが望ましい（例えば、使用性テスト）。サブシステムのシミュレーションを使用することも可能である。システムテストは、システムの仕様に関連するものであり、独立したテストチームによって実施されることがある。

システム統合テストは、テスト対象システムと他のシステム、外部サービスとのインターフェースのテストに焦点を当てる。システム統合テストには、できれば運用環境に近い適切なテスト環境が必要となる。

受け入れテストは、妥当性確認と、デプロイの準備ができていることの実証に焦点を当てる。これは、システムがユーザーのビジネスニーズを満たしていることを意味する。受け入れテストは、想定ユーザーによって実施をすることが理想的である。受け入れテストの主な形式としては、ユーザー受け入れテスト(UAT)、運用受け入れテスト、契約、および規制による受け入れテスト、アルファテストおよびベータテストがある。

テストレベルは、テスト活動の重複を避けるため、以下の代表的な属性のリストで区別する：

・テスト対象
・テスト目的
・テストベース
・欠陥、および故障
・アプローチと責務

2.テストタイプ

テストタイプには多くのものが存在し、プロジェクトに適用することができる。本シラバスでは 4 つのテストタイプを取り上げる。

機能テストでは、コンポーネント、およびシステムが実行する機能を評価する。機能とはテスト対象が「何」をすべきかである。機能テストの主な目的は、機能完全性、機能正確性、および機能適切性をチェックすることである。

非機能テストでは、コンポーネント、およびシステムが実行する機能特性以外の属性を評価する。非機能テストは、システムが「どのようにうまく振る舞うか」をテストする。非機能テストの主な目的は、非機能的なソフトウェア品質特性をチェックすることである。ISO/IEC 25010 標準では、非機能ソフトウェア品質特性について、以下のように分類している：

・性能効率性
・互換性
・使用性
・信頼性
・セキュリティ
・保守性
・移植性

非機能テストは、ライフサイクルの早期（例えば、レビューやコンポーネントテスト、システムテストの一部として）に開始するのが適切な場合もある。多くの非機能テストのテストケースは、同じ機能テストのテストケースを使用するため、機能テストのテストケースから導出する。ただし、機能

メンテナンスにはさまざまなカテゴリーがある。メンテナンスには、修正を伴うもの、環境の変化に適応するもの、パフォーマンスや保守性を改善するもの（詳細は ISO/IEC 14764 を参照）などがある。そのため、計画的なリリース/デプロイと計画外のリリース/デプロイ（ホットフィックス）が含まれる。システムの他の領域への潜在的な影響に基づき変更をするべきかどうかを判断するために、変更をする前に影響度分析を行うことがある。本番稼働中のシステムに対する変更のテストには、変更の実装の成功を評価することと、変更されないシステムの部分（通常はシステムの大部分）で起こりうるリグレッションをチェックすることの両方が含まれる。

メンテナンステストの範囲は、典型的には次に依存する：

・変更のリスクの度合い
・既存システムの大きさ
・変更の大きさ

メンテナンスのきっかけやメンテナンステストのきっかけは、以下のように分類する：

・計画的な機能拡張（すなわち、リリースベース）、修正を伴う変更またはホットフィックスと
いった改良。
・あるプラットフォームから別のプラットフォームへといった運用環境の更新、または移行。
新しい環境や変更されたソフトウェアに関連するテストが必要となる場合があり、別のアプリ
ケーションのデータを保守しているシステムに移行する場合は、データ変換のテストが必要と
なる。
・アプリケーションの寿命などによる廃棄。

システムを廃棄する際、長期間のデータ保持が要件となる場合は、データアーカイブのテスト
が必要となることがある。また、アーカイブ期間中にデータの取得が必要な場合は、アーカイ
ブ後の復元や取得手順のテストも必要になることがある。