ジャネットの許可を得てざっくり意訳しました。原文は『Testing From A Holistic Point Of View』です。訳に対するフィードバックも大歓迎です。Thanks for the great blog post, Janet!
ホリスティックテスト（訳注：総合的なテスト、全体的なテスト）という言葉を、私は以前から考えていました。より良い品質を実現するためには、様々な種類のテストをサポートにしていく必要があるのです。
2021年1月、私は「Testing And Coding, Not Coding ‘Then’ Testing」というブログ記事を書き、テストとコーディングが同じプロセスの一部であることを強調しました。その記事の中で、継続的テスティングを示すモデル（図1）を紹介しました。
この図に問題はなかったのですが、完全に満足していたわけではありませんでした。そこで、私はこの図を微調整し、本当に伝えたいメッセージは何かを考え、私が開発ライフサイクルをどのように見ているかを示す新しいモデル（図2）に落ち着きました。
これはDevOpsサイクルと似ていますが、サイクルの中でコーディングとテストを別々のステージとして分けていることにお気づきでしょう。ビルディングステージ（BUILD）には、コーディングとそれに付随するすべてのことが含まれており、テストはすべてのステージにおいて実施されるものだと私は考えています。
あまり複雑にならないように、フィードバックサイクルを図に含めるのは難しいのですが、この図が表現するサイクルは、時間で枠を決めるものではありません。既知または未知の課題ががどれだけ存在するかによって、ステージのいくつかは非常に早く進むこともあれば、非常に遅く進むこともあります。時には、チームは一時停止して、1つか2つ前のステージに戻る必要もでてきます。
図3では、必要なときにチームが振り返る時間を確保するために、可能な限り一時停止を設けるようにしました。例えば、以下のようなケースがあるはずです。ある機能についてもっと理解しようとしているときに、情報が足りないことに気づき、プランニング（PLAN）やディスカバリー（DISCOVER)ステージに戻る必要あるのではないか？この機能は意味があるのだろうか？ あるいは、テスト環境にデプロイしたところ、重大な問題が見つかり、ビルドステージに戻る必要があるんじゃないか？ さらにさかのぼって、動作や技術的な実装をもう少し理解する必要があるのではないか？
私はこのモデルを「ホリスティックテスティング」と名付けましたが、ここまで私は「テスティング」について触れていません。では、このモデルのどこでテストは行われるのでしょうか？Dan Ashbyの「we test here and here and here」という図を参考に、開発サイクル全体を通して起こりうるテスト活動を、いくつかリストアップしてみました（図4）。注：この一覧は網羅性を求めていません。
ループの左側は、私たちが早期に行なえるテストを示しています。ループの右側は、バグを発見し、学習するためのテストです。無限ループにはじまりも終わりもありませんが、発見（DISCOVER)、つまりアイデアのはじまりから見ていきましょう。
Discovery: 私たちは、ビジネス価値を求めています。これは、プロダクトマネージャーが顧客と一緒になって、その機能が追求する価値があるかどうかを判断している場合が多いのです。彼らはアイデアをテストしています。
Planning: その機能にとってどの品質属性が重要になるかを判断するためにリスクを特定します。フィーチャーはより小さなストーリーに分割され、テスト可能なストーリーを提唱するための時間になります。チームは高レベルの受け入れテストを見はじめ、ストーリーに対する理解を深めようとするかもしれません。
Understanding: 受け入れテスト駆動開発（test-driven development）やビヘイビア駆動開発（behaviour-driven development）などのプラクティスは、ストーリーを理解する活動の一部とも言えます。チームは、顧客体験について学ぶために、ユーザーエクスペリエンスの専門家を利用することもできます。Matt Wynneのexample mappingは、ビジネスルールを実例としてマッピングするのに役立つ素晴らしいフレームワークです。また，Ellen Gottesdiener氏とMary Gorman氏の『Discover to Deliver 』にある「7 Product Dimensions」を使って，構造化された会話も可能です。プログラマーは、忠実度の低いプロトタイプを作成し、高速で反復的なフィードバックを行い、未知の領域に関するリスクを軽減できます。さまざまな品質属性について話し合うことで、テストやモニタリング、あるいは後で観察するためのイベントのタグ付けなどのために、「何をどのように」コードに組み込む（instrument the code）か、チームは意思決定できるようになります。
Building: ここでは、ユーザーストーリーや機能を実装します。おそらく、テスト駆動開発（TDD）を実践したり、できるだけ早くテストを行うために、高速フィードバックの原則を使用したりします。テスト可能な小さなストーリーによって、これらのプラクティスを簡単に適用できるようになります。アンサンブルワーク、ペアリング、コードレビュー、テストレビューが行われます。先に作成したサンプルを使って、開発の指針となる実行可能なテストを作成できます。これらの自動テストは、リグレッション・スイートの一部となり、リグレッションの失敗を検出し、迅速なフィードバックを提供します。チームは探索的なテストを行い、開発時には考えもしなかったことを明らかにします。バージョン管理システムとワークフローを理解することで、技術的なリスクを管理するためにどのようなテストが必要なのかを判断できます。
Deploying: 「一回ビルドすれば、何回でもデプロイできる」。このアイデアを初めて聞いたときに、私はそれがどのようにテスト作業に役立つのかを考えました。デプロイメントパイプラインにおいて、同じビルドを複数の環境にデプロイすれば、コードが常に同じであることを認識しながら、異なる環境に対して異なるテスト活動を実行できます。例えば、各環境の違いは構成であったり、使用するデータ量であったりするはずです。多くのチームが安定したテスト環境の構築に苦労しています。しかし、組織が仮想インフラストラクチャーやクラウドインフラストラクチャーを採用することで、オンデマンドでテスト環境を構築できるようになりました。これにより、負荷テストやパフォーマンステストなど、一部の品質属性のテストがよりシンプルになる可能性があります。まだ継続的デリバリーや継続的デプロイを行っていない場合であっても、本番環境と同じようにデプロイすれば、システム全体をテストできます。
Releasing: 最近は、お客様に対してリリースする仕組みがいろいろとあります。継続的デリバリーや継続的デプロイを実践している場合、ブルー/グリーンデプロイメント戦略を使用している可能性があります。どちらの環境も同じ構成ですが、テストが安全に行えるように、デリバリはアイドリングしている環境に行います。準備が整ったらスイッチを入れ、新機能がアクティブな本番環境に導入されます。より多くのチームがリリースフィーチャートグルを使用しており、チームは機能を本番稼動させながら、準備ができたときにだけ顧客に見せられます。
Observability: 万が一、問題が発生した場合にも、すぐに発見できるようにと、チームはさまざまなイベントをキャプチャします。お客様がどのように製品を使うかを確認し、状況に応じてチームが対応していきます。また、チームは警告やエラーについてシステムを監視します（監視のための実装がコードに施されている場合）。
Learning: 学習の一環としてのテストを、質問される場合があります。チームは、自分たちのプロダクトが顧客にどのように使用されているかを観察することで、どのように改善すればよいかという仮説を立てられます。チームは自分たちの仮説を検証しているのです。
Summary
継続的テストという言葉は使い古されたものなので、私はその言葉から離れ、「ホリスティックテスト」という言葉が人々の心に響くのを願っています。テストを行う際には、テスターが担当するものだけでなく、あらゆる種類のテストを考慮する必要があります。それらは、自動化、探索テスト、その他人間中心のテストです。こういったテストは、チーム全体、製品組織、そしてお客様も巻き込んでいくものです。我々はテストを総合的に考える必要があり、この図が、さまざまな種類のテストが「いつ」行われるかを理解する一助になればと思います。
私が一緒に仕事をしてきた中で、最も高い業績を上げているチームや組織は、製品の品質に対して全体的な視点を持ち、テストがそのビジョンをどのようにサポートできるかを理解しています。
＊
- 翻訳メモ
- 「Testing」を「テスト」と訳されているケースが多いですが、ここでは原文である「テスティング」のままにしています。
- 「instrument the code」は、Androidのinstrumental test とは違い、Google Analyticsのような計測ツールのタグを埋め込む行為を指しているぽい。
旅と子育てとアジャイルコーチのブログ「世界」 