テストを軽視する者ども

[1 仕様書無しさん 2008/06/28(土) 19:49:20]

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

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

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

この馬鹿者どもが。

[161 80 2008/07/04(金) 00:37:43]

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

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

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

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

[162 80 2008/07/04(金) 00:43:03]

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

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

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

[163 仕様書無しさん 2008/07/04(金) 00:44:22]

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

[164 仕様書無しさん 2008/07/04(金) 00:45:08]

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



もってっけー

[165 仕様書無しさん 2008/07/04(金) 00:59:16]

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

これだけやりゃ十分

[166 仕様書無しさん 2008/07/04(金) 02:24:20]

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

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

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

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

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

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

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

[167 仕様書無しさん 2008/07/04(金) 02:40:19]

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

テストファーストという言葉があるように、
バグが発生する前から、テストを書くことができるわけなんだよな。
バグが発生する前というのは、コードをかくまえってこと。

ということは当然、コードを書く人ではなく、
仕様を書く人がテストを書いて、あとは実装者に任せるということも可能なわけだ。

だから仕様書を作る人が、テストコード書けばいいんじゃね？
プログラミングができない人が、設計をするのがどれだけナンセンスなことか。

[168 仕様書無しさん 2008/07/04(金) 02:47:02]

携帯電話なんて、発売後に顧客が実地テストさせられてるよなw

[169 仕様書無しさん 2008/07/04(金) 02:49:50]

あれは顧客じゃない
βテスター

[170 仕様書無しさん 2008/07/04(金) 02:53:07]

いや、あの製品とか、あの製品とか。あの製品とかの話だよ。

[171 仕様書無しさん 2008/07/04(金) 02:54:15]

金払ってまでβテスタに立候補するなんてステキ

[172 仕様書無しさん 2008/07/04(金) 03:00:04]

カネ貰ってもお断りしますってカンジだな

[173 仕様書無しさん 2008/07/04(金) 05:16:42]

>>80
>>145にコメントしろ、カス

[174 仕様書無しさん 2008/07/04(金) 05:26:42]

携帯なんて所詮おもちゃ。品質は一番あとまわし。
軍事・航空宇宙・医療機器・発電所とかだと品質が命。

80は何作ってるんだろうね？候補は大体想像つくけど。

[175 仕様書無しさん 2008/07/04(金) 05:46:53]

1000万行のうち、スケルトン・自動生成が700万行なので、UnitTest軽視なんですよ。

[176 仕様書無しさん 2008/07/04(金) 07:23:13]

80はユニットテストは属人性が高いと言っているが、なぜだかシステムテストは属人性が高くない
ような前提になっている。
ユニットテストが成功する前提条件として高度な能力を持ったプログラマが必要としておきながら、
なぜだかシステムテストさえやれば、テスタの能力は関係ないような記述になっている。
また、もっとも効率の良いテストケースを導き出せるのはホワイトボックスの視点を持ったプログラマ
であるにも関わらず、それを全く無視してる。
単体テストは必要であると言いながら、どのように実行しているかを曖昧にして具体的な説明を
避けている。
バグはできるだけ早く解決するのが、もっともコストが低いのは常識なのだが、システムテストまで
解決を遅延させても平気なのはなぜだろうか。
プログラマを育てる気はないのだろうか。全員派遣かSESなのか。

[177 仕様書無しさん 2008/07/04(金) 20:44:02]

> することは分かったと思う。

この辺りの言い回しが非常にうさんくさい
某アホコテっぽいし

[178 仕様書無しさん 2008/07/04(金) 21:21:15]

1000万行ってのが胡散臭いんだよな。
システムテスト件数30万件で、バグは3〜6万件くらいか？
10人じゃさばけないよなぁ、コミュニケーションコスト的に。

ちなみに、Windows 2000は2900万行で、出荷前のバグ件数は数十万件だったらしいぞ。
80のシステムは多分業務系だろうから件数は甘めに見積もった。

[179 仕様書無しさん 2008/07/04(金) 23:17:16]

早めにバグを潰した方がトータルコストが安くなる
↓
プログラマはうれしい
↓
テスターもうれしい
↓
でも会社はぼったくるよ
↓
クライアントのためにならない

[180 仕様書無しさん 2008/07/05(土) 01:38:16]

> クライアントのためにならない
ここちょっと違くね？
時間を金で買うクライアントもいるよ

[181 仕様書無しさん 2008/07/05(土) 08:05:40]

トラブルシステムを経験してるクライアントは
品質面についての時間、工数をちゃんと理解してくれることが多いけど

「ハァ？品質？金払ってるんだから問題ない
システム入れんのは当然だろ？スケジュール見直し？
ふざけんな、こっちはお客様だぞ！」
というお客様は多い。

[182 仕様書無しさん 2008/07/05(土) 11:57:14]

同じ物作りでも、H/Wは徹底的にテストするんだよなぁ。
ちゃんとスケジュールを確保し、テスト項目をドキュメント化し、
何回も精査を重ね、それこそ、しつこいぐらいにテストする。
要件や性能の確認ははもちろん、耐久性、動作限界（温度、湿度、
etc..）、危険の可能性はないか、等々。
それにH/Wの場合は、テストだけでなくマニュアルもしっかりして
いる。人命に関わるケースも多いし、法令化されているから当然と
いえば当然なんだけど。
しかし、これほどの徹底したテストを実施しても、品質不良や車の
リコールなどたまにあるわけだけど。

