validation testing ultimate guide
検証テストの重要性を探る：
学習内容：
検証テストとは何ですか？
検証テストは、テストおよび開発されたソフトウェアがクライアント/ユーザーのニーズを満たしているかどうかを確認するプロセスです。ビジネス要件のロジックまたはシナリオは、詳細にテストする必要があります。ここでは、アプリケーションのすべての重要な機能をテストする必要があります。
テスターとして、与えられたビジネスロジックまたはシナリオを検証する方法を知ることは常に重要です。機能の詳細な評価に役立つそのような方法の1つは、検証プロセスです。
検証テストの実行を求められた場合は常に、ユーザーのニーズに基づいてすべての重要なビジネス要件をテストする必要があるため、大きな責任があります。ユーザーが要求する要件を1つも見逃してはなりません。したがって、検証テストに関する鋭い知識が非常に重要です。
テスターは、テストの実行結果が要件ドキュメントに記載されている結果に準拠しているかどうかを評価する必要があります。逸脱があればすぐに報告する必要があるため、その逸脱はバグと呼ばれます。
HP Quality Centre、Selenium、Appiumなどのツールを使用して検証テストを実行し、そこにテスト結果を保存できます。適切なテスト計画、テスト実行の実行、欠陥レポート、レポートおよびメトリックは、提出する重要な成果物です。
会社の観点から、単純な検証テストは次の手順で実行されます。
- 検証テストのビジネス要件をエンドユーザーから収集します。
- 事業計画を作成し、承認のために関係するオンサイト/利害関係者に送信します。
- 計画が承認されると、必要なテストケースの作成を開始し、承認のために送信します。
- 承認されたら、必要なソフトウェア、環境を使用してテストを完了し、クライアントの要求に応じて成果物を送信します。
- 成果物が承認されると、UATテストがクライアントによって実行されます。
- その後、ソフトウェアは本番環境に移行します。
c ++は数秒待つ
ここで、検証について詳しく見ていきましょう。
検証と妥当性確認の違い
簡単な例でこれらを理解しましょう。
例：
クライアントの要件：
提案された注射の重さは2cmを超えてはなりません。
検証テスト：
- チェックリスト、レビュー、および設計を使用して、注射が2cmを超えない注射であるかどうかを確認します。
検証テスト：
- 手動または自動テストを使用して、注入の重量が2cmを超えていないかどうかを確認します。
- 適切なテスト方法（機能的および非機能的方法）を使用して、射出重量に関連するすべての可能なシナリオを確認する必要があります。
- 2cm未満および2cmを超える測定値を確認してください。
| 検証 | 検証 |
|---|---|
| このプロセスでは、設計、コード、およびプログラムをチェックするだけです。 | コードを含む製品全体を評価する必要があります。 |
| レビュー、ウォークスルー、検査、およびデスクチェックが含まれます。 | テストの機能的および非機能的方法が含まれます。製品の詳細なチェックが行われます。 |
| ソフトウェアを仕様でチェックします。 | ソフトウェアがユーザーのニーズを満たしているかどうかを確認します。 |
関与する段階
- 設計資格： これには、ビジネス要件に基づいたテスト計画の作成が含まれます。すべての仕様を明確に記載する必要があります。
- インストール資格： これには、要件に基づくソフトウェアのインストールが含まれます。
- 運用資格： これには、ユーザー要件仕様に基づくテストフェーズが含まれます。
これには以下が含まれる場合があります 機能テスト：
-
- ユニットテスト– ブラックボックス、ホワイトボックス、グレーボックス。
- 統合テスト– トップダウン、ボトムアップ、ビッグバン。
- システムテスト– 正気度、煙、および回帰テスト。
- パフォーマンス資格： UAT（ユーザー受け入れテスト） - アルファおよびベータテスト。
- 製造
設計資格
設計資格とは、ユーザーの仕様を満たすようにソフトウェアの設計を準備する必要があることを意味します。主にあなたは取得する必要があります ユーザー要件仕様（URS）ドキュメント クライアントから設計を進めるために。
テスト戦略：
このドキュメントは、テスト計画を作成するための基礎を形成します。これは通常、プロジェクトのチームリーダーまたはマネージャーによって作成されます。それは、私たちがどのようにテストを進め、望ましい目標を達成するかを説明しています。
すべての手順を組み込むには、適切な計画を設計し、利害関係者から承認を受ける必要があります。それでは、テスト計画の構成要素をお知らせください。
いくつかのプロジェクトでは、テスト計画とテスト戦略を1つのドキュメントとして組み込むことができます。複雑なプロジェクト（主に自動化手法）用に、個別の戦略ドキュメントも用意されています。
検証テスト計画のコンポーネント：
- プロジェクトの説明
- 要件を理解する
- テストの範囲
- テストレベルとテストスケジュール
- 計画作成を実行する
- ハードウェア-ソフトウェアおよび人員配置の要件
- 役割と責任
- 仮定と依存関係
- リスクと軽減
- レポートと指標
プロジェクトの説明： ここでは、テスト用に提供されたアプリケーションのすべての説明を説明する必要があります。アプリのすべての機能が含まれている必要があります。
要件を理解する： USRを取得したら、理解している要件について自分の側から言及する必要があります。必要に応じて、説明を上げることもできます。これは、テストの基本またはテスト基準として機能します。
テストの範囲： スコープには、高レベルの機能とともにモジュールを詳細に含める必要があります。テストでカバーするすべての要件をクライアントに伝える必要があります。
ビジネスの観点から、検証テストは、アプリケーションの重要な要件に対して実行するように求められる場合があります。それは単にあなたが何がカバーされ、何がカバーされないかを言うことを意味します 。
テストレベルとテストスケジュール： 何回のテストを実施する必要があるかについて言及する必要があります。テストプロジェクトの全体的な作業量は、テストケースポイント（TCP）見積もりなどの標準的な見積もり手法を使用して見積もります。
名前が示すように テストスケジュール テストがどのように実行されるかを説明します。また、承認の方法と時期、およびレビューが行われることも記載する必要があります。
例：
ウェブページのデザインは考慮されるプロジェクトです。
テストレベルは次のとおりです。
レベル1： スモークテスト
レベル2： ユニットテスト
レベル3： 統合テスト
レベル3： システムテスト
レベル3： 受け入れ試験
テストスケジュール：
- 計画の提出– 1日目
- テストケースの設計– 2日目
- ドライランとバグ修正– 4日目
- レビュー- 5日目
- 正式な実行– 6日目
- 承認のために送信された成果物– 8日目
- レポート– 10日目
実行計画の作成： 実行計画は、テストに必要な実行数を示します。オフサイトで実行するすべての実行は、オンサイトチームによって記録されます。
例えば、 あなたが使用するとき HP Quick TestProfessionalツール 実行の場合、実行数はテスト計画の(実行)タブに表示されます。
ハードウェア-ソフトウェアおよび人員配置の要件：
- プロジェクトに必要なデバイス、ブラウザバージョン、IOS、テストツールなどのハードウェアおよびソフトウェア要件。
- 人員配置とは、テストに必要な人を任命することを意味します。ここでチーム数について言及できます。
- 追加のテストメンバーが必要な場合は、テストの範囲に応じてオンサイトでリクエストできます。テストケースの数が増えると、それを実行するにはより多くのチームメンバーが必要になることを意味します。
役割と責任： これは、さまざまなレベルのテストの実行を担当する関連する役割にタスクを割り当てることを意味します。
Chrome用の最高の無料広告ブロッカーは何ですか
例えば、
4つの検証プロトコルを実行するには、4人のメンバーで構成されるチームがアプリをテストする必要があり、次のように責任を委任できます。
- テストリード： テスト計画の設計
- チームメンバー1： プロトコルの設計と実行1,2。
- チームメンバー2： プロトコルの設計と実行3,4。
- チームメンバー： レポート、レビュー、およびメトリックの準備。
仮定と依存関係： これは、設計中に行われた仮定とテスト用に特定された依存関係がここに含まれることを意味します。
リスクと軽減： 必要な環境の可用性、ビルドなどのテスト計画に関連するリスクと、緩和および緊急時対応計画。
レポートと指標： テストと利害関係者への報告に使用された要因については、ここで言及する必要があります。
モバイルアプリの例を以下に示します。
インストール資格
- インストール資格には、使用するテスト環境とその数、各環境のテスターに必要なアクセスレベル、および必要なテストデータなどの詳細が含まれます。ブラウザの互換性、実行に必要なツール、テストに必要なデバイスなどが含まれる場合があります。開発中のシステムは、ユーザーの要件に従ってインストールする必要があります。
- 一部のアプリケーションのテストにはテストデータが必要な場合があり、適切な担当者から提供する必要があります。これは重要な前提条件です。
- 一部のアプリケーションでは、データベースが必要になる場合があります。仕様を検証するために、テストに必要なすべてのデータをデータベースに保存しておく必要があります。
例えば、新しいアプリでは、「abc」はモバイル（Android 4.3.1）とブラウザ（Chrome 54）でテストする必要があると言われています。そのような場合、次のことを追跡する必要があります。
- アプリ「abc」のサイトを確認するための適切な承認が与えられているかどうかを確認してください。
- モバイル（android / ios）、ブラウザー-Chrome、必要なバージョンのInternetExplorerなどのアプリのテストに使用されるデバイスが利用可能かどうかを確認します。
- 指定されたバージョン（例：Chrome 54、Androidバージョン4.3.1）でそれらが正しくインストールされているかどうかを確認します。
- アプリがブラウザとモバイルの両方でアクセス可能かどうかを確認してください。
運用資格
運用資格により、テスト対象のアプリケーション用に設計されたすべてのモジュールとサブモジュールが、目的の環境で期待どおりに適切に機能することが保証されます。
一般に、検証テストは次の階層で実行されます。
機能テストは、検証テストで主要な役割を果たします。それは単に、言及されたすべての重要な要件によってアプリケーションの機能を検証する必要があることを意味します。これにより、機能仕様書に記載されている要件をマッピングし、製品が記載されているすべての要件を確実に満たすようになります。
機能テストとそのタイプ
名前が示すように、 機能テストとは、機能、つまりソフトウェアが何をしなければならないかをテストすることです。 ソフトウェアの機能は、要件仕様書で定義されます。
そのタイプをざっと見てみましょう。
＃1）ユニットテスト：
ユニットテストとは、特定のシステムの個々のユニット/モジュール/コンポーネント/メソッドをテストすることです。フィールド検証、レイアウト制御、設計などは、コーディング後にさまざまな入力でテストされます。コードの各行は、個々の単体テストケースに対して検証する必要があります。
ユニットテストは開発者自身が行います。他のレベルのテストと比較した場合、バグを修正するコストはここでは少なくなります。
例：
関数のコードのループを評価することは、性別の選択が単体テストの例であると言います。
＃2）ブラックボックステスト：
システムの内部の詳細に焦点を当てることなく、要件に対して目的の機能についてアプリケーションの動作をテストすることを、ブラックボックステストと呼びます。これは通常、独立したテストチームまたはアプリケーションのエンドユーザーによって実行されます。
アプリケーションは関連する入力でテストされ、システムが希望どおりに動作するかどうかを検証するためにテストされます。これは、機能要件と非機能要件の両方をテストするために使用できます。
＃3）ホワイトボックステスト：
ホワイトボックステスト コードによるプログラムコードの詳細なチェックに他なりません。アプリケーションの全体的な動作は、記述されたコードに依存するため、コードを非常に注意深くテストする必要があります。すべてのユニットとその統合をモジュール全体として段階的にチェックする必要があります。
ここでは、プログラミングの知識を持つテスターが必須の基準です。これにより、アプリケーションのワークフローに逸脱があるかどうかが明確にわかります。これは、開発者とテスターの両方に役立ちます。
＃4）グレーボックステスト：
グレーボックステストは、ホワイトボックステストとブラックボックステストの両方を組み合わせたものです。テストされるユニットの構造またはコードに関する部分的な知識は、ここで知られています。
統合テストとそのタイプ
単体テストですでにテストされているソフトウェアの個々のコンポーネントは、モジュール間のデータフローを保証するために、統合されて一緒にテストされ、全体としての機能をテストします。
これは、開発者自身または独立したテストチームによって行われます。これは、2つ以上のユニットがテストされた後に実行できます。
トップダウンアプローチ：
このアプローチでは、最初に上位のユニットがテストされ、次に下位のユニットが1つずつ段階的にテストされます。使用できるテストスタブは、初期段階では使用できない可能性のある低レベルのユニットをシミュレートするために必要です。
ボトムアップアプローチ：
このアプローチでは、最下位のユニットが最初にテストされ、統合されてから、上位レベルのユニットがテストされます。 使用できるテストスタブは、初期段階では使用できない可能性のある高レベルのユニットをシミュレートするために必要です。
システムテストとそのタイプ
完全なシステム/ソフトウェアのテストは、システムテストと呼ばれます。システムは、機能要件の仕様に対して完全にテストされています。システムテストは、機能要件と非機能要件の両方に対して行われます。このタイプのテストには、一般的にブラックボックステストが推奨されます。
＃1）スモークテスト：
ビルダーが最初にテストするビルドを提供するとき、ビルドを徹底的にテストする必要があります。これはスモークテストと呼ばれます。 ビルドがさらにテストできるかどうかを述べる必要があります。
検証を実行するには、適切なビルドが必要です。したがって、スモークテストは最初にテストチームによって行われます。テストするアプリケーションのワークフローは、テストケースありまたはなしでテストする必要があります。フロー全体をカバーするテストケースは、このテストに役立ちます。
以下のそれぞれは、ネットワークの状態をチェックするために使用されるツールです
＃2）健全性テスト：
健全性テストでは、テスト対象のアプリケーションのモジュールの主な機能がテストされます。プロファイルの作成、教育、ログインなど、3つのタブがあるWebサイトをテストする場合 IRCTC 、これらすべてのタブの主な機能は、深く掘り下げることなくチェックする必要があります。
メニュー、サブメニュー、タブはすべてのモジュールでテストする必要があります。テストはメインフローに対してのみ行われ、詳細には行われないため、これは回帰テストのサブセットです。
＃3）回帰テスト：
プロジェクトのリリースごとに、開発チームは特定の変更を導入する場合があります。導入された新しい変更がシステムの作業フローに影響を与えていないかどうかを検証することを、回帰テストと呼びます。ここでは、新しい要件に関連する特定のテストケースのみをテストする必要があります。
パフォーマンス資格
UAT（ユーザー受け入れテスト）：
これは、指定された要件に対応してシステムが必要に応じて動作することを確認するために実行されるテストの最後のフェーズです。これはクライアントによって行われます。クライアントがシステムテストを認証してクリアすると、製品を展開できるようになります。
アルファおよびベータテスト：
アルファテストは、ソフトウェア開発サイトでリリースされる前に、アプリケーションの開発者によって行われます。これには、ブラックボックステストとホワイトボックステストが含まれます。ベータテストは、製品が開発および展開された後、顧客側で行われます。
サンプル検証テストケースまたはプロトコル
私の経験では、Gmailログイン用にこのプロトコルを作成しました。
対象となるログイン機能の詳細なチェックは、検証が実際に何であるかです。ただし、使用される文の列のスタイルは完全に異なり、クライアントの要件によって異なる場合があることを述べておきます。
=>サンプル検証テストケースのダウンロード： Gmailログインテストケース
結論
検証とは、製品の機能を詳細に分析することです。検証テスターとして、テストで最適な結果を得るには、常に偏差を報告することを忘れないでください。
書かれているすべてのテストケースは、一般の人にも鋭く、簡潔で、理解できるものでなければなりません。検証テスターは、指定された要件に対して適切な製品が開発されていることを確認する必要があります。
検証テストのガイドとして、検証に関連するプロセスについて説明しました。
検証計画を含む設計資格、ハードウェアとソフトウェアのインストールについて説明するインストール資格、システム全体のテストを含む運用資格、生産の承認を提供するユーザー受け入れテストを含むパフォーマンス資格。
この記事が検証テストの概念に関する知識を深めることを願っています!!