JSTQB Advanced Level テストアナリスト（AL-TA）まとめ

JSTQB AL TA v3.1.1 の内容を各章ごとにまとめたノート。

試験概要

試験情報

• 問題形式：多肢選択式
• 問題数：40 問
• 合格基準：総得点の 65%以上
• 受験資格：Certified Tester Foundation Level 認定資格
• 章ごとの講義時間の目安：第 1 章 150 分、第 2 章 60 分、第 3 章 630 分、第 4 章 180 分、第 5 章 120 分、第 6 章 90 分

テストアナリストの役割と責任境界

テストアナリストは、テストプロセスのうち、特に次の 4 つを中心に担当するロールである。

1. テスト分析：テストベースを読み、テスト条件・フィーチャー・リスク・優先度を識別する。
2. テスト設計：テスト技法を使い、テストケース、テストデータ、期待結果、事前条件・事後条件を設計する。
3. テスト実装：テスト手順、テストスイート、テストデータ、テスト環境、実行スケジュールを準備する。
4. テスト実行：テストを実行し、期待結果と比較し、欠陥を報告し、結果から新しいリスクや追加テストを提案する。

つまり、テストアナリストは単にテストを実行する担当者ではなく、何を、なぜ、どの条件で、どのようにテストし、結果をどう判断するかを具体化するロールである。一方、テスト戦略全体、組織横断の計画、リソースや残余リスクに関する最終判断は、通常テストマネージャーの責任範囲になる。

flowchart TB
    M[テストマネージャー<br/>テスト戦略・計画・全体のモニタリング／コントロール]
    TA[テストアナリスト<br/>テスト条件・ケース・データ・実行・結果分析]
    TTA[テクニカルテストアナリスト<br/>技術的な品質特性・技術リスク]
    AUTO[テスト自動化担当<br/>自動化スクリプト・フレームワーク]
    DEV[開発者<br/>実装・欠陥修正・技術調査]
    BIZ[ユーザー／プロダクトオーナー／ドメイン専門家<br/>業務目的・期待・受け入れ基準・ビジネス影響]

    M -->|方針・制約・優先度| TA
    TA -->|進捗・結果・残余リスク| M
    BIZ -->|要求・期待結果・業務リスク| TA
    TA -->|テスト条件・ケース・欠陥情報| BIZ
    TA <-->|機能・技術の境界を調整| TTA
    TA -->|キーワード・テストデータ・期待結果| AUTO
    AUTO -->|スクリプト・自動実行結果| TA
    DEV -->|ビルド・修正・技術情報| TA
    TA -->|欠陥報告・再テスト結果| DEV

この境界は組織や SDLC によって変わる。特にアジャイルでは、ロール名が明確に分かれず、チーム全体でテストアナリストのタスクを分担することがある。試験では「誰の職位か」よりも、その活動の責任を誰が担うかで判断する。

全体像

flowchart LR
    A[テストベースを読む] --> B[テスト分析]
    B --> D[テスト設計]
    D --> E[テスト実装]
    E --> F[テスト実行]
    F --> G[結果・欠陥・新しいリスク]
    G --> B
    H[レビュー]:::note -.-> A
    I[テスト技法]:::note -.-> D
    J[ツール・自動化]:::note -.-> E
    J -.-> F
    K[テスト条件・リスク・優先度]:::note -.-> B
    K -.-> D
    classDef note fill:#fff8dc,stroke:#b8860b,stroke-dasharray: 5 5,color:#5c4500

第 1 章 テストプロセスにおけるテストアナリストのタスク

1.1 SDLC とテストアナリストの関わり

テストアナリストは、要件エンジニアリング、プロジェクト管理、構成・変更管理、開発、保守、テクニカルサポート、技術文書作成などへ、レビュー結果・スケジュール情報・ビルド検証結果・欠陥情報・既知の問題などを提供する。

1.2 テスト分析

テスト分析では、テスト計画で定めた範囲に対して、次を行う。

