テストを軽視する者ども

**仕様書無しさん** · 2008/06/28(土) 19:49:20

何だよ、８割方終わった風な顔で、「コーディング終わりました。後はテストするだけです。」
って...
コーディングが終わってやっと３割終わったかどうかってところだろが。
コーディングが終わってからが本番だっちゅーの。テスト仕様書に従い、テストデータ用意して、
正常系、異常系含めて、抜かりなく全網羅テストすること。これがどれだけ大変なことか。
本当に理解してんのか？　コーディングが終わってやっとスタートラインに立ったぐらいの気持ち
でいろよ、ってくヘラヘラしやがって。

こういう、テストを軽視する輩共が、プログラミングという作業を軽んじ、工数見積りを誤り、
徒に製造を急かし、バグの混入率を間接的に高めているということに気づかんのか。
どんな優秀な奴だって、人間だもの、間違いを犯す。バグを生み出す。それを極力未然に防ぐのが
テストだろ。いつバグが判明するかとドキドキしながら納品後の時間を過ごすか、自信と満足感を
もって笑顔で過ごすか。どちらがいいか自明のことだろ。

プログラミングはなぁ、テストに始まりテストに終わるんだよ。要件を理解し、その中に潜む異常
パターンを見抜き、どんだけ抜かりなくテストをやれるかが一流とカスを分かつ分水嶺だ。
コーディングなんかできてあたり前、肝心なのはテストだ。テストを極めてこそ、一流のプログラ
マーって呼べるんだよ。

この馬鹿者どもが。

**仕様書無しさん** · 2008/06/30(月) 00:57:44

魑魅魍魎が跋扈するこの業界で、ユニットテストこそ
プログラマが唯一信じられるもの。
俺の作業からユニットテストを奪われたら、俺は泣く。

**仕様書無しさん** · 2008/06/30(月) 01:01:59

>>66
>>42とか

**仕様書無しさん** · 2008/06/30(月) 01:07:33

>>58とかも

**仕様書無しさん** · 2008/06/30(月) 01:16:19

ageてる奴は、公開されないクラスのC0カバレッジが100%でなくともいいって主張？

**仕様書無しさん** · 2008/06/30(月) 01:22:17

>>36
お前さんの言う「大規模プロジェクト」って何人月くらいなんだ？
んで、QTPとやらの一人当たりのライセンス料はいくらで、習得コストはどれくらいなんだ？

**仕様書無しさん** · 2008/06/30(月) 01:23:53

信頼性に興味がないのでしょう。

**仕様書無しさん** · 2008/06/30(月) 01:33:11

>>68 >>69
コストじゃなくて、「細部」を見るのか「全体」を見るのかの話してるように見えるが。
ただ、テストケース作って勧めるテストドリブンと
テスト工程を前に持ってきただけってのは、大きく違うからそこで話がかみ合ってないんだと思うが。

**仕様書無しさん** · 2008/06/30(月) 01:44:10

大規模プロジェクトでは、UnitTestは意味無くて、「QTPで行う単体テスト」は意味あるということか？
QTPというのは使ったことないけど、QTPで意味があるなら、UnitTestでも意味があると思うがな。
なぜUnitTestじゃダメなのか、そこんとこもっと詳しく。

**仕様書無しさん** · 2008/06/30(月) 01:47:17

大規模プロジェクトになると、仕様の矛盾がそもそものBUGの原因になる事が多いよな。

**仕様書無しさん** · 2008/06/30(月) 01:50:45

テストパターンってなんだよ？
ま、それはともかく、1が何を言いたいのかいまいちよくわからんな。
QTPはすばらしい、QTPを使ってるウチはすばらしい、以上の主張が見えない。

**仕様書無しさん** · 2008/06/30(月) 01:52:05

バカの一つ覚えと言う言葉がありまして。

**仕様書無しさん** · 2008/06/30(月) 01:52:20

どんなに大規模なプロジェクトでも、レイヤーや機能で分割されてチーム分けされると思うのだが。

**仕様書無しさん** · 2008/06/30(月) 01:55:51

あげてる奴が1だとすると、大体においては賛成なんだが、各論総反対、みたいな感じ。

**仕様書無しさん** · 2008/06/30(月) 18:09:49

>>74
結論から言おう。

