前置き

最近、ATDDについて勉強しています。

BDD（振る舞い駆動開発）の提唱者である Daniel North が、TDDや自動テスト、アジャイル開発手法についてまとまった記事 "We need to talk about testing" を書いていました。

Zenn では公開していないのですが、以前TDD, BDD, ATDDとアジャイルに関する主要な動きのタイムラインをまとめたことがあって、2014年以降の話があまり見当たらないな、と思っていたところ、今回の記事にはちょうどその時期についての話題があり、興味深かったので、勉強のために邦訳してみました。

原文

以下邦訳です。

タイトル: 『テストについての話をしよう』
または、プログラマとテスターが手を取りあって幸福で充実した職業生活を送るには？

なぜ、すべてのテストを自動化しないのか？　テストカバレッジは有用な指標なのか？　テストの「シフトレフト」にはどのような意味があるのか？　テストはいつ、どんなときに必要なのか？　どのくらいテストをすれば充分なのか？

これまで何年もの間、これと似たような疑問について、多くのプログラマやテスター、その他の人々と何度も議論を交わしてきた。重要なトピックでありながら、しばしば混乱や誤解、派閥主義に包まれてきた話題だ。プログラマはテストを書くべきか、そうでないか。プログラマはテストを書く資格があるのか、ないのか。プログラマはテストをそもそも理解しているのか、そうでないか。どちらの派閥の意見も聞いたことがある。

議論を始めてみれば、最後にはより良い理解に辿り着くことが多い。そこでこの記事では、そうした議論のいくつかを共有してみたい。

混乱の多くは、テストの目的を理解しておらず、議論のリファレンスフレームを共有できていないことに由来する。皮肉なことに、私が話した多くのテスト担当者たちもそうだった。

議論のリファレンスフレームを作るために、以下のトピックに注目したい:

テストとは何であり、何でないか
TDD (やBDD) がテストと枝葉末節でしか関係しないのはなぜか

以下では、記事冒頭の疑問に答え、テスト担当者とプログラマがどのように仲良く協力すれば良いのかを議論する。この記事をきっかけに、読者の肩書きがなんであれ、テストについての教義と領域を見つめ直す機会となり、テストそれそのものを第一級市民的な業務として取り組むようになってくれればと願う。

長い文章なので、紅茶でも読んで読みはじめてほしい。

テストの目的

「おかしくなり得るのはどのあたりだろう？」

ソフトウェアを変更するとき、新たな機能を追加するのであれ、機能を変更したり置き換えたりするのであれ、改善のための「舞台裏」の変更をするのであれ、リスクは生じる。どのような変更でも、何か"悪いこと"を引き起こす可能性はゼロではない。

コードそのものだけではない。ビルドシステム、デプロイ経路、運用環境、統合箇所、その他のあらゆる直接的・間接的依存性でも生じることだ。

起こり得る"悪いこと"には様々な種類がある。一例を挙げよう:

機能的正確性: 期待していた結果をもたらさない。
安定性: ほとんどの場合に正確な答えを出すが、ときどき不正確になる。
利便性: 確かに動作するのだが、不安定で使っていてストレスがたまる。
アクセシビリティ: 利便性と似ているが、排斥的で違法な場合もある。
予見可能性: メモリ、IOやCPU使用率といったリソース消費に不規則なスパイクがあったり、ときどき体感できる時間固まったりする。
セキュリティ: 設計通りに動作しているが、セキュリティ上の脆弱性がある。
コンプライアンス: 動作するが、個人の情報を適切に扱っていない、など。
観測可能性: ほとんど動作するが、うまくいかない場合にその原因を特定することが困難である。

それぞれの"悪いこと"について、それを気に掛ける人がいる。その人たちをステークホルダーと呼ぶ。この後の議論で、それらの人々はそれぞれ異なるリスクの尺度や品質の尺度を代表する。

なぜテストをするのか？

これについて、私が提唱するのは以下の命題だ:

テストの目的とは、ステークホルダーにとっての信頼性を、エビデンスを通して増大することだ。

この命題には三つの要素がある:

