メニュー

リスクベーステストの究極のガイド：ソフトウェアテストにおけるリスク管理

  • メイン
  • テスト戦略
  • リスクベーステストの究極のガイド：ソフトウェアテストにおけるリスク管理

ultimate guide risk based testing

問題を排除するために楽器を試してください

リスクベーステスト、リスク管理、およびそのアプローチの究極のガイドと例：

リスクベーステストとは何ですか？

リスクベーステストとは、テストを実行するか、シナリオを設計および実行することです。これにより、顧客が特定したビジネスに悪影響を与える上位のビジネスリスクが、ライフサイクルの早い段階で製品または機能で発掘されます。緩和策を実施することで緩和されます。

=> 完全なテスト計画チュートリアルシリーズについては、ここをクリックしてください

リスクベーステスト

悪影響には、コストへの影響、顧客の不満、ユーザーエクスペリエンスの低下、さらには顧客を失う程度まで含まれる可能性があります。

言い換えれば、RBTのアプローチは、ユーザーがテストを行う方法でテストが行​​われることを保証することです。 バグを見つける 本番環境では、ソフトウェアの使用を妨げたり、ビジネスに深刻な影響を与えたりすることはありません。

RBTは、製品のリスクに基づいて実行されるテストです。 RBTは、テストケースに優先順位付け手法を使用することにより、本番環境で特定の機能が失敗するリスクと、コストやその他の損害の観点からビジネスに与える影響を事前に把握する必要があります。

したがって、リスクベーステストは次の原則を使用します。 テストの優先順位付け 製品またはソフトウェアの機能、モジュール、および機能の概要。優先順位付けは、本番環境でその機能が失敗する可能性のリスクと、それが顧客に与える影響に基づいています。

学習内容：

リスクベーステストとそのアジャイルおよびDevOpsとの関連性

ソフトウェアの開発に費やされた300時間は、本番環境で1つの欠陥が特定されるだけで、わずか30秒で役に立たなくなる可能性があります。

これは、他の選択肢がなく、市場から撤退するだけで、製品全体の目的を台無しにする可能性があります。そしてそれが「品質テスト」の重要性と必要性​​です。

テクノロジーの急速な成長に伴い、ソフトウェアは複数のOS、複数のプラットフォーム、複雑なITインフラストラクチャなどをサポートするクラウド上でホストされ、エンドユーザーは機能やオプションについてますます煩わしくなり、顧客満足度を妥協することはありません。 。

今日、「品質」はソフトウェア配信の重要な要素になりつつあり、顧客を満足させるために品質を改善するために継続的な改善が行われています。

ほとんどすべてのテスターが、テストウィンドウが圧迫され、通常、ビルドが最後の最後にテストのためにテスターに​​渡されるという大きなプレッシャーにさらされることは、一般的な問題であることに気付くことがよくあります。設計したすべてのテストを実行するのに十分な時間とリソースがなく、自動化の範囲が常に100％であるとは限らず、独自の課題があります。

リスクベーステストの要因

RBT時間の不足

納期を逃すことはできませんが、同時に品質も損なわれることはありません。プランBが、他のチームから引き出してテストリソースを追加することがうまくいかない場合でも、プランCは、他のすべてのアクティビティの実行を停止し、これだけに努力を振り向けることは、実際には役に立ちません。ただし、最終的には、テストリソースの多くの追加はうまくいきません。

RBTより少ない時間

他に選択肢はありませんが、利用可能な時間とリソースの範囲内で限られた重要なテストを実行するだけです。

では、この段階でどのテストが重要であるかをどのように判断するのでしょうか。テスターが重要と考えるものは何でも、顧客にとってそれほど重要ではないかもしれません。機能の重要性は誰の観点から決定されますか？重要なテストは誰が決めるのですか？そして、他にも多くの疑問が生じ続けています。

これらすべての質問に答え、上記の状況を効果的に処理するために、 「リスクベーステスト」 、まもなく呼ばれる 「RBT」 が誕生し、チームは「プロジェクトリスク」基準に基づいてテストシナリオを明確に計画および特定しました。

QAチームは重要なテストを明確に把握していますが、RBTは、顧客およびビジネスの観点から重要で重要なテストを特定するための実証済みの方法です。 「リスク分析」 手順 。

そのため、ソフトウェアの欠陥を単純に特定する従来の方法とは異なり、技術の変化、高品質のソフトウェアをリリースするための市場での競争の激化、導入により、QAのアプローチと目標は時間とともに変化しました。 「すべてを自動化」、そしてソフトウェアを数時間にわたって提供するアジャイルとDevOpsの実践の全体的な紹介。

したがって、「テスト原理」の現在の傾向は、単に「欠陥を特定する」だけでなく、

