ソフトウェア開発のテスト工程について

テスト工程の流れ

ウォーターフォール型開発ではテスト工程は1つにまとめられていますが、実際にはいくつかの工程に分けられています。V字モデルに沿って、各テスト工程の概要を説明します。

単体テスト

単体テストは、ソフトウェア開発プロセスの中で行われるテストの一種であり、個々のコンポーネントやモジュールが期待通りに動作するかを検証するテストです。
　
単体テストの特徴：

• 個々のコンポーネントやモジュールを分離してテストします。
• 通常、ユニットテストとも呼ばれます。
• 開発者が主に行います。
• コードの機能や振る舞いをテストするためのテストケースを作成し、そのテストケースを実行して検証します。
  　

単体テストの流れ：

1. テストケースの設計:
   各コンポーネントやモジュールに対するテストケースを設計します。これには、入力値や期待される出力値を定義します。
   　
2. テストの実行:
   設計したテストケースを実行し、実際の出力が期待値と一致するかどうかを確認します。
   　
3. テスト結果の検証:
   テストの実行結果を評価し、問題があれば修正が必要かどうかを検討します。
   　
4. 問題の解決:
   発見された問題を修正し、再度テストを実行して問題が解決されたことを確認します。
   　
5. テストの終了:
   全てのテストケースがパスし、コンポーネントやモジュールが期待通りに動作することが確認されたら、単体テストを終了します。
   　

結合テスト ・ 機能テスト

結合テスト

結合テストとは、ソフトウェア開発プロセスにおけるテストの一種であり、複数のモジュールやコンポーネントを組み合わせてそれらが連携して正しく動作するかを検証するテストです。個々のモジュールが単独で正しく機能することが確認された後に、それらを結合し全体のシステムの動作を確認します。
結合テストは、個々のモジュールの単体テストを通過した後に行われます。結合テストでは、異なるモジュール間のインターフェースやデータのやり取りや相互の依存関係などを検証し、全体のシステムの正常な動作を確認します。

機能テスト

機能テストは、ソフトウェアがユーザーの要求や期待通りの機能を持っているかを検証するテストです。つまり、システムが指定された要件や仕様に沿って正しく動作するかどうかを確認します。機能テストでは、ユーザーが利用するシナリオやユースケースを再現し、システムの各機能が正常に動作するかどうかをテストします。機能テストは、システム全体の機能を対象とする場合もあれば、特定の機能やモジュールを対象とする場合もあります。機能テストは、ソフトウェアの品質やユーザー満足度を確保するために重要なテストの一つです。

システムテスト

システムテストは、ソフトウェア開発プロセスの最終段階で行われるテストの一種です。このテストでは、開発されたソフトウェアが全体として正常に動作し、要求された機能や要件を満たしているかを検証します。システムテストは、ユーザーが利用する実際のシナリオやユースケースを再現し、システム全体の機能や性能、セキュリティ、信頼性などをテストします。
システムテストの特徴は次のとおりです。

1. 総合的なテスト：
   システムテストでは、開発されたソフトウェアの全体像を把握し、システム全体の機能や性能を総合的にテストします。個々のコンポーネントやモジュールの動作だけでなく、それらが組み合わさった際の相互作用もテストします。
   　
2. 要件の検証：
   システムテストでは、要求された機能や要件が実装されており、システムがユーザーの要求を満たしているかどうかを検証します。要件定義や仕様書と照らし合わせながら、システムが正しく動作していることを確認します。
   　
3. ユーザーの視点：
   システムテストでは、ユーザーが利用する実際の状況やシナリオを想定し、ユーザーの視点からシステムをテストします。ユーザーの利便性や使いやすさ、応答速度などもテストの対象となります。
   　
4. 統合テストとの関連：
   システムテストは、統合テストの後に行われることが一般的です。統合テストで個々のコンポーネントやモジュールの動作が確認された後に、それらが組み合わされた際のシステム全体の挙動を確認するためにシステムテストが行われます。
   　

ソフトウェアの内部構造に関するテスト

「ソフトウェアの内部構造に注目する、しない」を基準にして分類すると、大きくブラックボックステストとホワイトボックステストに分類されます。
　
ブラックボックステスト
ブラックボックステストは、ソフトウェアの内部構造や実装の詳細に関係なく、ソフトウェアの機能や動作を検証するテスト手法です。
つまり、テストを行う際にソフトウェアを「ブラックボックス」と見なし、外部からの入力と出力のみを考慮します。
　
ホワイトボックステスト
ホワイトボックステストは、ソフトウェアの内部構造や実装の詳細を知っている状態で、その内部を検証するテスト手法です。
つまり、テストを行う際にソフトウェアを「ホワイトボックス」と見なし、内部のコードやロジックに焦点を当てます。
　

ソフトウェアの動作に関するテスト

「ソフトウェアを動作させてテストする・しない」を基準にして分類すると、大きく静的テストと動的テストに分類されます。
　
静的テスト
静的テストは、コードやドキュメントなどのソフトウェアの成果物を対象に、実際に実行せずに検証を行うテスト手法です。通常、静的テストは開発工程で行われます。

• コードレビュー
  チームメンバーや専門家がコードを分析し、バグや潜在的な問題を特定します。
  　
• ウォークスルー
  チームがドキュメントや仕様を読み、問題や疑問を議論します。

　
動的テスト
動的テストは、実際にソフトウェアを実行し、その動作や機能を検証するテスト手法です。通常、動的テストはテスト工程で行われます。

テスト工程とテストフェーズについて

テストには、テスト全体計画とテスト個別計画があります。

