私がアジャイルテストについて学んだことの多くは、Janet GregoryとLisa Crispinの著書「実践アジャイルテスト」から得たものです。この本や他の多くの本から学んだテクニックや考え方を、何年も前から自分のチームで実践してきました。この本が日本語に翻訳されたことで、多くの人がJanet GregoryとLisa Crispinの知恵に簡単にアクセスできるようになったことをとても嬉しく思います。今回は、この本から一つの考え方を紹介します： 「アジャイルテストの４象限」です。「アジャイルテストの４象限」とは何か、そして有効性を高めて、顧客が満足できる優れたプロダクトを開発できるようにスクラムチームがどのようにして生かせるかを説明します。
ソフトウェア品質には多くの側面があり、それぞれに異なるテストアプローチが必要です。何をもって「テストが終わった」と言えるのか？各テストの目的は何か？このモデルはソフトウエアプロダクト開発チームがこのような質問に答えられるようになるためのツールです。各象限を説明します。
- 第1象限（左下）は、技術に焦点を当てて、チームを支援する・導くテスト活動になります。単体テスト、コンポネントテストやシンプルな結合テストが含まれます。テスト駆動開発（TDD）によって作成される時もあります。第1象限のテストは基本的に自動化する必要があります。
単体テストは「プログラマーテスト」と呼ばれることがあります。Kent Beckによると、「プログラマーがコードの内部品質を測定する」（Extreme Programming Explained）ためのものです。 - 第2象限（左上）は、ビジネスに焦点を当てて、またチームを導くことを目的としています。機能テスト、ストーリーテスト、プロトタイプなどが含まれます。
これらのテストは、第1象限からのテストと部分的に重複することもありますが、プロダクトやシステム全体の動作により重点を置いています。場合によって、受け入れテスト駆動開発（ATDD）によって作成されます。
私の経験では、この象限は最もよく理解されている象限かもしれません。多くのアジャイルチームがこの象限に多くの時間を費やし、これらのテストを自動化し、早期に、頻繁に実行することの重要性を理解しています。 - 第3象限（右上）は、プロダクトを批評することにビジネスに焦点が当てられています。これらのテストは主に手動で実行されます。用意されたテストシナリオに従うか、探索的アプローチで実行されます。第3象限に属するテストは、チームのメンバー以外の方がかかわることがあります。
第3象限を活用して、スクラムチームがプロダクトやユーザーが求めているものに関する仮説を検証します。優れた開発チームは例えば6ヶ月に1回のUATフェーズでは満足しません。リスクを最小化するために、このようなテストを早期に、そして頻繁に行います。スクラムチームがスプリントごとに完成したインクリメントを作成する大きい理由の１つは、このような検証を行うためです。 - 第4象限（右下）は、技術に焦点を当てて、プロダクトの非機能的な側面を批評するものです。プロダクトの反応のスピード・パフォーマンスはどれくらいあるか？高負荷の時サーバーなどは落ちないか？を検証します。
コンプライアンス、セキュリティ、安全性、その他の「○○性」テストも含まれています。第4象限に位置するテストは、通常、様々なツールのサポートを得て実行されます。
これらのテストも、残念ながら実行される頻度が低すぎたり、遅すぎたりすることが多いのです。開発するプロダクトによっては、非機能要件がプロダクトのコアな競合上の優位性になることがあります。第4象限のテストを自動化し、CI/CDパイプラインの一部として実行しないチームは、大きなリスクを負っています。
第1象限と第2象限は、プロダクトが仕様や要件に適合しているかどうかの検証に焦点を当てます。
第3象限と第4象限は、プロダクトが目的に合っているかどうかの検証に焦点を当てます。
考える順番、重要性など、Q1・Q2・Q3・Q4にはその意味が特に含まれていません。Q2は、すべてのプロジェクトが始まるべき象限だと思われるかもしれませんが、必ずしもそうではありません。例えば、あるプロジェクトでは、顧客が要件について不確実であったため、探索的テスト（Q3）から始めました。また、プロダクトの最大のリスクであり未知の部分がパフォーマンスであれば、まずパフォーマンスを先にテストする（Q4）必要があるかもしれません。
このモデルはある意味で世の中に既にあったプラクティスを整理しているだけだと思われるかもしれませんが、強力なコミュニケーションツールだと思っています。なぜテストをするのでしょうか？その答えは明白に見えるかもしれませんが、実はかなり複雑です。「ビジネス面」と「技術面」、そして「チームを支援するためのテスト」と「プロダクトを批評するためのテスト」と言う二次元で構成されていることで、各テストに明確な目的を持たせています。テストを考える際に、目的を明確にすることで集中もでき、無駄のリスクも制限されると思います。また、チームの状況やニーズに合わせてモデルをアレンジすることもOKです。 実際、上記の図には複数のバージョンが存在する。「静的コード解析はQ1に加えるべきではないか？」や「私たちが普段やっている"アルファ&ベタテスト"はどこに属するのか？」など、このような議論をチーム内で実行すると面白いと思います。加えて、「アジャイルテストの4象限」は、テスターの役割だけでは品質を確保できず、開発者、SME、各種専門家の協力が必要であることを気づかせてくれます。また、自動化できるところはどんどん自動化していかないと回らないということも再認識させられます。
スクラムのフレームワークの中で、具体的に以下のような様々な方法・タイミングで適用することができます。
- チームの「完成の定義」とCI/CDパイプライン（内容や構造）を定義し、継続的に検査・適応させる際に。
- ユーザーがインクリメントに満足しなかった時、バグが発生した時、様々な問題の原因を特定し、二度同じことが再発しないように対策を考える際に。
- チームが新しいプロダクトバックログアイテムの開発に着手し、どのようにしてテストを進めていくかを話し合う際に。
アジャイル開発を支援するテストの進め方に関してもっと詳しく知りたいという方には、以下をお勧めします。
- 「実践アジャイルテスト」を読む。
- Janet GregoryとLisa Crispinの次の本を読む：「More Agile Testing」(残念ながら英語版のみ)
- アジャイルテストやソフトウェア品質に関する以下のような本を読んでみる。
- Specification by Example（Gojko Adzic）
- ATDD by Example（Markus Gartner）
- 品質重視のアジャイル開発（誉田 直美）
- 継続的デリバリー（Jez Humble 、David Farley）
- 「Agile Testing Night」のような実践者のコミュニティに参加する。
- 受け入れテスト駆動開発、ビヘイビア駆動開発、実例による仕様（SBE）、探索的テスト、コラボレーションのテクニックをカバーする、アゴラックス（弊社）とYamanecoが提供している2日間のアジャイルテスト研修を受けてみる。