なぜすべての人がUATを検証アクティビティと見なすのですか？元の考えと矛盾します
ソフトウェアテストを扱っている事実上すべての本は、ユーザー受け入れテスト（UAT）が究極の検証アクティビティであると述べており、多くの場合、ベームスの非公式な定義を引用しています。「検証：適切な製品を構築していますか？」
しかし、なぜベーム自身がUATを検証と見なすのでしょうか。
ソフトウェア要件と設計仕様を検証および妥当性確認するためのガイドライン。 B.ベーム：
Vチャートから、検証アクティビティから検証アクティビティを識別する重要なアーティファクトがソフトウェア要件のベースラインであることは明らかです。これは、計画および要件フェーズ中に開発および検証され、ソフトウェア開発契約の基礎として計画および要件レビューで顧客および開発者によって受け入れられ、その後正式に変更管理される要件仕様を指します。
定義上、検証には、要件ベースラインと、それから派生する連続する改良（製品設計、詳細設計、コード、データベース、およびドキュメント）との比較が含まれ、これらの改良を要件ベースラインと一致させます。 したがって、検証アクティビティは製品設計フェーズで開始され、受け入れテストで終了します。それらは要件ベースラインの変更を導きません。そこから派生する改良点の変更のみ。
一方、検証では、要件仕様の変更によって解決する必要がある問題を特定します。したがって、開発フェーズを含むソフトウェアのライフサイクル全体で発生する検証アクティビティがあります。たとえば、製品設計のシミュレーションでは、設計がベースラインのパフォーマンス要件を満たせない（検証）だけでなく、パフォーマンス要件が費用効果の高い製品設計には厳しすぎるため、変更する必要があることを確認できます（検証）。
私が考えることができる唯一の説明は、ベームが受け入れテストをUSER受け入れテストとしてではなく、仕様に対するある種の最終チェックと見なしたということです。
さらに、すべての本が参照しているこの元の記事は、V＆Vの人工的な定義よりもはるかに明確であると思います（さらに、この観点からは間違っています）。ベーム氏によると、要件に照らして製品をチェックするとき、それは検証です。製品の使用をテストするとき、要件の変更につながる何かを見つける可能性があるため、製品を検証します。
もちろん、ベームの元のアイデアは、検証がソフトウェア作業成果物の特定の使用目的の要件が満たされていることを確認することであるISO 12207などのいくつかの標準と矛盾します。これは、仕様に照らしてチェックすることを意味します。
ほとんどの本は検証は静的であると言っていますそしてコードは実行されません。ベームによれば、それは真実ではないと思います。例えば。：
Software Engineering And Quality Assurance、A.A。Puntambekar：検証アクティビティは静的テストのカテゴリに分類されます。
ソフトウェアテストの効果的な方法：完全なガイドラインを含む、William E. Perr：V検証テスト-静的モードでのテスト-.....検証テスト（例：ユニット、統合...）
多くの著者の意見にもかかわらず、VERIFICATIONには仕様とプログラムの対応を確認するために行われるテストが含まれていると思います。検証にはテストも含まれますが、仕様に基づくものではありません。
あなたが引用する論文の冒頭のセクション で、ベームは次のように述べています。
ソフトウェア分野では、「検証」と「検証」という用語の定義についてほとんど合意がありません。
ベームは、検証と妥当性確認という用語を、残りの文章を曖昧さなく明確に提示できるようにするために、本書の残りの部分で使用することを意図して定義しています。
検証-ソフトウェア製品とその仕様の間の対応の真実を確立します。 （注：この定義は、ラテン語で「真実」を意味するveritasに由来します。データベースとドキュメントは、プログラムだけでなく、検証の対象にもなることに注意してください。）
検証-運用上の使命に対するソフトウェア製品の適合性または価値を確立するため。 （注：この定義は、「価値がある」というラテン語のvalereから派生しています。）
ソフトウェアエンジニアリングの知識体系へのガイドは、これについてもある程度の洞察を提供できると思います。
古典的な扱いでは、「検証」は静的評価方法を扱い、「テスト」は動的評価方法を扱うことが示唆されています。ただし、ISO/IECドラフト29119を含む最近の処理では、この区別があいまいになっているため、ここではテスト標準について説明します。
このすべてが言っていることは、ベームが彼の論文を書いた時点では、「検証」とは何か、「検証」とは何かについて広く受け入れられている単一の定義はなかったということです。今日でも、それは真実です。
「検証」と「妥当性確認」という用語（および「テスト」がこれらにどのように適合するか）にあいまいさが存在することがわかったので、ベームが提示した図を見ることができます。
Boehmが議論しなかったことですが、複数のソース（ISO/IEC 12207を含む）で見たように、検証では、検証アクティビティが運用環境で行われ、ユーザーの観点から意図された目的を達成できることが特に必要です。これはベームの定義によって暗示されているかもしれませんが、明確に述べられていません。
ベームは「受け入れテスト」という用語も使用しました。これを「ユーザー受け入れテスト」と解釈しています。工場受け入れテスト（FAT）など、他の種類の受け入れテストがあります。私の経験では、FATは開発組織のサイトで開発組織によって実行され、手順はお客様によって確認され、受け入れられます。これは、システム全体（すべてのソフトウェアとハードウェア）が完全に機能し、仕様を満たしていることを確認するためのチェックであり、お客様の施設に配送する前の最終検査です。ベームの定義に基づくと、これは、開発組織が運用コンテキスト内で製品を完全に実行できない検証アクティビティである可能性があります。
「ユーザー受け入れテスト」を検討しているのは、おそらく「OT＆E」-運用テストと評価です。顧客とユーザーは運用コンテキスト内で製品を確認し、ニーズを満たしているかどうかを判断できるため、これは確かに検証アクティビティです。
検証と妥当性確認の下でISO12207が要求するテスト成果物を調べることは有用かもしれません：
検証
7.2.4.3.2.3コード検証。
コードは、以下の基準を考慮して検証する必要があります。
a）コードは、設計と要件にトレーサブルであり、テスト可能で、正しく、要件とコーディング標準に準拠しています。
b）コードは、適切なイベントシーケンス、一貫したインターフェイス、正しいデータと制御フロー、完全性、適切な割り当てタイミングとサイジングバジェット、およびエラー定義、分離、および回復を実装します。
これは、とりわけユニットテストと静的分析について説明します。単体テストと静的分析は、赤い要件ベースラインを下回っています。それらはverificationアクティビティです。
7.2.4.3.2.4統合の検証。
統合は、以下の基準を考慮して検証する必要があります。
a）各ソフトウェアアイテムのソフトウェアコンポーネントとユニットは、ソフトウェアアイテムに完全かつ正しく統合されています。
b）システムのハードウェアアイテム、ソフトウェアアイテム、および手動操作が完全かつ正しくシステムに統合されている。
それは統合テストまだ検証プロセスの一部です。
検証
7.2.5.3.2.3 [テストに含まれるもの]：
a）ストレス、境界、および特異な入力を使用したテスト。
b）ソフトウェア製品をテストして、エラーの影響を分離して最小化する能力を確認する。つまり、故障時の優雅な劣化、ストレス、境界、および特異な状態でのオペレーター支援の要求
c）代表的なユーザーが、ソフトウェア製品を使用して目的のタスクを正常に実行できることをテストします。
この種のテストは、元の要件仕様で具体化されることはめったにありません。これは通常、とりわけユーザーのテストとフィードバックの結果として発生します。それは当然要件ベースラインの上に属し、検証プロセスの一部です。
ISO 12207は、「静的」テストと「動的」テストを区別していないようです。
受け入れテストに関して、私の見解では、要件が有効な要件である場合、それはテスト可能です。したがって、受け入れテストは、テストを介して要件を検証するプロセスであり、検証プロセスの一部として要件ベースラインの下に属します。
したがって、ユーザー調査の結果として生じるソフトウェア要件の変更は、検証プロセスの一部として境界線より上に属します。