08/06/28 19:49:20
何だよ、８割方終わった風な顔で、「コーディング終わりました。後はテストするだけです。」
って...
コーディングが終わってやっと３割終わったかどうかってところだろが。
コーディングが終わってからが本番だっちゅーの。テスト仕様書に従い、テストデータ用意して、
正常系、異常系含めて、抜かりなく全網羅テストすること。これがどれだけ大変なことか。
本当に理解してんのか？ コーディングが終わってやっとスタートラインに立ったぐらいの気持ち
でいろよ、ってくヘラヘラしやがって。
こういう、テストを軽視する輩共が、プログラミングという作業を軽んじ、工数見積りを誤り、
徒に製造を急かし、バグの混入率を間接的に高めているということに気づかんのか。
どんな優秀な奴だって、人間だもの、間違いを犯す。バグを生み出す。それを極力未然に防ぐのが
テストだろ。いつバグが判明するかとドキドキしながら納品後の時間を過ごすか、自信と満足感を
もって笑顔で過ごすか。どちらがいいか自明のことだろ。
プログラミングはなぁ、テストに始まりテストに終わるんだよ。要件を理解し、その中に潜む異常
パターンを見抜き、どんだけ抜かりなくテストをやれるかが一流とカスを分かつ分水嶺だ。
コーディングなんかできてあたり前、肝心なのはテストだ。テストを極めてこそ、一流のプログラ
マーって呼べるんだよ。
この馬鹿者どもが。
2:仕様書無しさん
08/06/28 20:04:31
普通はテスト書いてからコーディング
3:仕様書無しさん
08/06/28 20:04:37
お疲れ様です、テスターさん。
4:仕様書無しさん
08/06/28 20:05:21
普通は納品してからテスト
5:仕様書無しさん
08/06/28 20:12:15
「ユキ！やめろ！まだテストもしていないんだぞ！！」
「今すればいいじゃありませんか！・・」
6:仕様書無しさん
08/06/28 20:15:03
プログラマ一人に対してテスト担当者を一人付けるべきだな。
テストは重要だ。そしてプログラマーは自分のプログラムには甘い。
7:仕様書無しさん
08/06/28 20:50:36
テストが仕様書
8:仕様書無しさん
08/06/28 20:50:55
>>1 なんかは、多分 テスト >>> コーディング とか思ってるんだろうな。
世間は既に、設計 >>>>>>> テスト >> コーディング になってるのに。
9:仕様書無しさん
08/06/28 21:15:28
1.テスト対象クラスのメソッドをテストするコードをテストクラスに書く。
2.メソッドを実装する。
3.1で作ったテストクラスを使って2のメソッドをテストする。
4.テストを通らなければ修正する。
5.1へ戻って次のメソッドを実装する。
この繰り返しこそ、結局は一番確実で早い。
そしてテストクラスを使っていつでも今まで作ったものをテスト
できるから、勇気をもってリファクタリングができる。
10:仕様書無しさん
08/06/28 23:54:14
>>9
それ、ユニットテストじゃん。ユニットテストは普通テスターがやるもの
じゃないっしょ。ユニットテストは、設計レベルの確認でしょ。そのやり方
は、開発規模が大きくなった場合は、現実的には無理だと思うぞ。
顧客の要求レベルのテスト、すなわち、システムテスト（ホワイトボック
ステスト）が、最重要でしょ。
11:仕様書無しさん
08/06/28 23:58:45
上流工程こそ最重要だよ
テスト？やって当然だろ
12:仕様書無しさん
08/06/29 00:39:41
客にバグ出しさせればいいじゃない
13:仕様書無しさん
08/06/29 00:48:47
>>12
はげどう
どうせ仕様が気に入らないっていって大改造させられるんだから
テストなんかしても意味ない
14:仕様書無しさん
08/06/29 00:58:16
>客にバグ出し
へぇ、顧客による受け入れテストってやってないのか？
15:仕様書無しさん
08/06/29 01:22:53
客先でBUGなんか出したら、開発費値切られるだろw
16:仕様書無しさん
08/06/29 02:48:14
一般人のテストの感覚でいるんだろうな。
ちょっと使ってみて、うん動く。テストおっけーみたいな。
ソフトウェアのテストとは、動かないところがないか
探すものなんだよ。
ゲームで言えば、ストーリーどおりやってクリアするのはテストじゃない。
裏技を探すのがテストだ。
17:仕様書無しさん
08/06/29 02:52:23
>>10
> ユニットテストは、設計レベルの確認でしょ。そのやり方
> は、開発規模が大きくなった場合は、現実的には無理だと思うぞ。
逆だろ。
開発規模が大きいのに、ユニットテストをしていないところは
馬鹿 と断言していい。
18:仕様書無しさん
08/06/29 03:22:14
>>15
ソフトにバグはつきものってことは十分擦り込んであるから大丈夫。
MSやらのおかげで最近はずいぶん理解を得やすくなった。
19:仕様書無しさん
08/06/29 03:38:04
プログラマーに嫌がられるようになってこそテスターも一人前。
プログラマーに愛想振っているようではまだまだ半人前の若僧だ。
テスター道一筋６年目の俺様が言うのだから間違いない。
20:仕様書無しさん
08/06/29 04:30:42
(;´д｀)ごめんなさい。
パンチしかできてない、サンプルつぎはぎしただけのでたらめなソースを提出しました。
21:仕様書無しさん
08/06/29 04:54:43
パンチってなに？
22:仕様書無しさん
08/06/29 07:51:20
>>10
> システムテスト（ホワイトボックステスト）が、最重要でしょ。
無理して知らない用語使うなｗ
23:仕様書無しさん
08/06/29 10:10:50
>>17
ユニットテストは、開発者がやるものだと言っただろ。
開発規模が大きくなってもユニットテストは確実にやる。
開発者がな。
俺が言いたいのは、開発規模が大きくなれば、ユニットテストの
積み重ねだけでシステム全体のテストをしたことにはならないという
ことだ。
テスターは、カバレッジをどう確保するかが大切だろ。
ユニットテストに注力してホワイトボックステストをおろそかにするバカは
いないとは思うが、ユニットテストを強調するあたり、分かってないとしか
言いようがない。
ユニットテストは、開発規模が大きくなれば、自動化するもんだ。
うちは、QTP使ってる。システム揃えるのに数千万もする代物だ。
それでも、人件費に比べれば安いものさ。
UnitTestなんて非効率なもの大規模プロジェクトでは使わないんよ。
>>9
のやり方は、開発者にとって効果的だが、テスターが付き合う義理はねぇ。
テスターは、「顧客要求を満たせば、ソースコードは糞でも何でもいい。」
じゃねーのか？
プログラマーに、ユニットテストのスキルを身につけさすのが現実解だろ。
24:仕様書無しさん
08/06/29 10:18:28
>>19
うちのプロジェクトでは、テスターってプログラマーより給料が少ない。
日本じゃテスターの地位は低いのだ。
だから、みんな、テスターになりたがらない。で、テスターの質が下がる。
現場は、テストの重要性を分かっているが、上層部は、テストは誰でも
できると思っている。馬鹿にでもわかるようにテストの重要性を
解いてくれないか？
25:仕様書無しさん
08/06/29 10:44:45
>>22
指摘サンキュ。うっかりしてた、ブラックボックステストだった。
お恥ずかしい。
26:仕様書無しさん
08/06/29 12:03:22
テスト工数が軽んじられる傾向にあるのは確かだな。
テストにかかる時間と手間がちゃんと工数に考慮されたら、
そして経験と勘に頼るような人任せなやり方が改善されて、
テスト手法がちゃんと確立されて標準化されたら、みんな
定時で帰れるし、トラブルも減って、もう少しみんながハッ
ピーになれると思うんだけど。
でも現実は、製造とテストは一緒くたに丸投げされて、やら
される方もただ盲目的に「テストOK」の印をつけることだけ
が目的になっている。自分で製造もやってるから隙もできる。
これじゃぁ、質があがるわけない。せめて製造とテストは実施
者を分けるべきじゃないかと思う。
27:仕様書無しさん
08/06/29 16:22:52
>>25
は？
28:仕様書無しさん
08/06/29 16:26:33
>>23
えーと、何万人月のシステムでも、あなたが担当するのは、一か月でたかだか
一人月かそこらですよ。
29:仕様書無しさん
08/06/29 16:32:29
>>28
だから？
テストするなと？
30:仕様書無しさん
08/06/29 18:06:43
テストをしていないシステムを使うのは、素人が捌いたフグ刺しを食べるようなものだ。
フグの味とともにスリルも味わいたいなら止めはしないが、一般の人にはお勧めしない。
31:仕様書無しさん
08/06/29 18:07:37
>>29
大規模プロジェクトでUnitTestなんか使わないってのの反論。
32:仕様書無しさん
08/06/29 18:10:47
QTPって機能テストツールであって、UnitTestは関係ない
33:仕様書無しさん
08/06/29 18:20:55
ageてる奴がアホ（=1?）
34:仕様書無しさん
08/06/29 18:33:00
言語や設計の本はよく読むのに、テスト関連の本読まれなさすぎ
35:仕様書無しさん
08/06/29 19:40:11
うちのプロジェクトは詳細設計なんてやってる時間があったら
テスト仕様書でも書けよとは思う
どうせ基本設計が腐ってるんだからテストで潰すしかないのに
36:仕様書無しさん
08/06/29 20:17:48
>>32
うちは、QTPを単体テストで使用している。
開発の初期からテストを意識している。
つまり、テストはテスターだけの仕事じゃない。
設計者は、単体テストでテスト自動化を導入できるようにはじめから
設計する。目標は、すべてのテストの自動化と管理だ。
テストは設計の一部だ。
いわゆるユニットテストでは、カバレッジを評価できないし、
達成度も不明確だ。
うちは、ユニットテストからすべてQC/QTPで一元管理している。
そして、統計を取ってシステムやチームの弱点を洗い出す。
QTPは単なるツール。どう使うかは使う側による。
37:仕様書無しさん
08/06/29 20:18:06
ちゃんと動くプログラム＞＞＞＞抜けだらけのテスト＞＞＞＞誤りだらけの仕様書
38:仕様書無しさん
08/06/29 20:19:17
>>35
要求書はないのか？要求が明確なら少しの労力でテストシナリオを書けるだろ。
39:仕様書無しさん
08/06/29 20:21:41
>>37
「ちゃんと動くプログラム」と「テスト」と「仕様書」をなぜに比べる？
一蓮托生だろ。
テストも出来ていない腐った仕様のプログラムは、ちゃんと動いているとは
言えない。
40:仕様書無しさん
08/06/29 21:05:33
今や重要度では
テスト ＞ プログラミング
主従関係も逆転した。
プログラムにテストがくっついているのではない。
テストこそが主。
要件定義 → 用件を満たすテストパターンの洗い出し → テストクラスの作成 → テストを通すための実装
今や時代はこれ。テストドリブン。これ。いわば最初に足枷をはめるやり方。
一見手間がかかるように見えるかもしれんが、結果的には一番効率的。
客にもテストパターンをみせて、「こういう入力の場合はこうなればいいんですね」と、
意外と説明しやすい。
41:仕様書無しさん
08/06/29 21:13:01
>>40
ま、普通だな。
詳細設計の前に、結果を先に作っておくと言うのも手だぞw
42:仕様書無しさん
08/06/29 23:16:39
>>40
客に見せるテストパターンとテストクラスとでは粒度が違う気がするけど。
テストドリブンというようりユースケースドリブンじゃね？
要件定義と書いているけど、ユースケースつまりシナリオベースで要件を
整理するわけで、客にテストパターンを見せる必要はないわな。
よーは、日本人が苦手な「全体最適化」だろ。テストというコストが
高い工程を改善するのに全工程をテスト中心に考えるという考え方は
悪くないが、テストドリブンは、大規模プロジェクトでは、失敗
しやすいぜ。
要件定義をした後に、テストパターンを洗い出す必要があるということは
要件定義が完全に終わっていないことを物語っている。
要件定義が完璧ならテストパターンは自ずと決まってくる。
テストパターンを顧客に見せなくてはいけない時点で、
要件定義が不十分だということに気づくべきだな。
43:仕様書無しさん
08/06/29 23:20:19
>>40
それでも抜けてるテストがあるのがお約束。
さらに、「こんな動かし方もしたいからこういうテストは？」とか聞かれて要件抜けてるのに向こうと気がついたりｗ
まあ、無い頃は良くテスト先に作らないでプロジェクト進んでたなーと思うけどな。
44:仕様書無しさん
08/06/29 23:28:52
このスレってテスト駆動の名前しか知らない人たちばっかりなの？マ板も落ちたもんだな・・・
45:仕様書無しさん
08/06/29 23:30:02
マ板は昔から底辺ですが何か？
46:仕様書無しさん
08/06/29 23:30:03
>>43
要件定義は、ドメイン知識と経験がいるからね。
開発手法をどうこねくり回しても、抜けをなくすことは不可能だよ。
47:仕様書無しさん
08/06/29 23:48:07
>>44
リーン開発とかやってみたくても怖くて仕事にもってけねー
どんな開発手法も、ある程度流行ってからだろ。大手以外は体力無いから二匹目の泥鰌ねらいで
48:仕様書無しさん
08/06/29 23:58:03
ユニットテストは一番重要。
それこそ要件定義や設計書なんかよりもな。
要件定義や設計書は所詮、人間が読むもの。
どこまで煮詰めても、あいまいさはなくならない。
そもそも、人間相手だから、なくそうともしていない。
なぜ要件定義や設計が簡単に変わるのがその証拠。
変えたときに絶対存在する問題、あいまいさを考えていないから。
ソフトウェアってのはコードで動く。
コンピュータが100%コードのとおり動く以上、
そこにあいまいさを含めてはいけない。
100%の機械相手だから、あいまいさをなくさないといけない。
人間相手の仕事と機械相手の仕事、どちらがあいまいさのない、
つまりバグのないものを作り上げるプロなのか、言うまでもない話。
49:仕様書無しさん
08/06/29 23:59:52
118:以下、名無しにかわりましてVIPがお送りします :2008/06/29(日) 21:22:15.60 ID:hxmEELXAO
転載
1:☆ばぐた☆◆JSGFLSFOXQ＠☆ばぐ太☆φ ★ :2008/06/28(土) 11:28:32 ID:???0 [off_go@yahoo.co.jp]
インターネット上には、今回の処分とは全く関係のない複数の女性記者、社員個人の人格を著しく
誹謗（ひぼう）・中傷する映像や書き込みが相次いでいる。毎日新聞はこうした名誉を棄損するなど
明らかな違法行為に対しては、法的措置を取る方針でいる。
URLﾘﾝｸ(mainichi.jp) 後半部分より一部引用
★参考画像：毎日側から見て誹謗中傷に相当する？（2ch有志作成）
URLﾘﾝｸ(asahiru.net)
URLﾘﾝｸ(asahiru.net)より
★まとめサイトより
URLﾘﾝｸ(www9.atwiki.jp)
URLﾘﾝｸ(www8.atwiki.jp)
50:仕様書無しさん
08/06/30 00:00:23
149:以下、名無しにかわりましてVIPがお送りします :2008/06/29(日) 21:49:04.65 ID:snrNPE1y0
マスコミによる報道被害に対しては、スポンサーへの圧力が効果的。以下の２ちゃんねるのコピペによると、
スポンサーへの「抗議」よりも「問い合わせ」のほうが効果があるらしい。毎日新聞のサイトにアクセスし、
スポンサー企業に「問い合わせ」をしよう。
一番効果があるのは、スポンサーへの「抗議」ではなく「問い合わせ」です。
現在マスコミ、とりわけテレビ局のスポンサーは、テレビ局の営業と
直に契約してスポット広告や番組の枠を買っているわけではなく、
間に広告代理店が入ってます。何かの番組がおかしいとして、
その番組のスポンサーに抗議しても、間の広告代理店が調整してしまいます。
翌週にはまったく別のスポンサーとなってしまい、効果がありません。
企業は、一社提供の番組をのぞき、放送の枠の一部を買っているだけで、
その番組に直接タッチしているわけではないのです（これは電通の悪知恵です）
ではどうするか。
問い合わせればいいんです。「この番組はこれこれこうなっているが、
どのような意図でスポンサードしているか、教えていただけますか？」と
問い合わせしましょう。「抗議」のように、言いっぱなしにしないこと。
これが重要です。
問い合わせをすると、その問い合わせは企業から広告代理店にゆき、
最終的には番組の制作スタッフへ行きます。視聴者からではなく、
スポンサーからの問い合わせですから、無視できません。電話で釈明することもできず、
アルバイトや外注に投げることもできず、社員が書類を作って広告代理店や
スポンサーに説明をしに行かないと行けないわけです。
天下のテレビ局の社員であっても、人間ですから一日は２４時間です。
その２４時間のうち、数時間をスポンサーへの釈明に費やさないといけません。
場合によっては一日がかりになるでしょう。彼らはこれを、非常に嫌がります。
51:仕様書無しさん
08/06/30 00:00:53
146:以下、名無しにかわりましてVIPがお送りします :2008/06/29(日) 21:40:48.10 ID:hxmEELXAO
毎日「日本人の母親は中学生の息子のためにフェラチオをする。」
市民「では毎日新聞社員の皆さんも中学時代ママにフェラチオしてもらってたんですね？」
毎日「名誉毀損です。訴えます。」
毎日「24時間オルガズムが止まらない病気で苦しむ日本人女性の数が増えている」
市民「では24時間オルガズムが止まらない病気で苦しむ毎日新聞女性社員も増えているんですね？」
毎日「名誉毀損です。訴えます。」
毎日「日本男子は柔道や空手の部活で男相手に童貞を捨てている。」
市民「では毎日新聞社員の皆さんも柔道や空手の部活で童貞捨てたんですね？」
毎日「名誉毀損です。訴えます。」
毎日「日本人女性の55％は、出会ったその日に男と寝る。」
市民「では毎日新聞の女性社員の55%は出会ったその日に男と寝るのですね？」
毎日「名誉毀損です。訴えます。」
毎日「日本人主婦は皆コインランドリーに附属のコインシャワーで売春している」
市民「では毎日新聞社員の妻は皆コインシャワーで売春しているんですね？」
毎日「名誉毀損です。訴えます。」
52:仕様書無しさん
08/06/30 00:01:20
155:以下、名無しにかわりましてVIPがお送りします :2008/06/29(日) 22:00:06.76 ID:a153r8rjO
>>151
これで少しは把握できるかな？
毎 日 新 聞 の 悪 行 を
絶 対 に 許 し て は な ら な い ！ ！
■ 【毎日新聞英語版から過去に配信された記事】 ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
◆思春期の受験生の集中力を増すために母親はフェラチオで息子の性的欲望を解消する。
◆24時間オルガズムが止まらない病気で苦しむ日本人女性の数が増えている
◆日本人は食事の前にその材料となる動物と獣姦する
◆日本古来の米祭りはアダルトビデオ業界が「顔射」と呼ぶものに非常によく似ている
◆日本人の若い女性はファーストフードを食べると性的狂乱状態になる
◆日本人主婦は皆コインランドリーに附属のコインシャワーで売春している
◆日本のティーンたちはバイアグラを使ってウサギのようにセックスをする
キチガイ記事を英文で、世界中にバラ撒いた狂気の毎日新聞社。
バレれば一方的な処分、謝罪、証拠隠滅。
当時の担当役員が今、社長をやっている真実。
抗議行動に対して法的処置をちらつかせる、恥を知らぬ鬼畜集団。
日本の著名な報道機関として、絶対に許されざる所業である。
毎 日 変 態 新 聞 を 絶 対 に 許 す な ！ ！
53:仕様書無しさん
08/06/30 00:03:33
【9年に渡って配信されつづけ、日本人を激しく貶し続けた記事の一部： 毎日新聞 英語版のサイトにて】
・そして、毎晩、ハルキの勉強は、15分間の母親によるフェラチオから始められた。
・「かつてパールハーバーと南京大虐殺（レイプ・オブ・ナンキン）を起こした日本政府が、
ペドフィル（児童性愛者）向けのマンガを作ってオタクを自衛隊にひきつけようとしている」
・「デブでハゲで臭い旦那から、昔の恋人に抱かれに行く人妻」
・「福岡の米祭りは、顔にベトベトの白い液体を塗るため、AV業界が「顔射」と呼ぶものによく似ている」
・「２４時間オルガズムが止まらない病気で苦しむ日本人女性の数が増えている」
・「ハンバーガーを食べる傾向は日本の女子高生たちを日本で一番の色情狂に変えました。
専門家は、今日の女子高生の無分別な振る舞いは、ハンバーガーのせいだと答えました。」
・「六本木のあるレストランでは、日本人は食事の前にその材料となる動物と獣姦する」
・「濡れてワイルドに : 主婦は近所のコインシャワーで大金を稼ぐ」
・「ほとんどすべての漁師は海でマンタとSEXしている」
・15歳の少女の売春婦が一晩で客を5人とらされ、子宮に炎症を起こしてしまった
・多くの日本人がセックスツアー、奴隷ツアー、残虐ツアーのために海外へ行く
・日本人女性の55％は、出会ったその日に男と寝る。
OLの72％が、セックスをより堪能するために何らかのトレーニングを受けているという。
ルービックキューブ・セックスとは、挿入している間にさまざまに体位を変えること。
これにより、日本人の不器用なセックスが改善される
もし「本番」や「素股」をやるためのお金がなかったら、2980円で「手コキ」をしよう。
まだ10代の少年から退職した老人までみんな手コキを利用している
・高速道路のサービスエリアで、トラック運転手がウェイトレスとセックスをした
・エクアドルでは、日本人はジャングルに放たれた子供たちをライフルでハンティングする。
日本人はべラルーシでも、奴隷オークションに参加し、セックスビジネスのための奴隷を日本に持ち帰る。
尚このサイトには、メタサーチに「hentai」という語句などを付けて、「hentai」でもヒットするように仕向けられていました。
54:仕様書無しさん
08/06/30 00:03:49
スレ違いの書き込みは逆効果だろうがw
55:仕様書無しさん
08/06/30 00:04:24
先日友人の友人（日本人女性）がレイプにあったのね。
こっち（NY）では、日本人女性は尻軽の上に淫乱でレイプ願望があるとかいう
とんでもない誤解があるんだけど、この毎日のHentai記事はそういう偏見
を増幅してるよね。ひどすぎる。不愉快極まりない
９年前から急増の恐ろしい事実
295 名前：名無しさん＠全板トナメ参戦中[] 投稿日：2008/06/29(日) 14:36:00 ID:/LWAY6Jk0
外務省発表の邦人被害統計
URLﾘﾝｸ(www.anzen.mofa.go.jp)より
強姦、強姦致死傷、強制猥褻の被害件数の推移（すべて未遂含む）を纏めてみた
全世界 北米
１９９６ １５ 分類なし
１９９７ １８ ４
１９９８ ２１ ５
１９９９ ３７ ６
２０００ １６ ３
２００１ ３１ ７
２００２ ２９ ７
２００３ ３８ １０
２００４ ４４ ４
２００５ ４５ ８
２００６ ３２ ５
２００７ ３６ ３
やはり被害は確実に増えている。
56:仕様書無しさん
08/06/30 00:05:28
217:以下、名無しにかわりましてVIPがお送りします :2008/06/29(日) 22:56:48.96 ID:FhRpqt8Q0
毎日新聞のスポンサー
キリン
URLﾘﾝｸ(www.kirin.co.jp)
日本HP
URLﾘﾝｸ(welcome.hp.com)
日本エイサー
URLﾘﾝｸ(www.acer.co.jp)
FX｜外国為替証拠金取引 | FXOnline Japan（エフエックス・オンライン・ジャパン）
URLﾘﾝｸ(www.fxonline.co.jp)
旭化成
URLﾘﾝｸ(www.asahi-kasei.co.jp)
日本コカコーラ
URLﾘﾝｸ(www.cocacola.co.jp)
・AU(KDDI)
URLﾘﾝｸ(www.au.kddi.com)
・プジョー
URLﾘﾝｸ(www.peugeot.co.jp)
・野村アセットマネージメント
URLﾘﾝｸ(www.toushin.com)
・マツダ
URLﾘﾝｸ(www.mazda.co.jp)
・日産
URLﾘﾝｸ(www.nissan.co.jp)
セブン-イレブン
URLﾘﾝｸ(www.sej.co.jp)
サッポロビール
URLﾘﾝｸ(www.sapporobeer.jp)
MINI.jp
URLﾘﾝｸ(www.mini.jp)
57:仕様書無しさん
08/06/30 00:06:00
231:以下、名無しにかわりましてVIPがお送りします :2008/06/29(日) 23:22:51.70 ID:XKqK3rzM0 [sage]
まだまだ一市民としてできることはある。
◆スポンサーや折込チラシの会社へ今回の変態記事報道についての見解を質し、
企業のイメージダウンにならないかを尋ねる。
◆ご婦人やご老人をはじめとしたネットにアクセスするのが難しい層へどんどんと
この事実を広めていく。
◆記事によって損害を受けたのかも知れぬ関連団体に対してこの事実について知らせ
どのような対応をするのか聞く。
◆海外へ英語を使って日本の新聞社がやらかしたことをネットで知らせていく。
・
・
・
・
・
まだまだ個人でできることがたくさんあるな。マスコミ権力の横暴は絶対に許さない。
もうマスコミが大きな顔をできる時代は終わったということを知らしめるべきだろう
これがもしかしてマスコミの終わりのはじまりになるかもしれない。
もうすぐ月曜。これからだ
58:仕様書無しさん
08/06/30 00:23:41
>>48
頭冷やせ。
ソフトウェア開発は、機械だけ相手にしていたら良いわけではない。
金を払う顧客、それを使うユーザー、他人の作ったコンポーネント。
厳密さを求めるがゆえに大切なものを排除してはいけない。
曖昧なもの、変わるものをコントロールする事の方が重要だ。
ユニットテストはゴールではない。
顧客の要求を満たすことがゴールだ。
日本人はすぐに問題個所を血祭りにあげて「部分最適化」を試みる。
本当に必要なのは、開発プロセス全般の「全体最適化」だ。
その全体に影響を及ぼすのが「要件」じゃないのか？
ユニットテストだけをパーフェクトにしても、大した成果は出ないと
思うがな。
59:仕様書無しさん
08/06/30 00:34:23
> 曖昧なもの、変わるものをコントロールする事の方が重要だ。
その変わるものをコントロールするのが
ユニットテストだ。
要求や設計変えても、要求仕様書や設計仕様所には
完璧なテストが存在しないから、
変えることをコントロールすることが不可能。
思いつきで変えるからバグがでる。
ユニットテストは一部分のテストではない。
要求から仕様まですべてを対象にしたテストなのだ。
60:仕様書無しさん
08/06/30 00:40:28
>>59
学生はマ板くんなよｗ
61:仕様書無しさん
08/06/30 00:41:03
>>59
まあがちがちにテストで固めておくと、馬鹿がバグ入れたときにすぐ引っかかるからな。
ユニットテスト＋CVS＋デイリービルドのコンボで何回救われたか…
正直、自分の手の届く範囲でコントロールできない要求仕様とか設計仕様とか営業ｗとかは
理想論吐くだけ虚しい。
62:仕様書無しさん
08/06/30 00:50:45
要求や仕様。変わるのはいいが、
変わった後ちゃんとテストしているか？
システムすべてをテストしないといけないんだぞ。
どうせしないだろう？
ユニットテストなら、変わった後すべてをテストしている。
それと同等のことをしないといけないんだぞ。
人間相手だから、あいまいな定義で十分。
それゆえに適当でコードなどで自動化もされていないから
面倒だからとまともなテストができない。
結局ちゃんとしたテストはコードでテストするしかないんだよ。
それがユニットテストなんだよ。
63:仕様書無しさん
08/06/30 00:53:19
そういや営業を忘れていたなｗ
営業もちゃんとテストをしているのか？
顧客から○○機能がほしいといわれたとき、
その機能を追加したときの費用がどれくらいかかるか
納期に間にあうか、それをちゃんとテストしているか？
結局してないだろう。
はいできます！ってその場で無責任に言うのは
簡単で客受けもいいからな。
ユニットテスト以上に完璧なテストをやる方法が
どこにある。
64:仕様書無しさん
08/06/30 00:54:31
>>62
>変わった後ちゃんとテストしているか？
修正項目に直接関わらない所で仕様の不整合によるBUGが発覚する事が多いよなw
65:仕様書無しさん
08/06/30 00:55:19
コストの話かしたい奴と信頼性の話がしたい奴がいて
会話がかみ合ってないね。
66:仕様書無しさん
08/06/30 00:57:24
>>65
コスト？
67:仕様書無しさん
08/06/30 00:57:44
魑魅魍魎が跋扈するこの業界で、ユニットテストこそ
プログラマが唯一信じられるもの。
俺の作業からユニットテストを奪われたら、俺は泣く。
68:仕様書無しさん
08/06/30 01:01:59
>>66
>>42とか
69:仕様書無しさん
08/06/30 01:07:33
>>58とかも
70:仕様書無しさん
08/06/30 01:16:19
ageてる奴は、公開されないクラスのC0カバレッジが100%でなくともいいって主張？
71:仕様書無しさん
08/06/30 01:22:17
>>36
お前さんの言う「大規模プロジェクト」って何人月くらいなんだ？
んで、QTPとやらの一人当たりのライセンス料はいくらで、習得コストはどれくらいなんだ？
72:仕様書無しさん
08/06/30 01:23:53
信頼性に興味がないのでしょう。
73:仕様書無しさん
08/06/30 01:33:11
>>68>>69
コストじゃなくて、「細部」を見るのか「全体」を見るのかの話してるように見えるが。
ただ、テストケース作って勧めるテストドリブンと
テスト工程を前に持ってきただけってのは、大きく違うからそこで話がかみ合ってないんだと思うが。
74:仕様書無しさん
08/06/30 01:44:10
大規模プロジェクトでは、UnitTestは意味無くて、「QTPで行う単体テスト」は意味あるということか？
QTPというのは使ったことないけど、QTPで意味があるなら、UnitTestでも意味があると思うがな。
なぜUnitTestじゃダメなのか、そこんとこもっと詳しく。
75:仕様書無しさん
08/06/30 01:47:17
大規模プロジェクトになると、仕様の矛盾がそもそものBUGの原因になる事が多いよな。
76:仕様書無しさん
08/06/30 01:50:45
テストパターンってなんだよ？
ま、それはともかく、1が何を言いたいのかいまいちよくわからんな。
QTPはすばらしい、QTPを使ってるウチはすばらしい、以上の主張が見えない。
77:仕様書無しさん
08/06/30 01:52:05
バカの一つ覚えと言う言葉がありまして。
78:仕様書無しさん
08/06/30 01:52:20
どんなに大規模なプロジェクトでも、レイヤーや機能で分割されてチーム分けされると思うのだが。
79:仕様書無しさん
08/06/30 01:55:51
あげてる奴が1だとすると、大体においては賛成なんだが、各論総反対、みたいな感じ。
80:仕様書無しさん
08/06/30 18:09:49
>>74
結論から言おう。
ユニットテストをプログラマーが行うとして以下の問題がある。
- 優秀な奴とそうでない奴の差が激しく、属人的でテストの品質がばらつく。
- プログラマーは納期が厳しい。ユニットテストは真っ先に手を抜かれる。
- プログラマーとテスターの両方の能力を持つ人材が少ない。
- プログラマーはテストが嫌い。
- プログラマーが設計するとして、間違った設計をする奴に正しい
テストを書けるはずがない。
- コーダーは、設計の通りにコードを書く。
コーディングに支障がない限り、間違った設計でもそのままコードに
してしまう。コーダーにはユニットテストを書くことはできない。
「チーム内のプログラマー全員が、律儀にユニットテストをこなす。」
という期待は捨てた方がいい。
ポイントは、テストのプロを雇ってテストに専念させる事にある。
「第三者によるテスト」が重要。
>>78
分割すると管理コストが増えるし組織が複雑になる。
そして、意思疎通が難しくなる。
問題が形を変えるだけで何も解決したことにはならない。
81:仕様書無しさん
08/06/30 18:15:00
>>74
ユニットテストを否定するつもりはない。ちゃんとやればかなり効果的だ。
ただし、期待したとおりにプロジェクトは進まない。
ユニットテストは、最後の砦ではない。システムテストが最後の砦だ。
テストを厳密にやるという事に取り組んだことがあるが、コストがかかる
という理由で断念した。
ビジネスの世界の最終目的は、金儲け。対投資効果が得られないと長続き
しない。100%の結果を得るのに100億かかるとして、80%の結果を得るに
40億で済むなら。会社は、後者を選び仕事の量を倍にする。
82:仕様書無しさん
08/06/30 19:23:52
>>80
だから、お前が言う「大規模」ってどのくらいだよ？
> >>78
> 分割すると管理コストが増えるし組織が複雑になる。
> そして、意思疎通が難しくなる。
もちろんそうだが、しかし現実は分割されるだろ？
それに、数百人規模（数千～数万人月）のプロジェクトの場合、一時受けが作業を
一括で請け負って（もちろんその先に有象無象がいるわけだが）、プロジェクト全体で
プロセスを強制することすら不可能な場合が多いのだが。
83:仕様書無しさん
08/06/30 19:24:46
ビッグバンテスト信者ですか
84:仕様書無しさん
08/06/30 19:29:54
ユニットテスト終了＝納品と勘違いしてるんじゃね？
85:仕様書無しさん
08/06/30 19:33:05
あれ？>>36=>>80じゃないのか？いってることが全然違うぞ。
わかりづらいから、数字コテハン使ってくれ。
86:仕様書無しさん
08/06/30 19:38:36
だが断る
87:80
08/06/30 19:56:07
>>82
数百人もいない。100人強だな。そして、全員が精鋭ではない。
あと、実際には分割される。協力企業もいる。
協力企業に開発プロセスを強要できない。請負だからね。
ユニットテストは、CppUnit, JUnitとか単体テストを自動的に行う
あれのことを言っていると思ってるのだが。
単なる単体テストの事なら、今まで俺が書いた事は忘れてくれ。
単体テストは必須だ。
テストを自動的に行うために、テスト自動化用のコードを書いて
メンテナンスを行うのはコストが高くて現実的でないというのが
俺の意見だ。
工数のかかる言語、たとえば、C++/CLIで書いたコードを
工数のかからない言語、VBでテストを書くならまだ納得だ。
テスト用のコードをいかに少ない工数で書くかが重要だと思う。
88:80
08/06/30 20:03:05
近頃のテストの世界では、「カバレッジ」を諦めている節が見受けられる。
ユニットテストで、網羅的にテストを行うと実際のアプリケーションで
は、絶対使用されないシナリオまでテストをする事になってしまう。
それを排除しようとする動きだ。
顧客の要求を満たすためのみにテストすべきだ（それ以外は
やっている時間がない）というトップダウンのアプローチも、ソフトの
規模が大きい昨今ではありなのかもしれない。
89:仕様書無しさん
08/06/30 20:03:53
>>87
QTPの人？
QTPのライセンス料＋教育費は一人当たりどれくらい？
90:仕様書無しさん
08/06/30 20:05:08
>>88
C0カバレッジ100%は必須なの？必須じゃないの？
91:仕様書無しさん
08/06/30 20:08:08
単にユニットテストと聞いてxUnit連想するか？
92:仕様書無しさん
08/06/30 20:11:47
>>80
なんつーか、大筋は同意できるんだが、品質保証と効率的なプロセスとはという点では全く同意できない。
93:仕様書無しさん
08/06/30 20:14:47
>>87
スキルがばらばらの100人超のプロジェクトなんだろ？
>顧客の要求を満たすためのみにテストすべきだ（それ以外は
>やっている時間がない）というトップダウンのアプローチも、ソフトの
>規模が大きい昨今ではありなのかもしれない。
無いよ、絶対に。
94:仕様書無しさん
08/06/30 20:18:54
単体テスト工程を自動にしない奴って、それ以降のテスト工程でコードに修正が入ったとき、
どうやってリグレッションテストをやるんだろうか。
まぁ、やらないんだろうけど。
95:80
08/06/30 20:26:47
>>89
導入を考えているのか？正確にはHPに聞いた方がいいぞ。
一概には言えないからね。ライセンス形態もいろいろだし。
アプリにもよるし。
10名程度のテストチームで運用するとして、
数千万円くらいかかるんじゃないかな。
>>90
C0を100%にしたからといって、万事OKではない。
逆にC0が50%でも全体としては、OKかもしれない。
必須かどうかと言われれば、必須だが。1000万行を超すコードで
どこまでできるかが問題だ。
逆に、質問なんだが。
C++で言うテンプレート、C#とかで言うジェネリクスを使ったコードを
テストするのにカバレッジはどう考えたらいい？
>>91
文面から見て、そんな気がしたんだが。
96:仕様書無しさん
08/06/30 20:31:13
100人で1000万行？
一人10万行？
一体、何人月のシステムなんだよ？
97:仕様書無しさん
08/06/30 20:31:28
>>92
「限りのあるリソースで膨大なテストを作って挫折するやり方」と
「与えられたリソースで最も効果的にテストを行うやり方」
なら俺は後者を選ぶ。
98:仕様書無しさん
08/06/30 20:33:28
>>95
> 10名程度のテストチームで運用するとして、
ありゃ？
開発者（プログラマ）がQTP使うんじゃないの？
> 逆に、質問なんだが。
> C++で言うテンプレート、C#とかで言うジェネリクスを使ったコードを
> テストするのにカバレッジはどう考えたらいい？
どう考えるも何も、C0カバレッジに考えることなんてあるのか？
99:仕様書無しさん
08/06/30 20:34:41
>>97
その後者を実現させる一つの方法が、ユニットテストだと思ってるんだよ。
だから、その点は全く同意できない。
100:仕様書無しさん
08/06/30 20:39:08
テストチームがQTPでテストするとして、プログラマはどうやって単体テストしてるんだ？
101:80
08/06/30 20:40:20
>>98
プログラマーとテスターに別に壁はないので、テスターが管理している
QTPをプログラマーが使わせてもらうことも可能。テストコード自分で
書いてテスターによろしくーってのもあり。柔軟にやってる。
>>99
ユニットテストってどういうものを言ってるんだ？
xUnit?、単なる単体テスト、テストファーストの考え方？アジャイル？
102:仕様書無しさん
08/06/30 20:42:24
え？QTPってテストコード書くのか？
だったらなぜQTPはよくてUnitTestが悪いのか、わけわからん。
103:80
08/06/30 20:50:11
>>102
xUnitだとテスト用のコードを書くのに時間がかかるし、テスターには無理。
QTPのテストコードは、VBScriptでテスターでも書こうと思えばかける。
しかも、自動的にVBScriptのテストコードを生成する機能も付いている。
104:仕様書無しさん
08/06/30 20:53:54
え？テスターとプログラマに壁はないけどスキルの壁はあるのか？
どうでもいいけど、>>100の回答プリーズ。
105:仕様書無しさん
08/06/30 20:55:25
QTPだと時間がかからないのは、使いなれてるから。
どんなツールでも慣れれば時間がかからなくなる。
xUnitが時間がかかると思ってるのは、よく知らないか、慣れてないから。
106:99
08/06/30 20:59:06
>>101
ユニットテストとは、テストの種類。イコール単体テスト。
使うツールは何でもよいが、アドホックなものや繰り返し不可なものは駄目（俺的に）。
107:80
08/06/30 22:01:59
>>104
一般論を言うと、QTPは、システムテスト用のツールでそもそもユニット
テスト用ではない。が、うちでは、ユニットテストにも使ってる。
テストコードは、プログラマが書くが、テストはテスターがやっている。
テストコードは、テスト用データを入力できるようになっている。
テスト用データを用意するのはテスター。
・・・つーかうちの会社の特殊事情聞いてどうするんだ？一般的だとは
言ってないぞ。
108:80
08/06/30 22:04:42
>>106
システムテストはやらないのか？
たぶんやるだろ。
ユニットテストとシステムテストはどちらが大切だと思うんだ？
俺はシステムテストだと思っているんだが・・・。
ユニットテストだけでまさか出荷していないよな。
109:仕様書無しさん
08/06/30 22:18:22
>>12
鉄道動かすプログラムですが、客にバグ出しさせますね＾＾ｖ
110:仕様書無しさん
08/06/30 22:37:47
テストできない仕様は作らない設計。
111:仕様書無しさん
08/06/30 23:13:53
テストはそこそこでいいよ
112:仕様書無しさん
08/06/30 23:26:02
>>107
>テストコードは、プログラマが書くが、テストはテスターがやっている。
なぁ、これテストのプロなのか？
>・・・つーかうちの会社の特殊事情聞いてどうするんだ？一般的だとは
>言ってないぞ。
一般論としてユニットテストを否定してるんだろ？だからどうやってるのか聞いてるんだけど。
>>108
>ユニットテストとシステムテストはどちらが大切だと思うんだ？
どっちも大事に決まってるじゃん。
従来のウォーターフォール的なテストのやり方だと工数が膨らむから、ユニットテストに
力を入れようぜって話だ。
つか、はっきり言って、お前がPMだとしたら、その下でできた1000万行のシステムなんか
受け入れたくないわ。
113:仕様書無しさん
08/07/01 00:24:29
あげてみるテスト
114:仕様書無しさん
08/07/01 00:35:37
>>107
> テストコードは、プログラマが書くが、テストはテスターがやっている。
テストコードをプログラマが書くだって?
テストの品質がばらつくからそりゃ駄目だって主張してるんじゃないのか?
>>80
> - 優秀な奴とそうでない奴の差が激しく、属人的でテストの品質がばらつく。
115:仕様書無しさん
08/07/01 01:27:50
プログラマが書くテストコードは、実際のソースコードの前提条件みたいなもんだよ
「テストの品質」っていうテストは受け入れテストみたいな顧客に近いレベルのテストだね
つまりテスターがやるテストはプログラマがやるテストとは別ってこと
116:仕様書無しさん
08/07/01 01:54:44
ブラックボックスとホワイトボックスの違い？
117:80
08/07/01 06:28:14
>>114
ユニットテストのテストコード -> テスター＆プログラマー
システムテストのテストコード -> テスター
うちのテスターは、すべての仕様書や設計書を読む。
全てのテストは、テスターの監視下で行われる。
もちろん、プログラマーの書いたテストコードも監視下に置かれている。
ユニットテストよりもシステムテストに重きを置いている。
システムテストのカバレッジは100%必須。未達成ならリリースはない。
ユニットテストに関しては、残念ながらカバレッジ100%を待てない。
大抵のプログラマーは、時間切れに陥る。十分な時間を与えてもだ。
プログラマーは、余った時間があればコードを洗練させるがテストは
しない。プログラマーは、テストが嫌いな生き物だ。
118:80
08/07/01 06:40:46
>>115
同意。顧客はテストにも金を払っている。ユニットテストは、顧客にとって
のテストではない。プログラマーの失敗を補うものと思われるので
なかなか顧客には納得が得られない。単体テストとデバッグの違いを
明確に区別して作業しているプログラマーがどれだけいることか・・・。
テスターは、あくまでもシステムテストに主眼を置いている。
ただし、うちはテスターが開発初期からアサインされ、
要求把握、分析、設計、ユニットテスト・・・といろいろな工程を
監視している。
一般的には、ユニットテストは、テスターの仕事ではない。
しかし、ユニットテストが本当に重要だというのなら。
プロに監視してもらうのも一案だし、うちでは、効果があった。
119:仕様書無しさん
08/07/01 08:51:27
優秀なテスターは、外部テストだけでプログラムの構造、BUGの場所と実装具合が分かる。
120:仕様書無しさん
08/07/01 19:54:57
テストの経験を積ませてくれない90人は不幸だよな
121:80
08/07/01 23:47:14
>>119
同意。さらに言うなら、外部テスト（ブラックボックステスト）で
問題をちゃんと把握できるシステムは良いシステムだと思う。
「テスト可能なシステム」とうわけだ。
ユニットテストに主眼を置かなければ品質を保てないシステムは、どこか
おかしいと思うのだが・・・。
122:仕様書無しさん
08/07/01 23:59:12
良くわからんが、テスト駆動の
テスト→実装→レビュー→コミットしてデイリービルドへ
の「テスト」と、完成後の受け入れテストは違うモンだろ？
両方やるんじゃないのか普通。
うちは受け入れテスト（というか、納入前の自社内受け入れテスト）は、専門のテストチームがやってるが。
テスト駆動開発とそうじゃないので、バグ発生件数が如実に違ったから、社内でテスト駆動流行りだした。
123:仕様書無しさん
08/07/02 00:07:17
仕様が明確な場合は有効だと思うが...仕様がなぁ...ころころ変わるぐらい
ならまだしも、がらっと変わるときあるからなぁ。根底から。せっかく作った
テストもぱぁ。せっかくいい調子でやってたのに、モチベーションを木端微塵
にしてくれるよなぁ... あ、スレチスマソ
124:仕様書無しさん
08/07/02 00:30:44
80はユニットテストに主眼を置けと言われてると思ってるみたいだな。
ユニットテストを軽視するなっつーのが大半の意見だと思うけどな。
ユニットテストの自動化を意識してる所は、当然、機能テストもシステムテストも
受け入れテストも自動化を意識してると思う。ユニットテストやってるから、テスト
可能なシステムになってないとでも思ってるんかいな。
それと、機能テスト以外の話が出てこないが、本当のテストのプロは、機能テスト
以外に力を入れるもんだけどな。たとえばISO 9126に基づく品質保証をめざすとかな。
（蛇足だが、テストチームを外部委託すると、確かに数割はテストのプロがいるが、
残りは二重派遣とかが多いぞ。会社名は出さないが、TEF協賛の品質保証専門の
会社のいくつかはそうだ。全部と付き合いがあるわけじゃないから、全部がそうだとは
言わんが）
それから、はっきり言って、コード書けないテスターは「プロ」とは言いたくない。
テスト対象の言語特性も標準ライブラリの仕様も知らずに、効率の良いテストなんか
できるはずない。
プログラマは、本質的にはテストが好きだと俺は思うぞ。まぁこれは定量的な
評価ができないから水かけ論になるだろうが。
ユニットテストが重要なのは、それが設計という意味でのコードの品質を上げる手段に
なるからだ。自分でユニットテストをやらなくては、真の意味でのTestabilityを
考えられるようにはならないと思うぞ。詳しくは説明しないが、ユニットテストは
保守性を大きく向上させる手段になりうる。
80のプロジェクトでは、たまたまうまくいってるんだろうが、ユニットテストレベルのバグが
ぼろぼろ出るプロジェクトは、テスト技術者のモチベーションを著しく落としめて、
プログラマ対テスターという対立構造を生みやすい。
125:仕様書無しさん
08/07/02 00:35:08
長い
126:仕様書無しさん
08/07/02 00:38:17
すまねー。
でも言い足りん。
またどこかで。
127:125
08/07/02 00:39:30
いや、すまん。
俺以外の住人は待ってるのかも知れん。
続けてくれ。
128:>123
08/07/02 01:24:09
使えなくなった(使わなくなった)コードは"習作"と割り切って捨てるが吉
下手に利用しようとして傷口を広げるべからず
129:仕様書無しさん
08/07/02 03:03:17
>>117
> システムテストのカバレッジは100%必須。
そんなことをやっていたら時間がいくらあっても足りない。
たいていのテスターは時間切れに陥る。十分な時間を与えてもだ。
130:仕様書無しさん
08/07/02 03:08:56
> ユニットテストよりもシステムテストに重きを置いている。
> システムテストのカバレッジは100%必須。未達成ならリリースはない。
> ユニットテストに関しては、残念ながらカバレッジ100%を待てない。
これはどういうことを意味するか。
それは、システムテストのカバレッジが100%でも
ユニットテストのカバレッジは100%ではないということ。
つまり、バグがあったとしても、システムテストの
カバレッジが100%になるということを意味する。
これが最近巷でよく発生している「ごくまれな事例において発生する不具合」に
つながっている。つまりテスト不足。
そしてそのいいわけがこれ。
> ユニットテストに関しては、残念ながらカバレッジ100%を待てない。
> 大抵のプログラマーは、時間切れに陥る。十分な時間を与えてもだ。
言い換えると、時間が足りないからテストを省くという意味である。
131:仕様書無しさん
08/07/02 08:12:27
よくある現実
マ「すいません、これ以上仕様変更があると改修はともかく
テストが間に合いません」
上司「テストなんて現地ですればいいよ」
・・・
客「なんだこの不具合だらけのシステムは！こんなものをリリースするなんて
おたくはいったいry)」
132:仕様書無しさん
08/07/02 08:50:19
>>131
それで上司が
「俺は関係ない、部下の独断だ」
とか言ったら最悪だな。
133:仕様書無しさん
08/07/02 13:10:02
>>132
それに近いことは言うけどな
「すいません、開発担当のものたちがスケジュールの調整でうんぬん」
結局自分以外の誰かを悪人にしないとすまないらしい
134:80
08/07/02 21:26:47
>>124
「テストファースト」は賛成だが、「テスト駆動」は反対だ。
前者は、ソフトを作る時に先にテストを考えるというアプローチだ。
後者は、テストに基づいてプログラミングをするということなんだろう。
135:仕様書無しさん
08/07/02 21:35:17
>>134
テストに基づいたプログラミングが、イコール設計に基づいたプログラミングと読めないうちは素人だな。
136:仕様書無しさん
08/07/02 21:36:21
テスト＝設計書という前提だがな。
137:80
08/07/02 21:42:14
>>135
プログラミング可能なテストということなんだろ。
コード化が可能なほど詳細に書かれているテストってどうやって記述
してあるんだ？
設計とテストがイコールということは、設計書のタイトルをテスト仕様書
に変更しても問題ないということか？
テストは、設計からすると客観的な別の存在であるべきではないのか？
138:仕様書無しさん
08/07/02 21:44:10
世の中には外部設計と内部設計とがあってだな（ry
139:80
08/07/02 21:53:46
>>138
外部設計と内部設計は、誤った用語で今は死語になっている。
設計に内部も外部もない。
作りたい対象の詳細が書かれているものが設計書。
外部と内部の区別はない。
140:80
08/07/02 22:16:44
>>130
>それは、システムテストのカバレッジが100%でも
>ユニットテストのカバレッジは100%ではないということ。
>つまり、バグがあったとしても、システムテストの
>カバレッジが100%になるということを意味する。
システムテストのカバレッジが100%＝ユーザーに発見できるバグは0個と
言う定義なので、もしバグが見つかったらシステムテストのカバレッジ
が100%ではなかったということになる。
ユーザーがバグを発見できるということは、それは、システムテストで
テスターでも発見できるはずのバグと言える。
ユニットテストをちゃんとしておくとテスターは楽になる。
でもユーザーには関係がない。
141:仕様書無しさん
08/07/02 22:29:57
>>139
顧客に言えよw
142:124
08/07/02 23:27:10
うーんと、とても100人で1000万行のシステムを作ってる人の発言とは思えないんだよなぁ。
反論するのもアホらしいというか。
かまってちゃんの学生さんって気がしてきた。
143:仕様書無しさん
08/07/02 23:34:18
100人で1000万行が本当だとしても、多分>>80は、まともにコードが書けなくてVBScriptくらいでしか
テストが書けない10人いるテスターの下っ端だろ。
しかも、派遣テスターｗｗｗ
144:仕様書無しさん
08/07/02 23:54:15
アナログ（エンドユーザ） と デジタル（プログラム）
の間をとりもつのがテスト。
それぞれ言い分や希望、得手不得手、好き嫌いが異なるのは
当り前。そこはお互いを尊重し譲歩すべきは譲歩し、テスト
という愛の証、いわば結婚指輪があってこそ両者は結ばれる。
テストのない結納（納品）は、すぐに破局を招くのが必定。
ワハハハハハハハッ なんのこっちゃ
145:仕様書無しさん
08/07/03 00:06:52
100人で1000万行のシステムで、外部設計も内部設計もない設計書しか作らないってどういうこった。
クライアントとレビューして承認してもらうというマイルストーンは無いのか？
仮にあったとして、実装仕様てんこ盛りの仕様書をレビューしてもらってるとかか？
それとも、実装仕様がほとんど書かれてない仕様書しか作らないのか？
それで、スキルがばらばらなプログラマ９０人で、ちゃんとしたユニットテストも行われず、
どうやって品質を担保してんだよ。
その回答が、プロ１０人によるシステムテスト？
146:仕様書無しさん
08/07/03 00:24:57
>>117
> システムテストのカバレッジは100%必須。未達成ならリリースはない。
>>140
> システムテストのカバレッジが100%＝ユーザーに発見できるバグは0個と
> 言う定義なので、もしバグが見つかったらシステムテストのカバレッジ
> が100%ではなかったということになる。
カバレッジが100%に達成したことを証明できる人は誰もいないので、
リリースは永遠にないのですね。わかります。
147:仕様書無しさん
08/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にしとくべきでした。
と、あらためてユニットテストの重要性を認識したしだい。デグレを起こさないため
にもね。
148:仕様書無しさん
08/07/03 00:55:48
うわ、間違ってた。
return d = a / b * 12.34;
じゃなくて、
return a / b * 12.34;
ね。下の奴も同じく。
149:仕様書無しさん
08/07/03 00:58:01
投下するレスのユニットテストも必要だな
150:仕様書無しさん
08/07/03 01:02:24
面目ない。。。。
151:仕様書無しさん
08/07/03 01:06:44
>>80のおかげでユニットテストの重要性を再認識できました。
ありがとう！！>>80
152:仕様書無しさん
08/07/03 20:39:02
>>149
俺たちがバグ出しするから問題ないよ
153:80
08/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 除算くらいは避けよう。
問題点３：
掛け算から先にする。説明が面倒だからググれ。浮動小数点
で演算する場合は、精度を意識しよう。
以上３つの問題点は、ユニットテストでは見つからない。
なぜかって？プログラマーのレベルを超えるユニットテストが行われる
事は不可能だからだ。
154:仕様書無しさん
08/07/04 00:03:14
＞問題点３
＞掛け算から先にする。
え？
155:仕様書無しさん
08/07/04 00:04:08
つかユニットテストコードは先に書け
156:仕様書無しさん
08/07/04 00:08:45
なんかとんでもないこと言い出したな・・・
調子に乗らずにちょっと前までのレスで終わりにしてれば締まってたのに
157:80
08/07/04 00:13:45
>>155
テストファーストの事だな。
>>154
よーく考えてみよう。
ちなみに掛け算から先にする理由は２つある。
158:仕様書無しさん
08/07/04 00:14:57
>>147
プログラミングを軽視する者ども
というスレ立てても良いですか？
159:仕様書無しさん
08/07/04 00:19:57
>>158
「マを侮るなかれ」
ってスレがいいと思います
160:仕様書無しさん
08/07/04 00:29:17
80さんよ
一応言っておくが>154は「かけ算から先」がコードの解説と勘違いしてると思われ
俺もそう勘違いしたけどね
問題点と書きながらいきなり修正案を書くのはアホだろ
161:80
08/07/04 00:37:43
>>160
なるほど。そこまで意識していなかった。
確かにその通りだ。
一応、掛け算を先にする理由を書いておく。
掛け算を先にするとたとえ引数がintでもキャストする必要がなくなる。
演算子は、暗黙のうちにオーバーロードされるからね。
あと、割り算してすごい小さな値になったらその時点で精度が
落ちてしまうから先に掛け算をする方が良いのだ。
分かっている人からすると「何をいまさら・・・。」だろうけど
念のためにね。
162:80
08/07/04 00:43:03
話はそれたけど、結局、プログラマーがユニットテストで解消される
バグは、プログラマーの能力に依存することは分かったと思う。
それでも、ユニットテストは必要だ。ただし、あまり依存しすぎては
いけない。
アジャイルとか、テストファーストとか言っているカリスマプログラマーの
意見は、「天才プログラマーだからこそできる芸当である。」という事を
念頭に置くべきだ。
ユニットテストで成果を出すための前提条件は「高度なプログラミング
能力に裏付けされた分析・設計能力を備えた人材が揃うこと。」
だと俺は思う。
163:仕様書無しさん
08/07/04 00:44:22
どっかの糞コテの文体に似てきたなあ・・・
164:仕様書無しさん
08/07/04 00:45:08
おれは３．５流ＰＧだけど、
だからこそ
作ることよりちゃんと仕様を満たすことの確認こそに命をかける
もってっけー
165:仕様書無しさん
08/07/04 00:59:16
正常系なんて客にやらせる
異常系は自分でやる
これだけやりゃ十分
166:仕様書無しさん
08/07/04 02:24:20
>>162
>話はそれたけど、結局、プログラマーがユニットテストで解消される
>バグは、プログラマーの能力に依存することは分かったと思う。
そこが、まず間違えで、ユニットテストはバグを解消するモノではなくて、
外部仕様（入力・出力・副作用の具体例）そのもの。
今時、テストファーストではない開発は、「ゴールの決まっていないマラソン」
とおなじようにナンセンスだと思うけど、、、
>ユニットテストで成果を出すための前提条件は
>「高度なプログラミング能力に裏付けされた分析・設計能力を
>備えた人材が揃うこと。」
仕様を網羅するユニットテストを作れないということは、
設計できないということと同義。
ユニットテストを作れるくらい全然「高度な人材」ではないと思う。
# 最後はレビュアーの腕次第とはいえ、コード・カバレッジの自動計測
# など網羅性をはかるツールもいろいろ出てきているし、、、
167:仕様書無しさん
08/07/04 02:40:19
>話はそれたけど、結局、プログラマーがユニットテストで解消される
>バグは、プログラマーの能力に依存することは分かったと思う。
テストファーストという言葉があるように、
バグが発生する前から、テストを書くことができるわけなんだよな。
バグが発生する前というのは、コードをかくまえってこと。
ということは当然、コードを書く人ではなく、
仕様を書く人がテストを書いて、あとは実装者に任せるということも可能なわけだ。
だから仕様書を作る人が、テストコード書けばいいんじゃね？
プログラミングができない人が、設計をするのがどれだけナンセンスなことか。
168:仕様書無しさん
08/07/04 02:47:02
携帯電話なんて、発売後に顧客が実地テストさせられてるよなw
169:仕様書無しさん
08/07/04 02:49:50
あれは顧客じゃない
βテスター
170:仕様書無しさん
08/07/04 02:53:07
いや、あの製品とか、あの製品とか。あの製品とかの話だよ。
171:仕様書無しさん
08/07/04 02:54:15
金払ってまでβテスタに立候補するなんてステキ
172:仕様書無しさん
08/07/04 03:00:04
カネ貰ってもお断りしますってカンジだな
173:仕様書無しさん
08/07/04 05:16:42
>>80
>>145にコメントしろ、カス
174:仕様書無しさん
08/07/04 05:26:42
携帯なんて所詮おもちゃ。品質は一番あとまわし。
軍事・航空宇宙・医療機器・発電所とかだと品質が命。
80は何作ってるんだろうね？候補は大体想像つくけど。
175:仕様書無しさん
08/07/04 05:46:53
1000万行のうち、スケルトン・自動生成が700万行なので、UnitTest軽視なんですよ。
176:仕様書無しさん
08/07/04 07:23:13
80はユニットテストは属人性が高いと言っているが、なぜだかシステムテストは属人性が高くない
ような前提になっている。
ユニットテストが成功する前提条件として高度な能力を持ったプログラマが必要としておきながら、
なぜだかシステムテストさえやれば、テスタの能力は関係ないような記述になっている。
また、もっとも効率の良いテストケースを導き出せるのはホワイトボックスの視点を持ったプログラマ
であるにも関わらず、それを全く無視してる。
単体テストは必要であると言いながら、どのように実行しているかを曖昧にして具体的な説明を
避けている。
バグはできるだけ早く解決するのが、もっともコストが低いのは常識なのだが、システムテストまで
解決を遅延させても平気なのはなぜだろうか。
プログラマを育てる気はないのだろうか。全員派遣かSESなのか。
177:仕様書無しさん
08/07/04 20:44:02
> することは分かったと思う。
この辺りの言い回しが非常にうさんくさい
某アホコテっぽいし
178:仕様書無しさん
08/07/04 21:21:15
1000万行ってのが胡散臭いんだよな。
システムテスト件数30万件で、バグは3～6万件くらいか？
10人じゃさばけないよなぁ、コミュニケーションコスト的に。
ちなみに、Windows 2000は2900万行で、出荷前のバグ件数は数十万件だったらしいぞ。
80のシステムは多分業務系だろうから件数は甘めに見積もった。
179:仕様書無しさん
08/07/04 23:17:16
早めにバグを潰した方がトータルコストが安くなる
↓
プログラマはうれしい
↓
テスターもうれしい
↓
でも会社はぼったくるよ
↓
クライアントのためにならない
180:仕様書無しさん
08/07/05 01:38:16
> クライアントのためにならない
ここちょっと違くね？
時間を金で買うクライアントもいるよ
181:仕様書無しさん
08/07/05 08:05:40
トラブルシステムを経験してるクライアントは
品質面についての時間、工数をちゃんと理解してくれることが多いけど
「ハァ？品質？金払ってるんだから問題ない
システム入れんのは当然だろ？スケジュール見直し？
ふざけんな、こっちはお客様だぞ！」
というお客様は多い。
182:仕様書無しさん
08/07/05 11:57:14
同じ物作りでも、H/Wは徹底的にテストするんだよなぁ。
ちゃんとスケジュールを確保し、テスト項目をドキュメント化し、
何回も精査を重ね、それこそ、しつこいぐらいにテストする。
要件や性能の確認ははもちろん、耐久性、動作限界（温度、湿度、
etc..）、危険の可能性はないか、等々。
それにH/Wの場合は、テストだけでなくマニュアルもしっかりして
いる。人命に関わるケースも多いし、法令化されているから当然と
いえば当然なんだけど。
しかし、これほどの徹底したテストを実施しても、品質不良や車の
リコールなどたまにあるわけだけど。
S/W、特に受託型アプリケーション開発の場合は、何故かねぇ...
テストをやらないわけじゃないけど、個人の技量に依存しちゃって
る場合が多いよなぁ。
183:仕様書無しさん
08/07/05 16:05:21
>>162
お前のとこのプロジェクトはテストケースレビューしないのか？
低能一人じゃ無理でも、低能三人集まれば1.5倍の能力にはなる
184:仕様書無しさん
08/07/05 16:14:06
>>183
テストケースレビューって必要か？仕様書がこなれてないだけじゃね？
テストに落とせない仕様書は悪い仕様書。
「URLが開けなかったら、エラーを吐く」←悪い仕様書
「200～206番以外のステータスコードが返ってきたらエラーを吐く」←良い仕様書
良い仕様書は「おいおい、じゃあタイムアウトは別か？俺が担当すんのか？」みたいなツッコミに繋がる。
185:仕様書無しさん
08/07/05 16:15:12
>>183
低能一人増える毎に0.5倍なので0.75倍です。1.5倍になるんなら紛れもなく有能な方です。
ちなみに－倍になるのは無能です。
-倍は成果物が0もしくは、焼き直しの仕様が無い成果物しかつくれないって事ね。
低能は一応引き継ぎ出来る。無能は無駄な作業してから結局破棄して一からやり直すので－倍。
落ち目の会社で人が減っていくのは一番有能な連中が消えて低能や無能が増えるので作業効率が落ちる。
それはまだ言いのだが、上が人月取りたい為にさらに人を増やして作業効率を落とす事するので次に有能な連中が消える。
これのスパイラルが有能が一人もいなくなるまで続く。
(ちなみに、低能が有能に化けるので意外に長く続く 無能は低能にも有能にもならない)
いえ、そのスパイラルの最終段階に移行中なんで > 給料遅配。
186:仕様書無しさん
08/07/05 16:17:58
>>185
会社潰れるとgdgdになるから、今のうちに転職した方が良いよ
責任感から動くと、周りを巻き込んで崩壊するぜ
187:仕様書無しさん
08/07/05 17:48:19
>>184
良い仕様書から作り出すテストって
ほぼ全てがユニットテストで書けるんだよね。
ユニットテストが苦手だといわれていたGUIでさえ、
GUI操作の自動化により、かなりのことが可能になっている。
出来ないのは見た目のデザインぐらいじゃないかな。
（ここの背景はもっと明るい色でとか）
システムテスト？ よくわからないな。
それはユニットテストで出来ないものなのかね？
188:仕様書無しさん
08/07/05 17:54:19
>>187
単なる名称とかやりかたの違いで、システムテストもユニットテストも同じ様なもんだよ。
いくつかのチームで作ってると、単体同士では良くても、全体としてパフォーマンスがでなかったりするから。
デザインのテストみたいな感性系は、テスターが大量にいるからなあ
189:仕様書無しさん
08/07/05 17:55:26
仕様書のテストはどうやるんだ
190:仕様書無しさん
08/07/05 18:17:43
>>189
その仕様書には、どんなことが書いてあるの？
そして、その書いてあることが正しいかどうかは
誰が判断できるの？
この二つの質問に答えることができれば、
おのずとどうやるかがわかると思う。
191:仕様書無しさん
08/07/05 18:32:10
ところで、仕様書の内容だけで、バグが無いソフトが作れるのかな？
理想としてはそうあるべきなのだろうが、仕様書を書く人に聞きたい。
本当に漏れの無い（全ての例外的な事象を考慮している）仕様書を書いていますか？
結局はプログラマがユニットテストという形で仕様書を書いていませんか？
こういう場合にはこうなるという仕様書がユニットテストの中にしか無いってことありませんか？
たぶんね。仕様書の内容を変更があるたびに短時間で
全て見直すことが出来ない限り漏れが無い仕様書を書くことは
出来ないと思うよ。
ユニットテストのように、OK/NGって表示されないのなら、間違っていてもいいもんね。
だから絶対仕様書のテストをサボるでしょ？ 漏れの無い仕様書書かないでしょ？
だからプログラムコードではない自動的に何度も検証できない仕様書は、
あくまで参考資料のために作るのであって
ユニットテストを本当の仕様書＆テストコードにするべきだよ。
時間は限られているからね。何万とある検証項目を何度もする時間は無いんだよ。
192:仕様書無しさん
08/07/05 18:34:03
ユニットテストを書く人をプログラマーと呼ぶか
テスターと呼ぶか設計者と呼ぶかはこの際問題じゃない。
ユニットテストを書く人が一番重要なのさ。
193:仕様書無しさん
08/07/05 18:50:33
シングルタスクのプロセスのテストはまぁ簡単。
だけど、これがマルチタスク、マルチユーザの環境になるととたんに
複雑になる。
排他のことやら、負荷の集中や、リソース不足やら、アクセス制御や
セキュリティー関連やら、想定されるケースが指数関数的に増える。
ファイルひとつアクセスするのにも、DBのトランザクション処理の場合
でも、いろんなケースを想定し、異常ケースでどう振舞うのが正しい
のか考えないといけない。そして普通、仕様書にはそこまで細かく書
いてなく、「このファイルのここをこの値で更新する」ぐらいしか書
いてない。ファイルが無かったらどうするのとか、オープンで失敗した
ら?とか、書き込みで失敗したら? とか。人によってそこを確認する人
もいるけど、だいたいエラーメッセージ出すとか、例外を投げるとか、
アボートさしちゃうとか、PG任せなケースも多いわけで、仕様書とプロ
グラムのギャップってどうしてもあるのよねぇ。ま俺から言わせれば設
計者の怠慢なんだけど、それをいちいち突っ込むのも、時間がなかった
り、面倒くさかったり、人間関係に気を使ったりとかいろいろあってで
きなかったりとか。はぁーとにかくめんどいよ、この業界。
自分でスケジューリングして、自分で設計して、自分でつくって、自分
でテストして、全部自分で責任持つのが一番楽だね。
194:仕様書無しさん
08/07/05 18:51:43
>>193
どこを盾読み?w
195:仕様書無しさん
08/07/05 19:02:30
>>194 14行目の31列目から2行分だ。
196:仕様書無しさん
08/07/05 21:48:53
仕様書のテストなんて恐ろしくて提案出来ないw
197:仕様書無しさん
08/07/05 23:57:14
テストデータをどのくらい作ればいいのか迷う。
198:仕様書無しさん
08/07/06 00:07:11
>>197
顧客が満足するくらい
199:80
08/07/06 00:09:16
>>166
外部仕様書に相当するものは、うちではインターフェース仕様書と
呼んでいる。
インターフェース仕様書は、その実現を記した「設計書」と区別される。
さらに、インターフェース仕様書の実現方法は複数あるので、
インターフェース仕様書１つに対して、複数の設計書が存在することもある。
外部仕様書と内部仕様書という言葉を使っているということは、
オブジェクト指向とか使ってないの？言語は何？
>>178
1000万行ってどうも行数が多いから嘘だと思われているようだな。
俺は逆に、少ないから馬鹿にされているかと思った。
でも、うちの業界では別に多い部類じゃないんだけどね。。。。
ちなみに、業務系じゃないよ。
200:80
08/07/06 00:15:21
>>198
良いことを言うな。
うちの顧客は、ユニットテストにまったく興味がない。
説明しても絶対に理解できないし、説明を聞く気持もない。
顧客に説明しなくてはいけない事は、要求（ユースケース）を正しく実
現出来ているかどうかである。
201:80
08/07/06 00:22:15
>>191
設計書にないコードを書くのは禁止されている。
設計書に間違いがあってもそのままコーディングされる。
設計書に不備があったら、設計者に戻され修正される。
そして、レビューが開催される。
責任関係があいまいになるような開発スタイルは、うちではありえない。
外資系なのでそのあたりはかなりドライ。
202:仕様書無しさん
08/07/06 00:33:54
っていうかどこのシステム。
銀行とか証券とか知っているけど、全システムあわせないとそれ位いかんぞ。
漏れのところは総計10万行で、×20で200万行。
1000万行ってどんな無能が作ってるんだ！？って意味合いでも疑わしい。
203:仕様書無しさん
08/07/06 00:41:55
多分、糞コード、糞仕様オンパレードの携帯の話じゃね？
204:166
08/07/06 01:49:39
>199,200,201
>良いことを言うな。
>うちの顧客は、ユニットテストにまったく興味がない。
>説明しても絶対に理解できないし、説明を聞く気持もない。
>
>顧客に説明しなくてはいけない事は、要求（ユースケース）を正しく実
>現出来ているかどうかである。
なんか、根本的に誤解していない？
誰もこのことに反対しているわけではないですよ。
そもそもシステム「製造」の目的が、
顧客の提示した仕様を満たすモノを作り
そのモノが顧客の提示した仕様を満たすことを証明すること。
であることには議論の余地はない。
で、その最終目的にアタックする足場として、
７合目あたりに強固なベースキャンプ（自動ユニットテスト）
が絶対に必要というのが、80さんの以外のほぼ全員が言っていること。
>設計書にないコードを書くのは禁止されている。
>設計書に間違いがあってもそのままコーディングされる。
>設計書に不備があったら、設計者に戻され修正される。
・・・
>責任関係があいまいになるような開発スタイルは、うちではありえない。
だから、設計にテスト仕様の洗い出しを含めろとあれほど・・・
なんか 191 さんの論旨が全く伝わっていないような希ガス。
>外資系なのでそのあたりはかなりドライ。
今日日むしろ外資系(特に米系、特に"I")はAgile一色。
205:166
08/07/06 02:10:28
>>199
>外部仕様書に相当するものは、うちではインターフェース仕様書と
>呼んでいる。
>インターフェース仕様書は、その実現を記した「設計書」と区別される。
>さらに、インターフェース仕様書の実現方法は複数あるので、
>インターフェース仕様書１つに対して、複数の設計書が存在することもある。
だから何？
テストケースは、インターフェース仕様の一部にすべきという
のが私の論旨なのだが・・・
なぜに、80さんのプロジェクトのドキュメント体型の話をなさる？
>外部仕様書と内部仕様書という言葉を使っているということは、
>オブジェクト指向とか使ってないの？言語は何？
オブジェクト指向だろうが何だろうが、
－プログラムには外部仕様と内部仕様とがある
－－外部仕様はこのプログラムをどう使うかを定義するモノで、
入力・出力・副作用(+前提条件・例外)で表される
－－内部仕様は外部仕様の実現手段
というのは変わらないと思けど、、、
何が言いたいのかよく分かりません。
206:80
08/07/06 08:03:32
>>202
銀行とか証券とかそういうのじゃないよ。って言うか全く違う。
207:80
08/07/06 08:25:39
>>205
ちゃんと整理しよう。
システムの内部＝内部仕様書
システムの外部＝外部仕様書
だろ。まぁ、一見とてもわかりやすいよな。
では質問
１．システム内部とシステム外部の境界は、どちらの仕様書に書くの？
２．開発するシステムに対しして内部と外部があるわな。
開発範囲＝システムとした場合、外部とは、開発範囲の外側と言う
ことにならないか？
たぶん。
205 の頭の中を整理すると
-> 外部仕様書＝インターフェース仕様書、ユースケース仕様書
内部仕様書＝設計書
なんだと思う。
問題点１
システムの外部は、開発対象ではない。
問題店２
レイヤー、サブシステムに分割されているシステムの場合、
あるサブシステムの外部仕様は、上位のサブシステムの内部仕様書
になる（全く一緒ではないが）。つまり、外部と内部でわけると
仕様書に重複が生じる。
また、インターフェースは、レイヤーやサブシステムに縛られない。
つまり、単に外部仕様とすることはできない。
問題点３
インターフェースを誤解している。
インターフェースは、極めて外部に近い内部ということになる。
208:80
08/07/06 08:33:20
>>205
うちは、インターフェースに対するテストを重視している。これを
うちは、システムテスト（サブシステム）テストと呼んでいる。
システムの実現側つまり、ソースコードの隅積みまで
行うテスト（単体テスト、ユニットテスト）は、普通にやってる。
システムテストほど重要視していない。
>>205
の最大の矛盾は、外部仕様書に基づいてテストを単体テストとかユニットテスト
と呼んでいることだ。単体テストは、内部のテストじゃないのか？
外部仕様書が書かれていることがちゃんとできているか＝システムテスト
内部仕様書に書かれていることがちゃんとできているか＝ユニットテスト
だと思うが？だとすると、205は単体テストをやっていないことになるな。
209:仕様書無しさん
08/07/06 09:07:05
としたら、学術系か軍事系か宇宙・航空系か・・・。
まあ
166の言いたい単体・ユニットテストは
>システムのテスト手法の一つで、個々のモジュール(部品)のみを対象としたテスト。
>対象のモジュールが仕様書で要求された機能や性能を満たしているかどうかをテストする。
>複数のモジュールを組み合わせて行なうテストは結合テスト、システム全体を対象に行なうテストはシステムテストという。
80の言いたいのは単体・ユニットテストは
>単体テストとは、プログラムを検証する作業の中でも、プログラムを手続きや関数といった個々の機能ごとに分割し、
>そのそれぞれについて動作検証を行う手法のことである。
大体こんな感じだろ、粒度の問題でその辺変わるので双方間違ってないように見えるけどな。
双方ともシステムやサブシステム”未満”のテストを言っているが、粒度によっては、外部インターフェースとのやり取り
をするレベルだと外部仕様書レベル元に単体・ユニットテストやったりするわけだし。
210:80
08/07/06 09:27:55
仕様書・・・システムが、ユーザー（人、外部システム）に提供する利益
が記されている。
設計書・・・システムが、仕様をどのように実現するかが記されている
仕様書に基づいたテスト・・・システムテスト
設計書に基づいたテスト・・・ユニットテスト
仕様書や設計書はシステム、サブシステム、コンポーネントといった
開発対象それぞれに対して作成される。
○○システム仕様書、○○システム設計書という具合
で、インターフェース仕様書は、インターフェースのことだけ書いた
仕様書。
仕様書と設計書だと、仕様書の方が重要。
人と人とのコミュニケーションやレビューの対象は、おもに仕様書。
設計書は、開発スタイルによるが、自分で設計書書いてプログラミングする
場合は、事細かに書かずに、ユニットテスト（xUnit）で代用することもできる。
ユニットテストはもろ刃の剣で、プログラマーのレベルが高い事が前提だ。
それに、テストコードを書くのはコスト高だ。
これを解決するのに何年か前から試行錯誤を繰り返している。
その解決方法のひとつが、xUnit以外の専用のテストツールを使ったテスト
と第三者によるユニットテストだ。
211:80
08/07/06 09:31:50
>>209
粒度は、開発範囲（スコープ）と詳細度（レベル）の２次元で定義すると。
今回のケースをとらえやすくなる。
今、ごちゃごちゃになっているのは、スコープを無視して話をしているからだ
。外部と内部という簡単な方法で開発対象を規定しようとしているところに
無理があると思ったから、粒度（スコープとレベル）を物差しに加えてみた。
212:80
08/07/06 10:17:18
>>166 の言ってるユニットテストは、
スコープ＝小さなシステム（サブシステム、コンポーネント、ライブラリ）
のシステムテスト（外部から見たふるまいのテスト）だと思う。
213:80
08/07/06 10:18:37
>>209
の言うとおり、粒度に惑わされるが、どんなにスコープが小さくとも
仕様書に基づいたテストは、全部、システムテストだ。
つまり、システムテストは、システム（サブシステム、コンポーネント）の
境界をテストすることだと言える。
システムをサブシステムやコンポーネントに分割すれば、
システムテストの件数が増大する。分割しなければ、ユニットテストの
件数が増大する。
分割していないという事は、システムの詳細を仕様化していない
ことになりテスト工数が増大する。
よーは、システムを適度に分割して、分割した境界についてテストを行う
ことが重要で、単純にユニットテストを強化しても不具合は減らないと
言いたいのだ。
まぁ、よくよく聞けば。同じ事を言っているみたいなので安心した。
要点は、
・テストファースト
→仕様をテスト可能かどうか検証してから設計する。
・粒度が高い場合
システムを分割して、分割したサブシステムを仕様化する。
そして、その際にテストファーストを実施する。
・粒度が低い場合
一人で切り盛りできるレベルになったら、プログラマーに任せる。
あと、俺のミスだが、
ユニットテストをテスターが行うというのは、厳密には、
「粒度の小さいシステムテストもテスターが行う。」だ。
粒度の小さいシステムテスト＝ユニットテストと混同してたな。
214:仕様書無しさん
08/07/06 12:44:42
お前はまず開発工程の定義から勉強して出直して来い
215:仕様書無しさん
08/07/06 13:20:18
>>214
ウォーターフォールに慣れすぎた古き人々よ
落として焼かねば変わらんのか？
216:仕様書無しさん
08/07/06 13:52:45
要求仕様を満たしているかをテストするって考えがまるっきり無いんだな。
自社製品ならまだ知らず、顧客から注文された製品なら、重要な事なのに。
217:仕様書無しさん
08/07/06 16:18:27
> 仕様書に基づいたテストは、全部、システムテストだ。
なら、ユニットテストは全部システムテストってことになるな。
218:仕様書無しさん
08/07/06 16:23:08
ユニットテスト以外で、
どうやってシステムテストをやっているのだろうか？
いや、果たしてやれるのだろうか？
219:仕様書無しさん
08/07/06 16:23:56
> ユニットテストはもろ刃の剣で、プログラマーのレベルが高い事が前提だ。
その点、システムテストは、レベルが低くてもやることができる。と？
220:仕様書無しさん
08/07/06 16:24:48
＞ これを解決するのに何年か前から試行錯誤を繰り返している。
＞ その解決方法のひとつが、xUnit以外の専用のテストツールを使ったテスト
＞ と第三者によるユニットテストだ。
残念ながらユニットテストをやることは必須。
システムテストでは、ユニットテストの代用にはならない。
なぜなら、システムテストは適当なテストだから。
221:仕様書無しさん
08/07/06 16:26:58
「適当なテスト」の意味は、レベルが低いやつでもできるテストであり
バグがないことを保障していない。
値を入れて、それらしい値がでてくれば、それでオッケー的なもの。
例外的なことを考慮していない。異常な値を入れたときどうなるかは
一切考えていない。
222:仕様書無しさん
08/07/06 16:28:48
システムテストでどんな内容をテストしているかを
具体的にいってくれれば、それがユニットテストでやれるってことを
証明できるのになぁｗ
223:仕様書無しさん
08/07/06 16:42:03
>>222
そりゃないんじゃないか？
名前が違うのかも知れないけど、うちのシステムテストって
・チームAが作ったデータベース周り
・チームBが作った入出力周り
・チームCが作った夜間バッチ周り
を、一斉に動かしてどこがボトルネックになってるか調べるテストだけども。
（データベースと入出力のAPIとか応答速度は決めて、その速度出るのはテスト済み）
224:仕様書無しさん
08/07/06 16:59:40
システムテストとユニットテストはやることの対象が違うんだから、
システムテストをいくらしたところで
ユニットテストの工数は減らないよ。
そもそも減らしてはいけない。減らす = サボるってことだから。
システムテストはユニットテストの代わりにはならない。
システムテストをさぼることで、無駄なユニットテストをやらされたとしたら、
それはユニットテストが問題なのではなく、システムテストやったやつがヘボで、
そのとばっちりを食らっただけの話。
225:仕様書無しさん
08/07/06 17:04:33
>>223
ボトルネックになっているとわかった後どうする？
修正するよね？
そのときユニットテストがあれば、
不具合を入れることなくパフォーマンスのみを
あげることができたって自信が持てるよね？
ほらどうだい。ユニットテストってすばらしいだろう？
それにボトルネックになっているのを見極めるために、
同じ条件で同じ操作を何度も繰り返すものだ。
どうだい。ユニットテストで自動化されていればそれも可能だろう？
226:仕様書無しさん
08/07/06 17:06:18
>>225
だからよ。ユニットテストはやってるって書いてるだろう？
>（データベースと入出力のAPIとか応答速度は決めて、その速度出るのはテスト済み）
>システムテストでどんな内容をテストしているかを
>具体的にいってくれれば、それがユニットテストでやれるってことを
>証明できるのになぁｗ
↑は、おかしいだろ。
ユニットテストで出来ることと、システムテストでできることは別じゃね？
227:80
08/07/06 17:20:08
>>217
そもそも、ユニットテストという言葉が微妙なんだ。
>>219
システムテストは複数のテスターによって実行できる。
テスターは単価が安い。
228:80
08/07/06 17:26:31
>>225
の言っているユニットテストはなんなの？
「テスト用のプログラムと結合して自動的にテストを行う」事か？
229:80
08/07/06 18:10:30
>>225
>システムテストでどんな内容をテストしているかを
>具体的にいってくれれば、それがユニットテストでやれるってことを
>証明できるのになぁｗ
もし証明できるなら、逆も証明することになる。
システムテストとユニットテストは等価変換できるという、
相当、大それたことを言っていることに気づこう。
230:仕様書無しさん
08/07/06 18:47:53
80は色々いっているけどプログラムの動作レベルに関して言及していない、
テストは概ねブラックボックスに関して述べている。
よりはっきりいえば、詳細なホワイトボックステストをテスターがやるのは意味が無いといっているとも思われる。
設計がパーペキなら問題ないし(バグはプログラマーの問題)
設計にバグがあるなら差し戻ししてそこからグラマーが直せばよいとの事。
設計通りにすればとりあえずうまくいうと言う考え。
ホワイトボックスのテストはテストツールでやるとかともいっているねー。
それだけの話。
231:80
08/07/06 19:01:54
>>230
残念ながら全然違う。
俺が言ってるのは、ホワイトボックステストを最小限にするという戦略。
部品化を進めて、各部品の仕様書を書く。仕様書に基づいて各部品の
ブラックボックステストを行うのだ。
ホワイトボックステストを最小限にするのに部品化のほかに
「インクリメンタル型の開発」がある。簡単に言えば一気に作り上げて
一気にテストをするのではなく、少しづつ作って少しづつテストをする
のだ。そうすることで、ブラックボックステストとホワイトボックステストの
乖離を最小限にする。
以下の２つを実現したのち、ブラックボックステストが効果的になる。
１．ホワイトボックステストの規模を最小化する。
２．ホワイトボックステストとブラックボックステストの乖離を最少化する。
「問題の難しさ」を「問題の量」に転化したのだから、当然、
ブラックボックステストの件数がかなり多くなる。
これを、テスト自動化によりコストを減らしているわけだ。
まぁ、全部が完全にうまくいっているわけではないが、これ以外に
良い方法を俺は知らない。勉強不足かもしれないので、ヒントを
探しているところさ。
232:仕様書無しさん
08/07/06 20:23:46
一言で言えば、粒度を上げて問題の均質化を狙ったわけね。
でもそれって、改良やパフォーマンスチューニング等で崩れそうなもんだけど。
マルチスレッドに起因するバグ発生したら地獄だな。
233:仕様書無しさん
08/07/07 03:22:05
テストを軽視するのは御役所もいっしょ。
特殊なケースと無理矢理な変数当てはめて机上ではうまくいく。
うまくいくから道路作れ。それ、レッツらゴーってなもんでしょ。
日本という体質そのものがテスト軽視の傾向があるんだよ。
234:仕様書無しさん
08/07/07 05:35:05
>>231
机上の空論。
実戦経験をつめ。
235:仕様書無しさん
08/07/07 08:11:18
おまいら一生懸命語ってるけどテストなんて
そんなに重視してないよ
236:仕様書無しさん
08/07/07 08:26:33
でもテストって大事なんだぜ？
今の現場も結合テスト甘くみやがったせいで
客にブチ切れられて納期延ばし、
メンバーも増員毎日深夜まで再テストだ
そう、つまり黒から一気に赤化
237:仕様書無しさん
08/07/07 11:40:51
>>235
マ辞めちまえ。おまい迷惑。
238:仕様書無しさん
08/07/07 11:45:04
>>237
俺が辞めたら客が困るんだぜ
239:仕様書無しさん
08/07/07 11:47:57
>>238
そう思っているのはおまいだけw
240:仕様書無しさん
08/07/07 12:01:08
>>239
言うと思ったｗ
241:仕様書無しさん
08/07/07 12:30:29
わたしが死んでもわたしの代わり(にテストさせられる可哀想なヤツ)は居るもの
242:仕様書無しさん
08/07/07 12:40:45
>>239
勘違いも甚だしいな。
お前が辞めた方が客は喜ぶぞ。
テストの不十分な商品渡されるよりよっぽど安心だろ。
243:仕様書無しさん
08/07/07 12:43:34
レス先間違えてね？
244:仕様書無しさん
08/07/07 12:55:08
専ブラの番号ズレたんじゃね？
245:仕様書無しさん
08/07/07 16:29:11
>>241
そんな（おれらに被害が及ぶような）こと言うなよ
246:仕様書無しさん
08/07/07 16:34:17
>>245
だって（めんどくさいんだもの）仕方ないじゃない
247:仕様書無しさん
08/07/07 19:53:15
>>210
> 仕様書・・・システムが、ユーザー（人、外部システム）に提供する利益
> が記されている。
世間では、その部分を要件定義書と外部設計書にわけてるんだよ。
例えばユーザインターフェース仕様。これはクライアントが要件として出す場合もあるが
それはまれで、普通はシステムを作る方が設計する。
> 仕様書に基づいたテスト・・・システムテスト
> 設計書に基づいたテスト・・・ユニットテスト
なるほど、「俺定義」で今まで話してたのはわかった。
> 仕様書や設計書はシステム、サブシステム、コンポーネントといった
> 開発対象それぞれに対して作成される。
サブシステム分割や、何をコンポーネント化するかというのは、内部設計と普通は言う。
なので顧客レビューはせず、80定義で言う所の仕様書は書かない。
> ユニットテストはもろ刃の剣で、プログラマーのレベルが高い事が前提だ。
> それに、テストコードを書くのはコスト高だ。
ユニットテストのケースレビューやコードレビューをするという概念は全くないの？
顧客はユニットテストにはお金を出さないというようなことを繰り返し言ってるが、
まったくそんなことない。顧客は品質にもお金を払ってる。
ユニットテストでバグを潰そうが、システムテストでバグを潰そうが、顧客が知ったこっちゃ
ないのは同意する。
248:仕様書無しさん
08/07/07 20:02:58
（続き）
「効率の悪いユニットテスト」や「品質の低いユニットテスト」は確かに否定されるべきだが、
だからと言って、ユニットテストが否定されるものではない。
バグは潰すのが早ければ早いほど、その修正コストは低くなる。これには80も同意してくれる
ものと思う。
「効率の悪いユニットテスト」や「品質の低いユニットテスト」が、開発コストを押し上げている
のであれば、「効率の良いユニットテスト」「品質の高いユニットテスト」に出来ないかを考えるのが
まず第一だ。なぜなら、バグは潰すのが早ければ早いほど修正コストが低いからだ。
修正コストが低ければ、開発コスト全体も低くなり、それが顧客のメリットになる。
ユニットテストをほとんどやらずに、第三者によるシステムテストに力を入れるという方法論も
あるだろう。
俺自身は、この方法論を全く支持しないが、スキルの低いプログラマが多数いるチームであれば
そのような方法論を取った方が、全体のコストが下がるのかもしれない。
しかし、方法論として提示するのであれば、システムテスト重視の方が品質が高くなる理由（根拠）と
ある程度のメトリクスを提示しなければ、第三者を納得させることはできないと思う。
249:仕様書無しさん
08/07/07 20:18:40
サブシステムやコンポーネントやレイヤーを合わせてテストするのは、普通、結合テストと言います。
250:仕様書無しさん
08/07/07 20:28:37
（少し追加）
>>231
> これを、テスト自動化によりコストを減らしているわけだ。
今のところ、80の発言から読み取れる「削減できているもの」は、このシステムテスト
（ブラックボックステスト）実行コストのみだ。
本気でテストの自動化をやってるところは、自動化されたテストの実行コストなど、
テスト全体のコストにほとんど影響を与えないことを知っている。
つまり、本当に自動化されているなら、実行するPCの台数を増やし、夜間に動作
させればよいのである。
問題は、自動化にかかるコストと、第三者検証の場合は、テスタ－プログラマ間の
コミュニケーションコスト、プログラマチームからテスタチームへ引き渡すリソース管理、
出荷判定（100%バグを修正できない場合の判定という意味での）などのコストをどう
減らすかなんだよ。
251:仕様書無しさん
08/07/07 20:31:23
（書き忘れ）
テストのコストを引き上げる要因をひとつ忘れていた。
自動化テストの場合、それが正しいテストかどうかのチェックに非常に時間を取られる。
事前条件は正しいのか、テストの内容は正しいのか、事後条件は正しいのか、（自動）確認は
正しく行えているかなど。
252:仕様書無しさん
08/07/07 20:43:11
・PGが作ったものが「作ったとおりに」動く事（あるパス通したら落ちる、ボタンはあるけど反応がない、など）
単体としてはまともに動く事を確認するのが単体テスト
・１PGから複数PG、はては複数チームが作ったものが、ちゃんと連動すること
お客様にうたった仕様どおりの動作をしている事を確認するのが結合テスト
・（結合との位置づけがあいまいなんだけど）
お客様レベルでの操作をしてもらって、「うん、ちゃんと動いてますね」
って確認を本番環境、現地レベルで取るのがシステムテスト、そして最終的な運用テスト
とか位置づけちゃってたわ、ワタシ
>>248の言うように、単体レベルでの不備はテスト初期（というか開発途中）のレベルで
とっておいた方がいいと思う、コストというより、後の方のテストはざるの目が粗いから
思わぬ不具合（ある異常系パスを通るとシステム全体がダウンしてしまう、など）を
見逃してしまう可能性が高い（下位のレベルの不具合は上位のテストからはブラックボックスなので）
253:仕様書無しさん
08/07/07 21:08:02
最後のは、普通、受け入れテストと言いますね。
254:仕様書無しさん
08/07/07 21:17:01
>>253
thx
255:仕様書無しさん
08/07/07 21:58:28
テストが億劫になるｽﾚだなぁ
256:仕様書無しさん
08/07/07 23:25:27
「システムテスト」が設計(design)ではなく、仕様(specification)に基づくものだという80の意見には同意する。
80が言う方法論には同意しないが。
依然として機能テスト以外のテストに関する話が出てこないが、よくまとまっているページを見つけたので
紹介しておく。
URLﾘﾝｸ(en.wikipedia.org)
システムテストでは、機能的に要件とマッチしていることを保証するとともに、上記ページにあるようなテストを
行うのが一般的だと思う。
まぁ普通は機能外要件を要件定義書に書けるチームはほとんど無いと思うが、「システムテスト」工程で
行うもんなんだよね。
また、いわゆる「内部設計」以外を「仕様書」におこして、それをクライアントレビューにかけるというのは、
双方にとって負担が大きいと思うね。工事進行基準が始まれば、「要件定義書」の範囲も、業界的に合意が
形成されていくのかもしれないね。
257:仕様書無しさん
08/07/08 00:11:34
>>256
wikiを良く纏まったページって紹介するのはなんだと思う。
80の言っている事だけど
一つの方法論だけど・・・、
>「問題の難しさ」を「問題の量」に転化したのだから、当然、
>ブラックボックステストの件数がかなり多くなる。
>これを、テスト自動化によりコストを減らしているわけだ。
テスト項目表作成も自動化しないとコストかかるね。
正確には「正しい｣テスト項目表の作成。
ぶっちゃけ、テストにコストがかかるのではなくて、
テスト項目の洗い出しにコストがかかり、
さらにその妥当性をだすのにコストがかかる。
半年後のユーザの意見を聞きたいな、ボトルネックが山に
様にできてそうだ。
（まあ、最近のPCは出来が良いので問題おこんないって前提だろうけど）
258:80
08/07/08 01:01:27
>>256
■機能要件
機能要件は、インクリメンタル型で開発している。仕様書に基づいて
要求が満たされているかをチェックするのに重点が置かれる。
■フレームワーク
非機能要件は、フレームワークに含まれるのがほとんどで、イテレーティブ
型で開発をしている。
実際には、リファクタリングをしまくるわけだ。つまり、外的な
ふるまいだけをテストして、内部はガンガン変えていくのだ。
なので、単体テストは軽視され回帰テストが重要視される傾向がある。
■再利用可能なコンポーネント
レイヤーの低い位置にいる、再利用可能なコンポーネントは、
不具合が全体に波及するので、ユニットテストからコツコツ積み上げる。
ユニットテストは低レベルのコンポーネント（ライブラリ）開発で役に立つ。
259:80
08/07/08 01:09:01
>>256
>また、いわゆる「内部設計」以外を「仕様書」におこして、それを
>クライアントレビューにかけるというのは、 双方にとって負担が
>大きいと思うね。工事進行基準が始まれば、「要件定義書」の範囲も、
>業界的に合意が形成されていくのかもしれないね。
開発プロジェクト内で閉じるレビューがほとんど。レビューは、一種の
テストだから軽視してはいけない。それに、ドキュメント
に関しては、CMMとかISOとかやってるので結局書かなくてはいけない。
260:仕様書無しさん
08/07/08 01:58:40
80は一体誰と闘い、何が目的なんだ
261:仕様書無しさん
08/07/08 02:10:45
>>259
>>210の内容と、思いっきり矛盾してるのに気がつかないのか？
262:仕様書無しさん
08/07/08 02:22:06
80をやり込めても、誰も何も得しないよ。逆もまた真なり。
263:仕様書無しさん
08/07/08 03:28:11
つまり、80にやり込められても、誰も何も得しないw
264:仕様書無しさん
08/07/08 08:41:06
>>257
システム／ネットワークのパフォーマンス的なボトルネックは生まれにくくなってきてるけど
利用するライブラリ／パッケージ自体は未だに流行に合わせどんどん入れ替わり立ち替わりな
うちのPrjでは、半年以内に「原因不明系」のトラブルが多発してるよ。
ImageGear許すマジ