• テストベースを分析する。
• テストベースの欠陥（曖昧さ、矛盾、欠落、テスト不能など）を識別する。
• テスト対象のフィーチャーとテスト条件を識別し、優先度を付ける。
• テストベースの要素とテスト条件の間に双方向トレーサビリティを確立する。
• リスク識別、リスクアセスメント、リスク軽減に参加する。

分析を始める前に、テストベースとなる知識、関係者、テスト環境、利用可能なツール、テスト目的、テスト条件を整理する。テストベースが不完全でも、欠落・曖昧・矛盾・テスト不能な要件を発見すること自体がテスト分析の成果になる。

1.3 テスト条件をステークホルダーと共有する理由

• テスト対象の範囲と、テストする／しないものを合意できる。
• 仕様の欠落・矛盾・曖昧さを早期に発見できる。
• 業務上重要なリスクやユーザーの期待をテストへ反映できる。
• テスト条件から要件、テストケース、結果へのトレーサビリティを保てる。
• 受け入れ基準や期待結果を、テストアナリストだけの解釈にしないで済む。

1.4 ハイレベル／ローレベルテストケース

要件が明確・安定していく場合は、ハイレベルからローレベルへ段階的に詳細化する。設計レベルは、リスク、規制、再現性、担当者のスキル、要件の安定度、自動化の必要性で決める。

1.5 テストケース設計で定義する項目

• 目的：観測可能・測定可能なテスト実行の目的。
• 事前条件：環境、リリース、システム状態、必要な権限など。
• テストデータ：入力値だけでなく、データベースや環境に事前投入するデータ。
• 期待結果：明確な合格／不合格基準。画面出力だけでなく、データ・環境の事後状態も含む。
• 事後条件：変更されたデータ、システム状態、後続処理のトリガーなど。
• トレーサビリティ：テストベース → テスト条件 → テストケース → 手順／スクリプト → 結果。

テストオラクルは、実際の結果が正しいか判断する仕組みである。期待結果を計算できないまま実行すると、欠陥かどうか判断できず、価値の低いテストになる。

1.6 テスト実装

テスト実装は、分析・設計したテストを実行可能なテストウェアにする活動である。

• テスト手順と必要な自動テストスクリプトを作成する。
• テスト手順・スクリプトをテストスイートへ整理する。
• リスク、依存関係、リソース、テスト対象の準備順を考えて実行順を決める。
• テスト実行スケジュールとリソース割り当てを作る。
• テストデータ、テスト環境、構成管理、欠陥管理、結果記録を準備・検証する。
• テストベースからテストスイートまでのトレーサビリティを更新する。

スクリプトなしのテストは、無目的・ランダムに行うのではなく、タイムボックスとテストチャーターで管理する。探索的テストは軽量で欠陥発見に有効な一方、期間・カバレッジ・再現性の予測が難しい。

1.7 テスト実行

• 手動テスト、探索的テスト、自動テストを実行する。
• 実際の結果と期待結果を比較する。
• 不正な結果を分析し、故障と欠陥を報告する。
• 実際の結果、環境、ビルド、データを記録する。
• テストベースとテストウェアのトレーサビリティを更新する。
• リグレッションテストを実施する。
• 欠陥が集中する領域、新しいリスク、今後の探索的テスト、手順改善を提案する。

1.8 頻出のひっかけ

• 「テスト分析」はテストケースの具体的な手順を書くことだけではない。テストベース、条件、優先度、リスク、トレーサビリティを扱う。
• 「テスト実装」はテスト対象の実装ではない。テスト手順・データ・環境・スイート・スケジュールを準備する。
• 高リスクだから必ずローレベルにする、とは限らない。リスク、規制、再現性、変化頻度などを総合判断する。
• テスト終了基準は、以降の実行に必要な情報が揃い、準備が完了し、測定可能であることが重要。

第 2 章 リスクベースドテストにおけるテストアナリストのタスク

2.1 基本モデル

flowchart LR
    A[幅広いステークホルダー] --> B[リスク識別]
    B --> C
    B --> D
    subgraph RA["リスクアセスメント"]
        direction TB
        C[可能性を評価]
        D[影響を評価]
        C --> E[リスクレベルを決定]
        D --> E
    end
    E --> F[テスト優先度・軽減策]
    F --> G[テスト結果・新情報]
    G --> B
    style RA fill:#f3f6ff,stroke:#4a6fa5,stroke-width:2px