S/W、特に受託型アプリケーション開発の場合は、何故かねぇ...
テストをやらないわけじゃないけど、個人の技量に依存しちゃって
る場合が多いよなぁ。

[183 仕様書無しさん 2008/07/05(土) 16:05:21]

>>162
お前のとこのプロジェクトはテストケースレビューしないのか？
低能一人じゃ無理でも、低能三人集まれば1.5倍の能力にはなる

[184 仕様書無しさん 2008/07/05(土) 16:14:06]

>>183
テストケースレビューって必要か？仕様書がこなれてないだけじゃね？
テストに落とせない仕様書は悪い仕様書。

「URLが開けなかったら、エラーを吐く」←悪い仕様書
「200〜206番以外のステータスコードが返ってきたらエラーを吐く」←良い仕様書
良い仕様書は「おいおい、じゃあタイムアウトは別か？俺が担当すんのか？」みたいなツッコミに繋がる。

[185 仕様書無しさん 2008/07/05(土) 16:15:12]

>>183
低能一人増える毎に0.5倍なので0.75倍です。1.5倍になるんなら紛れもなく有能な方です。

ちなみに−倍になるのは無能です。

-倍は成果物が0もしくは、焼き直しの仕様が無い成果物しかつくれないって事ね。
低能は一応引き継ぎ出来る。無能は無駄な作業してから結局破棄して一からやり直すので−倍。

落ち目の会社で人が減っていくのは一番有能な連中が消えて低能や無能が増えるので作業効率が落ちる。

それはまだ言いのだが、上が人月取りたい為にさらに人を増やして作業効率を落とす事するので次に有能な連中が消える。

これのスパイラルが有能が一人もいなくなるまで続く。
(ちなみに、低能が有能に化けるので意外に長く続く 無能は低能にも有能にもならない)




いえ、そのスパイラルの最終段階に移行中なんで　>　給料遅配。

[186 仕様書無しさん 2008/07/05(土) 16:17:58]

>>185
会社潰れるとgdgdになるから、今のうちに転職した方が良いよ
責任感から動くと、周りを巻き込んで崩壊するぜ

[187 仕様書無しさん 2008/07/05(土) 17:48:19]

>>184
良い仕様書から作り出すテストって
ほぼ全てがユニットテストで書けるんだよね。

ユニットテストが苦手だといわれていたGUIでさえ、
GUI操作の自動化により、かなりのことが可能になっている。

出来ないのは見た目のデザインぐらいじゃないかな。
（ここの背景はもっと明るい色でとか）

システムテスト？ よくわからないな。
それはユニットテストで出来ないものなのかね？

[188 仕様書無しさん 2008/07/05(土) 17:54:19]

>>187
単なる名称とかやりかたの違いで、システムテストもユニットテストも同じ様なもんだよ。
いくつかのチームで作ってると、単体同士では良くても、全体としてパフォーマンスがでなかったりするから。

デザインのテストみたいな感性系は、テスターが大量にいるからなあ

[189 仕様書無しさん 2008/07/05(土) 17:55:26]

仕様書のテストはどうやるんだ

[190 仕様書無しさん 2008/07/05(土) 18:17:43]

>>189
その仕様書には、どんなことが書いてあるの？

そして、その書いてあることが正しいかどうかは
誰が判断できるの？

この二つの質問に答えることができれば、
おのずとどうやるかがわかると思う。

[191 仕様書無しさん 2008/07/05(土) 18:32:10]

ところで、仕様書の内容だけで、バグが無いソフトが作れるのかな？

理想としてはそうあるべきなのだろうが、仕様書を書く人に聞きたい。
本当に漏れの無い（全ての例外的な事象を考慮している）仕様書を書いていますか？

結局はプログラマがユニットテストという形で仕様書を書いていませんか？
こういう場合にはこうなるという仕様書がユニットテストの中にしか無いってことありませんか？

たぶんね。仕様書の内容を変更があるたびに短時間で
全て見直すことが出来ない限り漏れが無い仕様書を書くことは
出来ないと思うよ。

ユニットテストのように、OK/NGって表示されないのなら、間違っていてもいいもんね。
だから絶対仕様書のテストをサボるでしょ？ 漏れの無い仕様書書かないでしょ？

だからプログラムコードではない自動的に何度も検証できない仕様書は、
あくまで参考資料のために作るのであって
ユニットテストを本当の仕様書＆テストコードにするべきだよ。

時間は限られているからね。何万とある検証項目を何度もする時間は無いんだよ。

[192 仕様書無しさん 2008/07/05(土) 18:34:03]

ユニットテストを書く人をプログラマーと呼ぶか
テスターと呼ぶか設計者と呼ぶかはこの際問題じゃない。

ユニットテストを書く人が一番重要なのさ。

[193 仕様書無しさん 2008/07/05(土) 18:50:33]

