アジャイルプロジェクトの技法

JSTQB アジャイルテスト担当者シラバス（2014年版）の「3.3 アジャイルプロジェクトの技法」について、実務に役立つ主要なポイントを整理します。

受け入れ基準と完了（Done）の定義

アジャイルプロジェクトでは、ユーザーストーリーや品質リスク、過去の経験などをテストベースとして活用します [cite: 1]。テストを確実なものにするため、詳細な受け入れ基準と「完了（Done）」の共通認識が不可欠です。

受け入れ基準で考慮すべき項目

テスト可能にするために、以下のトピックを考慮して基準を定義します。

• 機能的振る舞い: ユーザ操作に対する外見上の動き。
• 品質特性: 性能、信頼性、使用性などの非機能要件。
• シナリオ: 特定の目標を達成するための一連のアクション。
• ビジネスルール: システム外の手順や制約に基づく条件。
• 外部インターフェース/制約: 他システムとの接続や物理的・設計上の制限。

各レベルの完了（Done）基準の例

レベル	主な完了基準（例）
ユニットテスト	100%のデシジョンカバレッジ、静的解析の実行、重大な欠陥なし。
システムテスト	E2Eでのテスト完了、全品質特性のカバー、本番相当環境での実施。
リリース	全テストベース要素のカバレッジ確保、残存リスクが許容範囲内であること。

受け入れテスト駆動開発（ATDD）の活用

ATDDは、ストーリーの実装前に開発者、テスト担当者、ビジネス代表者が協調してテストを作成する「テストファースト」のアプローチです。

1. 仕様ワークショップ: 三者でストーリーを分析・検討し、曖昧さを解消します。
2. 代表例の作成: ストーリーを正しく実装するための具体的なテスト（例）を作成します。
3. テストの拡充: 正常系（期待通りの動作）から開始し、異常系や非機能属性（性能など）へと広げます。

ブラックボックステスト設計技法の適用

アジャイルでも従来のブラックボックステスト設計技法は非常に有効であり、開発と並行して適用されます。

• 適用される主な技法: 同値分割法、境界値分析、デシジョンテーブル、状態遷移テストなど。
• 対象: 機能面だけでなく、性能や信頼性などの非機能要件のユーザストーリーに対しても適用可能です。

探索的テストの実践

時間が限られ、仕様が詳細に記述されないアジャイルでは、探索的テストが極めて重要です。これは設計と実行を同時に行うアプローチです。

• テストチャータ: 「アクター」「目的（テスト条件）」「セットアップ」「活動」など、テストセッションの指針を定義します。
• セッションベースドマネジメント: 中断のない60〜120分のセッションで実施し、結果に基づいて次のテストを決定します。
• ヒューリスティック: 「CRUD（作成・読み取り・更新・削除）」や「境界」「中断」などの経験則を活用して問題を発見します。