前回は、「⁠テストが開発を駆動していくからテスト駆動開発」ということを説明させていただきました。しかしここで言っている「テスト」とは何でしょうか。

「テスト駆動開発」という名前を持っているからには、基盤となるのは当然「テスト」です。ですから、次に「テスト駆動開発のテストってどういうテスト？」という議論をしなければなりません。

結論を先に言いましょう。テスト駆動開発における「テスト」とは、品質のためのテストではありません。

「テスト」という言葉から連想するもの

「テスト」というと、みなさんはどのようなものを想像しますか？

ソフトウェア業界の「テスト」ではどうでしょうか。たとえば昨今、ソフトウェアの品質が非常に問題になっています。有名なのはエレベータの制御ソフトの件や、電話会社の広域障害などです。そういったソフトウェアの品質が問題になってきているという文脈でのテストというのは、品質のためのテストです。

テストから連想するものは、だいたいにおいて「品質」なんですね。では品質という話をしていくとなると、「⁠品質ってなんですか？」という話をしなければなりません。たとえば、行数に対する欠陥数ですとか、そういったトピックがどうしても出て来てしまいます。

品質に関することを例に挙げるまでもなく、テストという言葉が指し示すものが複数あり多岐に渡るということが、テスト駆動開発という考え方をみなさんに広げていくときに意外と落とし穴になっています。

このためこの連載では、読者の方にテスト駆動開発を誤解なく理解していただくために、テストを改めて3つに分類します。

Developer Testing

先述したように、テスト駆動開発におけるテストというのは、品質のためのテストではありません。テスト駆動開発でのテストの位置づけは、開発を先に進めて行くための「はずみ車⁠」⁠、開発を前に進める「原動力」です。

テスト駆動開発におけるテストは「Developer Testing」と呼ばれています。Developer Test、つまり開発者が行うテストですね。Developer Testingは、開発者が開発者のために、自分自身のために、もしくはチームメンバーのために行うテストです。

ですから、たとえば、自分が書いたコードは自分でテストします。そして、テストを書くことで、フィードバックを得ることができます。「⁠次はこうしなきゃいけないはずだ」「⁠こういうコードのほうがいいんじゃないか」――テストがもたらしてくれる情報をもとにコードをより良くしていこうというのが、テスト駆動開発におけるテスト、つまりDeveloper Testingの役割です。

Customer Testing

先ほどのDeveloper Testという開発者が行うテストのほかに、Customer Testingというものがあります。「⁠Customer」というのは「お客さま」ですね。

テスト駆動開発の生まれるもととなったアジャイル開発、たとえばeXtreme Programing（XP）のような開発では、これから作成する機能のテストを、お客さまが実際に最初に書くというのが一番原始的な（原理主義的な）姿だと思います（注⁠）⁠。

Customer Testingの目的は、お客さまから見て機能がどれくらいできあがっているかを示すことです。要するに、あるテストが通ったら、その機能が完成していることを示すということです。そして、このテストが通らなければ、たとえ開発者ができあがったと主張したとしても、その機能はできあがっていないことになります。このようなお客さまの目から見たテストを、Customer Testと呼んでいます。

Customer Testingは進捗管理にも使用します。「⁠ある機能ができている／できていない」を端的に示せるためです。Customer Testingと進捗管理の話は本連載の次回、次々回でも説明します。

注）

お客さまにテストを書いていただくというトピックは少し難しく、別の話になってしまうためのでここでは割愛します。

QA Testing

第三のテストが、冒頭で例に挙げたような、品質管理・品質保証の側面からのテストです。バグを検出したり、パフォーマンスやセキュリティの検証をしたりと、さまざまな切り口からソフトウェアの信頼性を上げるために行うテストです。

品質保証のことを「Quality Assurance」（⁠クオリティアシュアランス）というため、私はQA Testingと呼んでいます。

QA Testingについては、今回はあまり深く掘り下げず、次回に再度触れることにします。

「テスト」という言葉が持つ問題

テスト駆動開発という考え方を導入するときに、一人ひとりがすでに「テスト」という言葉を知っているということが、意外なハードルになるということを先ほど触れました。

誰もが自分自身が知っているテストのイメージでテスト駆動開発を見てしまうので、どうしても、最初違和感を感じてしまいがちです。読者の方々がご存じなのは、多くの場合QA Testingだったり、もしくはCustomer Testingかもしれません。そういう自分が知ってるテストのイメージからテスト駆動開発のテストという言葉を見ると、どうしても最初は「このテストで本当に品質が上がるのか？」「⁠このテストで品質保証になっているのか？」という疑問がわいてしまいます。

そして、このような疑問や誤解は、異なるものを、「⁠テスト」という同じ言葉で指し示していることが原因で生じているという不幸な構図があります。

読者の方々に誤解なくテスト駆動開発という考え方を理解していただくためには、テスト駆動開発について説明する前にまず、「⁠テスト」という言葉の再定義を行わなければなりません。それが今回「テストという言葉」の話をさせていただいた理由です。

今回のまとめ

結論としては、テスト駆動開発をするにあたって私がテストという言葉を使って説明しているのは、「⁠Developer Testing」ということになります。

テスト駆動開発を知るには、「⁠テスト」という言葉に持つイメージを変えましょう。

開発者が、プログラマが、自分自身の開発を先に進めるために、開発を促進するために、自分自身で書いて行うテスト、それがDeveloper Testingです。今日のところは、Developer Testingという言葉を覚えてください。