IQ OQ PQとは：ソフトウェア検証プロセスの3つのQ

what are iq oq pq 3 q s software validation process

IQ-OQ-PQの紹介：

IQ、OQ、およびPQは、ソフトウェア妥当性確認プロセスの3Qを構成します。

テスターとして、ソフトウェア開発チームがソフトウェア要件仕様（SRS）、機能仕様に従って社内でソフトウェアを開発し、その後、テストチームがさまざまなテスト環境でのさまざまなレベルのテストで実装を検証することを知っています。ハイエンド。これにより、本番環境が複製されます。

SDLCのこのアプローチでは、ソフトウェア開発チームは通常、完成したソフトウェア（開発および検証済み）を運用チームに渡すことで手を洗い流します。さらに、運用環境への展開を担当し、エンドユーザーが使用できるようにするのは運用チーム（一般に運用チームと呼ばれます）です。

ここで、運用チームが本番環境でソフトウェアを機能させるための真の課題があります。ソフトウェア開発フェーズでは、開発と検証はシミュレートされた環境で行われ、実際の環境に近いことはめったにありません。データの可用性と本番環境の構成の場合。

ここで、ソフトウェアの検証が重要になります。検証が完了し、ソフトウェアがプログラム/製品チームによって承認されると、運用チームは、ソフトウェアが本番環境に展開されることを受け入れる前に一連のアクティビティを実行し、ソフトウェアが期待どおりに動作していることを証明します。検証活動に他なりません。

学習内容：

• 検証と妥当性確認
• 検証プロセスのフェーズ
• 3Qのアプローチ：IQ-OQ-PQ
  • インストール資格（IQ）
  • 運用資格（OQ）
  • パフォーマンス認定（PQ）
  • 結論
  • 推奨読書

検証と妥当性確認

ここでは、「検証」アクティビティと「妥当性確認」アクティビティの違いを明確に理解しましょう。 ' 検証 ’は、開発者とテスターがソフトウェア開発サイトで社内で行う、指定された一連の要件と仕様に関してソフトウェアを評価することです。

一方、「 検証 ’は、外部の顧客、所有者、ベンダーが納品する製品について実施する一連の品質保証チェックであり、製品を受け入れるか購入する前に適合性をチェックします。検証活動は主に生産現場で行われます。

したがって、アプリケーション開発の場合、ソフトウェアの検証アクティビティを実行しているのはOpsチームです。

また読む：

https://www.softwaretestinghelp.com/difference-between-verification-vs-validation/

検証プロセスのフェーズ

一般に、製品の検証プロセスとは、開発から使用および保守までの製品のライフサイクル全体を指します。したがって、検証プロセスは5つのフェーズに分けられます。

検証プロセスの5つのフェーズは次のとおりです。

検証プロセスのこの5段階のアプローチは、製造、医療、製薬などの多くの業界で採用されています。ここでは、機械、機器、または製品を購入する前に、エンドカスタマーが検証を行います。

ソフトウェアの検証アクティビティの構成要素は、「ソフトウェアがユーザーによる使用の準備ができている」ことを証明し、主にソフトウェアのインストールが成功したことを検証し、続いて機能と操作性を検証することです。

3Qのアプローチ：IQ-OQ-PQ

ただし、ソフトウェアのコンテキストでは、 3Qのアプローチ、IQ-OQ-PQ 検証の一環としてフォローされており、運用チームによって実行されます。運用チームは、ソフトウェアを本番環境に展開する最終的な責任を負います。

以下に、検証プロセスのフロー図を示します。

3Qを実行するために入力されるテンプレート、計画、およびその他のドキュメントは、ソフトウェアチームによってソフトウェア用にレイアウトされ、これらの資格の一部として実行される詳細なアプローチ、タスク/アクティビティ/テストが含まれます。テスト結果で。

要約レポートは、ソフトウェアの引き渡し中に、バイナリやその他の成果物とともにOpsチームに渡されます。