ステークホルダーとは、直接的または間接的に、私たちの仕事から影響を受ける人のことだ。UX専門家の Marc MacNeill は「私たちがその人生に関わる相手」とドラマティックな表現で呼んでいる。プロダクトやサービスの顧客やエンドユーザよりも広い概念だ。ステークホルダーは一次元のサイロ化された個人などではなく、それぞれの異なる視野から貢献する共同作業者だ。
信頼性を増大すること、厳密には不確実性を減少することとは、ステークホルダーが気に掛けていることや、我々の取り組んでいる（もしくは取り掛かろうとしている）仕事がそれにどう影響を与えるかを理解することだ。このステークホルダーがより安らかに夜を眠れるために、我々に何ができるだろうか？
エビデンスとは、議論の余地のない情報やデータだ。ステークホルダーは私たちの口約束や保証を信じされられたり、前評判を頼らされてはいけない。冷徹で強固な証拠を受け取るべき立場の人たちだ。

この不確実性を減少する過程を「保証」と、ステークホルダーが気に掛けることを「品質（基準）」と言い換えることができる。したがって、これはテストの教義の人気のあるもう一つの呼び名、「品質保証」に関する話題といえる。私たちの主張は、この保証を、盲信や演技ではなくエビデンスに基づくものにしよう、ということだ。

というわけで、テストのマインドセットに関連付けられる三つの「超能力」がある:

共感力: ステークホルダーの頭の中に入り込み、彼らの視点で世界を見ることで、彼らが何に関心を向けるのかを理解する能力。
懐疑性: 仕事に取り組みながら、その仕事について疑問を持つ能力。エゴや確証バイアスのために、我々プログラマにとってはとりわけ難しい。これは仮説の"証明"ではなく"反証"を試みる「科学的方法」に沿っている。
創造性: ステークホルダーを安心させるためであればできることは何でもやる能力と意思、あるいはそもそも自らの仕事を疑うべきだと思い至ること！　テストは非線形で、非自明で、しばしば緊急性がある。データベースをつつきまわす、ネットワーク上のパケットを覗き見る、相互作用を記録するためにサービスプロクシを注入する、視線の動きをトラッキングする、DNSをハックする、他のコードを壊すコードを書くといったことは、いずれも優れたテスターにとっては禁じ手ではない。

もし…ならば、そのときに限り…

これらの定義から、次のことが言える:

テストをしているといえるのは、ステークホルダーにとっての信頼性を増大しているときであり、そのときに限る。

テスト的思考法とは、種々の欠陥を未然に防いだり、手作りのUIを、ロバストかつ堅牢で充実したドキュメントを持つ、常識的な振る舞いを備えたウィジェットの明示的な集合に置き換えるといったアーキテクチャおよび設計上の選択を含む。それらはある種のリスクを打ち消す予防策だ: ステークホルダーがあまり嬉しくないサプライズを受け取ることがなくなるので、下流にいる誰もがこの種のエラーをチェックせずに済むようになる。

テスト的思考法とは、新たな機能を設計するとき、異なるステークホルダーそれぞれがその変更にどのような興味を持ち、彼らが正しいと仮定した上で、何を懸念するかを考える時間を設けることだ*。*

逆にいえば、もし、少なくとも一種類のステークホルダーにとっての信頼性を、具体的なエビデンスによって明確に増大していないとすれば、他に何をしていようとも、テストをしているとはいえない。テストの観点から見れば、良くて既に踏み固められた道を歩いているだけ、悪くすればテスト劇場に従事して、テストの幻想を演じながら実際的価値のある情報は何も生み出していない。

デジタルプロダクトの文脈では、これらのエビデンスを浮かび上がらせる最も良くあるやり方は、システムを操作しての手動テストか自動テストの設計・実装・実行を、ハンズオンで行うことだ。優れた自動テストを設計・実装することについてはそのためだけに節を設けるべきだが、その前にTDDについて話す必要がある。なぜならTDDこそが、混乱の最大の根源だからだ。

テスト駆動開発 - 補足記事

テスト駆動開発 (TDD) とは、実行可能な小さなコードサンプルを書くことによって、APIや機能の設計を駆動するというプログラミング手法のひとつだ。この手法は、注意深く小さく分割されたステップを作ることで、コードサンプルを動作させるために最小限必要なことだけに集中することができる、優れた手法だ。プログラマが、新たなコードサンプルに着手するときにリファクタリングやお片付けを忘れることさえなければ、コンパクトなインターフェイスと良く構造化された見通しの良いコードが生み出されることが多い。

