あなたのテストの盲点はどこにある？〜テスト駆動開発をやめて、なお残すべき習慣とは(3)
テストの複数の視点を使って盲点を探して対処せよ！！
前回、スタブ・モックの使いどころの再考について触れました。そのなかで、ユニットテストのみに頼るのは、盲点が生まれるという点を指摘しました。「群盲象を評す」という寓話があります。各々の盲目の人が象の一部を触って象を語るだけでは部分でしかありませんし、盲点も消えません。
象の部分を統合して初めて全体を語れるように、一つの視点では盲点ができてしまいますが、複数の視点があればそれを防ぐことができます。
今回は、アジャイルテストの４象限を使って、テスト観点の全体像をお伝えし、次回では多重のフィードバックループについて盲点を少なくする仕組みについて解説します。
テスト駆動開発のスタイルをやめたとしても、自分たちが作り続けているプロダクトが期待通り動き続け、プロダクトがユーザや市場によりフィットしていくようにするには、複数の観点でテストし続けることは欠かせません。
アジャイルテスト４象限
上の図は、実践アジャイルテスト(AgileTesting)や More Agile Testingのなかで紹介されアジャイルテストの4象限と呼ばれ、よく引用されます。テスト計画を立て実施するときや、現状のテスト活動の重大な抜け漏れを発見するのに役立つ図です。
アジャイルテストの4象限のテストを実現するには、テスターのロールだけでは不十分で、開発者、ビジネスに詳しい人との多様な専門家が協力し、継続して活動に取り組むことが欠かせません。
開発を支援するQ1Q2の活動
左右に分割した左側が開発を支援するテストになります。一部はUnit TestsやStory Tests（≒End2Endのテスト）などをテストの自動化をすすめ、CIで頻繁にデグレが起こってないかを確認します。CIなどでテスト失敗を早期に発見できれば、小さい変更差分にフォーカスし問題箇所を早期に特定し対処できます。また、自動テストがリファクタリングの活動の支えとなります。
Q2
左上のQ2の活動はいくつかありますが代表格が、Acceptance TDD、 Behavior Driven Development、Specification By Exampleでビジネス面を強調します。開発者、テスター、ビジネスに詳しい人の3者のロールが協力して、3者が理解できる言葉（≒ユビキタス言語）で、Story Tests（≒Specification By Example：仕様の具体例）を明瞭化し、コンピュータを使って期待通り動作したか否かを評価でできるように自動化（≒Executable Specification：実行可能な仕様）し、頻繁に確認します。
エクストリームプログラミングを積極的に推進している場合は、優先順位の高いユーザストーリーを、Story Testsを使って内容を具体化し、ストーリーが完成したか否かの判断に使われます。Acceptance TDDのネーミングでわかるように、人によってはQ2の活動もTDDの範囲内と捉えています。
ビジネスも採用技術要素も複雑なプロダクトの場合、Q2ですべてのテストをカバーしようとなると実行に時間がかかったり、ちょっとした変更で壊れる脆いテストになったり、問題箇所の特定が難しいなど問題を抱えることがあります。適切な要素に分割してQ1で確認できること増やす作戦も必要です。
筆者自身は、Q2の活動が弱いために仕様を的確に捉えられないまま、Q1のユニットテストやテスト結合テストの自動テストに注力した経験があります。その結果、盲点が生まれ、あとで重大な抜け漏れを発見して、慌てて作業するという苦い経験をしました。あのときは焦った(汗)
Q1
左下のQ1の代表格が、ユニットレベルのTDDやユニットテストや結合テストでできるだけ自動化していきます。Q2のビジネスで実現したいことの支えとなる、個々のユニットやコンポーネントが期待通り動作するか？どんな構成要素であるべきか？という点を、Q1の活動ではフォーカスします。
もし、Q1レベルで個々の要素が期待通り動かないのであれば、Q2のレベルの組み合わせで期待通り動作することはないでしょう。
ストーリーを実現するために必要なオープンソースライブラリーのテストコードを使って、テストが十分にされているかで採用基準としたり、テストの書き方やライブラリーの使い方を学ぶことができます。開発中にライブラリーのバグを発見した場合、テストコードと共に修正をPull Requestすることもあるでしょう。
Q1はビジネス面よりもテクノロジ面を強調しますが、前回のヘキサゴナルの中心ドメインに対するテストは、ビジネス面を強調し、Q2側に２歩３歩近づきます。ただしEnd2Endのテストと違って、エンドユーザが直接観て触って確認できるものをテストしているわけではありませんし、外部サービスと連携してテストしているわけでもありません。
プロダクトを評価するQ3Q4の活動
開発者主導のテストだとQ1やQ2にフォーカスしがちですが、右側のプロダクトの評価にフォーカスしたテストも欠かせません。右側は左側と比較し、CIを使って頻繁に自動実行ができない項目が増えてきます。
Q3
ユーザビリティテスト、探索的テストがQ3の代表格です。ユーザビリティテストは、ユーザがプロダクトを利用している様子の行動観察や言動を記録し、プロダクトの直すべきところを明らかにします。探索的テストは、決められたスクリプト手順に従ってテストするのではなく、プロダクトに対して様々な入出力を試行錯誤し、重大な欠陥を発見に注力します。期待通り動作することを確認することよりも、どうやれば壊れて損害が出てしまうのかに注力し仮説を立て実験を繰り返すのが特徴的です。
Q1、Q2を継続的に実施して開発できていれば、テスターはQ3のテストの時間を割け、プロダクトをより磨き上げることが可能になります。
筆者自身、そのときは正式なユーザビリティテストではなかったのですが、実ユーザに自分が関わったプロダクトをじっくり使ってもらうシーンに同席する機会が何度かありました。そのたびに、実ユーザが操作に迷っている行動を目撃したり、「え？どう使うの？わらない！」の苛立ちの感情の言葉を耳にしたり、「これは出来ないの？」と私が思いもしなかったニーズを語ってくれたりと、多くのフィードバックを得ることがありました。
よりリアルなユーザ目線のニーズを獲得するには、インタビュー、ジャーニマップ作成やペルソナモデル作成だけでは不十分で、プロダクトを使った実験を繰り返し獲得してくことが欠かせません。
Q4
ユーザストーリーの機能要件ばかりだけでなく、非機能要件も気を配る必要があります。セキュリティテスト、パフォーマンステスト、などなど…。
開発に不慣れなビジネス側であれば、非機能要件の観点が抜け落ちがちなので、テスターや開発者から積極的にプランニング時やテスト計画などのタイミングで働きかける必要があるでしょう。
まとめ
アジャイルテスト４象限を紹介しました。今のプロジェクトで盲点となっている箇所、欠けているテストはありましたでしょうか？TDDという形でテストを行わずとも、アジャイルテスト４象限の視点を持ち、盲点が生まれないように、各象限のテストを続ける必要があります。TDDの範囲はせいぜいQ1、Q2の一部です。
ユーザストーリー（バックログアイテム）の内容が曖昧で完了条件が不明瞭であれば、Q2のAcceptance TDD、BDD、Specification by Exampleの活動をお勧めします。
実装の個々の要素の境界が曖昧だったり、問題箇所の特定等に困っているのであれば、Q1の活動がお勧めです。
プロダクトが市場に受け入れられるようにするには、自動化が難しいQ3の活動も欠かせません。Q4も忘れずに。
次回は、TDDのアイデアのコアの部分となる、多重のフィードバックループについて解説します。
