アジャイルテストにおけるTesting Manifestについて自分なりに考えてみる
はじめに
アジャイルテストには"Testing Manifest"というものが存在します。
詳しくは以下のブロッコリーさんのブログ＆紹介されている書籍をご覧ください。
これらはRegistered Agile Testing研修というScrum Inc.のトレーニングでも扱われています。
この記事ではそれを引用します。(内容としては同等です)
最後にテストするよりもずっとテストし続ける
Testing throughout over testing at the end
バグの発見よりもバグの防止
Preventing Bugs over finding Bugs
機能性をチェックするよりもチームが理解している価値をテストする
Testing Understanding over checking functionality
システムを破壊するよりも最高のシステムを構築する
Building the best system over breaking the system
テスターの責任よりもテストに対するチームの責任
Team responsible for testing over tester responsible
「Scrum Inc.認定アジャイルテスティング研修 p21-22」
これらの価値観は、2025年現在、普段からテストに親しんでいる人にとって、当たり前の価値観とも言えるかなと思います。
一方で、これらを見ても、今１つどういう背景なのか十分に理解できないという人もいると思います。
アジャイルテスティング、特にTesting Manifestはテストの専門家のためではないと私は解釈しています。
むしろ、アジャイル開発をテストの側面から語り、具体的なプラクティスを提案しているものです。
こういった理解をより進めていくことを目的として、本記事では、Testing Manifestに対する やまずん個人の解釈 を記載します。
決してアジャイルテスティングや私が所属する団体を代表するわけではありません。
私の考えを呼び水として、さまざまな背景に思いを馳せたうえで、「自分自身はどのように考え、行動すべきか？」をぜひ言語化していただければいいなと思っています。
最後にテストするよりもずっとテストし続ける
アジャイルテスティングにおける大事な概念として、継続的テストやホリスティックテストなどがあります。
上記の用語はぜひ調べてみていただきたいです。
簡単に説明すると、以下の2点が要点となると考えています。
- ソフトウェア開発は一度作って終わりではなく、さまざまなアクティビティを繰り返すループ構造を持っている
- これらのアクティビティ、あるいはすべての活動において「テスト」が必要
このマニフェストにおける「テスト」を「リリース前に確認すること」と捉えていると混乱を招いてしまいます。
もう少しテストを概念的に捉える必要があります。
例えば以下のような概念だといかがでしょうか。
「実際に目に見えるものが、チームにとって正しいか確認する活動」
そう考えると、例えば仕様やストーリー・事業計画書のレビューや本番環境での監視で「正しく動いているか」を確認することもテストと捉えることができるかもしれません。
あるいは、今のテストのアクティビティのタイミングを考えることもできます。
もっと事前に行なうには、もっと後に行なうにはどうしたらいいか、を考えることが必要かもしれません。
私個人としては、「テストをする」が大切だという単純なメッセージではないと思いました。
「テスト」という活動を通じて、今作っている我々のプロダクト・それによる価値が正しく届けられているか、そうなっているかの透明性を保ち、検査を続けるということだと思います。
もう少し概念的に捉えると「品質について常に意識を向けている」とも言えるかもしれません。
「すべてはテストだ」と主張している人もいます。
私はそれも正しいと思います。
ぜひ、自分たちのプロダクトや事業を「テスト」という側面で考えてみるといただければと思います。
バグの発見よりもバグの防止
バグは発見できるに越したことはありません。
ただ、「最初からバグを作らないようにする」というのは、コストの側面・スピードの側面でも重要です。
「アジャイルあるいはスクラムは経験主義だからバグを見つけて学べばいい」という主張もあります。
私は特定のコンテキストではそれもありだと思いますが、これを根拠なしに言ってしまうのはエンジニアリングの放棄だと考えています。
例えば、「プロトタイプを作ってみてフィードバックをしてもらう」といった場面での「フィードバック」をバグと捉えるとこれらの主張は肯定できる側面があると思います。
一方で、プロダクトとして顕在化する前に防止できるバグもあります。
例えば以下のようなものです。
- 「我々は何を作るのか」という仕様の曖昧性によるもの
- そもそもプロダクトが市場で準拠すべき法規（や規制）を調査・把握できていない
他にも設計段階での不整合や、アーキテクチャレベルでの手戻りもあるかもしれませんね。
すべてを検討し、すべてを設計するという考えでは決してありません。
しかしながら、現実問題としてバグを発見し、修正するコストが高い場合はむしろ防止することのほうが効果的です。
アジャイルだからといって、「とにかく作る」のではなく、「我々が届けたい価値をできるだけ早いタイミングで実現し届ける」が本質なのではないかと考えています。
もしこの問題について詳しく気になる方は、「品質コスト」などのキーワードも合わせて調べてみてください。
機能性をチェックするよりもチームが理解している価値をテストする
英語の原文を見ると、testingとcheckingの違いという側面もありそうですが、それは別途調べていただきたいです。
ここで記載されている内容で特筆する点は、「チームが理解している価値」(Understanding)という点だと思います。
これについての解釈は、私は「狙った品質をテストする」というふうに理解しました。
「狙った品質」とは、一般的に「顧客にとっての価値」と定義される品質に対し、「我々が仮説として考える価値」という観点で私なりに名付けた概念です。
気になった方は以下の記事をご覧ください。
テストできることは、「Unknown Knowns」としたものだけという考え方があります。
知らないことすら、知らないことをテストすることは難しいです。
これが「チームが理解している価値」という言葉に込められた限界だという認識をしています。
一方で、「機能性のチェック」とは、アジャイルにおいてよくあるテストのふるまいです。
リリースを急ぐあまり、最も考えやすい「機能性」に焦点を当て、それのみのテストで満足してしまう場合があります。
もちろんそれらはコンテキストによって許容されるべきですが、最もわかりやすい「機能性」という「Unknown Knowns」だけに飛びついてしまうのは、テストを担う人（つまり責任のある開発者）としてプロではないと思います。
チームとしてきちんと理解しているものをきちんと理解し、それが機能性では表現できないなら、何かしら表現してテストが必要かどうかを検討すべきだと考えます。
探索的テスト、あるいはContext Driven Testingという考え方
「Unknown Knowns」をテストすることについて述べましたが、一方で「Unknown Unknowns」にアプローチしうる「探索的テスト」にも触れておきます。
探索的テストはさまざまな考えを持つ人がさまざまな目的で使用するプラクティスですが、Context Driven Testingでは探索的テストというアプローチを使って特に「学習」を強調しています。
この文脈での探索的テストは、むしろ動くプロダクトからテストすべきことを学習して、次のテストに繋げるような、まさに探索的なアプローチです。
アジャイルテスティングでも探索的テストについて触れています。
しかし、"探索"をどのように行なうか、どのような位置付けで探索的テストを行なうかは、実は人によってさまざまです。
この点は今後学習してそのコンテキストに合わせた活用をしていただきたいと思います。
もし気になった方は以下も参考にしてください。
執筆時点では未発売ですが、以下の本も出版されるようです。
システムを破壊するよりも最高のシステムを構築する
これはまさにマインドセットについて述べたものだと考えます。
古くは、テストの役割を開発との対立軸として表現したものがありました。
「プログラマーたちが完成してほっと一息ついている裏でシステムをテストによって壊し喜んでいるのがテスターだ」
といった旨の表現はいくつもあります。
この考え方には一理あると思います。
テストの一側面として、バグによって引き起こされたふるまいがユーザーの財産や心身に危害を与えないことを確かめることがあります。
これは重要な役割の１つです。
その手段として、出荷前のテストにおいて壊すこと、つまりバグを見つけることが役割と言っても過言ではないと思っています。
とはいえ、これはテストの一側面でしかありません。
「最後にテストするようもずっとテストし続ける」や「バグの発見よりもバグの防止」でも述べられている（あるいは示唆されている）通りです。
「システムを破壊する」というものを目的としてはいけないと思います。
あくまで我々の目的は、チームの一員として、価値ある最高のシステムを構築することです。
ときにシステムを破壊することも必要だとは思いますが、これは最高のシステムを構築するために行なっているのです。
テストという手段の目的化を戒めたマニフェストだと感じました。
テスターの責任よりもテストに対するチームの責任
品質はもちろん、品質を確かめる手段としてのテストも、テスターという個人や役割ではなく、チームの責任として持っておくという原則です。
これに対して違和感を持つ人はいるかもしれません。
特にテストの独立性が高いチームや、IV&Vを実践されている組織ではそのようなことがあるかもしれません。
しかしながら、特に品質に関しての責任について、チームは手放してはいけません。
チームとしてきちんと責任を持ち、自己管理されたテスト活動を行なう必要があります。
これについては、以下の記事でも「透明性」という観点で触れています。
最後に
本記事では、アジャイルテストの「Testing Manifest」について、私個人の解釈を述べてきました。
「はじめに」でも触れたように、これらは決して唯一の正解ではありません。
私の考えを呼び水として、皆さんがご自身の環境やチームにおいて「自分自身はどのように考え、行動すべきか？」を改めて言語化するきっかけとなれば、これほど嬉しいことはありません。
最後までお読みいただき、ありがとうございました。
Discussion