シングルタスクのプロセスのテストはまぁ簡単。
だけど、これがマルチタスク、マルチユーザの環境になるととたんに
複雑になる。
排他のことやら、負荷の集中や、リソース不足やら、アクセス制御や
セキュリティー関連やら、想定されるケースが指数関数的に増える。
ファイルひとつアクセスするのにも、DBのトランザクション処理の場合
でも、いろんなケースを想定し、異常ケースでどう振舞うのが正しい
のか考えないといけない。そして普通、仕様書にはそこまで細かく書
いてなく、「このファイルのここをこの値で更新する」ぐらいしか書
いてない。ファイルが無かったらどうするのとか、オープンで失敗した
ら?とか、書き込みで失敗したら? とか。人によってそこを確認する人
もいるけど、だいたいエラーメッセージ出すとか、例外を投げるとか、
アボートさしちゃうとか、PG任せなケースも多いわけで、仕様書とプロ
グラムのギャップってどうしてもあるのよねぇ。ま俺から言わせれば設
計者の怠慢なんだけど、それをいちいち突っ込むのも、時間がなかった
り、面倒くさかったり、人間関係に気を使ったりとかいろいろあってで
きなかったりとか。はぁーとにかくめんどいよ、この業界。
自分でスケジューリングして、自分で設計して、自分でつくって、自分
でテストして、全部自分で責任持つのが一番楽だね。

[194 仕様書無しさん 2008/07/05(土) 18:51:43]

>>193
どこを盾読み?w

[195 仕様書無しさん 2008/07/05(土) 19:02:30]

>>194 14行目の31列目から2行分だ。

[196 仕様書無しさん 2008/07/05(土) 21:48:53]

仕様書のテストなんて恐ろしくて提案出来ないw

[197 仕様書無しさん 2008/07/05(土) 23:57:14]

テストデータをどのくらい作ればいいのか迷う。

[198 仕様書無しさん 2008/07/06(日) 00:07:11]

>>197
顧客が満足するくらい

[199 80 2008/07/06(日) 00:09:16]

>>166
外部仕様書に相当するものは、うちではインターフェース仕様書と
呼んでいる。
インターフェース仕様書は、その実現を記した「設計書」と区別される。
さらに、インターフェース仕様書の実現方法は複数あるので、
インターフェース仕様書１つに対して、複数の設計書が存在することもある。

外部仕様書と内部仕様書という言葉を使っているということは、
オブジェクト指向とか使ってないの？言語は何？

>>178
1000万行ってどうも行数が多いから嘘だと思われているようだな。
俺は逆に、少ないから馬鹿にされているかと思った。
でも、うちの業界では別に多い部類じゃないんだけどね。。。。
ちなみに、業務系じゃないよ。

[200 80 2008/07/06(日) 00:15:21]

>>198
良いことを言うな。
うちの顧客は、ユニットテストにまったく興味がない。
説明しても絶対に理解できないし、説明を聞く気持もない。

顧客に説明しなくてはいけない事は、要求（ユースケース）を正しく実
現出来ているかどうかである。

[201 80 2008/07/06(日) 00:22:15]

>>191
設計書にないコードを書くのは禁止されている。
設計書に間違いがあってもそのままコーディングされる。
設計書に不備があったら、設計者に戻され修正される。
そして、レビューが開催される。

責任関係があいまいになるような開発スタイルは、うちではありえない。
外資系なのでそのあたりはかなりドライ。

[202 仕様書無しさん 2008/07/06(日) 00:33:54]

っていうかどこのシステム。
銀行とか証券とか知っているけど、全システムあわせないとそれ位いかんぞ。
漏れのところは総計10万行で、×20で200万行。

1000万行ってどんな無能が作ってるんだ！？って意味合いでも疑わしい。

[203 仕様書無しさん 2008/07/06(日) 00:41:55]

多分、糞コード、糞仕様オンパレードの携帯の話じゃね？

[204 166 2008/07/06(日) 01:49:39]

>199,200,201
>良いことを言うな。
>うちの顧客は、ユニットテストにまったく興味がない。
>説明しても絶対に理解できないし、説明を聞く気持もない。
>
>顧客に説明しなくてはいけない事は、要求（ユースケース）を正しく実
>現出来ているかどうかである。

なんか、根本的に誤解していない？
誰もこのことに反対しているわけではないですよ。

そもそもシステム「製造」の目的が、
　顧客の提示した仕様を満たすモノを作り
　そのモノが顧客の提示した仕様を満たすことを証明すること。
であることには議論の余地はない。

で、その最終目的にアタックする足場として、
７合目あたりに強固なベースキャンプ（自動ユニットテスト）
が絶対に必要というのが、80さんの以外のほぼ全員が言っていること。

>設計書にないコードを書くのは禁止されている。
>設計書に間違いがあってもそのままコーディングされる。
>設計書に不備があったら、設計者に戻され修正される。
・・・
>責任関係があいまいになるような開発スタイルは、うちではありえない。

だから、設計にテスト仕様の洗い出しを含めろとあれほど・・・
なんか 191 さんの論旨が全く伝わっていないような希ガス。

