システム・テストとは。

このユニットを持つ顕微鏡で、その最大倍率でソフトウェア・システムを見ていると想像してくださいこれは、ソフトウェア・システムの基本的な構成要素です。次に、ビューが外側に拡大すると、次のレベルの拡大、つまり個々のユニットによって作成されたモジュールが含まれます。最後に、完全にズームアウトすると、システム・レベルに到達します。このレベルの拡大率では、システム内のすべてと、それらのモジュールによって作成されたすべてのコンポーネントがどのように連携して動作するかを確認できます。

システム・テストはある意味で顕微鏡のサイトに似ていますが、重要な違いがあります。システム・テストはブラックボックス・テストの一種であり、テスターがシステム全体の機能よりも、システムのアセンブリーに含まれるコンポーネントのビューに関心がなく、このような「合格/不合格」の観点から見ると、システムの動作は、システムの性能に関連するものであれば、唯一注目に値します。（ホワイトボックス・テストにより、システム内のコンポーネントの性質をより詳細に可視化できます）。

システム・テストでは、多くの場合、特定のソフトウェア・システム内で連携して動作する場合とそうでない複数の個別のソフトウェア・システムの分析が含まれます。

宇宙ロケットの打ち上げに至るまでのカウントダウンを考えてみましょう。点火から発射の前の劇的な10ステップのカウントダウンは誰もが覚えていますが、フライト長に尋ねられ、「ゴー」と積極的に答えた多数の部門チェックを覚えている人はほとんどいません。典型的な宇宙打ち上げでは、計画された運用、ミッションの安全性、宇宙機のシステム、予想される気象条件など、数多くの事項について部門長らに意見を求めます。各部門が質問を受け、各部門長が順番に応答します。

同様に、システム・テストは、新しいソフトウェア・システムを起動する前の最終チェックリストと考えることができます。ソフトウェアの既知のバグのクリーンアップの最終回が完了しました。そして、初期の宇宙先駆者が考案した歴史的なチェックオフ・リストと同じように、システム・テストに含まれる各「部門」の最終的な決定にすべてをもたらします。

各クエリは、システムの機能の観点から日取りされます。

• 各コンポーネントは期待どおりに機能していますか。

• コンポーネント同士が適切に連携して機能していますか。

• そのソフトウェアは、スムーズなユーザー・インターフェースをサポートし、望ましいユーザー体験（UX）を提供する態勢が整っていますか。

システム・テストについて説明するときは、当然ながら依存関係の話題に遭遇します。依存関係とは、テスト・ケース内に存在する関係です。このような状況では、あるテスト・ケースの成果が別のテスト・ケースの成果に部分的または完全に依存する可能性があります。依存関係には、機能、テスト環境、またはセキュリティー・ポリシーも含まれる場合があり、組織が維持するテスト・プロセス全体に影響を与える可能性もあります。

システム・テストの方法論では、内部の仕組みについて詳しく知ることはできません（これはブラックボックス・テストの一種であることを忘れないでください）。その代わりに、特定のアプリケーションが動作するかどうかを知ることができます。システム・テストは、ソフトウェア・アプリケーションの全体的な機能を決定する際に、ギャップ、エラー、または欠落している要件を特定するのに役立ちます。

システム・テストは通常、統合テストの後、受け入れテストの前に実施されます。これにより、全てのコンポーネントが適切に連携して機能することが保証されます。ご覧のように、多くの場合、システムの機能的側面と非機能的側面の両方が含まれます。厳密に機能する領域と広範な非機能領域の両方に基づいているため、ユーザビリティー、セキュリティー、性能などの領域に影響を及ぼします。

システム・テストの主な目的の1つは、ソフトウェアのコーディング言語を使用可能なプログラムに変換できることをV検証することです。ただし、システム・テストの包括的な目標は、評価対象のソフトウェアが利用するユーザーのビジネス要件を適切にサポートしていることを確認することです。

テスト・プロセスは、使用されるのと同じ運用環境を反映することを目的としており、変化する現実世界の状況に応じて必要に応じてソフトウェアが機能することを確保します。同様に、テスト・データは現実世界のデータや状況を模倣するように作成されます。テスト・ケースが実施されると、ソフトウェアの欠陥を特定して修正できます。

システム・テストは、主に3つのグループのいずれかに分類できます。1つ目はFunctional Testingです。これは性能に関係するものですが、ソフトウェアが約束したとおりに機能するかどうかの確認以上に、深い答えは求めません。Functional Testingの主な種類をいくつか紹介します。

• 受け入れテスト：ユーザー受け入れテストでは、作成されるソフトウェアの対象とする層を代表する人々によって実施される性能テストを組み込むことを目指します。これらのユーザーは、実際の条件でソフトウェアをテストすることで、テスト・プロセスをさらにリアルにします。

• 統合テスト：Functional Testingの非常に重要な分野の1つは、さまざまなモジュールやコンポーネントが緊密に連携して動作することを余儀なくされた場合にどの程度適合するかを研究します。それが統合テストです。完全に統合されたシステムにより、テスターは重要なインタラクションを評価する機能を提供します。

• Smokeテスト：Smokeテストは、開発者が何らかのコード変更を行った後、全体的な機能が維持されているかどうかをチェックする手段を提供します。変更が行われ、Smokeテストを使用すると、そのコードの変更によって生じた悪影響があるかどうかをすぐに確認できます。

• 単体テスト：単体テストでは、分離されたテスト環境内でコードの限定セクションがチェックされます。問題のユニットがテストに失敗した場合（テスト・データと機能目標の比較からわかるように）、通常、システム全体のレベルで個々のコンポーネントまたはモジュールの追加のテストが必要になります。