ユニットテストをプログラマーが行うとして以下の問題がある。
- 優秀な奴とそうでない奴の差が激しく、属人的でテストの品質がばらつく。
- プログラマーは納期が厳しい。ユニットテストは真っ先に手を抜かれる。
- プログラマーとテスターの両方の能力を持つ人材が少ない。
- プログラマーはテストが嫌い。
- プログラマーが設計するとして、間違った設計をする奴に正しい
テストを書けるはずがない。
- コーダーは、設計の通りにコードを書く。
コーディングに支障がない限り、間違った設計でもそのままコードに
してしまう。コーダーにはユニットテストを書くことはできない。

「チーム内のプログラマー全員が、律儀にユニットテストをこなす。」
という期待は捨てた方がいい。

ポイントは、テストのプロを雇ってテストに専念させる事にある。
「第三者によるテスト」が重要。

>>78
分割すると管理コストが増えるし組織が複雑になる。
そして、意思疎通が難しくなる。
問題が形を変えるだけで何も解決したことにはならない。

**仕様書無しさん** · 2008/06/30(月) 18:15:00

>>74
ユニットテストを否定するつもりはない。ちゃんとやればかなり効果的だ。
ただし、期待したとおりにプロジェクトは進まない。

ユニットテストは、最後の砦ではない。システムテストが最後の砦だ。

テストを厳密にやるという事に取り組んだことがあるが、コストがかかる
という理由で断念した。

ビジネスの世界の最終目的は、金儲け。対投資効果が得られないと長続き
しない。100%の結果を得るのに100億かかるとして、80%の結果を得るに
40億で済むなら。会社は、後者を選び仕事の量を倍にする。

**仕様書無しさん** · 2008/06/30(月) 19:23:52

>>80
だから、お前が言う「大規模」ってどのくらいだよ？

> >>78
> 分割すると管理コストが増えるし組織が複雑になる。
> そして、意思疎通が難しくなる。

もちろんそうだが、しかし現実は分割されるだろ？

それに、数百人規模（数千～数万人月）のプロジェクトの場合、一時受けが作業を
一括で請け負って（もちろんその先に有象無象がいるわけだが）、プロジェクト全体で
プロセスを強制することすら不可能な場合が多いのだが。

**仕様書無しさん** · 2008/06/30(月) 19:24:46

ビッグバンテスト信者ですか

**仕様書無しさん** · 2008/06/30(月) 19:29:54

ユニットテスト終了＝納品と勘違いしてるんじゃね？

**仕様書無しさん** · 2008/06/30(月) 19:33:05

あれ？>>36=>>80じゃないのか？いってることが全然違うぞ。
わかりづらいから、数字コテハン使ってくれ。

**仕様書無しさん** · 2008/06/30(月) 19:38:36

だが断る

80 · 2008/06/30(月) 19:56:07

>>82
数百人もいない。100人強だな。そして、全員が精鋭ではない。

あと、実際には分割される。協力企業もいる。
協力企業に開発プロセスを強要できない。請負だからね。

ユニットテストは、CppUnit, JUnitとか単体テストを自動的に行う
あれのことを言っていると思ってるのだが。
単なる単体テストの事なら、今まで俺が書いた事は忘れてくれ。
単体テストは必須だ。

テストを自動的に行うために、テスト自動化用のコードを書いて
メンテナンスを行うのはコストが高くて現実的でないというのが
俺の意見だ。
工数のかかる言語、たとえば、C++/CLIで書いたコードを
工数のかからない言語、VBでテストを書くならまだ納得だ。
テスト用のコードをいかに少ない工数で書くかが重要だと思う。

80 · 2008/06/30(月) 20:03:05

近頃のテストの世界では、「カバレッジ」を諦めている節が見受けられる。
ユニットテストで、網羅的にテストを行うと実際のアプリケーションで
は、絶対使用されないシナリオまでテストをする事になってしまう。
それを排除しようとする動きだ。

顧客の要求を満たすためのみにテストすべきだ（それ以外は
やっている時間がない）というトップダウンのアプローチも、ソフトの
規模が大きい昨今ではありなのかもしれない。

**仕様書無しさん** · 2008/06/30(月) 20:03:53

>>87
QTPの人？
QTPのライセンス料＋教育費は一人当たりどれくらい？

