テストを軽視する者ども

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

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

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

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

この馬鹿者どもが。

[2 仕様書無しさん 2008/06/28(土) 20:04:31]

普通はテスト書いてからコーディング

[3 仕様書無しさん 2008/06/28(土) 20:04:37]

お疲れ様です、テスターさん。

[4 仕様書無しさん 2008/06/28(土) 20:05:21]

普通は納品してからテスト

[5 仕様書無しさん 2008/06/28(土) 20:12:15]

「ユキ！やめろ！まだテストもしていないんだぞ！！」
「今すればいいじゃありませんか！・・」

[6 仕様書無しさん 2008/06/28(土) 20:15:03]

プログラマ一人に対してテスト担当者を一人付けるべきだな。
テストは重要だ。そしてプログラマーは自分のプログラムには甘い。

[7 仕様書無しさん 2008/06/28(土) 20:50:36]

テストが仕様書

[8 仕様書無しさん 2008/06/28(土) 20:50:55]

>>1 なんかは、多分 テスト >>> コーディング とか思ってるんだろうな。

世間は既に、設計 >>>>>>> テスト >> コーディング になってるのに。

[9 仕様書無しさん 2008/06/28(土) 21:15:28]

1.テスト対象クラスのメソッドをテストするコードをテストクラスに書く。
2.メソッドを実装する。
3.1で作ったテストクラスを使って2のメソッドをテストする。
4.テストを通らなければ修正する。
5.1へ戻って次のメソッドを実装する。

この繰り返しこそ、結局は一番確実で早い。
そしてテストクラスを使っていつでも今まで作ったものをテスト
できるから、勇気をもってリファクタリングができる。

[10 仕様書無しさん 2008/06/28(土) 23:54:14]

>>9
それ、ユニットテストじゃん。ユニットテストは普通テスターがやるもの
じゃないっしょ。ユニットテストは、設計レベルの確認でしょ。そのやり方
は、開発規模が大きくなった場合は、現実的には無理だと思うぞ。

顧客の要求レベルのテスト、すなわち、システムテスト（ホワイトボック
ステスト）が、最重要でしょ。

[11 仕様書無しさん 2008/06/28(土) 23:58:45]

上流工程こそ最重要だよ

テスト？やって当然だろ

[12 仕様書無しさん 2008/06/29(日) 00:39:41]

客にバグ出しさせればいいじゃない

[13 仕様書無しさん 2008/06/29(日) 00:48:47]

>>12
はげどう
どうせ仕様が気に入らないっていって大改造させられるんだから
テストなんかしても意味ない

[14 仕様書無しさん 2008/06/29(日) 00:58:16]

>客にバグ出し

へぇ、顧客による受け入れテストってやってないのか？

[15 仕様書無しさん 2008/06/29(日) 01:22:53]

客先でBUGなんか出したら、開発費値切られるだろw

[16 仕様書無しさん 2008/06/29(日) 02:48:14]

一般人のテストの感覚でいるんだろうな。

ちょっと使ってみて、うん動く。テストおっけーみたいな。

ソフトウェアのテストとは、動かないところがないか
探すものなんだよ。

ゲームで言えば、ストーリーどおりやってクリアするのはテストじゃない。
裏技を探すのがテストだ。

[17 仕様書無しさん 2008/06/29(日) 02:52:23]

>>10
> ユニットテストは、設計レベルの確認でしょ。そのやり方
> は、開発規模が大きくなった場合は、現実的には無理だと思うぞ。

逆だろ。

開発規模が大きいのに、ユニットテストをしていないところは

馬鹿 と断言していい。

[18 仕様書無しさん 2008/06/29(日) 03:22:14]

>>15
ソフトにバグはつきものってことは十分擦り込んであるから大丈夫。
MSやらのおかげで最近はずいぶん理解を得やすくなった。

[19 仕様書無しさん 2008/06/29(日) 03:38:04]

プログラマーに嫌がられるようになってこそテスターも一人前。
プログラマーに愛想振っているようではまだまだ半人前の若僧だ。
テスター道一筋６年目の俺様が言うのだから間違いない。

