1.3 作業成果物に関連するタスク (Tasks Related to Work Products)

作業成果物（Work Products）におけるTAの役割

テストアナリスト（TA）の活動は、テストプロセスの各フェーズにおいて具体的な「作業成果物」として形になります。これらの成果物は、テストの客観的な証拠（エビデンス）となるだけでなく、プロジェクト全体の品質を保証し、将来の回帰テストにおいて再利用される貴重な資産となります。

シラバスの1.3.1節から1.3.7節に完全に準拠し、TAが責任を持つ重要な作業成果物とタスクについて解説します。

1.3.1 ハイレベルテストケースとローレベルテストケース (High-Level Test Cases and Low-Level Test Cases)

TAは、テスト設計において抽象度の異なる2種類のテストケースを使い分け、または段階的に具体化していきます。

ハイレベルテストケース（論理テストケース / High-level Test Cases）: 具体的な入力値や具体的な環境設定、詳細なデータを含まないテストケースです。ビジネスロジックや大まかな運用の流れを検証することに適しています。
- メリット: 仕様変更に強く、ドキュメントのメンテナンスコストが低く抑えられます。また、他のプロジェクトや異なる環境でも再利用しやすいという特徴があります。
ローレベルテストケース（具象テストケース / Low-level Test Cases）: 実際にテストを実行するために必要な、具体的な入力値、事前条件、明確な操作手順、および具体的な期待値を含んだテストケースです。
- メリット: 経験の浅いテスターでも迷わずに実行でき、結果の「パス／フェイル」の判定を客観的かつ確実に行えます。また、テスト自動化スクリプトを作成するための直接的なインプットとなります。

TAは、プロジェクトのスケジュール、自動化の戦略、およびテスト実行者のスキルレベルに合わせて、これらを適切に設計・管理するタスクを担います。

1.3.2 テストケースの品質基準 (Quality Criteria for Test Cases)

設計されたテストケースがその目的を果たすためには、高い品質を備えていなければなりません。TAは、作成したテストケースが以下の 9つの品質基準 を満たしているかを常に検証・レビューする必要があります。

正確性（Correctness）: テストベース（仕様書など）の要件を正しく反映していること。誤った期待値や誤ったステップが含まれていないこと。
実現可能性（Feasibility）: テストケースが実際に実行可能であること。必要な環境やデータが入手可能であること。
必要性（Necessity）: テストケースの各ステップや各期待値が、テスト目的を達成するために本当に必要であること。不要な冗長さがないこと。
理解可能性（Understandability）: テストケースを読んだ人が、その意図・手順・期待値を容易に理解できること。曖昧な表現がないこと。
追跡可能性（Traceability）: どの要件（またはどのリスク項目）を検証するためのテストケースなのかが双方向に紐付いていること。
一貫性（Consistency）: テストケース間で、用語・フォーマット・スタイルが統一されていること。
精密性（Precision）: 期待値と実際の結果の比較が、明確かつ具体的に定義されていること。あいまいさなく合否判定できること。
完全性（Completeness）: テストケースが、テスト目的を達成するために必要なすべての情報（事前条件、手順、期待値など）を網羅していること。
簡潔性（Conciseness）: テストケースが、必要以上に長くなく、目的を達成するために最小限の手順で記述されていること。

1.3.3 テスト環境の要件 (Test Environment Requirements)

テストを正確に実行し、本番環境で起こり得る問題を事前にあぶり出すためには、適切な 「テスト環境の要件」 を特定することが不可欠です。TAは、技術的な視点から以下の要素を網羅した環境要件を定義し、文書化します。

ハードウェアとソフトウェア: サーバー、クライアント端末、OSの種類やバージョン、必要なミドルウェア、ブラウザのバージョンなど。
ネットワーク構成: テストに必要な通信帯域、ファイアウォールの設定、プロキシ、社内外のネットワーク接続経路。
インターフェースと周辺システム: テスト対象システムが依存する外部のAPIやサブシステム、またはそれらを代替するスタブやモックの必要性。
アクセス権限: テストを実行するアカウントに必要なロール（管理者、一般ユーザーなど）や、適切なセキュリティ権限。