**仕様書無しさん** · 2008/06/30(月) 20:05:08

>>88
C0カバレッジ100%は必須なの？必須じゃないの？

**仕様書無しさん** · 2008/06/30(月) 20:08:08

単にユニットテストと聞いてxUnit連想するか？

**仕様書無しさん** · 2008/06/30(月) 20:11:47

>>80
なんつーか、大筋は同意できるんだが、品質保証と効率的なプロセスとはという点では全く同意できない。

**仕様書無しさん** · 2008/06/30(月) 20:14:47

>>87
スキルがばらばらの100人超のプロジェクトなんだろ？

>顧客の要求を満たすためのみにテストすべきだ（それ以外は
>やっている時間がない）というトップダウンのアプローチも、ソフトの
>規模が大きい昨今ではありなのかもしれない。

無いよ、絶対に。

**仕様書無しさん** · 2008/06/30(月) 20:18:54

単体テスト工程を自動にしない奴って、それ以降のテスト工程でコードに修正が入ったとき、
どうやってリグレッションテストをやるんだろうか。

まぁ、やらないんだろうけど。

80 · 2008/06/30(月) 20:26:47

>>89
導入を考えているのか？正確にはHPに聞いた方がいいぞ。
一概には言えないからね。ライセンス形態もいろいろだし。
アプリにもよるし。

10名程度のテストチームで運用するとして、
数千万円くらいかかるんじゃないかな。

>>90
C0を100%にしたからといって、万事OKではない。
逆にC0が50%でも全体としては、OKかもしれない。
必須かどうかと言われれば、必須だが。1000万行を超すコードで
どこまでできるかが問題だ。

逆に、質問なんだが。
C++で言うテンプレート、C#とかで言うジェネリクスを使ったコードを
テストするのにカバレッジはどう考えたらいい？

>>91
文面から見て、そんな気がしたんだが。

**仕様書無しさん** · 2008/06/30(月) 20:31:13

100人で1000万行？
一人10万行？
一体、何人月のシステムなんだよ？

**仕様書無しさん** · 2008/06/30(月) 20:31:28

>>92
「限りのあるリソースで膨大なテストを作って挫折するやり方」と
「与えられたリソースで最も効果的にテストを行うやり方」
なら俺は後者を選ぶ。

**仕様書無しさん** · 2008/06/30(月) 20:33:28

>>95
> 10名程度のテストチームで運用するとして、
ありゃ？
開発者（プログラマ）がQTP使うんじゃないの？

> 逆に、質問なんだが。
> C++で言うテンプレート、C#とかで言うジェネリクスを使ったコードを
> テストするのにカバレッジはどう考えたらいい？

どう考えるも何も、C0カバレッジに考えることなんてあるのか？

**仕様書無しさん** · 2008/06/30(月) 20:34:41

>>97
その後者を実現させる一つの方法が、ユニットテストだと思ってるんだよ。
だから、その点は全く同意できない。

**仕様書無しさん** · 2008/06/30(月) 20:39:08

テストチームがQTPでテストするとして、プログラマはどうやって単体テストしてるんだ？

80 · 2008/06/30(月) 20:40:20

>>98
プログラマーとテスターに別に壁はないので、テスターが管理している
QTPをプログラマーが使わせてもらうことも可能。テストコード自分で
書いてテスターによろしくーってのもあり。柔軟にやってる。

>>99
ユニットテストってどういうものを言ってるんだ？
xUnit?、単なる単体テスト、テストファーストの考え方？アジャイル？

**仕様書無しさん** · 2008/06/30(月) 20:42:24

え？QTPってテストコード書くのか？
だったらなぜQTPはよくてUnitTestが悪いのか、わけわからん。

80 · 2008/06/30(月) 20:50:11

>>102
xUnitだとテスト用のコードを書くのに時間がかかるし、テスターには無理。
QTPのテストコードは、VBScriptでテスターでも書こうと思えばかける。
しかも、自動的にVBScriptのテストコードを生成する機能も付いている。

**仕様書無しさん** · 2008/06/30(月) 20:53:54

え？テスターとプログラマに壁はないけどスキルの壁はあるのか？
どうでもいいけど、>>100の回答プリーズ。

**仕様書無しさん** · 2008/06/30(月) 20:55:25

