test management tutorial
これは、ソフトウェアテストのテスト管理チュートリアルです。これには、テスト管理フェーズ、ツール、およびテスト管理と組織構造が含まれます。
テスト管理は、すべてのテスト関連のアクティビティ、ドキュメント、およびその他の関連作業を管理するプロセスです。組織構造とは、特定のプロジェクトに取り組んでいるチームまたは従業員の階層を指します。
組織構造がテスト管理に影響を与えると思いますか？
答えが「いいえ」の場合、その理由がわかりますか？はいの場合、それがどのように影響するか見てみましょう。これら2つの関係を見つけるには、これらのトピックを明確に理解してから、テスト管理と組織構造の関係を調査する必要があります。
学習内容：
テスト管理の概要
テスト管理とは、特定のプロジェクトのソフトウェアテストのプロセス全体を管理することを意味します。テスト管理プロセスは、ソフトウェア開発ライフサイクル全体に適用されます。したがって、理想的には、ソフトウェア開発プロセスが開始するとすぐに、テスト管理プロセスも開始する必要があります。
テストマネージャーには次の責任がありました-
- テストマネージャーは、これらの作業成果物の一貫性と品質を確保する必要があります。
- TestAnalystおよびTechnicalTest Analystと協力して、適切なテンプレートを選択およびカスタマイズします。
- テストアナリストおよびテクニカルテストアナリストと協力して、詳細度のレベルなど、これらの製品の基準を確立します。
- 適切な手法を使用して作業成果物を確認します。
テスト管理コンポーネント
テスト管理は、理解を深めるために5つの部分に分かれています。
- テストドキュメント
- テスト推定
- テストメトリクス
- テストの進捗状況の測定
- テストライフサイクルを監視するためのメトリック
＃1）テストドキュメント
以下にリストされているテストドキュメントには3つのタイプがあります。
- テストポリシー
- テスト戦略
- マスターテスト計画
＃1）テストポリシー：
- 組織がテストから得た価値を要約します。
- テストポリシーを定義します。
- テストの有効性を評価する方法について説明します。
- テストプロセスの概要。
- 組織がテストプロセスをどのように改善するかを指定しますか？
＃2）テスト戦略：
- プロジェクトおよび製品のリスクを管理するために使用される一般的なテスト方法について説明します。
- 分析戦略： リスクベーステストのように。
- モデルベースの戦略： テストチームが環境、入力、および条件の実際の状況と受け入れられた状況に基づいてモデルを開発する運用プロファイルのように。
- 方法論的戦略： テストチームが一連のテスト条件、チェックリスト、または一般化された論理テストのコレクションを使用する品質特性。
- プロセスまたは標準に準拠した手法： SCRUM / Agileのような一連のプロセスに従います。
- 反応戦略： 探索的テストのような欠陥ベースの攻撃の使用。
- 協議戦略： テストチームが1人以上の利害関係者の入力に依存して、外部委託互換性テストなどのテスト条件を決定する、ユーザー主導のテストのように。
- また、説明します：
- 統合手順
- テスト仕様テクニック
- テストの独立性
- 必須およびオプションの標準
- テスト環境
- ツール
- ソフトウェア製品の再利用性
- 再テストと回帰。
＃3）マスターテスト計画：
- 実行する必要のあるすべてのテストタスクをカバーしています。
- テストがテスト戦略とポリシーをどのように実装するかについて説明します。
- 何かが説明されていない場合、テスト計画はその理由とその緩和計画を説明する必要があります。
- テスト計画の内容は次のとおりです。
- テストする項目
- テストする品質特性。
- スケジュール
- 実行サイクル
- 欠陥変数
- スコープ内のテスト項目
- 終了基準
- プロジェクトのリスク
- テスト作業の全体的なガバナンス、
- 役割と責任
- 入出力
＃2）テストの見積もり
一般的なポイント：
- 管理活動です
- それは経験に基づいています。
- コスト、リソース、タスク、および人員の具体的で詳細なカタログを提供します。
- 見積もりが作成されたら、正当化とともに経営陣に提出する必要があります。
- 最終的な見積もりは、組織とプロジェクトの目標の可能な限り最良のバランスを表しています。
- 見積もりは、その時点で入手可能な情報に基づいており、作成されました。
- 正確さを保つために、新しい情報や変更された情報を反映するように見積もりを更新する必要があります。
テストの見積もりに影響を与える要因：
- 必要な品質レベル
- システムのサイズ
- 歴史的なデータ
- 戦略、開発、ライフサイクルなどのプロセス要因
- テスト環境、自動化、ツール、データなどの重要な要素
- 人の要因
- プロセスの複雑さ
- トレーニングとKT（知識移転）
- 新しいツールとテクノロジー、プロセス、または技術の同化と開発。
- 詳細なテスト仕様の高度な要件。
- コンポーネント到着のタイミング
- テストデータ。
推測：
- 作業分解図
- チーム見積もりセッション
- テスター–開発者比率
- 組織の歴史
- ファンクションポイント分析、LOC。
テスト推定については、チュートリアルの後半で詳しく説明します。
＃3）テストメトリクス
- 何が測定され、完了したと見なされますか？
- 測定しないものは、無視されやすいですか？
- 有用なメトリックの限定されたセットを定義する必要があります。
- 解釈が全員によって合意されたメトリックのみを定義する必要があります。
- メトリックのレポートとマージは自動化する必要があります。
- Managerは、メトリックで情報を検証する必要があります。
プロジェクトメトリック： 合格率、不合格率など。
製品メトリック：
- 製品の属性
- 欠陥密度
プロセスメトリック： 欠陥の％などのテスト能力を測定します。
人： 個人の能力。
テスト進捗メトリック：
- 計画済みと実行済みのテスト条件/ケースの数。
- 重大度、優先度、現在の状態、および影響サブシステムによって分類された欠陥全体。
- 必要な変更、承認された変更、ビルドされた変更、およびテストされた変更の数。
- 計画コストと実際のコスト。
- 計画期間と実際の期間
- 計画されたテストと実際のテストのマイルストーン。
- 製品品質リスクステータス
- テストの労力、コスト、または時間の損失率。
＃4）テストの進捗状況の測定
製品のリスク：
- カバーされるリスクの％。
- テスト失敗のリスクの％
- ％個人によって特定されたリスク。
欠陥：
- 見つかった欠陥の数と提出された欠陥の数。
- 平均故障間隔の到着率
- 特定のテスト項目の欠陥。
- RCAの検出（根本原因分析）
- 欠陥はテストリリースです。
- 同相の欠陥
- 優先度と重大度
- レポートの拒否と重複
- 解決に時間がかかる
- 古い欠陥の修正により導入された新しい欠陥の数。
テスト：
- テスト合格、不合格、ランナー、ブロックの総数
- 回帰テストケースの総数。
カバレッジ：
- 要件と設計範囲
- リスクカバレッジ
- 環境構成カバレッジ
- コードカバレッジ
＃5）テストライフサイクルを監視するためのメトリック
テスト計画の監視
- リスクと要件の数
- 欠陥の発見
- 計画と実際の取り組み。
テスト設計の監視
- 設計中に見つかった欠陥の数。
テスト分析の監視
- 条件の数
- 分析における欠陥の数
テストの実装を監視する
- 環境構成の％
- 自動化されたテストケースの％。
実行の監視
- 合格、不合格、実行なし、ブロックされたテストケースの割合
- 対象となるテストケースの割合
- 計画された欠陥と実際の欠陥が解決されました
- プランと実際のカバレッジの割合
閉鎖の監視
- テストケースの％は合格、すべて
- 再利用可能なカテゴリにチェックインされたテストケースの割合
- 自動化されたテストケースの割合。
- 解決済み/未解決の欠陥の数。
- テスト作業成果物の％
以下で説明するテストの監視および制御フェーズでは、このトピックについてさらに説明します。
テスト管理フェーズ
テスト管理プロセスでは、次の点を考慮する必要があります。つまり、テスト管理プロセスのさまざまなフェーズは次のとおりです。
- リスク分析
- テスト推定
- テスト計画
- テスト組織
- テストの監視と制御
- 問題管理
- 試験報告書
最初の4つのフェーズは計画に関するものであり、残りの3つのフェーズは実行に関するものであることがわかります。したがって、完全なテスト管理プロセスを2つの部分、つまり計画と実行に分割できます。
さまざまなテスト管理フェーズについて詳しく見ていきましょう。
＃1）リスク分析
このフェーズには、リスク要因と考えられる解決策を見つけることが含まれます。リスク分析を徹底的に行えば、将来の失敗を回避できるか、少なくとも何らかの解決策が利用できる可能性があります。
リスクは起こるかもしれないし起こらないかもしれない何かです。しかし、それが起こった場合、その影響はどうなるでしょうか？ソフトウェアの品質や会社の評判などに悪影響を与える可能性があります。
この悪影響を回避するには、リスク要因を見つける必要があります。リスク要因を見つけるためにリスク分析を行う必要があります。リスクには、プロジェクトリスクと製品リスクの2種類があります。プロジェクトリスクは作業プロセスに関連するリスクであり、製品リスクは開発された製品に関連するリスクです。
＃2）テストの見積もり
テストの見積もりは、各テストアクティビティ/フェーズに必要な時間の予測に関するものです。これは見積もりであるため、正確ではありません。より良いテスト見積もりのために、私たちは当社の過去のプロジェクトを研究するか、その作業またはテストフェーズを担当する予定のチームメンバーと相談することができます。
＃3）テスト計画
テスト計画自体は長いプロセスです。これには、テストの目的、テストの範囲、テスト戦略、タイムスケジューリング、リソース、コミュニケーションアプローチなどの定義が含まれます。テストの目的と範囲を定義するための要件は非常に明確である必要があります。テスト計画は、テスター、ユーザー、およびプロジェクトチームメンバーを対象としています。
テスト計画では、プロジェクトでのテストの役割について説明します。テスト計画には、役割と責任、テストされる予定の機能とテストされない機能のリスト、テスト環境、ツールのリスト、および前提条件（ある場合）も含まれます。
＃4）テスト組織
テスト計画フェーズでは、テストに関して考えられるすべてのことを計画しました。
したがって、この計画を実行したり、計画を成功させるには、熟練したチームメンバーが必要です。テスト組織とは、プロジェクトを成功させるための完璧なテストチームを構築することです。
＃5）テストの監視と制御
テスト作業の進行中、またはテスターがテスト計画を実行している間、これらすべての作業の進行状況を監視する必要があります。このすべてのテスト作業を追跡する必要があります。テストの監視が行われると、テストチームとテストマネージャーはテストの進捗状況に関するフィードバックを受け取りますか？
このフィードバックを使用して、テストマネージャーはチームメンバーをガイドして、さらなるテスト作業の品質を向上させることができます。テストモニタリングの助けを借りて、プロジェクトチームはテスト結果の可視性を取得します。また、テストカバレッジについて知るのにも役立ちます。
大規模なプロジェクトの場合、データの収集が容易になるため、テストの監視は自動化されたツールを使用して行われます。小規模なプロジェクトの場合、1人がテストの進行に関連するすべてのデータまたはドキュメントを収集します。テストの進捗情報を収集するには、IEEE829テストログテンプレートを利用できます。これはすべてテストモニタリングに関するものでした。
テストコントロールとは何かを見てみましょう。プロジェクトの作業は、必ずしも計画どおりに進むとは限りません。計画と実際の作業には多少の違いがあるかもしれません。これらの違いを最小限に抑える、または取り除くには、いくつかの変更を行う必要があります。これが、テスト作業を制御する方法です。
＃6）問題管理
問題は、ソフトウェアの開発およびテストプロセス中に発生する問題である可能性があります。それが、私たちが高品質の製品を開発/提供できない最小の理由である可能性があります。一部の問題は目立たないものです。つまり、その問題を解決しないと、それ以上のプロセスを進めることができません。
問題管理とは、これらの問題/問題をどのように処理するかということです。インシデント管理とも呼ばれます。問題管理には、問題を解決するプロセスのより良い計画が必要です。より良い問題管理は、テストマネージャーのスキルと経験に依存します。
これらの問題はどのように発生しますか？
問題が発生する理由はいくつか考えられます。いくつかの問題は戦略に関連しており、いくつかは定義、人事、スケジューリングなどに関連しています。
戦略の問題 ：
例：
- プロジェクトは資金が不足しています。
- プロジェクトのコミュニケーションが不十分。
- プロジェクト管理プロセスは、定められた基準に従っていません。
定義の問題 ：要件に関連する問題。
例： 不明確な要件。要件が不明確なため、多くの問題が発生する可能性があります。
スケジューリングの問題： これは最も一般的なタイプの問題です。従業員は締め切りに間に合わせるのに苦労しなければなりません。
人事問題：
Windows用の最高のタスク管理ソフトウェア
例：
- チームのスキルが不足しています。
- 仕事のための間違った従業員マッピング。
より多くの種類の問題が存在する可能性があり、ここでそれらすべてに言及することはできません。したがって、問題管理とは、問題のログ記録、追跡、および解決に関するものです。
＃7）テストレポート
テストレポートは、テストカバレッジ、開発された製品の品質、および必要なプロセスの改善を特定するのに役立ちます。 「どのくらいのテストが必要か」を決めることができます。
十分なテストが行われたら、このテストレポートを利害関係者またはクライアントに提出できます。また、製品の品質を知り、製品に対してどの程度のテストが実行されているかを把握できるようにします。
テスト管理ツール
ソフトウェア開発プロセスを進めるにつれて、テスト管理は複雑になります。これが、今日非常に多くのテスト管理ツールが利用できる主な理由の1つです。
これらのツールは、テスト管理プロセスの最後の4つのフェーズ（テスト組織、テストの監視と制御、問題の管理、およびテストレポート）に役立ちます。これらのツールはテスト管理の重要なフェーズに役立つため、プロジェクトの最初に検討する必要があります。
以下に、最も人気のあるテスト管理ツールを示します。
- qTest
- PractiTest
- ゼファー
- コラボのテスト
- JIRAのTestFLO
- XQual
- X線–最先端のテスト管理
- TestRail
- QACカバレッジ
- Jira（RTM）の要件とテスト管理
- InflectraによるSPIRATEST
- クアリティー
- アクア
- テストパッド
- JunoOne
=> TOPテスト管理ツールの詳細なレビューについては、ここをクリックしてください
組織構造
さまざまな組織構造を見てみましょう。
組織構造には特定のルールがある場合もあれば、理想的な構造がある場合もありますが、それとは関係なく、すべての組織がその構造を持つことができます。非常に多くの組織構造があり、それぞれに長所と短所があります。
ここでは、それらのいくつかについて説明します。
まず、小さなプロジェクトに使用される最も単純な組織構造を見ていきます。
この構造では、テスターとプログラマーの両方が開発マネージャーに報告しています。
- 開発マネージャーは、プロジェクトの活動を適切に管理できます。
- テストチームと開発チームの間のコミュニケーションギャップの可能性は少なくなります。
- また、ミーティングでは、開発マネージャーがテストと開発作業について完全な知識を持っているため、開発マネージャーの期限を決定するのに役立ちます。
- レイヤーが最小限であるため、チームワークが効率的になります。
この構造の欠点は次のとおりです。
- テストマネージャーがいないため、プロジェクトの後半でテストが検討される可能性があります。
- テストがプロジェクトにとって重要性を失う可能性もあります。プロジェクトの後半と見なすことができます。
一般に、小規模なプロジェクトの小規模な組織では、開発チームが前述の時間よりも時間がかかり、テストチームが苦しむ必要があります。つまり、テストチームは期限までに製品をテストする必要があるため、テストチームはテストにかかる時間を短縮できます。製品。
この構造では、プロジェクトを正常に完了するために、開発マネージャーは、プロジェクトを完了するだけでなく、高品質のソフトウェアを開発することを目的としていることを念頭に置く必要があります。
2番目に一般的に使用される組織構造：
これは、最も一般的なタイプの組織構造です。この構造では、テスターはテストマネージャーに報告し、開発者は開発マネージャーに報告します。テストマネージャーと開発マネージャーの両方がプロジェクトマネージャーに報告しています。
テストマネージャーは、すべてのテスト関連のアクティビティを担当し、ソフトウェアを開発するのは開発マネージャーの責任です。プロジェクトマネージャーは、テストと開発の両方のアクティビティを管理します。
利点：
- 以前の構造とは異なり、この構造では、テストと開発のための異なるマネージャーが存在するため、どちらも自分の作業に集中できます。彼らは彼らの仕事に専念し続け、彼らの気を散らすものは少なくなります。
- この構造では、テストアクティビティを無視したり、プロジェクトの後半で検討したりすることはできません。これは、テストと開発の両方が等しく重要になることを意味します。
- 重要な決定を行うことになると、有利なことに、テストチームは独立しています。
短所：
- 複数のレベルがあるため、通信ギャップが発生する可能性があります。
テスト管理と組織構造
組織構造は、テスト管理に直接影響します。組織構造が異なれば、テスト管理への影響も異なります。したがって、テスト管理は、テストマネージャーのスキルと経験、および組織構造におけるテストマネージャーの位置によって異なります。
ここでは、2つの組織構造を見てきました。最初の構造では、開発マネージャーとテストマネージャーが同じ人物であるため、テスト管理に影響します。開発マネージャーはソフトウェアを開発することを目的としており、その間、テスト作業も検討する必要があります。
したがって、時々彼/彼女は偏った意見を与えるかもしれません。彼/彼女は問題を見逃して先に進むかもしれません。このように、テスト管理に影響を与える可能性があります。独立したテストマネージャーはより多くの正義を提供することができ、テスト管理は独立したテストマネージャーでより良くなります。
結論
テスト管理と組織構造の両方のトピックを別々に、そしてこれら2つの関係とともに見てきました。組織構造がテスト管理に影響を与えると結論付けることができます。
上記の両方の構造を比較すると、2番目の構造では、テスト管理が最初の構造よりも適切に処理されます。この背後にある理由は、専任のテストマネージャーである可能性があります。
組織構造は組織ごとに異なります。テスト管理にはいくつかの定義されたプロセスがありますが（またはチームがテスト管理ツールを使用している場合もあります）、組織構造、テストマネージャー、テストマネージャーのスキルと経験が異なるため、テスト管理は異なります。