2.2 リスク識別

リスク識別は、できるだけ多くのリスクを見つける活動である。テストアナリストはビジネスドメインの知識を活かし、次に参加する。

• ドメイン専門家・ユーザーへのインタビュー
• 独立したアセスメント
• リスクテンプレートの利用
• リスクワークショップ
• ユーザーとのブレインストーミング
• テスト用チェックリストの定義
• 類似システム・過去プロジェクトの経験活用

典型的なプロダクトリスクは、機能正確性、使用性、移植性などに関するもの。リスク識別は SDLC 全体で繰り返し、新しい情報や優先度の変化を反映する。

2.3 リスクアセスメント

リスクアセスメントは、識別したリスクを調査し、分類してレベルを決める活動である。通常、次の 2 軸を評価する。

• 可能性：潜在的な問題がシステムに存在し、本番移行後に観察される可能性。
• 影響：ユーザー、顧客、ビジネス、社会、法律、安全などへの重大さ。

テストアナリストは、主にビジネス影響の評価に貢献する。影響の例は、利用頻度、金銭的損失、法的制裁、機能安全、回避策の有無、ブランド毀損、顧客喪失などである。可能性と影響を組み合わせて、数値、低・中・高、信号機などでリスクレベルを決める。

2.4 リスク軽減と優先度付け

テストによるリスク軽減には、次がある。

• 合否を一意に判断できるテストケースを設計する。
• 要件、設計、ユーザードキュメントをレビューする。
• 高リスクのビジネスプロセスへ適切な技法を割り当てる。
• 追加情報に応じて可能性・影響・リスクレベルを再評価する。
• テストで発見した新しいリスクを記録する。
• 正確なデータ、現実的なユーザーシナリオ、使用性調査を用意する。

リスクレベルはテストケースの優先度付けにも使う。

時間内に全テストを終えられない場合、残余リスクをマネジメントへ報告する。テスト延長か、ユーザー・顧客・サポート・運用へのリスク移転かを判断してもらう。

2.5 将来のテストサイクルで再調整するもの

• 新規または大幅変更されたプロダクトリスク
• テストで不安定・故障が多い領域
• 修正された欠陥に由来するリスク
• テストで発見した典型的な欠陥
• 要件カバレッジが低く、テスト不十分な領域

2.6 問題を解くときの順序

1. リスクアイテムを列挙する。
2. それぞれの可能性と影響を分けて評価する。
3. リスクレベルを決める。
4. 高リスクを優先するだけでなく、縦型か横型かを状況に合わせる。
5. テスト・レビュー・早期使用性テスト・追加データなど具体的な軽減策に落とす。

第 3 章 テスト技法

3.1 技法の選択早見表

ブラックボックス技法と経験ベース技法は補完関係にある。単一の「最善の技法」が常にあるわけではなく、技法を組み合わせる。

3.2 同値分割法（EP）

何をするか

同じように処理されると期待する値の集合を同値パーティション（同値クラス）に分け、各パーティションから代表値を選ぶ。入力、出力、内部値、時間関連の値に適用できる。値は連続／離散、有限／無限、順序あり／順序なし、有効／無効を考える。

カバレッジと設計

• カバレッジ = テストしたパーティション数 ÷ 識別したパーティション総数。
• 1 パラメーターなら、有効・無効を含む各パーティションを少なくとも 1 回テストする。
• 複数パラメーターで有効パーティションだけなら、独立性を仮定した最小ケース数は各パラメーターの有効パーティション数の最大値。
• 無効パーティションは、他のパラメーターを有効にして原則 1 つずつ単独でテストする。無効値同士の組み合わせは、リスクが高い場合に追加する。
• パーティション内の値を複数試しても、パーティションカバレッジ自体は増えない。

注意点

パーティション内の値が本当に同じ処理になるかを確認する。正数・負数・ゼロ、文字種、権限、状態など、処理が異なる可能性があるものを同じパーティションにまとめない。異なるパラメーター間の依存関係・組み合わせ制約も見る。

