MENU

JSTQB(ALTM) シラバス学習:2 テストマネジメント(2.1~2.2)

2018.03.03更新 

この章はテストマネージャに必要な知識領域にフォーカスしています。

2.1 イントロダクション

テストマネージャの定義

Advanced Levelでは組織によってテストプロフェッショナルを、テストリーダ、テストマネージャ、およびテストディレクタなど様々に定義することを考慮して、テストマネージャと総称しています。

学習の目的

シラバスから引用します。

「テストマネジメント」の学習の目的

 

2.2 状況に応じたテストマネジメント
TM-2.2.1 (K4)ステークホルダ、状況、およびソフトウェア開発ライフサイクルモデルを含むソフトウェアプロ ジェクトまたはプログラムのニーズを分析し、最適なテスト活動を識別する。
TM-2.2.2 (K2)ソフトウェア開発ライフサイクル活動と成果物がテストに与える影響、およびテストがソフトウェ ア開発ライフサイクル活動と成果物に与える影響を理解する。
TM-2.2.3 (K2)経験ベースのテストおよび非機能テストに関するテストマネジメントの問題を管理する方法を 説明する。

 

2.3 リスクベースドテストとその他のテストの優先度付けと工数配分のアプローチ
TM-2.3.1 (K2)リスクベースドテストでリスクに対応するさまざまな方法を説明する。
TM-2.3.2 (K2)プロダクトリスク分析のためのさまざまな技法を、例を示して説明する。
TM-2.3.3 (K4)プロダクト品質リスクを分析、識別、および評価し、主要なプロジェクトステークホルダの観点 に基づいて、リスクとその評価されたリスクレベルの概要を説明する。
TM-2.3.4 (K2)識別したプロダクト品質リスクを、ライフサイクルとテストプロセス全体を通じて、評価したリス クレベルに応じて、軽減しマネジメントする方法を説明する。
TM-2.3.5 (K2)テストの選択、テストの優先度付け、および工数の割り当てに関するさまざまなオプションの 例を示す。

 

2.4 テストドキュメントとその他の成果物
TM-2.4.1 (K4)提供されたテストポリシーとテスト戦略のサンプルを分析し、これらのドキュメントに対して完 全性と一貫性のあるマスターテスト計画書、レベルテスト計画書、およびテスト成果物を作成する。
TM-2.4.2 (K4)所定のプロジェクトに対して、プロジェクトリスクを分析し、適切なリスクマネジメントオプション (軽減、コンティンジェンシープラン、移転、受け入れなど)を選択する。
TM-2.4.3 (K2)テスト戦略のテスト活動に対する影響を、例を示して説明する。
TM-2.4.4 (K3)適用可能な標準化団体の利用可能なテンプレートを採用して、組織、ライフサイクル、およ びプロジェクトのニーズに合ったテスト成果物のための文書化の規範とテンプレートを定義する。

 

2.5 テストの見積り
TM-2.5.1 (K3)所定のプロジェクトに対して、適用可能なすべての見積り技法を使用して、すべてのテストプロセス活動の見積りを作成する。
TM-2.5.2 (K2)テストの見積りに影響を与える可能性がある要因を理解し、例を示す。

 

2.6 テストメトリクスの定義および使用
TM-2.6.1 (K2)一般的なテスト関連のメトリクスを説明し比較する。 TM-2.6.2 (K2)テスト進捗モニタリングのさまざまな側面を比較する。
TM-2.6.3 (K4)未対応のリスク、欠陥ステータス、テスト実行ステータス、テストカバレッジステータス、および 確信度合いの観点で、テスト結果を分析およびレポートし、プロジェクトステークホルダがリリース を決定するための判断材料となる的確な情報と提案を提供する。

 

2.7 テストのビジネスバリュー
TM-2.7.1 (K2)品質コストを決定する 4 つのカテゴリのそれぞれについて例を示す。
TM-2.7.2 (K3)品質コストをベースに、他の定量的および定性的要素を考慮して、テストの価値を見積り、見積った価値をテストステークホルダに伝える。

 

