はじめに

1章3章5章に引き続き2章を読んでみました。シラバスの内容について「これ大事だな」と思うもの独断と偏見で記述し、「特に大事だな」と思うものboldにしています。

ソフトウェア開発ライフサイクルモデル

ソフトウェア開発とソフトウェアテスト

どのようなソフトウェア開発ライフサイクルモデルにも、よいテストを行うときの特徴がいくつかある。

各開発活動に対応してテスト活動がある。
各テストレベルには、そのレベル特有の目的がある。
各テストレベルのテスト分析や設計は、対応する開発活動の間に開始する。
テスト担当者は要件と設計を定義および洗練する討議に参加し、作業成果物(要件、設計、ユーザーストーリーなど)のドラフトができたらすぐにそのレビューに関与する。

早期テストのテスト原則に従い、どのようなソフトウェア開発ライフサイクルモデルであるかに関係なく、テスト活動はライフサイクルの早い段階に開始すべきである。

一般的なソフトウェア開発ライフサイクルモデルの特徴

シーケンシャル開発モデル
- 特徴
  - 要求仕様からメンテナンスまでのソフトウェア開発ライフサイクル活動を表現したフレームワーク。
  - ソフトウェア開発プロセスを順次実行する活動として表す。これは、開発プロセスのあらゆるフェーズが直前のフェーズの完了とともに始まることを意味する。理論的にはフェーズが重なることはないが、実際には、後続のフェーズからフィードバックを早期に行うのが効果的である。
  - フィーチャーが完全に揃ったソフトウェアを提供するが、ステークホルダーやユーザーが利用できるまでには、典型的に数か月から数年を要する。
- シーケンシャルモデルの例
  - ウォーターフォールモデル
    - 開発活動(要件分析、設計、コーディング、テストなど)は、逐次完了する。このモデルでは、テスト活動はその他の開発活動がすべて完了した後に実行する。
  - V字モデル
    - ウォーターフォールモデルと異なり、開発プロセス全体にテストプロセスを統合しており、早期テストの原則を実装している。早期テストの裏付けとして、各開発フェーズにテストレベルが対応している。テスト実行は、関連付けられているテストレベルごとに順次進めていくが、重複することもある。
イテレーティブ開発モデルとインクリメンタル開発モデル
- インクリメンタル開発
  - システムを分割し、分割単位ごとに要件の確定、設計、構築、テストを行う。増加させていくフィーチャーの分割単位の大きさは手法によってさまざま。
- イテレーティブ開発モデル
  - グループにしたフィーチャー群を、一連のサイクルの中で一緒に仕様化、設計、構築、テストする。各イテレーションでは、動作するソフトウェアが提供される。提供されるソフトウェアは、段階的にフィーチャーを追加して成長させていく。完成したソフトウェアが提供されるか、開発が中止するまでイテレーションを継続する。
- イテレーティブ開発モデルとインクリメンタル開発モデルの例
  - ラショナル統一プロセス(RUP)
    - 各イテレーションは他と比べて長期(例えば2~3か月)になる傾向にあり、フィーチャー増分は、関連するフィーチャーで構成するいくつかのグループなど、期間に対応して大きくなる傾向にある。
  - スクラム
    - 各イテレーションは他と比べて短期(例えば、数時間、数日、数週間)になる傾向にあり、フィーチャーの増分は、わずかな機能強化、いくつかの新しいフィーチャーなど、小さくなる傾向にある。
  - カンバン
    - イテレーションの期間の長さが固定されているかどうかに関係なく実装できるので、完了時に単一の機能強化やフィーチャーをリリースすることも、複数のフィーチャーをまとめて一括してリリースすることもできる。
  - スパイラル
    - 増分を試行しながら追加する。増分は、後続の開発作業で大幅に作り直すことも破棄することもある。
- これらの手法は、システムの段階的な成長を可能にする。システムが成長するにつれてリグレッションテストの重要性は増大する。

テストレベル

コンポーネントテスト

別名：ユニットテストまたはモジュールテスト

目的
- リスクの軽減
- コンポーネントの機能的/非機能的振る舞いが設計および仕様通りであることの検証
- コンポーネント品質に対する信頼の積み上げ
- コンポーネントに存在する欠陥の検出
- 欠陥がより高いテストレベルまで見逃されることの防止
特徴
- 特にコード変更が継続して行われるインクリメンタル開発モデルやイテレーティブ開発モデルでは、コンポーネントテストのリグレッションテストを自動化して、変更が既存のコンポーネントを破壊していないという信頼を積み重ねていくことが重要である。
- ソフトウェア開発ライフサイクルモデルやシステムの特性により、システムの他の部分と切り離したテストが可能である。この場合、モックオブジェクト、サービス仮想化、ハーネス、スタブ、ドライバーなどを使う。
- 検出した欠陥は、形式に沿った欠陥マネジメントを行わず、見つけたらすぐに修正するのが一般的である。ただし、開発担当者が欠陥を報告すると、根本原因分析やプロセス改善にとって重要な情報が得られることになる。
典型的な欠陥と故障的な欠陥と故障の例
- 正しくない機能(例えば、設計仕様の記述とは異なる)
- データフローの問題
- 正しくないコードとロジック
アプローチと責務
- コードを開発した開発担当者が行うことが一般的である。
- コンポーネント用のコードを記述した後で、テストを記述し実行することが多い。
  - ただし、特にアジャイル開発では、アプリケーションコードを記述する前に、自動化されたコンポーネントのテストケースを記述する場合がある。例えば、テスト駆動開発(TDD)のサイクルは、自動化されたテストケースの開発、小規模なコードの構築と統合、コンポーネントテストの実行、問題の修正、コードのリファクタリングで構成される。このプロセスは、コンポーネントを完全に構築し、すべてのコンポーネントテストが合格となるまで継続する。テスト駆動開発は、テストファーストアプローチの一例である。