QTPだと時間がかからないのは、使いなれてるから。
どんなツールでも慣れれば時間がかからなくなる。
xUnitが時間がかかると思ってるのは、よく知らないか、慣れてないから。

99 · 2008/06/30(月) 20:59:06

>>101
ユニットテストとは、テストの種類。イコール単体テスト。
使うツールは何でもよいが、アドホックなものや繰り返し不可なものは駄目（俺的に）。

80 · 2008/06/30(月) 22:01:59

>>104
一般論を言うと、QTPは、システムテスト用のツールでそもそもユニット
テスト用ではない。が、うちでは、ユニットテストにも使ってる。
テストコードは、プログラマが書くが、テストはテスターがやっている。
テストコードは、テスト用データを入力できるようになっている。
テスト用データを用意するのはテスター。

・・・つーかうちの会社の特殊事情聞いてどうするんだ？一般的だとは
言ってないぞ。

80 · 2008/06/30(月) 22:04:42

>>106
システムテストはやらないのか？
たぶんやるだろ。

ユニットテストとシステムテストはどちらが大切だと思うんだ？
俺はシステムテストだと思っているんだが・・・。

ユニットテストだけでまさか出荷していないよな。

**仕様書無しさん** · 2008/06/30(月) 22:18:22

>>12
鉄道動かすプログラムですが、客にバグ出しさせますね＾＾ｖ

**仕様書無しさん** · 2008/06/30(月) 22:37:47

テストできない仕様は作らない設計。

**仕様書無しさん** · 2008/06/30(月) 23:13:53

テストはそこそこでいいよ

**仕様書無しさん** · 2008/06/30(月) 23:26:02

>>107
>テストコードは、プログラマが書くが、テストはテスターがやっている。
なぁ、これテストのプロなのか？

>・・・つーかうちの会社の特殊事情聞いてどうするんだ？一般的だとは
>言ってないぞ。
一般論としてユニットテストを否定してるんだろ？だからどうやってるのか聞いてるんだけど。

>>108
>ユニットテストとシステムテストはどちらが大切だと思うんだ？
どっちも大事に決まってるじゃん。
従来のウォーターフォール的なテストのやり方だと工数が膨らむから、ユニットテストに
力を入れようぜって話だ。

つか、はっきり言って、お前がPMだとしたら、その下でできた1000万行のシステムなんか
受け入れたくないわ。

**仕様書無しさん** · 2008/07/01(火) 00:24:29

あげてみるテスト

**仕様書無しさん** · 2008/07/01(火) 00:35:37

>>107
> テストコードは、プログラマが書くが、テストはテスターがやっている。

テストコードをプログラマが書くだって?
テストの品質がばらつくからそりゃ駄目だって主張してるんじゃないのか?

>>80
> - 優秀な奴とそうでない奴の差が激しく、属人的でテストの品質がばらつく。

**仕様書無しさん** · 2008/07/01(火) 01:27:50

プログラマが書くテストコードは、実際のソースコードの前提条件みたいなもんだよ
「テストの品質」っていうテストは受け入れテストみたいな顧客に近いレベルのテストだね
つまりテスターがやるテストはプログラマがやるテストとは別ってこと

**仕様書無しさん** · 2008/07/01(火) 01:54:44

ブラックボックスとホワイトボックスの違い？

80 · 2008/07/01(火) 06:28:14

>>114
ユニットテストのテストコード -> テスター＆プログラマー
システムテストのテストコード -> テスター

うちのテスターは、すべての仕様書や設計書を読む。
全てのテストは、テスターの監視下で行われる。
もちろん、プログラマーの書いたテストコードも監視下に置かれている。

ユニットテストよりもシステムテストに重きを置いている。
システムテストのカバレッジは100%必須。未達成ならリリースはない。
ユニットテストに関しては、残念ながらカバレッジ100%を待てない。
大抵のプログラマーは、時間切れに陥る。十分な時間を与えてもだ。

プログラマーは、余った時間があればコードを洗練させるがテストは
しない。プログラマーは、テストが嫌いな生き物だ。

80 · 2008/07/01(火) 06:40:46

>>115
同意。顧客はテストにも金を払っている。ユニットテストは、顧客にとって
のテストではない。プログラマーの失敗を補うものと思われるので
なかなか顧客には納得が得られない。単体テストとデバッグの違いを
明確に区別して作業しているプログラマーがどれだけいることか・・・。

