超(個人)訳JSTQB Foundation Level シラバス Part6

はじめに

前回の続きでテスト活動に関するシラバスを読解していく。

引用元について

テーマにある通り、ISTQBが提供するFoundation Levelシラバスを引用させて頂く。

1.4.3 テストウェア

テストウェアは、1.4.1 項で説明したテスト活動にて出力する作業成果物として作成する。組織によって、作業成果物の作成方法、形式、名称、整理方法や管理方法には大きな違いがある。適切な構成管理（5.4 節参照）により、作業成果物の一貫性と整合性を確保する。以下の作業成果物のリストは、すべてを網羅するものではない：

以降でテスト活動の中で発生する作業成果物(テストウェア)の一例を紹介する。

テスト計画の作業成果物には、テスト計画書、テストスケジュール、リスクレジスター、開始基準と終了基準が含まれる。（5.1 節参照）。リスクレジスターは、リスクの可能性、リスクの影響、リスク軽減に関する情報とともに、リスクを列挙したものである（5.2 節を参照）。テストスケジュール、リスクレジスター、開始基準、終了基準は、多くの場合、テスト計画書の一部である。

テスト計画では、テストを行うに当たってのスケジュールや懸念事項、テストの開始・終了の要件をテスト計画書としてまとめてテストウェアと位置づけている。

テストのモニタリングとコントロールの作業成果物には、テスト進捗レポート(5.3.2 項参照)、コントロールのための指示の文書化（5.3 節参照）、リスク情報（5.2 節参照）が含まれる。

テストのモニタリングとコントロールにおいては、テストの進捗状況をレポートとして残し、テスト活動の中で発生したリスクや、モニタリングから見えてくる懸念事項やそれに対するアクションを記載しておくことがある。

テスト分析の作業成果物には、（優先順位を付けた）テスト条件（例えば、受け入れ基準など、4.5.2 項参照）、およびテストベース内の欠陥についての（直接修正しない場合の）欠陥レポートが含まれる。

テスト分析では、要件一覧や開発チームが作成した開発仕様書をベースに、テストの条件を整理した作業成果物が作られる。

テスト設計の作業成果物には、（優先順位を付けた）テストケース、テストチャーター、カバレッジアイテム、テストデータ要件とテスト環境要件が含まれる。

テスト設計では、テスト分析を経て作成されたテスト条件をベースに、テストケースを作成する。
テストケースの中には、テストで使用する環境やデータについての要件を含めることがある。

テスト実装の作業成果物には、テストプロシジャー、自動テストスクリプト、テストスイート、テストデータ、テスト実行スケジュール、およびテスト環境が含まれる。テスト環境に含むものの例としては、スタブ、ドライバー、シミュレーター、そしてサービス仮想化がある。

テスト実装では、テストを実行する上で必要な環境やデータがテストウェアの位置づけとなる。

テスト実行の作業成果物には、テスト結果記録および欠陥レポートがある（5.5 節参照）。

テスト実行では、テストの結果記録やテストの中で検出した欠陥のレポートが該当する
※実務においては、テストケースの中に結果を記録するフォーマットが組み込まれているが多い

テスト完了の作業成果物には、テスト完了レポート（5.3.2 項参照）、後続するプロジェクトまたはイテレーションを改善するためのアクションアイテム、得られた教訓をドキュメントにしたもの、変更要求（例えば、プロダクトバックログアイテムとして）が含まれる。

テスト完了では、テスト結果を伝達するテストレポートとテストを通して見つけた課題、次回開発に向けたアクションアイテムや申し送り事項が該当する。

1.4.4 テストベースとテストウェアとの間のトレーサビリティ

効果的なテストのモニタリングとコントロールを実装するためには、テストベースの各要素と関連するテストウェア（例えば、テスト条件、リスク、テストケース）、テスト結果、検出した欠陥との間のトレーサビリティを、テストプロセス全体を通して確立、および維持することが重要である。
正確なトレーサビリティはカバレッジの評価を支援する。なので、測定可能なカバレッジ基準がテストベースに定義してある場合、非常に有用となる。カバレッジ基準は、テスト目的がどの程度達成しているか示す活動を遂行するための KPI として機能する（1.1.1 項参照）。例えば、以下のようなものがある。

