An old saying in the testing business is, "You can't test quality into the product." This is, of cource, true of agile development as well. We feel you can't deliver high-quality software without following some fundamental practices.
テストのビジネスのことわざで、「製品の中で品質をテストできない」 というのがあります。これはもちろんアジャイル開発においても真実です。いくつかの基本的なプラクティスなしには、高い品質のソフトウェアは作れないと感じています。
"Quality cannot be tested in" is so cliche it has to be true.
<品質はテストできない>という言葉はとても使い古されているので、真実であるに違いない。自動車からソフトウェアまで、最初の設計段階から品質が作り込まれていなければ、製品は決してまともなものにはならない。
As they say, "You can't test in quality. If it's not there before you begin testing, it won't be there when you're finished testing."
「品質はテストできない。テストを始める前に存在しなかった品質は、テストが終わったところでやはり存在しないのだ」という言葉の通りだ。
辰巳さんからは、William Edwards Deming氏の言葉を教えていただきました。
『Out of the Crisis』*2からの引用(翻訳筆者)です。
Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product. As Harold F. Dodge said, “**You can not inspect quality into a product.”
品質は、検査によって改善されるわけでも、約束されるわけでもない。検査では遅すぎるのだ。良いにせよ悪いにせよ、品質はすでに製品に備わってしまっている。
ただそれでも、「test quality into the product」ってどういうニュアンスなのよというモヤモヤは残ります*3。日本人(主語デカ)は、動詞+副詞/前置詞型の句動詞に弱いんだよ!
Deming氏の引用にも出てくる*4、統計的品質管理のHarold F. Dodge氏のこの言葉がヒントになると思います。
You cannot inspect quality into a product; it must be built into it.
build quality into a product と inspect quality into a product を対句と捉えることができます。
build inが「作り込む」、push inが「割り込む」であるように、inやintoがもたらす「~込む」という語感。これをtestにくっつけることで、「テストを通じて品質を練り込む」みたいなニュアンスを表現しているのでは、というのがわたしの仮解釈です。どうでしょうかね?
結局ヒトは、ツリー構造・階層構造にわかりやすさを見出すものです。扱う対象が大きいほど、divide and conquerってなもんで分割していく。それはツリー構造になっていくはずです。思えば上述のExcelテスト管理パラダイムにおける「大分類」「中分類」「小分類」も、ツリー構造によるグルーピングですね。
ツリーがきれいにできていれば、「フィーチャにA関するテストはこのディレクトリより下に全部集まっている」ということが一目でわかるようになります。