＃1） 生産の失敗または失敗の可能性が高いためにビジネスに大きな影響を与える製品の領域に焦点を合わせます。

＃二） 焦点を当て 欠陥の特定 早期にチームがそれをできるだけ早く修正できるようにすることで、ソフトウェア/製品または機能を 「FailFast」。

＃3） QAチームのサービスの最も重要な側面は、顧客に焦点を当てることで、顧客に価値をもたらすことです。 「エンドツーエンドのカスタマーエクスペリエンス」。

リスクベーステストアプローチ

十分な数のテストを設計して実行したとしても、テストが十分であり、ソフトウェアに欠陥がないということは、常に試験の準備のようなものです。

テストケースの数を増やすだけでは、ソフトウェアの安定性が二重に保証されない点があります。現時点では、テストの数だけでなく、実際に顧客がリリースに期待していることに焦点を当てています。

したがって、テストの合理的な努力で最大の利益を得るには、テストの最適化のバランスをとることが不可欠です。また、これは、テストのタイムラインが非常に厳しく、十分なテストを実行するのに十分なリソースが利用できない場合に、より重要になります。

したがって、この場合、RBTアプローチは、QA作業を最適化し、ビジネスリスクを最小限に抑えてテストのメリットを最大化する上で重要な役割を果たします。

したがって、上記の側面に焦点を当てると、QAの作業は大幅に軽減されます。彼らは週末をオフィスで燃やし、ソフトウェアを継続的にテストし、テストから生じるすべてのS4（重大度4）およびP4（優先度4）の欠陥について心配する必要はありません。

さて、4はテストにおける欠陥の最低の優先順位と重大度と見なされます。彼らは、プロジェクトの他の有用な側面により多くの時間を投資することができます。

「リスクベーステスト」アプローチの主な推進要因を要約すると、次のようになります。

  • ビジネスの観点から「顧客が望むもの」をテストできるようにするため。
  • 期待される品質でタイムスケジュールを満たすため。
  • QAの取り組みを最適化するため。

RBTアプローチはいつ使用しますか？

これは、以下のシナリオで使用されます。

  • RBTアプローチは、プロジェクトの時間、コスト、およびリソースに制限または制約がある場合、およびリソースを最適化する必要がある場合にいつでも使用できます。
  • RBTアプローチは、プログラムがより複雑で、新しいテクノロジーを採用しているため、多くの課題を伴う場合に使用されます。
  • プログラムがR＆Dプロジェクトであり、それが第一種のタイプであり、プロジェクトに多くの未知数とリスクがある場合。

RBTアプローチの例

IT業界では、生産とその影響が直面するリスクを克服するために、いくつかのリスクベースの分析アプローチが使用されています。

以下にそのようなアプローチの1つを示します。

RBTのこのアプローチには、製品の「重要な機能または主要な機能」を特定し、これらの各機能が本番環境でさらされるリスクを評価し、リスクを軽減または軽減するための適切な軽減策を実装することが含まれます。

したがって、RBTアプローチには、障害が発生する可能性が高く、ビジネスに最も大きな影響を与える機能のテストが含まれます。障害の種類は、運用またはビジネス、技術、外部などです。

リスクベースの分析アプローチ

リスク分析を実行する方法

製品のすべての機能についてソフトウェアテストでリスク分析を実行するためにそのように定義された標準的なプロセスまたはテンプレートはありません。さまざまな組織が独自のアプローチを使用してリスク分析方法を行っています。

さまざまなプロジェクト項目に対してリスク分析を実行して、リスクを特定し、分析のためのRBTアプローチを実装できます。それらのアイテムには、

  • 特徴
  • 機能性
  • ユーザーストーリー
  • 要件
  • ユースケース
  • テストケース

この場合、リスクベーステストアプローチの実装を理解するために、テストケースのみに焦点を当てましょう。

リスク分析手順

リスク分析には、プログラムの関連する利害関係者の関与が含まれます。 技術チームとビジネスチーム」 これには、製品の所有者、製品マネージャー、ビジネスアナリスト、アーキテクト、テスター、および顧客担当者が含まれます。

これらの利害関係者が関与するブレーンストーミングセッションは、製品の各機能の重要性を特定し、障害のリスクと本番環境でのエンドユーザーへの影響に基づいて優先順位を付けるためのディスカッションを実行するために編成されます。

要件ドキュメント、技術仕様ドキュメント、アーキテクチャと設計ドキュメント、ビジネスプロセスドキュメント、ユースケースドキュメントなどのさまざまな「プロジェクトドキュメント」が、ブレーンストーミングセッションの入力になります。