混乱の始まりは、これらのサンプルコードが、コードベースの成長に伴いプログラマが明らかなレグレッションを作り込むことを防ぐテストとして事後的にも使えることから、初期の実践者たちがこれらのスタイルを「テスト駆動開発」と呼び始め、ケント・ベックの "Extreme Programming, Explained" を始めとするアジャイルの古典的解説書によって主流の用語となったことからだ。

コードサンプルは有用なフィードバックをプログラマにもたらしてはくれるが、必ずしも良いテスト（何が良いテストかは後述する）とは限らないし、なんにせよ、経験を詰んだTDDの実践者たちは可能な限り少ないテストを書こうとするものだ。ケント・ベックも言うように、プログラマーはテストを書くためにお金を受け取っているのではなく、動作するコードを書くためにお金を受け取っているのだ。

私が振る舞い駆動開発を作った最大の動機が、この混乱だった。いくつものチームでTDDをコーチしているとき、この記事の冒頭にあるような疑問のすべてが湧いて出てきて、結局はそれらがTDDの実践とは大して関係がないことがわかった。そこで、私はTDDを「テスト」という言葉を一切使わずに記述する方法を編み出し、チームの中でのTDDの導入と定着にずっと良い効果があることを確認した。

この用語の誤った使い方が、ほとんどのテストがテスト劇場に過ぎないという信念とあいまって、この数十年の間、アジャイルムーブメントをソフトウェアテストに甚大なダメージを与える方向にうっかり導いてしまったのだと、私は考えている。

私のこの見解が物議を醸したことを踏まえて、以下で少し詳しく説明したいと思う。否定的なことではまったくない。テストの世界は、ビルド・デプロイの自動化から多大な良い影響を受けた。「プログラマ向けテスト」の実行は、何のフィードバックもないよりは良い。小さなカタマリで作業することは、デリバリータイムとフィードバック遅延の減少に寄与している。カオスエンジニアリングに代表される「本番環境でテストする」文化が現れてきたことは期待に値するが、まだ歴史の浅い分野でもある。

しかし、テストやその実践者の目的や本質は、**"自動テスト"**という侵略的種族によって希薄化されてしまった。有名な"自動テストピラミッド"ですら、機能に関することにほとんど終始していて、セキュリティ、コンプライアンス、運用可能性・観測可能性の特性といった横断的な安全指標には言及しないことが大抵だ。

要約しよう: TDD, BDD, ATDDなどの手法は、その名前がどんな風に聞こえたとしても、テストを置き換えるものではまったくない。これらは一義的に、設計・開発の技法だ。

さて、今、私たちはテストとはステークホルダーにエビデンスを提供することであり、仮にTDDに宗教的に従ったとしても、良くて表層的なテストをしているだけだという理解に至った上で、冒頭の疑問に戻ることにしよう。

テストについて話そう

なぜすべてのテストを自動化しないのか？

この質問自体が、私が言及した意図せぬ甚大なダメージを明確に表している。

アジャイル手法が名声を得る前の1990年代の間、テストとは、プロジェクト開始時に要求が書かれつつある中で実施される、テスト計画という構造的活動の一つだった。この段階での主要な活動は何が変更されるのか、それによりどのような"悪いこと"が引き起こされうるのかを理解する、影響分析という活動だった。

私は何も、ソフトウェアの暗黒時代に戻ろうという声を代弁しているのではない。だが、テストという生まれたての赤子を、 Big Design Up Front という大きな浴槽とともに投げ捨ててしまったのだとは思っている。

それからの数年間で、次のような新たなマインドセットが根付いた:

アジャイルなソフトウェアチームとは、複数のプログラマに加えて、ドメイン知識を提供する対象事業のエキスパートと、スコープを定義するアナリスト（後にプロダクトオーナーと呼ばれるようになった）から構成される。
私たちプログラマは、TDD、あるいは"テストファースト"プログラミングなどの手法を使い、プロジェクトの進行に合わせて単体テストを書く。
このようにプログラムを作成することで、十分なテストを作成することができ、私たちはコードに対して自信を持つことができる。
単体テストは、変更するたびに毎回実行しても問題ないくらいに速い。なんなら、「いつでも、すべてのテストを実行せよ」というマントラすらある。
従って、影響分析の必要はない。仮に何らかの機能がどこかに影響を与えたら、読みやすく作られた単体テストスイートを実行した瞬間に気付くことができる。
テスターは、自動化するにはコストがかかりすぎるテストや、変化が頻繁すぎて自動化する価値がないテストを実行するための、自分たちの後始末のためにしか必要がない。これを「手動テスト」と呼ぶ。
自動テストを書くことに習熟すればするほど、手動テストの担当者はどんどん必要なくなる。
テスターは、十分優秀であれば自動テスト作成者として再トレーニングされるべきだろう。自動テストを書く程度の能力しか持たない第二級のプログラマだ。それにもなれなければ、ボタンを押すことしかできない。つまり、階層構造は「プログラマ＞自動テスト作成者＞手動テスト担当者」の順となる。
そのような付加価値の低いテストはアウトソースし、コモディティ化した二軍の活動として扱って構わない。
テストカバレッジは、私たちがいかにテストに優れているかを示す指標だ。やったぞ！