テスターは、あくまでもシステムテストに主眼を置いている。
ただし、うちはテスターが開発初期からアサインされ、
要求把握、分析、設計、ユニットテスト・・・といろいろな工程を
監視している。

一般的には、ユニットテストは、テスターの仕事ではない。
しかし、ユニットテストが本当に重要だというのなら。
プロに監視してもらうのも一案だし、うちでは、効果があった。

**仕様書無しさん** · 2008/07/01(火) 08:51:27

優秀なテスターは、外部テストだけでプログラムの構造、BUGの場所と実装具合が分かる。

**仕様書無しさん** · 2008/07/01(火) 19:54:57

テストの経験を積ませてくれない90人は不幸だよな

80 · 2008/07/01(火) 23:47:14

>>119
同意。さらに言うなら、外部テスト（ブラックボックステスト）で
問題をちゃんと把握できるシステムは良いシステムだと思う。
「テスト可能なシステム」とうわけだ。
ユニットテストに主眼を置かなければ品質を保てないシステムは、どこか
おかしいと思うのだが・・・。

**仕様書無しさん** · 2008/07/01(火) 23:59:12

良くわからんが、テスト駆動の
テスト→実装→レビュー→コミットしてデイリービルドへ
の「テスト」と、完成後の受け入れテストは違うモンだろ？
両方やるんじゃないのか普通。
うちは受け入れテスト（というか、納入前の自社内受け入れテスト）は、専門のテストチームがやってるが。
テスト駆動開発とそうじゃないので、バグ発生件数が如実に違ったから、社内でテスト駆動流行りだした。

**仕様書無しさん** · 2008/07/02(水) 00:07:17

仕様が明確な場合は有効だと思うが...仕様がなぁ...ころころ変わるぐらい
ならまだしも、がらっと変わるときあるからなぁ。根底から。せっかく作った
テストもぱぁ。せっかくいい調子でやってたのに、モチベーションを木端微塵
にしてくれるよなぁ...　あ、スレチスマソ

**仕様書無しさん** · 2008/07/02(水) 00:30:44

80はユニットテストに主眼を置けと言われてると思ってるみたいだな。
ユニットテストを軽視するなっつーのが大半の意見だと思うけどな。

ユニットテストの自動化を意識してる所は、当然、機能テストもシステムテストも
受け入れテストも自動化を意識してると思う。ユニットテストやってるから、テスト
可能なシステムになってないとでも思ってるんかいな。

それと、機能テスト以外の話が出てこないが、本当のテストのプロは、機能テスト
以外に力を入れるもんだけどな。たとえばISO 9126に基づく品質保証をめざすとかな。
（蛇足だが、テストチームを外部委託すると、確かに数割はテストのプロがいるが、
残りは二重派遣とかが多いぞ。会社名は出さないが、TEF協賛の品質保証専門の
会社のいくつかはそうだ。全部と付き合いがあるわけじゃないから、全部がそうだとは
言わんが）
それから、はっきり言って、コード書けないテスターは「プロ」とは言いたくない。
テスト対象の言語特性も標準ライブラリの仕様も知らずに、効率の良いテストなんか
できるはずない。

プログラマは、本質的にはテストが好きだと俺は思うぞ。まぁこれは定量的な
評価ができないから水かけ論になるだろうが。

ユニットテストが重要なのは、それが設計という意味でのコードの品質を上げる手段に
なるからだ。自分でユニットテストをやらなくては、真の意味でのTestabilityを
考えられるようにはならないと思うぞ。詳しくは説明しないが、ユニットテストは
保守性を大きく向上させる手段になりうる。

80のプロジェクトでは、たまたまうまくいってるんだろうが、ユニットテストレベルのバグが
ぼろぼろ出るプロジェクトは、テスト技術者のモチベーションを著しく落としめて、
プログラマ対テスターという対立構造を生みやすい。

**仕様書無しさん** · 2008/07/02(水) 00:35:08

長い

**仕様書無しさん** · 2008/07/02(水) 00:38:17

すまねー。
でも言い足りん。
またどこかで。

**125** · 2008/07/02(水) 00:39:30

いや、すまん。
俺以外の住人は待ってるのかも知れん。
続けてくれ。

