■編集元：プログラマー板より「テストを軽視する者ども」
1 仕様書無しさん :2008/06/28(土) 19:49:20
1 仕様書無しさん :2008/06/28(土) 19:49:20
何だよ、８割方終わった風な顔で、「コーディング終わりました。後はテストするだけです。」
って...
コーディングが終わってやっと３割終わったかどうかってところだろが。
コーディングが終わってからが本番だっちゅーの。テスト仕様書に従い、テストデータ用意して、
正常系、異常系含めて、抜かりなく全網羅テストすること。これがどれだけ大変なことか。
本当に理解してんのか？ コーディングが終わってやっとスタートラインに立ったぐらいの気持ち
でいろよ、ってくヘラヘラしやがって。
こういう、テストを軽視する輩共が、プログラミングという作業を軽んじ、工数見積りを誤り、
徒に製造を急かし、バグの混入率を間接的に高めているということに気づかんのか。
どんな優秀な奴だって、人間だもの、間違いを犯す。バグを生み出す。それを極力未然に防ぐのが
テストだろ。いつバグが判明するかとドキドキしながら納品後の時間を過ごすか、自信と満足感を
もって笑顔で過ごすか。どちらがいいか自明のことだろ。
プログラミングはなぁ、テストに始まりテストに終わるんだよ。要件を理解し、その中に潜む異常
パターンを見抜き、どんだけ抜かりなくテストをやれるかが一流とカスを分かつ分水嶺だ。
コーディングなんかできてあたり前、肝心なのはテストだ。テストを極めてこそ、一流のプログラ
マーって呼べるんだよ。
この馬鹿者どもが。
2 仕様書無しさん :2008/06/28(土) 20:04:31
普通はテスト書いてからコーディング
お疲れ様です、テスターさん。
普通は納品してからテスト
「ユキ！やめろ！まだテストもしていないんだぞ！！」
「今すればいいじゃありませんか！・・」
プログラマ一人に対してテスト担当者を一人付けるべきだな。
テストは重要だ。そしてプログラマーは自分のプログラムには甘い。
テストが仕様書
1.テスト対象クラスのメソッドをテストするコードをテストクラスに書く。
2.メソッドを実装する。
3.1で作ったテストクラスを使って2のメソッドをテストする。
4.テストを通らなければ修正する。
5.1へ戻って次のメソッドを実装する。
この繰り返しこそ、結局は一番確実で早い。
そしてテストクラスを使っていつでも今まで作ったものをテスト
できるから、勇気をもってリファクタリングができる。
10 仕様書無しさん :2008/06/28(土) 23:54:142.メソッドを実装する。
3.1で作ったテストクラスを使って2のメソッドをテストする。
4.テストを通らなければ修正する。
5.1へ戻って次のメソッドを実装する。
この繰り返しこそ、結局は一番確実で早い。
そしてテストクラスを使っていつでも今まで作ったものをテスト
できるから、勇気をもってリファクタリングができる。
>>9
それ、ユニットテストじゃん。ユニットテストは普通テスターがやるもの
じゃないっしょ。ユニットテストは、設計レベルの確認でしょ。そのやり方
は、開発規模が大きくなった場合は、現実的には無理だと思うぞ。
顧客の要求レベルのテスト、すなわち、システムテスト（ホワイトボック
ステスト）が、最重要でしょ。
17 仕様書無しさん :2008/06/29(日) 02:52:23それ、ユニットテストじゃん。ユニットテストは普通テスターがやるもの
じゃないっしょ。ユニットテストは、設計レベルの確認でしょ。そのやり方
は、開発規模が大きくなった場合は、現実的には無理だと思うぞ。
顧客の要求レベルのテスト、すなわち、システムテスト（ホワイトボック
ステスト）が、最重要でしょ。
>>10
> ユニットテストは、設計レベルの確認でしょ。そのやり方
> は、開発規模が大きくなった場合は、現実的には無理だと思うぞ。
逆だろ。
開発規模が大きいのに、ユニットテストをしていないところは
馬鹿 と断言していい。
23 仕様書無しさん :2008/06/29(日) 10:10:50> ユニットテストは、設計レベルの確認でしょ。そのやり方
> は、開発規模が大きくなった場合は、現実的には無理だと思うぞ。
逆だろ。
開発規模が大きいのに、ユニットテストをしていないところは
馬鹿 と断言していい。
>>17
ユニットテストは、開発者がやるものだと言っただろ。
開発規模が大きくなってもユニットテストは確実にやる。
開発者がな。
俺が言いたいのは、開発規模が大きくなれば、ユニットテストの
積み重ねだけでシステム全体のテストをしたことにはならないという
ことだ。
テスターは、カバレッジをどう確保するかが大切だろ。
ユニットテストに注力してホワイトボックステストをおろそかにするバカは
いないとは思うが、ユニットテストを強調するあたり、分かってないとしか
言いようがない。
ユニットテストは、開発規模が大きくなれば、自動化するもんだ。
うちは、QTP使ってる。システム揃えるのに数千万もする代物だ。
それでも、人件費に比べれば安いものさ。
UnitTestなんて非効率なもの大規模プロジェクトでは使わないんよ。
>>9
のやり方は、開発者にとって効果的だが、テスターが付き合う義理はねぇ。
テスターは、「顧客要求を満たせば、ソースコードは糞でも何でもいい。」
じゃねーのか？
プログラマーに、ユニットテストのスキルを身につけさすのが現実解だろ。
28 仕様書無しさん :2008/06/29(日) 16:26:33ユニットテストは、開発者がやるものだと言っただろ。
開発規模が大きくなってもユニットテストは確実にやる。
開発者がな。
俺が言いたいのは、開発規模が大きくなれば、ユニットテストの
積み重ねだけでシステム全体のテストをしたことにはならないという
ことだ。
テスターは、カバレッジをどう確保するかが大切だろ。
ユニットテストに注力してホワイトボックステストをおろそかにするバカは
いないとは思うが、ユニットテストを強調するあたり、分かってないとしか
言いようがない。
ユニットテストは、開発規模が大きくなれば、自動化するもんだ。
うちは、QTP使ってる。システム揃えるのに数千万もする代物だ。
それでも、人件費に比べれば安いものさ。
UnitTestなんて非効率なもの大規模プロジェクトでは使わないんよ。
>>9
のやり方は、開発者にとって効果的だが、テスターが付き合う義理はねぇ。
テスターは、「顧客要求を満たせば、ソースコードは糞でも何でもいい。」
じゃねーのか？
プログラマーに、ユニットテストのスキルを身につけさすのが現実解だろ。
>>23
えーと、何万人月のシステムでも、あなたが担当するのは、一か月でたかだか
一人月かそこらですよ。
29 仕様書無しさん :2008/06/29(日) 16:32:29えーと、何万人月のシステムでも、あなたが担当するのは、一か月でたかだか
一人月かそこらですよ。
>>28
だから？
テストするなと？
31 仕様書無しさん :2008/06/29(日) 18:07:37だから？
テストするなと？
>>29
大規模プロジェクトでUnitTestなんか使わないってのの反論。
22 仕様書無しさん :2008/06/29(日) 07:51:20大規模プロジェクトでUnitTestなんか使わないってのの反論。
>>10
> システムテスト（ホワイトボックステスト）が、最重要でしょ。
無理して知らない用語使うなｗ
25 仕様書無しさん :2008/06/29(日) 10:44:45> システムテスト（ホワイトボックステスト）が、最重要でしょ。
無理して知らない用語使うなｗ
>>22
指摘サンキュ。うっかりしてた、ブラックボックステストだった。
お恥ずかしい。
27 仕様書無しさん :2008/06/29(日) 16:22:52指摘サンキュ。うっかりしてた、ブラックボックステストだった。
お恥ずかしい。
>>25
は？
11 仕様書無しさん :2008/06/28(土) 23:58:45は？
上流工程こそ最重要だよ
テスト？やって当然だろ
客にバグ出しさせればいいじゃない
13 仕様書無しさん :2008/06/29(日) 00:48:47>>12
はげどう
どうせ仕様が気に入らないっていって大改造させられるんだから
テストなんかしても意味ない
109 仕様書無しさん :2008/06/30(月) 22:18:22はげどう
どうせ仕様が気に入らないっていって大改造させられるんだから
テストなんかしても意味ない
>>12
鉄道動かすプログラムですが、客にバグ出しさせますね＾＾ｖ
15 仕様書無しさん :2008/06/29(日) 01:22:53鉄道動かすプログラムですが、客にバグ出しさせますね＾＾ｖ
客先でBUGなんか出したら、開発費値切られるだろw
18 仕様書無しさん :2008/06/29(日) 03:22:14>>15
ソフトにバグはつきものってことは十分擦り込んであるから大丈夫。
MSやらのおかげで最近はずいぶん理解を得やすくなった。
16 仕様書無しさん :2008/06/29(日) 02:48:14ソフトにバグはつきものってことは十分擦り込んであるから大丈夫。
MSやらのおかげで最近はずいぶん理解を得やすくなった。
一般人のテストの感覚でいるんだろうな。
ちょっと使ってみて、うん動く。テストおっけーみたいな。
ソフトウェアのテストとは、動かないところがないか
探すものなんだよ。
ゲームで言えば、ストーリーどおりやってクリアするのはテストじゃない。
裏技を探すのがテストだ。
プログラマーに嫌がられるようになってこそテスターも一人前。
プログラマーに愛想振っているようではまだまだ半人前の若僧だ。
テスター道一筋６年目の俺様が言うのだから間違いない。
24 仕様書無しさん :2008/06/29(日) 10:18:28プログラマーに愛想振っているようではまだまだ半人前の若僧だ。
テスター道一筋６年目の俺様が言うのだから間違いない。
>>19
うちのプロジェクトでは、テスターってプログラマーより給料が少ない。
日本じゃテスターの地位は低いのだ。
だから、みんな、テスターになりたがらない。で、テスターの質が下がる。
現場は、テストの重要性を分かっているが、上層部は、テストは誰でも
できると思っている。馬鹿にでもわかるようにテストの重要性を
解いてくれないか？
26 仕様書無しさん :2008/06/29(日) 12:03:22うちのプロジェクトでは、テスターってプログラマーより給料が少ない。
日本じゃテスターの地位は低いのだ。
だから、みんな、テスターになりたがらない。で、テスターの質が下がる。
現場は、テストの重要性を分かっているが、上層部は、テストは誰でも
できると思っている。馬鹿にでもわかるようにテストの重要性を
解いてくれないか？
テスト工数が軽んじられる傾向にあるのは確かだな。
テストにかかる時間と手間がちゃんと工数に考慮されたら、
そして経験と勘に頼るような人任せなやり方が改善されて、
テスト手法がちゃんと確立されて標準化されたら、みんな
定時で帰れるし、トラブルも減って、もう少しみんながハッ
ピーになれると思うんだけど。
でも現実は、製造とテストは一緒くたに丸投げされて、やら
される方もただ盲目的に「テストOK」の印をつけることだけ
が目的になっている。自分で製造もやってるから隙もできる。
これじゃぁ、質があがるわけない。せめて製造とテストは実施
者を分けるべきじゃないかと思う。
うちのプロジェクトは詳細設計なんてやってる時間があったら
テスト仕様書でも書けよとは思う
どうせ基本設計が腐ってるんだからテストで潰すしかないのに
38 仕様書無しさん :2008/06/29(日) 20:19:17テスト仕様書でも書けよとは思う
どうせ基本設計が腐ってるんだからテストで潰すしかないのに
>>35
要求書はないのか？要求が明確なら少しの労力でテストシナリオを書けるだろ。
37 仕様書無しさん :2008/06/29(日) 20:18:06要求書はないのか？要求が明確なら少しの労力でテストシナリオを書けるだろ。
ちゃんと動くプログラム＞＞＞＞抜けだらけのテスト＞＞＞＞誤りだらけの仕様書
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ま、普通だな。
詳細設計の前に、結果を先に作っておくと言うのも手だぞw
>>40
客に見せるテストパターンとテストクラスとでは粒度が違う気がするけど。
テストドリブンというようりユースケースドリブンじゃね？
要件定義と書いているけど、ユースケースつまりシナリオベースで要件を
整理するわけで、客にテストパターンを見せる必要はないわな。
よーは、日本人が苦手な「全体最適化」だろ。テストというコストが
高い工程を改善するのに全工程をテスト中心に考えるという考え方は
悪くないが、テストドリブンは、大規模プロジェクトでは、失敗
しやすいぜ。
要件定義をした後に、テストパターンを洗い出す必要があるということは
要件定義が完全に終わっていないことを物語っている。
要件定義が完璧ならテストパターンは自ずと決まってくる。
テストパターンを顧客に見せなくてはいけない時点で、
要件定義が不十分だということに気づくべきだな。
43 仕様書無しさん :2008/06/29(日) 23:20:19客に見せるテストパターンとテストクラスとでは粒度が違う気がするけど。
テストドリブンというようりユースケースドリブンじゃね？
要件定義と書いているけど、ユースケースつまりシナリオベースで要件を
整理するわけで、客にテストパターンを見せる必要はないわな。
よーは、日本人が苦手な「全体最適化」だろ。テストというコストが
高い工程を改善するのに全工程をテスト中心に考えるという考え方は
悪くないが、テストドリブンは、大規模プロジェクトでは、失敗
しやすいぜ。
要件定義をした後に、テストパターンを洗い出す必要があるということは
要件定義が完全に終わっていないことを物語っている。
要件定義が完璧ならテストパターンは自ずと決まってくる。
テストパターンを顧客に見せなくてはいけない時点で、
要件定義が不十分だということに気づくべきだな。
>>40
それでも抜けてるテストがあるのがお約束。
さらに、「こんな動かし方もしたいからこういうテストは？」とか聞かれて要件抜けてるのに向こうと気がついたりｗ
まあ、無い頃は良くテスト先に作らないでプロジェクト進んでたなーと思うけどな。
46 仕様書無しさん :2008/06/29(日) 23:30:03それでも抜けてるテストがあるのがお約束。
さらに、「こんな動かし方もしたいからこういうテストは？」とか聞かれて要件抜けてるのに向こうと気がついたりｗ
まあ、無い頃は良くテスト先に作らないでプロジェクト進んでたなーと思うけどな。
>>43
要件定義は、ドメイン知識と経験がいるからね。
開発手法をどうこねくり回しても、抜けをなくすことは不可能だよ。
48 仕様書無しさん :2008/06/29(日) 23:58:03要件定義は、ドメイン知識と経験がいるからね。
開発手法をどうこねくり回しても、抜けをなくすことは不可能だよ。
ユニットテストは一番重要。
それこそ要件定義や設計書なんかよりもな。
要件定義や設計書は所詮、人間が読むもの。
どこまで煮詰めても、あいまいさはなくならない。
そもそも、人間相手だから、なくそうともしていない。
なぜ要件定義や設計が簡単に変わるのがその証拠。
変えたときに絶対存在する問題、あいまいさを考えていないから。
ソフトウェアってのはコードで動く。
コンピュータが100%コードのとおり動く以上、
そこにあいまいさを含めてはいけない。
100%の機械相手だから、あいまいさをなくさないといけない。
人間相手の仕事と機械相手の仕事、どちらがあいまいさのない、
つまりバグのないものを作り上げるプロなのか、言うまでもない話。
58 仕様書無しさん :2008/06/30(月) 00:23:41それこそ要件定義や設計書なんかよりもな。
要件定義や設計書は所詮、人間が読むもの。
どこまで煮詰めても、あいまいさはなくならない。
そもそも、人間相手だから、なくそうともしていない。
なぜ要件定義や設計が簡単に変わるのがその証拠。
変えたときに絶対存在する問題、あいまいさを考えていないから。
ソフトウェアってのはコードで動く。
コンピュータが100%コードのとおり動く以上、
そこにあいまいさを含めてはいけない。
100%の機械相手だから、あいまいさをなくさないといけない。
人間相手の仕事と機械相手の仕事、どちらがあいまいさのない、
つまりバグのないものを作り上げるプロなのか、言うまでもない話。
>>48
頭冷やせ。
ソフトウェア開発は、機械だけ相手にしていたら良いわけではない。
金を払う顧客、それを使うユーザー、他人の作ったコンポーネント。
厳密さを求めるがゆえに大切なものを排除してはいけない。
曖昧なもの、変わるものをコントロールする事の方が重要だ。
ユニットテストはゴールではない。
顧客の要求を満たすことがゴールだ。
日本人はすぐに問題個所を血祭りにあげて「部分最適化」を試みる。
本当に必要なのは、開発プロセス全般の「全体最適化」だ。
その全体に影響を及ぼすのが「要件」じゃないのか？
ユニットテストだけをパーフェクトにしても、大した成果は出ないと
思うがな。
59 仕様書無しさん :2008/06/30(月) 00:34:23頭冷やせ。
ソフトウェア開発は、機械だけ相手にしていたら良いわけではない。
金を払う顧客、それを使うユーザー、他人の作ったコンポーネント。
厳密さを求めるがゆえに大切なものを排除してはいけない。
曖昧なもの、変わるものをコントロールする事の方が重要だ。
ユニットテストはゴールではない。
顧客の要求を満たすことがゴールだ。
日本人はすぐに問題個所を血祭りにあげて「部分最適化」を試みる。
本当に必要なのは、開発プロセス全般の「全体最適化」だ。
その全体に影響を及ぼすのが「要件」じゃないのか？
ユニットテストだけをパーフェクトにしても、大した成果は出ないと
思うがな。
> 曖昧なもの、変わるものをコントロールする事の方が重要だ。
その変わるものをコントロールするのが
ユニットテストだ。
要求や設計変えても、要求仕様書や設計仕様所には
完璧なテストが存在しないから、
変えることをコントロールすることが不可能。
思いつきで変えるからバグがでる。
ユニットテストは一部分のテストではない。
要求から仕様まですべてを対象にしたテストなのだ。
61 仕様書無しさん :2008/06/30(月) 00:41:03その変わるものをコントロールするのが
ユニットテストだ。
要求や設計変えても、要求仕様書や設計仕様所には
完璧なテストが存在しないから、
変えることをコントロールすることが不可能。
思いつきで変えるからバグがでる。
ユニットテストは一部分のテストではない。
要求から仕様まですべてを対象にしたテストなのだ。
>>59
まあがちがちにテストで固めておくと、馬鹿がバグ入れたときにすぐ引っかかるからな。
ユニットテスト＋CVS＋デイリービルドのコンボで何回救われたか…
正直、自分の手の届く範囲でコントロールできない要求仕様とか設計仕様とか営業ｗとかは
理想論吐くだけ虚しい。
62 仕様書無しさん :2008/06/30(月) 00:50:45まあがちがちにテストで固めておくと、馬鹿がバグ入れたときにすぐ引っかかるからな。
ユニットテスト＋CVS＋デイリービルドのコンボで何回救われたか…
正直、自分の手の届く範囲でコントロールできない要求仕様とか設計仕様とか営業ｗとかは
理想論吐くだけ虚しい。
要求や仕様。変わるのはいいが、
変わった後ちゃんとテストしているか？
システムすべてをテストしないといけないんだぞ。
どうせしないだろう？
ユニットテストなら、変わった後すべてをテストしている。
それと同等のことをしないといけないんだぞ。
人間相手だから、あいまいな定義で十分。
それゆえに適当でコードなどで自動化もされていないから
面倒だからとまともなテストができない。
結局ちゃんとしたテストはコードでテストするしかないんだよ。
それがユニットテストなんだよ。
64 仕様書無しさん :2008/06/30(月) 00:54:31変わった後ちゃんとテストしているか？
システムすべてをテストしないといけないんだぞ。
どうせしないだろう？
ユニットテストなら、変わった後すべてをテストしている。
それと同等のことをしないといけないんだぞ。
人間相手だから、あいまいな定義で十分。
それゆえに適当でコードなどで自動化もされていないから
面倒だからとまともなテストができない。
結局ちゃんとしたテストはコードでテストするしかないんだよ。
それがユニットテストなんだよ。
>>62
>変わった後ちゃんとテストしているか？
修正項目に直接関わらない所で仕様の不整合によるBUGが発覚する事が多いよなw
75 仕様書無しさん :2008/06/30(月) 01:47:17>変わった後ちゃんとテストしているか？
修正項目に直接関わらない所で仕様の不整合によるBUGが発覚する事が多いよなw
大規模プロジェクトになると、仕様の矛盾がそもそものBUGの原因になる事が多いよな。
優秀なテスターは、外部テストだけでプログラムの構造、BUGの場所と実装具合が分かる。
121 80 :2008/07/01(火) 23:47:14>>119
同意。さらに言うなら、外部テスト（ブラックボックステスト）で
問題をちゃんと把握できるシステムは良いシステムだと思う。
「テスト可能なシステム」とうわけだ。
ユニットテストに主眼を置かなければ品質を保てないシステムは、どこか
おかしいと思うのだが・・・。
131 仕様書無しさん :2008/07/02(水) 08:12:27同意。さらに言うなら、外部テスト（ブラックボックステスト）で
問題をちゃんと把握できるシステムは良いシステムだと思う。
「テスト可能なシステム」とうわけだ。
ユニットテストに主眼を置かなければ品質を保てないシステムは、どこか
おかしいと思うのだが・・・。
よくある現実
マ「すいません、これ以上仕様変更があると改修はともかく
テストが間に合いません」
上司「テストなんて現地ですればいいよ」
・・・
客「なんだこの不具合だらけのシステムは！こんなものをリリースするなんて
おたくはいったいry)」
132 仕様書無しさん :2008/07/02(水) 08:50:19マ「すいません、これ以上仕様変更があると改修はともかく
テストが間に合いません」
上司「テストなんて現地ですればいいよ」
・・・
客「なんだこの不具合だらけのシステムは！こんなものをリリースするなんて
おたくはいったいry)」
>>131
それで上司が
「俺は関係ない、部下の独断だ」
とか言ったら最悪だな。
133 仕様書無しさん :2008/07/02(水) 13:10:02それで上司が
「俺は関係ない、部下の独断だ」
とか言ったら最悪だな。
>>132
それに近いことは言うけどな
「すいません、開発担当のものたちがスケジュールの調整でうんぬん」
結局自分以外の誰かを悪人にしないとすまないらしい
191 仕様書無しさん :2008/07/05(土) 18:32:10それに近いことは言うけどな
「すいません、開発担当のものたちがスケジュールの調整でうんぬん」
結局自分以外の誰かを悪人にしないとすまないらしい
ところで、仕様書の内容だけで、バグが無いソフトが作れるのかな？
理想としてはそうあるべきなのだろうが、仕様書を書く人に聞きたい。
本当に漏れの無い（全ての例外的な事象を考慮している）仕様書を書いていますか？
結局はプログラマがユニットテストという形で仕様書を書いていませんか？
こういう場合にはこうなるという仕様書がユニットテストの中にしか無いってことありませんか？
たぶんね。仕様書の内容を変更があるたびに短時間で
全て見直すことが出来ない限り漏れが無い仕様書を書くことは
出来ないと思うよ。
ユニットテストのように、OK/NGって表示されないのなら、間違っていてもいいもんね。
だから絶対仕様書のテストをサボるでしょ？ 漏れの無い仕様書書かないでしょ？
だからプログラムコードではない自動的に何度も検証できない仕様書は、
あくまで参考資料のために作るのであって
ユニットテストを本当の仕様書＆テストコードにするべきだよ。
時間は限られているからね。何万とある検証項目を何度もする時間は無いんだよ。
201 80 :2008/07/06(日) 00:22:15理想としてはそうあるべきなのだろうが、仕様書を書く人に聞きたい。
本当に漏れの無い（全ての例外的な事象を考慮している）仕様書を書いていますか？
結局はプログラマがユニットテストという形で仕様書を書いていませんか？
こういう場合にはこうなるという仕様書がユニットテストの中にしか無いってことありませんか？
たぶんね。仕様書の内容を変更があるたびに短時間で
全て見直すことが出来ない限り漏れが無い仕様書を書くことは
出来ないと思うよ。
ユニットテストのように、OK/NGって表示されないのなら、間違っていてもいいもんね。
だから絶対仕様書のテストをサボるでしょ？ 漏れの無い仕様書書かないでしょ？
だからプログラムコードではない自動的に何度も検証できない仕様書は、
あくまで参考資料のために作るのであって
ユニットテストを本当の仕様書＆テストコードにするべきだよ。
時間は限られているからね。何万とある検証項目を何度もする時間は無いんだよ。
>>191
設計書にないコードを書くのは禁止されている。
設計書に間違いがあってもそのままコーディングされる。
設計書に不備があったら、設計者に戻され修正される。
そして、レビューが開催される。
責任関係があいまいになるような開発スタイルは、うちではありえない。
外資系なのでそのあたりはかなりドライ。
235 仕様書無しさん :2008/07/07(月) 08:11:18設計書にないコードを書くのは禁止されている。
設計書に間違いがあってもそのままコーディングされる。
設計書に不備があったら、設計者に戻され修正される。
そして、レビューが開催される。
責任関係があいまいになるような開発スタイルは、うちではありえない。
外資系なのでそのあたりはかなりドライ。
おまいら一生懸命語ってるけどテストなんて
そんなに重視してないよ
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そう思っているのはおまいだけw
>>239
言うと思ったｗ
242 仕様書無しさん :2008/07/07(月) 12:40:45言うと思ったｗ
>>239
勘違いも甚だしいな。
お前が辞めた方が客は喜ぶぞ。
テストの不十分な商品渡されるよりよっぽど安心だろ。
241 仕様書無しさん :2008/07/07(月) 12:30:29勘違いも甚だしいな。
お前が辞めた方が客は喜ぶぞ。
テストの不十分な商品渡されるよりよっぽど安心だろ。
わたしが死んでもわたしの代わり(にテストさせられる可哀想なヤツ)は居るもの
245 仕様書無しさん :2008/07/07(月) 16:29:11>>241
そんな（おれらに被害が及ぶような）こと言うなよ
246 仕様書無しさん :2008/07/07(月) 16:34:17そんな（おれらに被害が及ぶような）こと言うなよ
>>245
だって（めんどくさいんだもの）仕方ないじゃない
だって（めんどくさいんだもの）仕方ないじゃない
昔の記事
■１年前の記事
■２年前の記事
オススメの動画
今日の更新一覧
最近のアンケート一覧
その他の記事
■同じカテゴリー（ネット,PC,技術,知識,薀蓄）の記事を読む
■新しい記事：「秋葉原外国人参政権反対デモ」の参加者が集団で暴行をはたらく
■過去の記事：RPGに壮大な物語は必要なのか？ 毎回人類存亡の危機を救ったりするのもう飽きた
コメントありがとう御座います。⇒最新のコメントへ（46）
テスト
ちんぽ
てすと
サーセンwww
解答がのってない問題集を解くようなもの
何の意味も無い
何の意味も無い
欠陥だらけの製品を発売して、後からアップデートすればいいと
思って出している会社もあるぐらいだ。
思って出している会社もあるぐらいだ。
昔のエロゲメーカーでは日常茶飯事
テストが話題の中心にあるこういう話はとても興味ある。
Vistaはどうしてああなったんだ。
最後の流れが秀逸
そうやって上流の人が、
下流の人をいじめる口実にするんですね。
下流の人をいじめる口実にするんですね。
なんか言い合いが醜い
まだ社会人になってないからいまいち言ってることがわからんが
まだ社会人になってないからいまいち言ってることがわからんが
テスト部隊にいた事あるよ
バグを検出する度に「それはレアケースだから」と言い訳していたPGがいたな
正常系データ流してクリティカルエラー起こしてんのにレアはねーだろ!!単体テストすらしてねーのかよ!?って問い詰めたら「仕様書が悪い」とかﾌｧﾋﾞｮってんの
それを聞いた設計部隊からﾎﾞｺﾎﾞｺに言われて、最後に開発部隊の課長は胃潰瘍で入院した
バグを検出する度に「それはレアケースだから」と言い訳していたPGがいたな
正常系データ流してクリティカルエラー起こしてんのにレアはねーだろ!!単体テストすらしてねーのかよ!?って問い詰めたら「仕様書が悪い」とかﾌｧﾋﾞｮってんの
それを聞いた設計部隊からﾎﾞｺﾎﾞｺに言われて、最後に開発部隊の課長は胃潰瘍で入院した
んー、PMやってる俺の感覚だと
要件定義、基本設計：３割
詳細設計、コーディング：２割
テスト：４割
リリース、アフター：１割
くらいかなあ。テスト大事だよテスト。
要件定義、基本設計：３割
詳細設計、コーディング：２割
テスト：４割
リリース、アフター：１割
くらいかなあ。テスト大事だよテスト。
テスター的ポジションで頼みますとか言われて
なんかかたっぱしから書き直すことになる罠
なんかかたっぱしから書き直すことになる罠
まあ、テストの重要性や手法は、いまや現場によって、
格差が大きいな。
テストプログラムを組んでカバリッジをチェックしながらの
全ステップテスト必須の処もあれば、
未だに目検だけのザルなテストやってるところも多い。
格差が大きいな。
テストプログラムを組んでカバリッジをチェックしながらの
全ステップテスト必須の処もあれば、
未だに目検だけのザルなテストやってるところも多い。
まあ、こうやって地べた這いつくばりながら「俺の方が偉い」とか思ってるから、この業界の底辺は今日も破綻してんだよなwいい加減諦めろよwww
俺は諦めた。
俺は諦めた。
２Ｇのエロゲパッチはいい思い出
こいつらがテストに注目し始めるようになった事は褒めてやってもいい。
が、なんだ最初のは。
ホワイトボックスとブラックボックスを勘違いするとか、新人でもありえん。
最初の以外も、テストの種類が対象とする物がおかしかったりするし、なんじゃこりゃ。
ソフトウェアテストに関する基本的な書物さえ読んでない奴がスレの半分以上なんじゃねーのかこれは。
やはり日本のITは暗いぞ。
JSTQBが普及してテストの地位が向上しますように…
が、なんだ最初のは。
ホワイトボックスとブラックボックスを勘違いするとか、新人でもありえん。
最初の以外も、テストの種類が対象とする物がおかしかったりするし、なんじゃこりゃ。
ソフトウェアテストに関する基本的な書物さえ読んでない奴がスレの半分以上なんじゃねーのかこれは。
やはり日本のITは暗いぞ。
JSTQBが普及してテストの地位が向上しますように…
「要件理解しろよ」って何様！？
普通は、どんな底辺DQNプログラマでも理解できるような仕様書と、
無理なく定義することができて初めて言える台詞だよね？
明らかに要件定義する人のスキル低すぎな人の愚痴にしか聞こえないよ。
もちろん、テストは重要だ。
っつーかさ、テスト工数減らして値段下げろっていう奴、いい加減法律で罰してくれないかね？
民主党サマのお力でさ。（嘲笑
普通は、どんな底辺DQNプログラマでも理解できるような仕様書と、
無理なく定義することができて初めて言える台詞だよね？
明らかに要件定義する人のスキル低すぎな人の愚痴にしか聞こえないよ。
もちろん、テストは重要だ。
っつーかさ、テスト工数減らして値段下げろっていう奴、いい加減法律で罰してくれないかね？
民主党サマのお力でさ。（嘲笑
個別の従事者のレベルが低いというよりも
業界全体でテストにリソース（時間含めた）割くのが重視されてないのが大きいけどな
業界全体でテストにリソース（時間含めた）割くのが重視されてないのが大きいけどな
ソフトは完璧！・・・と思ってたらハードがバグってました、てへっ。
というのは組込み系にたまにある現象。
CPUそのものが停められてたりとか遅いとか、対策めんどいぜ。
というのは組込み系にたまにある現象。
CPUそのものが停められてたりとか遅いとか、対策めんどいぜ。
テストを仕事にしてるものにしかテストの重要性はわからん。
未だにテスターがデバッガーだと思ってる奴が後を立たん。
上もテストについてよく分かってないから見積もり取ってきても準備工数ほとんどないし、氏ね！！
「前のテストシート流用すればすぐテストできるでしょ？」できるかボケ！！
未だにテスターがデバッガーだと思ってる奴が後を立たん。
上もテストについてよく分かってないから見積もり取ってきても準備工数ほとんどないし、氏ね！！
「前のテストシート流用すればすぐテストできるでしょ？」できるかボケ！！
やっぱ単体試験は重要だな。
書類も作らず試験するとメタメタだな。
やっぱ辞めるべきだな。この仕事。
書類も作らず試験するとメタメタだな。
やっぱ辞めるべきだな。この仕事。
うむ、自ら風下に立ってはいけない。
くさい匂いがプンプンするぜぇぇぇぇえ
くさい匂いがプンプンするぜぇぇぇぇえ
単体テストでカバレッジ100%を達成しとくのはプログラマとして最低限のたしなみだろうよ。
つか、そのレベルの話はもはや「テスト」とかいちいち分離して考えるもんじゃなくてコーディングの一貫と言っていい。
つか、そのレベルの話はもはや「テスト」とかいちいち分離して考えるもんじゃなくてコーディングの一貫と言っていい。
2chだとPG、SE関連の話題は盛り上がるよね不思議と
そっち方面の人が多いのかな
そっち方面の人が多いのかな
コード吐けないヤツは書くなよ...
テストドリブンで進めたくても、頭の固い上司に、テストプログラムが間違ってたらどうする？とか言われて鬱陶しい。
今日も天和をツモるテストが始まるぉ〜
※19
ホワイトorブラックボックスの間違いを失笑してるんじゃないと思うぞ・・・
この業界、文脈が読めない子が多くて困る。
ホワイトorブラックボックスの間違いを失笑してるんじゃないと思うぞ・・・
この業界、文脈が読めない子が多くて困る。
品質ってのはな。
作業者が達成するものじゃあないんだよ。
管理者が達成するものなの。
○○テストだとか細かい話じゃあないんだよ・・・。
作業者が達成するものじゃあないんだよ。
管理者が達成するものなの。
○○テストだとか細かい話じゃあないんだよ・・・。
つうかいい加減ウォータフォールやめろよ
地方の中小はカバレッジが導入できない・・・
そもそも、テストの自動化技術とその価値を上が理解していないからな・・・
だれも認めないから使うことが出来ない・・・
結局力業でテストを繰り返すしかなくなる。
そもそも、テストの自動化技術とその価値を上が理解していないからな・・・
だれも認めないから使うことが出来ない・・・
結局力業でテストを繰り返すしかなくなる。
今の流行はテスト駆動開発だからテスターなんていらん
TDDでできるのはユニットテストだ
これはそもそもプログラマの仕事
本来脳内でやっていたことを記述して自動化したものだ
これだけで済むならそりゃテスタはいらん
これはそもそもプログラマの仕事
本来脳内でやっていたことを記述して自動化したものだ
これだけで済むならそりゃテスタはいらん
どんなに正論だろうと、>>1のような言い方する奴は死ねって思うんだ
あじゃいる。
全てはソースですよ。
紙はいらん。
全てはソースですよ。
紙はいらん。
上司「設計が終われば(＝仕様書が書き終われば)開発は8割終わったも同然だ！」
俺「。。。。。orz」
俺「。。。。。orz」
テストと言えば
アジャイルやTDD:自動テスト。多くはユニットテスト。開発と並行して実施。
日本の開発現場：人海戦術の手動テスト。多くは結合テスト。プログラミングが終わったあとで実施。
という違いがあると思う。
だから日本は非効率だと。
アジャイルやTDD:自動テスト。多くはユニットテスト。開発と並行して実施。
日本の開発現場：人海戦術の手動テスト。多くは結合テスト。プログラミングが終わったあとで実施。
という違いがあると思う。
だから日本は非効率だと。
＞ああ、メビウスの輪から抜け出せなくて、いくつものバグを繰り返す〜
逆襲のシャア？
逆襲のシャア？
何このスレ キモイ
windows3.1をあのクオリティで出してOKとするアメリカは
良い国なのか悪い国なのか、
いつも悩む
良い国なのか悪い国なのか、
いつも悩む
JRの面接で、
「不具合は決してなくならない。だからテストが重要です ｷﾘｯ」っていったら、
そんなわけないと、向こうのお偉いさんと言い合いになった……。
「不具合は決してなくならない。だからテストが重要です ｷﾘｯ」っていったら、
そんなわけないと、向こうのお偉いさんと言い合いになった……。
とりあえず「闘うプログラマ」読め
よくわからんが、2chやってるプログラマは「俺は優秀」という気持ちがずいぶんと強いらしい。
カテゴリ別の注目記事の注目記事一覧
お気軽に一言お願いします。
⇒最初のコメントへ（46）
全体のコメント
今日の注目記事
あなたの友だちを見つけてフォローしてください。