3.3 境界値分析（BVA）

何をするか

順序付けられた同値パーティションの境界上と、その前後をテストする。整数に限らず、文字列長、ループ回数、配列要素数、メモリサイズ、継続時間などにも適用できる。

2 値法と 3 値法

例：有効範囲が 1〜10 の整数の場合。

小数や通貨では最小精度を使う。例えば 1.00〜10.00 の上限なら 9.99, 10.00, 10.01 のように考える。高リスク項目では 3 値法を優先する。

カバレッジと注意点

• カバレッジ = テストした境界条件数 ÷ 識別した境界条件総数。
• EP と同じく、パーティションの識別が間違っていると BVA も間違う。
• 順序付けられたパーティションにだけ適用できる。
• 「未満／以下」「超／以上」のずれ、境界の欠落・余分、非機能の容量上限を狙う。

3.4 デシジョンテーブルテスト

構造

• 条件：入力や前提となる条件。
• ルール：条件値の組み合わせ。
• アクション：そのルールで起きる動作・期待結果。
• 制限指定：条件が真／偽のブール値。
• 拡張指定：条件やアクションが複数の値を取る。

設計手順

1. 仕様から条件とアクションを抽出する。
2. 条件の全組み合わせをルールにする。
3. 実現不可能な組み合わせを除外または明示する。
4. ルールの重複がないか、実現可能な組み合わせを網羅しているか、期待する動作を正しく表すかレビューする。
5. 各ルールをテスト条件として、具体的な入力値と期待結果に変換する。

カバレッジと簡単化

• n 個の真偽条件を持つ完全な制限指定デシジョンテーブルは 2^n ルール。
• 通常のカバレッジは、実行可能な各ルールを少なくとも 1 回テストすること。
• 同じアクションになり、差分条件がアクションに影響しない場合は、差分を「関係なし（-）」として簡単化できる。
• 「カードが無効なら PIN の正しさは関係ない」のように、適用不能な条件を簡単化できる。
• 簡単化はケース数を減らすが、リスクが高いと条件値の欠陥をマスクする可能性がある。高リスクでは条件の組み合わせを分ける。

典型的な欠陥は、条件の組み合わせに対する誤った論理、アクションの欠落、仕様の矛盾である。

3.5 状態遷移テスト

モデル

• 状態：システムが一定の振る舞いをする状況。
• イベント：状態遷移を引き起こす入力・出来事。
• 遷移：状態から状態への移動。
• ガード条件：遷移可能性を決める条件。
• アクション：遷移時に行われる動作。

状態遷移図または状態遷移表を作り、有効遷移だけでなく無効遷移も考える。ログイン、注文、ワークフロー、画面、組込み制御、トランザクションに適用できる。

カバレッジ

• 最小限：すべての状態に滞在し、すべての遷移を少なくとも 1 回通る。
• 0 スイッチ：1 つの遷移をカバーする。100%遷移カバレッジともいう。
• 1 スイッチ：連続する 2 遷移をカバーする。
• N スイッチ：連続する N+1 遷移をカバーする。
• ラウンドトリップ：各状態から元の状態へ戻るループをカバーする。
• より高いカバレッジでは、表で識別した無効遷移も含める。問題文が有効遷移のみか無効遷移を含むかを確認する。

典型的な欠陥は、初期状態・終了状態の誤り、必須状態へ到達できない、余分な状態、誤ったイベント／アクション、無効遷移が実行できる、ガード条件の誤り、仕様の欠落・矛盾である。

3.6 クラシフィケーションツリー技法

• クラシフィケーション：データ空間のパラメーター。例：OS、ブラウザー、言語、クライアント。
• クラス：パラメーターの値または同値パーティション。例：Windows、macOS、Chrome。
• データ空間を視覚化し、同値分割・境界値・シングルワイズ・ペアワイズ・3 ワイズの組み合わせを整理する。
• 互換性のない組み合わせ、関心の高い組み合わせ、変数間の論理関係を見つけるのに役立つ。
• クラシフィケーションツリー自体は完全なテストケースを作らない。組み合わせに手順と期待結果を付加する必要がある。
• クラス数が増えると図が大きくなり、全組み合わせは爆発する。

