これは何？
いわゆる「アジャイルテストの４象限」について、なんか見たことあるけどまともに使ってないなーという人も多いので
どうやって使うと有効なのか？という私見をまとめてみようと思います。
あくまで私見なので、違うんじゃない？というところがあればコメントとか修正依頼貰えればと思います。
アジャイル開発におけるテストの悩み
アジャイル開発を行う上で、どのようにテストを進めるか、どんな種類のテストをどんな順番で行うか？というのは良く悩むポイントだと思います。
特にこれまでウォーターフォールの開発をしていた人にとっては、どうしても「単体テスト」とか「結合テスト」といったテストレベルの順序が気になってしまい、そうしたテストの順序を明示した結果、ミニウォーターフォールをスプリントの中に埋め込むような開発をしてしまうということがあります。そうすると開発のアジリティが発揮できず、スコープの見直しが必要となってしまい、リリースが遅延する。というあまり良くない事態を引き起こしかねません。では、どうやってアジャイル開発でのテストを考えればいいのでしょうか？
その際に使えるのが「アジャイルテストの４象限」です。
そもそもウォーターフォールのテストレベルはどうやって決まっていたか？
さて、アジャイル開発におけるテストの話を始める前に、ウォーターフォールでどうやってテストレベルを決めていたか？を考えましょう。
ウォーターフォール開発の場合、多くはVモデルの考え方を中心としてテストレベルを決めていたと思います。
Vモデルでは、要求分析から各設計工程に渡る上流の流れに水平対応するようにテストレベルが設定されています。
- 要求分析に対して、受け入れテスト
- 機能設計に対して、結合テスト
といった形です。
そうすることで、大きく2つのメリットを享受できていたと思います。
- 全ての設計プロセスに対応してテストプロセスが設定されるため、設計に対するテストの漏れを産みにくい。
- 上流工程は段階的に詳細化されていくので、それを駆け上がるテストプロセスは小さな粒度からテストされていくことができ、実行コストの小さなテストで多くのバグを早期に見つけるというアプローチが体現しやすい。
一方、当然ですがデメリットも存在します。
- 上流工程と下流工程を水平対向させることでテストプロセスを検討することが必ずしも効率的とはいえない。
- 特に、過剰にテストプロセスが分割されてしまうことで分割損が発生したり、プロセス間の品質管理やQuality Gateが重荷になってしまう可能性が高い。
- 上流工程との対応ばかり意識してしまい、「何をいつ、どうやってテストするか？」ということが見失われることがある。
Vモデル自体は優れた考え方ではあると思いますが、デメリットにもしっかりと向きあって活用する必要があります。
特にアジャイル開発においてはデメリットの1点目は看過することができず、短期間の開発の中で非効率なアプローチを採用することは、致命的な問題になりかねません。
そもそも、スクラム開発などで1スプリントの中のタスクを工程に分割することは稀なので、水平対向させるという考え方自体が通用しにくいのですが。
アジャイルテストの4象限を使う
そこで、アジャイルテストの4象限の出番です。
アジャイルテストの4象限は、Vモデルと違って上流工程との対応などでテストを考えません。
「ビジネス面のテストか？技術面のテストか？」、「製品を批評するためのテストか？チームを支援するためのテストか？」という区分けで、テストを考えます。
具体的には下図のようになります。
（※図中太字のxxに対するテストという文言はわかりやすくするためにつけてみたものなのであまり意識しなくてもよいです）
こうして4象限に分けて考えることにより、上流工程の形に依存することなく、必要なテストについて考えることができます。
例えば第1象限(Q1)について、「自分たちのチームは技術者に向けて支援するようなテストって出来てるかな？」と考えたり
「技術者を支援するためのテストはDevチーム自らでやろう！」とか検討することができます。
同様に、第3象限(Q3)について、「ビジネス成果を出すことができるか？という観点で製品を批評するようなことって出来てるかな？」と考えてみることができます。
スクラムチームを立ち上げる際では、こうした4象限を使って
どのロールの人が、どの象限のテストに対して責任を持つか？と考えてあげるのもよいですし
doneの定義を行う上で、各象限について考えてみるのもよいでしょう。
例えば私の場合は
- 第1象限のテストは、スプリント内でDevチームが実施する。
- 第2象限のテストは、スプリントレビューまでにPOが実施する(ないしはユーザーにテストさせる)。
- 第3象限のテストは、スプリント外の活動として、独立したQA組織が行う。
- 第4象限のテストは、細分化した上でDevチームとQA組織で実施する。
といった形でプランニングしていました。
（当然左側のテストは自動化を前提とします。）
あくまで例であって、例えば第2象限のテストをPOだけでやるのは無理だよーといったことは当然あると思うので注意しましょう。
というより、本質的には開発に携わる全員が全ての象限に責任を持つべきだと思いますし。
で、既に立ち上がっているスクラムチームであれば
レトロスペクティブの際にチェックしてみたり、自分たちの開発をより良いものにするためのヌケモレチェックとして使うとよいでしょう。
また問題が起きた際に、どの象限のテストを改善すればよいか？といった見方もできると思います。
注意したいのは、アジャイルテストの象限は、テストプロセス自体や、その順序を示しているわけではないということです。
そもそも、ソフトウェアを作ることと、テストをすることを分割してしまうのがよくないです。
doneの定義次第かもしれませんが、そもそも作ることとテストをすることは、多くの場合で分割不可避な一体の活動です。
コードを書いた事があればわかると思いますが、Unit Testをする前に1度も動作確認することなく
最後の1行/1文字までコーディングするなんてことはありえませんよね？
ましてやTDDのように、プロダクトのコードよりも先にテストコードを作成することもありますよね。
少なくともプロダクトの開発において、モノを作るという行為はテストをすることまで含めて「作る」「開発する」ということです。
「作ること」と「テストする」ということを完全に分割できる。という前提で物事を考えるのは、少なくともアジャイル開発においては不向きと思います。
どこまでテストすることによって「何を」「作った」とするのか、そういったことも、このアジャイルテストの4象限と共に考えていくべきでしょう。
- 「コード」を「作った」というのは、どのテストまで含めているのか？
- 「新機能」を「作った」というのは、どのテストまで含めているのか？
- 「プロダクト」を「作った」というのは、どのテストまで含めているのか？
- 「サービス」を「作った」というのは、どのテストまで含めているのか？
- 「バグ」を「修正した」というのは、どのテストまで含めているのか？
さて、今回はアジャイルテストの4象限について
自分なりの使い方をまとめてみました。
ここ違うんじゃねー？的なことはままありそうな記事なので、そういうときはツッコミがもらえるとよりよい活用が生まれるかなと思うので
もしあればよろしくお願いします。