検証と検証はテストプロセスの一部ですか？
多くのソースに基づいて、テストの目的ができるだけ多くのバグを見つけることであると私は信じていません-私たちはそれが機能するか機能しないかを確認するためにテストします。例えば。 followintは、ISTQBからのテストの目標です。
（ソフトウェア製品）が指定された要件を満たしていることを確認します（その検証だと思います）
（ソフトウェア製品）が目的に合っていることを示す（それは検証だと思う）
欠陥を検出する
テストは検証、検証、欠陥検出であることに同意します。あれは正しいですか？
正解だと思います。
検証と検証は別物であり、実際にはかなり明確に定義されています。このドキュメントはあまり好きではありませんが、ISO 9000ffはQAに非常に関連性が高く、検証とは製品とその要件を比較することであり、検証はそれが実際に顧客/ユーザーのニーズに適合しているかどうかを確認することと定義しています。 。
どちらもテストを通じて行うことができます。検証を行うと、テストによってフォーム要件が生成されます。検証は、要件を直接参照せずにテストによって行われるテストにつながります。これはしばしば探索的テストと呼ばれていると思います。明らかにそれはユーザーの本当のニーズを真に理解している人によって行われなければならないので、本当のユーザーによるアルファとベータテストは明白なオプションです。
理論的には、最初の2つでカバーされるものはすべてバグではないと主張できるので、個別の目標としてバグを見つけることは意味がありません。しかし、実際に検証または検証できないものがあると思います。セキュリティの例：ソフトウェアシステムが攻撃に対して安全であることをどのように検証または検証しますか？代わりに、脆弱性を見つけようとします。この検索では、問題の発見に失敗しても何も検証または検証されませんが、成功するとバグが発見されます。
ウィキペディアから： "...つまり、検証は、製品が実際にユーザーのニーズを満たしていること、および仕様はそもそも正しいであることを確認しますが、検証は製品が要件と設計仕様に従って構築されていることを確認します。検証により、「正しいものを構築した」ことを確認します。検証により、「正しく構築した」ことを確認します。検証により、提供された製品が意図した用途を満たしていることを確認します」
ユーザーのニーズをテストしたり、コードで仕様が正しいかどうかを確認したりすることはできません。そのため、検証はテストでは行われません。
検証では、要件と設計が正しいことを前提としているため、コードを記述してテストできます（テスト）。
現実の世界では、テストはソフトウェアの要件（ビジネス/機能/非機能）を満たすソフトウェアの検証です。これらの目的は、ソフトウェアが目的に適しているかどうかを判断することです。アプリケーションの要件を満たさない動作はすべて欠陥です。ソフトウェアが目的に適しているかどうかを判断する前に、重大度を重み付けする必要があります。
重大度が低い欠陥は、ソフトウェアを本番タイプの使用に渡す際の問題ではない可能性が高く、重大度が高い場合は、修正を作成する必要がある場合があります。現実の世界では、すべてのソフトウェアに欠陥があり、一部はコーディングの問題であり、他は要件の欠落によるものです-未知の要件をテストできないため、テストされない可能性があります。
検証と検証には多くの定義があります。多くの人はV＆Vタグを使用して、両方を1つのアクティビティにグループ化しています。目的は、ソフトウェアが正しいことを行い、正しいことを確実にすることです。要件への準拠を確認するか、バグを見つけるかは、このレベルでは必須ではありません。
テストは、検証と検証のための多くの手法の1つであり、他の方法ではありません。コードレビューは別の1つであり、正式な検証であり、数学的証明がもう1つあります。
それでも、テストは、要件を満たしているかどうかを確認するためではなく、バグを見つけることを目的として実行する必要があります。
主な違いはテスターの心にあります。ソフトウェアが失敗する（バグを見つける）ことを示すテストケースを構築するよりも、ソフトウェアが意図したとおりに機能することを示す（コンプライアンスをチェックする）テストケースを構築する方がはるかに簡単です。
優れたテスターは、安全な方法でソフトウェアを実行することではなく、ソフトウェアの破壊に情熱を傾けています。
これを実用的な観点から見てみましょう。テストでは、テストケースを定義する必要があります。通常、指定された要件に沿ってテストケースを定義し、「ハッピーデー」ケースと「エッジケース」をカバーする必要があります。特に、後者はソフトウェアを壊すことを意図して定義されることがよくあります。一部のテストが失敗すると、バグ/欠陥が表示されます。各要件に対して妥当な量のテストケースがあり、すべてのテストに合格した場合、すべての要件が満たされていることを十分に証明できていない可能性がありますが、その可能性が向上したため、検証を行いました。
したがって、質問のその部分については、バグの発見と検証は、同じプロセスの両面にすぎない可能性があります。
テストが失敗する：見つかった欠陥
テストはパスします：確認済み（十分で適切なテストを提供する場合、少なくともある程度は）
検証について：@Mertが指摘したように、検証は受け入れテストで実行できますが、他の形式のテストでは実行できません。したがって、一般的にテストでは、一部の潜在的なユーザーによる受け入れテストとして行われた場合にのみ、検証は行われません。
それはすべて「検証」の定義に依存します。たとえば、 形式検証 は通常、QAチームによって行われるものではなく、開発者の責任です。それに伴うコストが高いため（知識のギャップと必要なリソース）、ほとんど誰も正式な検証を行いません。
ソフトウェアテストはQAと同じではありません。あなたはその権利を得ました。 ソフトウェアテスト全体には多くの段階が含まれます（煙、ユニット、回帰、統合、ユーザーの受け入れなど）自体。
したがって、ソフトウェアが要件に従って動作することを保証することは、QA（品質保証スペシャリスト-別名、何年も前は単にテスターと呼ばれていた）の主な目的です。ただし、これはテストだけではないです。 QAは、問題の製品の品質チェックを実行するための適切な一連のプロセスが実施されているか、少なくともプロジェクトの設計フェーズに組み込まれていることを保証します。
したがって、理想的には、QAが一連の要件に対してアプリケーションを検証するであることを期待し、ソフトウェアを破壊して欠陥を見つけるだけでテストするのではありません。