>外資系なのでそのあたりはかなりドライ。

今日日むしろ外資系(特に米系、特に"I")はAgile一色。

[205 166 2008/07/06(日) 02:10:28]

>>199
>外部仕様書に相当するものは、うちではインターフェース仕様書と
>呼んでいる。
>インターフェース仕様書は、その実現を記した「設計書」と区別される。
>さらに、インターフェース仕様書の実現方法は複数あるので、
>インターフェース仕様書１つに対して、複数の設計書が存在することもある。

だから何？

テストケースは、インターフェース仕様の一部にすべきという
のが私の論旨なのだが・・・

なぜに、80さんのプロジェクトのドキュメント体型の話をなさる？

>外部仕様書と内部仕様書という言葉を使っているということは、
>オブジェクト指向とか使ってないの？言語は何？

オブジェクト指向だろうが何だろうが、

−プログラムには外部仕様と内部仕様とがある
−−外部仕様はこのプログラムをどう使うかを定義するモノで、
　　　入力・出力・副作用(+前提条件・例外)で表される
−−内部仕様は外部仕様の実現手段

というのは変わらないと思けど、、、

何が言いたいのかよく分かりません。

[206 80 2008/07/06(日) 08:03:32]

>>202
銀行とか証券とかそういうのじゃないよ。って言うか全く違う。

[207 80 2008/07/06(日) 08:25:39]

>>205
ちゃんと整理しよう。

システムの内部＝内部仕様書
システムの外部＝外部仕様書
だろ。まぁ、一見とてもわかりやすいよな。

では質問
１．システム内部とシステム外部の境界は、どちらの仕様書に書くの？
２．開発するシステムに対しして内部と外部があるわな。
開発範囲＝システムとした場合、外部とは、開発範囲の外側と言う
　　ことにならないか？
たぶん。
205 の頭の中を整理すると
-> 外部仕様書＝インターフェース仕様書、ユースケース仕様書
内部仕様書＝設計書
なんだと思う。

問題点１
　　　システムの外部は、開発対象ではない。
　　問題店２
　　　レイヤー、サブシステムに分割されているシステムの場合、
あるサブシステムの外部仕様は、上位のサブシステムの内部仕様書
になる（全く一緒ではないが）。つまり、外部と内部でわけると
仕様書に重複が生じる。
　　　また、インターフェースは、レイヤーやサブシステムに縛られない。
　　　つまり、単に外部仕様とすることはできない。
　　問題点３
　　　インターフェースを誤解している。
インターフェースは、極めて外部に近い内部ということになる。

[208 80 2008/07/06(日) 08:33:20]

>>205
うちは、インターフェースに対するテストを重視している。これを
うちは、システムテスト（サブシステム）テストと呼んでいる。

システムの実現側つまり、ソースコードの隅積みまで
行うテスト（単体テスト、ユニットテスト）は、普通にやってる。
システムテストほど重要視していない。


>>205
の最大の矛盾は、外部仕様書に基づいてテストを単体テストとかユニットテスト
と呼んでいることだ。単体テストは、内部のテストじゃないのか？
外部仕様書が書かれていることがちゃんとできているか＝システムテスト
内部仕様書に書かれていることがちゃんとできているか＝ユニットテスト

だと思うが？だとすると、205は単体テストをやっていないことになるな。

[209 仕様書無しさん 2008/07/06(日) 09:07:05]

としたら、学術系か軍事系か宇宙・航空系か・・・。

まあ

166の言いたい単体・ユニットテストは
>システムのテスト手法の一つで、個々のモジュール(部品)のみを対象としたテスト。
>対象のモジュールが仕様書で要求された機能や性能を満たしているかどうかをテストする。
>複数のモジュールを組み合わせて行なうテストは結合テスト、システム全体を対象に行なうテストはシステムテストという。

80の言いたいのは単体・ユニットテストは
>単体テストとは、プログラムを検証する作業の中でも、プログラムを手続きや関数といった個々の機能ごとに分割し、
>そのそれぞれについて動作検証を行う手法のことである。

大体こんな感じだろ、粒度の問題でその辺変わるので双方間違ってないように見えるけどな。
双方ともシステムやサブシステム”未満”のテストを言っているが、粒度によっては、外部インターフェースとのやり取り
をするレベルだと外部仕様書レベル元に単体・ユニットテストやったりするわけだし。

[210 80 2008/07/06(日) 09:27:55]

仕様書・・・システムが、ユーザー（人、外部システム）に提供する利益
　　　　　　が記されている。
設計書・・・システムが、仕様をどのように実現するかが記されている

仕様書に基づいたテスト・・・システムテスト
設計書に基づいたテスト・・・ユニットテスト

仕様書や設計書はシステム、サブシステム、コンポーネントといった
開発対象それぞれに対して作成される。
○○システム仕様書、○○システム設計書という具合
で、インターフェース仕様書は、インターフェースのことだけ書いた
仕様書。

仕様書と設計書だと、仕様書の方が重要。
人と人とのコミュニケーションやレビューの対象は、おもに仕様書。

設計書は、開発スタイルによるが、自分で設計書書いてプログラミングする
場合は、事細かに書かずに、ユニットテスト（xUnit）で代用することもできる。

