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