製品および市場にある既存の製品に関する利害関係者の知識も、議論の入力要素になります。

他のいくつかの入力ソースも含めることができます、

  • 最も使用されている機能に関する入力を収集します。
  • ドメインの専門家に相談することからのインプット。
  • 以前のバージョンの製品または市場に出回っている同様の製品のデータ。

間に ブレーンストーミング セッションでは、これらの各機能に関連するリスクが特定されます。リスクの種類は、運用、技術、またはビジネス関連である可能性があります。それらに関連するテストとシナリオは重み付けされ、リスク値はリスク発生の可能性とリスクの影響に基づいて評価されます。

「リスク発生の可能性」は、次の理由で発生する可能性があります。

  • 製品開発チームによる機能の理解が不十分です。
  • 不適切なアーキテクチャと設計。
  • 設計に時間が足りません。
  • チームの無能。
  • 不十分なリソース–人、ツール、テクノロジー。

「リスクの影響」とは、障害が発生した場合のユーザーとビジネスへの障害の影響です。影響は、

  • コストへの影響、結果として損失。
  • ビジネスの損失または市場シェアの損失につながるビジネスへの影響、訴訟手続き、ライセンスの喪失。
  • 品質への影響。製品のリリースが標準以下または無能になります。
  • ユーザーエクスペリエンスが悪く、顧客の不満や喪失につながります。

機能または製品のリスクを評価する際の重点分野は、次のとおりです。

  • 機能のビジネス上の重要性の領域。
  • 最もよく使われる機能と重要な機能。
  • 欠陥が発生しやすい領域
  • 安全性とセキュリティへの影響をもたらす機能。
  • 複雑な設計とアーキテクチャの領域。
  • 以前のバージョンから行われた変更。

リスク分析の方法論

ここで、「リスクベーステストの方法論」について詳しく理解しましょう。

リスクベーステストアプローチでは、テストサイクルのすべてのテストフェーズで基準としてRISKを使用します。 テスト計画 、テスト設計、テスト実装、 テストの実行 、およびテストレポート。理想的には、多数の可能なテストシナリオの組み合わせを設計できます。

したがって、RBTアプローチには、リスクの重大度に基づいたテストのランク付けが含まれ、ビジネスに大きな影響を与える最も欠陥のある、またはリスクの高い障害領域を見つけます。

リスク分析の主な目的は、 '高い価値' 製品の特徴、機能、要件、 ユーザーストーリー 、およびテストケース、および ‘ 低い価値' そのため、後で「価値の低い」テストケースに焦点を当てることなく、「価値の高い」テストケースに焦点を当てるようになります。これは、リスクベーステストを開始する前のリスク分析の最初のステップです。

テストケースを高値と低値に分類またはグループ化し、これらの各テストケースに優先度の値を割り当てる主なタスクには、次の手順が含まれます。

ステップ1）3X3グリッドを使用する

リスク分析は、3X3グリッドを使用して実行されます。このグリッドでは、各機能、非機能、および関連するテストケースが、利害関係者のチームによって「可能性失敗の影響」と「失敗の影響」。

リスク分析

プロダクションの各機能が失敗する可能性は、通常、「技術専門家」のグループによってアクセスされ、グリッドの垂直軸に沿って「失敗する可能性が高い、非常に可能性が高い、可能性が低い」として分類されます。

失敗の可能性

モバイルアプリケーション用の自動化テストツール

同様に、本番環境でのこれらの機能の「障害の影響」は、テストされていない場合、エンドカスタマーが経験します。 ' ビジネススペシャリスト」であり、グリッドの横軸に沿って「マイナー、可視、および中断」カテゴリに分類されます。

失敗の影響

ステップ2）失敗の可能性と影響

すべてのテストケースは、下の図に点で示されている障害の可能性と障害の影響の識別された値に基づいて、3 X3グリッドの象限に配置されます。

失敗の可能性と影響

明らかに、障害の可能性が高く、障害（中断）の影響が大きいことがグリッドの右上隅にグループ化されています。これは非常に重要であるため、「高値」テストと「低値」テストがグループ化されていることがわかります。左下隅。お客様にとって重要性が最も低いか、まったく重要ではありません。これらの機能やテストケースに焦点を当てることはできません。

ステップ3）優先グリッドのテスト

グリッド内のテストケースの上記の配置に基づいて、テストに優先順位が付けられ、優先順位1、2、3、4、および5のラベルが付けられ、それぞれに対してマークが付けられます。最も重要なテストは1に配置されていますst優先度1が割り当てられ、同様に重要度の低いグリッドは、2、3、4、および5としてランク付けされます。