2.8 分散テスト、アウトソーステスト、およびインソーステスト
TM-2.8.1 (K2)分散テスト、アウトソーステスト、およびインソーステストのチームスタッフ戦略を、適切に使用するために必要な要因を理解する。

 

2.9 業界標準適用のマネジメント
TM-2.9.1 (K2)ソフトウェアテストに関する標準の出典とその用途についてまとめる。

 

引用元:Advanced Level シラバス日本語版 テストマネージャ

 

 

2.2 状況に応じたテストマネジメント

テストマネージャはリソース(要員、ソフトウェア、ハードウェア、インフラなど)を活用して付加価値をもたらすプロセス(テスト)を実行する責任があります。

テストプロセスの付加価値はプロジェクトの成功、または深刻な故障を防ぐことによって付加できるため、テストマネージャは付加価値をもたらすために、テストプロセスを計画してコントロールする必要があります。 

 

2.2.1 テストステークホルダについて

なぜ付加価値をもたらす必要があるのか?誰のための付加価値なのか?

それはステークホルダが関係しています。

テストステークホルダの関心

テストステークホルダは以下の品質に関心を持ち、直接的または間接的に関与します。

  • テスト活動
  • テスト成果物
  • 最終システム
  • 最終成果物

ステークホルダの役割

プロジェクト、プロダクト、組織などの要因によって次のような役割を持ちます。

  • 開発者、開発リーダ、開発マネージャ
  • データベースアーキテクト、システムアーキテクト、設計者
  • マーケティングアナリスト、ビジネスアナリスト
  • 上級管理職、プロダクトマネージャ、プロジェクトスポンサ
  • プロジェクトマネージャ
  • テクニカルサポート、顧客サポート、ヘルプデスク
  • 直接的および間接的なユーザ

テストマネージャの役割

以下の活動によりテストプロセスの有効性および効率性を最適化します。

  • プロジェクトまたはプログラムに関する特定のテストステークホルダを識別する。
  • ステークホルダとテストとの関係の本質、およびテストチームがステークホルダのニーズに応える方法について理解する。
  • テストに影響を与えたり、影響を受けたりするソフトウェア開発ライフサイクル活動、および成果物を識別する(2.2.2節を参照)。

 2.2.2 その他のソフトウェア開発ライフサイクル活動と成果物

ソフトウェアテストはソフトウェア開発ライフサイクル活動の一部です。
テストマネージャは、テスト活動以外の活動とその成果物がテストに与える影響、およびテストがそれらに与える影響を理解して、テスト活動をガイドする必要があります。

テストと関わるライフサイクル活動

テストマネージャはテストプロセスの有効性および効率性を最適化するため、テストステークホルダを識別することに加えて、テストが影響を受ける活動や影響を与える活動、または成果物を識別する必要があります。

密接に関係する項目について関係者とテストマネージャの活動を以下に記載します。

要求エンジニアリング、要求管理
  • 要件の変更に対応してテストをコントロールします。
  • スコープや工数の見積もり時に要件を考慮する必要があります。
  • テクニカルアナリスト、テストアナリストは要件のレビューに参加します。
プロジェクトマネジメント
  • テストアナリスト、テクニカルテストアナリストと協力してスケジュール要件とリソース用件をプロジェクトマネージャに伝えます。
  • プロジェクトマネージャと協力してプロジェクトをコントロールします。
 構成管理、リソース管理、変更管理
  • テストチームと協力してソフトウェアの配布プロセスを確立します。
  • テストアナリスト、テクニカルテストアナリストに対してバージョン管理を徹底させます。
ソフトウェアの開発と保守
  • 開発マネージャと協力して欠陥マネジメントを実施します。
  • テスト結果を受けてリリース内容と日程をコントロールします。
テクニカルサポート
  • テクニカルサポートマネージャと協力して、テスト結果を提供して既知の故障および回避策を共有します。
  • テクニカルサポートマネージャと協力して、運用時の故障を分析してテストプロセスの改善を行います。
技術ドキュメントの作成
  • 技術ドキュメントマネージャと協力して、ドキュメントの提供と欠陥のマネジメントを行います。

2.2.3 テスト活動とその他のライフサイクル活動の連携