ユニットテストはもろ刃の剣で、プログラマーのレベルが高い事が前提だ。
それに、テストコードを書くのはコスト高だ。

これを解決するのに何年か前から試行錯誤を繰り返している。
その解決方法のひとつが、xUnit以外の専用のテストツールを使ったテスト
と第三者によるユニットテストだ。

[211 80 2008/07/06(日) 09:31:50]

>>209
粒度は、開発範囲（スコープ）と詳細度（レベル）の２次元で定義すると。
今回のケースをとらえやすくなる。

今、ごちゃごちゃになっているのは、スコープを無視して話をしているからだ
。外部と内部という簡単な方法で開発対象を規定しようとしているところに
無理があると思ったから、粒度（スコープとレベル）を物差しに加えてみた。

[212 80 2008/07/06(日) 10:17:18]

>>166 の言ってるユニットテストは、
スコープ＝小さなシステム（サブシステム、コンポーネント、ライブラリ）
のシステムテスト（外部から見たふるまいのテスト）だと思う。

[213 80 2008/07/06(日) 10:18:37]

>>209
の言うとおり、粒度に惑わされるが、どんなにスコープが小さくとも
仕様書に基づいたテストは、全部、システムテストだ。
つまり、システムテストは、システム（サブシステム、コンポーネント）の
境界をテストすることだと言える。
システムをサブシステムやコンポーネントに分割すれば、
システムテストの件数が増大する。分割しなければ、ユニットテストの
件数が増大する。
分割していないという事は、システムの詳細を仕様化していない
ことになりテスト工数が増大する。
よーは、システムを適度に分割して、分割した境界についてテストを行う
ことが重要で、単純にユニットテストを強化しても不具合は減らないと
言いたいのだ。
まぁ、よくよく聞けば。同じ事を言っているみたいなので安心した。
要点は、
・テストファースト
　→仕様をテスト可能かどうか検証してから設計する。
・粒度が高い場合
　システムを分割して、分割したサブシステムを仕様化する。
　そして、その際にテストファーストを実施する。
・粒度が低い場合
　一人で切り盛りできるレベルになったら、プログラマーに任せる。

あと、俺のミスだが、
ユニットテストをテスターが行うというのは、厳密には、
「粒度の小さいシステムテストもテスターが行う。」だ。

粒度の小さいシステムテスト＝ユニットテストと混同してたな。

[214 仕様書無しさん 2008/07/06(日) 12:44:42]

お前はまず開発工程の定義から勉強して出直して来い

[215 仕様書無しさん 2008/07/06(日) 13:20:18]

>>214
ウォーターフォールに慣れすぎた古き人々よ

落として焼かねば変わらんのか？

[216 仕様書無しさん 2008/07/06(日) 13:52:45]

要求仕様を満たしているかをテストするって考えがまるっきり無いんだな。
自社製品ならまだ知らず、顧客から注文された製品なら、重要な事なのに。

[217 仕様書無しさん 2008/07/06(日) 16:18:27]

> 仕様書に基づいたテストは、全部、システムテストだ。

なら、ユニットテストは全部システムテストってことになるな。

[218 仕様書無しさん 2008/07/06(日) 16:23:08]

ユニットテスト以外で、
どうやってシステムテストをやっているのだろうか？

いや、果たしてやれるのだろうか？

[219 仕様書無しさん 2008/07/06(日) 16:23:56]

> ユニットテストはもろ刃の剣で、プログラマーのレベルが高い事が前提だ。

その点、システムテストは、レベルが低くてもやることができる。と？

[220 仕様書無しさん 2008/07/06(日) 16:24:48]

＞ これを解決するのに何年か前から試行錯誤を繰り返している。
＞ その解決方法のひとつが、xUnit以外の専用のテストツールを使ったテスト
＞ と第三者によるユニットテストだ。

残念ながらユニットテストをやることは必須。

システムテストでは、ユニットテストの代用にはならない。

なぜなら、システムテストは適当なテストだから。

[221 仕様書無しさん 2008/07/06(日) 16:26:58]

「適当なテスト」の意味は、レベルが低いやつでもできるテストであり
バグがないことを保障していない。
値を入れて、それらしい値がでてくれば、それでオッケー的なもの。
例外的なことを考慮していない。異常な値を入れたときどうなるかは
一切考えていない。

[222 仕様書無しさん 2008/07/06(日) 16:28:48]

システムテストでどんな内容をテストしているかを
具体的にいってくれれば、それがユニットテストでやれるってことを
証明できるのになぁｗ

[223 仕様書無しさん 2008/07/06(日) 16:42:03]

>>222
そりゃないんじゃないか？
名前が違うのかも知れないけど、うちのシステムテストって
・チームAが作ったデータベース周り
・チームBが作った入出力周り
・チームCが作った夜間バッチ周り
を、一斉に動かしてどこがボトルネックになってるか調べるテストだけども。
（データベースと入出力のAPIとか応答速度は決めて、その速度出るのはテスト済み）

[224 仕様書無しさん 2008/07/06(日) 16:59:40]