最後に、すべてのテストケースが優先順位番号に基づいてソートされ、優先順位に従って実行のためにピックアップされます。優先度の高いものが最初に実行のためにピックアップされ、優先度の低いものは後で実行されるか、スコープが解除されます。

優先グリッドのテスト

ステップ4）テストの詳細

次のステップは、定義されたテスト範囲のテストの詳細レベルを決定することです。テストの範囲の深さは、下のグリッドに従って上のランキングに基づいて決定できます。

ランク1の優先度の高いテストは「より徹底的に」テストされるため、専門家が配置され、これらの重要度の高い機能とそれに関連するテストケースをテストします。同様に、優先度2、3、および4のテストケース。利用可能な時間とリソースに基づいて、優先度5の機能とテストのスコープを解除する決定を下すことができます。

テストの詳細レベル

したがって、機能とそのテストケースに優先順位を付けるテストの詳細レベルのアプローチは、テスターが「高価値テスト」を特定するのに役立つだけでなく、これらの優先順位に基づいて「テストの詳細レベル」を決定するようにガイドします。最適化プロセスにより、より良いテストを実行し、テストコストを削減するのに役立ちます。

RBTはアジャイルとDevOpsにどのように関連していますか？

さて、特定の機能の「失敗のリスク」とライブでの「顧客への影響」に応じてテストの優先順位に基づいてテストを実行するリスクベーステストのアプローチを理解した後、明らかに次の疑問が生じます。アジャイルおよびDevOpsプラクティスにおけるリスクベーステストアプローチの関連性。

「すべてを自動化」、「すべてをテスト」、「継続的にテスト」、「繰り返しテスト」は、これらのプラクティスの重要な概念です。

コードに変更があったり、リリースがあったりするたびに、設計されたすべてのテストが自動化されて実行されます 継続的インテグレーション（CI） / 継続的デリバリー（CD） 優先順位に関係なく、パイプラインをすばやく繰り返し実行します。

では、RBTとDevOpsの関係は何ですか？ RBTはどこに適合し、アジャイルとDevOpsに関連するようになりますか？

アジャイルとDevOpsに対するRBTの関連性

＃1） はい、前に述べたように、すべての業界とすべての製品がテスト実行に対して100％の自動化をカバーしているわけではありません。したがって、チームが手動テストケースの選択からテスト実行の優先順位を選択する必要があり、他のアクティビティに向けてテストリソースのエネルギーと労力を節約したい場合は、RBTが最良の選択です。

リスクベースのアプローチは、優先度の高い自動テストを実行し、できるだけ早くテストするためのより良い方法でもあります。

＃二） QAチームは、要件分析中にRBTアプローチをより効果的に採用して、要件を分析し、製品と機能の予想されるリスクの事前レポートを提供して、プログラムチームがそれを軽減するために適切なアクションを積極的に実行できるようにします。

＃3） RBTアプローチは、高リスクに基づくテストケースとシナリオの設計に効果的に使用できるため、高リスクの機能にさらに焦点を当てることができます。

＃4） 「高リスク」領域を特定することで、QAチームは、「高スキルテスター」を使用して「より徹底的に」テストするために、それらの領域にテスト作業を集中させることができます。

＃5） 「FailFast」は、ご存知のとおり、「アジャイル」と「DevOps」の概念です。RBTアプローチは、ソフトウェアの「高リスク」領域を特定し、欠陥を早期に特定して、迅速に失敗して失敗できるようにするのに役立ちます。まず、チームに修正させます。

＃6） アジャイル/ DevOpsの最終的な目標は「顧客重視」であるため、RBTアプローチにより、QAは単に欠陥を見つけるだけでなく顧客体験に集中することができます。

Devopsとアジャイルでのリスクベーステスト

リスクベーステストアプローチの利点

要件の分析、テストシナリオの設計と実行という、RBTアプローチの目的と使用法についてはすでに理解しています。 RBTにはいくつかの利点があります。

