SDLCのコンテキストでは、検証と検証は、前のフェーズからの成果物の入力を検証し、現在のフェーズの出力を検証することについて知っています。そして、そのテストはSDLCフェーズのフェーズの1つです。
私の研究に基づいて、私は Toronto講義ノート から以下を発見しました
別の請負業者が実施するV&V
つまり、 IV&V ( 独立した検証と検証 )の専門家はSDLCに外部から関与しているため、テスト段階とは関係ありません。
一方、私は 別のコース を見つけます:
テストが最も一般的ですが、V&Vの唯一の形式ではありません
つまり、テスターはIV&Vに関与しています。
これにより、テスト段階とIV&Vの両方が同じ人物(QAエンジニアとしましょう)によって行われるのか、IV&Vを行う人物がテスト段階に関与していないのかがわかりません。
V&Vプロフェッショナルの仕事はソフトウェア業界に存在しますか? QAエンジニア、テスター、IV&Vの間にはどのような関係がありますか?
プロジェクト管理中にV&Vプロセスはどのように関与していますか?初期段階または最終段階でSDLC内で継続的に実行されていますか?
また、SDLCにはIV&Vがステージとして含まれていますか?
ソフトウェアの検証と検証 は、ソフトウェアが意図された目的のすべてのニーズと要件を確実に満たすすべてのアクティビティです。そのため、V&Vは Quality Assurance アクティビティの大きなセットの一部です(後者には、V&Vが属する品質管理の領域を超えて、品質を向上させるアクティビティも含まれます)。
これらのアクティビティの中で最もよく知られているのは、もちろんテストです。これは、ソフトウェアが適切に機能し、期待される結果が得られ、使用可能で、許容できるパフォーマンスであることを確認します。もちろん、ユーザビリティテストと受け入れテストで、操作状態に近い人間の関与が必要な場合でも、このアクティビティは高度に自動化できます。
ただし、検証だけがテストではありません。たとえばコードレビューは、コードが堅牢かどうかを検証し、将来のメンテナンスを容易にすることが期待されるいくつかの品質基準を満たしている別のQAアクティビティです。別の種類の検証は、セキュリティに関連しています。これらの種類のコードレビューは、望ましくないステルス動作がソフトウェアに隠されていないこと(たとえば、運用中に外国にデータを送信するスパイ機能)がないこと、または故意に脆弱性が埋め込まれていないことを確認するために必要になる場合があります。
今日、V&Vは、必ずしもウォーターフォールのようなSDLCでの連続したステップであると見なされるべきではありません。これらのアクティビティは、アジャイルプロセスの日常のアクティビティにスムーズに統合できます(例:doneの定義に埋め込まれています)。
独立したV&V は別の(高価な)ものです。これは、ミッションクリティカルなシステム(航空機システム、製薬会社の工場システムなど)および政府の取得プロセスのコンテキストでよく見られます。その理由は、チームメンバー(またはサプライヤーのスタッフメンバー)が無意識の偏見を持っているか、不完全な検証手順を適用している可能性があるためです(人の生活が依存するシステムには適切ではない純粋に経済的な考慮事項のため、手順に欠陥がある可能性もあります)。これが independent チームが必要になる場合がある理由です。それは、V&Vが可能な限り客観的に、最先端の専門知識を用いて実行されることを保証することです。
したがって、V&VとIV&Vは関連性が高いです。 2番目は、適切な 職務の分離 を考慮して、別の経済運営者が実行する必要があるというだけのことです。場合によっては、V&Vまたは独立したV&Vも法的要件の対象となる可能性があることに注意してください。
関係...は存在しません。
最近のソフトウェア開発には、一般に、入力を受け取って検証し、いくつかの作業を行ってから、それを組立ラインに渡すという個別のフェーズはありません。そして最近では、テスターやその他の品質保証業務のために別の役割を持つことさえ、ますますまれになっています。
ほとんどのソフトウェアに必要な規模で、検証プロセスは自動化され、継続的な展開プロセスに含まれています。これらのテストを自動化する専任の専門家が時折いますが、彼らは単なるQAエンジニアまたはSoftware Develoment Engineer in Test(SDET)です。レーベルはそれほど重要ではありませんが、V&Vの使用を聞いたことがありません。