シリーズAの締めくくりに
第1回では「スプリントが終わってもテストが終わらない」原因として、開発とテストのチーム体制の分断を取り上げました。
第2回では、テスト活動の全体像を把握するためのフレームワーク「アジャイルテストの4象限」を解説しました。
第3回となる今回は、スクラムの5つのイベントそれぞれにテストを融合する実践的な方法を紹介します。課題の理解とフレームワークの把握だけでは変化は起きません。「翌日のスプリントから何を変えるか」を持ち帰れる内容を目指します。
バックログリファイメント
バックログリファイメントでは、プロダクトバックログアイテムの詳細化と同時にテスト分析を行い、要件の明確化と欠陥の早期発見を目指します。この融合により、開発初期から品質向上が期待できます。
テスト条件の特定
バックログアイテムの詳細化により、必要なテスト条件やシナリオを明確にします。これにより、テストが効率的に行われ、欠陥を早期に発見できます。
具体的な問いかけ例:
- このアイテムが「正しく動いた」と判断するには何を確認すればよいか？
- どんな異常系・境界値を想定しておくべきか？
- 誰がテストするか（開発者・QA担当者・顧客）は決まっているか？
完了の定義
完了の定義にテスト要件を含めることで、テストが完了していることを保証します。これにより、テストの質が向上し、開発プロセス全体の信頼性が高まります。
「コードを書き終えた」と「テストまで完了した」は異なります。完了の定義にテストを明示することで、「完了」の認識がチーム全体で一致します。
スプリントプランニング
スプリントプランニングでは、テスト計画を策定し、テストのリソースや時間を確保して、開発とテストの連携を図ります。この融合により、スムーズなテスト実行が実現し、予期せぬ問題を防ぐことができます。
テスト計画の策定
テスト対象、範囲、環境、リスク分析などを含む計画を作成します。これにより、テストが計画的に行われ、リスクを最小限に抑えることができます。
スプリントプランニングで確認しておきたいこと:
- 今スプリントで何をテストするかの優先順位はチーム全体で合意できているか？
- テスト環境は準備されているか、依存関係はないか？
- リスクが高いアイテムはどれで、どのテストアプローチを取るか？
リソースと時間の確保
テストリソースや時間を確保し、スムーズなテスト実行を支援します。これにより、テストが効率的に行われ、開発とテストの連携が強化されます。
「テストはスプリントの最後にまとめてやる」という仕組みのままでは、後半にテストが積み上がる状況は変わりません。スプリントプランニングの段階でテストにかける時間を見積もりに含めることが出発点です。
スプリント
スプリント期間中にテスト設計、実装、実行を行い、継続的なフィードバックを得て迅速な修正と改善を行います。この融合により、開発とテストが一体となり、品質保証がスムーズに行えます。
連携したテスト実行
開発者が新しい機能を実装するたびに、QA担当者が即座にテストを実行します。これにより、欠陥が早期に発見され、迅速に修正されます。
「実装完了 → テスト依頼 → テスト実行」というバトンリレー形式から、「実装と並行してテスト設計、完了後に即テスト実行」という形に変えることで、スプリント内でのフィードバックサイクルが速くなります。
継続的なフィードバック
QA担当者が発見した不具合を迅速に開発者にフィードバックし、修正を促します。これにより、開発とテストの連携が強化され、品質監視が向上します。
不具合の報告が「チケット起票→担当者アサイン→確認」というプロセスを経るほど、修正のコストと時間が増えます。スプリント中は口頭・チャット・ペアでの即時フィードバックを優先することで、手戻りを最小化できます。
デイリースクラム
デイリースクラムで進捗状況を共有し、テストの進捗や課題を早期に把握して迅速に対応します。この融合により、チーム全体が常に最新の状況を把握し、迅速な問題解決が可能です。
進捗と課題の把握
毎日のミーティングで状況を確認し、対応策を迅速に実行します。これにより、問題が早期に発見され、迅速に解決されます。
デイリースクラムにテストの観点を加えるための問いかけ:
- テスト待ちのアイテムが積み上がっていないか？
- テスト中に新たな懸念事項が見つかっていないか？
- スプリントゴールに向けてテストの進捗はどうか？
障害対応
問題が発生した際に、即時に対処して解決します。これにより、チーム全体が迅速に対応し、品質保証が向上します。
テスト中に発見された問題がスプリントゴールに影響するなら、デイリースクラムで即座に共有し、チームで対応を決める。これがデイリースクラムとテストを融合する最大の価値です。
レトロスペクティブ
スプリント終了後に行われるレトロスペクティブでは、チーム全体で振り返りを行い、プロセスや成果物に対する評価を行います。この融合により、継続的なテストプロセス改善と品質向上が図れます。
テストプロセスの評価
テストの実行状況や効果を振り返り、成功した点や改善が必要な点を議論します。これにより、テストプロセスが継続的に改善されます。
レトロスペクティブでテストを振り返る問いかけ:
- 今スプリントでテストが遅れた場面はあったか？その原因は何か？
- 本番に出てしまった不具合はあったか？テストで防げたはずか？
- テストの仕組みとして変えられることは何か？
ベストプラクティスの導入
レトロスペクティブで議論された改善策を取り入れ、ベストプラクティスとして次のスプリントで実践します。これにより、継続的にテストプロセスが最適化され、品質が向上します。
「良かったこと」だけでなく「テストの観点で改善すべきこと」を毎スプリント1つ特定し、次スプリントで実践する——このサイクルを続けることが、チーム全体で品質文化を醸成していく仕組みになります。
スクラムを通じた品質文化の醸成
5つのイベントにテストを融合することは、テスト担当者だけが変わることではありません。開発者がバックログリファイメントでテスト条件を考え、スプリントプランニングでテスト時間を見積もり、デイリースクラムでテストの状況を共有する——チーム全体がテストを「誰かがやること」から「私たちが一緒にやること」として受け取るプロセスです。
最初から5つすべてを変える必要はありません。「まずレトロスペクティブでテストの振り返りを1つ加える」という小さな一歩から始めることができます。
スクラムテスティングとは、テスト活動をスクラムのリズムに乗せることで、品質への関心がチーム全体に広がっていく仕組みです。
まとめ
スクラムの5つのイベントにテストを融合することで、品質保証がスプリント全体を通じて行われる状態になります。
- バックログリファイメント: テスト条件の特定と完了の定義への組み込み
- スプリントプランニング: テスト計画の策定とリソース・時間の確保
- スプリント: 開発と並行した連携テスト実行と継続的なフィードバック
- デイリースクラム: テストの進捗・課題の共有と障害への即時対応
- レトロスペクティブ: テストプロセスの評価とベストプラクティスの導入
シリーズA「スクラムテスティング」は今回で完結です。
第1回（分断の問題）→ 第2回（4象限の全体像）→ 第3回（実践）と、課題から理論、実践まで一気通貫でお届けしました。