皆さん、こんにちは。
四連休（2020年時）もあっという間ですね。
いかがお過ごしでしたでしょうか。
今回はJSTQB Foundation Levelの5項「テストマネジメント」について述べていきたいと思います。
■5.1テスト組織
テストの組織では、以下の内容について述べていきます。
・独立したテスト
・テストマネージャーとテスト担当者のタスク
□5.1.1独立したテスト
「独立」というのは、開発プロジェクトの開発者、関係者と異なる人と認識するとよいかと思います。
以前、以下の記事で紹介しました、「第三者検証会社」と呼ばれる外部の会社にテストを依頼しテストを実施するといった形式の場合、独立性の高いテストであると認識しています。
https://susakiworks.com/2020/07/14/about_the_test_industry/
□客先へ出向しテスト業務を行う場合（第三者検証会社）
なお、JSTQB FoundationLevelに記載されている独立性については以下のように述べられています。
・独立したテスト担当者不在
・開発チーム、またはプロジェクトチーム内に所属する、独立した開発担当者、またはテスト担当者
・組織内にある独立したテストチームまたはグループで、プロジェクトマネージャーや上位管理者の直属組織
・顧客またはユーザーコミュニティから派遣された独立したテスト担当者、または、使用性、セキュリティ、性能、規制/標準適合性、移植性など、ある程度のテストタイプを専門に行う独立したテスト担当者
・組織外の独立したテスト担当者。オンサイト（インソーシング）、またはオフサイト（アウトソーシング）で作業する。
また、テストの独立性は、ソフトウェア開発ライフサイクルモデルによって異なります。
アジャイル開発の場合は、テスト担当者を開発チームに参加させることがあります。
さらに、プロダクトのオーナーが各イテレーションの終わりに受け入れテストを実行して、ユーザーストーリーの妥当性を確認するケースもあります。
自社開発のアプリ、Webサービスを開発し、1スプリントが短く、開発者がテストに参加し、
1スプリントの終わりごとに自社の部門長、役員が実際にその成果物を確認するといったようなケースが該当します。
独立したテストの利点、欠点は以下となります。
「利点」
・独立したテスト担当者は、開発担当者とは異なる背景、技術支店、バイアスを持つため、開発担当者とは異なる種類の故障を検出する可能性が高い。
・独立したテスト担当者は、仕様作成時及び実装時にステークホルダーが行った仮定について、検証、説明の要求、または反証を行うことができる。
・これは、私個人の見解となりますが、外部組織にテスト業務を依頼した場合、コストが安いということも挙げられます。
「欠点」
・開発チームから隔絶されると、協力関係の欠如、開発チームフィードバック提供の遅延、開発チームの対立を招くことがある。
・開発担当者の品質に対する責任感が薄れることがある。
・独立したテスト担当者は、ボトルネックとして見られ足り、リリース遅延で責任を問われたりすることがある。
・独立したテスト担当者にテスト対象の情報など重要な情報が伝わらないことがある。
・こちらも私見を述べると、外部組織でテスト業務を依頼した場合、多くは優秀な方が多いですが、案件、プロジェクトが多忙で、頭数合わせのように人をアサインされた場合、
場合によっては責任感が薄い・モチベーションが無いなど、適合したテスト担当者では無いケースもあります。
特に、金融系システムや大規模なソフトウェアの開発で、外部組織として、第三者検証会社に依頼した場合、検証会社の孫会社から人をアサインするケースがあります。
そのような場合、検証会社の正社員が管理、そのほかのテスト担当者が孫会社でアサイン等ざらにあり、メンバー間のマネジメントが上手くいかず、人の入れ替わりが激しいケースもあります。
□5.1.2テストマネージャーとテスト担当者のタスク
JSTQB Foundation Levelのシラバスでは、テストマネージャー、テスト担当者という2つの職務を解説しています。
「テストマネージャー」
テストマネージャーのタスクは、テストプロセスに対して全体的な責任を持ち、テスト活動においてリーダーシップを適切に発揮することです。
テストマネージャーのタスクは、主に以下があります。
・テストポリシー、テスト戦略、開発のレビュー
・テスト目的とリスクを理解してテスト活動を計画
（テストアプローチの選択、テストにかかる時間/工数/コストの見積もり、リソースの獲得、テストレベルやテストサイクルの定義、欠陥マネジメントの計画などを含みます）
・テスト計画書を作成し、適時更新を行い、テストコントロール
・プロジェクトマネージャー、プロダクトオーナーなどの間でテスト計画書の内容を調整
・テスト側の考え方を総合計画などの他のプロジェクト活動と共有
・テスト分析、設計、実装、実行の開始宣言、テスト進捗とテスト結果をモニタリング、終了基準のステータス確認
・テスト進捗レポート、テストサマリーレポートを収集した情報に基づいて準備し配布
・欠陥マネジメントシステムのセットアップ、テストウェアの適切な構成管理を支援
・テストプロセスで行うツールの選択と実装を支援
（ツールの選択のための予算提案、パイロットプロジェクトのための時間と工数の割り当て、ツール支援など）
・構築するテスト環境を決定
・組織内のテスト担当者、テストチーム、テスト専門家を昇格、支援
・テスト担当者のスキルアップ、キャリアアップを促す（トレーニング計画、業績評価、コーチングなど）
シラバスでは以上のように明記されています。
また、アジャイルなどのソフトウェア開発ライフサイクルモデルによっては異なるケースもあります。
テスト計画、テスト実施時の管理、テスト終了までのマネジメントが主なタスクです。
各タスクを実施する上で重要なことは、共通してコミュニケーション能力だと私は考えています。
テスト担当者、開発者、設計者、PMなどのメンバーとのコミュニケーションが不十分であると、上記の各タスクに対応できないためです。
テストマネージャーに限らず、管理する側の立場の方々は、全体を見渡すための広い視野、良好な人間関係の構築が重要であると私は考えます。
「テスト担当者」
次に、テスト担当者のタスクは以下があります。
・テスト計画のレビューへの貢献
・要件、ユーザーストーリーと受け入れ基準、仕様、テストベースの分析、レビュー、評価
・テスト条件の文書化、テストケース、テスト条件、テストベース間とのトレーサビリティを確立
・テスト環境の設計、セットアップ、検証
・テストケースとテスト手順を設計、実装
・テストデータ、及びテストアイテムの準備、入手
・詳細なテスト実行スケジュールの作成
・テストケースを実行、結果を評価、期待結果からの逸脱を文書化（インシデントレポートなど）
・適切なツールの使用
・必要に応じてテストの自動化
・性能効率性、信頼性、使用性、セキュリティ、互換性、移植性などの非機能特性を評価
・他の人が設計したテストケースのレビューなど
シラバスでは以上のように記載されています。
テスト担当者もコミュニケーション能力は必要ですが、私個人として最も大事なことは、指示待ちなどの受け身ではなく、自発的に行動することです。
特に大きいプロジェクトのケースで、テスト担当者が５～10人、10人以上といる場合、割り振られたテストタスクを終了後、自発的に行動できないテスト担当者がいると思います。
自発的に行動することができないと、自身の成長につながることはできないと私は考えます。
■5.2テストの計画と見積もり
こちらでは、以下の内容について述べたいと思います。
・テスト計画書の目的と内容
・テスト戦略とテストアプローチ
・開発基準と終了基準
・テスト実行スケジュール
・テスト工数に影響する要因
・テスト見積もりの技術
□5.2.1テスト計画書の目的と内容
テスト計画では、組織のテストポリシーやテスト戦略、使用する開発ライフサイクルや手法、テスト範囲、目的、リスク、制約、クリティカルな度合い、試験性、リソースの調達に基づきます。
テスト計画は、テストプロセスの序盤に計画するだけでなく、プロダクトのライフサイクル全体を通して行う必要があります。
テスト計画には、以下の活動が含まれます。
・テストの範囲、目的、リスクの決定
・テストに対する包括的なアプローチの定義
・テスト活動をソフトウェアライフサイクルでの活動に統合
・何をテストするか、様々なテスト活動でどのような人的リソース、テス方針の決定
・テスト分析、設計、実装、実行、評価の活動を特定の日付または各イテレーションの状況でスケジューリング
・テストのモニタリングとコントロールのためのメトリクスを選定
・テスト活動の予算を決定
・テストドキュメントの詳細レベルと構造の決定
□5.2.2テスト戦略とテストアプローチ
こちらでは、テスト戦略、アプローチついて述べていきます。
まず、テスト戦略の種類は、一般的に以下のようなものがあります。
・分析的
いくつかの要因の分析に基づきます。
リスクのレベルに基づいてテストを設計し優先順位付けするリスクベースドテストがあります。
・モデルベースド
プロダクトで必要な特性を表すモデル、例として、機能、ビジネスプロセス、内部構造、非機能特性などに基づいてテストを設計します。
ビジネスプロセスモデル、状態モデル、信頼度成長モデルなどがあります。
・統計的
事前に定義した一連のテストケース、またはテスト条件を体系的に使用します。
テスト条件には、可能性の高い故障を体系的に分る下リスト、重要な品質特性のリスト、モバイルアプリケーションやWebページに対する企業全体の印象標準などあります。
・プロセス準拠
外部のルールや標準を使用してテストの分析、設計、実装を行います。
プロセスドキュメント、テストベースの識別や使用、組織によって課せられるプロセスや標準などがあります。
・指導ベース（コンサルテーションベース）
テストチームの外部または素子区自体の外部のステー区ホルダー、ビジネスメインの専門家、技術的専門家からの助言、ガイダンス、指示に基づいてテストを行います。
・リグレッション回避
既存では実現されていた能力のリグレッションを避けることを目的とします。
既存のテストウェア、高度に自動化されたリグレッションテスト、及び標準テストスイートの再利用が含まれます。
・対処的
テスト対象のコンポーネントやシステム、テスト実行時に発生するイベントにチして対処的にテストを行います。
テストは事前に計画されず、先に実行したテストの結果により得られる知識に応じて、テストを設計および実装し、実行します。
テスト戦略は、テストプロセスを汎用的に説明したものであり、テストアプローチは特定のプロジェクトまたはリリース用にテスト戦略をテーラリング（プロジェクトにあった具体的な標準を策定すること）したものです。
テストアプローチは、テスト技法、テストレベル、テストタイプの選択や、開始基準と終了基準を決めるための出発点です。
テスト戦略のテーラリングは、プロジェクトの複雑さやゴール、開発対象プロジェクトの種類、プロダクトリスク分析を考慮して行います。
□5.2.3開始基準と終了基準（準備完了（ready)の定義と完了(done)の定義)
ソフトウェアおよびテストの品質を効果的にコントロールするために特定のテスト活動をいつ開始し、いつ完了するかを定義し基準を設けます。
「開始基準」
・テスト可能な要件、ユーザーストーリーなどが準備できていること
・前のテストレベルで終了基準を満たしたテストアイテムが準備できていること
・テスト環境が準備できていること
・必要なテストツールが準備できていること
・テストデータや他の必要なリソースが準備できていること
「終了基準」
・計画したテスト実行が完了していること
・定義済のカバレッジ（要件、ユーザーストーリー、受け入れ基準、リスク、コード）を達成していること
・未解決の欠陥は合意された制限内、または処遇が決まっている（次verのフェーズで対応等など）こと
・残存欠陥の想定数が十分に少ないこと
・信頼性、性能効率性、使用性、セキュリティ、他の関連する品質特性を十分に評価していること。
なお、終了基準を満たしていない場合でも、予算、時間などにより、テスト活動を切り上げることもあります。
また、プロジェクトのステークホルダーやビジネスオーナーが、テストの追加無しでプRダクトをリリースするリスクを見直して受け入れた場合は、このような状況でもテストを終了する場合があります。
□5.2.4テスト実行スケジュール
テスト実行スケジュールは、優先度、依存関係、確認テスト、リグレッションテスト、及びテストの実行に最も効果的な順序を考慮して決めます。
テストケースの実行順序は優先度レベルに基づくことが理想的で、最も高い優先度を持つテストケースを最初に実行することが一般的です。
確認テストやリグレッションテストは、変更に関する迅速なフィードバックの重要性に応じて優先度を割り当てます。
なお、制限事項等ある場合は、優先度の低い部分からテスト実施するというパターンもあります。
□5.2.5テスト工数に影響する要因
テスト工数の見積もりは、特定のプロジェクト、リリース、イテレーションのテスト目的を達成するために必要な作業工数を予測します。
テスト工数に影響する要因として、以下の事項が挙げられます。
「プロダクトの特性」
・プロダクトに関連するリスク
・テストベースの品質
・プロダクトの規模
・プロダクトドメインの複雑度
・品質特性の要件（セキュリティ、信頼性、使用性など）
・テストドキュメントの詳細度に関する要求レベル
・法規制への適合性の要件
「開発プロセスの特性」
・組織の安定度合いと成熟度合い
・使用している開発モデル
・テストアプローチ
・使用するツール
・テストプロセス
・納期のプレッシャー
「人の特性」
・参加メンバーのスキルや経験、特にドメイン知識のような類似プロジェクトやプロダクトのスキルや経験
・チームのまとまりのリーダーシップ
「テスト結果」
・検出した欠陥の数と重要度
・必要な再作業の量
□5.2.6テスト見積もりの技術
テストを適切に実行するために必要な工数について、一般的に使用する以下2つの内容について述べます。
・メトリクスを活用する
以前の類似したプロジェクトのメトリクス、典型的な値を基にしてテスト工数を見積もります。
こちらは、保守対応のプロジェクトであれば、該当するケースと思います。
新規プロジェクトについては、似たプロジェクトであったとしても、概要的な見積もりとなることが多い傾向ではあります。
そのため、詳細見積もりを後続に実施することが望ましいと私は考えます。
・専門家の知識を基にする
テストのタスクの所有者の経験、または専門家による見積りを基にしてテスト工数を見積ります。
こちらは、私の経験上、あまり聞いたことことがありません。
前者の以前のプロジェクトのメトリクスを活用、または過去のテスト経験を基に見積りを行うことが多いと考えています。
■5.3テストのモニタリングとコントロール
「テストモニタリング」
テストモニタリングの目的は、テスト活動に関する情報を収集して可視化し、フィードバックをかけることです。
テストの終了基準やアジャイルプロジェクトの完了の定義に関連するテストタスクで、プロダクトリスク、要件、受け入れ基準のカバレッジのターゲットを満たすか計測をするために使います。
「テストコントロール」
テストコントロールとは、収集、報告されたテストの実施結果を基にガイドや補正のアクションをすることです。
テストコントロールの作業は以下のようなものがあります。
・識別したリスクが現実になった場合、テストの優先度を見直す。
・テスト環境や他のリソースの利用可否により、テストスケジュールを変更する。
・再作業が発生した場合に、テストアイテムが開始基準と終了基準を満たすか再評価する。
□5.3.1テストで使用するメトリクス
メトリクスは、各テストの期間、及び終了時に収集できる以下の項目を評価します。
「メトリクスの評価項目」
・計画したスケジュールや予算に対する進捗
・テスト対象の現在の品質
・テストアプローチの十分性
・テスト木亭に対するテスト活動の効果
「代表的なテストメトリクス」
・計画したテストケースの準備が完了した割合
・計画したテスト環境の準備が完了した割合
・テストケースの実行（実行/未実行数、合格/不合格のテストケース数、合格/不合格のテスト条件数）
・欠陥情報（例：欠陥ウド、検出及び修正した欠陥数、故障率、確認テスト結果）
・要件、ユーザーストーリー、受け入れ基準、リスク、コードのテストカバレッジ
・タスクの完了、リソースの割り当てと稼働状況、工数
・テストに費やすコスト
□5.3.2テストレポートの目的、内容、読み手
テストレポートの目的は、テストレベルなどのテスト活動の期間中と終了の両方の時点でテスト活動に関する情報を要約し周知することです。テストレポートは主に以下があります。
テスト進捗レポート
テスト期間中に作成するテストレポート
・テスト活動の状況とテスト計画書に対する進捗
・進捗を妨げている要因
・次のレポートまでの間に計画されているテスト
・テスト対象の品質（テスト結果、テストケース数、NG数、OK数など）
テストサマリーレポート
テスト活動の終了時に作成するテストレポート
・行ったテストの要約
・テスト期間中に発生したこと
・計画から逸脱（スケジュール、期間、工数等）
・終了基準または完了
・進捗を妨げた、妨げている要因
・欠陥、テストケース、テストカバレッジ、活動進捗、リソース消費のメトリクス
・残存リスク
・再利用可能なテスト作業成果物
■5.4構成管理
構成管理の目的は、プロジェクトやプロダクトのライフサイクルを通じて、コンポーネントやシステムの完全性、テストウェア、およびそれら相互の関係を確立し、維持することです。
構成管理では以下を明確にします。
・全テストアイテムを一意に識別し、バージョンコントロールを行い、変更履歴を残し、各アイテム間を関連付けます。
・テストウェアの全アイテムを一意に識別し、バージョンコントロールを行い、変更履歴を残し、各アイテム間を関連付けます。またテストアイテムのバージョンとの関連付けを行い、テストプロセスを通してトレーサビリティを維持できます。
・識別したすべてのドキュメントやソフトウェアアイテムは、テストドキュメントに明確に記録します。
■5.5リスクとテスト
□5.5.1リスクの定義
リスクは、将来に否定的な結果となる事象が起きる恐れを含みます。
リスクのレベルは、そのような事象が起きる可能性とその影響で決まります。
□5.5.2プロダクトリスクとプロジェクトリスク
「プロダクトリスク」
作業成果物（仕様、コンポーネント、システム、テストケース）がユーザー、またはステークホルダーの正当なニーズを満たすことができない恐れを含みます。
プロダクトの品質特性（機能性、信頼性、性能効率性、使用性、セキュリティ、互換性、保守性、移植性）に関連し、品質リスクとも呼ばれます。
プロダクトリスクには、以下のものが含まれます。
・ソフトウェアの意図されている機能が仕様通りに動かない
・ソフトウェアの意図される機能がユーザー、顧客、ステークホルダーのニーズ通りに動かない
・システムアーキテクチャーが非苦悩要件を十分にサポートしていない
・特定の計算結果が状況によって正しくない
・ループ制御構造が正しくコーディングされていない
・高性能トランザクション処理システムで応答時間が適切でない
・ユーザーエクスペリエンスのフィードバックがプロダクト期待と異なる
「プロジェクトリスク」
プロジェクトリスクは、発生した場合にプロジェクトの目的達成に悪影響を与えます。
プロジェクトリスクの例として、以下のものがあります。
（プロジェクトの懸念事項）
・リリース、タスク、終了基準、官僚の定義の達成が遅延
・不正確な見積もり、組織全体での経費節減により資金が不足
・プロジェクト終盤での変更により、大規模なやり直しが必要
（組織の懸念事項）
・人員不足、人員のスキルやトレーニング不足
・人間関係の衝突や問題の発生
・ビジネス上の優先度の競合によって、ユーザー、ビジネススタッフ、専門家の都合がつかない
（政治的な懸念事項）
・テスト担当者が自分辰のニーズ、テスト結果の十分性をうまく伝えられない
・開発担当者、テスト担当者がテストやレビューで見つかった事項をフォローアップできない
・テストから期待できるものを正しく評価しようとしない
（技術的な懸念事項）
・要件を十分に定義できていない
・要件を満たさない
・テスト環境が期限まで用意できない
・データ変換及び移行の計画、それらのツール支援が遅れる
・開発プロセスの弱点が、設計、コード、構成、テストデータ、テストケースなど整合性や品質に影響を与える
・不適切な欠陥マネジメント及び類似の問題により、欠陥は他の技術的負債が累積
（供給者側の懸念事項）
・サードパーティが必要なプロダクトサービスを提供できない、撤退することがある
・契約上の懸念事項がプロジェクトの問題の原因となる
□5.5.3リスクベースドテストとプロダクト品質
テスト時に必要な工数についてどこに重点を置くか決定するためにリスクを使用します。
リスクベースのアプローチを採用すると、プロダクトリスクを軽減する予防処置を講じられます。
リスクベースのアプローチでは、プロダクトリスク分析の結果を使用し、以下を行います。
・適用するテスト技法を決める
・実施するテストレベル及びテスト耐ぴを決める
・テストを実行する範囲を決める
・重大な欠陥をなるべく早い時期に検出するため、テストの優先順位を決める
・テスト以外の活動でリスクを減らす方法があるか検討する
また、リスクマネジメントでは、以下事項についてアプローチを備える必要があります。
・どこが上手くいかないかリスクを分析する
・リスクの重要度を決める
・重大なリスクの処理方法を実装する
・リスクが実際に事象として発生した場合に備えてコンティンジェンシープラン（事前に定めておく対応策や行動手順）を作る
■5.6欠陥マネジメント
テストの目的の一つは欠陥を検出することです。
テストで見つかった欠陥は、バグトラックシステム（redmine、JIRA、Backlogなど）のチケットとして記録を残すといったことが一般的です。
典型的な欠陥のチケット（レポート）は、以下の目的があります。
・プロジェクト関係者（主に開発担当者）に情報を提供
・テストマネージャーに対して、作業成果物の品質や、テストへの影響を追跡する手段を提供
・開発プロセスとテストプロセスを改善するためのヒントを提供
動的テスト時の欠陥レポートは、一般的に以下の情報を記入します。
・ 識別子
・レポート対象の欠陥の件名と概要
・欠陥レポートの作成日付、作成者
・テストアイテムおよび環境を識別する情報
・欠陥を観察した開発ライフサイクルのフェーズ
・ ログ、スクリーンショット、動画（テスト実行中に検出された場合は）実行状況などの欠陥の再現と解決を可能にする詳細な説明資料
・欠陥が発生する、または確認できる操作手順
・期待結果と実際の結果
・重要度、優先度
・欠陥レポートのステータス（例えば、オープン、延期、重複、修正待ち、確認テスト待ち、再オープン、クローズなど）
・欠陥の修正が他の領域への影響を与えるといった、広範囲にわたる懸念事項
・欠陥が発生した、または関連するテストケースを含む参照情報
■最後に
如何でしたでしょうか。
今回は、テストマネジメントについて述べてみました。
私自身、テストマネージャー、テスト管理者でテストマネジメントを行う機会は幾度かあります。
案件、プロジェクトによってまちまちですが、上記で述べたことは重要なものが多いです。
テスト担当者からテストリーダー、テストマネージャーを目指す人は、押さえておきたい部分であると思います。
最後まで、見ていただきありがとうございました。
サイトトップへ
https://susakiworks.com/
ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応
