【翻訳】ホリスティック・テスト：プロセス全体からテストを捉えなおす（Testing From A Holistic Point Of View）
アジャイルテストの提唱・実践者であるJanet Gregory氏が「テスト」をプロセスの全体から捉え直す試みをしています。同氏に許可を得て、ブログ記事を@mkwrdが翻訳しました。図は意味のズレや誤解を防ぐために、オリジナルの記事と同じものを掲載しています。
オリジナルのブログ記事は以下のリンクからどうぞ。
本編
ホリスティック・テスト（holistic testing）という言葉を以前から検討しています。品質向上のためには、さまざまな種類のテストをサポートする必要があるのです。
2021年1月に『テスト＆コーディングであり、コーディングしてからテストするのではない（“Testing And Coding, Not Coding ‘Then’ Testing”）』という記事を書き、テストとコーディングが同じプロセスの一部だと強調しました。そのブログ記事でご紹介したのが、継続的テスト（continuous testing）を示す以下のダイアグラムです（図1）。
図1：継続的テスト
この図は悪くはないものの、満足がいくものではありませんでした。また、この図を見た人を混乱させているようでした。そこで図1を調整し、本当に伝えたいメッセージは何かを検討してきました。そして私が開発ライフライクルをどのように捉えているかを示すモデルとしてたどり着いたのが、図2です。
図2：開発ライフサイクル
これはDevOpsのサイクルに似ていますが、ご覧の通り、コーディング・ビルド・テストを別々の段階（ステージ）として示してはいません。私にとっては、ビルドにはコーディングが含まれますし、テストは全てのステージで行われるものなのです。
フィードバックサイクルを複雑にしすぎることなく図に入れるのは難しいことです。ご注意いただきたいのは、このサイクルが時間で区切るものではないということです。非常に早く進むステージもあれば、とても時間がかかるステージもあるでしょう。それは知っていることや知らないことがどれだけあるかによります。時には、チームが一旦停止して、1～2段階前のステージに戻る必要があるでしょう。
図3：一時停止を可視化した開発ライフサイクル
図3では、必要に応じてチームがふりかえりをする時間を確保するために起こりうる一時停止を加えました。例えば、その機能についてもっと理解しようとしているときに、情報が足りないことに気づき、Plan（計画）やDiscover（気づき）のステージに戻る必要があるかもしれません。「この機能には意味があるのか？」という問いが起こることもあるでしょうし、テスト環境にデプロイしてから重大な問題が見つかったらBuild（ビルド）のステージに戻る必要があるでしょう。ふるまいや技術的な実装をもう少し理解するために、さらに前のステージに戻る必要があるかもしれません。
私はこのモデルを「ホリスティック・テスト（holistic testing）」と呼んでいます。しかし、ここまではテストについては触れていませんでした。では、このモデルのどこでテストが行われるのでしょうか？ Dan Ashby氏の「We test here and here and here」の図を参考に、サイクルを通してチームが行うテストの種類をいくつか挙げてみました（図4）。これはすべてのテストを網羅したリストではないことにご注意ください。
図4：ホリスティック・テスト
ループの左側は、早期にできるテストを示しています。ループの右側は、バグを見つけたり、学びにつなげたりするためのテストです。無限ループには始まりも終わりもありませんが、各ステージの解説は、アイデアの始まりであるDiscovery（気づき）から始めましょう。
［訳注：図中では各ステージが動詞（原形不定詞）で表現されていますが、以下の解説ではそれぞれ名詞で記載されています。］
Discovery（気づき）：私たちはビジネス価値を探しています。よくある取り組みは、プロダクトマネージャーが顧客と協力して、そのフィーチャーを追求する価値があるかどうかを判断することです。彼らはアイデアをテストしているのです。
Planning（計画）：リスクを特定し、そのフィーチャーにとってどの品質特性（quality attributes）が重要かを判断します。フィーチャーはより小さなストーリーに分割されますが、この段階でテスト可能なストーリーにすることが推奨されます。チームは上位のテストである受け入れテストの検討を開始し、ストーリーの理解を深め始めるかもしれません。
Understanding（理解）：受け入れテスト駆動開発（ATDD）やビヘイビア駆動開発（BDD）などのプラクティスは、ストーリーを理解するのに不可欠な要素です。チームはユーザーエクスペリエンスの専門家からカスタマーエクスペリエンスについて学ぶことができます。ビジネスルールを実例に落とし込むのに役立つ優れたツールであるMatt Wynneの実例マッピングを活用したり、Ellen GottesdienerとMary Gormanが『Discover to Deliver』に書いた「The 7 Product Dimensions」を使って構造化された対話（structured conversations）をするかもしれません。プログラマーは素早く作成できる低品質なプロトタイプを使って迅速かつ反復的なフィードバックを得ることで、未知のリスクを軽減するでしょう。様々な品質特性について話し合うことで、テストやモニタリングでどのコードをどのように計測するか、また後に観察するためのタグをどのイベントに付けておくかをチームが決められるようになります。
Building（ビルド）：このステージではユーザーストーリーやフィーチャーを実装し、テスト駆動開発（TDD）やファストフィードバックの原則を活用して可能な限り早くテストを行います。ストーリーが小さくテスト可能であれば、容易に実践できます。アンサンブルワーク・ペアリング・コードレビュー・テストレビューが行われます。これまでに作成した実例を使って実行可能なテストを作成し、開発の指針にできます。これらの自動テストは、一連のリグレッション・スイートの一部となり、リグレッションの失敗を検出する迅速なフィードバックを提供します。チームは探索的テストを実施して、開発時に考慮してなかったことを明らかにするでしょう。バージョン管理システムとワークフローを理解することで、技術的なリスクを管理するためにどのようなテストが必要かを判断できます。
Deploying（デプロイ）：「ビルドは一度、デプロイは何度も（"Build once, deploy many."）」というアイデアを私が初めて聞いたとき、それがいかにテスト作業に役立ったかを覚えています。同じビルドをデプロイパイプラインの複数の環境にデプロイすることで、例えば構成や使用するデータ量などが異なった環境で、様々なテストを進めることができるのですが、コードが常に同じものであると確信した状態でそれができるのです。多くのチームが安定したテスト環境の確保に苦労していますが、組織が仮想インフラやクラウドインフラを採用するようになると、チームは必要に応じてテスト環境を立ち上げることができるようになります。これにより、負荷テストやパフォーマンステストといった品質特性別のテストが簡単にできるようになるかもしれません。継続的デリバリーや継続的デプロイ（continuous delivery / deployment）を行っていない場合は、本番環境に近づけた環境にデプロイすることで、システム全体をテストすることができます。
図5：シンプルな開発パイプライン
Releasing（リリース）：最近では、顧客にリリースするための仕組みが色々あります。継続的デリバリーや継続的デプロイを実践している場合は、ブルーグリーン・デプロイメントが使えるかもしれません。同じ構成の環境を2つ用意しておき、アイドル状態の方の環境にデリバリーします。これによりテストが安全に行えるのです。準備ができたら、スイッチを入れて、新しいフィーチャーをアクティブな本番環境で稼働させます。最近増えているのはフィーチャートグルを使用するチームです。このトグルを使用すると、準備が整うまで、本番環境に投入したフィーチャーを顧客に公開されないようにできます。
Observability（観察）：チームは問題が発生したときに迅速に発見できるようにするために、イベントを記録します。これは、顧客が製品をどのように使用しているかを観察し、チームがそれに応じて対応できるようにするための方法です。また、コードに実装されていれば、チームはシステムの警告やエラーを監視することもできます。
Learning（学び）：学びの一環としてのテストについて質問されたことがあります。チームは、自分たちの製品が顧客にどのように使われているかを観察することで、どのように改善すべきか仮説を立てることができます。彼らは私たちの仮説をテストしているのです。
まとめ
継続的テストという言葉は使い古されてしまいました。私はその特定の言葉からは遠ざかり「ホリスティック・テスト（holistic testing）」という言葉が人々の心に響くことを願っています。テストを行う際には、テスターが担当すると思われるテストだけでなく、あらゆる種類のテストを考慮する必要があり、そこには自動テストや探索的テストなど、人間を中心としたあらゆるテストが含まれます。チーム全体・製品組織・顧客さえも含まれるのです。私たちは、全体的な視点（holistic point of view）からテストを考える必要があります。この図が、さまざまなタイプのテストが「いつ」行われるのかを理解するのに役立てば幸いです。
私が一緒に仕事をしてきた、最高のパフォーマンスを発揮しているチームや組織は、製品の品質に対する全体的な視点を持ち、テストがそのビジョンをどのようにサポートするかを理解しています。
訳者あとがき @mkwrd
ホリスティック（holistic）という単語は、ソフトウェアテスト・品質界隈ではあまり知られていない言葉ではないでしょうか。これは「全体観」という意味を表していて、医学の世界では病気を治すという局所的な視点よりもむしろ患者の生活全体に光を当てる「ホリスティック医学」という言葉が、またマーケティングでは効果が最大化されるよう予算を配分する「ホリスティック・アプローチ」という言葉が、それぞれ知られています。
今回のJanetの試みは、Day Ashby氏が示した有名な図にインスパイアされつつ、議論をもう少し前に進めて、それぞれのステージで具体的にはどんなテストが行われるかを実務で得られた示唆をもとに形にしようとしたものだ……と訳者は理解しています。「テスト」と一口に言っても色々あります。日本でなじみ深いシーケンシャル開発のV字モデルでも（一例として）単体テスト・結合テスト・総合テストは、それぞれ異なる狙いを持つ、異なる取り組みです。同様に、DevOpsのサイクルの各ステージで必要とされる「テスト」も、ステージによって当然それぞれ狙いや取り組みが異なるはずだというJanetの主張は、納得しやすいものではないでしょうか。シフトレフト・シフトライトという表現がホリスティック・テストの図に入っていないのも、左右で区別する意味合いが薄いと考えたからかもしれません。あくまでも、プロセス全体と、各ステージでのテストに焦点を当てているのです。
個人的には、図3で示された、一時停止が可視化された開発ライフサイクルが印象的です。開発ステップは一定の速度で進むものでも、まして、一方通行のみで進むものでもありません。本文中でも例示されているように、もしも、開発中の新機能の仕様が顧客に重大な不利益をもたらすと判明したら、プログラミングの手を止めて「本当にこれを開発していいんだっけ？」と考えたり、前のステージに立ち戻って議論するのは、よくあることだと思います。この図3を見るだけでも、アカデミックの世界に閉じこもったものではない、実務に根差した考察をJanetが提示しているのだと感じられます。
Janetは今回ホリスティック・テスト（Holistic Testing）という用語を世に問いました。「たかが言葉」かもしれませんが、長く使われたことで、自身の意図を正確に反映した意味を表すとは言えなくなってきた継続的テスト（Continuous Testing）という言葉に対して、Janetがどんな思いを抱いてきたかを想像すると、新しい言葉の誕生は必然だったようにも思えます。テストはテスターだけが取り組むものではなく、品質はチーム全体が責任を持つものだというアジャイルテストの考え方を、より体現する用語ではないでしょうか。浸透するといいなと思います。
翻訳というのは英文和訳ではありません（原著と一口に言っても、英語とは限りません）。各外国語に関する知識も多少は必要ですが、それ以上にむしろ、この文章で何を伝えたいのかを考える解釈力と、もし原著者が日本語ネイティブだったらどう書くだろうかという想像力が大いに必要とされます。本稿では、オリジナルの記事には書かれていない言葉を補った訳が散見されますが、正解が無い翻訳の世界でどれほどの価値を出せたか、読者の皆さんの判断に委ねたいと思います。
刺激的でクリエイティブな機会を与えてくれたJanet Gregory氏と、ここまでお読みくださった皆さんに感謝します。
エンジニア・デザイナー・PdMを積極採用中！
「働きがいのある会社ランキング」で8年連続上位選出されているグロービスでは、EdTech事業グロースに伴い、腕っこきのエンジニア・デザイナー・プロダクトマネージャーの採用を強化しています！ まずはカジュアル面談にいらっしゃいませんか。「今いま現職を辞める気はないけど、興味あるかもー」という皆さま、グロービスのエンジニア採用サイトか、この記事を書いた@mkwrdまでご連絡ください。
この記事が気に入ったらサポートをしてみませんか？