結合テスト

目的
- リスクの軽減
- インターフェースの機能的/非機能的振る舞いが設計および仕様通りであることの検証
- インターフェース品質に対する信頼の積み上げ
- 欠陥の検出(インターフェース自体、コンポーネントに内在、またはシステムに内在)
- 欠陥がより高いテストレベルまで見逃されることの防止
特徴
- コンポーネントテストと同様に、統合テストのリグレッションテストを自動化する場合があり、自動化したリグレッションテストにより、変更が既存のインターフェース、コンポーネント、システムを破壊しないという信頼を提供できる。
2 つの異なるレベル
- コンポーネント統合テスト
  - 統合するコンポーネント間の相互処理とインターフェースに焦点をあててテストする。コンポーネントテストの後に実施し、自動化するのが一般的である。イテレーティブ開発およびインクリメンタル開発では、CIのプロセスの一環として行うことが一般的である。
- システム統合テスト
  - システム、パッケージ、マイクロサービス間の相互処理とインターフェースに焦点をあててテストする。外部組織(Webサービスなど)との相互処理、または外部組織により提供されるインターフェースをカバーすることもある。システムテストの後、または実行中のシステムテスト活動と並列に行う。
統合テストの典型的な欠陥と故障の例
- 正しくないデータ、データ不足、正しくないデータエンコーディング
- インターフェース呼び出しの正しくない順序またはタイミング
- インターフェースの不整合
- コンポーネント間のコミュニケーション故障/システム間通信による故障
- コンポーネント間のコミュニケーション故障/システム間通信による故障の処理不在、または不適切な処理
- コンポーネント間/システム間で渡されるデータの意味、単位、境界の正しくない思い込み
アプローチと責務
- コンポーネント統合テストとシステム統合テストは統合だけに集中すべきである。
  - モジュールAとモジュールBの統合をテストする場合、コンポーネントテストでカバー済みの個々のモジュールの機能ではなく、2つのモジュール間のコミュニケーションに焦点をあてる必要がある。
  - システムXとシステムYの統合をテストする場合、システムテストでカバー済みの個々のシステムの機能ではなく、2つのシステム間のコミュニケーションに焦点をあてる必要がある。
- 機能テスト、非機能テスト、構造テストは統合テストで行うことができる。
- コンポーネント統合テストは開発担当者が実行するのが一般的である。システム統合テストはテスト担当者が実行するのが一般的である。理想的には、システム統合テストを実行するテスト担当者はシステムアーキテクチャーを理解すべきであり、統合計画の作成に関与すべきである。
- 統合の範囲が大きくなるほど、欠陥を特定のコンポーネントまたはシステムに絞り込むことが難しくなる。これによりリスクが増え、トラブルシューティングの時間が増大する。

システムテスト

目的
- リスクの軽減
- システムの機能的/非機能的振る舞いが設計および仕様通りであることの検証
- システムが完成し、期待通りに動作することの妥当性確認
- システムの全体的な品質に対する信頼の積み上げ
- 欠陥の検出
- 欠陥がより高いテストレベルまたは運用環境まで見逃されることの防止
特徴
- システムが実行するエンドツーエンドのタスクと、タスクの実行時にシステムが示す非機能的振る舞いといったシステムやプロダクト全体の振る舞いや能力に焦点をあてる。
典型的な欠陥と故障
- 正しくない、または期待通りではないシステムの機能的または非機能的振る舞い
- システム内の正しくない制御フロー、データフロー
- エンドツーエンドの機能的タスクを適切かつ完全に実行できない
- システムマニュアルおよびユーザーマニュアルに記載されている通りにシステムが動作しない
アプローチと責務
- システムテストは通常、独立したテストチームが仕様を頼りにして行うことが多い。
- 仕様の欠陥は、システムの期待される振る舞いに関する正しい理解の欠落や誤解につながる。この状況が偽陽性や偽陰性の結果を招き、時間の浪費や欠陥検出効率の低下となる。テスト担当者がユーザーストーリーを洗練する活動およびレビューなどの静的テストの活動に早期から関与することで、このような状況が起きることを削減できる。