システムテストとユニットテストはやることの対象が違うんだから、
システムテストをいくらしたところで
ユニットテストの工数は減らないよ。
そもそも減らしてはいけない。減らす = サボるってことだから。
システムテストはユニットテストの代わりにはならない。

システムテストをさぼることで、無駄なユニットテストをやらされたとしたら、
それはユニットテストが問題なのではなく、システムテストやったやつがヘボで、
そのとばっちりを食らっただけの話。

[225 仕様書無しさん 2008/07/06(日) 17:04:33]

>>223
ボトルネックになっているとわかった後どうする？
修正するよね？

そのときユニットテストがあれば、
不具合を入れることなくパフォーマンスのみを
あげることができたって自信が持てるよね？

ほらどうだい。ユニットテストってすばらしいだろう？

それにボトルネックになっているのを見極めるために、
同じ条件で同じ操作を何度も繰り返すものだ。
どうだい。ユニットテストで自動化されていればそれも可能だろう？

[226 仕様書無しさん 2008/07/06(日) 17:06:18]

>>225
だからよ。ユニットテストはやってるって書いてるだろう？
>（データベースと入出力のAPIとか応答速度は決めて、その速度出るのはテスト済み）

>システムテストでどんな内容をテストしているかを
>具体的にいってくれれば、それがユニットテストでやれるってことを
>証明できるのになぁｗ
↑は、おかしいだろ。
ユニットテストで出来ることと、システムテストでできることは別じゃね？

[227 80 2008/07/06(日) 17:20:08]

>>217
そもそも、ユニットテストという言葉が微妙なんだ。

>>219
システムテストは複数のテスターによって実行できる。
テスターは単価が安い。

[228 80 2008/07/06(日) 17:26:31]

>>225
の言っているユニットテストはなんなの？
「テスト用のプログラムと結合して自動的にテストを行う」事か？

[229 80 2008/07/06(日) 18:10:30]

>>225
>システムテストでどんな内容をテストしているかを
>具体的にいってくれれば、それがユニットテストでやれるってことを
>証明できるのになぁｗ
もし証明できるなら、逆も証明することになる。
システムテストとユニットテストは等価変換できるという、
相当、大それたことを言っていることに気づこう。

[230 仕様書無しさん 2008/07/06(日) 18:47:53]

80は色々いっているけどプログラムの動作レベルに関して言及していない、
テストは概ねブラックボックスに関して述べている。

よりはっきりいえば、詳細なホワイトボックステストをテスターがやるのは意味が無いといっているとも思われる。

設計がパーペキなら問題ないし(バグはプログラマーの問題)
設計にバグがあるなら差し戻ししてそこからグラマーが直せばよいとの事。
設計通りにすればとりあえずうまくいうと言う考え。

ホワイトボックスのテストはテストツールでやるとかともいっているねー。

それだけの話。

[231 80 2008/07/06(日) 19:01:54]

>>230
残念ながら全然違う。

俺が言ってるのは、ホワイトボックステストを最小限にするという戦略。
部品化を進めて、各部品の仕様書を書く。仕様書に基づいて各部品の
ブラックボックステストを行うのだ。

ホワイトボックステストを最小限にするのに部品化のほかに
「インクリメンタル型の開発」がある。簡単に言えば一気に作り上げて
一気にテストをするのではなく、少しづつ作って少しづつテストをする
のだ。そうすることで、ブラックボックステストとホワイトボックステストの
乖離を最小限にする。

以下の２つを実現したのち、ブラックボックステストが効果的になる。
１．ホワイトボックステストの規模を最小化する。
２．ホワイトボックステストとブラックボックステストの乖離を最少化する。

「問題の難しさ」を「問題の量」に転化したのだから、当然、
ブラックボックステストの件数がかなり多くなる。
これを、テスト自動化によりコストを減らしているわけだ。

まぁ、全部が完全にうまくいっているわけではないが、これ以外に
良い方法を俺は知らない。勉強不足かもしれないので、ヒントを
探しているところさ。

[232 仕様書無しさん 2008/07/06(日) 20:23:46]

一言で言えば、粒度を上げて問題の均質化を狙ったわけね。
でもそれって、改良やパフォーマンスチューニング等で崩れそうなもんだけど。
マルチスレッドに起因するバグ発生したら地獄だな。

[233 仕様書無しさん 2008/07/07(月) 03:22:05]

テストを軽視するのは御役所もいっしょ。
特殊なケースと無理矢理な変数当てはめて机上ではうまくいく。
うまくいくから道路作れ。それ、レッツらゴーってなもんでしょ。

日本という体質そのものがテスト軽視の傾向があるんだよ。

[234 仕様書無しさん 2008/07/07(月) 05:35:05]

>>231
机上の空論。

実戦経験をつめ。

[235 仕様書無しさん 2008/07/07(月) 08:11:18]

おまいら一生懸命語ってるけどテストなんて
そんなに重視してないよ

[236 仕様書無しさん 2008/07/07(月) 08:26:33]

でもテストって大事なんだぜ？

今の現場も結合テスト甘くみやがったせいで
客にブチ切れられて納期延ばし、
メンバーも増員毎日深夜まで再テストだ

