検証と検証はテストプロセスの一部ですか？

多くのソースに基づいて、私はテストの目的ができるだけ多くのバグを見つけることであるとは信じていません-私たちはそれが機能するか機能しないかを確認するためにテストします。例えばfollowintはISTQBからのテストの目標です：

1. （ソフトウェア製品）が指定された要件を満たしていることを確認します（その検証だと思います）

2. （ソフトウェア製品）が目的に適合していることを示す（これは検証だと思います）

3. 欠陥を検出する

   テストは検証、検証、欠陥検出であることに同意します。あれは正しいですか？

正解だと思います。

1. 検証と検証は異なるものであり、実際にはかなり明確に定義されています。このドキュメントはあまり好きではありませんが、ISO 9000ffはQAに非常に関連性が高く、検証とは製品とその要件を比較することであり、検証はそれが実際に顧客/ユーザーのニーズに適合しているかどうかを確認することと定義しています。 。

2. どちらもテストを通じて行うことができます。検証を行うと、テストによってフォーム要件が生成されます。検証は、要件を直接参照せずにテストによって行われるテストにつながります。これはしばしば探索的テストと呼ばれていると思います。明らかに、それはユーザーの本当のニーズを真に理解している人によって行われなければならないので、本当のユーザーによるアルファとベータのテストは明白なオプションです。

3. 理論的には、最初の2つでカバーされるものはすべてバグではないと主張できるので、別の目標としてバグを見つけることは意味がありません。しかし、実際には検証または検証できないものがあると思います。たとえば、セキュリティ：ソフトウェアシステムが攻撃に対して安全であることをどのように検証または検証しますか？代わりに、脆弱性を見つけようとします。この検索で​​は、問題が見つからない場合は何も検証または検証されませんが、成功した場合はバグが見つかります。

ウィキペディアから：「...つまり、検証は、製品が実際にユーザーのニーズを満たしていること、および仕様がそもそも正しいことを確認し、検証は、製品が要件と設計仕様に従って構築されていることを確認しています。検証により、「正しいものを構築した」ことが確認されます。検証により、「正しく構築した」ことが確認されます。検証により、提供された製品が意図した用途を満たしていることが確認されます。

ユーザーのニーズをテストして、仕様がコードで正しいかどうかを確認することはできません。そのため、検証はテストでは行われません。

検証では、要件と設計が正しいことを前提としているため、コードを記述してテストできます（テスト）。

現実の世界では、テストはソフトウェアの要件（ビジネス/機能/非機能）を満たすソフトウェアの検証です。これらの目的は、ソフトウェアが目的に合っているかどうかを判断することです。アプリケーションの要件を満たさない動作は欠陥です。ソフトウェアが目的に適しているかどうかを判断する前に、その重大度を重み付けする必要があります。

重大度が低い欠陥は、ソフトウェアを本番タイプの使用に渡す際の問題ではない可能性があります。重大度が高い場合は、修正を作成する必要がある場合があります。現実の世界では、すべてのソフトウェアに欠陥があり、一部はコーディングの問題であり、他は要件の欠落によるものです-未知の要件をテストできないため、テストされない可能性があります。

検証と検証には多くの定義があります。多くの人はV＆Vタグを使用して両方を1つのアクティビティにグループ化しています。目的は、ソフトウェアが正しいことを行い、正しいことを確実にすることです。要件への準拠をチェックするか、バグを見つけようとするかは、このレベルでは必須ではありません。

テストは、検証と検証のための多くの手法の1つであり、その逆ではありません。コードレビューは別の1つであり、正式な検証であり、数学的証明がもう1つあります。

それでも、テストは、要件を満たしているかどうかを確認するためではなく、バグを見つけることを目的として実行する必要があります。

主な違いはテスターの心にあります。ソフトウェアが失敗したことを示すテストケースを構築する（バグを見つける）よりも、ソフトウェアが意図したとおりに機能することを示す（コンプライアンスをチェックする）テストケースを構築する方がはるかに簡単です。

優れたテスターは、安全な方法でソフトウェアを実行することではなく、ソフトウェアの破壊に情熱を傾けています。

これを実用的な観点から見てみましょう。テストでは、テストケースを定義する必要があります。通常、指定された要件に沿ってテストケースを定義し、「ハッピーデー」ケースと「エッジケース」をカバーする必要があります。特に、後者はソフトウェアを壊すことを意図して定義されることがよくあります。一部のテストが失敗すると、バグ/欠陥が表示されます。各要件に対して妥当な量のテストケースがあり、すべてのテストに合格した場合、すべての要件が満たされていることを完全に証明できていない可能性がありますが、その確率が向上しているため、検証を行いました。

したがって、質問のその部分については、バグの発見と検証は、同じプロセスの両面にすぎない場合があります。

• テスト失敗：欠陥が見つかりました

• テストに合格：検証済み（十分で適切なテストを提供する場合、少なくともある程度）

検証について：@Mertが指摘したように、検証は受け入れテストで実行できますが、他の形式のテストでは実行できません。したがって、一般にテストでは、一部の潜在的なユーザーによる受け入れテストとして行われた場合にのみ、検証は行われません。

それはすべて、「検証」の定義に依存します。たとえば、正式な検証は通常、QAチームによって行われるものではなく、開発者の責任です。それに伴うコストが高いため（知識のギャップと必要なリソース）、ほとんど誰も正式な検証を行いません。

ソフトウェアテストはQAと同じではありません。あなたはその権利を得ました。ソフトウェアテスト全体には、多くの段階（煙、ユニット、回帰、統合、ユーザーの受け入れなど）が含まれています。

したがって、ソフトウェアが要件に従って動作することを保証することは、QA（品質保証スペシャリスト-別名、何年も前は単にテスターと呼ばれていたもの）の目標です。ただし、テストだけではありません。QAにより、問題の製品の品質チェックを実行するための適切な一連のプロセスが実施されているか、少なくともプロジェクトの設計フェーズに組み込まれていることが保証されます。

したがって、理想的には、QAが一連の要件に照らしてアプリケーションを検証することを期待し、ソフトウェアを破壊して欠陥を見つけるだけでテストするのではありません。