JSTQB テストマネージャ ~ 第1章 テストプロセス ~
◣ はじめに
現在、JSTQB Adcanced Level テストマネージャを取得するために、シラバスをベースに学習をしております。本記事では、JSTQB Advanced Level テストマネージャ (Version 2012.J03)について、学習した内容と自分の解釈・気づきをまとめました。
(シラバスのリンク : http://jstqb.jp/syllabus.html#syllabus_advanced)
同じく、テストマネージャを目指している方や、テストのマネジメントを実業務で実施している方に読んでいただいて気づきを与えられたらと思っております。
※この記事の内容は個人的な解釈が含まれているので、ご参考程度に活用いただければと思います。また、本記事公開時点で私はTM勉強中・未受験・未取得状態なので、"改めて"、ご参考程度に活用いただければと思います。)
◣ 今回の内容：第1章 テストプロセス
第 1 章：テストプロセス
テストマネージャの主要な活動は、基本的なテストプロセス内の各ステップでカバーする。テスト計画、テストモニタリングおよびテストコントロールのタスクに重点を置く。さらに、テストマネージャはプロジェクトを過去に遡ってレビューする方法に加えて、プロセスの検証および改善部分の検出の方法を学ぶ。
(引用: テスト技術者資格制度Advanced Level シラバス 日本語版概要 Version 2012.J01)
→ テストマネージャの主要な活動として、以下を学習しました。本記事では、知識レベルK2,K3,K4に対してポイントになりそうな部分をまとめております。
・基本的なテストプロセスの各ステップでの役割・考え方
・特に、テスト計画、テストモニタリングおよびテストコントロールでの役割・考え方
・プロジェクトを過去に遡ってレビューする方法に加えて、プロセスの検証および改善部分の検出の方法
◣ 1.2 テストの計画作業、モニタリング、およびコントロール
知識レベル
TM-1.2.1 （K4）システムのテストニーズを分析して、テスト目的を達成するテスト活動およびテスト成果物を計画する。
◣ TMとしてのポイント (1.2.1 テスト計画作業より参照)
・テスト計画で以下を実施する。
- テスト戦略で特定されたテストの使命や目的を達成するために必要なテストの活動、リソースの特定を行うこと。
- 収集するメトリクスの決定と収集・追跡方法の特定を行うこと。
- ツール選択、トレーニングのスケジュール、文書化ガイドライン作成。
・テスト戦略に応じてテスト活動を決定する。
- テスト戦略「リスクベースドテスト戦略」の場合、リスク分析を実施し得られたプロダクトリスクやコンティンジェンシープランを考慮したテストプロセスを決定する。ex.) リスク分析によりセキュリティのリスクが高いことが判明した場合、セキュリティテストの工数を多めに計画する。
- テスト戦略「対処的戦略」の場合、使用するテスト技法として探索的テストを設定し、テストチャーターやツールを作成する計画を立てる。
・成果物のトレーサビリティ確保の手段を計画する。
・スコープ内/外のフィーチャを識別する。
・初期のテスト環境仕様の定義、必要なリソースの可用性検証、作業割り当てと状況確認を行う。
・外部とのすべての依存関係を識別する (必要に応じて連絡を取る)。
◣ TMとしてのポイント (1.2.2 テストのモニタリングとコントロールより参照)
・テストのモニタリングとコントロールを実施するために、テストの計画と戦略目的に関連付けるための、詳細な測定と対象を決定する。
・テスト条件およびテスト条件のグループに基づいて、テスト成果物とテスト活動を定義し進捗を測定する手段を定義する。
◣ 1.3 テスト分析
知識レベル
TM-1.3.1 （K3）トレーサビリティを確保し、テスト目的、テスト戦略、およびテスト計画に基づいて定義されたテスト条件の完全性と一貫性をチェックする。
◣ TMとしてのポイント (1.3 テスト分析より参照)
・テスト条件は、テストベース、テスト目的、およびプロダクトリスクを分析することで識別可能である。
・テスト条件は、(テストのモニタリングとコントロールで登場する)詳細な測定と対象と見なすこともできる。そのため以下注意すること。
- テスト条件は、テスト目的やテスト戦略などにまで遡ることができる必要がある。
- テスト条件は、以降のテストウェアを追跡できる必要がある。
知識レベル
TM-1.3.2 （K2）テスト条件を指定する詳細度に影響を与える可能性がある要因および、詳細にテスト条件を指定することの長所と短所について説明する。
・テスト条件の詳細度は、どれだけ詳細な条件でテスト条件を識別したか。
- ex.) eコマースアプリ用のテスト条件について
詳細でないテスト条件「チェックアウトのテスト」に対して、(支払方法に注目しテスト条件を詳細化した場合) 詳細なテスト条件 「キャッシュ払い時のチェックアウトのテスト」,「カード払い時のチェックアウトのテスト」などが識別される。
・テスト条件の詳細度に影響を与える要因として以下を考慮する。
- テストレベル
- テストベースの詳細度と品質
- システムまたはソフトウェアの複雑性
- プロジェクトリスクとプロダクトリスク
- テストベース、テスト内容、およびテスト方法間の関係
- 使用するソフトウェア開発ライフサイクル
- 使用するテストマネジメントツール
テスト設計およびその他のテスト成果物に関する、詳細度、および文書化のレベル
- テストアナリストのスキルと知識
- テストプロセスおよび組織自体の成熟度（成熟度が高いほど、高い詳細度合いが必要となることもあれば、低い詳細度合いが可能になることもあることに注意）ば、低い詳細度合いが可能になることもあることに注意）
- コンサルテーションのために他のプロジェクトステークホルダを利用できる可能性
・詳細なテスト条件のメリットは次の通りである。
- テスト条件以降のテストウェアをテストベースやテスト目的と関連付けしやすくなる。これにより、テストのモニタリングとコントロールが適切に詳細に行える。
- (上位テストレベルにて) テストベース確立後すぐに、詳細なテスト条件を開発することで、欠陥の防止(早期検出)に貢献できる。
- ステークホルダがテスト条件やそれ以外のテストウェアを理解しやすくなる。
- ほかのテスト活動と開発活動によい影響(フィードバック)を与えるのに役立つ。
- テスト設計、実装、実行において、詳細な測定と対象をより効率よく網羅することにつながる。
- より明確な水平トレーサビリティのためのベースとなる。
・詳細なテスト条件のデメリットは次の通りである。
- 開発に時間がかかる
- 保守性を維持するのが困難
- チーム内で形式化のレベルを定義する必要がある
・詳細なテスト条件の使いどころ (何をテストするのか明確でないとき)は次の通りである。
- 現状、チェックリストなどの簡易なテスト設計文書化方式を使用している場合。(→ 詳細なテスト条件により、テストの網羅性向上やステークホルダへの説明が容易となるなど効果がありそう。)
- 開発成果物がテストベースとして使用できない場合。(→ 詳細なテスト条件により、開発成果物へのフィードバックに繋がりそう。また、テストケースの根拠を示すことができそう。)
- プロジェクトが大規模、複雑、高リスクであり、テストのモニタリングとコントロールを必要とする場合。(→ 詳細なテスト条件に基づいて適切に正確に進捗の測定を行うことができそう。)
・詳細でないテスト条件の使いどころ (何をテストするのか明確な時)は次の通りである。
- コンポーネントレベルのテスト (→ テストベース(詳細設計書)がテスト成果物に直接関連付けできるため、詳細でないテスト条件で問題なさそう。)
- テスト内容とテスト方法の間に単純な階層構造が存在する、複雑性の低いプロジェクト (→ 詳細なテスト条件を介さなくても、テスト条件以降のテストウェアを開発できそう。)
- テストを定義するためにユースケースを活用できる受け入れテスト (→ 詳細なテスト条件の代わりに、ユースケース自体を以降のテストウェアの導出根拠とできそう。)
◣ 1.4 テスト設計
知識レベル
TM-1.4.1 （K3）トレーサビリティを使用し、定義されたテスト条件に基づいて設計されたテストケースの完全性と一貫性をチェックする。
◣ TMとしてのポイント (1.4 テスト設計より参照)
・テストケースは、テスト戦略およびテスト計画で識別したテスト技法を使用して、テスト条件またはテストベースを段階的かつ詳細に作成する。
・テストのモニタリングとコントロール、トレーサビリティ確保のために、テストケースはテストベースやテスト目的に(直接orテスト条件を介して)関連付ける場合がある。
・テスト設計は、テストレベルに応じて位置づけが異なる。
- 上位テストレベルでは、「テスト分析」「テスト設計」と独立し連続した活動とすることが多い。( → テスト分析で詳細なテスト条件を出す必要があり、それぞれボリュームがあるため、分析と設計の活動を分ける必要があると考えます。)
- 下位テストレベルでは、「テスト分析・設計」と統合された活動することが多い。(テスト分析で詳細なテスト条件を出す必要があまりなく(テストベースからテストケースを直接導出しやすい)ため、統合しても問題ないと考えます。)
・反復的アプローチでテストを作成する場合、テスト実装のタスク(テストデータ作成など)をテスト設計に統合する場合がある。
- テスト計画の段階で、開発プロセスに応じたテスト活動のプロセスへの割り当ての検討が必要となりそう。
◣ 1.5 テスト実装
知識レベル
TM-1.5.1 （K3）リスク、優先順位付け、テスト環境とデータ依存性、および制約を使用して、テスト目的、テスト戦略、およびテスト計画に対して完全性と一貫性のあるテスト実行スケジュールを作成する。
◣ TMとしてのポイント (1.5 テスト実装より参照)
・テスト実装では以下の活動を含む。
- 具体的なテストケース、テスト手順、テストデータを実装する。
- テスト実行を開始する準備ができているか最終チェックをする。
- テストケースの記述とレビューが完了していることを確認する。
- リスクや優先度、制約を考慮して、手動テストおよび自動テストの実行順序をテスト実行スケジュールに含める。
・テスト実装の作業の詳細度と複雑性は、テスト条件やテストケースの詳細度に影響される。
- テスト条件やテストケースが詳細であれば、テスト手順はあまり詳細な説明が不要である。反対に、テスト条件やテストケースが詳細でないならば、テスト手順は詳細である必要がある。
- 特に回帰テスト(長期的に再利用され、テスト担当者によらず信頼性を確保する必要がある場合)では、テスト手順は詳細な説明とする必要がある。
・早期テスト実装にはメリット・デメリットがある。
- メリットは、テスト実装によりソフトウェアの正しい動作状態の稼働例を開発工程に提供可能となる。(テスト7原則: 早期テストに関連する。)
- デメリットは、開発工程の変更が発生した場合にスクリプトやテスト手順が陳腐化する。あるいは保守が必要となる可能性がある。
- テスト計画の段階で、上記メリット・デメリットを考慮したテスト活動の決定が必要となりそう。
◣ 1.6 テスト実行
知識レベル
TM-1.6.1 （K3）トレーサビリティを使用し、テスト目的、テスト戦略、およびテスト計画との完全性と一貫性という観点で、テスト進捗をモニタリングする。
◣ TMとしてのポイント (1.6 テスト実行より参照)
・テストはテスト実行前に設計・定義されている必要がある。
・テスト実行を効率的に進めるために以下を事前に準備する必要がある。
- テストマネジメント、欠陥追跡、テスト実行自動化のツールを用意。
- メトリクス(テスト結果、欠陥情報)の追跡手段と共有先を明確にする。
- テスト計画の段階で、上記を定義する必要がありそう。
・テスト実行には、テスト担当者の自由裁量も与え、ある程度の時間を経験ベースや欠陥ベースの技法を使用したテストセッションのために確保する。
- このような記述されていないテストの内容についても、故障再現のために、差異を記録するべきである。
- テスト計画の段階で、上記を考慮する必要がありそう。
・テスト計画に対する進捗をモニタリングし、必要に応じてコントロール活動を行う。そのために、テスト結果、テスト条件、テストベース、テスト目的の間の双方向のトレーサビリティを確保し使用する。
◣ 1.7 終了基準の評価とレポート
知識レベル
TM-1.7.1 （K2）終了基準に対する正確なレポート作成と評価を支援するために、テストプロセスにおける正確でタイムリーな情報収集が重要であることを説明する。
◣ TMとしてのポイント (1.7 終了基準の評価とレポートより参照)
・終了基準とレポートを評価するために必要な情報を提供するプロセスを実装する必要がある。(テスト計画、モニタリングとコントロールの一環)
・提供する情報は、レポート毎に以下を考慮する必要がある。
- 必要なメンバに対して提供すること
- 必要十分な情報であること
- 正確であること
- タイムリーであること
◣ 1.8 テスト終了作業
知識レベル
TM-1.8.1 （K2）テスト終了作業における4つのグループの作業を要約する。
◣ TMとしてのポイント (1.8 テスト終了作業より参照)
・テスト終了作業として以下が必要である。
1. テスト完了チェック
- 計画したテストが実行済みであることの確認
- 判明した欠陥は修正され確認テスト済みもしくは対応が明確化されていることの確認
- 終了基準を満たしていることを確認する(シラバスには書いてないけど)
2. テスト成果物の提供
- 必要なステークホルダへ、必要な情報を提供する。
- 将来のテストのために、テストウェアなどを保守チームへ提供する。
3. テスト活動の振り返り(学習した教訓)
- テストプロジェクトまたはプロジェクト全体で振り返りミーティングを開催する
- 重要な点(優れていた点、過ち)を整理、文書化する。
- 解決できない問題に対して計画を立てられるようにする。
4. テストウェアの保管
- テストウェア(結果、ログ、レポート、その他ドキュメント)を構成管理システムで補完する。
- テストウェアと対象システム、バージョンの対応が明確となるように関連図ける。
・テスト計画の段階で、上記4つの作業を明示的に盛り込む必要がある。
TM-1.8.2 （K3）プロジェクトの振り返りを実行して、プロセスを評価し、改善する領域を発見する。 プロジェクトの振り返を実行して、プロセスを評価し、改善する領域を発見する。
◣ TMとしてのポイント (1.8 テスト終了作業より参照)
・テスト終了作業「3. テスト活動の振り返り(学習した教訓)」として以下が必要である。
a. 品質リスクの分析セッションにおいて、必要十分な関係部門を招集できたか振り返る。
- ex.) 予期しなかった欠陥の偏在を確認することで、不足していた関係部門を明らかにする。
b. 見積もりの正確さを振り返る。
- ex.) 見積りと実績に乖離があった場合に、テスト自体が非効率的であったのか？、見積もりが低すぎたのか？など原因を明らかにする。
c. 欠陥の原因分析および影響分析の傾向と結果を評価する。
- ex.) 遅い段階で発生する変更要求が分析や品質に与えた影響を評価する。
- ex.) テストレベルを適切に設定できているか？実施できているか？など慣習の見直しを行う。
d. プロセス改善の余地がないか検討する。
e. 今後の計画で考慮すべき、予期しなかった計画との差異がなかったか振り返る。
・振り返りの結果をもとに、次のプロジェクトやテスト活動の計画へ反映させる。
◣最後に
今回はテストマネージャの主要な活動として、以下をまとめました。
・基本的なテストプロセスの各ステップでの役割・考え方
☑ テスト分析、テスト設計、テスト実装、テスト実行では、トレーサビリティを使用し、テスト目的、テスト戦略、およびテスト計画との完全性と一貫性という観点で、テスト進捗をモニタリングする。
☑ テスト終了基準の評価とテストレポートでは、必要なメンバに対し、正確で必要十分な情報をタイムリーに提供する。
☑ テスト終了作業では、次の4つの活動を実施する。1. テスト完了チェック、2. テスト成果物の提供、3. テスト活動の振り返り(学習した教訓)、4. テストウェアの保管
・特に、テスト計画、テストモニタリングおよびテストコントロールでの役割・考え方
☑テスト計画では、以下を実施する。
- テスト戦略で特定されたテストの使命や目的を達成するために必要なテストの活動、リソースの特定を実施する。
- 収集するメトリクスの決定と収集・追跡方法の特定を行うこと。
- ツール選択、トレーニングのスケジュール、文書化ガイドライン作成。
☑ テスト戦略に応じてテスト活動を決定する。
☑ 成果物のトレーサビリティ確保の手段を計画する。
☑ スコープ内/外のフィーチャを識別する。
☑ 初期のテスト環境仕様の定義、必要なリソースの可用性検証、作業割り当てと状況確認を行う。
☑ 外部とのすべての依存関係を識別する (必要に応じて連絡を取る)。
・プロジェクトを過去に遡ってレビューする方法に加えて、プロセスの検証および改善部分の検出の方法
☑ テスト終了作業「3. テスト活動の振り返り(学習した教訓)」として以下が必要である。
a. 品質リスクの分析セッションにおいて、必要十分な関係部門を招集できたか振り返る。
b. 見積もりの正確さを振り返る。
c. 欠陥の原因分析および影響分析の傾向と結果を評価する。
d. プロセス改善の余地がないか検討する。
e. 今後の計画で考慮すべき、予期しなかった計画との差異がなかったか振り返る。
☑ 振り返りの結果をもとに、次のプロジェクトやテスト活動の計画へ反映させる。
以上です。読んでいただきありがとうございます (^^)/
もしご意見等あればコメントいただけると幸いです。
この記事が気に入ったらサポートをしてみませんか？