高レベルでは、

全体として、IQ、OQ、およびPQを実行する目的は、ソフトウェアを正常に展開し、ボトルネックなしですべての機能を使用できるようにすることです。

理想的には、IQ、OQ、およびPQは順次アクティビティであり、順番に実行する必要があります。インストールが行われない限り、ソフトウェアの機能を検証することはできず、機能が証明されない限り、パフォーマンスを測定する意味はありません。時間の制約により、OQの重要な側面が確立されると、PQはOQと並行して開始される場合があります。

ここで、これら3つのフェーズのそれぞれについて詳しく理解しましょう。

インストール資格（IQ）

設置資格は、 「IQ」 は、提供されたソフトウェア（バイナリ、スクリプトなど）が指定された構成で指定された環境に正常にインストールできるかどうかを検証し、これらのインストール手順が「インストールガイド」というドキュメントにどのように記録されているかを確認するプロセスです。

以下のアイテムは、提供されたソフトウェアパッケージとともに開発チームによって提供され、IQを実行するために運用チームによって使用されます。

1） 選択した環境でのインストール手順を説明する「インストールガイド」ドキュメント。

2） ソフトウェアの構成をセットアップするための「構成ガイド」ドキュメント。このドキュメントは、インストールガイドドキュメント自体の一部になる場合があります。

3） ソフトウェアパッケージとインストールスクリプト、できれば自動化されたスクリプト。

ソフトウェアのインストール認定フェーズは、最も重要なフェーズであり、通常は多くの問題であると考えられています 開いた このフェーズでアップします。

理由：

に） 開発環境では、インストールの問題を検証するために100％リアルタイムの環境を利用できないため、環境の違いがいくつかの問題の原因になります。

b） さまざまな理由により、ソフトウェア開発の初期段階では、開発チームと運用チームの間で、問題を十分に先取りするための十分なコラボレーションと調整が行われない場合があります。

c） 実際のインストール手順をドキュメントに記録しているときに、ドキュメントの問題が発生する可能性があります。これは、実稼働環境では正確に一致しない場合があります。

最近では、ソフトウェアのインストール手順全体が一連のスクリプトを介して可能な限り自動化されています。インストールに問題がある場合は、構成の不一致が原因で自動インストールが失敗し、それらの問題を修正するための手動介入が必要です。

Opsチームはインストールガイドのソフトウェアチームの指示に厳密に従ってIQを実行するため、「インストールガイド」が次のように記述されていることを確認することは非常に重要であり、ソフトウェアチームの責任でもあります。インストール手順は、リアルタイム環境に一致します。

また、テスターは、「インストール」プロセスが完全性についてのドキュメント検証とともに社内で検証されていることを確認し、システムで実行される実際のステップとの不一致を特定して、インストールガイド。

実稼働環境でのソフトウェアインストール時の問題を最小限に抑えるために、インストールガイドを作成して社内で検証する際には、次の点に注意する必要があります。

上記のすべての点に注意する必要があるため、人的エラーを回避するために、最小限の人的介入でソフトウェアのインストールプロセスを自動化することがベストプラクティスです。

IQ検証フェーズ中に問題が見つかった場合は、ソフトウェアチームに報告され、修正されると、 スモークテストとビルド検証テスト ソフトウェアのインストールが成功したかどうかを確認するために実行されます。

したがって、IQフェーズには、ソフトウェアパッケージのインストールと、それに続くビルド検証とスモークテストの実行が含まれます。

したがって、ソフトウェアを正しく正しくインストールすることで、機能障害に関連する問題のほとんどが確実に解消されるため、IQフェーズを正常に完了することは非常に重要です。

運用資格（OQ）

運用資格、別名 何 IQが正常に完了した後のソフトウェア検証プロセスの次のアクティビティです。

