ソフトウェアテストにおけるプロジェクトのリスク分析とソリューション
トーマス・ハミルトン
リスク分析とは何ですか？
リスクとは、望ましくないイベントが発生する確率です。
ソフトウェアエンジニアリングにおけるリスク分析は、システムに関連するリスクを分析するプロセスです。 テスト プロジェクト。
プロジェクトを成功させるには、プロジェクトの開始前にリスクを特定し、対応する解決策を決定する必要があります。 ソフトウェア エンジニアリングにおけるリスクの特定は、考えられるリスクを初期段階で特定するのに役立ちます。
このチュートリアルでは、ケーススタディを使用して、テスト管理プロセスの最初のステップであるリスク分析と解決策を学びます。
このトピックでは、テスト管理プロセスの最初のステップであるソフトウェアのテストとソリューションのリスク分析を、ケーススタディを使用して説明します。
テスト対象のアプリケーションは、 https://demo.guru99.com/V4/、ソフトウェア要件仕様を参照できます。 こちら.
Guru99 Bank には XNUMX つの役割があります
- マネージャー
- Customer
以下の機能/モジュールは、これら2つの異なる役割で利用できます。
ウェブサイトのちょっとしたツアーはこちら
要件ドキュメントを読んだ後、Web サイトには多すぎることに気づいたかもしれません。 機能的な 複雑な シナリオ。
状況は次のとおりです –
- Guru99 銀行 Web サイトはすでに開発段階を終了しています。 ここでテストフェーズが始まります。 残念ながら、あなたは要件段階の早い段階で関与していませんでした
- 上司はあなたにテストを終わらせるよう要求しています 一か月 予算は限られていますが、期待しています 素晴らしい 品質。
- 経験豊富なエンジニアであるチームメンバーがこう言います。
- このような場合、どうすればよいでしょうか？
A) 大きな問題のようです。Aに対処する必要があります。SAP!!!
B) 気にしません。 今すぐにでも作業を始めなければなりません。
- プロジェクトはめちゃくちゃで、リソースと時間をすべて費やしました。 従業員の仕事量が大幅に増加し、ストレスと過負荷を感じている
- – プロジェクトが遅れているため、上司に約束した期限までに製品をリリースできませんでした。チームメンバーが言ったように、このプロジェクトのスケジュールは現在のリソース割り当てに比べて厳しすぎます。
上の例は、 重要性 テスト管理におけるリスク分析の説明。
リスク管理は次のことに役立ちます。
上記の例で述べたリスクは、プロジェクトで発生する可能性のある多くの潜在的なリスクの1つにすぎません。リスクを特定し、対処する決定を下す必要があります。SAP!!! したがって、この例の正しい動作は アクションA.
したがって、テストにおけるリスク分析は重要です
リスク分析を実行するにはどうすればよいですか?
3 ステップのプロセスです
- リスクを特定する
- 特定された各リスクの影響を分析する
- 特定・分析されたリスクに対して対策を講じる
ステップ 1) リスクを特定する
ソフトウェア製品におけるリスクは2種類に識別・分類できる
プロジェクトリスク
プロジェクトのリスクは次のように定義できます。 不確かな プロジェクトの進行に影響を与える可能性のあるイベントまたはアクティビティ。 その影響には、 正の or 負 プロジェクトの目標達成の見通しに影響を与える。
プロジェクトリスクには主に3つのカテゴリがあります
組織のリスク
それはあなたに関連するリスクです 人材 またはテストチーム。 たとえば、あなたのプロジェクトでは、技術的に熟練したメンバーが不足しているとリスクになります。 プロジェクトを予定通りに完了するのに十分な人材がいないことも、別のリスクです。
組織のリスクを特定するには、いくつかの質問のリストを作成し、自己演習としてそれらに答える必要があります。 おすすめの質問をいくつか紹介します。
A) はい
B）いいえ
A) はい
B）いいえ
A) はい
B）いいえ
上記の質問すべてに答えると、プロジェクトに影響を与える可能性のある潜在的なリスクを簡単に特定できます。
技術的リスク
技術的リスクとは、テストされていないエンジニアリング、間違ったテスト手順など、技術的プロセスの実行中に発生する損失の可能性です。 技術的リスクの例は次のとおりです
- このプロジェクトのタスクは、銀行 Web サイトをテストすることです。 実際のビジネス環境を反映した適切なテスト環境をセットアップする必要があります。 もし テスト環境 正しくセットアップされていない場合、製品は 正しくテストされ、多くの 欠陥 検出されなくなります。
ビジネスリスク
リスクには次のようなものがあります。 外部 実在物。 それはあなたの会社や顧客からもたらされるかもしれないリスクですが、 あなたのプロジェクトから。
次の図はビジネス リスクの例を示しています。
このような場合、テストマネージャーは次のようなリスクに対処する解決策を見つける必要があります。
- 作成セッションプロセスで 優先順位 テスト段階では、Web サイトの主な機能のテストに重点を置きます。
- 活用する テストの生産性を向上させるテストツール
- 一緒にお仕事をしてみたい方はこちらまで プロセス改善 管理の労力を軽減します。
製品のリスク
製品リスク システムまたはソフトウェアが顧客、ユーザー、または利害関係者の期待を満たさない、または満たさない可能性です。 テスト計画におけるこのリスクは、 機能性 パフォーマンスの問題、セキュリティの問題、クラッシュのシナリオなど、製品の
以下は製品リスクの例です。
- ソフトウェアは一部をスキップします キー お客様がユーザー指定で指定した機能
要件 - ソフトウェアは 信頼できません そして頻繁に 失敗 動作するように。
- ソフトウェアが失敗し、ソフトウェアを使用するユーザーまたは会社に経済的損害またはその他の損害を引き起こす場合。
- ソフトウェアには、セキュリティ、信頼性、使いやすさ、保守性、パフォーマンスなどの特定の品質特性に関連する問題があります。
さて、あなたのプロジェクトに戻りましょう。Guru 99 Bankのウェブサイトには製品リスクがありますか？この質問に答えるには、次の手順に従う必要があります。
上記の 3 つのステップが完了したら、以下の簡単なクイズに答えて製品のリスクを特定してください。
A) はい
B）いいえ
C) よくわかりません
A) はい
B）いいえ
A) 安全な資金送金
B) ユーザーは新しいアカウントを登録できます
C) これ以上の機能は必要ありません
ステップ 2) 発生したリスクの影響を分析する
前のトピックでは、プロジェクトを妨げる可能性のあるリスクをすでに特定しました。 特定されたリスクのリストは次のとおりです。
- 十分ではないかもしれません 人材 期限までにプロジェクトを終わらせる
- テスト 環境 実際のビジネス環境のように適切にセットアップされていない可能性があります。
- あなたのプロジェクト 予算 経営状況により半額になる場合もございます
- このウェブサイトは、 不足 セキュリティ機能
次に、これらのリスクを分析する必要があります。
各リスクは次の2つのパラメータに基づいて分類する必要があります。
- 当学校区の 確率 発生の
- 当学校区の 影響 プロジェクトについて
以下のマトリックスを使用すると、次のことができます。 分類する リスクを XNUMX つのカテゴリーに分類 高、中、 低い値または値 3,2、1、XNUMX
|
確率 |
|
|---|---|
|
高（3） |
非常に高い確率で発生し、プロジェクト全体に影響を与える可能性があります |
|
ミディアム（2） |
発生確率50% |
|
低（1） |
発生確率が低い |
|
影響 |
|
|---|---|
|
高（3） |
解決しないとプロジェクト活動を続行できない 直ちに |
|
ミディアム（2） |
解決しないとプロジェクト活動を継続できない |
|
低（1） |
解決する必要があるが、しばらくの間は代替解決策を講じる可能性がある |
以下のリスクを考慮してください
|
リスク |
確率 |
影響 |
優先度 = 確率* 影響 |
|---|---|---|---|
|
プロジェクトの期限が守られていない |
3 |
3 |
9 |
|
停電 |
1 |
2 |
2 |
上記の優先順位に基づいて、テストのリスク軽減または以下の表に記載されている対抗策を講じることができます。
|
優先 |
リスク管理方法 |
|
|---|---|---|
|
ハイ |
6 -9 |
直ちに軽減措置を講じ、ステータスがクローズされるまでリスクを毎日監視します。 |
|
真ん中 |
3-5 |
社内進捗会議で毎週リスクを監視する |
|
ロー |
1-2 |
リスクを受け入れ、マイルストーンごとにリスクを監視します。 |
演習の時間です。Guru4 Banking プロジェクトでは 99 つのリスクが特定されています。 自分で分類してください
| リスク | ハイ | M | ロー | ステータス |
|
|
|
|
|
正しい。
間違っています。
|
|
|
|
|
|
正しい。
誤答
|
|
|
|
|
正しい。
誤答
|
|
|
|
|
|
|
正しい。
間違っています。
|
ステップ 3) リスクを軽減するための対策を講じる
このアクティビティは 3 つのパートに分かれています
リスク対応
プロジェクトマネージャーはリスクを最小限に抑える戦略を選択する必要があります。プロジェクトマネージャーは、次の4つのリスク対応戦略から選択できます。
先ほど特定した 4 つのリスクに戻り、テストまたはテストでリスクと軽減策を見つける必要があります。 対策 それらを回避または排除するために。
B) テスト 環境 実際のビジネス環境のように適切にセットアップされていない可能性があります
C) あなたのプロジェクト 予算 経営状況により半額になる場合もございます
D) このウェブサイトは、 不足 セキュリティ機能
このリスクは企業の状況により避けられません。 プロジェクトのためにこれ以上の人員リソースを要求することはできません。 このような場合、以下のオプションを選択することでリスクの影響を軽減できます。
- プロジェクトチームに参加する才能と経験豊富なメンバーを選択してください
- メンバーのスキルアップのためのトレーニング コースを作成し、生産性の向上を支援します。
B. テスト環境が実際のビジネス環境のように適切にセットアップされていない可能性がある
このリスクは、次の活動を行うことで回避できます。
- テスト環境を構築するために開発チームに協力を依頼します。
- 環境構築に必要なすべての機器や資材（サーバー、データベース、PCなど）を準備します。
C. ビジネスの状況により、プロジェクトが半分になる可能性があります
このリスクは重大です。 プロジェクト全体の進行が妨げられる可能性があります。 その場合、次のようにする必要があります
- プロジェクトのスコープを再定義し、何がテストされるのか、その場合に何が無視されるのかを特定します。
- プロジェクトの予算に合わせてプロジェクト期間についてお客様と交渉します。
- テスト、テスト仕様書の作成など、プロジェクトの各フェーズの生産性を向上させます…時間を節約できれば、コストも節約できます
D. この Web サイトにはセキュリティ機能が欠けている可能性があります
このリスクはプロジェクト全体には影響せず、回避できる可能性があるため、優先度は中と見なされます。 開発チームにこれらの機能を確認して Web サイトに追加するよう依頼できます。
リスクを登録する
すべてのリスクは記録、文書化され、プロジェクト マネージャー、利害関係者、プロジェクト メンバーによって認識される必要があります。 リスク登録には、プロジェクト チームのメンバー全員が自由にアクセスできる必要があります。
リスクを登録するのに役立つものとしては、次のようなものがあります。 Redmineの, マイター…など
リスクの監視と制御
リスクを継続的に監視して、変更が加えられたかどうかを確認できます。 新たなリスクは、継続的な監視および評価メカニズムを通じて特定できます。
リスク管理を改善するには、以下を参照してください。 リスクマネジメント この記事に含まれるテンプレート