**>123** · 2008/07/02(水) 01:24:09

使えなくなった(使わなくなった)コードは"習作"と割り切って捨てるが吉
下手に利用しようとして傷口を広げるべからず

**仕様書無しさん** · 2008/07/02(水) 03:03:17

>>117
> システムテストのカバレッジは100%必須。

そんなことをやっていたら時間がいくらあっても足りない。
たいていのテスターは時間切れに陥る。十分な時間を与えてもだ。

**仕様書無しさん** · 2008/07/02(水) 03:08:56

> ユニットテストよりもシステムテストに重きを置いている。
> システムテストのカバレッジは100%必須。未達成ならリリースはない。
> ユニットテストに関しては、残念ながらカバレッジ100%を待てない。

これはどういうことを意味するか。

それは、システムテストのカバレッジが100%でも
ユニットテストのカバレッジは100%ではないということ。

つまり、バグがあったとしても、システムテストの
カバレッジが100%になるということを意味する。

これが最近巷でよく発生している「ごくまれな事例において発生する不具合」に
つながっている。つまりテスト不足。

そしてそのいいわけがこれ。
> ユニットテストに関しては、残念ながらカバレッジ100%を待てない。
> 大抵のプログラマーは、時間切れに陥る。十分な時間を与えてもだ。

言い換えると、時間が足りないからテストを省くという意味である。

**仕様書無しさん** · 2008/07/02(水) 08:12:27

よくある現実
マ「すいません、これ以上仕様変更があると改修はともかく
　テストが間に合いません」

上司「テストなんて現地ですればいいよ」

・・・

客「なんだこの不具合だらけのシステムは！こんなものをリリースするなんて
　おたくはいったいry)」

**仕様書無しさん** · 2008/07/02(水) 08:50:19

>>131
それで上司が
「俺は関係ない、部下の独断だ」
とか言ったら最悪だな。

**仕様書無しさん** · 2008/07/02(水) 13:10:02

>>132
それに近いことは言うけどな
「すいません、開発担当のものたちがスケジュールの調整でうんぬん」

結局自分以外の誰かを悪人にしないとすまないらしい

80 · 2008/07/02(水) 21:26:47

>>124
「テストファースト」は賛成だが、「テスト駆動」は反対だ。
前者は、ソフトを作る時に先にテストを考えるというアプローチだ。
後者は、テストに基づいてプログラミングをするということなんだろう。

**仕様書無しさん** · 2008/07/02(水) 21:35:17

>>134
テストに基づいたプログラミングが、イコール設計に基づいたプログラミングと読めないうちは素人だな。

**仕様書無しさん** · 2008/07/02(水) 21:36:21

テスト＝設計書という前提だがな。

80 · 2008/07/02(水) 21:42:14

>>135
プログラミング可能なテストということなんだろ。
コード化が可能なほど詳細に書かれているテストってどうやって記述
してあるんだ？

設計とテストがイコールということは、設計書のタイトルをテスト仕様書
に変更しても問題ないということか？

テストは、設計からすると客観的な別の存在であるべきではないのか？

**仕様書無しさん** · 2008/07/02(水) 21:44:10

世の中には外部設計と内部設計とがあってだな（ry

80 · 2008/07/02(水) 21:53:46

>>138
外部設計と内部設計は、誤った用語で今は死語になっている。

設計に内部も外部もない。
作りたい対象の詳細が書かれているものが設計書。
外部と内部の区別はない。

80 · 2008/07/02(水) 22:16:44

>>130
>それは、システムテストのカバレッジが100%でも
>ユニットテストのカバレッジは100%ではないということ。
>つまり、バグがあったとしても、システムテストの
>カバレッジが100%になるということを意味する。
システムテストのカバレッジが100%＝ユーザーに発見できるバグは0個と
言う定義なので、もしバグが見つかったらシステムテストのカバレッジ
が100%ではなかったということになる。

ユーザーがバグを発見できるということは、それは、システムテストで
テスターでも発見できるはずのバグと言える。

ユニットテストをちゃんとしておくとテスターは楽になる。
でもユーザーには関係がない。

**仕様書無しさん** · 2008/07/02(水) 22:29:57

>>139
顧客に言えよw

**124** · 2008/07/02(水) 23:27:10