3.7 ペアワイズテスト

複数パラメーターの全組み合わせが多すぎるとき、任意の 2 パラメーターについて、各値のペアを少なくとも 1 回含めるようにテストケースを削減する。

覚えること

• 100%ペアワイズカバレッジ = 任意の 2 パラメーター間の値ペアをすべて 1 回以上カバー。
• 全直積ではないため、ケース数は通常大幅に減る。
• 3 つ以上のパラメーターの相互作用は見逃す可能性がある。
• 無効・両立不能な組み合わせ、必ず含めたい重要組み合わせ、フィーチャーモデル上の制約を先に確認する。
• 値が多すぎる場合は、先に EP などで値を減らす。
• ツールは組み合わせを生成できるが、各ケースの期待結果を作る責任はテストアナリストに残る。

よくある誤りは、3 つのパラメーターが各 4 値だから 4×4×4=64 ケースと答えてしまうこと。これは全組み合わせであり、ペアワイズの必要数とは別である。

3.8 ユースケーステスト

ユースケースに記載されたアクターとシステムの相互作用を実際のトランザクションとして実行する。ユーザー、外部ハードウェア、他システムなどをアクターにできる。

最小カバレッジ

1. 基本（メイン）フローを 1 ケース。
2. 各代替フローとエラー処理を十分にカバーする追加ケース。
3. 代替フローが互換性を持つ場合は 1 ケースへ組み込める。
4. 診断性を上げたい場合は、代替フローごとに分離する。

例外、代替、エラー処理が定義されていないユースケースは、テスト対象を完全に定義していない。必要に応じてフローチャートやデシジョンテーブルへ変換し、仕様の論理欠陥を探す。通常はシステムテスト・受け入れテストで使い、性能テストの現実的な負荷シナリオにも利用できる。

3.9 技法の組み合わせ

例えば、デシジョンテーブルで条件の組み合わせをカバーした後、各条件の値について EP／BVA で代表値や境界値を追加する。技法の選択では、適用可能性、制約、時間、スキル、期待するカバレッジ、検出したい欠陥、リスクを総合する。

3.10 経験ベースのテスト技法

共通の長所・短所

経験ベース技法には、公式なカバレッジ基準がない点に注意する。

エラー推測

過去の経験から、設計・実装で起きそうなエラーと、それが引き起こす故障を推測し、故障を観察できる入力・操作を作る。リスク分析にも役立つ。他の技法の追加として有効だが、担当者の経験に依存し、カバレッジと再現性の評価が難しい。

チェックリストベースドテスト

標準、経験、受け入れ基準などから作ったハイレベルな確認項目を使う。頻繁なリリース、リグレッション、スモークテストに向く。項目が抽象的なので担当者による解釈差が生じる。チェックリストの項目カバレッジは測れるが、実際の確認の深さは一定とは限らない。

探索的テスト

学習、計画、設計、実行、評価、報告を同時に行う。優れた探索的テストは、タイムボックスとテストチャーターで管理する。

• チャーター：セッションの目的、対象、範囲、成果物、集中する欠陥タイプを示す。
• タイムボックス：テストに使う時間を固定する。
• セッション後に結果を報告し、次のチャーターを更新する。
• シナリオ、機能境界、ワークフロー、性能・セキュリティの問題を発見することがある。
• 再現できるよう、入力、操作、期待結果、実際の結果、環境、証跡を記録する。

欠陥ベースのテスト技法

探したい欠陥タイプをテスト設計の出発点にする。欠陥タイプ、根本原因、故障の兆候などを整理した欠陥分類法からテスト条件とケースを導く。

分類法がプロダクトに適合するか、期待カバレッジを事前に定義する。カバレッジはブラックボックス技法ほど厳密でないことが多い。

3.11 技法選択の思考法

