まず第一に、ベースラインテストとは何かを理解する前に、ベースラインとは何かを知っておく必要があります。 平たく言えば、建物を作るには、ベースが必要です。 それと同じことがテストにも当てはまります。 ベースラインを作成し、そこからさらにテストを行う必要があります。 まず最初に、このテストは非機能テストであり、アプリケーションの機能テストとは関係がないことを知ることが非常に重要です。 むしろ、将来行われる作業の強固な基礎を築くドキュメントのテストが行われます。 つまり、将来の開発のベースとなるものだと言えます。 パフォーマンス、テストケース開発かもしれません。

Talking In Terms Of Performance Testing –

If it is seen that application of a particular server with a load of 100 users, if it is working fine with a load of 100 server without any interruption or slowess or breakdown and after that server performance decreases drastically after a load of 100 users are applying to the server containing the applications. そうすると、このサーバーの標準は100ユーザーと言えます。 ここで、この標準を標準サーバーと比較し、パフォーマンス テストの将来の範囲を定義できます。

別の例でこれを理解しましょう。リリース 1 の応答時間が 2 秒で、リリース 2 の応答時間が 3 秒だったとします。 さて、リリース 3 では、リリース 2 の 2 秒の応答時間が、リリース 3 のパフォーマンスの基本またはベースラインとして機能します。 つまり、ベースラインとは、今後の作業の比較や参考のために参照される文書であることが推測されます。

Talking In Terms Of Software Development –

If we talk in terms of Software Development, There are a document called Design Document. これは、ローレベルの文書であったり、ハイレベルの文書であったりしますが、これに基づいて開発が開始されます。 テスト用語で言えば、クライアントとコンタクトを取り、クライアントから要件を引き出す役割を担うビジネスアナリストが作成した文書が、テスターが開発やテストプロセスを開始するためのコンタクトポイントとして機能する。 ビジネスアナリストはアポイントを取った後、クライアントのもとを訪れ、要件を受け取り、特定のテンプレートに記入します。 次に、エンゲージメント・マネージャーやプロジェクト・マネージャーと要件について話し合い、要件をテストして実現可能性をチェックします。 要件が明確でない場合は、開発者にプロトタイプの作成を依頼し、納得がいけば、ソフトウェア要求仕様書を作成するプロジェクトマネージャに要件定義書を手渡す。 ビジネスアナリストが作成した文書は、組織によってビジネス要求仕様書、機能要求仕様書、ユーザー要求仕様書、ビジネスデザイン文書、ビジネス文書などと呼ばれる。 つまり、要求テストは、設計書やプロジェクト計画書、テスト計画書が作成され、ソフトウェア開発とテストの基礎となるベースとして機能する要求仕様書を確定するために行われることがわかる。 このタイプのテストは、ベースラインのテストと呼ばれています。 テストのこのタイプでは、我々は準備された文書がマークにアップしており、適切に期待を満たしているかどうか、言い換えれば、我々は文書を検証し、それを最終的に確認しています。

ベースラインテストが行われ、ソフトウェア要求仕様書が確定した後、我々は先に進み、開発とテストのプロセスを開始する準備ができています。 テストについては、要求仕様書に基づいてテストケースの作成に取りかかります。 ベースライン テストの主な利点は、ソフトウェア開発ライフサイクルの初期段階で要件の誤りを取り除き、後の段階で非常に多くの問題や労力を取り除き、最小限の手直しと少ない労力でプロジェクトを提供できるようになることです」

Talking In Terms Of Software Development Life Cycle Phase –

ソフトウェア開発ライフサイクルの初期段階で多くの作業を行うと、後の段階であまりにも多くの努力を減らすことがわかっています。 ベースライン-テストがいかに重要であるかを理解するために、我々は、ソフトウェア開発ライフサイクルの少し理解を持っている必要があります。 最初のフェーズは、ビジネスアナリストがクライアントから情報を収集し、組織の使用する用語に応じてビジネス要件文書または機能要件仕様書またはユーザー要件仕様書またはビジネス設計文書またはビジネス文書と呼ばれる要件文書を準備する要求のフェーズです。 要求仕様書から、ベースラインテストと呼ばれる要求仕様書のテストが行われ、要件が確定される。 要件がまとまると、分析フェーズでソフトウェア要求仕様書を作成する。 この文書では、プロジェクトマネージャ、テクニカルマネージャ、システムアナリストが、プロジェクトがどのように開発されるかについて、プロジェクト計画を作成する。 このSRSを基に、上位設計書、下位設計書などの設計書を作成し、これを基にコーディング、テスト、デリバリーなどのソフトウェア開発ライフサイクルの別のフェーズを実施する。

仮にベースラインテストが適切に行われず、ビジネス要件ドキュメントが適切に確定されていないとすると、ビジネス要件ドキュメントに基づいて作成されたSRSは適切ではなく、設計ドキュメントも正確ではないため、要件の取り違えや要件のベースラインが適切でない可能性があり、すべての開発およびテスト活動は顧客の期待通りにはならないでしょう。 このことから、ベースラインテストがいかに重要かがわかる。

一つ重要なことは、構成管理で使われるベースラインという用語があるが、意味はそこでも多かれ少なかれ同じである。 それは、ドキュメントのベースバージョンが確定し、ドキュメントの新しいバージョンがソフトウェアアプリケーションのリリースごとにリリースされるドキュメントのバージョニングに関連しています。 しかし、構成管理にはベースラインテストの概念はほとんどありません。なぜなら、開発、テスト、Webデザインなど、ソフトウェア開発に関連して作成されたすべての文書のベースバージョンは、フォーマットやコンテンツの観点から適切にレビューされる必要があり、すでに適切にフォーマットされた文書の次のバージョンが少ない労力で準備されるようにするためです。

結論：

したがって、我々はベースラインのテストはどのくらいの重要性と限り、要件が適切に検証されていないまで、または言い換えれば、ベースラインのテストが行われていない場合、後の段階で多くの問題があると努力の利用は、単に努力と時間の無駄であり、新しい要件が取られると完全に問題を解決するために、ソフトウェア開発ライフサイクルのすべての段階を通過する必要がある問題解決においてはるかにされることを確認しました。 ですから、ベースライン テストは、早い段階で多くの問題を解決し、ソフトウェア開発ライフサイクルの後期段階でのコスト、労力、および時間を削減すると言えるでしょう。

Happy Testing!!!!