以下にそれぞれの説明を記述します。

テスト全体計画

テスト全体計画は、ソフトウェア開発プロジェクトにおけるテスト活動全体を計画するための文書または計画書です。テスト全体計画は、ソフトウェアの品質を確保し、テストプロセスを効果的に管理するための指針や戦略を提供します。
テスト全体計画は、プロジェクトのテスト活動を統括し、効果的なテストプロセスの実行を支援する重要な文書です。

1. 目的と範囲:
   テスト全体計画では、テスト活動の目的と範囲を明確に定義します。プロジェクトの目標や要求を考慮し、テストがカバーすべき範囲を明示します。
   　
2. テスト戦略:
   テスト全体計画は、テスト戦略を策定するための基盤となります。テスト戦略は、テストのアプローチや方法、リソースの割り当て、スケジュールなどを定義します。
   　
3. テストスケジュール:
   テスト全体計画には、テストのスケジュールが含まれます。テストの開始日、終了日、重要なマイルストーンなどが明確に記載されます。
   　
4. リソース管理:
   テスト全体計画では、テストに必要なリソース（人員、ツール、環境など）の管理方法が記述されます。リソースの割り当てや管理責任者などが明確に定義されます。
   　
5. リスク管理:
   テスト全体計画には、テストに関連するリスクの特定と管理方法が含まれます。テストの障害や問題に備えるための対策や計画が策定されます。
   　
6. 品質基準:
   テスト全体計画は、品質基準やテストの合格基準を定義します。テストが満たす必要のある品質の基準や期待される成果物の品質に関する情報が含まれます。
   　
7. 報告とコミュニケーション:
   テスト全体計画には、テストの進捗状況や結果の報告方法、コミュニケーションのプロセスが含まれます。テストの責任者やステークホルダーとのコミュニケーションプランが策定されます。

テスト個別計画

テスト個別計画は、ソフトウェア開発プロジェクトのテスト活動を細かく計画する文書または計画書です。テスト個別計画は、テスト全体計画の一部であり、特定のテスト項目やテストケースに焦点を当てて詳細な計画を行います。

テスト個別計画は、プロジェクトの特定のテスト活動を詳細に計画し、テストの効率性と効果を向上させるための重要な文書です。

各テスト工程の作業内容

機能テストとシステムテストにはそれぞれ5つのフェーズがあります。

• テスト計画
  これは上記で記述したことと同様、目的や範囲、人員やスケジュールなどをテストに関する計画を定めます。
  　
• テスト設計
  テスト設計は、テストの種類や目的、テスト対象範囲などを定めます。
  　
• テストケース作成
  テストケースとは、ソフトウェアの機能や要件を検証するために、特定の入力値や条件を使用して行われるテストの単位です。テストケースは、ソフトウェアが期待どおりに動作するかどうかを確認するための手順やスクリプトを記述したものです。
  　
• テスト実施
  作成したテストケースを元にソフトウェアを動作させ、テストを実行します。テストステップに従って、システムに対して必要なアクションを実行し、結果を記録します。
  実際の結果が期待される結果と一致するかどうかを確認し、問題や欠陥を特定しテスト結果を記録します。
  　
• テスト報告
  テスト中に発見された問題や欠陥を適切に報告します。問題の重要度や影響度に応じて、優先順位付けを行い、適切な修正が行われるようにします。
  問題や欠陥が修正された場合、再テストを実施して修正の効果を確認します。修正が正常に機能していることを確認するために、関連するテストケースを再度実行します。

テスト計画・テスト設計の流れ

1. テストの目的確認
   テスト計画におけるテストの目的の確認は、プロジェクトやソフトウェアの目標に基づいて、テスト活動が期待される効果や成果を明確にするプロセスです。
   テスト計画におけるテストの目的の確認は、テスト活動の方向性を明確にし、テストが期待どおりに進行し、効果的な結果を得るための重要なステップです。
   • プロジェクトの目標と要求事項:
     テスト計画を策定する際に、プロジェクトの目標や要求事項を確認します。これには、ソフトウェアの機能や特性、品質基準、利用者の期待などが含まれます。
     　
   • テストの目的の明確化:
     テストの目的を具体的に明確化します。これには、テストが何を検証するか、何を確認するか、何を評価するかなどを明確に定義します。例えば、特定の機能の正常な動作を確認する、セキュリティの脆弱性を特定する、パフォーマンスを評価するなどがあります。
     　
   • テストのスコープの定義:
     テスト計画では、テストのスコープを明確に定義します。これには、テスト対象となる機能やシステムの範囲、テストの深さや広さ、テストの対象となるプラットフォームや環境などが含まれます。
     　
   • テストの優先順位の設定:
     テスト計画では、テストの優先順位を設定します。これには、テストの重要度やリスクの高さ、影響度などを考慮して、テストの実施順序や割り当てるリソースを決定します。
     　
   • テストの成果物と評価基準の定義:
     テスト計画では、テストの成果物や評価基準を定義します。これには、テストケースやテストスクリプト、テスト結果の報告書などが含まれます。また、テストが成功したかどうかを評価するための基準やメトリクスも定義します。
     　
2. 機能一覧作成
   この工程では、テストの対象・非対称関係なく、ソフトウェアの機能を全て洗い出します。
   　
3. テスト観点の抽出・割当て
   洗い出した機能からテスト観点の抽出を行います。洗い出した機能の一つひとつについて、どの観点のテストを行うかを検討します。
   　
4. テスト技法の検討と適応
   機能とテスト観点が定まったら、テスト設計を進めます。