[20 仕様書無しさん 2008/06/29(日) 04:30:42]

(;´д｀)ごめんなさい。
パンチしかできてない、サンプルつぎはぎしただけのでたらめなソースを提出しました。

[21 仕様書無しさん 2008/06/29(日) 04:54:43]

パンチってなに？

[22 仕様書無しさん 2008/06/29(日) 07:51:20]

>>10
> システムテスト（ホワイトボックステスト）が、最重要でしょ。

無理して知らない用語使うなｗ

[23 仕様書無しさん 2008/06/29(日) 10:10:50]

>>17
ユニットテストは、開発者がやるものだと言っただろ。
開発規模が大きくなってもユニットテストは確実にやる。
開発者がな。

俺が言いたいのは、開発規模が大きくなれば、ユニットテストの
積み重ねだけでシステム全体のテストをしたことにはならないという
ことだ。

テスターは、カバレッジをどう確保するかが大切だろ。
ユニットテストに注力してホワイトボックステストをおろそかにするバカは
いないとは思うが、ユニットテストを強調するあたり、分かってないとしか
言いようがない。

ユニットテストは、開発規模が大きくなれば、自動化するもんだ。
うちは、QTP使ってる。システム揃えるのに数千万もする代物だ。
それでも、人件費に比べれば安いものさ。
UnitTestなんて非効率なもの大規模プロジェクトでは使わないんよ。

>>9
のやり方は、開発者にとって効果的だが、テスターが付き合う義理はねぇ。
テスターは、「顧客要求を満たせば、ソースコードは糞でも何でもいい。」
じゃねーのか？

プログラマーに、ユニットテストのスキルを身につけさすのが現実解だろ。

[24 仕様書無しさん 2008/06/29(日) 10:18:28]

>>19
うちのプロジェクトでは、テスターってプログラマーより給料が少ない。
日本じゃテスターの地位は低いのだ。
だから、みんな、テスターになりたがらない。で、テスターの質が下がる。

現場は、テストの重要性を分かっているが、上層部は、テストは誰でも
できると思っている。馬鹿にでもわかるようにテストの重要性を
解いてくれないか？

[25 仕様書無しさん 2008/06/29(日) 10:44:45]

>>22
指摘サンキュ。うっかりしてた、ブラックボックステストだった。
お恥ずかしい。

[26 仕様書無しさん 2008/06/29(日) 12:03:22]

テスト工数が軽んじられる傾向にあるのは確かだな。
テストにかかる時間と手間がちゃんと工数に考慮されたら、
そして経験と勘に頼るような人任せなやり方が改善されて、
テスト手法がちゃんと確立されて標準化されたら、みんな
定時で帰れるし、トラブルも減って、もう少しみんながハッ
ピーになれると思うんだけど。
でも現実は、製造とテストは一緒くたに丸投げされて、やら
される方もただ盲目的に「テストOK」の印をつけることだけ
が目的になっている。自分で製造もやってるから隙もできる。
これじゃぁ、質があがるわけない。せめて製造とテストは実施
者を分けるべきじゃないかと思う。

[27 仕様書無しさん 2008/06/29(日) 16:22:52]

>>25
は？

[28 仕様書無しさん 2008/06/29(日) 16:26:33]

>>23
えーと、何万人月のシステムでも、あなたが担当するのは、一か月でたかだか
一人月かそこらですよ。

[29 仕様書無しさん 2008/06/29(日) 16:32:29]

>>28
だから？
テストするなと？

[30 仕様書無しさん 2008/06/29(日) 18:06:43]

テストをしていないシステムを使うのは、素人が捌いたフグ刺しを食べるようなものだ。
フグの味とともにスリルも味わいたいなら止めはしないが、一般の人にはお勧めしない。

[31 仕様書無しさん 2008/06/29(日) 18:07:37]

>>29
大規模プロジェクトでUnitTestなんか使わないってのの反論。

[32 仕様書無しさん 2008/06/29(日) 18:10:47]

QTPって機能テストツールであって、UnitTestは関係ない

[33 仕様書無しさん 2008/06/29(日) 18:20:55]

