「Test」という言葉について

t­wadahttp://d.hatena.ne.jp/t­wada/

2005年7月23日@J2EE勉強会 第10回

お品書き

★ 結論

時代背景

テストにまつわる混乱

テストの新しい分類

目的からテストを見直してみると

        TDDについて

結論から述べます

結論 その1

● TDDはテスト技術ではない

● "Test"が指し示しているものは複数ある

– 開発促進と品質保証

– 2つの"Test"に優劣はない。「違う」だけ。

– どちらも非常に重要● テストをロールから分類する

– 開発者 / 顧客 / 品質保証担当者

結論 その2

● TDDの"Test"は開発(者)のためのもの

– つまり、開発促進のテスト

● TDDの良さは設計技術でありながら品質保証技術に「かなり近い」こと

結論

★ 時代背景

テストにまつわる混乱

テストの新しい分類

目的からテストを見直してみると

        TDDについて

難しくなったソフトウェア開発

● ソフトウェアの複雑化● ソフトウェアの大規模化● プロジェクトの短納期化

● オブジェクト指向も(それなりに)使われだした

→ソフトウェアの品質が問題に(日経ビジネス)

→「テスト」が注目されてきた

アジャイル、XPの台頭

● 開発プロセスとしてはともかく、開発者にテスト技術への関心を持たせた– それまでテストは「めんどくさいもの」だった– テストファーストのインパクト

● XPより後からやってきたTDD– XPE(白本) 2000年

– TDD 2003年● アジャイラーに受け入れられる

テスト技術に対する関心

● テスティングコミュニティが活発です

– JaSST– パターンワーキンググループ分科会

● ソフトウェアテストに関する書籍が多数出てきました

結論

時代背景

★ テストにまつわる混乱

テストの新しい分類

目的からテストを見直してみると

        TDDについて

テストについての議論がかみあわないことが

ありませんか?

テスト分類の混乱

● 単体、ユニット、結合、機能、システム…

● 単体テストとユニットテストは同じもの?– 単体って?

– ユニットって?

● 結合テストは何を結合する?● 品質保証? 動作確認?● だれが? いつ?

オブジェクト指向とテスト分類

● オブジェクト指向が混乱に拍車をかけた

– 単体/ユニットの解釈がブレる

OO、コンポーネント技術は自己相似みたいだから難しい?

システム、サブシステム、コンポーネント、オブジェクトグラフ、...

テストの目的に戻ろう

● 何のためにテストするのか● 誰のためにテストをするのか● テストで何を知りたいのか

「結局、何のためにテストを行うのか」

目的について

● 何のためのテストなのか– 保証– 破壊– フィードバック

● 退行していないことを保証するテスト● 非機能要件を満たしていることを保証するテスト

● 自信をもって開発するためのテスト● そして、変化の呼び水となるテスト

TDD != 品質保証技術

● TDDは「こうしてみようか」をテストする

● QAテストは「こうあってはならない」をテストする

TDDは品質向上技術だが、品質保証技術ではない。そもそも「品質」の話が必要

あなたにとっての「品質」とは何ですか?

混乱の元凶

● TDDのTestの目的は従来メジャーでなかった

– 開発の促進– 変化の呼び水– 設計行為としてのテスト

　新しい目的に既存の言葉、

　これがTestにまつわる混乱の元凶

結論

時代背景

テストにまつわる混乱

★ テストの新しい分類

目的からテストを見直してみると

        TDDについて

テストを実行者によって分類する

● Developer(Programmer) Test– 開発者が行う、開発促進のためのテスト– 単体、ユニット、結合 …などなど

● Customer Test– 顧客(のロールを担うひと)が行うテスト

– 従来の「受け入れテスト」が多くを占める

● QA Test– 品質保証のためのテスト– 行う人は開発者かもしれないし、テスト担当者かもしれない

誰がテストするのか

● 「帽子」のメタファ– 同一人物が異なる役割を意識するためにつかう– 実装の帽子とリファクタリングの帽子

では品質保証の帽子もあるのでは?

結論

時代背景

テストにまつわる混乱

　 テストの新しい分類

★ 目的からテストを見直してみると

　TDDについて

カバレッジ

● 収穫逓減(80%までがおいしい)● 100%の罠

● テストは、予想の範囲内で、予想通りに動くことしか証明できない

● ホワイトボックステスト● テストの資産価値

テスト生成の機械化

● 人が作るテスト→生成できない– 意図– ユーザビリティ

