アジャイルで進めるプロジェクトにおいて、どこまで各スプリントでテストを実施しておくべきかというのは、どのプロジェクトにおいても頭を悩ませる話題でした。

スクラムガイドからの読み取り

スクラムガイドを参照すると、以下のことがわかります。

まず、スクラムチームは、スプリントごとにインクリメントを作成する責任があります。

スクラムチーム全体が、スプリントごとに価値のある有⽤なインクリメントを作成する責任を持つ。

インクリメントというのは「完成の定義」(Doneの定義)を満たしたものです。

完成の定義を満たさない限り、作業をインクリメントの⼀部と⾒なすことはできない。

そして「完成の定義」にはプロダクトの品質基準が書かれています。

完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を⽰した正式な記述である。

したがって自然な読み取り方をすれば、プロダクトの品質基準を満たすインクリメントを毎スプリント作成することが望ましいでしょう。また、言い換えれば、毎スプリントで「出荷可能」な状態を維持すべきでもあります。

毎スプリント出荷可能にするための負荷

これはチームで定める「完成の定義」にも依るところですが、毎スプリントで出荷可能であることを確認するためには、毎スプリント一定のテストを行う必要があります。理想的にはユニットテストだけでなく、CIでE2Eやパフォーマンステスト、セキュリティテストまで行っておけば良いですね。

しかし、これは理想であって、現実を理想に近づけることは、一足飛びにはできません。アジャイルは市場へ早期に価値を届けることを説き、プロダクトの1st.リリースだけを考えると、この考え方は自動テストの整備負荷と相反します。どのスプリントでも十分なテストを実施しようとすると、それはフィーチャーを開発する時間を圧迫することになるでしょう。

では、各プロジェクトでこの問題にどう向かい合うべきなのでしょうか。もちろん、アジャイルを適用するような分野において「どのプロジェクトでもそうしておけば良い」というカーゴ・カルトは存在しませんが、何らかの方針をつけておきたい。

wikipedia:Cynefin frameworkより引用。

アジャイルテストの四象限

調べていると行き着いたのが、アジャイルテストの四象限。

「何を」「どのように」テストするのか？――アジャイル開発におけるテストの基本戦略より引用。

この四象限は、アジャイルなプロジェクトで行われるテストを4つに分類したものです。象限は左下、左上、右上、右下という順で番号づけがされますが、以下のように整理されます。

Q1: 開発を導く技術面のテスト
Q2: 開発を導くビジネス面のテスト
Q3: プロダクトを評価するビジネス面のテスト
Q4: プロダクトを評価する技術面のテスト

「開発を導く」と銘打った左側の象限は、コーディング時の不具合を避けるためのもの(preventing defects before and during coding)です。「プロダクトを評価する」という右側の象限は、プロダクトとして必要な機能が存在しなかったり、それがないとビジネスが成立しないといった点を確認するものになります。

すべてを自動化できれば一番良いですが、現実的な自動化の優先度としては「開発を導く」左側の象限が優先になるでしょう。ある種、開発をスピードアップするためのテストであるためです。第3、第4象限のテストを後回しにすべきではありません。ただ、毎スプリント実施する優先度は下がると考えています。これは、プロダクト全体の評価は、ある程度「プロダクト」が仕上がった状態でないとできないためです。