flowchart TD
    A[テストのゴールを定義] --> B{仕様・モデルは十分か}
    B -- はい --> C{主な欠陥の種類は?}
    B -- いいえ --> D[経験ベース: エラー推測・探索的テスト]
    C -- 値・範囲 --> E[EP / BVA]
    C -- 条件の組合せ --> F[デシジョンテーブル]
    C -- 状態・順序 --> G[状態遷移]
    C -- 多数のパラメーター --> H[ペアワイズ]
    C -- ユーザー目的 --> I[ユースケース]
    D --> J[不足部分をブラックボックス技法で補完]
    E --> K[リスク・時間・カバレッジを再評価]
    F --> K
    G --> K
    H --> K
    I --> K

第 4 章 ソフトウェア品質特性のテスト

4.1 ISO 25010 のうち AL-TA で重点的に扱う領域

性能効率性、信頼性、セキュリティ、保守性などは主にテクニカルテストアナリストの領域だが、テストアナリストも重複・依存するリスクを認識する。

4.2 機能適合性の 3 特性

機能完全性は「正しく動くか」ではなく「必要なものが全部あるか」。機能適切性は「指定された機能があるか」だけでなく「ユーザーの目的に適した組み合わせか」。機能正確性は「結果が正しいか」である。

4.3 相互運用性テスト

2 つ以上のシステム／コンポーネントが情報を交換し、その情報を利用できることを検証する。

• ハードウェア、ソフトウェア、ミドルウェア、OS、代表的な対象環境を選ぶ。
• アーキテクチャー・設計文書も調査し、要件に明記されていないデータ交換点を見つける。
• データ、トランザクション、通信規格、異常時の連携を用意する。
• コンポーネント統合テスト、システム統合テストで重点的に実施する。
• EP、BVA、デシジョンテーブル、状態遷移、ユースケース、ペアワイズを適用できる。
• 典型欠陥は、フォーマット、意味、境界、タイミングなど、コンポーネント間の不適切なデータ交換。

4.4 使用性・UX・アクセシビリティ

3 つの概念

• 使用性：ユーザーが UI を介して、効果的・効率的・満足して目的を達成できるか。
• ユーザーエクスペリエンス（UX）：操作性だけでなく、ブランド信頼、相互作用、ヘルプ・サポート・トレーニングを含む全体的な体験。
• アクセシビリティ：特定のニーズや制限、障害があるユーザーも利用できるか。WCAG などの標準・法規を考慮する。

アクセシビリティは設計時から考慮し、統合テストからシステムテスト・受け入れテストまで継続する。例として、音声入力、非テキストコンテンツの代替テキスト、文字サイズ変更、色覚への配慮がある。

使用性テストで測る 3 指標

手法

• 使用性テスト：ユーザーが実際に目的へ到達できるかを測定する。
• 使用性レビュー／ヒューリスティック評価：早期に UI・要件・設計を確認する。スクリーンショットなど視覚資料が有効。
• 調査・アンケート：ユーザーの所見・フィードバックを集める。SUMI や WAMMI はベンチマークや測定値に使える。

テストアナリストは、使用性専門家・人間中心設計の専門家と協力し、ケース仕様化やモデレーターを担うことがある。

4.5 移植性テスト

テストアナリストは、対象環境の組み合わせを識別し、ペアワイズなどでケース数を抑え、インストール後の機能適合性と使用性も確認する。移植性のリスク識別とケース設計は、テストアナリストとテクニカルテストアナリストが協力する。

第 5 章 レビュー

テストアナリストはレビューに参加し、テスト可能性、完全性、曖昧さ、優先度、受け入れ基準、トレーサビリティの観点を提供する。レビューは、後工程のテストより早く安価に欠陥を見つける手段になり得る。

5.1 一般的なチェックリストの使い方

チェックリストは、見落としを減らし、属人的なレビューを避け、品質特性・文書種別・リスクレベル・テスト技法に合わせて調整するために使う。チェックリストにない問題の議論を妨げてはいけない。

5.2 要件レビューで確認する項目

• 出どころ（人・部署）が明確か。
• テスト可能か。
• 優先順位があるか。
• 受け入れ基準があるか。
• ユースケースの呼び出し構造が利用可能か。
• 一意な識別子とバージョンがあるか。
• ビジネス／マーケティング要件からのトレーサビリティがあるか。
• 要件・ユースケース・ユーザーストーリー間のトレーサビリティがあるか。
• 用語が一貫しているか。