● 機械でも作れるテスト→生成できる(金で買える?)– NullPointerException

– (一部の)臨界値テスト

– DbC的なもの

xUnitの果たした役割

● 「テスト熱中症」感染者を生んだ● 開発促進と品質保証を近づけた● デファクトスタンダードとして知識を共有

結論

時代背景

テストにまつわる混乱

　 テストの新しい分類

目的からテストを見直してみると

★　TDDについて

TDDとは何でないのか

おことわり

これから「TDD != ほげほげ」という論を展開しますが

● 「TDDであること」が

– 正しいとはかぎりません– 目的ではありません

TDD != 開発プロセス

● チームではなく、個人のプラクティス● アジャイルプロセスを前提としていない

● 規模にも関係ないと考えられる(Rodもそう言ってました)

つまり、独りでも出来ます

TDD != 品質保証技術 (again)

● TDDは「こうしてみようか」をテストする

● QAテストは「こうあってはならない」をテストする

TDDは品質向上技術だが、品質保証技術ではない。そもそも「品質」の話が必要

あなたにとっての「品質」とは何ですか?

TDD != テストファースト

● テストを先に書くかどうかが重要なのではない

– テストを先に書けばTDDというわけではない

– テストを後から書くTDDもある

● TDDはテストを書いて実行するという行為からフィードバックを受けて先に進むことを意識している

● 「直前に書くことと直後に書くこと」の差はそんなに大きくない

ではTDDとは何なのか

TDDは設計技法です

● 文脈

– プログラミングは設計行為である(J.Reeves)

– REDは仕様の設計

– GREENは仕様の実装

– Refactoringは内部設計の改善

参考：「ソフトウェア設計とは何か？」    http://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html

Drivenってどういうこと?

● ドライブ感– 「俺ってばスゲー」感

– Test Firstはフローの邪魔?

● ドリブン感 (駆動力と遠心力)– テストに実装を引き出される感覚

ドライブ感とドリブン感のバランスをとろう

Testに代わるいい名前はあるか

● 仕様(specification)● 意図(intention)● 振る舞い(behaviour)● 具体例、使用例 (example)

これは! という代替案がないのが実状

TDDを売り込んでみる

● 師曰く、マーケティングとは– 「わかってください」ではダメ– 「いいものだからわかってくれるはず」もダメ

– 相手に「わかるとお得かも」と思わせなければ

TDDを覚えると、何がお得なのでしょうか

TDDを行うと、何がお得?

● 「自信」「安心」– 自信をもって機能を追加できる– 自信をもってリファクタリングできる

● 設計改善● 軽微なバグの予防

● SbE(Spec by Example)– 動くドキュメント– 動くサンプルコード

どうやってTDDを始めたらいいか

● 「写経」– 『テスト駆動開発入門』– 『リファクタリング』

● ペアプロ● セミナー、ワークショップ

過程を見ないと、わからないかもしれません

組織にTDDを導入するきっかけは

● 草の根ルート

– TDDは個人タスク、一人でもできる

– まずは自分から習得– そして周りの人にペイ・フォワード

● 天災ルート

– 「TDDを導入せよ」の大号令

● お客さまたっての希望ルート– 私のプロジェクトもこれです– 最近多くなってきたようです

でも、上から降ってくると...

● 天災ルート、お客さまたっての希望ルートだと...

おそらく品質保証のテストだと考えています

だから、TDDを理解して、開発促進のためのテストも考えてみてほしいのです

終わりに

もう一度、結論をまとめると

結論 その1

● TDDはテスト技術ではない

● "Test"が指し示しているものは複数ある

– 開発促進と品質保証

– 2つの"Test"に優劣はない。「違う」だけ。

– どちらも非常に重要● テストをロールと目的で分類する

– 開発者 / 顧客 / 品質保証担当者

結論 その2

● TDDの"Test"は開発(者)のためのもの

– つまり、開発促進のテスト

● TDDの良さは設計技術でありながら品質保証技術に「かなり近い」こと

Enjoy Testing!

Special Thanks

● J2EE勉強会に参加されているみなさま● kakudaさん (J2EE勉強会のすばらしい世話人)● ひがさん (毎回発表ありがとうございます)● WRさん (実況スレお疲れさまです)● 八角研究所様(会場提供ありがとうございます)

● TDD産みの親である、Kent Beck氏

● そして、masarlさん

ご静聴ありがとうございました