うーんと、とても100人で1000万行のシステムを作ってる人の発言とは思えないんだよなぁ。
反論するのもアホらしいというか。
かまってちゃんの学生さんって気がしてきた。

**仕様書無しさん** · 2008/07/02(水) 23:34:18

100人で1000万行が本当だとしても、多分>>80は、まともにコードが書けなくてVBScriptくらいでしか
テストが書けない10人いるテスターの下っ端だろ。
しかも、派遣テスターｗｗｗ

**仕様書無しさん** · 2008/07/02(水) 23:54:15

アナログ（エンドユーザ）　と　デジタル（プログラム）
の間をとりもつのがテスト。
それぞれ言い分や希望、得手不得手、好き嫌いが異なるのは
当り前。そこはお互いを尊重し譲歩すべきは譲歩し、テスト
という愛の証、いわば結婚指輪があってこそ両者は結ばれる。
テストのない結納（納品）は、すぐに破局を招くのが必定。
ワハハハハハハハッ　なんのこっちゃ

**仕様書無しさん** · 2008/07/03(木) 00:06:52

100人で1000万行のシステムで、外部設計も内部設計もない設計書しか作らないってどういうこった。
クライアントとレビューして承認してもらうというマイルストーンは無いのか？
仮にあったとして、実装仕様てんこ盛りの仕様書をレビューしてもらってるとかか？
それとも、実装仕様がほとんど書かれてない仕様書しか作らないのか？
それで、スキルがばらばらなプログラマ９０人で、ちゃんとしたユニットテストも行われず、
どうやって品質を担保してんだよ。

その回答が、プロ１０人によるシステムテスト？

**仕様書無しさん** · 2008/07/03(木) 00:24:57

>>117
> システムテストのカバレッジは100%必須。未達成ならリリースはない。

>>140
> システムテストのカバレッジが100%＝ユーザーに発見できるバグは0個と
> 言う定義なので、もしバグが見つかったらシステムテストのカバレッジ
> が100%ではなかったということになる。

カバレッジが100%に達成したことを証明できる人は誰もいないので、
リリースは永遠にないのですね。わかります。

**仕様書無しさん** · 2008/07/03(木) 00:53:15

プログラマの心理とすれば、テストってめんどくさいんだよね。
特に結果が分かりきってる（と自分で思い込んでいる）メソッドのテストコード
をいちいち書くのがね。
で、俺がこの前ミスったのは、Cのコードで

double some_calc(int a, int b) {
return d = a / b * 12.34;
}

みたいな感じの奴。こんな四則演算なんて間違えようがないだろって高を括ってた。
ちょっとした油断でバグって生まれるんだよなぁ。
上の書き方だと、
some_calc(6, 2) だと問題無いが、
some_calc(2, 6) だと期待した結果にならないわけで。当り前だけど。

正解は、return d = (double)a / (double)b * 12.34;
などとキャストするか、引数をdoubleにしとくべきでした。

と、あらためてユニットテストの重要性を認識したしだい。デグレを起こさないため
にもね。

**仕様書無しさん** · 2008/07/03(木) 00:55:48

うわ、間違ってた。
return d = a / b * 12.34;
じゃなくて、
return a / b * 12.34;
ね。下の奴も同じく。

**仕様書無しさん** · 2008/07/03(木) 00:58:01

投下するレスのユニットテストも必要だな

**仕様書無しさん** · 2008/07/03(木) 01:02:24

面目ない。。。。

**仕様書無しさん** · 2008/07/03(木) 01:06:44

>>80のおかげでユニットテストの重要性を再認識できました。
ありがとう！！>>80

**仕様書無しさん** · 2008/07/03(木) 20:39:02

>>149
俺たちがバグ出しするから問題ないよ

80 · 2008/07/03(木) 23:58:00

>>151
いったんユニットテストを頑張って本当にバグが無くなるかを
試せばいい。経験は大切だと思う。
そのためには、ユニットテストのおかげでバグが減ったことを証明する
方法、つまり指標を決定しなくてはいけない。

まさか闇雲にユニットテストを行うわけじゃないだろ。

>>147
プログラミング能力の低さを、ユニットテストで補うつもりなら
よした方がいい。プログラミングスキル向上の方に力を注いだ方がいい。

> double some_calc(int a, int b) {
> return (double)a / (double)b * 12.34
> }