少し紐解く時間をかければ、これらがいかに誤った考え方であるかがわかる。

[アジャイルソフトウェアチームは…] プログラミングこそが、デジタルプロダクトにおけるバリューチェーンの唯一の構成要素だ。「チーム」のほとんどの構成員がプログラマあることが、他にも多くの人が価値想像に直接的・間接的に関与していることを覆い隠している。
[…単体テストを書くこと…] プログラマは単体テストを書いていると考えているが、実際には違う。設計を導くための簡単なコードサンプルを書いているのだ。典型的には、機能やそのコードが何をするのかを表す単一のコードサンプルを書いているのであって、その機能が特定のステークホルダーのために特別に書かれたものでもない限り、セキュリティ・アクセシビリティ・コンプライアンスなどといった、より微妙な尺度について書いているのではないし、仮にそうであっても、他のステークホルダーは脇に追いやられている。

これらのコードサンプルはテストとして設計されたのではなく、ガイドとして設計されている。一例として、プログラマが単一の値の計算を確認する「テスト」を書く、あるいはもう一つの値も使って三角測量すると考える。そこで勝利宣言だ。テストのマインドセットに従い、小さなあるいは大きな値、極端に大きな負の値、+/-ゼロ近傍の値といった、中間的だったり無効な値、見過ごされた値を想定し、それらを脈絡なく呼び出すなどの怪しい検証をすることだろう。

プログラマがこうしたテスト的思考法を持てないと考える理由はないが、大抵の場合、デリバリーの重圧のために既に次にやることに意識が向かっているものだ。
[…コードについての自信…] コードを書いたプログラマ本人の自信は、品質の指標としては役に立たないことで悪名高い。仕事をしたその人自身というのは、定義上その仕事に自信を持つものだ。もし何か良くない点があると思っていれば、そんな書き方はしないはずだからだ。あらゆる種類の認知的バイアスが出る幕となる。確証バイアス、根本的な帰属の誤り、ダニング・クルーガー効果など、枚挙に暇がない。

これらを一通り把握しておくことは、プログラマがテスターとしての思考法を身につけ始めるための最低限の条件でしかない。始めは失敗を仮定するよりも、成功を仮定するものだ。私もデフォルトでは、私の幻想を打ち砕くエビデンスよりも、「自分が正しいことを証明する」ためのエビデンスを探してしまうが、気づいたところで意識を変える。
[…すべてを実行…] 最初はその通りかもしれないが、こまめで専門的な細部への注意がなければ、数秒でビルドできたものが数分のビルド時間となり、30分かかるビルドとなる。テスト環境のプロビジョニングと削除の自動化、データのサニタイジングと読み込み、ビルドとデプロイのリソース競合、非力な開発環境をはじめとする様々な要因を導入すると、「いつでも、すべてのテストを実行せよ」などという幻想を抱いていたことは遠い思い出となる。

