TDDにおける品質保証の考え方

Kazu SUZUKI @kz_suzuki

TDDをやっている人に、「REDになった場合、それはすべて単体テストのバグとしてバグ票を起票して納品してください」って言ったら暴動が起きるだろうか。

きんぢ @kjstylepp

@kz_suzuki 起きました #実話

TKG @oreshio

@kz_suzuki 似たようなこと言われたことあります。自動テストの効果がわからないので、テストコードを書いたときや自動ビルドのなかで見つかったバグをチケット（もしくは後から集計できるもの）に記載してください、と･･･。もちろん断りました。

Kazu SUZUKI @kz_suzuki

実話であるのかｗ

Kazu SUZUKI @kz_suzuki

しかし確かに、それまでユニットテストを紙（論理的なものも含めて）で作成して、そのテストで見つかったものをバグ票として記載していたのを、テストケースがコードになり、見つかったバグはプログラミングの一貫で修正されるのだとしたら、それまでの考え方をどう移行していいかわからないだろう。

Kazu SUZUKI @kz_suzuki

よくわからないで言ってます。

TKG @oreshio

@kz_suzuki それもありますが、目に見える形で費用対効果を知りたかったのだと思います。テストケース書いてた工数が防げたバグに見合うのかどうか。もちろんバグを防ぐだけがテストを書く効果じゃないですけど、そんなことは理解できないので。

TKG @oreshio

@kz_suzuki 効果が目に見えないんだったらやる意味ねーじゃん、って言いたくて「効果を出せ」と言ってくる人も居ました。ユニットテスト、テストの自動化をまったく信用していませんでしたね。あんた勉強不足だよって言ってやりたくなりましたが、上司だったのでこらえましたｗ

Kazu SUZUKI @kz_suzuki

@oreshio そもそも「テストの効果」をどう測るかが定まっていないと、その懸念を晴らす説明をするのは難しいですよね。手動を自動に変えるだけなら変わらないかも知れませんが、プログラミングとユニットテストの境目がない（？）と、これまで蓄積してきたデータも役にたたないので・・・。

Kazu SUZUKI @kz_suzuki

結局、ユニットテストにおけるバグとは何なのか、どう数えるのかがよくわかっていないんだな。数えることには意味があると思うけど、数え方が一貫していないとダメなんだろう。

SHUJI @shuji_w6e

@kz_suzuki 手段（ツール）としては同じモノですが、目的は異なるモノと考えると良いと思います。 つまり、プロダクトの品質をあげる目的と、開発そのものを促進する目的との違いです。

Kazu SUZUKI @kz_suzuki

@shuji_w6e ありがとうございます。前者が「普通の」ユニットテストで、後者がTDDで行うテストですか？ また、一つの開発で両方を行うことはあるのですか？ 間抜けなことを聞いていたら申し訳ありません･・。

SHUJI @shuji_w6e

@kz_suzuki うさみみ氏の見解。 glide.so/kyonmm/147d2ec…

SHUJI @shuji_w6e

@kz_suzuki はい。 とはいえ、ざっくりとした話でしかないです。はじめに手段（ツール）ありきで話すとおかしな話になります。 なので、両方やっている場合もあるし、片方だけの場合もあるし、同時にやっている場合だってあります。

SHUJI @shuji_w6e

@kz_suzuki 最終目的は、一定の品質のソフトウェアをリリースすることですので、その目的のためxUnit使っても良いですし（どう使うかの議論は勿論必要）、それとは別に開発をうまく回すためにTDDを導入することもありますね。

Kazu SUZUKI @kz_suzuki

@shuji_w6e 説明いただき、ありがとうございます！ 両方のケースもある、というのは意外でした。きょんさんのスライドも見てみます。

Kazu SUZUKI @kz_suzuki

「TDDのおいても、レッドはバグを意味するのだから、バグ票を切って管理すべきだ」と主張している、と思われていたらどうしようと震えているところ。

Kazu SUZUKI @kz_suzuki

TDDってユニットテストをデバッグに使う技の一つって解釈し始めた。特徴は、先にテストがあること。そのおかげで以降も何度もテストを回せる。いやこれはTDDの特徴ってわけではないか。 まあぼくが何も知らずにしゃべってることは理解いただけてるでしょう･・。

Kazu SUZUKI @kz_suzuki

やはり気になるのは、「最初からTDDな人たち」じゃなくて、「それまでプログラミング→ユニットテストという順番でやってたけどある時TDDに切り替えた人たち」が、従来型の品質管理（この場合は欠陥密度）をどう扱うことにしたか、ですね。欠陥密度など意味ないとして切り捨てるのか、別解釈か。

Kazu SUZUKI @kz_suzuki

開発のやり方を変えたら欠陥密度の傾向は変わると思うけど、その新しい開発でもやはり一定の傾向があるんじゃないのかな。欠陥密度など意味ない！という意見もあろうけど、個人的には、見えない品質をざっくりと把握するには避けられないもの、とも思う。

Kazu SUZUKI @kz_suzuki

結局、ユニットテストが終わった段階でのプロダクトがどういう品質なのかを測る知恵を、僕があまりに知らないということなんだろうな。テストケース密度、欠陥密度、成長度信頼曲線、コードカバレッジ、コードメトリクスもろもろ？ どれも「間接的」で、ものによっては「統計的」過ぎるように思う。

ネモトノリユキ＠ソフトウェアテスト技法練習帳 発売中！！ @nemorine

仕様書に置き換えて考えると、書いてる途中のセルフチェックに近いと思うよ。例えばWORDでバーっと文章書いて、よく見ると赤い波線が･･･で直しました。これって、仕様書の不備＝バグに入れる？？それと同じイメージだと思うよ。 @kz_suzuki

ネモトノリユキ＠ソフトウェアテスト技法練習帳 発売中！！ @nemorine

TDDを使ってコード完成したあとに、バグが出た場合は欠陥密度に入れていいと思うなー TDD実施時はコードを作り途中なので、そこを欠陥に入れるのはあまり意味ないと思う。この前きょんくんの話を聞いて、なまじテストって付いているから混乱するんだと思った次第。 @kz_suzuki

Kazu SUZUKI @kz_suzuki

@nemorine なるほどー。テストコードが用意されてるという点をそのアナロジーで考えると、「保存」するたびにスペルチェックが入ってるイメージですかね？

ネモトノリユキ＠ソフトウェアテスト技法練習帳 発売中！！ @nemorine

ですです。それに近いと思ってます。チェックの方法を自分で定義しているというイメージですね。 @kz_suzuki