そう、つまり黒から一気に赤化

[237 仕様書無しさん 2008/07/07(月) 11:40:51]

>>235
マ辞めちまえ。おまい迷惑。

[238 仕様書無しさん 2008/07/07(月) 11:45:04]

>>237
俺が辞めたら客が困るんだぜ

[239 仕様書無しさん 2008/07/07(月) 11:47:57]

>>238
そう思っているのはおまいだけw

[240 仕様書無しさん 2008/07/07(月) 12:01:08]

>>239
言うと思ったｗ

[241 仕様書無しさん 2008/07/07(月) 12:30:29]

わたしが死んでもわたしの代わり(にテストさせられる可哀想なヤツ)は居るもの

[242 仕様書無しさん 2008/07/07(月) 12:40:45]

>>239
勘違いも甚だしいな。
お前が辞めた方が客は喜ぶぞ。
テストの不十分な商品渡されるよりよっぽど安心だろ。

[243 仕様書無しさん 2008/07/07(月) 12:43:34]

レス先間違えてね？

[244 仕様書無しさん 2008/07/07(月) 12:55:08]

専ブラの番号ズレたんじゃね？

[245 仕様書無しさん 2008/07/07(月) 16:29:11]

>>241
そんな（おれらに被害が及ぶような）こと言うなよ

[246 仕様書無しさん 2008/07/07(月) 16:34:17]

>>245
だって（めんどくさいんだもの）仕方ないじゃない

[247 仕様書無しさん 2008/07/07(月) 19:53:15]

>>210
> 仕様書・・・システムが、ユーザー（人、外部システム）に提供する利益
> 　　　　　　が記されている。

世間では、その部分を要件定義書と外部設計書にわけてるんだよ。
例えばユーザインターフェース仕様。これはクライアントが要件として出す場合もあるが
それはまれで、普通はシステムを作る方が設計する。

> 仕様書に基づいたテスト・・・システムテスト
> 設計書に基づいたテスト・・・ユニットテスト

なるほど、「俺定義」で今まで話してたのはわかった。

> 仕様書や設計書はシステム、サブシステム、コンポーネントといった
> 開発対象それぞれに対して作成される。

サブシステム分割や、何をコンポーネント化するかというのは、内部設計と普通は言う。
なので顧客レビューはせず、80定義で言う所の仕様書は書かない。

> ユニットテストはもろ刃の剣で、プログラマーのレベルが高い事が前提だ。
> それに、テストコードを書くのはコスト高だ。

ユニットテストのケースレビューやコードレビューをするという概念は全くないの？

顧客はユニットテストにはお金を出さないというようなことを繰り返し言ってるが、
まったくそんなことない。顧客は品質にもお金を払ってる。
ユニットテストでバグを潰そうが、システムテストでバグを潰そうが、顧客が知ったこっちゃ
ないのは同意する。

[248 仕様書無しさん 2008/07/07(月) 20:02:58]

（続き）
「効率の悪いユニットテスト」や「品質の低いユニットテスト」は確かに否定されるべきだが、
だからと言って、ユニットテストが否定されるものではない。
バグは潰すのが早ければ早いほど、その修正コストは低くなる。これには80も同意してくれる
ものと思う。
「効率の悪いユニットテスト」や「品質の低いユニットテスト」が、開発コストを押し上げている
のであれば、「効率の良いユニットテスト」「品質の高いユニットテスト」に出来ないかを考えるのが
まず第一だ。なぜなら、バグは潰すのが早ければ早いほど修正コストが低いからだ。
修正コストが低ければ、開発コスト全体も低くなり、それが顧客のメリットになる。

ユニットテストをほとんどやらずに、第三者によるシステムテストに力を入れるという方法論も
あるだろう。

俺自身は、この方法論を全く支持しないが、スキルの低いプログラマが多数いるチームであれば
そのような方法論を取った方が、全体のコストが下がるのかもしれない。

しかし、方法論として提示するのであれば、システムテスト重視の方が品質が高くなる理由（根拠）と
ある程度のメトリクスを提示しなければ、第三者を納得させることはできないと思う。

[249 仕様書無しさん 2008/07/07(月) 20:18:40]

サブシステムやコンポーネントやレイヤーを合わせてテストするのは、普通、結合テストと言います。

[250 仕様書無しさん 2008/07/07(月) 20:28:37]

（少し追加）

>>231
> これを、テスト自動化によりコストを減らしているわけだ。

今のところ、80の発言から読み取れる「削減できているもの」は、このシステムテスト
（ブラックボックステスト）実行コストのみだ。

本気でテストの自動化をやってるところは、自動化されたテストの実行コストなど、
テスト全体のコストにほとんど影響を与えないことを知っている。
つまり、本当に自動化されているなら、実行するPCの台数を増やし、夜間に動作
させればよいのである。

問題は、自動化にかかるコストと、第三者検証の場合は、テスタ−プログラマ間の
コミュニケーションコスト、プログラマチームからテスタチームへ引き渡すリソース管理、
出荷判定（100%バグを修正できない場合の判定という意味での）などのコストをどう
減らすかなんだよ。