問題点１：
　関数の仕様がありえない。
　int -> double

問題点２：
　b の 0 かどうかのチェックが必要。0 除算くらいは避けよう。

問題点３：
　掛け算から先にする。説明が面倒だからググれ。浮動小数点
で演算する場合は、精度を意識しよう。

以上３つの問題点は、ユニットテストでは見つからない。
なぜかって？プログラマーのレベルを超えるユニットテストが行われる
事は不可能だからだ。

**仕様書無しさん** · 2008/07/04(金) 00:03:14

＞問題点３
＞掛け算から先にする。

え？

**仕様書無しさん** · 2008/07/04(金) 00:04:08

つかユニットテストコードは先に書け

**仕様書無しさん** · 2008/07/04(金) 00:08:45

なんかとんでもないこと言い出したな・・・
調子に乗らずにちょっと前までのレスで終わりにしてれば締まってたのに

80 · 2008/07/04(金) 00:13:45

>>155
テストファーストの事だな。

>>154
よーく考えてみよう。
ちなみに掛け算から先にする理由は２つある。

**仕様書無しさん** · 2008/07/04(金) 00:14:57

>>147
プログラミングを軽視する者ども
というスレ立てても良いですか？

**仕様書無しさん** · 2008/07/04(金) 00:19:57

>>158
「マを侮るなかれ」
ってスレがいいと思います

**仕様書無しさん** · 2008/07/04(金) 00:29:17

80さんよ
一応言っておくが>154は「かけ算から先」がコードの解説と勘違いしてると思われ
俺もそう勘違いしたけどね

問題点と書きながらいきなり修正案を書くのはアホだろ

80 · 2008/07/04(金) 00:37:43

>>160
なるほど。そこまで意識していなかった。
確かにその通りだ。

一応、掛け算を先にする理由を書いておく。
掛け算を先にするとたとえ引数がintでもキャストする必要がなくなる。
演算子は、暗黙のうちにオーバーロードされるからね。

あと、割り算してすごい小さな値になったらその時点で精度が
落ちてしまうから先に掛け算をする方が良いのだ。

分かっている人からすると「何をいまさら・・・。」だろうけど
念のためにね。

80 · 2008/07/04(金) 00:43:03

話はそれたけど、結局、プログラマーがユニットテストで解消される
バグは、プログラマーの能力に依存することは分かったと思う。
それでも、ユニットテストは必要だ。ただし、あまり依存しすぎては
いけない。

アジャイルとか、テストファーストとか言っているカリスマプログラマーの
意見は、「天才プログラマーだからこそできる芸当である。」という事を
念頭に置くべきだ。

ユニットテストで成果を出すための前提条件は「高度なプログラミング
能力に裏付けされた分析・設計能力を備えた人材が揃うこと。」
だと俺は思う。

**仕様書無しさん** · 2008/07/04(金) 00:44:22

どっかの糞コテの文体に似てきたなあ・・・

**仕様書無しさん** · 2008/07/04(金) 00:45:08

おれは３．５流ＰＧだけど、
だからこそ
作ることよりちゃんと仕様を満たすことの確認こそに命をかける

もってっけー

**仕様書無しさん** · 2008/07/04(金) 00:59:16

正常系なんて客にやらせる
異常系は自分でやる

これだけやりゃ十分

**仕様書無しさん** · 2008/07/04(金) 02:24:20

>>162
>話はそれたけど、結局、プログラマーがユニットテストで解消される
>バグは、プログラマーの能力に依存することは分かったと思う。

そこが、まず間違えで、ユニットテストはバグを解消するモノではなくて、
外部仕様（入力・出力・副作用の具体例）そのもの。

今時、テストファーストではない開発は、「ゴールの決まっていないマラソン」
とおなじようにナンセンスだと思うけど、、、

>ユニットテストで成果を出すための前提条件は
>「高度なプログラミング能力に裏付けされた分析・設計能力を
>備えた人材が揃うこと。」

仕様を網羅するユニットテストを作れないということは、
設計できないということと同義。

ユニットテストを作れるくらい全然「高度な人材」ではないと思う。

# 最後はレビュアーの腕次第とはいえ、コード・カバレッジの自動計測
# など網羅性をはかるツールもいろいろ出てきているし、、、