リスクベーステストの利点を次のように統合して一覧表示できます。

  • テストリソースのより効率的で最適化された使用に役立ちます。
  • 優先順位付けにより、QA作業、テスト、テストの設計と開発、およびテスト準備のアクティビティを容易にするのに役立ちます。
  • 重要なリソースを重点分野に割り当てることで、QAリソースの管理を改善します。
  • これは、リソースの効果的な利用に役立ち、プロジェクトのより良いものに時間とエネルギーを振り向けます。
  • QAチームが、リスク評価と不安定で高リスクの領域の特定に基づいてテスト作業を計画するのを支援します。
  • これは、チームが重要性に応じて実行するテストを最適化するのに役立ち、したがって、利害関係者と合意して、価値の低いテストのスコープを解除します。
  • 全体として、最適化および削減されたテストアクティビティを通じて、コスト削減に役立ちます。
  • RBTアプローチにより、QAチームは最初にリスクの高い領域をテストし、製品を「迅速に失敗」させ、迅速に修正することができます。
  • RBTアプローチは、「 テストカバレッジ」 利害関係者のグループ全体に対する「テスト範囲」。
  • チームは、リスクの高い領域への集中を増やし、リスクの低い領域への集中を減らすことができます。
  • RBTにより、チームは製品リスクを軽減するための最も効果的な方法の実装を事前に決定することができます。
  • RBTは、緩和策の不適切な実装の影響を回避するのに役立ちます。
  • リスクベーステストにより、チームは適切なアクションを実行して、不測の事態を軽減または計画するか、Liveでリスクが発生した場合に障害を克服するか、その影響を軽減するための回避策を配置できます。
  • RBTは、リリースの残留リスクを最小限に抑えるのに役立ちます。
  • これは、生産におけるより安価な欠陥を通じて「品質の向上」を達成するのに役立ちます。
  • 最終的には、「顧客体験の向上」と「顧客満足」に役立ちます。

次に、ソフトウェアテストライフサイクルのテスト計画フェーズとテスト実行フェーズでリスクを管理する方法を学習します。

テスト計画中のリスク管理

テスト計画フェーズ中にリスクを管理する方法：

人生はリスクに満ちており、ソフトウェアプロジェクトも同様です。何かがいつでもうまくいかない可能性があります。私たちは常に物事を正しくするために努力していますが、何も問題がないことを確認し、問題が発生したときに何をすべきかを正確に把握するのはどうでしょうか。リスク管理に入る–これは、リスクを防止、理解、発見、克服するための準備をするソフトウェアテストプロジェクトの一部です。

リスクは単に発生する可能性のある問題であり、発生すると損失を引き起こします。

損失は​​、お金、時間、労力、または品質の妥協など、何でもかまいません。損失は​​決して良いものではありません。どれだけスピンを与えても、それはポジティブではなく、決してポジティブではありません。したがって、 危機管理 は、リスクを処理し、損失を防止/削減するためのソフトウェアプロジェクトの不可欠な部分です。

テスト計画中にリスクを管理する方法

リスクベーステスト ： 私たちはQAコミュニティであるため、リスクとそれに関連するプロセスをQAの世界だけに限定していきましょう。リスクは、大まかに2つのフェーズで評価および管理されます。 ソフトウェアテストのライフサイクル 。 STLCは、テスト計画、テスト設計、およびテスト実行の3つのフェーズに分類できます。

リスク管理プロセスは、次の2回発生します。

  1. テスト計画
  2. テストケースの設計（終了）または場合によってはテスト実行フェーズ

ケース1では必須ですが、ケース2では、より「必要に応じた」状況になります。

リスクベーステストプロセス

2部構成の記事シリーズ：

基礎となるプロセスは同じですが、 リスクの種類 これらの両方の分野で扱われることは完全に異なります。それらを個別に正義するために、2部構成のシリーズとして異なる方法で処理します。

このセクションでは、「テスト計画中のリスク管理」。

リスク管理プロセス

リスク管理の一般的なプロセスには、次の3つの重要な段階があります。

  1. リスクの特定
  2. リスク影響分析
  3. リスクの軽減

リスクと軽減の例のテスト：

＃1）リスクの特定

言われているように、問題を解決するための最初のステップはそれを特定することです。この段階では、発生する可能性があり、通常のイベントの流れを妨げる可能性のあるすべてのリストを作成します。

このステップの主な結果は、リスクのリストです。

このリスクベースのテストステップは、通常、QAリード/マネージャー/代表者が主導します。ただし、リードだけではリスト全体を作成することはできません。QAチーム全体の意見が大きな影響を及ぼします。これは、QAリードが主導する集合的な活動であると言えます。

また、テスト計画フェーズで特定されたリスクは、オリエンテーションにおいてより「管理的」です。つまり、QAプロジェクトのスケジュール、労力、予算、インフラストラクチャの変更などに影響を与える可能性のあるものをすべて調べます。ここでの焦点はAUTではなく、QAフェーズの進行方法です。

テスト計画中のリスク：リスクベースのテスト例

以下は、テスト計画フェーズ中にリストされる可能性のあるリスクのサンプルリストです。ここでは、AUTとその機能に焦点を当てていないことに注意してください。

  1. テストスケジュールは厳しいです。設計作業のためにテストの開始が遅れた場合、UATの予定開始日を超えてテストを延長することはできません。
  2. リソースが不足している、リソースのオンボーディングが遅すぎる（プロセスには約15日かかります）。
  3. 欠陥は、サイクルの後期または後期サイクルで発見されます。遅れて発見された欠陥は、仕様が不明確であることが原因である可能性が高く、解決に時間がかかります。
  4. スコープが定義されていない完全に定義されている
  5. 自然災害
  6. インディペンデントが利用できない テスト環境 とアクセシビリティ
  7. 新しい問題によるテストの遅延

