従来型テストとアジャイルテストの違い

JSTQB アジャイルテスト担当者シラバスに基づき、従来型のライフサイクル（V字モデルなど）とアジャイル開発におけるテストの根本的な違いを整理します。

従来型とアジャイルの主な相違点

アジャイルモデルは、テスト活動の統合方法、成果物、テストレベル、ツールの使用、および独立性の活用方法において従来のモデルと異なります。

テスト活動と開発活動の統合

アジャイルでは、極めて短いイテレーション内で価値あるソフトウェアをデリバリーします。

• 並行・重複する活動: 開発、統合、テストの各活動は並行して実行されます。
• 継続的なテスト: テストは開発の最後に行う「フェーズ」ではなく、イテレーション全体を通して行われる活動です。
• 全員参加: 開発者はユニットテストを行い、テスト担当者はフィーチャをテストし、ビジネス側も迅速なフィードバックのために随時テストを行います。
• 自動化の重視: 変更が頻繁に発生するため、すべてのテストレベルでテスト自動化を多用することが一般的です。

プロジェクト成果物の軽量化

アジャイルプロジェクトでは顧客価値を生まない過剰なドキュメントを避け、動くソフトウェアと自動テストを重視します。成果物は主に3つに分類されます。

分類	内容	例
ビジネス指向	システムに何が必要か、どう使うかを記述	ユーザストーリー、受け入れ基準
開発成果物	システムの構築方法や評価を記述	コード、自動ユニットテスト
テスト成果物	テスト方法や結果を記述	テスト戦略、自動テスト、テストダッシュボード

テストレベルと構成管理

テストレベルは独立したステップではなく、互いに重なり合いながら進みます。

• レベルの重なり: ユニットテスト、フィーチャ検証（自動）、フィーチャ妥当性確認（手動）がイテレーション内で繰り返されます。
• CIの活用: 自動化ツールと継続的インテグレーション（CI）を活用し、コード変更のたびにビルドとテストを繰り返し実行します。
• 回帰リスクの管理: 頻繁な変更によるデグレードを防ぐため、統合およびシステムレベルでも自動テストが不可欠です。

独立したテストに関する組織上の選択肢

テスト担当者の独立性をどのように確保するかについては、主に以下の3つのアプローチがあります。

1. チーム内への配置: 開発者と密接に協力できるが、客観性を失うリスクがあります。
2. 完全に独立したチーム: スプリントの終盤にのみテストを行う形態ですが、情報の欠落や人間関係の問題が起きやすくなります。
3. ハイブリッド形式: 独立したテストチームに所属しつつ、特定のテスト担当者をアジャイルチームに長期アサインする方法で、独立性とプロダクト理解を両立できます。