ageてる奴がアホ（=1?）

[34 仕様書無しさん 2008/06/29(日) 18:33:00]

言語や設計の本はよく読むのに、テスト関連の本読まれなさすぎ

[35 仕様書無しさん 2008/06/29(日) 19:40:11]

うちのプロジェクトは詳細設計なんてやってる時間があったら
テスト仕様書でも書けよとは思う
どうせ基本設計が腐ってるんだからテストで潰すしかないのに

[36 仕様書無しさん 2008/06/29(日) 20:17:48]

>>32
うちは、QTPを単体テストで使用している。
開発の初期からテストを意識している。
つまり、テストはテスターだけの仕事じゃない。

設計者は、単体テストでテスト自動化を導入できるようにはじめから
設計する。目標は、すべてのテストの自動化と管理だ。
テストは設計の一部だ。

いわゆるユニットテストでは、カバレッジを評価できないし、
達成度も不明確だ。

うちは、ユニットテストからすべてQC/QTPで一元管理している。
そして、統計を取ってシステムやチームの弱点を洗い出す。

QTPは単なるツール。どう使うかは使う側による。

[37 仕様書無しさん 2008/06/29(日) 20:18:06]

ちゃんと動くプログラム＞＞＞＞抜けだらけのテスト＞＞＞＞誤りだらけの仕様書

[38 仕様書無しさん 2008/06/29(日) 20:19:17]

>>35
要求書はないのか？要求が明確なら少しの労力でテストシナリオを書けるだろ。

[39 仕様書無しさん 2008/06/29(日) 20:21:41]

>>37
「ちゃんと動くプログラム」と「テスト」と「仕様書」をなぜに比べる？
一蓮托生だろ。
テストも出来ていない腐った仕様のプログラムは、ちゃんと動いているとは
言えない。

[40 仕様書無しさん 2008/06/29(日) 21:05:33]

今や重要度では
テスト　＞　プログラミング

主従関係も逆転した。
プログラムにテストがくっついているのではない。
テストこそが主。

要件定義　→　用件を満たすテストパターンの洗い出し　→　テストクラスの作成　→　テストを通すための実装

今や時代はこれ。テストドリブン。これ。いわば最初に足枷をはめるやり方。
一見手間がかかるように見えるかもしれんが、結果的には一番効率的。
客にもテストパターンをみせて、「こういう入力の場合はこうなればいいんですね」と、
意外と説明しやすい。

[41 仕様書無しさん 2008/06/29(日) 21:13:01]

>>40
ま、普通だな。

詳細設計の前に、結果を先に作っておくと言うのも手だぞw

[42 仕様書無しさん 2008/06/29(日) 23:16:39]

>>40
客に見せるテストパターンとテストクラスとでは粒度が違う気がするけど。

テストドリブンというようりユースケースドリブンじゃね？
要件定義と書いているけど、ユースケースつまりシナリオベースで要件を
整理するわけで、客にテストパターンを見せる必要はないわな。

よーは、日本人が苦手な「全体最適化」だろ。テストというコストが
高い工程を改善するのに全工程をテスト中心に考えるという考え方は
悪くないが、テストドリブンは、大規模プロジェクトでは、失敗
しやすいぜ。

要件定義をした後に、テストパターンを洗い出す必要があるということは
要件定義が完全に終わっていないことを物語っている。

要件定義が完璧ならテストパターンは自ずと決まってくる。
テストパターンを顧客に見せなくてはいけない時点で、
要件定義が不十分だということに気づくべきだな。

[43 仕様書無しさん 2008/06/29(日) 23:20:19]

>>40
それでも抜けてるテストがあるのがお約束。
さらに、「こんな動かし方もしたいからこういうテストは？」とか聞かれて要件抜けてるのに向こうと気がついたりｗ
まあ、無い頃は良くテスト先に作らないでプロジェクト進んでたなーと思うけどな。

[44 仕様書無しさん 2008/06/29(日) 23:28:52]

このスレってテスト駆動の名前しか知らない人たちばっかりなの？マ板も落ちたもんだな・・・