アドベントカレンダー１３日目
こんにちは。リリカルです。
次回WACATEの必須予習項目である、テスト技術者のFoundation Levelシラバス 第２章についてまとめていきます。（分量が多くなったため、二回に分けることにしました。）
WACATE2016 夏 満員御礼！と 予習内容について - WACATEブログ
２章を読みながら作成したマインドマップもどきがこちらです。
２章の構成は以下のようになっています。
2.1 ソフトウェア開発モデル
2.2 テストレベル
2.3 テストタイプ
2.4 保守テスト
一つずつ簡単にまとめていきます。
2.1 ソフトウェア開発モデル
ここでは、開発のライフサイクルモデルが異なればテストに対するアプローチも変わってくるということで、ソフトウェア開発モデルについて説明されています。
まず代表的なものがV字モデル（シーケンシャル開発モデル）です。
一般的なV字モデルでは、以下の４つのテストレベルがあります。
- コンポーネントテスト（ユニットテスト）
- 統合テスト
- システムテスト
- 受け入れテスト
次に説明されているのはイテレーティブ - インクリメンタル開発モデルです。
イテレーティブ - インクリメンタル開発モデルは、システムの要件、設計、構築、テストを何回かの短い開発サイクルで繰り返して開発するモデルです。プロトタイピング、RAD(Rapid Application Development)、RUP(Rational Unified Process)、アジャイル開発モデルがこれに該当します。このモデルにおいては、特に回帰テストの重要性が高くなります。
どのようなライフサイクルモデルであっても、各開発活動に対応したテスト活動を行うことや、各テストレベルにおいてそのレベル特有の目的を設定していることが大切です。
2.2 テストレベル
ここでは各テストレベルにおける目的、テストベース、テスト対象などについてまとめられています。一つずつここに示していきます。
コンポーネントテスト
テストベース： コンポーネント要件、詳細設計、ソースコード
テスト対象： コンポーネント、プログラム、データ変換／移行プログラム、データベースモジュール
コンポーネントテストでは、クラスやモジュールなどの欠陥を摘出し、機能の正しさを検証します。スタブ、ドライバなどを利用することで、システムの他の部分と切り離してテストを実施します。
なお、コンポーネントテストに対するアプローチの一つとして、テスト駆動開発やテストファーストがあります。
統合テスト
テストベース： ソフトウェア設計またはシステム設計、アーキテクチャ、ワークフロー、ユースケース
テスト対象： サブシステムのデータベース実装、インフラストラクチャ、インタフェース、システム構成・構成データ
統合テストは、システムの別の部分との相互処理、システム間のインタフェースをテストします。
一般的に、統合の範囲が大きくなればなるほど、欠陥の箇所の特定が困難になります。欠陥の切り分けを容易にするためには、統合は一度に実施するのではなく、少しずつ統合するのが一般的です。
システムテスト
テストベース： システム要求仕様もしくはソフトウェア要求仕様、ユースケース、機能仕様、リスク分析レポート
テスト対象： システム、ユーザとオペレーションマニュアル、システム構成・構成データ
システムテストでは、システムの要求仕様に対して実際の振る舞いが正しいかを確認します。基本的に、本番の環境と可能な限り同じテスト環境で実施します。
また、ここではシステムの非機能要件についても検証する必要がありますが、要件は必ずしもドキュメント化されていないので注意が必要です。
システムテストはその性質上、独立したテストチームが請け負うことが多くなります。
受け入れテスト
テストベース： コンポーネント要件、詳細設計、ソースコード
テスト対象： コンポーネント、プログラム、データ変換／移行プログラム、データベースモジュール
受け入れテストには以下のような種類があります。
- ユーザ受け入れテスト
- 運用受け入れテスト
- 契約による受け入れテスト、および規定による受け入れテスト
- アルファテスト、ベータテスト
受け入れテストはシステムを使う顧客やユーザが実施することが多いです。ステークホルダーが参加することもあります。また、受け入れテストの主目的は欠陥の摘出ではなく、あくまでシステム全体あるいは一部の稼働の確認、非機能特性の検証となります。
次回予告
次回も引き続きFoundation Levelシラバスの２章（後半）をまとめていきます。
