what is impact analysis software testing
このチュートリアルでは、影響分析とは何か、その利点、実行方法、および影響分析ドキュメントを準備する方法について説明します。
ご存知のように、テクノロジーは社会にプラスとマイナスの両方の影響を及ぼします。単純な変更はすべて、そのシステムに影響を与える可能性があります。非常に小さな変更でも、システムに大きな影響を与える可能性があります。
このチュートリアルでは、影響分析を詳細に理解し、影響分析ドキュメントを準備するためのいくつかの手順についても説明します。
ER(実体関連)図を使用して、この分析の重要性を理解しましょう。
アニメを無料で視聴するアニメのウェブサイト
学習内容:
影響分析の重要性
デパート管理システムのER図を検討してください。 「Item」モジュールの名前を「Product」モジュールに変更して、このデータモデル図を編集します。図01から、「アイテム」モジュールが他の多くのモジュールと関連していることがわかります。したがって、「アイテム」モジュールの名前を変更すると、必然的に他のモジュールに影響します。
図:No.01:デパート管理システム
したがって、そのような変更を行う前に、データモデルと変更の影響について十分に分析する必要があります。関係者がモジュールでコミットしようとしている変更の結果について慎重に考えていない場合、アプリケーション自体の適切な動作に影響を与える可能性があります。これが、影響分析が非常に重要である理由です。
注:この分析では、アプリケーションの予期しない動作とすべての副作用が示されます。
影響分析とは何ですか?
これには、アプリケーションの機能/モジュールに加えられた変更の影響の分析が含まれます。これは、プロジェクト要件、システム設計、コーディング、テストなど、ソフトウェア開発ライフサイクルのほぼすべての段階で実行できます。
- 影響分析ドキュメントを使用してモジュールを分析します。モジュール/製品のあらゆる種類の変更に関連するリスクを見つけます。
- これは、システムに変更を加えるために必要なチームの労力の見積もりに役立ちます。
- また、開発者とテスターがシステムでの効果を体験するためのプロトタイプを実装するのにも役立ちます。
効果的な影響分析を行う方法は?
プロジェクトの分析を実行する際に実行される手順は次のとおりです。
- チームを準備します。
- 高レベルモジュールを検査します。
- 低レベルモジュールを検査します。
- 影響を評価します。
- 否定的な結果を管理します。
ステップ1チームを準備する
アプリケーションのモジュールに変更を加える前に、チームを編成する必要があります。チームメンバーは、アプリケーション内のすべてのモジュールにアクセスでき、提案された変更について完全な知識を持っている必要があります。
一部のチームメンバーは、すべてのモジュールに気付かないでしょう。しかし、影響分析の実施後、すべてのメンバーはシステムの完全な知識を持つことになります。
ステップ2高レベルモジュールの検査
チームメンバーは、最初にアプリケーションの高レベルモジュールを分析します。これは、提案された変更の影響を受ける可能性があります。この時点で、モジュール内の戦略とワークフロールールについての知識が必要です。
ステップ3低レベルモジュールの検査
高レベルのモジュールを検査した後、チームメンバーは低レベルのモジュールを検査し、その変更の影響を特定します。チームメンバーは、各モジュールの変更の影響をリストしたドキュメントを作成できます。彼らはエクセルシートまたはワード文書のいずれかを使用することができます。
ステップ4影響を評価する
チームメンバーによって作成されたドキュメントは、加えられた変更のプラスとマイナスの両方の影響のリストを明らかにします。ドキュメントの助けを借りて、チームメンバーは、変更によって生じる可能性のある利点と、変更によって直面する問題について明確なアイデアを得ることができます。
ステップ5否定的な結果を管理する
今のところ、チームメンバーは変更の長所と短所について正確なアイデアを持っています。その結果、チームメンバーや利害関係者と話し合った後、変更を受け入れるか拒否することができます。
テスターは回帰テストを実行できます。回帰テストは、モジュールの変更の影響によって発生したモジュール間の問題を認識するのに役立ちます。
影響分析方法は開発者にとってどのように役立ちますか?
プロジェクトでは、開発プロセスを開始した後でも、クライアントが提示する要件が変更される場合があります。開発者はいくつかのコーディングを行った可能性があります。その後、要件の変更により、コードを変更する必要があります。そのため、開発者は要件に応じてコードを編集し、変更をコミットします。
開発プロセスには複数の開発者が関与している場合があります。状況によっては、複数の開発者がコードをコミットするため、異なるモジュールでの変更の影響を追跡することが非常に困難です。
開発者「A」は、開発者「B」によって処理される別のモジュールのワークフローを認識していない可能性があります。そのため、開発者がテストを実施した場合でも、一部のモジュールと機能は「未テスト」のままになります。開発者は、共有リソースを適切に追跡する必要もありました。
このような状況では、モジュールに変更を加える前に、ソフトウェア影響分析会議を実施できます。会議後、チームメンバーは影響分析ドキュメントを準備します。最新の変更とすべてのリスクベースの情報を反映する必要があります。
会議の後、開発者はアプリケーション内のすべてのモジュールに気付くでしょう。このような会議では、各チームメンバーの意見が考慮されます。
開発者は、変更を加える前に、アプリケーション/最終製品全体を検討します。開発者によるテストの方が優れています。そのため、開発の最終段階でエラーが発生するリスクが軽減されます。
注:影響分析ドキュメントは最新の状態に保つ必要があります。
影響分析方法はテスターにとってどのように役立ちますか?
開発者とテスターの間のコミュニケーションは非常に重要です。テスターは、要件の変更に関する通知を受け取らず、変更に関する情報なしでテストプロセスを続行する場合があります。これは時間とリソースの浪費です。
影響分析メソッドがないと、アプリケーションの新機能は「テストされない」ままになります。テスターがアプリケーションに追加された新機能を知っている場合は、回帰テストを開始できます。
分析後、テスターは、要件の変更またはシステムに追加された新機能に応じて、テストケースの作成または変更を開始します。
注意: この分析は、テスターがテストに重点を置く領域を決定するのに役立ち、テストケースに優先順位を付けることができます。したがって、テストの効率を向上させることができます 。
影響分析文書を作成する方法は?
影響会議のすべての参加者は、影響分析ドキュメントの作成に貢献します。一般的にはExcelファイルです。 Word文書にすることもできます。
このドキュメントのテンプレートは、マトリックスのようなものです。とてもわかりやすいです。読みやすさが高いです。詳細については、表No.02を参照してください。
影響分析ドキュメントの作成方法を学びましょう。プロジェクトには、多くのモジュール、機能、および機能が含まれる場合があります。
5つの機能を持つ小さなプロジェクトを考えてみましょう。
- ログイン
- プロフィール
- メールボックス
- お気に入りに追加
- ログアウト
以下に示すのは(表No.02)、この特定のプロジェクトの対応する影響分析表です。
ここで、列は変更されたモジュール/機能を表し、マトリックスの行は変更によって影響を受けたモジュール/機能を表します。機能「A」の変更が機能「B」に影響を与える場合、開発者はテーブルにマーク()を付けます。このドキュメントがテスターに渡される前に。
| 特徴 | ログイン | プロフィール | メールボックス | お気に入りに追加 | ログアウト | ||||
|---|---|---|---|---|---|---|---|---|---|
| ............。 | |||||||||
| ログイン | | ||||||||
| プロフィール | | ||||||||
| メールボックス | | ||||||||
| お気に入りに追加 | | ||||||||
| ログアウト | |
表No.02
強い影響を与えるために、REDカラーを使用しました。黄色の色は中程度の影響を示すために使用され、緑の色は弱い影響を示します。詳細については、表No.03を参照してください。
そうすることで、テスターはドキュメント内のさまざまなカラーコードを確認することで、モジュールの変更を簡単に理解できます。このドキュメントは開発者のチェックリストとして機能し、開発者がモジュールと依存関係を見逃していないかどうかを確認できます。
| 色 | 説明 |
|---|---|
| ネット | 影響力が大きい |
| 黄 | 中程度の影響 |
| 緑 | 週の影響 |
表No.03
ログイン機能に変更がある場合、それは主に「ログイン」機能自体に影響を与えます。ログイン機能の変更は、「プロファイル」機能と「ログアウト」機能にわずかに影響を与える可能性があります。これは、影響分析ドキュメントでカラーコードを使用してマークされています。したがって、ドキュメントは表No.04のようになります。
| 特徴 | ログイン | プロフィール | メールボックス | お気に入りに追加 | ログアウト |
|---|---|---|---|---|---|
| ログイン | |||||
| プロフィール | |||||
| メールボックス | |||||
| お気に入りに追加 | |||||
| ログアウト |
表No.04
表No.05に示した影響のレベルを数値で示すことができます。したがって、表No.04は表No.06のように再描画できます。
表No.06では、ログイン機能(影響レベル:03)が最優先されています。プロファイル機能(影響レベル:02)には中程度の優先順位が与えられます。ログアウト機能(影響レベル:01)には最低の優先順位が与えられます。
| 影響力のレベル | 説明 |
|---|---|
| 3.ネットワーク | 強い影響力 |
| 2.黄色 | 中 |
| 1.グリーン | 低 |
表No.05
| 特徴 | ログイン | プロフィール | メールボックス | お気に入りに追加 | ログアウト |
|---|---|---|---|---|---|
| ログイン | 3.ネットワーク | 1.グリーン | 2.黄色 | ||
| プロフィール | |||||
| メールボックス | |||||
| お気に入りに追加 | |||||
| ログアウト |
表No.06
注意:
- 表に示されている数値は、QAチームにとって非常に役立ちます。番号に基づいてテストケースに簡単に優先順位を付けることができます。
- いくつかの大きなプロジェクトは、より多くのレベルの影響力を持つでしょう。以下の表で指定されています。 (参考までに表No.07をご確認ください。)
| 影響力のレベル | 説明 |
|---|---|
| 5 | とても強い |
| 4 | 強い |
| 3 | 中 |
| 二 | 弱い |
| 1 | 非常に弱い |
表No.07
多くの機能とサブ機能を持つプロジェクトの影響分析ドキュメントを準備するにはどうすればよいですか?
20個の機能を備えたプロジェクトを考えてみます。そのプロジェクトのすべてのメイン機能には、それぞれ5個のサブ機能があります。影響分析ドキュメントを表すマトリックスは非常に大きく、維持するのが困難です。対応するテーブルはテーブル番号のようになります。08。
| モジュール | モジュール1 | サブモジュール1 | サブモジュール2 | サブモジュール3 | .......。 | モジュール2 | サブモジュール1 | サブモジュール2 | .............。 |
| モジュール1 | |||||||||
| サブモジュール1 | |||||||||
| サブモジュール2 | |||||||||
| ............。 | |||||||||
| モジュール2 | |||||||||
| サブモジュール1 |
表No.08
Macで.datファイルを開く方法
したがって、この問題を克服するために、影響分析ドキュメントでモジュールとサブモジュールを表すための特別なテーブルを使用できます。表No.09を参照してください。行は主な機能を表し、列は副次的な機能を表します。
| サブモジュール1 | サブモジュール2 | サブモジュール3 | サブモジュール4 | サブモジュール5 | |
|---|---|---|---|---|---|
| モジュール7 | |||||
| モジュール1 | |||||
| モジュール2 | |||||
| モジュール3 | |||||
| モジュール4 | |||||
| モジュール5 |
表No.09
このドキュメントを大規模なプロジェクトに使用することで、開発者はメイン機能の変更によって影響を受けるサブ機能に簡単にマークを付けることができます。このドキュメントの読みやすさは、表No.09。
注:メイン機能の変更により、すべてのサブ機能が影響を受けるわけではありません。
ここで、50のメインモジュールを持つ別のプロジェクトについて考えてみます。プロジェクトには開発者のグループがいます。さまざまな開発者がプロジェクトのさまざまなタスクに取り組んでいます(新機能の追加、バグ修正、リファクタリングなど)。
影響分析ドキュメントを使用して、プロジェクトの変更を表示できます。開発者は、対応する変更に関する情報をテーブルに書き込みます。表No.10および表No.11を参照してください。
| 構成の変更 | 開発者によるコメント | 優先度 | 今後の計画 | |
|---|---|---|---|---|
| モジュール1 | Chromeブラウザ | Chromeブラウザを使用してテストします。 | バグレポート#001 | |
| モジュール2 | ||||
| モジュール3 | ||||
| モジュール4 | ||||
| モジュール5 | ||||
| モジュール6 |
表No.10
| アイテム | 説明 |
|---|---|
| 構成の変更 | プロジェクト内の一部のモジュール/機能の変更は、使用するデバイス/環境によって異なります。開発者は、テスターが変更をよりよく理解できるように、ドキュメントで構成の変更を指定する必要があります。 |
| 開発者によるコメント | これは、テストを実行する際にテスターに必要な最も重要な情報の1つです。 |
| 優先度 | テスターは、ドキュメント内のカラーコードまたは番号を使用して、テストタスクに簡単に優先順位を付けることができます。 |
| 今後の計画 | テスターは、開発者の将来の計画を認識している必要があります。開発者が数週間後にコードを変更することを計画している場合、テスターは機能をテストして時間を無駄にする必要はありません。テスターは、開発者がコーディングプロセスを完了するまで待つことができます。 |
表No.11
テストにおける影響分析の利点
- 正確: このドキュメントは、アプリケーションのモジュール/機能の変更に関する正確なデータを常に提供します。
- テストの効率の向上: このドキュメントはモジュールの変更に関する明確な情報を提供するため、このドキュメントを使用すると、テスターはテストケースをより効率的に計画できます。
- 同期作業: すべてのチームメンバーは、影響分析ドキュメントを更新する責任があります。このドキュメントは最新である必要があります。
- 正確: ドキュメントは読みやすいので、テスターはドキュメントを見ることでアプリケーションの変更について明確に理解できます。
- テスト時間の短縮: テスターは、システム全体のテストとは別に、変更されたモジュールおよびサブモジュールでテストを実行できます。テスターは、テストケースに優先順位を付けて計画することができます。これにより、テスト時間を短縮できます。
- カバレッジの増加: このドキュメントを使用して、テスターは、モジュールの変更によって影響を受けるサブモジュールをチェックしたことを確認します。そうすることで、プロジェクトのテストカバレッジが増加します。
- テスト結果の標準化: 開発者とテスターは、モジュール内のすべての変更を表す共通の影響分析ドキュメントを使用します。
- チームの責任が増加します: チームメンバーは、このドキュメントを最新の状態に保つ必要があります。すべてのチームメンバーは、システムに加えた変更に関する情報を更新する責任があります。
- タスクに早期かつ簡単に優先順位を付けます。 ドキュメントは変更の明確な全体像を提供するため、テスターはそれに応じてテストに優先順位を付けることができます。
- 製品に関する明確な知識: このドキュメントの助けを借りて、開発者とテスターの両方が、システムに存在するすべてのモジュールについてのアイデアを得ることができます。
- 簡単なバグ検出: バグ検出が大幅に改善されました。影響分析ドキュメントは、統合テストに役立ちます。
結論
プロジェクトは、影響分析の有無にかかわらず実行できます。しかし、上記の記事から影響分析ドキュメントの利点を見てきました。このドキュメントの導入により、テスト時間は大幅に短縮されます。テスターは、変更のない機能をテストすることで時間を無駄にする必要はありません。
このドキュメントの導入により、開発者とテスター間のコミュニケーションが大幅に改善され、テストの効率が向上します。テスターは、システム全体をよりよく理解できます。
テストにおける影響分析について明確に理解されていることを願っています。コメントをお気軽に共有してください。
推奨読書
- ソフトウェアテストQAアシスタントジョブ
- ソフトウェアテストコース:どのソフトウェアテスト機関に参加する必要がありますか?
- ソフトウェアテストテクニカルコンテンツライターフリーランサーの仕事
- キャリアとしてのソフトウェアテストの選択
- 分析能力と思考力をテストする-ソフトウェアテストの演習(パート2)
- ソフトウェアテストコースのフィードバックとレビュー
- いくつかの興味深いソフトウェアテストのインタビューの質問
- ソフトウェアテストは感情的なタスクですか?