テスト活動(テスト計画、テスト分析、テスト設計、テスト実装)は開発モデルの種類に関係なく不可欠で、テストマネージャはライフサイクル活動と連携させ円滑にテスト活動を進めるための調整を行う役割があります。

ソフトウェア開発には以下のような開発モデル(ライフサイクル活動)があります。

開発モデルとテスト活動

ソフトウェア開発モデルの種類

f:id:ntwk:20180215234918p:plain

ライフサイクルモデルとの連携例:Vモデル

f:id:ntwk:20180215234933p:plain

テスト活動の調整

テスト活動とライフサイクル活動を適切に連携させるために、テストマネージャはライフサイクルモデルを正しく理解して、各プロジェクトごとに固有の調整を行う必要があります。組織、プロジェクト、成果物の必要に応じて追加のテストレベルを定義します。

標準のテストレベル
追加のテストレベル
  • ハードウェアーソフトウェア統合テスト
  • システム統合テスト
  • フィーチャ相互作用テスト
  • 顧客プロダクト統合テスト

テストレベルの要素分析

異なるテストレベル間で発生する無駄や漏れを防ぐため、以下の項目を明確に定義する必要があります。

  • テストの目的
  • テストのスコープとテストアイテム
  • テストベース(トレーサビリティ)
  • 開始基準と終了基準
  • テスト成果物
  • テスト技法
  • 測定指標、メトリクス
  • テストツール
  • リソース(テスト環境など)
  • 責任を負う要員、グループ
  • 組織、規制、標準への準拠

2.2.4 非機能テストのマネジメント

非機能テストはISO/IEC 9126(下記参照)の品質モデルに表されるような品質特性を検証するテストを意味します。そして、検証する項目に対して定量的に定めた基準値を満たすことを評価します。
また、非機能テストは費用が高額になる傾向があるため(性能測定を行う計測器など非常に高価です)、テストマネージャはリスクと制約に基づいて適した非機能テストの選択を行う必要があります。

f:id:ntwk:20180220002621p:plain

非機能テストの考慮事項

テストマネージャが考慮事項に対応する専門知識を持っていない場合、非機能テスト活動を実施するテクニカルアナリストあるいはテストアナリストに以下に記載する一般的な考慮事項の責任の一部を委任します。

一般的な考慮事項
  • ステークホルダの要件
  • 必要なツールの使用
  • テスト環境
  • 組織的要因
  • セキュリティ
その他重要な考慮事項
  • ソフトウェア開発ライフサイクルとの統合

欠陥の検出が遅れるリスクを軽減するため、非機能テストをソフトウェア開発ライフサイクルに統合して、リスクに応じた優先度付けを行い、テストの早い段階や開発中に非機能テストを実行します。
開発中の非機能テストは、例えばシステム設計中のプロトタイプの使用性レビューなどです。

  • イテレーティブライフサイクルからの独立

イテレーティブライフサイクルではイテレーションのペースが速いため、単一イテレーションのスケジュールよりもテスト設計及び実装の方が時間がかかる場合には、イテレーションから独立した活動として整理する必要があります。

2.2.5 経験ベースのテストのマネジメント

経験ベースのテスト(特に探索的テスト)は、他のテストで見逃す場合がある欠陥を効率的に検出できるというメリットがありますが、テストマネジメントに関しては課題も存在します。

マネジメント手法

テストセッションによる分割

短い時間でセッションが完了するように、テストセッションを分割して作業を区切ることで、モニタリングとスケジュール管理が改善します。
テストマネージャはテストチャータ(テストの目的を明記したもの)をテスト担当者に伝えることにより、テスト担当者はテストへの集中力が高まり、複数のテスト担当者がいる場合でも重複を防ぐことができます。

テストセッションと自律的なテストの統合

事前に設計したテストセッションに自律的かつ自発的なテストを統合します。
例えば、テスト担当者に自律的にテストを行う時間と権限を与えることができます。
このようなテストセッションで欠陥や今後のテスト対象領域を識別した場合は、テストセッションを更新することがプロジェクトとしてテストの品質を維持していくために重要な作業となります。