「非常にユーザーフレンドリー」のような曖昧な要件は、合否判断ができずテスト不能である。「標準文書の版 xxx に適合する」のように、判定基準と参照が明確である必要がある。「24 時間 365 日、可用性 100%」のように現実的に測定できない要件も、テスト可能性を検討する。

5.3 ユースケースレビュー

• メインフローは明確か。
• 代替フローはすべて識別され、エラー処理が十分か。
• UI メッセージは定義されているか。
• メインフローが複数混在していないか。複数ならユースケース分割を検討する。
• 各振る舞いがテスト可能か。

5.4 ユーザーストーリーレビュー

• 対象イテレーション／スプリントに適切か。
• 要求者・ユーザーの観点で書かれているか。
• 受け入れ基準が定義され、テスト可能か。
• フィーチャーが明確で他と区別できるか。
• 他のストーリーから独立しているか。
• 優先度が付いているか。
• 一般的な形式に従っているか。

一般形：<ユーザーの種類>として、<あるゴール>をしたい。なぜなら<ある理由>だから。

5.5 チェックリストの調整軸

組織のポリシー・標準・法律、プロジェクトの重点・技術・リスク、作業成果物の種類、リスクレベル、使用するテスト技法に合わせる。標準チェックリストと組織固有チェックリストを組み合わせるとよい。

第 6 章 テストツールおよび自動化

6.1 キーワード駆動テスト

キーワード（アクションワード）は、注文取消しなど、ビジネス・システムのハイレベルな相互作用を表す。キーワードとデータの列がテストケースになり、テスト自動化側がキーワードを実行可能スクリプトへマッピングする。

つまり、テストケースを細かな「操作手順」ではなく、意味のある操作名（キーワード）の列として記述し、そのキーワードを自動化スクリプトが実行する方法である。例えば、注文キャンセルなら次のように書く。

Login → SearchOrder → CancelOrder → VerifyOrderStatus

各キーワードの内部では、画面操作や API 呼び出しなどの詳細を自動化担当が実装する。画面の変更時も、テストケースの業務シナリオではなく、該当キーワードの実装を修正すればよい。このように、テストケースの記述と自動化実装を分離できることが「キーワード駆動」のポイントである。

flowchart LR
    A[テストアナリスト] -->|キーワード・テストデータ| B[キーワード列]
    B --> C[自動化スクリプト]
    C --> D[テスト対象]
    D --> E[実結果]
    F[期待結果] --> G[比較・分析]
    E --> G
    G --> H{故障?}
    H -- いいえ --> I[結果記録]
    H -- はい --> J[手動再実行・原因切り分け]
    J --> K[アプリ / データ / キーワード / スクリプトの判定]

役割分担

• テストアナリスト：ビジネスプロセス、キーワード、データ、期待結果を作成・保守し、実行結果を分析する。
• テスト自動化エンジニア／テクニカルテストアナリスト：キーワードを実装するモジュール化スクリプトを作る。
• 開発者：必要に応じて技術的な原因分析・修正を支援する。

利点

• ドメイン専門家がコードを理解せずにケースを仕様化できる。
• テストケース仕様と実装を分離できる。
• モジュール化により変更時の保守性が高い。
• ドメインの知識を自動化へ反映しやすい。

故障時の切り分け

1. 同じデータ・同じケースを手動で実行する。
2. 手動でも失敗するなら、アプリケーション欠陥の可能性を調べる。
3. 手動では再現しないなら、キーワード、テストデータ、スクリプトを確認する。
4. 先行手順が誤ったデータを投入し、後続で故障として現れていないか確認する。
5. 判定できなければ、証跡を添えて自動化担当者・開発者へ渡す。

6.2 ツールの種類

自動実行の投資効果は、繰り返し実行するリグレッションテストで高くなりやすい。スモークテストや CI でのビルド評価にも有効だが、保守コストを考慮する。

重要な比較