こうなってしまえば、もはやどのステージでどの種類のテストのサブセットを実行するか決めなければならない。そしてこれによって、中間フィードバックループを短くしようとしてより多くのステージを追加し、結果としてプロダクションまでのリードタイムは増大する。そして、テストスイート管理という濁った世界に足を踏み入れることになる。
[…影響分析…] ツールによっては、失敗したテストを最初に再実行したり、静的解析によりどのテストが最も効果的かを踏まえた影響主導のアプローチを取るものもある。だが、影響分析の技術と体系は必要でありながら消えゆく技法となったままだ・
[…テスターは後始末を…] ここまでくれば、これがどういうことがわかるだろう。テスターは、どのようにテストを考えるべきかを助けるために必要だ！　自動か手動かは、最も議論する意味のない軸だといえる。リスクと、様々な尺度におけるその潜在的影響範囲を理解すること、そしてそうしたどれも重要な情報を浮かび上がらせることは、それ単体で評価されるべきフルタイム級の専門性だ。
[…より少ない手動テスト担当者が…] これについては私も賛同してしまいがちだ（！）。だがアジャイルプログラマが「自動テストを書く」と思っていることは、優れた自動テストを書くスキルや専門性ではまったくない。この話はプログラマを驚かせることだしばしばある。
[自動テスト担当者として再トレーニング] プログラミングスキルはテスターにとって便利なものでもあるが、自動テスト担当者とか手動テスト担当者とかいった役割が存在するとは考えにくい。自動化は、優れたテスターが道具箱に備えている便利なツールの一つだ。
[…アウトソース…] さて、これが問題だ。リスクを認識したり、影響範囲を理解したり、ステークホルダーの頭の中を想像してみたり（これはしばしば重要人物やグループとの関係性構築を必要とする）、浮かび上がりつつあるエビデンスを夢中で集めたりすることは、どれもアウトソースすることが賢明といえる活動や能力ではない。チーム内に「テスト担当外注先」があるとか、あるいは組織内の別のチームがその役割をになっているとしても、彼らはおそらくテスト劇場を演じているだけで、実際にリスクを減少させたり信頼性を増幅してはいないだろう。
[…テストカバレッジは…] テストカバレッジについては次に話そう。残念ながら、テストにとっては素晴らしいと言えるものではない。

こうしたマインドセットはすべてのチームにあるとは思わないし、多くのチームは健康的でわかりやすいテストへのアプローチを備えているが、しかし広く受け入れられてしまった考え方でもあるし、「手動テスト vs 自動テスト」の発想は、リクルーティングから認定制度やキャリアパス全体を通して普遍的に見られる。

では、疑問に答えよう。なぜすべてのテストを自動化しないのか？　自動テストを書くべきなのは、それがエビデンスを浮かび上がらせる助けになるとき、特に繰り返し実施することについてであるべきだ。そしてそのときには、プログラマのガイドとして視座ではなく、テストの視座から書くべきだ。例えばデータベースやリモートサービスからテスト結果を取得したり、テストデータを利用可能な形に前処理するような、テスト活動以外のためのツールを書いても良い。

人間が計算機システムと関わるときには、単にボタンを押す以上のことをしており、そこで生み出されるインサイトやフィードバックこそが、ハンズオンでのテストを価値ある持続的な活動にしている。

テストカバレッジは有用な指標なのか？

いいえ。はい。ときどき。場合によっては。「テストカバレッジ」は「実行される自動テストによりカバーされるコード」の略だ。ここでも複数の品質尺度の考え方が適用できる。あるテストでエビデンスを提供しようとしている相手は、どのステークホルダーなのか？　彼らの信頼にどれくらい寄与する情報なのか？　最も良い場合で、あるコードが別のコードを動かしたという事実によって、少なくとも一人のステークホルダーのためのエビデンスを獲得したことがわかる。

例えば、あるコードの正しさを検証するためにそれを実行すること（正しい答えを返すだろうか？）は、セキュリティ脆弱性や法令違反の有無について何の情報ももたらさない。そして毎回一つの同じ値についてテストするテストを実行しても、何ら保証することができない。

テストカバレッジが明らかにできることの一つとして、自動テストが存在しない、という事実がある。そもそもカバレッジが存在しないということは、そのコードは自動テストではまったくチェックされていないということだ。しかし、コードを検証する方法が他にもあるとわかっていれば、それも必ずしも懸念事項にはならない。例えば、開発者やテスターが一日に何度も見ている画面であれば、レイアウトがひどい崩れ方をしているということはないと考えられるだろう。自動テストで同じことを確認する方法はない。

テストの「シフトレフト」にはどのような意味があるのか？

私はかつて、「テストのシフトレフト」とは、ここまで述べたようなテスト活動をプロセスの初期から始めることだと考えていたが、後にそれ以上のものだと理解した。異なることをするという意味だったのだ。テストのシフトレフトは、異なるステークホルダーについて初期から継続的に考え、アーキテクチャや設計を異なる形にするということだ。それはつまり、セキュリティ、アクセシビリティやその他の注意を払うべき品質尺度もシフトレフトすることを意味する。つまりテストのシフトレフトは、実際には使うことのないソリューションに過剰投資することを抑制する、あらゆる種類の品質担保活動を動機付けすることになる。強化版TDDのようなものだ。