Functional Testingは非常に重要な情報を提供しますが、そのデータは基本的に、システムが想定通りに動作するかどうかに基づく賛成か反対かの判断に限定されます。これにより、システム・セキュリティー、UX、性能面など、膨大な数の関連変数が省略されます。

非機能システム・テストは、システムがどのように動作するかを判断する手段を提供します。Functional TestingとNon-Functional Testingの本質的な違いは、次の単純な比較に集約できます。

• Functional Testing：システムは動作するか。

• Non-Functional Testing：システムはうまく動作しているか。

このことを念頭に置いて、非機能システム・テストの主な形式をいくつか次に示します。

• アクセシビリティー・テスト：提示されているデジタル・コンテンツは、さまざまな障害を持つ人々を含む、誰もがアクセスできるものか判断します。アクセシビリティー・テストは、この質問を調査し、身体的および精神的ハンディキャップを克服し、米国障害法（ADA）によって確立されたインクルージョンの基準との一貫性を確保する方法で、考えられるすべてのユーザーにコンテンツが確実に伝達されるように取り組みます。

• 互換性テスト：アプリケーションの配布範囲と、アプリがどのようなクロスプラットフォームの移行をしなければならないかを考慮すると、ネットワークやブラウザーの数に関係なく、このようなアプリがどの程度適切に機能するかを測定する互換性テストの必要性を理解しやすくなります。オペレーティング・システムとハードウェアの構成要素で構成されているためです

• 負荷テスト：負荷の概念が提示する独自の物理現象と、それがシステム要求を処理する能力にどのような影響を与えるかを扱う下位区分にある負荷テストは、負荷テストが大規模に拡張性を実現したときに何が起こるかに焦点を当てています。システムは1つのシステム・リクエストを問題なく処理すると仮定しますが、その負荷が数千、あるいは大幅に増加した場合はどうなるでしょうか。

• ローカリゼーション・テスト：これは、これまで以上に多くの国または地域や文化が参加するグローバル経済において必要とされます。ローカリゼーション・テストは、世界中のさまざまなロケールにエクスポートされるソフトウェア・コンテンツが、UXに関する一般ルールに従って、その特定の地域に適切であることを確認することです。

• 性能テスト：このタイプのNon-Functional Testingは、性能の問題に特に注意を払います。例えば、性能を向上させるには、システムがリクエストに迅速かつスムーズに応答することが不可欠です。性能テストのテスト・プランでは、リクエストが処理されるまでユーザーが待機する必要がある時間を評価します。

• セキュリティー・テスト：最近、データ・セキュリティーが最重要であることは周知の事実です。したがって、テスト形式がセキュリティーに特化していることは理にかなっています。セキュリティー・テスト方法は、企業が受ける潜在的な脅威の種類に応じて選択されます。

• ストレス・テスト：医療上のストレス・テストでは、集中状態が重要な作業の下で人の心臓の働きを理解することを目的としているのと同じように、ソフトウェアのストレス・テストは、ボトルネックや脆弱性を検知するために、通常の能力を超えた場合に、システムがどの程度回復力を維持できるかを検証します。

• ユーザビリティー・テスト：このタイプのNon-Functional Testingは、すべてユーザー体験（UX）の品質を重視します。ユーザビリティー・テストは、小規模で実際に使用される手動テスト・プロセスです。ただし、アプリケーションをローカライズするなどの複雑な動きを実行する場合には、おそらく頻繁に適用すべきでしょう。

機能テスト、非機能テストというカテゴリーに分類されずに、他のタイプのシステム・テストも役に立ちます。ここでは、これらの方法論の中で最も注目に値するものをいくつか紹介します。

• APIテスト：アプリケーション・プログラミング・インターフェース（API）は非常に重要であり、異なるアプリやシステムの接続を助けることでソフトウェア開発を可能にします。APIテストは、API接続ポイントが意図したとおりに動作することを保証します。また、ユーザー権限やAPIによるデータの管理方法に関する監視も行います。

• 自動テスト：その名の通り、自動化テスト（テスト自動化とも呼ばれる）は、自動化の力をソフトウェ・アアプリケーション・テストに応用するものです。これは、ソフトウェア・アプリ上でテスト・ケースを実行するように設計されたテスト・スクリプトを作成および使用することによって実現され、人間の介入なしに大規模に実行されます。テスト・プロセスの自動化に役立つ構造化された一連のガイドライン、ツール、プラクティスはフレームワークと呼ばれます。

• 手動テスト：自動テストとは正反対に、手動テストは、さまざまなテスト・シナリオやテスト・スクリプトに導かれながら、評価対象のソフトウェアを実験する人間のテストに依存します。テスターは、ソフトウェアをそのペースで実際に試して修復が必要な問題を特定することをお勧めします。

• 移行テスト：移行テストは、企業のデジタル文化の更新や変革に取り組んでいる組織に必要です。企業がこのような変革の取り組みに取り組む際には、重要なデータとソフトウェアが送信システムから受信システムに適切に転送されていることを検証する必要があります。

• 回帰テスト：コードの変更はソフトウェアの改善や機能の強化を目的としていますが、そこにヒューマン・エラーが何らかの形で加わると、意図しない困難が生じる可能性があります。回帰テストでは、必要に応じてテストを再実行することで、安定した正しい動作を確認することができます。

システム・テスト・プロセスでは極めて包括的なブラックボックス性能テストが実施されますが、システム・テストの実行には潜在的な問題がないわけではありません。