[251 仕様書無しさん 2008/07/07(月) 20:31:23]

（書き忘れ）
テストのコストを引き上げる要因をひとつ忘れていた。
自動化テストの場合、それが正しいテストかどうかのチェックに非常に時間を取られる。
事前条件は正しいのか、テストの内容は正しいのか、事後条件は正しいのか、（自動）確認は
正しく行えているかなど。

[252 仕様書無しさん 2008/07/07(月) 20:43:11]

・PGが作ったものが「作ったとおりに」動く事（あるパス通したら落ちる、ボタンはあるけど反応がない、など）
　単体としてはまともに動く事を確認するのが単体テスト

・１PGから複数PG、はては複数チームが作ったものが、ちゃんと連動すること
　お客様にうたった仕様どおりの動作をしている事を確認するのが結合テスト

・（結合との位置づけがあいまいなんだけど）
　お客様レベルでの操作をしてもらって、「うん、ちゃんと動いてますね」
　って確認を本番環境、現地レベルで取るのがシステムテスト、そして最終的な運用テスト

とか位置づけちゃってたわ、ワタシ

>>248の言うように、単体レベルでの不備はテスト初期（というか開発途中）のレベルで
とっておいた方がいいと思う、コストというより、後の方のテストはざるの目が粗いから
思わぬ不具合（ある異常系パスを通るとシステム全体がダウンしてしまう、など）を
見逃してしまう可能性が高い（下位のレベルの不具合は上位のテストからはブラックボックスなので）

[253 仕様書無しさん 2008/07/07(月) 21:08:02]

最後のは、普通、受け入れテストと言いますね。

[254 仕様書無しさん 2008/07/07(月) 21:17:01]

>>253
thx

[255 仕様書無しさん 2008/07/07(月) 21:58:28]

テストが億劫になるｽﾚだなぁ

[256 仕様書無しさん 2008/07/07(月) 23:25:27]

「システムテスト」が設計(design)ではなく、仕様(specification)に基づくものだという80の意見には同意する。
80が言う方法論には同意しないが。

依然として機能テスト以外のテストに関する話が出てこないが、よくまとまっているページを見つけたので
紹介しておく。
http://en.wikipedia.org/wiki/System_testing

システムテストでは、機能的に要件とマッチしていることを保証するとともに、上記ページにあるようなテストを
行うのが一般的だと思う。

まぁ普通は機能外要件を要件定義書に書けるチームはほとんど無いと思うが、「システムテスト」工程で
行うもんなんだよね。

また、いわゆる「内部設計」以外を「仕様書」におこして、それをクライアントレビューにかけるというのは、
双方にとって負担が大きいと思うね。工事進行基準が始まれば、「要件定義書」の範囲も、業界的に合意が
形成されていくのかもしれないね。

[257 仕様書無しさん 2008/07/08(火) 00:11:34]

>>256
wikiを良く纏まったページって紹介するのはなんだと思う。

80の言っている事だけど
一つの方法論だけど・・・、

>「問題の難しさ」を「問題の量」に転化したのだから、当然、
>ブラックボックステストの件数がかなり多くなる。
>これを、テスト自動化によりコストを減らしているわけだ。

テスト項目表作成も自動化しないとコストかかるね。
正確には「正しい｣テスト項目表の作成。

ぶっちゃけ、テストにコストがかかるのではなくて、
テスト項目の洗い出しにコストがかかり、
さらにその妥当性をだすのにコストがかかる。

半年後のユーザの意見を聞きたいな、ボトルネックが山に
様にできてそうだ。
（まあ、最近のPCは出来が良いので問題おこんないって前提だろうけど）

[258 80 2008/07/08(火) 01:01:27]

>>256

■機能要件
機能要件は、インクリメンタル型で開発している。仕様書に基づいて
要求が満たされているかをチェックするのに重点が置かれる。

■フレームワーク
非機能要件は、フレームワークに含まれるのがほとんどで、イテレーティブ
型で開発をしている。
実際には、リファクタリングをしまくるわけだ。つまり、外的な
ふるまいだけをテストして、内部はガンガン変えていくのだ。
なので、単体テストは軽視され回帰テストが重要視される傾向がある。

■再利用可能なコンポーネント
レイヤーの低い位置にいる、再利用可能なコンポーネントは、
不具合が全体に波及するので、ユニットテストからコツコツ積み上げる。
ユニットテストは低レベルのコンポーネント（ライブラリ）開発で役に立つ。

[259 80 2008/07/08(火) 01:09:01]

>>256
>また、いわゆる「内部設計」以外を「仕様書」におこして、それを
>クライアントレビューにかけるというのは、 双方にとって負担が
>大きいと思うね。工事進行基準が始まれば、「要件定義書」の範囲も、
>業界的に合意が形成されていくのかもしれないね。

開発プロジェクト内で閉じるレビューがほとんど。レビューは、一種の
テストだから軽視してはいけない。それに、ドキュメント
に関しては、CMMとかISOとかやってるので結局書かなくてはいけない。

[260 仕様書無しさん 2008/07/08(火) 01:58:40]

80は一体誰と闘い、何が目的なんだ