和田卓人の“テスト駆動開発”講座 でテスト駆動開発 (TDD) における「テスト」という用語について解説されています。これ、すっごく勉強になりました。
別にテストファーストでの開発を信条としないひとであっても、ソフトウェアテスト自体にはお世話になっている人も多いと思います。
そこでしっかりと整理しておきたいのがソフトウェアテストにおける「用語」。例えば、僕は「QAテスト」という用語なんて完全に間違って覚えていた、というか、そもそも何を指すのかよくわかっていませんでした。
いや、分かってはいたつもりなんですよ。QAが「クオリティ・アシュアランス」で「品質保証」のことだとかいう理解で。じゃあその「品質」って何を指すの？ って聞かれれば、「う、うーん。バグとかがないことですかねぇ」とか言っていたと思います。
違ったんですね。QAとは、レスポンス速度やセキュリティの確保など、ソフトウェアの「非機能部分」のことを指す用語だったんですね。
後学のためにも、ここに用語をまとめておきます。
| Developer Testing | Customer Testing | QA Testing | |
|---|---|---|---|
| 何のためのテストか | ソフトウェア開発 | プロジェクト進捗管理 | 品質（機能でない部分） |
例えばこんなテスト |
|
|
|
ここまでソフトウェアテストにおける用語について見てきましたが、用語自体の意味するところを知ることと比べても同等かそれ以上に大事なことがあります。それは、「プロジェクトチーム内での用語を統一すること」です。
同じチーム内の A さん, B さん, C さんが、彼らがてんでバラバラに意味の異なる「受け入れテスト」という言葉を用いれば、そのたびに、理解に齟齬が生じて確認の作業が必要になります。これでは仕事の効率がよくなるどころか、悪くなってしまいます。こんな状態におちいるならソフトウェアテストを導入する意味がありません。
ソフトウェアテストはあくまでもソフトウェア開発を効率よく行うための「単なるツールのうちのひとつ」に過ぎないからです。ソフトウェアテストそのものが「目的」ではなく、「単なるツールのうちのひとつ」に過ぎないということは忘れてはならなりません。
共通した用語を使うことは、正しい用語を使うことよりも重要なことなのです。コミュニケーションを阻害してしまうような用語をお互いに使うならば、「間違ってはいるが共通している用語」を使ったほうがマシです。
さて、ここまで「プロジェクトチーム内での用語を統一すること」の大切さについて書きましたが、「用語の統一の重要性」は、大きな企業であれば会社組織レベルにも言える話です。
つまり、「チーム名も社内用語」だということです。例えば、あなたの会社に「QAチーム」があったとして、そのチームは何をするチームか分かりますか。
TDDの用語に従えば、QAチームの仕事は、レスポンスが 200ms 以下であれば本番環境にデプロイできないような仕組みをつくっていたり、XSSの自動検知ツールを作っていたりするはずです。
もしもQAチームの仕事が、検証環境での機能テストを行うことであれば、TDDにおける「QA」とは違う意味になってしまっているということになります。
ですが、それも「間違ってはいるが共通している用語」であれば大きな問題ではないでしょう。しかし、現状が「間違ってもいるし、共通もしていない」ということであれば、それは一刻も早く処置しなければならない状況です。
自社が自社内の便宜のために名付けるはずのチーム名が、会社全体のコミュニケーションの阻害要因になっているなんて、残念すぎますからね。
逆に言うと、経営陣から現場の開発者までが、チーム名にせよ、ビジネスロジックにせよ、統一した用語を用いているならば、それは優れた組織であるといえるでしょう。
蛇足: ドメイン駆動開発においてはソフトウェア中における用語も統一する「ユビキタス言語」という概念があるということを同僚から聞きました。これはすごくハッピーなことです。ここまでくるとプロジェクトマネジャーが用いるビジネスの話から、ソフトウェアのなかの1つのローカル変数まで、一気貫通した「用語」が使われているということになるからです。
