【第二弾】JSTQB Foundation Level試験の勉強

JSTQBについて

ソフトウェア開発モデル

テストは単独では存在せず、テストの対象を作り上げていく開発プロセスの一部になる。

V字モデル
ウォーターフォールモデルは、『分析→設計→開発→テスト』という順に開発が進む。それを上流工程（品質を作り込む工程）と下流工程（品質を確認する工程）を対応づけて、Vの字で表したモデル。上流工程で作成した設計書を元にテストを行う。

イテレーティブーインクリメンタル開発モデル
ウォーターフォールモデルのサイクル（分析→設計→開発→テスト）を何度か繰り返して、ソフトウェアを作る。イテレーション（反復）で開発する単位をどのようにするかは一律に決まっているわけではない。
イテレーティブーインクリメンタル開発の代表的なもの

・プロトタイピング
・RAD
・RUP
・アジャイル開発モデル

プロトタイピング
要件定義の段階でソフトウェアのプロトタイプ（試作品）を作成し、ユーザからのフィードバックを元に仕様を確立した後で、本番開発を行うソフトウェア開発モデル。

RAD
RAD（Rapid Application Development）は、迅速に（rapid）ソフトウェアを作り上げる手法で、GUI作成ツールや自動プログラミング4GLなどのRADツールを用いて開発するスタイルの総称。

RUP
RUP（Rational Unified Process）は、UMLを用いて設計を行い、スパイラル型で開発を進める。

アジャイル開発モデル
無駄な作業を省いて短期間で開発するプロセス。代表的なものはXP（eXtreme Programming）やScrumがある。

コンポーネントテスト

コンポーネントテストは、単体テスト、ユニットテスト、モジュールテスト、プログラミングテストなどと呼ばれることもある。システムの他の部分と切り離してテストを実行できる。

分離可能なソフトウェアに対して、スタブやドライバ、シミュレータなどを用いて、システムの他の部分と切り離してテストを行う。コンポーネントテストは、主にコードを作成した開発者自身が行う。機能テストや非機能テストも行う。

統合テスト

統合テストには大きく分けて２種類のテストがあり、コンポーネント統合テストとシステム統合テストである。

コンポーネント統合テスト
コンポーネントテストの後に行い、コンポーネント間のインターフェースおよび相互処理をテストする。

システム統合テスト
他システムとの間のインターフェースや相互処理に関するテストや、ハードウェアとソフトウェア間の相互処理に関するテストを行う。

システムテスト

システムテストは、システムの機能要件、非機能要件、およびデータの品質特性をテストし、その範囲は、マスターテスト計画やテストレベルごとのレベルテスト計画で定義したシステムのスコープ全体をテストする。

システムテストでは、コンポーネント統合テストを行っていた開発環境でテスト実行することはなく、本番環境（運用環境）とできるだけ近い、可能であれば同じテスト環境で行い、この環境をステージング環境と呼ぶこともある。

受け入れテスト

システムが稼働できるかどうかをテストするためのもので、最後のテストである必要はない。統合テスト、コンポーネントテスト、システムテスト前にも行われる。受け入れテストには以下のような種類がある。

運用受け入れテスト
システム管理者がシステム運用に耐えられるかどうかをテストする。バックアップや災害復旧、データ負荷や脆弱性定期チェックなど。
契約による受け入れテスト
カスタムメイドのプロダクトを開発する場合、契約者に記述した判定条件に従って検証する。
規定による受け入れテスト
法律や安全基準などに合致しているかを検証する。
アルファテスト、ベータテスト（フィールドテスト）
実際に市場へリリースする前に将来のユーザや現在の顧客からフィードバックを受けるために行うテスト。開発チームではない別の開発組織内で実施するのがアルファテスト。顧客または潜在顧客が実施するのがベータテスト。