1.3.4 テストオラクルの決定 (Determining Test Oracles)

テストを実行した際、システムの実際の挙動が「正しいか、誤っているか」を判断するための情報源を 「テストオラクル（Test Oracle）」 と呼びます。TAは、期待される結果を定義するために、信頼できるテストオラクルを決定しなければなりません。

代表的なテストオラクルの例:
- 要件定義書、基本設計書、ユーザーストーリーの受け入れ基準
- 既存の古いシステム（レガシーシステムとの比較）
- ユーザーマニュアルや業務規定、業界の標準規格・法律
- プロダクトオーナーやドメイン専門家の知識
テストオラクル問題: 仕様が不正確であったり、ドキュメントが存在しなかったりする場合、何が正しい挙動なのか判断できない「テストオラクル問題」が発生します。TAは開発初期のテスト分析を通じてこの問題を検知し、ステークホルダーと協議して期待値を明確にするタスクを担います。

1.3.5 テストデータ要件 (Test Data Requirements)

テストケースを実行可能にするためには、適切なデータが揃っていなければなりません。TAは、必要な 「テストデータ要件」 を詳細に定義します。

データの種類と条件: 同値分割や境界値分析で特定した値、異常系のエラーを引き起こすための無効な値、特定のステータスを持つアカウントデータなど。
データの量: ビジネスプロセスを一通り通すための数レコードから、大量処理を検証するための大規模データまで。
データのライフサイクルと管理: テストの実行によってデータが消費（使用不可に）されたり、状態が書き換わったりする場合の対策。TAは、テスト実行後にデータを初期状態に戻すクリーンアップ手順や、再ロード（初期化）の要件も併せて定義します。

1.3.6 キーワード駆動テストを使ったテストスクリプトの開発 (Developing Test Scripts Using Keyword-Driven Testing)

自動化の保守性と効率性を高めるアプローチとして、TAは 「キーワード駆動テスト（Keyword-Driven Testing）」 を活用したテストスクリプトの開発に貢献します。

タスクの詳細:
- キーワードの定義: 画面操作やビジネスプロセスを抽象化した「キーワード」を定義します（例：Login（ログイン）, InputText（テキスト入力）, VerifyResult（結果確認））。
- スクリプトの構造化: テストの実行ロジック（キーワードの組み合わせ）と、そこに流し込む「テストデータ」を完全に分離します。
メリット: これにより、プログラミング技術を持たないテストアナリストでも、キーワードとデータをスプレッドシート等に並べるだけで、簡単かつ迅速に新しいテストスクリプトを開発・修正できるようになります。

1.3.7 テストウェア管理に適用するツール (Tools Applied in Managing the Testware)

多数のテストケース、テストデータ、自動化スクリプト、および不具合レポートを破綻させずに運用するためには、適切なツールの活用が不可欠です。TAは、以下の 「テストウェア管理ツール」 を実務に適用し、管理を徹底します。

テスト管理ツール（ALMなど）: テスト仕様書、テストケースの実行ステータス（Pass/Fail）、および要件とのトレーサビリティ（追跡可能性）を一元管理します。
構成管理ツール（Gitなど）: テストケースのドキュメントや自動化スクリプトのバージョンを管理し、システムのどのバージョンに対してどのテストウェアを適用したかを明確にします。
欠陥管理ツール（Jiraなど）: テスト実行中に発見された不具合のステータス（新規、修正中、確認テスト完了など）を追跡し、テストケースと不具合をリンクさせて管理します。

TAはこれらのツールを効果的に組み合わせることで、テスト資産の紛失を防ぎ、いつでも再利用・追跡ができる強固な管理体制（構成管理）を維持します。