受け入れテスト

目的
- システムテストと同様、一般的にシステムやプロダクト全体の振る舞いや能力に焦点をあてる。
  - 全体的な品質に対する信頼の積み上げ
  - 機能的/非機能的振る舞いが仕様通りであることの検証
特徴
- 受け入れテストからの情報に基づいて、システムが導入に向けて準備できているかどうか、および顧客(エンドユーザー)が使用できるかを評価できる。受け入れテストで欠陥が見つかることはあるが、欠陥を見つけることは目的ではない。とても多くの欠陥が受け入れテスト時に検出されるような事態は、重要なプロジェクトリスクと見なすことができる。
受け入れテストの一般的な形態
- ユーザー受け入れテスト
  - 意図されているユーザーが本番環境または模擬運用環境にて、想定しているシステムの使用方法と合致していることを確認する。
  - 主目的は、システムの使用において、システムがユーザーニーズに合致し、要件を満たし、最小限の困難さ、コスト、リスクでビジネスプロセスを実行できるという信頼を積み重ねることである。
- 運用受け入れテスト
  - 運用担当者またはシステムアドミニストレーターが、運用環境で(例外的な状況/困難な状況であっても)ユーザー向けにシステムを適切な稼動状態に維持できるという信頼を積み重ねることである。
  - (模擬)本番環境で行うのが一般的である。
- 契約による受け入れテスト
  - カスタムメイドのソフトウェアを開発する場合に、契約書に記述した受け入れ基準に従って行う。受け入れ基準は、契約時に当事者間で合意している。
  - ユーザーまたは独立したテスト担当者が行うことが多い。
  - 契約に準拠しているという信頼を積み重ねることである。
- 規制による受け入れテスト
  - 政府、法律、安全の基準などに合致しているかを確認する。
  - ユーザーまたは独立したテスト担当者が行うことが多いが、規制機関が結果を証明または監査する場合もある。
  - 規制に準拠しているという信頼を積み重ねることである。
- アルファテストおよびベータテスト
  - 市販ソフトウェア(COTS)の開発担当者がソフトウェアプロダクトを市場へリリースする前に、顧客/システムの運用者からフィードバックを受けるために行う。
  - システムが使われる環境(特に、開発チームでは再現できない状況や環境)での欠陥を検出することも目的の1つである。
  - アルファテストは、開発組織内にて開発チームの代わりに潜在的または既存の顧客、システムの運用者もしくは独立したテストチームが行う。
  - ベータテストは、潜在的または既存の顧客、システムの運用者が彼ら自身の作業場所で行う。ベータテストはアルファテストの後に行うことも、アルファテストなしに行うこともある。
さまざまな形態の受け入れテストで典型的な欠陥と故障の例
- システムのワークフローがビジネス要件またはユーザー要件を満たさない。
- ビジネスルールが正しく実装されていない。
- システムが契約要件または規制要件を満たさない。
- セキュリティの脆弱性、高負荷時の不適切な性能効率、サポート対象プラットフォームでの不適切な操作などの非機能特性の故障。
アプローチと責務
- 受け入れテストは、顧客、ビジネスユーザー、プロダクトオーナー、システムの運用担当者の責任で行われる。他のステークホルダーも関与することがある。

テストタイプ

ソフトウェアの特性をテストするための活動を束ねたもの。

機能テスト

システムが実行する機能を評価する。機能とはシステムが「何を」すべきかである。すべてのテストレベルで行うべき。
機能カバレッジを用いてテストが十分かを計測できる。機能カバレッジは、テストした機能の範囲を示し、カバーした要素の種類の割合で表す。

非機能テスト

システムやソフトウェアの使用性、性能効率性、セキュリティといった特性を評価する。システムが「どのように上手く」振る舞うかをテストする。
一般的に誤解されているが、非機能テストはすべてのテストレベルで行うことができる。そして可能な限り早期に行うべきである。
非機能カバレッジを用いてテストが十分かを計測できる。非機能カバレッジは、テストした非機能要素の種類の範囲を示し、カバーした要素の種類の割合で表す。

ホワイトボックステスト

システムの内部構造や実装に基づいてテストを導出する。
コンポーネントテストレベルでは、コードカバレッジで計測できる。コンポーネント内のテスト済みのコードの割合に基づき計測できる。
コンポーネント統合テストレベルでは、テストで実行済みのインターフェースの割合で計測できる。

変更関連のテスト

システムに対する変更をした場合に行うテスト。

確認テスト
- 欠陥が確実に修正されたことの確認。
リグレッションテスト
- 変更後に意図しない副作用を検出する。 確認テストとリグレッションテストは、すべてのテストレベルで行う。

感想

ある程度はすでに知っている内容でした。ただ、テストレベルの違いが曖昧だったので、そこを改めて知ることができ良かったです。

徒然なるままに

学習メモがメインです

JSTQBFL2章のまとめ