その意図せぬ帰結として、かつてテスターがプロジェクトの下流しか見られないときに行っていた伝統的な作業のほとんどを、撤廃することができる。繰り返しになるが、同じ仕事を早い段階でやるのではなく、自分たち自身の仕事がまったく必要なくなるような状況に追い込んでしまったのだ。

テストはいつ、どんなときに必要なのか？

これはテストのシフトレスとの別名だ。自明な答えがある: 可能な限り早い段階で、現実的な程度になるべく頻繁に、だ。開発サイクルのどの段階でも、品質の保証となるエビデンスを浮かび上がらせることは始められる。プログラマーは、少なくともときどきはテスターのように考えるべきだ。テスターは、このときにプログラマーの助けになれる。

テストするより前の段階で、機能は「完了」したり「完成」しているべきだという誤謬があるが、これは簡単に論破することができる。[どんな段階でも]データがどんなデータがどこから、どんな方法で、どれくらいの間、何の目的でアクセスされているかを知ることがでいる。軽量なUIスケッチからでも、一完成やアクセシビリティの評価をすることができる。

これらを元に、セキュリティ、プライバシー、コンプライアンスに関する見解を定めることができる。毎回、どのくらいのデータが戻ってくるのか？　データ容量や価値、画面の更新頻度は最悪のケースでどれくらいになるか？　こうしたことから、信頼性、ロバスト性、レジリエンスについてのインサイトを得ることができる。

プログラマーが常にすべてのステークホルダーの頭になって考えることはできない。そんなことをすれば何一つ作り上げられずに終わりだろう。だがこのテスト的思考法は、開発チームやバリューチェーンのどこかに組み込まれたテスターたちとともに継続的に取り組むべきだ。

どのくらいテストすれば充分なのか？

システムに対するあらゆる変更は、様々な尺度におけるリスク（"悪いこと"が起きる可能性）を増大する。ここまで、その例を見てきた。変更の種類や文脈により異なるが、それらに対し適切な程度の自信をエビデンスを通じて構築することは、私たち自身の責任となる。

これは、テストの「量」なるものが線形の数量ではないことを示唆している。「充分」かどうか、前述の様々な尺度に沿って考える必要がある。変更のサイズはどれくらいか？　何か変なことが起きたとき、その影響範囲はどのくれいか？　この変更がセキュリティ・利便性などに与え得る影響はどの程度か？　同じことを、リスクの分布を変えて行うにはどうすればいいだろうか？

「充分」なテストについて考えることは、別な影響を持つ代替案について建設的な議論を導く良いきっかけとなる。それらはほとんどの場合トレードオフだ。一つのソリューションが、別のものに比べて、客観的にみてあらゆる評価尺度で「優れて」いることはあまりない。ただ、シンプルで小さな変更は、複雑で巨大な変更よりリスクが小さい、とは言えるかもしれない。

総括

私のプログラマーとしての30年程度のちょっとしたキャリアのうち、おそらくここ20年は、テストとテスターがソフトウェア開発にどのようにフィットするかを考えることに費やしてきた。アジャイルソフトウェア開発におけるテストとテスターの扱いはあまり良い心地のするものではなく、これらの考えを整理し明確にするために長い時間を要することとなった。この記事の内容の多くは2016年のBDDxでの講演を材料としたもので、書き始めたのは2018年下旬のことだ。

私はテスターとして仕事をしているわけではない。この記事は、いくつかのチームで仕事をしながら、何名かの素晴らしいテスターと話し、共同作業する機会に恵まれた一人のアジャイルプログラマーの目線から書かれている。

私は、テストの目的と原則が、アジャイルなデリバリー手法とうまく噛み合うものだと信じている。一般的にそうはなっていない事実については、本質的に避けがたいものではなく、歴史的な経緯によるひずみのようなものだ。このまま進めば、テストやテスターを脇役に追いやり、想像的なハイパフォーマンスチームを生み出す機会をみすみす逃してしまうだろう。

この記事で述べたような考え方を再び導入することで、より良い品質のソフトウェアを早く、それでいて持続可能なかたちで作り出すことができ、類い稀な "より良く、速く、安く" の三拍子が揃う様を見られるはずだ。

以上、抄訳でした。原文はこちら:

Discussion