システム開発におけるテスト工程を理解しましょう！

システム開発プロセスの最後にテストを行った場合、バグが検出されるタイミングが遅くなることから、システムの品質リスクが高まります。したがって、リスクを軽減するために、バグを早期に発見し、より高いテストレベルでバグが発生するのを防ぐには、システム開発の各段階に対応してテストを実行する必要があります。

1. システム開発のテスト工程とは

システム開発におけるテストの意義とは、開発されたシステムが要件、仕様書通りに動作するか、不具合がないかなどの確認を行うための作業を意味します。

開発されたシステムには、バグがないということはあり得ません。しかしながら、可能な限り不具合を解消し、問題なくシステムを活用するためにもテスト工程は必須です。

ソフトウェアテストにおいて、基本となるモデルの一つに『V字モデル』と呼ばれるモデルがあります。
『V字モデル』では、4段階のシステム開発工程に応じて、同様に4段階のテスト工程に基づいたテストが実施されます。

2. システム開発で実施される4種類のテスト工程

2.1. 単体テスト

目的

単体テストは、ソフトウェアの単機能が仕様書どおりに開発されているかどうかを確認することを目的としたテストであり、ユニットテストとも呼ばれます。

特徴

システムの他の部分とは別に実装するには、エミュレーターオブジェクト、仮想サービス、スタブ、ドライバーが必要です。

テストタイプ

機能テスト

非機能的

テストベース

詳細設計書

コード

データ・モデル

コンポーネント仕様

テストオブジェクト

典型的なテストオブジェクト

コードおよびデータ構造のコンポーネント、ユニット、またはモジュール

クラス

データベースモジュール

環境

開発されたフレームワーク、デバッグツールと同様

典型的な欠陥と不具合

正しくない機能（例：設計分析のドキュメントに記載されていない）

データフローの問題

不正なコードとロジック

責任者

開発者

2.2. 結合テスト

目的

結合テストの目的は、基本設計書通りにコンポーネントまたはシステム間の相互作用とインターフェースが動作するかどうかを確認することです。

特徴

統合テストの2つの異なるレベルは次のとおりです。

コンポーネント統合テスト-コンポーネント統合のテスト

システム統合テスト-システム統合のテスト

テストタイプ

機能テスト

非機能テスト

テストベース

ソフトウェアとシステムの設計-ソフトウェアとシステムの設計

シーケンス図-シーケンス図

インターフェイスと通信プロトコルの仕様-インターフェイスとプロトコル

ユースケース

コンポーネントまたはシステムレベルのアーキテクチャ-コンポーネントまたはシステムレベルのアーキテクチャ

ワークフロー-ワークフロー

外部インターフェースの定義

典型的なテストオブジェクト

サブシステム-サブシステム

データベース

インフラストラクチャ-インフラストラクチャ

インターフェイス-インターフェイス

API

マイクロサービス

環境：ステージング環境、開発環境など

典型的な欠陥と不具合

メッセージ構造がシステム間で一貫していない

誤ったデータ、欠落したデータ、または誤ったデータエンコーディング

サイクルのシーケンスまたはタイミングが正しくない

コンポーネント間の通信エラー

コンポーネント間の通信エラーが処理されない、または不適切に処理される

コンポーネント間で転送されるデータの意味、単位、または境界値に関する誤った仮定

必須のプライバシー規制に準拠していない

責任者

開発者およびテスター

2.3. 総合テスト

目的

総合テストの目的は、システム全体または製品の動作と機能が指定された要件に準拠しているかどうかを検討することです。

特徴

ドキュメントはほとんどありませんが、経験に基づいています

テストタイプ

機能テスト

非機能テスト

テストベース

ソフトウェアおよびシステム要件の文書化（機能および非機能）

リスク分析レポート

ユースケース

ユーザー履歴と分析

システム動作モデル

システムユーザーマニュアル

典型的なテストオブジェクト

使用したアプリケーション

システムのハードウェアとソフトウェア

オペレーティングシステム

テスト対象システム（SUT）

システム構成および構成データ

環境：実稼働環境と互換性のある環境

典型的な欠陥と不具合

計算が正しくない

正しくない、または予期しないシステム機能または機能しない動作

システム内の不適切な制御および/またはデータフロー

機能的なタスクを適切に完了できず、最後まで完了しない

システムエラーが実稼働環境で正しく機能しない

システム障害は、ユーザーシステムマニュアルに記載されているように機能しない

責任者

独立したテストテスターテスト対象システムの側面に最も適切なテクニック

2.4. 受入テスト

目的

システム全体の品質に対する信頼を築くこと

システムが完全であり、期待どおりに機能することを確認します

システムの機能的および非機能的動作が、指定された一般的な形式の受け入れテストであることを確認します

テストベース

ビジネスプロセス

ユーザーまたはビジネスの要件

規制、法的契約および基準

ユースケース

システム要求

システムまたはユーザーのドキュメント

インストール手順-リスク分析レポート

典型的なテストオブジェクト

テスト対象システム

システム構成および構成データ

完全に統合されたシステムのビジネスプロセス

システムリカバリとホットサイト（継続的な復元テストとディザスタリカバリ用）

サンプルレポート

既存および変換された生産データ

環境：ステージング環境、開発環境など

典型的な欠陥と不具合

システムワークフローがユーザーまたはビジネスの要件を満たしていない-ビジネスルールが正しく実装されていない

システムが契約上または規制上の要件を満たしていない

セキュリティホール、高負荷時の不十分なパフォーマンス、サポートされているプラ​​ットフォームでの不適切な操作など、機能しないバグ

責任者

お客様

ユーザー

3. まとめ

テスト工程の全体像を理解するために、V字モデルにおける各テストの種類や特徴を紹介させて頂きました。

4. 参照

1. https://softwaretestingfundamentals.com/software-testing-levels/

2.https://system-kanji.com/posts/system-test

3. https://it-kyujin.jp/article/detail/2267/