運用資格活動にはtが含まれます 彼は、ソフトウェアが消費者に展開するのに運用上適切であることを確認するために実行されるテストを行います。理想的には、ソフトウェアの主要な機能は、この検証プロセスの一部として検証されます。

OQ検証を実行するためのOQ計画は、ソフトウェアチーム（テスター）が作成する必要があります。これは、実行する必要のあるOQテストのすべての側面をカバーする必要があります。テスト、テストスケジュール、方法論、ツール、サービスへの影響、テストの実行シーケンス、問題の報告方法と問題を修正するためのSLA、欠陥トリアージアプローチなど。

OQの一部として実行される運用認定テストは、ソフトウェアの成果物とともにソフトウェアチームによって再度提供されます。これらの運用認定テストは、「機能要件仕様」ドキュメントに基づいて設計された重要なテストのコレクションであり、ソフトウェアシステム全体が期待どおりに機能することを確認します。

このOQテスト仕様書は、機能要件仕様書に対してテストエンジニアが作成します。多くの場合、このドキュメントは、SDLCのシステムテストフェーズで作成および検証されたシステムテスト仕様ドキュメントのサブセットになります。

テストは、運用チームの要件とそれが実行されるサイトの条件に合わせて変更または更新される場合があります。

したがって、OQの一部であるテストを選択する際には、すべての主要な機能と主要なビジネスワークフローがこの検証の一部として含まれていることを確認するために、さらに注意を払う必要があります。

以下は、OQテスト仕様書を準備する際のテスター向けのヒントです。

したがって、このように準備されたOQ計画とテスト仕様は、関連する利害関係者によって徹底的にレビューおよび承認され、主にカバレッジが少なすぎたり多すぎたりせず、すべての主要な機能がカバーされていることを確認する必要があります。

OQが正常に完了すると、ソフトウェアは選択した環境での運用仕様に従って機能することが示されます。これは、ソフトウェアを本番環境に移行するためのステージゲートであり、検証プロセスの次のアクティビティである検証プロセスを進めるためのシグナルです。 PQ 。

パフォーマンス認定（PQ）

IQが正常に完了した後、検証プロセスの次のアクティビティは、製品/ソフトウェアが、本番環境でボトルネックを発生させることなく、予想される負荷の下で指定されたパフォーマンスの側面を一貫して満たすかどうかを確認することです。

PQの重要な側面は、ソフトウェアが期待されるシステムにインストールされたときに、 ライブ負荷を処理し、期待される応答時間を満たすことができ、同時ユーザーを処理している間、ピーク負荷とストレスの下でクラッシュしません。

したがって、PQは主に、ソフトウェアの指定されたパフォーマンス基準が、ライブのパターンと同様に、さまざまな負荷条件で信頼できる基準で一定期間（おそらく1週間）にわたって達成されるかどうかを確認することです。したがって、これらのテストは、ソフトウェアシステムの動作を監視するために毎日実行する必要があります。したがって、システムのパフォーマンスが証明されるまで、PQの完了にはしばらく時間がかかります。

理想的には、PQ検証は、OQの完了後に実行されます。ここで、ソフトウェアの機能が保証され、製品またはソフトウェアのパフォーマンス面の検証を進めることができます。時間の制約により、OQの完了率の信頼度に基づいて、PQをOQと並行して開始できる場合があります。

これらのパフォーマンステストは、システムが完全にロードされたライブシステム、またはライブと同様の条件で実行し、パフォーマンスの側面にボトルネックがないことを確認するのが理想的です。

以下のテストは通常​​、パフォーマンス認定の一部として実行されます。また、テストの選択はソフトウェアによって異なります。

＃1）可用性テスト： ソフトウェアがクラッシュしたりダウンしたりすることなく継続的に利用できるようにするため。

＃2）アクセシビリティテスト： ソフトウェアが問題なく期待されるパフォーマンス速度であらゆる場所から簡単にアクセスできるようにするため。

