-
- いいね！1
Ayumu AIZAWA
@ayumin
テストによって「バグがある」ことを検出はできるけれども、「バグがない」ことを証明することは出来ない（悪魔の証明っていうの？）
2010-02-15 01:24:21
おんでぃ
@120reset
仕様要求を満たしているかは確認出来るけど、テスト項目が項目を網羅しているかは確認するのが難しいんだと思う。要求されている充分なテストの範囲が特定し辛い。
2010-02-15 01:25:28
しろくろきつね
@skn9x
@yoshiori なるほど……。というかバグ件数を元に品質管理目標を定めるPJだとTDD入れた途端に崩壊するね。確かに品質の話はしないほうが良いかも……だけど、それだと何のためにTDDるのか説明しにくいなぁ。確かに悩みどころ。
2010-02-15 01:27:26
Ayumu AIZAWA
@ayumin
今のお仕事でシステムじゃないんだけど、事業再編後の会計システムが出力する決算の結果を経理部として承認する基準は何にするかっていう議論があるのだが
2010-02-15 01:28:11
わいさかき🥞
@ysakaki
統合テストレベルは要件からの方が判断しやすいことも多いと思いますが単体、結合レベルはテスト手法や統計方法色々確立されてると思いますけど違うのかな？ちなみに手法以前に試験フェーズが省略されたりする方が多・・・うわ何をする！
2010-02-15 01:29:55
ヨシオリX
@yoshiori
@skn9x TDD はやっぱり開発者が不安を無くすためなんだけど、極論で言えば print 文で目で確認するのがメンドイからコンピュータでも判るように 真偽で確認するようにしてますよってだけな気がするんだよね。
2010-02-15 01:31:27
ヨシオリX
@yoshiori
@skn9x で、コンピュータでもわかるようにしたから目で確認するのに比べて見間違いとかも無くなったし、 CI 使えるようになっりして、そうすると継続的にテストを繰替えす事をコンピュータがやってくれて、バグを早期発見出来るようになって品質が上ってくるとかかなぁ……
2010-02-15 01:33:17
ヨシオリX
@yoshiori
@cactusman 設計もちょっと言い過ぎな気がしてきた。目で値確認するのがメンドイから真偽値で確認出来るようにしてるでも良い気がしてきた
2010-02-15 01:34:36
Ayumu AIZAWA
@ayumin
@moro ここ数年 @t_wada がデベロッパーテストのことばかり煽るのでそろそろ別のメニューが欲しくなってきたｗ
2010-02-15 01:34:45
おんでぃ
@120reset
@ysakaki そこでAcceptance TDDってのがあった気がするんだけど、結局フェーズとしてのテストじゃないから粒度が大きいのが問題だったのと、普通のTDDみたいにリズミカルに出来ないのであまり一般化しなかったのかも。
2010-02-15 01:34:51
goyo
@goyoki
自分も反省しているけど、同じ主張でも「TDDでのテストは一般的なテストと同じ」という誤解と、「一般的なテスト設計手法を知ってるとTDDをもっとうまく運用できるよ」というアドバイスが混在してて、品質やテストの人が前者ばかり言っているわけじゃないんだよね
2010-02-15 01:37:26
Takuto Wada
@t_wada
品質保証のテストは TDD の文脈で言う「テスト」とは別に必要であり、品質保証のためのテストの価値はまったく減じていません、というのが私の意見です。 QT @moro: @t_wada 3行でまとめると「品質保証の テストは どうなった?」
2010-02-15 01:38:13