この時点で、利用可能な時間に応じて、必要に応じて徹底することを選択できます。

すべてのリスクがリストされたら、リスク評価/リスク影響分析に進みます。

＃2）リスクアセスメント/リスク影響分析

あなたのリスク分析はこのようなものですか？ :)

リスク管理漫画

ソフトウェアテストにおけるリスク分析 ：このステップでは、すべてのリスクが定量化され、優先順位が付けられます。すべてのリスクの確率（発生の可能性）と影響（このリスクが顕在化したときに発生する損失の量）は体系的に決定されます。

高–中低 、値は、各リスクの確率と影響の両方に割り当てられます。 「高い」確率と「高い」影響のあるリスクが最初に処理され、次に順序が続きます。

リスク影響分析表：

これらの手順に従うと、リストされている上記のリスクのリスク影響分析テーブルは次のようになります（すべての値は架空のものであり、理解を目的としたものです）。

危険確率影響
7.新しい問題によるテストの遅延中高い
1.テストスケジュールは厳しいです。設計作業のためにテストの開始が遅れた場合、UATの予定開始日を超えてテストを延長することはできません。高い高い
2.リソースが不足している、搭乗のリソースが遅すぎる（プロセスには約15日かかります）。中高い
3.欠陥は、サイクルの後期または後期サイクルで発見されます。遅れて発見された欠陥は、仕様が不明確であることが原因である可能性が高く、解決に時間がかかります。中高い
4.スコープが完全に定義されていない中中
5.自然災害低中
6.独立したテスト環境の非可用性とアクセシビリティ中高い

＃3）リスクの軽減

このリスクベーステスト（RBT）プロセスの最後のステップは、これらの状況のそれぞれを処理する方法を計画するためのソリューションを見つけることです。これらの計画は、会社ごと、プロジェクトごと、さらには人ごとに異なる可能性があります。

リスク軽減手法：

このフェーズが完了すると、リスクのテーブルがどのように変換されるかの例を次に示します。

危険確率影響緩和計画
新しい問題によるテストの遅延中高いテスト中に、いくつかの「新しい」欠陥が特定され、解決に時間がかかる問題になる可能性があります。
ドキュメントの仕様が不明確なため、テスト中に発生する可能性のある欠陥があります。これらの欠陥は、解決に時間がかかる問題を引き起こす可能性があります。
これらの問題が目を見張るものになると、プロジェクト全体のスケジュールに大きな影響を与えます。
新しい欠陥が発見された場合は、欠陥管理と問題管理の手順を実行して、すぐに解決策を提供します。
スケジュール
テストスケジュールは厳しいです。設計作業のためにテストの開始が遅れた場合、UATの予定開始日を超えてテストを延長することはできません。
高い高い•テストチームは、準備タスク（事前）と関係者との早期のコミュニケーションを管理できます。
•ベストプラクティスがアドバイスするほどではありませんが、不測の事態に備えていくつかのバッファーがスケジュールに追加されました。
リソース
リソースが不足している、搭乗のリソースが遅すぎる（プロセスには約15日かかります。
中高い休日と休暇は推定され、スケジュールに組み込まれています。見積もりからの逸脱は、テストの遅延につながる可能性があります。
欠陥
欠陥は、サイクルの後期または後期サイクルで発見されます。遅れて発見された欠陥は、仕様が不明確であることが原因である可能性が高く、解決に時間がかかります。
中高い迅速な連絡と問題の修正を確実にするために、欠陥管理計画が実施されています。
範囲
スコープは完全に定義されています
中中スコープは明確に定義されていますが、機能の変更はまだ確定されていないか、変更を続けています。
自然災害低中チームと責任は、2つの異なる地理的領域に分散しています。あるエリアでの壊滅的なイベントでは、他のエリアでテスト活動を継続するために必要なリソースがあります（ペースは遅くなりますが）。
独立したテスト環境の非可用性とアクセシビリティ中高い環境が利用できないため、スケジュールが影響を受け、テスト実行の開始が遅れることになります。

注意すべきいくつかのポイント：

  1. QAプロジェクト計画フェーズでリスク管理を開始するのが早ければ早いほどよいでしょう。
  2. 3つのステップすべてのうち、 リスクの特定が最も重要です 。何かがリストされておらず、さらなるステップが検討されていない場合、リスクは処理されません。
  3. この活動の理想的な時間枠を見つけてください。計画が多すぎると、実行する時間が少なすぎることを忘れないでください。
  4. また、リスク管理プロセスの後、新しい状況が発生した場合、リスク管理計画を変更または更新して、最新の状態を反映させることができます。
  5. 歴史的なデータ このプロセスを成功させるために非常に役立ちます。