＃3）負荷テスト： 予想される日々の負荷およびピーク負荷条件下でのシステムの動作を測定します。

＃4）ストレステスト： 極端な負荷条件下でシステムのブレークポイントを測定します。

＃5）スループットパフォーマンステスト： システムの応答時間を測定し、TPS（1秒あたりのトランザクション数）を測定します。

＃6）スケーラビリティテスト： システムは、予想される同時ユーザーを処理するように拡張できます。

パフォーマンステストシナリオと対応する自動スクリプトは、「ユーザー要件仕様」ドキュメントで指定されているパフォーマンス関連の要件に基づいて作成されます。

OQ計画と同様に、テストアプローチ、戦略、計画、およびスケジュールをツールとともに明確に示す詳細なPQ計画を作成し、PQエグゼキュータで実行する必要があります。

パフォーマンスメトリクスを測定および報告するには、PQが実行されている環境にパフォーマンステストおよび監視ツールをインストールする必要があります。

以下は、運用チームがPQを正常に実行できるようにするためのテスター向けのヒントです。

PQが正常に完了すると、パフォーマンス要件を満たすことが非常に重要になります。パフォーマンスに関連する逸脱は、ユーザーに不快感を与えて大きなビジネス上の損失を引き起こし、使用するソフトウェアへの信頼が失われ、ソフトウェアの障害につながるためです。

一言で言えば、t 以下の表は、IQ-OQ-PQの活動をまとめたものです。

次の表は、各検証フェーズのさまざまな入力について説明しています。

結論

製品/ソフトウェアがすべての検証段階を通過し、IQ-OQ-PQのいずれかを証明できなかったとしても、結果は悲惨なものになる可能性があり、莫大な費用がかかります。 したがって、IQ-OQ-PQのみが正常に完了すると、開発サイトから生産サイトへの製品の転送が成功します。

全体として、IQ-OQ-PQ検証プロセスが正常に完了すると、ソフトウェアに対する信頼が得られるだけでなく、クライアント、所有者、ソフトウェア開発者、およびテスターに​​も安心感がもたらされます。

例のあるウォーターフォールモデルとは

IQ-OQ-PQを実行すると、テストを実行せずに実際に展開するリスクも軽減され、障害のコストが削減され、製品のリコールのリスクが軽減されます。

したがって、Guys、ソフトウェア開発者、およびテスターは、社内で開発とテストを完了し、ソフトウェアをOps Teamにリリースした後、祝賀会はありません。 祝賀会は、IQ-OQ-PQが正常に完了し、ソフトウェアが対象のシステムで稼働している場合にのみ行われます。

したがって、ソフトウェアが成功するかどうかは、IQ-OQ-PQが正常に完了し、ソフトウェアが稼働してエンドユーザーが使用できるようになる時期に依存します。

著者について： この記事は、STHチームのメンバーであるGayathriSubrahmanyamによって書かれました。彼女はソフトウェアテストの分野で20年以上の経験があります。彼女はテストのキャリアの中で、テスト配信の処理に加えて、多くのTMMI評価、テスト工業化作業、TCOEセットアップを行い、大規模なエンゲージメントのためにDevOpsプラクティスを実装しました。しかし、彼女によると、学習は止まることはありません…

検証プロセスの実行に関する経験を共有し、この記事について質問がある場合はお知らせください。

推奨読書

• ソフトウェアテストコース：どのソフトウェアテスト機関に参加する必要がありますか？
• 最高のソフトウェアテストツール2021 (QAテスト自動化ツール)
• ソフトウェアテストQAアシスタントジョブ
• キャリアとしてのソフトウェアテストの選択
• ソフトウェアテストテクニカルコンテンツライターフリーランサーの仕事
• いくつかの興味深いソフトウェアテストのインタビューの質問
• ソフトウェアテストコースのフィードバックとレビュー
• ソフトウェアテストはアフィリエイトプログラムを助けます！