• テストケースと要件のトレーサビリティにより、要件がテストケースでカバーされていること
  を検証することができる。
• テスト結果とリスクのトレーサビリティは、テスト対象にある残存リスクのレベルを評価する
  ために利用できる。

テスト担当者が作成したテストケース等の作業成果物と、要件や開発仕様書等のテストベースとの間でどの要件や仕様が対応しているかを紐づけておくことで、トレーサビリティを確保すると表現する。
こうすることでテストケースの抜け漏れを防ぐことができる。
要件を軸にしたカバレッジを形成し、それらを測定することでテストの進み具合も可視化できる。

また、トレーサビリティはテストケースと要件を紐づけるだけでなく、テスト結果とテスト実行中に検出した欠陥を紐づけることで、どの機能で不具合が検出し、それらの情報から現在の品質状況を分析する手段にもなる。

カバレッジの評価に加えて、優れたトレーサビリティは、変更の影響を判断することができ、テストの監査を容易にし、ITガバナンスの基準を満たすのに役立つ。また、テストベースの各要素の状況を含めることで、テスト進捗や完了レポートをよりわかりやすくする。テストの技術的な側面をステークホルダーにわかりやすく伝えることにも役立つ。トレーサビリティは、プロダクト品質、プロセス能力、およびビジネスゴールに対するプロジェクトの進捗を評価するための情報を提供する。

トレーサビリティはソフトウェアの変更履歴を追うことにも役立つ。
トレーサビリティが確保されていない状況を仮定した場合、テストウェア側と要件を参照しながらどこの機能をどう修正を加えたかをいちいち確認するのは非常に効率が悪い。
トレーサビリティを確立することで要件変更に対する影響範囲が可視化され、テストウェアに対する影響度も測定でき、その結果からテストに投下できる工数も目処がつきやすくなる。

1.4.5 テストの役割

本シラバスでは、テストにおける 2つの主要な役割である、テストをする役割とテストマネジメントをする役割を取り上げる。この 2つの役割に割り当てられる活動やタスクは、プロジェクトやプロダクトのコンテキスト、各役割を担う人々のスキル、組織などの要因に依存する。

テストマネジメントをする役割は、テストプロセス、テストチーム、テスト活動のリーダーシップに対する全体的な責任を負う。テストマネジメントをする役割は、主にテスト計画、テストモニタリングとコントロール、テスト完了の活動に重点を置いている。テストマネジメントをする役割の実施方法は、状況によって異なる。例えば、アジャイルソフトウェア開発では、テストマネジメントのタスクの一部をアジャイルチームが担当することがある。複数のチームや組織全体にまたがるタスクは、開発チーム以外のテストマネージャーが行うことがある。

テストをする役割は、テストのエンジニアリング（技術的）側面に対する全体的な責任を負う。テストをする役割は、主にテスト分析、テスト設計、テスト実装、テスト実行の活動に重点を置いている。さまざまな人が、さまざまなタイミングでこれらの役割を担う場合がある。例えば、テストマネジメントをする役割は、チームリーダーが行うこともあれば、テストマネージャーが行うこともあり、開発マネージャーが行うこともある。また、一人がテストをする役割とテストマネジメントをする役割を同時に担うことも可能である。

テストには2つの役割があり、テストをする担当と、テストマネジメントを行う担当に分かれる。
テストマネジメントを行う役割は、テスト活動で必要なマネジメントの以下の活動に注力することが求められる。

• テスト計画
• モニタリングとコントロール
• テスト完了

テストをする役割は、テストの技術的領域の部分に注力する担当であり、テスト分析からテスト実行までの活動にリソースを割く。

各役割の具体的な担い手については、明確に決まっておらず、プロジェクトによって様々である。
マネジメント専任で人間もいれば、プレイングマネージャーのようにテストを行う担当とマネジメントをする担当との兼任も可能である。

おわりに

次回ではテストに必要不可欠なスキルについて、シラバス読解を進めていく。