結論

これにより、テスト計画フェーズでのリスク管理が終了します。基本的な手順と原則は類似していますが、リスク管理プロセスは、テストの設計/実行フェーズで発生すると、AUTに集中します。

次のセクションでは、以下について説明します– テスト実行フェーズでのリスク管理。

テスト実行フェーズでのリスク管理（例を含む）

リスク管理プロセスを理解するための私たちの旅の中で、私たちはそれが排他的にどのように進むかについて話しました リスクベーステストのテスト計画フェーズ 。また、リスクの特定、リスク評価、およびリスク軽減計画に関連する一般的なプロセスについても理解しました。

テスト設計またはテスト実行フェーズでリスクを管理する方法：

もう1つの形式があります 危機管理 （別名、 リスクベーステスト ）状況に応じて、テスト設計フェーズまたはテスト実行フェーズで発生します。さて、私たちはどのような状況について話しているのですか？まずそれを理解してみましょう。

最高のPCメンテナンスソフトウェアは何ですか

私たちのテスト作業が反応的であることは誰もが知っています。要件（またはスコープが定義されていない）がないため、実現可能性分析を実行したり、テストシナリオを作成したり、テストアクティビティを計画したりすることはできません。

同様に、コードの準備ができていない場合、テストケース、テストデータなどの観点から、準備作業の準備ができていても、テストするものはありません。また、テストは、製品がリリースされる前に残された唯一のステップです。住む。

リスク管理–AUTに焦点を当てて

リスクベーステストパート2

例を挙げて、これをよりよく理解しましょう。

上記の日にテストを開始する場合は、1月1日stそして1月14日まで続けなければなりませんでしたth–テストが完了すると、通常、製品の運用開始日はすぐに修正されます。たとえば、1月15日th簡単にするために。さて、完璧な世界では、物事は計画通りに進みます。しかし、私たちは皆、現実を知っています。

この場合、何らかの理由で、テストが1月7日まで開始されなかったと仮定します。th、つまり、テスト時間の半分が失われました。しかし、製品を徹底的にテストするには14日かかります。稼働開始日をさらに7日移動することもできますが、これは通常オプションではありません。製品は特定の日に市場に出ることが約束されており、遅延はビジネスにとって良くないからです。

したがって、通常、テストチームは遅延を吸収し、何らかの方法で補正し、利用可能な時間で作業し、製品が適切にテストされていることを確認する必要があります。大変な仕事ですね。

ここで、リスク管理プロセスが再び採用されます。

  • さて、 遅延は前もって予想されます テストが始まる前に-プロセスはテスト設計段階で行われます。
  • 場合 遅延は テスト実行フェーズ これは正常に開始されました-プロセスはテスト実行フェーズで追跡されます。
  • 手順と方法は、どの段階で発生しても同じです。

プロセスは何ですか？

リスク管理は、AUT（テスト対象アプリケーション）のどの領域に最大の焦点を当てる必要があるかを判断するために行われます。これらは通常、最終製品の成功に不可欠であり、最も失敗しやすい機能領域（モジュールまたはコンポーネント）です。

また読む=> 故障モードおよび影響分析（FMEA）は、リスク管理手法です。

誰がそれを実行しますか？

AUTに関する知識であるため、QAだけでなく、開発、BA、クライアント、プロジェクト管理チームなどの他のすべてのチームにも知識があります。したがって、テストチームが主導する共同作業です。

リスクベースのテストはどのように行われますか？

ステップ1） リスクの特定

AUTのすべての機能領域を特定します。これには、単にリストの作成が含まれます。

ステップ2） リスクアセスメント

このステップでは、すべてのリスクが定量化され、優先順位が付けられます。定量化とは、リスト内の各リスクに番号を割り当てて、対処する必要のある優先順位を示すことです。

すべてのリスクの確率（発生の可能性）と影響（このリスクが顕在化したときに発生する損失の量）が決定されます。

典型的な方法は、評価を割り当てることです。 例えば、 確率は1から5の値を取ることができます。1は発生の確率が低い（まったく発生しない）、5は高い（最も確実に発生する）です。

同様に、Impactにも1〜5の評価を割り当てることができます。 1は影響が少なく（このリスクが顕在化したとしても、損失は最小です）、5は影響が大きい（発生すると大きな損失が発生します）。

ステップ3）

表形式を作成し、すべてのチーム担当者（開発者、BA、クライアント、PM、QA、およびその他の関係者）に回覧します。

リスクベーステスト1

ステップ4）

各チームに、確率と影響の評価に基づいて値を入力するように指示します。

確率と影響の値は数値であるため、「リスクファクター」値の計算が容易になります。

リスクファクター=確率X影響。危険因子が高いほど、問題は深刻です。

例：

リスクベーステスト2

この時点で、これは単に1つのチームの評価の結果であることに注意してください。 5つの異なるチームが関与するプロジェクトの場合、QAチームは5つの異なるテーブルになります。

ステップ5）

リスクファクター値の平均を取ります。 例えば、 モジュールごとに5つのチームがある場合は、すべてのリスクファクター値を加算し、それを5で割ります。これが処理する最終値です。たとえば、これらは平均化されたリスク要因です。

リスクベーステスト3

リスク要因が多ければ多いほど、そのモジュールをテストする必要があります。

したがって、モジュール5と2は、ビジネスの成功にとって最も重要です。結果をすべてのチームと共有します。

ステップ6）

リスク軽減計画 ：さて、これはプロジェクトからプロジェクトへと変わるステップです。モジュール5と2は、最も集中する必要があるモジュールであることがわかりました。

例計画の可能性があります：

  1. モジュール5と2は、それらに関連するすべてのテストケースがテストされていることを確認することにより、徹底的にテストされます。他のモジュールは探索的にテストされます。
  2. モジュール5と2が最初にテストされ、次に利用可能な時間に応じて、他のモジュールが処理されます。

計画が立てられると、すべてのチームが合意に達し、それに従って製品をテストし、リスク要因を考慮します。

それでおしまい！

注意すべきいくつかの重要なポイント：

  • これは集合的な活動なので みんなの意見を考慮に入れる ;それが正確で効果的である可能性は高くなります。
  • これは 形式手法ではありません また、すべてのQAプロジェクトに参加する必要はありません。
  • チームがテーブルを描画せず、値を割り当てないことを選択した場合でも、 簡単なブレーンストーミングセッション 全員が出席していると、QAチームに進め方について良い方向性を与えることができます。
  • ザ・ 開発チームの意見 彼らは製品を作成する人であるため、非常に重要です。そのため、何が機能し、何が追加のチェックを必要とするかを知ることができます。必ず注意してください。
  • プロセスには複数のステップがありますが、 それらを実行するのにかなりの時間はかかりません 。特に、すべてのチームが一緒に座って同時に作業できる場合。
  • このプロセスとその結果を覚えておいてください 代替のみ 。 QAアクティビティを実行するには、テストの計画にできるだけ多くの時間をかけることが最善の方法です。

結論

リスクベーステストのアプローチは、テスターの焦点が、重大度や優先度に関係なく、欠陥を調査し続けることだけではないことを明確に示しています。今、状況は変化し、テスターは賢く働く必要があり、明確な「顧客のニーズとユーザーの要望」を理解する必要があります。

彼らは製品を徹底的に研究し、生産で最も頻繁に使用される機能、収益を生み出すための最も重要なパス、および生産の問題やビジネスの脅威から顧客を保護および保護する方法を理解する必要があります。

したがって、RBTアプローチは、すべてをテストしたり、広範囲にテストしたりするだけでは、テストが完了したり、製品に欠陥がないことを意味しないことを3人のテスターに​​明確に教育します。規定された時間内に効果的にテストし、重大で主要なビジネスへの影響が無効になっていることを確認します。これはテスターに​​とって非常に重要です。

したがって、リスクベーステストは、QAチームがプロジェクトのリスクに基づいてプロジェクトの利害関係者を導くための最も効率的なツールです。 RBTアプローチは、プロジェクト全体の目標と目的の達成を危険にさらす可能性のあるリスクとその解決策をQAチームが継続的に特定するのに役立ち、QAグループの最終的な目的を達成するのに役立ちます。

P.S. QAとテストという言葉は、ドキュメント全体で同じ意味で使用されています。

著者について： この記事は、複数のSTHチームメンバー（GayathriSubrahmanyamとSwatiS）によって書かれています。

Gayathriは、ソフトウェアテストで20年以上の経験を持つソフトウェアテストSMEであり、いくつかの取り組みでテスト産業化の一環として「リスクベーステスト」アプローチを幅広く採用し、テストリソースの最適化と品質テストのメリットを実現しています。

リスクベーステストはあなたにとって挑戦的なものでしたか？チュートリアルに追加する興味深い事実はありますか？下記のコメント欄にご意見をお聞かせください!!

=> 完全なテスト計画チュートリアルシリーズについては、こちらをご覧ください

推奨読書

^