テストを軽視する者ども

1 ：仕様書無しさん：2008/06/28(土) 19:49:20 .net

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

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

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

この馬鹿者どもが。

2 ：仕様書無しさん：2008/06/28(土) 20:04:31 .net

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

3 ：仕様書無しさん：2008/06/28(土) 20:04:37 .net

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

4 ：仕様書無しさん：2008/06/28(土) 20:05:21 .net

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

5 ：仕様書無しさん：2008/06/28(土) 20:12:15 .net

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

6 ：仕様書無しさん：2008/06/28(土) 20:15:03 .net

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

7 ：仕様書無しさん：2008/06/28(土) 20:50:36 .net

テストが仕様書

8 ：仕様書無しさん：2008/06/28(土) 20:50:55 .net

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

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

9 ：仕様書無しさん：2008/06/28(土) 21:15:28 .net

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

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

10 ：仕様書無しさん：2008/06/28(土) 23:54:14 .net

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

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

11 ：仕様書無しさん：2008/06/28(土) 23:58:45 .net

上流工程こそ最重要だよ

テスト？やって当然だろ

12 ：仕様書無しさん：2008/06/29(日) 00:39:41 .net

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

13 ：仕様書無しさん：2008/06/29(日) 00:48:47 .net

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

14 ：仕様書無しさん：2008/06/29(日) 00:58:16 .net

>客にバグ出し

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

15 ：仕様書無しさん：2008/06/29(日) 01:22:53 .net

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

16 ：仕様書無しさん：2008/06/29(日) 02:48:14 .net

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

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

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

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

17 ：仕様書無しさん：2008/06/29(日) 02:52:23 .net

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

逆だろ。

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

馬鹿 と断言していい。

18 ：仕様書無しさん：2008/06/29(日) 03:22:14 .net

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

19 ：仕様書無しさん：2008/06/29(日) 03:38:04 .net

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

20 ：仕様書無しさん：2008/06/29(日) 04:30:42 .net

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

21 ：仕様書無しさん：2008/06/29(日) 04:54:43 .net

パンチってなに？

22 ：仕様書無しさん：2008/06/29(日) 07:51:20 .net

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

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

23 ：仕様書無しさん：2008/06/29(日) 10:10:50 .net

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

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

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

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

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

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

24 ：仕様書無しさん：2008/06/29(日) 10:18:28 .net

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

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

25 ：仕様書無しさん：2008/06/29(日) 10:44:45 .net

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

26 ：仕様書無しさん：2008/06/29(日) 12:03:22 .net

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

27 ：仕様書無しさん：2008/06/29(日) 16:22:52 .net

>>25
は？

28 ：仕様書無しさん：2008/06/29(日) 16:26:33 .net

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

29 ：仕様書無しさん：2008/06/29(日) 16:32:29 .net

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

30 ：仕様書無しさん：2008/06/29(日) 18:06:43 .net

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

31 ：仕様書無しさん：2008/06/29(日) 18:07:37 .net

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

32 ：仕様書無しさん：2008/06/29(日) 18:10:47 .net

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

33 ：仕様書無しさん：2008/06/29(日) 18:20:55 .net

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

34 ：仕様書無しさん：2008/06/29(日) 18:33:00 .net

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

35 ：仕様書無しさん：2008/06/29(日) 19:40:11 .net

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

36 ：仕様書無しさん：2008/06/29(日) 20:17:48 .net

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

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

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

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

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

37 ：仕様書無しさん：2008/06/29(日) 20:18:06 .net

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

38 ：仕様書無しさん：2008/06/29(日) 20:19:17 .net

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

39 ：仕様書無しさん：2008/06/29(日) 20:21:41 .net

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

40 ：仕様書無しさん：2008/06/29(日) 21:05:33 .net

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

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

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

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

41 ：仕様書無しさん：2008/06/29(日) 21:13:01 .net

>>40
ま、普通だな。

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

42 ：仕様書無しさん：2008/06/29(日) 23:16:39 .net

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

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

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

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

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

43 ：仕様書無しさん：2008/06/29(日) 23:20:19 .net

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

44 ：仕様書無しさん：2008/06/29(日) 23:28:52 .net

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

45 ：仕様書無しさん：2008/06/29(日) 23:30:02 .net

マ板は昔から底辺ですが何か？

46 ：仕様書無しさん：2008/06/29(日) 23:30:03 .net

>>43
要件定義は、ドメイン知識と経験がいるからね。
開発手法をどうこねくり回しても、抜けをなくすことは不可能だよ。

47 ：仕様書無しさん：2008/06/29(日) 23:48:07 .net

>>44
リーン開発とかやってみたくても怖くて仕事にもってけねー
どんな開発手法も、ある程度流行ってからだろ。大手以外は体力無いから二匹目の泥鰌ねらいで

48 ：仕様書無しさん：2008/06/29(日) 23:58:03 .net

ユニットテストは一番重要。
それこそ要件定義や設計書なんかよりもな。

要件定義や設計書は所詮、人間が読むもの。
どこまで煮詰めても、あいまいさはなくならない。
そもそも、人間相手だから、なくそうともしていない。
なぜ要件定義や設計が簡単に変わるのがその証拠。
変えたときに絶対存在する問題、あいまいさを考えていないから。

ソフトウェアってのはコードで動く。
コンピュータが100%コードのとおり動く以上、
そこにあいまいさを含めてはいけない。
100%の機械相手だから、あいまいさをなくさないといけない。

人間相手の仕事と機械相手の仕事、どちらがあいまいさのない、
つまりバグのないものを作り上げるプロなのか、言うまでもない話。

49 ：仕様書無しさん：2008/06/29(日) 23:59:52 .net

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]
インターネット上には、今回の処分とは全く関係のない複数の女性記者、社員個人の人格を著しく
誹謗（ひぼう）・中傷する映像や書き込みが相次いでいる。毎日新聞はこうした名誉を棄損するなど
明らかな違法行為に対しては、法的措置を取る方針でいる。

http://mainichi.jp/info/etc/20080627.html 後半部分より一部引用

★参考画像：毎日側から見て誹謗中傷に相当する？（2ch有志作成）
http://asahiru.net/nakazuri_hentai.jpg
http://asahiru.net/より

★まとめサイトより
http://www9.atwiki.jp/mainichiwaiwai/
http://www8.atwiki.jp/mainichi-matome/pages/1.html

50 ：仕様書無しさん：2008/06/30(月) 00:00:23 .net

149:以下、名無しにかわりましてVIPがお送りします :2008/06/29(日) 21:49:04.65 ID:snrNPE1y0
マスコミによる報道被害に対しては、スポンサーへの圧力が効果的。以下の２ちゃんねるのコピペによると、
スポンサーへの「抗議」よりも「問い合わせ」のほうが効果があるらしい。毎日新聞のサイトにアクセスし、
スポンサー企業に「問い合わせ」をしよう。

一番効果があるのは、スポンサーへの「抗議」ではなく「問い合わせ」です。
現在マスコミ、とりわけテレビ局のスポンサーは、テレビ局の営業と
直に契約してスポット広告や番組の枠を買っているわけではなく、
間に広告代理店が入ってます。何かの番組がおかしいとして、
その番組のスポンサーに抗議しても、間の広告代理店が調整してしまいます。
翌週にはまったく別のスポンサーとなってしまい、効果がありません。
企業は、一社提供の番組をのぞき、放送の枠の一部を買っているだけで、
その番組に直接タッチしているわけではないのです（これは電通の悪知恵です）
ではどうするか。
問い合わせればいいんです。「この番組はこれこれこうなっているが、
どのような意図でスポンサードしているか、教えていただけますか？」と
問い合わせしましょう。「抗議」のように、言いっぱなしにしないこと。
これが重要です。
問い合わせをすると、その問い合わせは企業から広告代理店にゆき、
最終的には番組の制作スタッフへ行きます。視聴者からではなく、
スポンサーからの問い合わせですから、無視できません。電話で釈明することもできず、
アルバイトや外注に投げることもできず、社員が書類を作って広告代理店や
スポンサーに説明をしに行かないと行けないわけです。
天下のテレビ局の社員であっても、人間ですから一日は２４時間です。
その２４時間のうち、数時間をスポンサーへの釈明に費やさないといけません。
場合によっては一日がかりになるでしょう。彼らはこれを、非常に嫌がります。

51 ：仕様書無しさん：2008/06/30(月) 00:00:53 .net

146:以下、名無しにかわりましてVIPがお送りします :2008/06/29(日) 21:40:48.10 ID:hxmEELXAO
毎日「日本人の母親は中学生の息子のためにフェラチオをする。」
市民「では毎日新聞社員の皆さんも中学時代ママにフェラチオしてもらってたんですね？」
毎日「名誉毀損です。訴えます。」

毎日「24時間オルガズムが止まらない病気で苦しむ日本人女性の数が増えている」
市民「では24時間オルガズムが止まらない病気で苦しむ毎日新聞女性社員も増えているんですね？」
毎日「名誉毀損です。訴えます。」

毎日「日本男子は柔道や空手の部活で男相手に童貞を捨てている。」
市民「では毎日新聞社員の皆さんも柔道や空手の部活で童貞捨てたんですね？」
毎日「名誉毀損です。訴えます。」

毎日「日本人女性の55％は、出会ったその日に男と寝る。」
市民「では毎日新聞の女性社員の55%は出会ったその日に男と寝るのですね？」
毎日「名誉毀損です。訴えます。」

毎日「日本人主婦は皆コインランドリーに附属のコインシャワーで売春している」
市民「では毎日新聞社員の妻は皆コインシャワーで売春しているんですね？」
毎日「名誉毀損です。訴えます。」

52 ：仕様書無しさん：2008/06/30(月) 00:01:20 .net

155:以下、名無しにかわりましてVIPがお送りします :2008/06/29(日) 22:00:06.76 ID:a153r8rjO
>>151
これで少しは把握できるかな？

毎　日　新　聞　の　悪　行　を　
　絶　対　に　許　し　て　は　な　ら　な　い　！　！

■ 【毎日新聞英語版から過去に配信された記事】 ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

　◆思春期の受験生の集中力を増すために母親はフェラチオで息子の性的欲望を解消する。
　◆24時間オルガズムが止まらない病気で苦しむ日本人女性の数が増えている
　◆日本人は食事の前にその材料となる動物と獣姦する
　◆日本古来の米祭りはアダルトビデオ業界が「顔射」と呼ぶものに非常によく似ている
　◆日本人の若い女性はファーストフードを食べると性的狂乱状態になる
　◆日本人主婦は皆コインランドリーに附属のコインシャワーで売春している
　◆日本のティーンたちはバイアグラを使ってウサギのようにセックスをする


キチガイ記事を英文で、世界中にバラ撒いた狂気の毎日新聞社。

バレれば一方的な処分、謝罪、証拠隠滅。

当時の担当役員が今、社長をやっている真実。

抗議行動に対して法的処置をちらつかせる、恥を知らぬ鬼畜集団。

日本の著名な報道機関として、絶対に許されざる所業である。


毎　日　変　態　新　聞　を　絶　対　に　許　す　な　！　！

53 ：仕様書無しさん：2008/06/30(月) 00:03:33 .net

【9年に渡って配信されつづけ、日本人を激しく貶し続けた記事の一部：　毎日新聞　英語版のサイトにて】

・そして、毎晩、ハルキの勉強は、15分間の母親によるフェラチオから始められた。
・「かつてパールハーバーと南京大虐殺（レイプ・オブ・ナンキン）を起こした日本政府が、
　ペドフィル（児童性愛者）向けのマンガを作ってオタクを自衛隊にひきつけようとしている」
・「デブでハゲで臭い旦那から、昔の恋人に抱かれに行く人妻」
・「福岡の米祭りは、顔にベトベトの白い液体を塗るため、AV業界が「顔射」と呼ぶものによく似ている」
・「２４時間オルガズムが止まらない病気で苦しむ日本人女性の数が増えている」
・「ハンバーガーを食べる傾向は日本の女子高生たちを日本で一番の色情狂に変えました。
　専門家は、今日の女子高生の無分別な振る舞いは、ハンバーガーのせいだと答えました。」
・「六本木のあるレストランでは、日本人は食事の前にその材料となる動物と獣姦する」
・「濡れてワイルドに : 主婦は近所のコインシャワーで大金を稼ぐ」
・「ほとんどすべての漁師は海でマンタとSEXしている」
・15歳の少女の売春婦が一晩で客を5人とらされ、子宮に炎症を起こしてしまった
・多くの日本人がセックスツアー、奴隷ツアー、残虐ツアーのために海外へ行く
・日本人女性の55％は、出会ったその日に男と寝る。
OLの72％が、セックスをより堪能するために何らかのトレーニングを受けているという。
ルービックキューブ・セックスとは、挿入している間にさまざまに体位を変えること。
これにより、日本人の不器用なセックスが改善される
もし「本番」や「素股」をやるためのお金がなかったら、2980円で「手コキ」をしよう。
まだ10代の少年から退職した老人までみんな手コキを利用している
・高速道路のサービスエリアで、トラック運転手がウェイトレスとセックスをした
・エクアドルでは、日本人はジャングルに放たれた子供たちをライフルでハンティングする。
日本人はべラルーシでも、奴隷オークションに参加し、セックスビジネスのための奴隷を日本に持ち帰る。
尚このサイトには、メタサーチに「hentai」という語句などを付けて、「hentai」でもヒットするように仕向けられていました。

54 ：仕様書無しさん：2008/06/30(月) 00:03:49 .net

スレ違いの書き込みは逆効果だろうがw

55 ：仕様書無しさん：2008/06/30(月) 00:04:24 .net

先日友人の友人（日本人女性）がレイプにあったのね。
こっち（NY）では、日本人女性は尻軽の上に淫乱でレイプ願望があるとかいう
とんでもない誤解があるんだけど、この毎日のHentai記事はそういう偏見
を増幅してるよね。ひどすぎる。不愉快極まりない
９年前から急増の恐ろしい事実
295 名前：名無しさん＠全板トナメ参戦中[] 投稿日：2008/06/29(日) 14:36:00 ID:/LWAY6Jk0
外務省発表の邦人被害統計
http://www.anzen.mofa.go.jp/anzen_info/support.htmlより
強姦、強姦致死傷、強制猥褻の被害件数の推移（すべて未遂含む）を纏めてみた

　　　　　　　全世界　　　　北米
１９９６　　　１５　　　　分類なし
１９９７　　　１８　　　　　４
１９９８　　　２１　　　　　５
１９９９　　　３７　　　　　６
２０００　　　１６　　　　　３
２００１　　　３１　　　　　７
２００２　　　２９　　　　　７
２００３　　　３８　　　　１０
２００４　　　４４　　　　　４
２００５　　　４５　　　　　８
２００６　　　３２　　　　　５
２００７　　　３６　　　　　３

やはり被害は確実に増えている。

56 ：仕様書無しさん：2008/06/30(月) 00:05:28 .net

217:以下、名無しにかわりましてVIPがお送りします :2008/06/29(日) 22:56:48.96 ID:FhRpqt8Q0
毎日新聞のスポンサー
キリン
http://www.kirin.co.jp/
日本HP
http://welcome.hp.com/country/jp/ja/welcome.html
日本エイサー
http://www.acer.co.jp/
FX｜外国為替証拠金取引 | FXOnline Japan（エフエックス・オンライン・ジャパン）
http://www.fxonline.co.jp/
旭化成
http://www.asahi-kasei.co.jp/asahi/jp/
日本コカコーラ
http://www.cocacola.co.jp/
・AU(KDDI)
http://www.au.kddi.com/
・プジョー
http://www.peugeot.co.jp/index.html
・野村アセットマネージメント
http://www.toushin.com/firms/k0000001.htm
・マツダ
http://www.mazda.co.jp/home.html
・日産
http://www.nissan.co.jp/
セブン-イレブン
http://www.sej.co.jp/index.html
サッポロビール
http://www.sapporobeer.jp/
MINI.jp
http://www.mini.jp/mini.html

57 ：仕様書無しさん：2008/06/30(月) 00:06:00 .net

231:以下、名無しにかわりましてVIPがお送りします :2008/06/29(日) 23:22:51.70 ID:XKqK3rzM0 [sage]
まだまだ一市民としてできることはある。
◆スポンサーや折込チラシの会社へ今回の変態記事報道についての見解を質し、
企業のイメージダウンにならないかを尋ねる。
◆ご婦人やご老人をはじめとしたネットにアクセスするのが難しい層へどんどんと
この事実を広めていく。
◆記事によって損害を受けたのかも知れぬ関連団体に対してこの事実について知らせ
どのような対応をするのか聞く。
◆海外へ英語を使って日本の新聞社がやらかしたことをネットで知らせていく。
　　　　　　　　　　　　　　　・
　　　　　　　　　　　　　　　・
　　　　　　　　　　　　　　　・
　　　　　　　　　　　　　　　・
　　　　　　　　　　　　　　　・
まだまだ個人でできることがたくさんあるな。マスコミ権力の横暴は絶対に許さない。
もうマスコミが大きな顔をできる時代は終わったということを知らしめるべきだろう
これがもしかしてマスコミの終わりのはじまりになるかもしれない。
もうすぐ月曜。これからだ

58 ：仕様書無しさん：2008/06/30(月) 00:23:41 .net

>>48
頭冷やせ。
ソフトウェア開発は、機械だけ相手にしていたら良いわけではない。
金を払う顧客、それを使うユーザー、他人の作ったコンポーネント。

厳密さを求めるがゆえに大切なものを排除してはいけない。
曖昧なもの、変わるものをコントロールする事の方が重要だ。

ユニットテストはゴールではない。
顧客の要求を満たすことがゴールだ。

日本人はすぐに問題個所を血祭りにあげて「部分最適化」を試みる。
本当に必要なのは、開発プロセス全般の「全体最適化」だ。
その全体に影響を及ぼすのが「要件」じゃないのか？

ユニットテストだけをパーフェクトにしても、大した成果は出ないと
思うがな。

59 ：仕様書無しさん：2008/06/30(月) 00:34:23 .net

> 曖昧なもの、変わるものをコントロールする事の方が重要だ。

その変わるものをコントロールするのが
ユニットテストだ。

要求や設計変えても、要求仕様書や設計仕様所には
完璧なテストが存在しないから、
変えることをコントロールすることが不可能。

思いつきで変えるからバグがでる。

ユニットテストは一部分のテストではない。
要求から仕様まですべてを対象にしたテストなのだ。

60 ：仕様書無しさん：2008/06/30(月) 00:40:28 .net

>>59
学生はマ板くんなよｗ

61 ：仕様書無しさん：2008/06/30(月) 00:41:03 .net

>>59
まあがちがちにテストで固めておくと、馬鹿がバグ入れたときにすぐ引っかかるからな。
ユニットテスト＋CVS＋デイリービルドのコンボで何回救われたか…

正直、自分の手の届く範囲でコントロールできない要求仕様とか設計仕様とか営業ｗとかは
理想論吐くだけ虚しい。

62 ：仕様書無しさん：2008/06/30(月) 00:50:45 .net

要求や仕様。変わるのはいいが、
変わった後ちゃんとテストしているか？
システムすべてをテストしないといけないんだぞ。

どうせしないだろう？

ユニットテストなら、変わった後すべてをテストしている。
それと同等のことをしないといけないんだぞ。

人間相手だから、あいまいな定義で十分。
それゆえに適当でコードなどで自動化もされていないから
面倒だからとまともなテストができない。

結局ちゃんとしたテストはコードでテストするしかないんだよ。
それがユニットテストなんだよ。

63 ：仕様書無しさん：2008/06/30(月) 00:53:19 .net

そういや営業を忘れていたなｗ

営業もちゃんとテストをしているのか？
顧客から○○機能がほしいといわれたとき、
その機能を追加したときの費用がどれくらいかかるか
納期に間にあうか、それをちゃんとテストしているか？

結局してないだろう。
はいできます！ってその場で無責任に言うのは
簡単で客受けもいいからな。

ユニットテスト以上に完璧なテストをやる方法が
どこにある。

64 ：仕様書無しさん：2008/06/30(月) 00:54:31 .net

>>62
>変わった後ちゃんとテストしているか？

修正項目に直接関わらない所で仕様の不整合によるBUGが発覚する事が多いよなw

65 ：仕様書無しさん：2008/06/30(月) 00:55:19 .net

コストの話かしたい奴と信頼性の話がしたい奴がいて
会話がかみ合ってないね。

66 ：仕様書無しさん：2008/06/30(月) 00:57:24 .net

>>65
コスト？

67 ：仕様書無しさん：2008/06/30(月) 00:57:44 .net

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

68 ：仕様書無しさん：2008/06/30(月) 01:01:59 .net

>>66
>>42とか

69 ：仕様書無しさん：2008/06/30(月) 01:07:33 .net

>>58とかも

70 ：仕様書無しさん：2008/06/30(月) 01:16:19 .net

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

71 ：仕様書無しさん：2008/06/30(月) 01:22:17 .net

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

72 ：仕様書無しさん：2008/06/30(月) 01:23:53 .net

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

73 ：仕様書無しさん：2008/06/30(月) 01:33:11 .net

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

74 ：仕様書無しさん：2008/06/30(月) 01:44:10 .net

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

75 ：仕様書無しさん：2008/06/30(月) 01:47:17 .net

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

76 ：仕様書無しさん：2008/06/30(月) 01:50:45 .net

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

77 ：仕様書無しさん：2008/06/30(月) 01:52:05 .net

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

78 ：仕様書無しさん：2008/06/30(月) 01:52:20 .net

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

79 ：仕様書無しさん：2008/06/30(月) 01:55:51 .net

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

80 ：仕様書無しさん：2008/06/30(月) 18:09:49 .net

>>74
結論から言おう。

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

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

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

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

81 ：仕様書無しさん：2008/06/30(月) 18:15:00 .net

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

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

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

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

82 ：仕様書無しさん：2008/06/30(月) 19:23:52 .net

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

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

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

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

83 ：仕様書無しさん：2008/06/30(月) 19:24:46 .net

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

84 ：仕様書無しさん：2008/06/30(月) 19:29:54 .net

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

85 ：仕様書無しさん：2008/06/30(月) 19:33:05 .net

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

86 ：仕様書無しさん：2008/06/30(月) 19:38:36 .net

だが断る

87 ：80：2008/06/30(月) 19:56:07 .net

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

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

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

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

88 ：80：2008/06/30(月) 20:03:05 .net

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

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

89 ：仕様書無しさん：2008/06/30(月) 20:03:53 .net

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

90 ：仕様書無しさん：2008/06/30(月) 20:05:08 .net

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

91 ：仕様書無しさん：2008/06/30(月) 20:08:08 .net

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

92 ：仕様書無しさん：2008/06/30(月) 20:11:47 .net

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

93 ：仕様書無しさん：2008/06/30(月) 20:14:47 .net

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

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

無いよ、絶対に。

94 ：仕様書無しさん：2008/06/30(月) 20:18:54 .net

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

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

95 ：80：2008/06/30(月) 20:26:47 .net

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

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

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

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

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

96 ：仕様書無しさん：2008/06/30(月) 20:31:13 .net

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

97 ：仕様書無しさん：2008/06/30(月) 20:31:28 .net

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

98 ：仕様書無しさん：2008/06/30(月) 20:33:28 .net

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

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

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

99 ：仕様書無しさん：2008/06/30(月) 20:34:41 .net

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

100 ：仕様書無しさん：2008/06/30(月) 20:39:08 .net

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

101 ：80：2008/06/30(月) 20:40:20 .net

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

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

102 ：仕様書無しさん：2008/06/30(月) 20:42:24 .net

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

103 ：80：2008/06/30(月) 20:50:11 .net

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

104 ：仕様書無しさん：2008/06/30(月) 20:53:54 .net

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

105 ：仕様書無しさん：2008/06/30(月) 20:55:25 .net

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

106 ：99：2008/06/30(月) 20:59:06 .net

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

107 ：80：2008/06/30(月) 22:01:59 .net

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

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

108 ：80：2008/06/30(月) 22:04:42 .net

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

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

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

109 ：仕様書無しさん：2008/06/30(月) 22:18:22 .net

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

110 ：仕様書無しさん：2008/06/30(月) 22:37:47 .net

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

111 ：仕様書無しさん：2008/06/30(月) 23:13:53 .net

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

112 ：仕様書無しさん：2008/06/30(月) 23:26:02 .net

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

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

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

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

113 ：仕様書無しさん：2008/07/01(火) 00:24:29 .net

あげてみるテスト

114 ：仕様書無しさん：2008/07/01(火) 00:35:37 .net

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

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

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

115 ：仕様書無しさん：2008/07/01(火) 01:27:50 .net

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

116 ：仕様書無しさん：2008/07/01(火) 01:54:44 .net

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

117 ：80：2008/07/01(火) 06:28:14 .net

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

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

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

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

118 ：80：2008/07/01(火) 06:40:46 .net

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

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

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

119 ：仕様書無しさん：2008/07/01(火) 08:51:27 .net

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

120 ：仕様書無しさん：2008/07/01(火) 19:54:57 .net

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

121 ：80：2008/07/01(火) 23:47:14 .net

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

122 ：仕様書無しさん：2008/07/01(火) 23:59:12 .net

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

123 ：仕様書無しさん：2008/07/02(水) 00:07:17 .net

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

124 ：仕様書無しさん：2008/07/02(水) 00:30:44 .net

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

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

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

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

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

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

125 ：仕様書無しさん：2008/07/02(水) 00:35:08 .net

長い

126 ：仕様書無しさん：2008/07/02(水) 00:38:17 .net

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

127 ：125：2008/07/02(水) 00:39:30 .net

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

128 ：>123：2008/07/02(水) 01:24:09 .net

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

129 ：仕様書無しさん：2008/07/02(水) 03:03:17 .net

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

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

130 ：仕様書無しさん：2008/07/02(水) 03:08:56 .net

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

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

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

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

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

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

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

131 ：仕様書無しさん：2008/07/02(水) 08:12:27 .net

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

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

・・・

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

132 ：仕様書無しさん：2008/07/02(水) 08:50:19 .net

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

133 ：仕様書無しさん：2008/07/02(水) 13:10:02 .net

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

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

134 ：80：2008/07/02(水) 21:26:47 .net

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

135 ：仕様書無しさん：2008/07/02(水) 21:35:17 .net

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

136 ：仕様書無しさん：2008/07/02(水) 21:36:21 .net

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

137 ：80：2008/07/02(水) 21:42:14 .net

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

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

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

138 ：仕様書無しさん：2008/07/02(水) 21:44:10 .net

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

139 ：80：2008/07/02(水) 21:53:46 .net

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

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

140 ：80：2008/07/02(水) 22:16:44 .net

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

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

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

141 ：仕様書無しさん：2008/07/02(水) 22:29:57 .net

>>139
顧客に言えよw

142 ：124：2008/07/02(水) 23:27:10 .net

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

143 ：仕様書無しさん：2008/07/02(水) 23:34:18 .net

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

144 ：仕様書無しさん：2008/07/02(水) 23:54:15 .net

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

145 ：仕様書無しさん：2008/07/03(木) 00:06:52 .net

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

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

146 ：仕様書無しさん：2008/07/03(木) 00:24:57 .net

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

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

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

147 ：仕様書無しさん：2008/07/03(木) 00:53:15 .net

プログラマの心理とすれば、テストってめんどくさいんだよね。
特に結果が分かりきってる（と自分で思い込んでいる）メソッドのテストコード
をいちいち書くのがね。
で、俺がこの前ミスったのは、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 ：仕様書無しさん：2008/07/03(木) 00:55:48 .net

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

149 ：仕様書無しさん：2008/07/03(木) 00:58:01 .net

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

150 ：仕様書無しさん：2008/07/03(木) 01:02:24 .net

面目ない。。。。

151 ：仕様書無しさん：2008/07/03(木) 01:06:44 .net

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

152 ：仕様書無しさん：2008/07/03(木) 20:39:02 .net

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

153 ：80：2008/07/03(木) 23:58:00 .net

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

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


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

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

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

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

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

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

154 ：仕様書無しさん：2008/07/04(金) 00:03:14 .net

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

え？

155 ：仕様書無しさん：2008/07/04(金) 00:04:08 .net

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

156 ：仕様書無しさん：2008/07/04(金) 00:08:45 .net

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

157 ：80：2008/07/04(金) 00:13:45 .net

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

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

158 ：仕様書無しさん：2008/07/04(金) 00:14:57 .net

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

159 ：仕様書無しさん：2008/07/04(金) 00:19:57 .net

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

160 ：仕様書無しさん：2008/07/04(金) 00:29:17 .net

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

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

161 ：80：2008/07/04(金) 00:37:43 .net

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

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

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

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

162 ：80：2008/07/04(金) 00:43:03 .net

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

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

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

163 ：仕様書無しさん：2008/07/04(金) 00:44:22 .net

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

164 ：仕様書無しさん：2008/07/04(金) 00:45:08 .net

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



もってっけー

165 ：仕様書無しさん：2008/07/04(金) 00:59:16 .net

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

これだけやりゃ十分

166 ：仕様書無しさん：2008/07/04(金) 02:24:20 .net

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

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

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

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

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

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

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

167 ：仕様書無しさん：2008/07/04(金) 02:40:19 .net

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

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

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

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

168 ：仕様書無しさん：2008/07/04(金) 02:47:02 .net

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

169 ：仕様書無しさん：2008/07/04(金) 02:49:50 .net

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

170 ：仕様書無しさん：2008/07/04(金) 02:53:07 .net

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

171 ：仕様書無しさん：2008/07/04(金) 02:54:15 .net

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

172 ：仕様書無しさん：2008/07/04(金) 03:00:04 .net

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

173 ：仕様書無しさん：2008/07/04(金) 05:16:42 .net

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

174 ：仕様書無しさん：2008/07/04(金) 05:26:42 .net

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

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

175 ：仕様書無しさん：2008/07/04(金) 05:46:53 .net

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

176 ：仕様書無しさん：2008/07/04(金) 07:23:13 .net

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

177 ：仕様書無しさん：2008/07/04(金) 20:44:02 .net

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

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

178 ：仕様書無しさん：2008/07/04(金) 21:21:15 .net

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

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

179 ：仕様書無しさん：2008/07/04(金) 23:17:16 .net

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

180 ：仕様書無しさん：2008/07/05(土) 01:38:16 .net

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

181 ：仕様書無しさん：2008/07/05(土) 08:05:40 .net

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

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

182 ：仕様書無しさん：2008/07/05(土) 11:57:14 .net

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

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

183 ：仕様書無しさん：2008/07/05(土) 16:05:21 .net

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

184 ：仕様書無しさん：2008/07/05(土) 16:14:06 .net

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

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

185 ：仕様書無しさん：2008/07/05(土) 16:15:12 .net

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

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

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

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

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

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




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

186 ：仕様書無しさん：2008/07/05(土) 16:17:58 .net

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

187 ：仕様書無しさん：2008/07/05(土) 17:48:19 .net

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

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

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

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

188 ：仕様書無しさん：2008/07/05(土) 17:54:19 .net

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

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

189 ：仕様書無しさん：2008/07/05(土) 17:55:26 .net

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

190 ：仕様書無しさん：2008/07/05(土) 18:17:43 .net

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

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

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

191 ：仕様書無しさん：2008/07/05(土) 18:32:10 .net

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

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

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

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

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

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

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

192 ：仕様書無しさん：2008/07/05(土) 18:34:03 .net

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

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

193 ：仕様書無しさん：2008/07/05(土) 18:50:33 .net

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

194 ：仕様書無しさん：2008/07/05(土) 18:51:43 .net

>>193
どこを盾読み?w

195 ：仕様書無しさん：2008/07/05(土) 19:02:30 .net

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

196 ：仕様書無しさん：2008/07/05(土) 21:48:53 .net

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

197 ：仕様書無しさん：2008/07/05(土) 23:57:14 .net

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

198 ：仕様書無しさん：2008/07/06(日) 00:07:11 .net

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

199 ：80：2008/07/06(日) 00:09:16 .net

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

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

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

200 ：80：2008/07/06(日) 00:15:21 .net

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

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

201 ：80：2008/07/06(日) 00:22:15 .net

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

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

202 ：仕様書無しさん：2008/07/06(日) 00:33:54 .net

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

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

203 ：仕様書無しさん：2008/07/06(日) 00:41:55 .net

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

204 ：166：2008/07/06(日) 01:49:39 .net

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

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

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

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

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

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

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

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

205 ：166：2008/07/06(日) 02:10:28 .net

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

だから何？

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

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

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

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

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

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

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

206 ：80：2008/07/06(日) 08:03:32 .net

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

207 ：80：2008/07/06(日) 08:25:39 .net

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

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

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

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

208 ：80：2008/07/06(日) 08:33:20 .net

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

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


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

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

209 ：仕様書無しさん：2008/07/06(日) 09:07:05 .net

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

まあ

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

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

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

210 ：80：2008/07/06(日) 09:27:55 .net

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

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

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

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

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

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

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

211 ：80：2008/07/06(日) 09:31:50 .net

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

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

212 ：80：2008/07/06(日) 10:17:18 .net

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

213 ：80：2008/07/06(日) 10:18:37 .net

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

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

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

214 ：仕様書無しさん：2008/07/06(日) 12:44:42 .net

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

215 ：仕様書無しさん：2008/07/06(日) 13:20:18 .net

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

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

216 ：仕様書無しさん：2008/07/06(日) 13:52:45 .net

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

217 ：仕様書無しさん：2008/07/06(日) 16:18:27 .net

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

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

218 ：仕様書無しさん：2008/07/06(日) 16:23:08 .net

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

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

219 ：仕様書無しさん：2008/07/06(日) 16:23:56 .net

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

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

220 ：仕様書無しさん：2008/07/06(日) 16:24:48 .net

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

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

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

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

221 ：仕様書無しさん：2008/07/06(日) 16:26:58 .net

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

222 ：仕様書無しさん：2008/07/06(日) 16:28:48 .net

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

223 ：仕様書無しさん：2008/07/06(日) 16:42:03 .net

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

224 ：仕様書無しさん：2008/07/06(日) 16:59:40 .net

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

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

225 ：仕様書無しさん：2008/07/06(日) 17:04:33 .net

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

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

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

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

226 ：仕様書無しさん：2008/07/06(日) 17:06:18 .net

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

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

227 ：80：2008/07/06(日) 17:20:08 .net

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

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

228 ：80：2008/07/06(日) 17:26:31 .net

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

229 ：80：2008/07/06(日) 18:10:30 .net

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

230 ：仕様書無しさん：2008/07/06(日) 18:47:53 .net

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

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

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

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

それだけの話。

231 ：80：2008/07/06(日) 19:01:54 .net

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

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

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

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

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

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

232 ：仕様書無しさん：2008/07/06(日) 20:23:46 .net

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

233 ：仕様書無しさん：2008/07/07(月) 03:22:05 .net

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

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

234 ：仕様書無しさん：2008/07/07(月) 05:35:05 .net

>>231
机上の空論。

実戦経験をつめ。

235 ：仕様書無しさん：2008/07/07(月) 08:11:18 .net

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

236 ：仕様書無しさん：2008/07/07(月) 08:26:33 .net

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

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

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

237 ：仕様書無しさん：2008/07/07(月) 11:40:51 .net

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

238 ：仕様書無しさん：2008/07/07(月) 11:45:04 .net

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

239 ：仕様書無しさん：2008/07/07(月) 11:47:57 .net

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

240 ：仕様書無しさん：2008/07/07(月) 12:01:08 .net

>>239
言うと思ったｗ

241 ：仕様書無しさん：2008/07/07(月) 12:30:29 .net

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

242 ：仕様書無しさん：2008/07/07(月) 12:40:45 .net

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

243 ：仕様書無しさん：2008/07/07(月) 12:43:34 .net

レス先間違えてね？

244 ：仕様書無しさん：2008/07/07(月) 12:55:08 .net

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

245 ：仕様書無しさん：2008/07/07(月) 16:29:11 .net

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

246 ：仕様書無しさん：2008/07/07(月) 16:34:17 .net

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

247 ：仕様書無しさん：2008/07/07(月) 19:53:15 .net

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

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

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

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

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

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

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

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

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

248 ：仕様書無しさん：2008/07/07(月) 20:02:58 .net

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

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

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

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

249 ：仕様書無しさん：2008/07/07(月) 20:18:40 .net

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

250 ：仕様書無しさん：2008/07/07(月) 20:28:37 .net

（少し追加）

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

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

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

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

251 ：仕様書無しさん：2008/07/07(月) 20:31:23 .net

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

252 ：仕様書無しさん：2008/07/07(月) 20:43:11 .net

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

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

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

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

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

253 ：仕様書無しさん：2008/07/07(月) 21:08:02 .net

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

254 ：仕様書無しさん：2008/07/07(月) 21:17:01 .net

>>253
thx

255 ：仕様書無しさん：2008/07/07(月) 21:58:28 .net

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

256 ：仕様書無しさん：2008/07/07(月) 23:25:27 .net

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

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

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

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

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

257 ：仕様書無しさん：2008/07/08(火) 00:11:34 .net

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

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

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

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

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

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

258 ：80：2008/07/08(火) 01:01:27 .net

>>256

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

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

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

259 ：80：2008/07/08(火) 01:09:01 .net

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

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

260 ：仕様書無しさん：2008/07/08(火) 01:58:40 .net

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

261 ：仕様書無しさん：2008/07/08(火) 02:10:45 .net

>>259
>>210の内容と、思いっきり矛盾してるのに気がつかないのか？

262 ：仕様書無しさん：2008/07/08(火) 02:22:06 .net

80をやり込めても、誰も何も得しないよ。逆もまた真なり。

263 ：仕様書無しさん：2008/07/08(火) 03:28:11 .net

つまり、80にやり込められても、誰も何も得しないw

264 ：仕様書無しさん：2008/07/08(火) 08:41:06 .net

>>257
システム／ネットワークのパフォーマンス的なボトルネックは生まれにくくなってきてるけど
利用するライブラリ／パッケージ自体は未だに流行に合わせどんどん入れ替わり立ち替わりな
うちのPrjでは、半年以内に「原因不明系」のトラブルが多発してるよ。

ImageGear許すマジ

265 ：仕様書無しさん：2008/07/08(火) 08:43:02 .net

>>260、これな
　　　　　　　　　　　　　　　　　　　　　　　　　　 ＿,====ミミﾐヽ、
　　　　　　　　　　　　　　　　　　　　　　　　　,,==≡ミヽミヾミミミ、ヾ、
　　　　　　　　　　　　　　　　　　　　　　 _=≡≡三ミミﾐ ミﾐヾ、ソ)),,》　　.
　　　　　　　　　　　　　　　　　　　　　彡彡二二三≡ミ-_　ﾐﾐ|ノﾉj )||ヽ,　)、
　　　　　　　　　　　　　　　　 __,,,,,,,,,／彡二二二　　　 ,-　__ﾐ|/ﾉ ﾉﾉﾉﾉ)　||
　　　　　　　　　　　　　　　　-=二ミミミミ----==--'彡 ∠ミﾐ_ソノノノﾉ　ﾉ
　　　　　　　　　　　　　　　　　　/／＞=''"二二=-'"_／　　 ノ''''')λ彡／
　　　　　　　 ,,/￣''l　　　　　　 彡/-'''""￣-=彡彡／　,,-''",,,,,,,ノ .彡''"
　　　　　　　(,　 ,--(　　　　　　彡 ,,-- ===彡彡彡"_,-＿　　　ヽ　Υ
　　　　　　　ヾ-( r'''''＼　　　　／／=二二''''''彡ｿ￣ ∠__＼ .＼ｿ　 .|
　　　　　　　　　＼;;;;　 ＼　　　Ζ彡≡彡-'''',r-､>　　　l_"t。ﾐ＼ﾉ,,r-v　　　／￣￣￣￣￣￣
　　　　　　　　　　 ＼;;;;　 ＼　　彡""彡彡-//ヽ"　''''''""￣'''""(ｴｱ/　　／
　　　　　　　　　　　　＼;;　　＼'''''')彡ヽ//　|　(tv　　 ／|　　,　r_>'|　　＜一体みんな誰と戦っているんだ
　　　　　　　　　　　　　＼;;;　　＼'"　　＼　,,"''-,,ﾉ,r-", /　　r'''-,　.j　　　＼
　　　　　　　　　　　　　　 ＼;;;　　＼　／,,>--'''二"''' r-|　　 二'" /　　__　　＼＿＿＿＿＿＿
　　　　　　　　　　　　　　　　＼;;r'""彡_l:::::::::::::::::::::: /./_　　　" ／￣￣"===-,
　　　　　　　　　　　　　　　　　 )''／／rl_--::::::::::::::::/:/ヽ"'=--":

266 ：仕様書無しさん：2008/07/09(水) 00:48:04 .net

作業指示出してる人が「テスト嫌い。あんなもん無駄だしやってると苛々してくんだよね。」とか言っててこっちが苛々ですよ。

267 ：仕様書無しさん：2008/07/09(水) 01:13:20 .net

結局結論としては80の言ってるシステムテストと他の人の考えるシステムテストの定義が違ったってことでいい？
俺的には80が言ってるシステムテストは単体テストレベル。
一般的にテストはUT、IT、STという順番でやっていくはず。
だからSTの観点はITより上のレベル。分割したモジュールをテストしてシステムテストとか、一般的じゃない。

268 ：仕様書無しさん：2008/07/09(水) 01:16:38 .net

>>267
同じ同じ。
UTってMTと一緒なのかな？

269 ：仕様書無しさん：2008/07/09(水) 01:40:34 .net

80は業務系じゃないらしいから考え方が違うんだと思う。

UT：作ったものが仕様書どおりだよねってことをIF含めて確認するテスト。
⇒コードのチェック
IT：それぞれが作ったものをつなげても動くよね？ってことを確認するテスト。
⇒仕様書の整合性のチェック
ST：とりあえず動くもの作ったけど、そもそもこんなんでよかったんだっけ？ってのを確認するテスト。
⇒要件を満たしてることのチェック。
受け入れテスト：STまでやってるけど、レビューとか適当な客もいるので後で文句を言わせないために
実際に動かしてもらって、確かに要件満たしてますよね？って確認するテスト。
⇒保険。

270 ：仕様書無しさん：2008/07/09(水) 06:36:32 .net

MT?

271 ：仕様書無しさん：2008/07/09(水) 07:00:15 .net

いやいやいや、

>「問題の難しさ」を「問題の量」に転化したのだから

なんの証明も根拠もなしに、転化できましたなどと無邪気に主張されてもとても納得できない。
80の中で完結しているロジックが存在するとすれば、それはまだこの場では語られていない。
語ったつもりになっているとすれば、それは表現能力に問題があると言わざるを得ない。

272 ：仕様書無しさん：2008/07/09(水) 19:17:24 .net

80来ないとつまんないね

273 ：仕様書無しさん：2008/07/09(水) 22:41:42 .net

そもそも、UTとかMTとか、
必ずしも企業間で、示す実作業の統一が取れているとは言い切れない、
曖昧模糊とした略語で話を進めようとするのが問題ではないか？

274 ：仕様書無しさん：2008/07/09(水) 23:10:36 .net

実作業としては統一されてないだろうけど、UTの概念は統一されてるだろ。知らない奴は論外。

MTは知らんｗ

275 ：仕様書無しさん：2008/07/10(木) 02:47:55 .net

あとはPGはあると思う（ｗ。
UTとかPTとかは辺りも曖昧だし、当然それ以上はも場所によって違うだろうし。

276 ：仕様書無しさん：2008/07/10(木) 03:12:38 .net

世の中にはテスト技術者資格認定とかいう資格があってだな、そこで公開されている
シラバスとか標準用語集位の事を知っておいてもらえるとありがたいなぁと思ったり
するわけですよ。
80みたいに自分理論で色々言われてもねぇ。

ttp://www.jstqb.jp/syllabus.html

277 ：仕様書無しさん：2008/07/10(木) 23:31:11 .net

あら…
一つのモジュールがちゃんと動くかどうか…みたいなテストを
モジュールテストとかMTとか呼んでるんだけど一般的じゃないのかｗ

テストの種類は基本情報の勉強で覚えたくらいだな。
ユニットテストとか現場でのレベル感で縛られるな。

278 ：80：2008/07/11(金) 00:05:27 .net

>>267
> 結局結論としては80の言ってるシステムテストと他の人の考えるシステムテストの定義が違ったってことでいい？
よいです。

> 一般的にテストはUT、IT、STという順番でやっていくはず。
> だからSTの観点はITより上のレベル。分割したモジュールを
> テストしてシステムテストとか、一般的じゃない。
UT, IT, STという３段階が一般的なのは理解している。
ただし、うちでは、これでは、うまくテストを定義できなかった。

質問１
巨大なシステムでも小さなシステムでも等しく
この3段階でテストを進めるので良いと考えているのか？
俺が聞きたいのは、一般論ではない。過去の経験から判断してほしい。

質問２
小規模の場合、UT->IT->STとするなら大規模だとどうなる？
1. UT->UT->UT->UT->UT->UT->UT->UT->UT->IT->ST
2. UT->IT->IT->IT->IT->IT->IT->IT->IT->IT->ST
3. UT->IT->ST->ST->ST->ST->ST->ST->ST->ST->ST
4. UT->IT->ST->IT->ST->IT->ST->IT->ST->IT->ST
5. UT->IT->ST->UT->IT->ST->UT->IT->ST->UT->IT
6. そのた。

279 ：仕様書無しさん：2008/07/11(金) 00:14:23 .net

>>278
１．同じでないと困る。

２．テスト結果による。


全体的にはどんなプロジェクトも同じ工程じゃないと困るが、
そのテスト工程で発覚する不具合の深刻度と混入工程によって、
それぞれ小さな部分テストの反復があるんだよ。

修正する度に、部分的にUT→IT→が間に幾つも入るのさ。

280 ：仕様書無しさん：2008/07/11(金) 00:15:46 .net

場合によっちゃSTまでを反復で何度も行う事だってあるしな。

281 ：80：2008/07/11(金) 00:23:30 .net

つまり、仕様や性能を満たせているかを確認するテスト（ST）が
ずいぶん後回しになるやり方を皆は支持しているわけだ。

そもそも、仕様書は、システム全体に対してのみ書かれるのか？

282 ：仕様書無しさん：2008/07/11(金) 00:29:52 .net

>>281
皆っておい、俺一人しか答えてねえよwww

279も280も俺、俺俺www

283 ：仕様書無しさん：2008/07/11(金) 00:31:51 .net

>>282
いや、オレオレwww

284 ：仕様書無しさん：2008/07/11(金) 00:34:56 .net

>>278
工程として考えたいのか、テスト手順と考えたいのかがよくわからない。
工程なら大規模小規模かかわらずUT＞IT＞STとなるべきだが、
実際に行われてるテストはいくらでも入り組むだろう。
バグ対応入った時とか。

もし工程として(もしくは工程に近いレベルで)
質問２みたいな手順になっているなら
>>78の言うとおり、機能単位で分けるべき。


すごく今更なんだが、>>80の
> 分割すると管理コストが増えるし組織が複雑になる。
> そして、意思疎通が難しくなる。
> 問題が形を変えるだけで何も解決したことにはならない。
なんというか…オブジェクト指向じゃない感じみたいな…
モジュール一つで表示から処理から遷移から何から何までって感じがする…

285 ：仕様書無しさん：2008/07/11(金) 00:40:03 .net

>>80の言っている>>258には同意できる。

■機能要件
開発スタイルにもよるんだろうけどうちの顧客はころころ機能要件を
修正してくるから、機能にマッピングされるモジュール内の関数構成や
実装はそのたびに修正される。
=> ホワイトボックステストはコスト的に合わないので、モジュールの
入出力に相当するAPIだけをブラックボックステスト。

■再利用可能なコンポーネント
タスク・タスク間通信・メモリ管理周りといった部分がそれに含まれる？
不具合が全体に波及するのは勿論だし、そういったモジュールは
関数構成や実装が大きく変わることは無い。
=> ユニットテストで関数ごとにホワイトボックステスト。

コスト的に許されるんなら、全てにホワイトボックステストを用意するに
越した事は無いんだけど。

286 ：仕様書無しさん：2008/07/11(金) 00:48:20 .net

>>258はよくわからなかったけど>>285には納得できる。

> => ホワイトボックステストはコスト的に合わないので、モジュールの
> 入出力に相当するAPIだけをブラックボックステスト。
コスト的にかどうか知らないんだけど、これが一番理想とするテストだと思ってる。
APIの所だけホワイトな、穴あきブラックボックステストみたいな。

287 ：仕様書無しさん：2008/07/11(金) 01:03:04 .net

>>278
スパイラル型でもない限り結合超えてUTに戻る、ってのはないんじゃないの？
上位テストフェーズで不具合が見つかった瞬間はともかく

おれはスパイラルスキーなんだけどね。

ちなみに今関わってるPrjは大規模であっても
UT->IT->ST
これだけ。そして受け入れフェーズで多々トラブル。
おれ、どうしたらいい？

あ、
１．よくない。お客様との要件詰めが完全合致していて、仕様変更などが絶対入らない
　　前提でもない限りUT->IT->STのみではうまくいかない。
　　なぜなら、UT後に仕様変更なぞ入ろうものなら品質面での保証がまったく出来なくなってしまう、
　　客は触って初めて「違うぞこれ？」とか言い出す生き物、などなど。
２．同じことの繰り返し、と考えてしまうと、６．その他、が正解だと思う。
　　自動テストをUT,IT,STのくくりにいれず同時並行すべきかなー、とか。

288 ：仕様書無しさん：2008/07/11(金) 01:04:19 .net

みんな考え方は現場経験や本人の考え方により違うんだろうけど
こうやってテストフェーズについて色々活発に話せることはよいことだナァ。

289 ：仕様書無しさん：2008/07/11(金) 01:05:31 .net

>>288
なー。おれはよくわからんから読んでるだけだけどなー。

290 ：仕様書無しさん：2008/07/11(金) 01:14:59 .net

>>289
実際現場でテストやその後フェーズで苦労しだすと結構分かってくるんじゃない？
ってか品質面で問題でない現場ならそれが一番の幸せだよ｡゜（ﾟ´Д｀ﾟ)゜｡

291 ：仕様書無しさん：2008/07/11(金) 01:15:27 .net

>>281
仕様書はもちろん個々の機能についても書かれる。
そしてその仕様どおりの入出力を満たしていることの確認もする。
ただし、業務系ではそれをシステムテストとは呼ばない。
個々の機能の入出力を重点的にテストして、それより下位のテストは適当にするっていうのは
いいと思うよ。
本当にただ言葉の定義が違うために言ってることが分かりづらいだけ。

292 ：仕様書無しさん：2008/07/11(金) 01:20:39 .net

今回うけた仕事、システム全体の中の1カ所の開発(というかリファクタ)なんだが
自分たちが受けた部分はともかく、他のところはいきなりシステムテストらしい。
ちゃんとモジュールテストされてない・・・

そのせいで、システムテストで
他の会社が作った部分のデバッグをやらされてる。

293 ：仕様書無しさん：2008/07/11(金) 01:22:10 .net

>>292
そういう段取り／スケジュール考えた奴は軽蔑していいよ

294 ：仕様書無しさん：2008/07/11(金) 02:33:59 .net

>>290
テスト後フェーズは幾度となく経験してるし、
修正後のテスト堂々巡りも経験してるけど、
大規模開発というものを経験したことがないので、
UT→IT→ST が同時進行ならまだしも、何度も巡る
というのが理解できず、議論についていけないｗ

というかあれだな、読んでいて思ったけど、
言葉の定義や論点がずれているだけで、
本質はみんな同じ認識の様な気がする。

295 ：仕様書無しさん：2008/07/11(金) 06:03:21 .net

>言葉の定義や論点がずれているだけで、
>本質はみんな同じ認識の様な気がする。

いや、違うね。俺だけが違ってるという可能性もあるが。

>>281
テストフェーズの定義について、素直に間違っていたと認めた80は評価する。
同じように「仕様書」に関しても、他とずれていると認識してほしいのだが。
そうでないと、>>281の後半部分には答えられない。

>つまり、仕様や性能を満たせているかを確認するテスト（ST）が
>ずいぶん後回しになるやり方を皆は支持しているわけだ。

何度も言うように、システムテストは機能テストと「性能を測る」テストだけではない。
後回しになる（後でやらないと意味がない）テスト（ケース）もあれば、先にやるものもある。

機能テストのことをずいぶん気にしているようだが、「皆」がどう取り組んでいるかは、
「受け入れテスト 自動化」でググってみるとわかるかもね。

296 ：仕様書無しさん：2008/07/11(金) 06:12:26 .net

俺が80と違っている（と思っている）点は、
・ユニットテストは軽視してはならない。むしろ重視すべき。
・ユニットテストはプログラマが行うべき
・ユニットテストを重視することは、顧客のメリットになる
・（おまけ）外部設計と内部設計という考え方はある

80に同意する点もいくつもあるが、それは列挙しない。

297 ：仕様書無しさん：2008/07/11(金) 19:44:58 .net

適当でいいんだよ適当で。

298 ：仕様書無しさん：2008/07/12(土) 02:15:00 .net

適当、よりも、適度、がいいと思うんだ

299 ：仕様書無しさん：2008/07/12(土) 15:17:35 .net

適当≠手抜き

300 ：仕様書無しさん：2008/07/12(土) 19:29:48 .net

サンビャク！

301 ：80：2008/07/13(日) 08:07:03 .net

>>296
>・ユニットテストは軽視してはならない。むしろ重視すべき。
->軽視はしていない。重視もしていない。
　おれは、テスターじゃなくて、プログラマー上がりなので、
ユニットテストの大切さを知っている。ただ、組織としてユニットテストを
　成功させる場合は、以下の前提条件を満たせないとだめだ。
1. バグが減ったことを評価して、ボーナス査定をUPさせる。
　2. 機能実装よりバグが少ないことを重視する。
重要なのは、2 だ。ユニットテストを重視した結果開発のスピードが
　落ちたのだ。つまり、機能的要件（フレームワーク、下位コンポーネント
　を除く）を実装するチームに関しては、ユニットテストがボトルネックになる。
　よーは、すべてがトレードオフなのだ。ユニットテストを重視しすぎると
　逆に効率が落ちる開発フェーズがあることを俺は、経験で学んだ。
　
>・ユニットテストはプログラマが行うべき
-> ユニットテスト＝ホワイトボックステストなら同意。

>・ユニットテストを重視することは、顧客のメリットになる
　-> 大規模開発では、顧客には理解されない。
　 業務系ではないうちでは、専門的すぎて説明するのが難しい。

>・（おまけ）外部設計と内部設計という考え方はある
-> うちの会社にも昔はあったよ。外部設計、内部設計という言葉が
間違っているのに気がついた。
　　 確かに、システムというものを対象にした時にそれの外部について
記述したドキュメントと内部について記述したドキュメントはある。
ただ、外部か内部かという言葉は、対象物を前提としている。
システム、サブシステム、コンポーネント、ライブラリ・・・・などだ。
そして、これらは、整然と関連付けられる。内部設計とか外部設計という
言葉をこれに当てはめると間違いである事が理解できる。
外部は仕様書で、内部は設計書なんだ。これでもわからないなら。
　　 仕様書と設計書の違いを説明してくれないか

302 ：80：2008/07/13(日) 08:17:57 .net

補足だが、プログラマーとテスターの作業量を新規開発の初めから
終わりまで時間を追ってグラフにしてみると俺の言っていることが
分かるかもしれない。
理想を言えば、一番初めのインテグレートの時にテスターが
チームに参加すれば、コスト的にOKなのだが。
大抵は
1. 一番初めのインテグレートは遅れる。つまりテスターが遊ぶ。
2. テスターが開発初期から参加している場合、テスターは
プログラマーよりも暇である。
3. 機能要件は、よく変わる。せっかくユニットテストをばっちりしても
作り直しが多数発生する。さっさと、要求者に「うごく」ソフトを
見せるのは重要だ。

テスターを遊ばせないで、機能要件の間違いを早期に発見できる方法
を俺は支持しているんだ。

303 ：80：2008/07/13(日) 08:29:15 .net

>>285
だいたい、同じ考えだ。
機能要件と再利用可能なコンポーネントでは、テストのやり方
を変えないとだめだ。

再利用可能なコンポーネントは、下位の層で人目につかない。
テスターに通信プロトコルや各種規格をすべて理解してもらうことは無理
なので、プログラマーしか「テストができない」と俺は思う。


違うところは、再利用可能なコンポーネントのテストは、
ホワイトボックステストと加えて回帰テスト（ブラックボックス）を
重視するところだ。

再利用可能コンポーネントは、最適化を繰り返すので、ソースコードが激変する。
つまり、ホワイトボックステストは毎回変わってしまう。
ホワイトボックステスト事態の品質を維持することは非常に難しい、
なので、回帰テストとの合わせ技が重要になる。

304 ：80：2008/07/13(日) 09:11:20 .net

開発工程の中のボトルネックはどこにあるのか？によってやり方は異なる。
プログラマーのスキルが高い場合、テスターのスキルが高い場合など
状況は様々だ。

うちのボトルネックは、「実装」フェーズだった。
スケジュールの遅れは、プログラマーの責任だという認識が多数を占めていた。
なので、ユニットテストが流行したが、結局、失敗に終わった。

ボトルネックにさらに仕事を増やした（人は増えない）結果、開発そのもの
が遅れ、テスターが遊び始めた。設計者は次の設計に入っている。
しかし、ボトルネックが解消されなければ、実装されない設計が溜まる
ばかりだ。テスターは、空いた時間で別のプロジェクトのテストをしている。
リソースが有効活用されていないのは明らかだ。
ボトルネックを解消するのに設計者にテスターにできることはないのか？
そう考えるのが普通だろう。
設計者には、設計を洗練させた。結果、不要なソースコードをプログラマー
が書かなくても良いようになった。
ユニットテストを強要することはやめた。その代りテスターの負担が増えた
が、もともとテスターは遊んでいたのでプロジェクト全体のスループットは
向上した。テスターのストレスは増えたが・・・。

ユニットテストを完璧にやるという事は、ウォーターフォールの考え方
に近い。うちは、繰り返し型の開発をやっているので、たとえバグが残っても
開発の最後の方でプログラマーの手が空いてきたころに網羅性の高いテストを
行うので実質品質が下がるようなことはない。
ユニットテストは有効だが、使い方を間違ってはいけないと思う。
重要なのは、部分最適化（ユニットテストだけを協調する）のではなく
全体最適化（全ての開発工程を見直す）の方だと思う。

305 ：80：2008/07/13(日) 09:30:44 .net

>>291
業務系は、書籍などで知っているだけで現場は知らない。

うちは、メカトロニクス。半分は制御系。ただし、大規模な制御系だ。
Web技術、データーベース、各種通信、など色々開発要素も多い、
言語もC++, C#, Java, その他が入り乱れている。

うちのシステムは、多層になっているシステムの集合体だ。
担当者は、自分の担当範囲だけどをシステムと呼んでいる。
つまり、人によって、システムの範囲（スコープ）が違うんだ。
そして、多段階にインテグレートしてテストを行う。

なので、スコープとレベルの違うシステムテストはチーム内の複数存在
することになる。

見方を変えれば、下位のシステムは、ユニットとも言えなくもないが、
よほどの下位でもない限り「一般論で言うユニット」とは違う。

うちでは以下のように定義している。
・（粒度はともかく）機能的要件を実現する単位をシステム
　（サブシステム）と呼んでいる
・下位の原始的なメカニズムを提供するものを、ユニットと呼んでいる。
・機能外要求や、システムのアーキテクチャーをつかさどるものを
フレームワークと呼んでいる。

306 ：仕様書無しさん：2008/07/13(日) 11:05:04 .net

>>301
>ユニットテストを重視した結果開発のスピードが落ちたのだ

結局ユニットテスト非重視と重視で品質面はどちらがあがったの？
非重視で品質落ち（最悪客先リリース後に不具合多々発現）だとしたら
開発スピードが落ちた、ではなく必要フェーズをはぶいてスピードあげてた、
ってだけでは？？

307 ：仕様書無しさん：2008/07/13(日) 11:10:26 .net

みんなの会社で「専任テスター」っている？うちは

a.管理：チームMGR、PL
b.営業／客対応：客対応向けSE、営業
c.開発：開発向けSE、PG

みたいな位置づけになってて、テストは
「それ開発の一環だろ」って見方を上がしているから結局c.が全員で当たってる。

いい形とは思ってないけど、この場合、
フェーズによって「テスター」が暇になる、ってのはないけどなー

308 ：仕様書無しさん：2008/07/13(日) 12:54:44 .net

80の方法だと、ユニットが細かい区分になるので、つまり単純化される。
つまり単純で小さなテストが沢山できる。

質の問題を量に転化したと言っている。
で、コスト削減の為にテストを自動化したと。

まあ、制御系で1000万コードってどんだけーって話だけど。
工場の制御丸ごとやったとしか思えんなぁ。

309 ：仕様書無しさん：2008/07/13(日) 18:02:22 .net

グローバル変数が100万個位あるんだろ

310 ：80：2008/07/13(日) 20:32:06 .net

>>306
品質は向上した。第三者テストの重要性を再認識することとなった。
多分、問題点や間違いを早期のうちに把握できたことと、プロジェクト管理
がやりやすくなったことなども良かったと思う。

プログラマーに、プレッシャーを与えることになったのと、
テスターの地位が向上したのも良かったのかもしれない。

311 ：80：2008/07/13(日) 20:40:06 .net

>>307
うちは、専任のテスターがいる。
そして、開発の初めから開発に参加している。
要件定義が終わったら、これをもとにテストを作成しはじめる。
（テスターが要件を事細かに見るので要件は洗練されるというおまけもつく。）

312 ：仕様書無しさん：2008/07/13(日) 21:11:33 .net

つーか、日本の現場にありがちな曖昧な部分を消したという事が重要だと思う。
グラマーのプライドなんて、邪魔ものだからなー（本人にとってもー）。

313 ：80：2008/07/13(日) 23:04:06 .net

>>312
そういう見方もできるな。要件の曖昧さとテスターのカバレッジを
ユニットテストで補えるとプログラマーが考えているなら、
勘違いも甚だしいな。

314 ：仕様書無しさん：2008/07/13(日) 23:05:54 .net

プログラマの常識は一般人の非常識って事ですね。わかります。

315 ：仕様書無しさん：2008/07/14(月) 01:12:09 .net

>そういう見方もできるな。要件の曖昧さとテスターのカバレッジを
>ユニットテストで補えるとプログラマーが考えているなら、
>勘違いも甚だしいな。

いや、それに甘えてきたSEが問題でしょ。
厳密に言えば、曖昧さは発生しない為に仕様があるわけで、
仕様抜けとか仕様に考慮を入れていないというミスを
グラマーがプログラミングやユニットテストで吸収するのは
よくある風景だ。
単純にそれはSEの怠慢でしかない。

ちなみにそれやらないと、ユニットテストが上がらないっていう
話になって仕様書を押し戻すと作成元の責任になったりする
ので出来ないってのも基本。

316 ：仕様書無しさん：2008/07/14(月) 06:01:41 .net

>>301
>　よーは、すべてがトレードオフなのだ。ユニットテストを重視しすぎると
>　逆に効率が落ちる開発フェーズがあることを俺は、経験で学んだ。
バグを取り除くのが早ければ早いほど、トータルコストが少なくなるというのには同意してもらえるのかな？
もっと言えば、トータルコストが少なくなるような効果的なユニットテストを模索しなければならない。

>　-> 大規模開発では、顧客には理解されない。
>　 業務系ではないうちでは、専門的すぎて説明するのが難しい。
トータルコストが少なくなり、品質も安定するという意味で、顧客のメリットになる。

>-> うちの会社にも昔はあったよ。外部設計、内部設計という言葉が
>間違っているのに気がついた。
>そして、これらは、整然と関連付けられる。内部設計とか外部設計という
>言葉をこれに当てはめると間違いである事が理解できる。
君が間違っていると主張しても、それでも世界は回っているんだよ。
目をふさぐのは簡単だけどね。

317 ：80：2008/07/14(月) 06:56:34 .net

>>316
>バグを取り除くのが早ければ早いほど、トータルコストが少なくなるというのには
>同意してもらえるのかな？
当然そうだが、早いというのは、開発のスケジュールの早い段階でという
意味でだ。うちはスパイラルだからできる芸当なんだが、早期の詳細な
テストが徒労に終わることを経験で知っている。
開発の初期で最低限の要件で開発して、さっさとインテグレート
してさっさとシステムテストをやることで早期にテストを行って
要件の問題を修正している。この場合、ユニットテストは簡単にしか
行われない。

318 ：80：2008/07/14(月) 07:10:39 .net

>>316
>君が間違っていると主張しても、それでも世界は回っているんだよ。
>目をふさぐのは簡単だけどね。
世界って広いぞ。うちは外資系だからアメリカ、インド、ロシア・・・・
いろんな奴と一緒に仕事しているけど、ソフト開発なんてのは、世界的に
統一されたりしてないぞ。各国各様でばらばらだ。つまり、外部設計と
内部設計という言葉が通用しないのを、実際に経験で知っている。

319 ：仕様書無しさん：2008/07/15(火) 01:47:04 .net

なんでシステムテストをやると
ユニットテストをサボれると思うのだろう？

320 ：仕様書無しさん：2008/07/15(火) 08:56:28 .net

>>317
> 意味でだ。うちはスパイラルだからできる芸当なんだが、早期の詳細な
> テストが徒労に終わることを経験で知っている。

誰も、過剰なユニットテストをやれなんて言ってねーよ。ユニットテストをプログラマにやらせると
必ず過剰なものになるからやらせないってことか。
まぁ、お前のチームのプログラマがレベル低すぎて効果的なユニットテストをできないのならそれも仕方ないかもな。

>>318
どんだけ田舎者と仕事してんだよ。
internal designとexternal designも通じない奴と仕事してんのかよ。

321 ：仕様書無しさん：2008/07/15(火) 08:58:53 .net

そろそろメトリックスベースで話さないと埒があかんな。
1000万行のシステムで、第三者検証チームが検出したバグは何件だったんだ？

322 ：仕様書無しさん：2008/07/15(火) 09:26:09 .net

>>318
とりあえず、原著で読んだsoftware development processの本の題名を列挙してくれ。

323 ：80：2008/07/15(火) 23:50:38 .net

>>320
シリコンバレーは、確かに田舎だな。。。。

ちなみに言うとうちでは設計書はあまりかかれない。仕様書を重視する。
うちの外人さんは、「設計書＝ソースコード」だと言い張る。
年収3000万を超えるプログラマーだからできる芸当なのかもしれない。
こいつらテストはしない。テストは、テスターの仕事だと言い張る。

324 ：仕様書無しさん：2008/07/16(水) 00:20:17 .net

ダメだ、はったりにしか見えない｡゜（ﾟ´Д｀ﾟ)゜｡おれもうROMるわ

325 ：仕様書無しさん：2008/07/16(水) 01:51:18 .net

「顧客のメリットになる」ことにこだわっている人が
いるけど、それが必ずしも自社にとってメリットになる
わけでは無いわけで。そういった意味で顧客との間で
落とし所をさぐる時にユニットテストを一部省くというのは
普通にあると思うけど？

やった作業に対して全て金を払ってくれる契約
（それって派遣？）なら全ソースに対してユニット
テストするのもありかもね。

326 ：仕様書無しさん：2008/07/16(水) 16:08:56 .net

経験上の話だが、（良い）詳細設計というものは考えていても作れない。

そういう頭の中で考えただけの設計というものは実際に作るときに、
絶対に問題点やバグがある。パフォーマンスの問題なんか
実際に作らないで目標を達成することなんか不可能。

結局コーディングして、その結果をフィードバックして
設計を完成させなければならない。

ユニットテストってのは、その設計を完成させる為のチェックポイントなんだ。

これは重要なこと。
「設計・コードは簡単に変わるが、チェックポイント（テスト内容）は変わらない。」

ゲームに例えるとこうなる。
仕様・・・世界を平和にする。
ユニットテスト・・・各ステージのボスを倒す。（チェックポイント）
設計・・・どういうルートを通ると早くすすめるか。
コーディング・・・実際のキー操作


最初に仕様があるが、これはすごくあいまいなもの。
システムを作るうえでの大前提だが、コレを決めてもシステムは作れない。
個々の目標が、ユニットテスト。これがシステムを作るうえで一番重要なもの。
これがあれば、設計やコードを柔軟に変更することができるし、間違っていない証明になる。
そして、ユニットテストを作ってから、設計とコーディングを行いながら開発していく。
（実際にキー操作をしないと、考えたルートが通れるのか本当に早いかはわからないね）

327 ：仕様書無しさん：2008/07/16(水) 16:20:33 .net

>>325
あなたが言っているのは、ユニットテストに限った話じゃないね。

「自社のメリットにならない場合はテストを省く。」
「やった作業に対して全て金を払ってくれる契約なら全部テストするのもありかもね。」

もし俺が客で、あなたの会社にシステム開発を依頼する立場なら、
お金を払って開発したシステムを、あなたがちゃんとテストしてくれるかどうか不安だけど。

> やった作業に対して全て金を払ってくれる契約
これは、全部のテストの作業量を見積もって、その金額で契約するわけだから、
全部テストするのが当たり前だと思うんだけど？(客が80%で良いとか言うのなら別）

328 ：仕様書無しさん：2008/07/16(水) 16:37:47 .net

>>1
おれの作ったプログラムにはバグがない。
だからテストは不要。

と書きたいところだが、
Ｃ言語だと１万ステップに３カ所ぐらいは
バグがある。

ただし重要なところでバグがでないように
単体テストをしっかりとやってから納品している。

バグは意思の疎通が十分にできていれば
ほとんどでることはない。
バグのでる仕事というのは、だいたい意志の疎通がとれていない
ということ。

329 ：仕様書無しさん：2008/07/16(水) 16:45:46 .net

俺も1万行に一回くらいしかコンパイルしないけど
ほとんどバグないな

330 ：仕様書無しさん：2008/07/16(水) 17:08:08 .net

何この全力で釣られるスレは・・・

331 ：仕様書無しさん：2008/07/16(水) 19:24:52 .net

>>327
>これは、全部のテストの作業量を見積もって、その金額で契約するわけだから、
>全部テストするのが当たり前だと思うんだけど？(客が80%で良いとか言うのなら別）
100%見積もれて、客が１つも仕様変更をしない場合の話だよね。それって。
そこら辺は開発スタイルの問題かと。俺が言いたいのは「仕様変更のリスクを設計や
計画に含めた形で客に説明しているし、客にもある程度納得してもらってる」
という事。

そういった意味でテストの手法や粒度をどうしましょうか？という事を>>80は言い
たいんじゃないの？

332 ：仕様書無しさん：2008/07/16(水) 19:37:34 .net

>>331
でも、最初っから変更出来るって頭を顧客に植え付けちゃうのもどうかと思う。
費用込みなんだから一度くらいは変更できるよね？　とか言われないか？

333 ：仕様書無しさん：2008/07/16(水) 19:59:42 .net

>>332
プロジェクトがある程度続いている or 続く事が期待できる
相手であればそれもありかと。いずれにしても開発・契約
スタイルによるわな。

334 ：仕様書無しさん：2008/07/16(水) 20:01:37 .net

まあ、変更は一切出来ませんとか言っててもどうせ変更させられるんだけどなwww

335 ：仕様書無しさん：2008/07/16(水) 21:27:23 .net

普通は1000行あたりバグが5〜50個くらいかな。数え方やプロダクトの難易度にもよるが。
1000万行だったら、5万〜50万個くらいか。
まぁ、正直、これだけのバグを10人でさばけるのなら大したもんだよ。

336 ：仕様書無しさん：2008/07/16(水) 23:05:12 .net

>>335
ちょっと待て
最悪20行に一個出るのが普通か?
たとえ200行に一個でもかなり多いだろ
新人レベルがかなり混じってるならともかく･･･

337 ：仕様書無しさん：2008/07/16(水) 23:25:32 .net

>>336
設計から実装までやれば、延べにしてそのくらいは出るよ。
設計ミスで全面入れ替えの所とか、パフォーマンス出なくてとか、必ず出てくるwww

338 ：仕様書無しさん：2008/07/16(水) 23:35:42 .net

ここがコーディング界のネ申達がおわす所、バルハラですか（１万ステップに１バグあるかないかを誇るという）？

それにしては冴えない連中が多いのですが・・・

339 ：仕様書無しさん：2008/07/16(水) 23:37:43 .net

あいつ使えねーからこっちで直しておこーぜ。
いいよ、バグ無しって言っておけよ。

340 ：仕様書無しさん：2008/07/16(水) 23:39:08 .net

>>329
それはデータ込みの・・・むしろデータのみを扱ったコードですか？
社会保険庁よりは優秀ですねwww

341 ：仕様書無しさん：2008/07/16(水) 23:42:32 .net

>>340
一般人には想像すらできない天才っているもんなのよ。
天才というか、障害というか。

342 ：仕様書無しさん：2008/07/16(水) 23:43:54 .net

>>337
設計にしてもキモになる部分ならプロトタイプなりなんなりで
実装可能性やパフォーマンス検討するだろ。
それを実装まで持ち越しているなら設計工程が十分でないだけ。

ひょっとして手戻りが好きなのか？ｗ

343 ：80：2008/07/16(水) 23:46:47 .net

>>324
はったりじゃないんだけど・・・。
それに、嘘ついても仕方がないじゃんか。

344 ：仕様書無しさん：2008/07/16(水) 23:48:32 .net

>>342
やらねえよ。
だって動作環境が半年後じゃないと揃わないとかザラにあるからな。
パソコン上で幾ら理論構築しても、載せて初めて発覚するパフォーマンスなんてのは普通だし。

345 ：仕様書無しさん：2008/07/16(水) 23:54:42 .net

まあ、何万行書いてもBUGなんて皆無と豪語してる奴は、信じられなくて当然。
そういうコードは結合後に醜い事になってる事が経験的に多いなw
要するに、俺様仕様でBUGゼロってだけだからwww

346 ：仕様書無しさん：2008/07/17(木) 00:05:34 .net

入力がパンチカードとかだった時代ならともかく…

347 ：仕様書無しさん：2008/07/17(木) 00:07:03 .net

どこかの会社の面接を受けて
特技「１万ステップのコーディングでバグが１件です」
って言ったら、さてどうなるか？

348 ：80：2008/07/17(木) 00:07:24 .net

>>342
パフォーマンスに関するチューニングを急いではいけない。
これは、鉄則なので、いまさら説明する必要はないだろう。
パフォーマンスのチューニングは、設計ではなくて
測定に基づいて行われるべきである。


>>345
正論だな。俺様仕様で作ったプログラムを、俺様が作ったユニットテストを
しても、そりゃー合格するよ。そもそも、自分が理解したとおりのプログラム
を書けない奴はうちにはいない。

たいてい、俺様仕様が間違っている時にバグが埋め込まれる。

349 ：仕様書無しさん：2008/07/17(木) 00:10:11 .net

///なんか80に正論とか言われると萎える・・・

350 ：仕様書無しさん：2008/07/17(木) 00:13:46 .net

// 80は極論派だと思う

351 ：仕様書無しさん：2008/07/17(木) 00:15:48 .net

/うわなんでコンパイルエラー！？

352 ：仕様書無しさん：2008/07/17(木) 00:38:06 .net

>>1はいいこと書いてるな。

353 ：仕様書無しさん：2008/07/17(木) 00:49:15 .net

でも、なんか>>1ってチンコ臭そう

354 ：仕様書無しさん：2008/07/17(木) 00:52:26 .net

/* >>351 コメントとして間違っている！！ */

355 ：仕様書無しさん：2008/07/17(木) 01:26:10 .net

まて、もしかするとマンコかもしれないじゃないか

356 ：仕様書無しさん：2008/07/17(木) 01:27:47 .net

>>344
組み込みならモノがないのでやむを得ない面もあるが、
大概は前のチップや代替品を使って見当を付ければいい。

>>348
パフォーマンスを急げと言っているわけではない。
パフォーマンスがどれくらいでそうか当たりを付けて
速度重視にするかフットプリント重視にするかの設計方針に入れろと言っている。
それを設計工程で行わないで後に回すから手戻るんだよ。

357 ：仕様書無しさん：2008/07/17(木) 02:14:55 .net

パフォーマンスって、チップ次第だし。
パソコンアプリ作ってればそのまま試せるだろうがな。
石のアクセス自体仕様通りじゃない場合だって普通にあるからさw

358 ：仕様書無しさん：2008/07/17(木) 02:22:35 .net

>>356
設計段階でパフォーマンスのトレードオフ検討出来るってうらやましいな
たいていは、死守要求だったりするからな。

359 ：仕様書無しさん：2008/07/17(木) 02:47:00 .net

>>358
排反事象なら一方を満たして他方を次善にして、後は交渉術でそ。
全部実現するにはこれこれのコスト(金額、開発期間)がかかりますと言うだけだし。
金払わない以上どこか諦めてね♥

360 ：仕様書無しさん：2008/07/17(木) 02:50:37 .net

>>359
いや、払うだろ。
正当な追加費用ならなwww

361 ：仕様書無しさん：2008/07/17(木) 03:09:11 .net

>>360
まともな客ならなぇ。。。
大概はより良く(まぁいい)より安く(切り詰めてんじゃねぇ)。

362 ：仕様書無しさん：2008/07/18(金) 02:24:12 .net

たしかに>>1はいいこと書いてるな


先日面接で「ｘｘのシステムを作り直すとしたらどのくらい？」って聞かれて
「コアを作り直すなら２人月ぐらいですね、今まで自分らで作っていた部分が今ではライブラリとして提供されているから。
それよりも、テストの方に工数がかかると思いますよ。」って答えた。

でもよく考えたら、ｘｘを作り直す（完成させる）まで、ってのは当然テストが完了して、のことなんだよな。。。

どうも自分の中で実装とテストを別に考えてしまっていたわ・・・ちゃんとしたものを作る、っていう意味では
テストはものづくりの一部だわ、、、今ここで反省します m(^＿^;)m


遠足は家に帰るまでが遠足だかんね。

363 ：仕様書無しさん：2008/07/18(金) 21:10:41 .net

>>362
ど素人さんですか？
今まで何やってたの？

364 ：仕様書無しさん：2008/07/19(土) 01:08:59 .net

>>363
>>362はちゃんとテスト工数の話してるしちょっと区切り間違っちゃっただけだろ。
いじわるなんだからっ！

365 ：仕様書無しさん：2008/07/19(土) 11:20:47 .net

たかだか二人月のゴミみたいなプロジェクトの例を出されましても・・・

366 ：仕様書無しさん：2008/07/19(土) 13:00:56 .net

ttp://itpro.nikkeibp.co.jp/article/OPINION/20080423/299886/
6000人のSEが同時期に集まったのであって，「6000人月」ではない。
開発工数は先に書いた通り，11万人月である。
このSEパワーは開発だけではなく，テストに惜しみなく使われた。
ざっと5000人が8カ月テストをしたとするとこれだけで4万人月，開発工数の3分の1がテストに費やされた計算になる。

　本来なら有り得ない開発工数とマネジメント工数とテスト工数である。
　本来なら有り得ない開発工数とマネジメント工数とテスト工数である。
　本来なら有り得ない開発工数とマネジメント工数とテスト工数である。

367 ：80：2008/07/19(土) 17:11:42 .net

ttp://sankei.jp.msn.com/economy/finance/080512/fnc0805122000013-n1.htm

テスト段階では、全く想定していなかったトラブルが起きた
テスト段階では、全く想定していなかったトラブルが起きた
テスト段階では、全く想定していなかったトラブルが起きた

テストに開発工数の 1/3 を費やしてもシステム障害で行政処分。
部分最適化のもろさを露呈してしまう結果になった。

「全く想定していない」・・・要求定義者や分析・設計者のミスをテストで
カバーできないってこと。間違った仕様を完璧にコーディングしても
それは、バグ。

368 ：仕様書無しさん：2008/07/19(土) 17:22:10 .net

6000人全員が派遣でしたwww　って話？？

369 ：仕様書無しさん：2008/07/19(土) 20:48:04 .net

コーディングは終わったので、あとは人海戦術で手動テストしてくださいって
パターンなら最初からうまくいくはずないよ。

370 ：仕様書無しさん：2008/07/19(土) 22:14:17 .net

なんか、ぶっちゃけ私の方法ならうまくいくと間接的に言ってるように
見えるけど、ほんとそうなの？

371 ：仕様書無しさん：2008/07/19(土) 22:22:01 .net

>>369
テストの際に出てくる不具合報告を眺めてるだけじゃ完成しないがなw

テストに入ってからが本当のコーディング作業が始まると思わなきゃ上手く行かない。

372 ：仕様書無しさん：2008/07/20(日) 02:22:31 .net

>>371
メガプロジェクトじゃ、そんなの通用しないし。

373 ：仕様書無しさん：2008/07/20(日) 02:34:44 .net

>>372
はあ？
メガプロジェクトじゃ、最後までコーディングしてる部署が必ずあるよ。

つうか、不具合改修はやらねえの？

374 ：仕様書無しさん：2008/07/20(日) 03:14:48 .net

普通、やるでしょ
PSPの海腹川背みたいな例もあるけどw

375 ：仕様書無しさん：2008/07/20(日) 12:12:05 .net

>>371
> テストに入ってからが本当のコーディング作業が始まると思わなきゃ上手く行かない。
だから、無駄なテスト前コーディングをしないで、
テストをやってコーディングをするんだよね。

376 ：仕様書無しさん：2008/07/20(日) 12:16:01 .net

>>367
> 「全く想定していない」・・・要求定義者や分析・設計者のミスをテストで
> カバーできないってこと。間違った仕様を完璧にコーディングしても
> それは、バグ。

ですよね。だからちゃんと想定して、
その想定した内容をテストとして書くんですよね。

これであなたもユニットテストの重要性を理解したと思います。

377 ：仕様書無しさん：2008/07/20(日) 12:20:56 .net

ついにマ板にも夏が来たか・・・

378 ：仕様書無しさん：2008/07/20(日) 14:21:36 .net

>>376
ユニットテストじゃ、要求定義や設計時のミスは取り除けないよ。

それを元にテストが作られるんだからね。

だいたい、設計時の矛盾は最終的な総合テストまで残る。
要求定義の矛盾は製品にまで残る。

379 ：仕様書無しさん：2008/07/20(日) 15:00:32 .net

>>373
「本当のコーディング作業」の定義次第だな。
そして、その定義を云々するのはくだらねー。

380 ：仕様書無しさん：2008/07/20(日) 17:13:26 .net

80の言い分だけど、

うちの会社は1000万のコードで、

次に、基本証券・金融系では無い。制御系だといって、

最後に、国内最大の金融系の仕様段階での問題点を出している。

あ、あとシリコンバレーと仕事しているってのもあったな。

で、別に仕事のやり方は全否定する要素は無いが、具体例は
全否定されても仕方ないほど妄想力に満ちていると感じたの漏れだけ？

381 ：仕様書無しさん：2008/07/20(日) 19:23:59 .net

>>374
あれは、「仕様です」

382 ：仕様書無しさん：2008/07/23(水) 01:01:35 .net

とりあえずユニットテストやファンンクショナルテストをちゃんと書いていけば
設計時の矛盾とか普通にたくさんでてくるよ。
んで、短いサイクルでどんどんリファクタしていけばいい。
もちろん手動テストもするけど、ばかげた規模での人海戦術テストとかにはならないでしょ。

383 ：仕様書無しさん：2008/07/23(水) 01:06:30 .net

またまた富士通！東証システム障害　プログラムミスが原因 　2008/7/22
http://headlines.yahoo.co.jp/hl?a=20080722-00000027-maip-brf

41 名前：仕様書無しさん 投稿日：2008/07/23(水) 00:00:22
　　 　∧∧
　富 ( ･ω･)　　　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　士 （つ/￣￣/　＜　1銘柄当たり1280バイトの作業用メモリー領域だから、
　通　　/＿＿/ ＼　＼　2万8000銘柄分、合計3万5000Kバイト・・・
　||＼　　TOWNS　＼　＼　 4万バイトということで"PIC 9(40M)"ってことだな
　||＼||￣￣￣￣￣|| 　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　||　 ||￣￣￣￣￣||　
　 　 .|| 　 　 　 　 　||
え〜と40M・・と、　　それ、ポチっとな　
　000230　01　WORKAREA.
　000240 　　　　03 WORK　　　　　　　　 PIC 9(04). 　　<--- 4バイト
　　　　　　　 ∧東∧
　　∧富∧ （´<_｀ ）　　　さすがだな富士通
　 （ ´_ゝ`）/　　⌒i　
＿(__つ/￣￣￣/i |＿　　そんなこと言ってないで、チェックお願いしますよ、東証&NTTデータさん
　　＼/＿＿＿/ ヽ⊃

そして・・・・
　　　　. . : : : :: : : :: : ::: :: : :::: :: ::: ::: ::::::::::::::::::::::::::::::::::::::
　　　.　. .... ..: : :: :: ::: :::::: :::::::::::: : :::::::::::::::::::::::::::::::::::::::::::::
　　　　　　　 Λ＿Λ . . . .: : : ::: : :: ::::::::: :::::::::::::::::::::::::::::
　　　　　 　/:彡ミ゛ヽ;）ー､　. . .: : : :::::: :::::::::::::::::::::::::::::::::
　　　　　 / :::/:: ヽ、ヽ、 ::i . .:: :.: ::: . :::::::::::::::::::::::::::::::::::::::
　　 　　 / :::/;;: 　 ヽ　ヽ ::ｌ　. :. :. .:: : :: :: :::::::: : ::::::::::::::::::
￣￣￣（_,ノ ￣￣￣ヽ､_ノ￣￣￣￣

384 ：仕様書無しさん：2008/07/23(水) 01:06:41 .net

　【東証のシステム障害、設定ミスをテストでも見抜けず　2008/07/22　】
　　鈴木CIOは「設定をミスしたのはベンダーの富士通」とした上で、「多数の銘柄に対し板情報の
　　問い合わせがあった場合をテストケースに含んでいなかったのは我々の責任。もっと幅広く
　　テストすべきだった」と陳謝した。
　　　http://itpro.nikkeibp.co.jp/article/NEWS/20080722/311271/

　【富士通の開発ミスの全責任は東証にある」とみずほ証券、株誤発注裁判　2008/05/09　】
　　2005年12月にみずほ証券がジェイコム株の誤発注で出した損失を巡って東京証券取引所を
　　訴えた裁判の第9回口頭弁論が2008年5月9日、東京地方裁判所で開かれた。
　　原告のみずほ証券側は、被告の東京証券取引所にシステムの発注者としての注意義務違反と
　　重過失があったことを改めて主張する準備書面を地裁に提出した。
　　みずほ証券側は「東証はシステムの発注者として、業務上の要求を富士通に伝え、富士通が
　　開発したプログラムが要求と整合しているかをテストする責任がある」と訴え、「誤発注の
　　取り消しができなかったのは東証の重過失だ」と主張した。
　　　　　：
　　次回口頭弁論は2008年7月25日の予定だ。
　　　　　　　　　　　　~~~~~~~~~~~~~~~~~~~~~~~~~~　　
　　　http://itpro.nikkeibp.co.jp/article/NEWS/20080509/301077/

　【「短期間で2回のシステム障害は、痛恨の極み」東証社長が会見 2008/03/25　】　
　　証は2月8日の金融派生商品の取り引きを担う新派生売買システムの障害に続き、3月10日にも
　　株式売買システムで障害を起こした。
　　先月22日に新派生売買システムを中心とした障害の再発防止策を発表したばかりだが・・・
　　　http://itpro.nikkeibp.co.jp/article/NEWS/20080325/297067/

　【特集・東証システム問題リンク】
　　　http://itpro.nikkeibp.co.jp/99/tousyou/index.html

385 ：仕様書無しさん：2008/07/25(金) 03:00:06 .net

ユニットテストは詳細設計どおりにプログラムが稼働するテストと認識しているんだが、
詳細設計が１ＳＴＥＰ対応の設計書でない場合、全パステストの結果って
どういう扱いになるのかな？

386 ：仕様書無しさん：2008/07/26(土) 01:44:42 .net

>詳細設計
の確認はうちではユニット-ユニットの結合テストだな

ユニットテスト対象はプログラム設計
ここ→ttp://msugai.fc2web.com/pgm/test.html
のV字モデルに近い

なので全パステストなんて結合テストで考えない

387 ：386：2008/07/26(土) 01:57:35 .net

ttp://itpro.nikkeibp.co.jp/article/COLUMN/20051102/223934/
の図1もプログラム設計が書いてないけど同じっぽい

388 ：仕様書無しさん：2008/07/28(月) 11:42:25 .net

今日初めて見たが、みんな何か勘違いしてないか？
テストで信頼性は上げられない、テストは
「このプログラムにはバグがあるます」を実証するもので
バグを沢山検出したからと言って、そのプログラムには
もうバグが存在しないと言う実証にはならない。
実際は逆で、統計的に見るとバグ密度の多いプログラムほど
残りの潜在バグが多く含まれている。

テストでは信頼性は旦保できない為、極度に
信頼性が求められるシステムでは、テストをしない開発手法もある。

389 ：仕様書無しさん：2008/07/28(月) 15:31:02 .net

>>388
asshole

390 ：仕様書無しさん：2008/07/28(月) 18:11:43 .net

>>388
＞信頼性が求められるシステムでは、テストをしない開発手法もある。
kwsk

391 ：仕様書無しさん：2008/07/28(月) 18:23:16 .net

耐震偽装と同じレベルだろwww

392 ：388：2008/07/29(火) 00:35:28 .net

>>390
有名な所では、ダーリントン原子力発電所の緊急炉停止システム

393 ：仕様書無しさん：2008/07/29(火) 00:43:53 .net

>>388
ソフトウェアの信頼性を定義してみな

394 ：仕様書無しさん：2008/07/29(火) 02:52:18 .net

IEC読んで言ってるなら凄いけどね・・・

395 ：388：2008/07/29(火) 21:00:07 .net

>>393,394
俺をテストしてどうする。しかし、なぜムキになるか分からん？
http://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%86%E3%82%B9%E3%83%88
>ソフトウェアテストでは、欠陥が存在することを示すことはできるが、欠陥が存在しないことは証明できない。
Wikipediaにもにも書いてあるし、大半の「テスト」関連の書籍にも同じような意味の事が書かれている
いままで、その辺りの知識もなしにレスを書いていたのか？

396 ：仕様書無しさん：2008/07/29(火) 21:28:57 .net

>>395
それは394への答えにはならないよ。

397 ：仕様書無しさん：2008/07/29(火) 21:32:30 .net

>>395
だから、普通テストは
要求された機能が特定の条件下で要求通りの結果を示せるかをテストするんだぜ？
要求されてない（テストされてない）機能がどのように振る舞おうが知ったこっちゃ無いのはあたりまえ。

だからその理論は正しいが、そんな事は誰も要求していないんだよ。
想定外の欠陥は許されるが、想定内の欠陥はダメなの。

398 ：仕様書無しさん：2008/07/30(水) 00:31:54 .net

>>397
＞想定外の欠陥は許されるが、想定内の欠陥はダメなの。

現実は想定外の欠陥でも許さない人間が大半だがな。　相乗りしている他システムが
異様にリソース使いまくって、それに巻き込まれて不具合起きて、それでも不具合が
おきない様にしろと言われかけたときは頭抱えたよ、、、

399 ：仕様書無しさん：2008/07/30(水) 00:34:35 .net

>>398
もちろん納品前に発覚した不具合は想定内だよ。

400 ：仕様書無しさん：2008/07/30(水) 00:36:13 .net

予想GUYダ！

401 ：仕様書無しさん：2008/07/30(水) 00:52:25 .net

よそう、GAYﾀﾞ!

402 ：仕様書無しさん：2008/07/30(水) 02:14:08 .net

>>399
納品後ですが、何か？
しかも納品後すぐとかじゃなくて、数ヶ月たってとかだったり、他の納品先だと
そんなこと起きなかったりとかで調査だけでも結構かかりましたが。

403 ：仕様書無しさん：2008/07/30(水) 02:16:01 .net

>>402
受け入れ検査終了後なら別料金もらってんだろ。
いいじゃん仕事あって。

404 ：仕様書無しさん：2008/07/30(水) 18:45:40 .net

>>388
＞信頼性が求められるシステムでは、テストをしない開発手法もある。
ネタにしてはよく出来てる手口。

405 ：仕様書無しさん：2008/07/30(水) 21:15:43 .net

>>395
で、信頼性はどう定義するんだ？

406 ：388：2008/07/30(水) 23:03:31 .net

>>397
限られた前提条件・限られた入力値・限られた入力値組み合わせでテストをして
その機能が、全て正しく動くと思ってる？　テストが何たる物か分かっていない証拠だな

>>404
自分の知識で分からないものはネタか！やっぱりこんな奴がいるんだ
例を出したんだから、調べれば分かると思うが。

>>405
俺に聞いても、プログラムの信頼性は上がらんだろう、自分で考えないと。

407 ：仕様書無しさん：2008/07/30(水) 23:07:51 .net

>>406
誰も信頼性の上がる方法なんて聞いてない。
信頼性の定義を聞いているのがわからないのか？

408 ：仕様書無しさん：2008/07/30(水) 23:09:50 .net

>>406
お前もちゃんと調べてから例出しな

409 ：仕様書無しさん：2008/07/30(水) 23:10:08 .net

>>406
全て動くなんて言ってないが。
ファビョるのもたいがいにしろよ。

410 ：388：2008/07/30(水) 23:19:22 .net

>>407
>信頼性の定義を聞いているのがわからないのか？
分かって書いているんだが、分からないのか？

>>408
調べても分からなかったのか？俺はこれ以上教えるつもりはないから

>>409
>全て動くなんて言ってないが。
だから、テストでは信頼性は確保出来

411 ：仕様書無しさん：2008/07/30(水) 23:20:59 .net

>>信頼性の定義を聞いているのがわからないのか？
>分かって書いているんだが、分からないのか？

どこに書いたんだ？

412 ：仕様書無しさん：2008/07/30(水) 23:21:48 .net

駄目だこいつ。

413 ：仕様書無しさん：2008/07/30(水) 23:22:33 .net

テストの前にソースの読み直しをお願いします
先輩

414 ：仕様書無しさん：2008/07/30(水) 23:23:52 .net

単純リプレースとか言って営業がとってくる仕事ほど
前の機能をちゃんと満たしてるか（正しく動作するか？）って意味で
テストが重要、

って口をすっぱくして言ったんだがヌルーされた。
マシン->マシンでコピーして、簡単に動作確認すればいい

だってさ


まぁ、うまくいけばいいんだけどね。。。その時期夏休みとって携帯電源切っとこう

415 ：仕様書無しさん：2008/07/30(水) 23:23:58 .net

原子力発電所のソフトウェア開発について議論するスレじゃないよ

416 ：仕様書無しさん：2008/07/30(水) 23:24:26 .net

>>410
394にまともに答えられない人に教えてもらう事無いと思うよｗ

417 ：仕様書無しさん：2008/07/30(水) 23:25:44 .net

何手法だか知らないが、その手法でぬるいメガプロジェクトでも回してみればいいさ。

418 ：仕様書無しさん：2008/07/30(水) 23:40:28 .net

KKDは勘と経験と度胸による見積もり法です

419 ：仕様書無しさん：2008/07/30(水) 23:40:45 .net

それ
なんて
みずぽ？

420 ：388：2008/07/31(木) 00:05:03 .net

>>411
>>どこに書いたんだ？
信頼性の定義は書いていない

>>412
>駄目だこいつ。
そうだな

>>413
>テストの前にソースの読み直しをお願いします
読み直しは大事だと思う、テストよりも

>>414
何処でも営業は同じ、そんなもん

>>415
ソフトウェアの話じゃないのか？

>>416
教えるつもりもないから大丈夫

>>417
そこまで信頼性を求められるプロジェクトは、ほとんどない

>>418
勘・経験・度胸は大切だと思うよ、マネジメントは人間性が一番重要だと思う

>>419
???

421 ：仕様書無しさん：2008/07/31(木) 00:10:24 .net

>>420
聖徳太子現る

明日は合コンだってさ、木曜だしなーーー
女の子たちの接客上手をテストしてやるぜ〜

422 ：仕様書無しさん：2008/07/31(木) 13:06:27 .net

>>420 からおじゃば臭がするのは気のせいか？

423 ：仕様書無しさん：2008/07/31(木) 19:21:50 .net

気のせいじゃなくね

424 ：仕様書無しさん：2008/07/31(木) 20:04:06 .net

>>421
どこのキャバでやんの？

425 ：仕様書無しさん：2008/07/31(木) 20:39:41 .net

>>420
おじゃばとしては、どういうテスト手法を理想としてんの？

426 ：仕様書無しさん：2008/07/31(木) 20:43:06 .net

>>422
いや、ハカセじゃないのかシステム工学を語りたいんだろう
でもハカセはアホだから違うかｗ

427 ：仕様書無しさん：2008/07/31(木) 20:48:28 .net

>>425
教えてやろう君にはすばらしい餌だなｗ

428 ：仕様書無しさん：2008/07/31(木) 20:52:52 .net

>>426
お前、おじゃばだろ

429 ：仕様書無しさん：2008/07/31(木) 22:14:57 .net

>>424
キャバじゃないし、今日でもなかった・・・

だれかおれの視力、聴力、記憶力をテストしてくれ

430 ：仕様書無しさん：2008/07/31(木) 22:18:40 .net

>>429
つ　http://homepage3.nifty.com/funahashi/game/game693.html

431 ：仕様書無しさん：2008/08/01(金) 03:03:06 .net

テストしてほしけりゃ金よこせ

432 ：仕様書無しさん：2008/08/01(金) 03:36:48 .net

まともにテストできるか能力を示せ。

433 ：388：2008/08/02(土) 15:13:28 .net

テストは限られたリソースの中で、いかに効率良く不具合を見つけるかが重要
例えば、同じプログラムをテストして
　「Aは１０件のテストケースで５件のバグが見つけた」
　「Bは１００件のテストケースで１０件のバグが見つけた」
では、Bの方がAより残りのバグも少ないので信頼性のあるプログラムになるが
テストとしては、半分の確率でバグを見つけたAの方が、「良いテスト」と言える

つまり、テストは効率性が重要で、プログラムの信頼性は考えない
（バグを多く見つけるかでは無く、「"効率的"」にバグを多く見つけるかが重要)
同値テストや限界値テストなどのテストテクニックも、バグを効率に見つける為に考え出されたもの

434 ：仕様書無しさん：2008/08/02(土) 16:18:18 .net

なるほどね。
おじゃばという人物は、コミュニケートする気はないわけだ。
相手とちゃんとやりとりしたい訳じゃない。

単に「自分は知識があるのだ、おまえらより優れているのだ」と思っていて、
その優れた俺様の知識をひけらかし(たつもりになっ)て、気持ちよくなってるだけ。
その過剰な自己過信が揺らぐことも、基本的にはなくて、
それ故に、主張が基本的にいつでも一方的で、言いたいことを言うだけ。

使いようによっては、存在に意味を持たせる事は可能かもしれないけど、
人間的にはゴミだなぁ。ｗ

435 ：仕様書無しさん：2008/08/02(土) 16:23:25 .net

Aの方が効率悪いじゃん？
なんでBは100件もこなせてるのに
Ａは10件しかこなせなかったんだ？
リソース一緒なのに。

436 ：仕様書無しさん：2008/08/02(土) 16:44:08 .net

>>388
節子、それ、テストやない。デバッグや。

437 ：仕様書無しさん：2008/08/02(土) 19:52:15 .net

>>435
１０件辺り５件も不具合出りゃあ、テスト中止だろwww
５０％なんてどんだけボロボロなんだよwww

438 ：80：2008/08/03(日) 00:48:44 .net

>>437
>>435 の例は、
・同じプログラムなら網羅できたとしてテストケースの数は同じになる。
・テストケース数＝1000件
・実際の不具合の数＝20件

テストA：
　テストケースの中から10件を選択してテストを実施->不具合5件発見

テストB：
　テストケースの中から100件を選択してテストを実施->不具合10件発見

プログラマーが嫌うような意地悪なテストから実施すると不具合は見つかり
やすいとか、やりようによっては早期に不具合を発見できるという意味なのでは？

さらに、テストケースの粒度や内容をコントロールすれば効率はさらに
上がると思う。

439 ：80：2008/08/03(日) 01:17:35 .net

屁理屈といわれそうだが、言葉の定義だけで言うなら
「信頼性＝故障しにくい事」

故障とは
1. 機械や身体などの機能が正常に働かなくなること。
2. 物事の進行が損なわれるような事情。
3. 異議。苦情。

1. の意味だと
ハードウェアシステムの場合は、劣化などでそのうち故障する。
ソフトウェアシステム（プログラム）の場合は、劣化などはしないので
故障しない。

ソフトウェアの不具合は、2. の意味と考えられる。で、実際には、
3の苦情を指すんじゃなかろうか？
つまり、苦情の件数が少ないほど信頼性が高いと考えられる。

で、
A. 頻繁に使用されるある1つの機能に不具合がある
B. たまに使用されるある2つの機能に不具合がある
C. 滅多に使用されないある10の機能に不具合がある
を考えた場合、A, B, Cのどれを見つけるのが実際に利益があるのか？
を考えるとわかりやすいかもしれない。

なので、 >>435 の言う「テストの効率」は、もっと深く考慮されるべき
だと思う。

蛇足だが、
あるボタンを連打すると発生する不具合をテスト自動化で見つけたが
人間業では決して発生させることができない不具合だったので修正を
見送った経験がある。

440 ：仕様書無しさん：2008/08/03(日) 01:21:11 .net

>>435じゃなくて>>433な。

441 ：仕様書無しさん：2008/08/03(日) 01:25:14 .net

>>438
そんな机上論、幾ら並べても無意味。
何故って？

不具合の数に全容なんて無いからさ

その「実際の不具合の数」自体が空論
テスト方法変えて出てくるのは、異なる不具合であり、全容の一部が見えたわけではない。

442 ：80：2008/08/03(日) 01:36:54 .net

>>440
訂正サンキュー。

ついでに補足
滅多に使用されない機能に致命的な不具合がある場合が一番厄介。
しかも、要求にはない機能が盛り込まれる場合、つまり、想定外の使い方
をされるのは、本当に厄介だ。

要求に無い機能（設計の段階で暗に入り込んだ機能）は、テストから漏れる
事が多いと思う。で、うちでは、繰り返し型なので、この手の潜在的な機能は、
（気付けば）要求としてとらえることにしている。

443 ：80：2008/08/03(日) 01:53:57 .net

>>441
「ソフトウェアの信頼性ほど信頼性の低いものはない」と俺も思う。
不具合密度がどーとか経営陣や顧客に嘘くさい説明はできても自分自身は
納得していない。なので、実際には、統計的な手法からは距離を置いている。

持論で申し訳ないが、俺は、
「ソフトウェアの信頼性＝クレーム処理にかかった費用の少なさ」
と考えている。
極論すると
・ユーザが発見できない不具合は不具合とはみなさない。
（無実ではないが無罪。飲酒運転も逮捕されなければOK的な・・・）
・要求にない機能は、一切入り込まないようにする。
てな感じかな。

444 ：仕様書無しさん：2008/08/03(日) 02:21:12 .net

>>443
そういうプログラム引き継がされて爆弾爆発させたら
爆弾仕込んだヤツは無罪で爆発させたヤツが
全部罪をかぶることになる

この図式はなんとかならないかなあ

445 ：仕様書無しさん：2008/08/03(日) 02:24:47 .net

まあ、完全にBUGを潰す作業をいつまでも行っていたら、永久に製品が出せないからね。

完全にBUGの無いプログラムなんて存在しないからね。

もしBUGが一切無いプログラムがあったとしたら、それは検査方法が間違っているかテスト結果にねつ造があるかのどちらかさ。

446 ：80：2008/08/03(日) 02:45:56 .net

以前にも書いたけど、テストだけを頑張るだけではだめだと思う。
部分最適化じゃなくて全体最適化ね。

以下は、テストではなく設計で逃げたケースの事例。

要求
「何年も24時間連続稼働させないといけないシステム」

設計
・非稼働時に定期的にこっそり再起動
・異常終了した場合はこっそり再起動

100%絶対に異常終了しない設計にするとテストが大変（証明できない）ので
設計で対策をこうじた。画面はあれ？ってな感じになるけどしばらくすると
復帰する。今のところクレームは無い。

447 ：仕様書無しさん：2008/08/03(日) 10:42:24 .net

>>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ

448 ：仕様書無しさん：2008/08/03(日) 10:56:30 .net

>>446
死ぬほどよくあるインフラ構成を偉そうに語る辺り働いてないか末端PGでしょ。
しかも、いきなり「非稼働時」とかまともに説明出来てないしｗ
インフラ構成に頼ったシステム安定性なんて無いに等しい

449 ：仕様書無しさん：2008/08/03(日) 11:04:28 .net

>>436
なるほど。>>388を直してみた。

--------
今日初めて見たが、みんな何か勘違いしてないか？
デバッグで信頼性は上げられない、デバッグは
「このプログラムにはバグがあるます」を実証するもので
バグを沢山検出したからと言って、そのプログラムには
もうバグが存在しないと言う実証にはならない。
実際は逆で、統計的に見るとバグ密度の多いプログラムほど
残りの潜在バグが多く含まれている。

デバッグでは信頼性は旦保できない為、極度に
信頼性が求められるシステムでは、デバッグをしない開発手法もある。

450 ：仕様書無しさん：2008/08/03(日) 11:45:31 .net

>>449
あ　すげーまともな文章になったww

451 ：80：2008/08/03(日) 16:25:33 .net

>>448
インフラじゃないけど・・・。全然、意味通じてないみたい。
俺、文章力自信なくしてきた。

452 ：80：2008/08/03(日) 16:51:01 .net

>>448
真面目に読んでくれているみたいだな。
非稼働ってのは変だな。よーは、ユーザーがシステムを使用していない
隙間の時間ということ。

あと、システムと書いたけど厳密には、ソフトウェアシステムね。
自己診断機能と自己修復機能を連携させてるよーな感じのシステム。
実際には、ソフトが原因で異常終了することはないんだけど、
うちは、デバイスがくっついてるからそいつらのせいでシステムが
落ちたりする。

デバイス側の不具合により通信系が異常をきたした場合・・・・
ごめん、長文になりそうだから説明止めとく。

453 ：388：2008/08/03(日) 18:19:20 .net

>>439
>つまり、苦情の件数が少ないほど信頼性が高いと考えられる。
それは違う「原子力発電所の緊急炉停止システム」みたいな
稼動する事がまれで、稼動での不具合が致命的になるケースもある
苦情の件数など関係なく、信頼性は稼動前から求められている

>>436,449,450
テストとデバッグは別もの

454 ：448：2008/08/03(日) 18:41:06 .net

>>452
余計おかしいだろ。

>要求「何年も24時間連続稼働させないといけないシステム」
>非稼働ってのは変だな。よーは、ユーザーがシステムを使用していない隙間の時間ということ。
要求満たしてないのはお話しにならないよね？
上の文が出るって事は仕様を修正した訳でもないし。

>うちは、デバイスがくっついてるからそいつらのせいでシステムが
>落ちたりする。
この1行でもうお腹一杯です・・・

455 ：仕様書無しさん：2008/08/03(日) 19:18:07 .net

最近話題の地震速報とかか？

456 ：仕様書無しさん：2008/08/03(日) 20:03:05 .net

>>453
> テストとデバッグは別もの

正解。よくできました。
お前自分が書いたレスよく読んでみろ。
テストとデバッグの違いの何たるかが解ってない奴の発言だ。
勉強して出直して来い。

457 ：388：2008/08/03(日) 22:14:06 .net

>>456
それは間違い、俺が書いたものを理解出来ないだけの話

458 ：仕様書無しさん：2008/08/03(日) 22:33:42 .net

>>457
だとしたら日本語の書き方を勉強して出直して来い。

459 ：388：2008/08/03(日) 23:17:19 .net

>>458
それも違う、そっちが知識が無いから理解出来ないだけの話
システム工学系の話だから、知識がない人とは話が噛み合わない

460 ：仕様書無しさん：2008/08/03(日) 23:27:23 .net

理解出来てたら簡潔に説明できる。
理解出来てないから伝わらないと教わった俺はいい先生に出会えてたんだなｗ

461 ：仕様書無しさん：2008/08/03(日) 23:35:54 .net

なんかいつのまにか80：その他大勢
みたいな流れになってしまったな


おれとしては80みたいな特異な例よりも
ふつーに自分の現場では・・・みたいなノリが好きなんだが・

462 ：仕様書無しさん：2008/08/04(月) 00:34:05 .net

自分の話が分かってもらえないなら
まずどうすれば分かってもらうかを考えるべき




分かってもらいたいのであればな。

463 ：仕様書無しさん：2008/08/04(月) 01:15:35 .net

「信頼性」の定義が述べられない以上
>>388の話には何の主張も存在していない。
故に誰にも理解できるはずがない。

464 ：仕様書無しさん：2008/08/04(月) 01:27:15 .net

『HAYST法』ってなんて読むのか知っている方いますか？？

465 ：80：2008/08/04(月) 07:01:35 .net

>>453
繰り返すが、ソフトの信頼性は、苦情の件数ではなくて以下と
俺は、考えている。
「ソフトウェアの信頼性＝クレーム処理にかかった費用の少なさ」

「原子力発電所の緊急炉停止システム」のような重要な機能は、
不具合が現実のものとなった時、クレーム処理に相当金がかかるだろう。
よって、網羅的にテストすべきだと思う。

対投資効果的に

誤解があるようだけど、クレームは、あくまでも結果。
「クレーム処理費用が高くつきそうな不具合を発生させる可能性のある
機能のテストケースをきっちりやれば、絶望的な数のテストケース全部
はやらなくてもいいんじゃないか？」と言ってるだけ。

クレーム処理で高くつく機能は、顧客要求にある機能とリスクに関する機能
とかね。

466 ：80：2008/08/04(月) 07:04:16 .net

>>454
悪いが、たぶん俺と >>454 はドメインが違いすぎると思う。
「顧客要求≒真の要求」とだけ書いとく。

467 ：80：2008/08/04(月) 07:25:53 .net

>>460
横やりで悪いが。
そんなに単純なものじゃないと思うぞ。

システムのアーキテクチャは複数のビューで相補的にモデル化される事が
ある。エンドユーザ、プログラマー、システムエンジニア、アナリスト・・・
といった立場によって、「見方」が違うわけ。

話題がプログラミングならビューは「プログラマ」だけで済むので
混乱は少ないが、「テスト」は裏返すと要求でもあるので、いろんな利害
関係者が混ざってややこしい。

理解にも種類があるんじゃないか？

468 ：80：2008/08/04(月) 07:44:33 .net

>>464
俺は、ヘイストと読んでるが・・・。自信はない。
別に否定するつもりはないが、数あるテスト手法の一つだな。
HAYST法は、上流工程がパーフェクトな場合に生きる手法だと思う。

469 ：仕様書無しさん：2008/08/04(月) 21:23:22 .net

隔離スレが必要なレベルだな・・・

470 ：仕様書無しさん：2008/08/04(月) 22:22:55 .net

>>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ

>>338
能書き垂れる前に、ソフトウェアの信頼性を定義しろ

471 ：仕様書無しさん：2008/08/04(月) 22:29:31 .net

なぁ、なんで>>80は粘着しとんの？

それプログラマやない、評論家気取りの厨房や

472 ：仕様書無しさん：2008/08/04(月) 22:42:26 .net

>>459-471
お前らみたいに釣られるカモがいるからじゃねーか？
しかも連投だしｗ。ごくろうさん。

473 ：仕様書無しさん：2008/08/04(月) 23:25:02 .net

>>466
要求分類出来てないよ。
≒にならざるおえない要求とそうでない要求がある。
君が例で出した要求は後者。

コテ酉つけて専スレ立ててもらいなよ。
みんな弄るの飽きたみたいだし、このスレではもう君は不要。

474 ：仕様書無しさん：2008/08/05(火) 00:46:38 .net

を

475 ：388：2008/08/05(火) 07:50:21 .net

>>465
書いている事は分かるが、それは受注企業の論理だ
企業である以上、費用対効果を考えるのは当然だが
絶対の安全が求められるシステムでは通用出来ない
「人が死んでも生命保険に入っているから大丈夫」とは、絶対にならない

俺の考える信頼性は、当事者の論理では無く、第三者も納得出来る
科学的根拠、例えば
「プログラム正当性の証明」(数理論理学的根拠)
「運用実績」（統計的根拠)

当事者の論理では、信頼性の根拠にならない

476 ：仕様書無しさん：2008/08/06(水) 23:03:41 .net

>>475
人が死ぬ不具合は、「クレーム処理費用が高くつきそうな不具合」の
典型だろ。

科学的根拠は、ユーザからしたら「当事者の論理」となんら変わらない。
ユーザーが理系なら納得もしてくれるだろうが・・・。
「プログラム正当性の証明」が理解されることはないだろう。
「運用実績」は唯一の不具合で崩壊する。

「統計的根拠」って天気予報で降水確率100%でも晴れる日があるだろ。
天気予報が外れても訴えられることはないのは、みんなが納得しているからだ。
ただ、ソフトウェアの不具合は、統計的に信頼性が高いと何度言っても、
不具合は不具合なわけで客は決して「統計」を重要視しない。

プログラム正当性証明をバグを生む開発者がどーせやるんだろ。
「正当性を証明できる」なら「もともとバグはない」というパラドックスに
ハマるのが落ちだと思うがな。

477 ：仕様書無しさん：2008/08/07(木) 22:07:06 .net

テストは全ルート試験です。
もちろんifやswitchならば全てを網羅。
試験項目数が1000を軽く越えます。

478 ：仕様書無しさん：2008/08/07(木) 23:52:07 .net

夏休みだなぁ

479 ：仕様書無しさん：2008/08/08(金) 20:36:54 .net

全網羅で「1000を軽く越える」程度なら楽勝だろ

480 ：仕様書無しさん：2008/08/08(金) 21:07:59 .net

開発規模・期間に対しては辛すぎる
一日400件消化しろと？
常識的に考えてくれ・・・

481 ：仕様書無しさん：2008/08/08(金) 21:09:17 .net

そういう情報を後出ししてるようだからダメなんだよ

482 ：仕様書無しさん：2008/08/08(金) 23:20:20 .net

>>480
そんなん普通だろ
何自分だけ不幸のつもりになってんだよwww
テスト自体の効率のいい作業順番とか考えれ
まさか項目上から順番にやってたりしないよな？

483 ：仕様書無しさん：2008/08/09(土) 21:19:18 .net

作業順番を変えても期限は変わらない件

484 ：仕様書無しさん：2008/08/09(土) 21:32:46 .net

>>80のおじゃば
うざいし

485 ：仕様書無しさん：2008/08/09(土) 21:43:04 .net

一日400件なんて新人レベル

486 ：仕様書無しさん：2008/08/09(土) 21:50:21 .net

アプリのテストを言ってるようだが、
異常系や例外系のテストなんか網羅できんだろ

487 ：仕様書無しさん：2008/08/09(土) 23:13:48 .net

スレは読んじゃないけどさ。

>>476
そうは言っても、ある程度定量的に評価出来ないと、
成果物の信頼性が属人的になってしまって、管理出来なくなるだろよ。

475で言うところの「第三者も納得出来る」というのは、
客観的に評価しているということの表現であって、
ユーザが納得できるかどうかでは無いと思うよ。

個人的には根拠は何でも良い。
>>443なら「ソフトウェアの信頼性＝クレーム処理にかかった費用の少なさ」
それをどのように評価し、どのように見積もって、
これから出荷するソフトウェアの信頼性を評価するのか、
という話。
「出荷したソフトの信頼性が高かった」だけでは意味が無い。
大事なのは「これから出荷するソフトの信頼性は高いのか？」

既に運用されているシステムの販売であるとかであれば、
それはつまり「運用実績」であるかな。

「プログラム正当性の証明」ってのはサッパリ意味不明。

488 ：仕様書無しさん：2008/08/09(土) 23:54:11 .net

>>486
最近のテストツールは出来が良くて、異常系や例外系のテストなんかもできるらしいね。

ぶっちゃけ、80が言っていたのはプログラムを細切れにして、単純化されたものを
テストツールでガリガリすると言っている。

489 ：仕様書無しさん：2008/08/10(日) 11:19:43 .net

なんで別人になりすますの？

490 ：80：2008/08/10(日) 21:23:12 .net

>>489
いや悪いが、最近、忙しくてレスしてない。

>>488
こま切れまですると、管理コストが逆に増えるから、
ほどほどに分割している。テストのために分割するのではなくて、
チーム開発なので結果的にそうなるだけかもしれないけど。

「ソフトウェアの信頼性＝クレーム処理にかかった費用の少なさ」
だけど、財務部門がほっといても評価してくれる。奴らはソフトを
金でしか見てない。

「これから出荷するソフトの信頼性が高いのか？」
なんて出荷しなくちゃ分からねい。これは、あらゆる手段を講じても
無理だ。できるという奴がいても俺は一生信じない。

運用実績は、極めて重要だ。実際に客が使って納得して信頼性って言う。
客と開発者のギャップが信頼性の欠如を生む。
よーは、開発者のテストなんて客からしたら気休めさ。

建築、機械、電気・・・・いろんなものになぞられてソフトウェアは
とらえられてきたが、結局のところ「ソフトはソフト」でしかないと思う。

ソフトは、極めて人間くさくて、泥臭い、だから厄介だと俺は思う。

客観的手法や統計で何とかなると本気で考えている奴を否定はしないが
俺はあんまり関心がない。

491 ：80：2008/08/10(日) 21:28:23 .net

統計とか客観的な事実とかを突き詰めるのにすげー金使っても、
結局、プロジェクト内の「過労で疲れた技術者のミスの積み重ね」で
大バグは埋め込まれる。

100万件のテストケースを、休日返上でテスターにやらせたとしたらどうなる？
テストケースがいくら素晴らしくても、「疲れ切ったテスターの判断ミス」
で、バグは見過ごされる。

人間系を見直さないとだめだと俺は思っている。で、テスト自動化に
取り組んだってわけだ。少なくとも、テスターや開発者に対する
負担は減った。彼らに余裕ができた。良い仕事ができるようになり始めた。

テスト自動化による副次的効果の方が、重要なのかもしれん。

492 ：仕様書無しさん：2008/08/10(日) 21:29:35 .net

自動化されたテスト環境にもBUGはあるよｗｗｗ

493 ：80：2008/08/10(日) 21:32:19 .net

テストを重視して、ただでさえ疲れ切った技術者にさらに仕事を
積む。そーやって、現場をさらに混乱に陥れる。

部分最適化だけじゃだめだ。バグを見つけた奴には給料を倍払うとか
しないとな。

技術者は、常に理屈で何とかなると思っている、何か良い手法があると
考えている。ただ、その手法を実行する人の振る舞いについては関心がない。

494 ：80：2008/08/10(日) 21:34:17 .net

>>492
開発者が楽して結果的にバグがあるのと
開発者が死ぬ気でテストしてバグがあるのでは意味が違う。

テスト自動化で手の空いた技術者が、自動テストで取りきれなかった
バグを取る。

テスト自動化だけをやってるわけじゃない。

495 ：仕様書無しさん：2008/08/10(日) 21:35:21 .net

テスト環境をテストするのに同じだけ人と金がかかるんだよぉ♪

496 ：仕様書無しさん：2008/08/10(日) 21:36:10 .net

どうしてこう次から次へとマ板は自己陶酔するコテが湧くのか。
>80がおじゃばならまだいいけど、別人ならこんなのが複数いると思うだけでいやだ。

497 ：80：2008/08/10(日) 21:37:59 .net

この業界の奴らは、頭は良いが、利口じゃない。
つくづくそう思う。不器用で要領が悪い。

498 ：80：2008/08/10(日) 21:41:38 .net

>>496
おじゃばって誰のことかわからない。

おまえは「おじゃば」のファンなのか？なら、「おじゃば」のいるスレに行け。
俺はお前の相手をしてやれない。

499 ：仕様書無しさん：2008/08/10(日) 21:44:30 .net

難しい事を書くから頭の悪い >>496 が嫉妬してるんだろｗ
ほっときゃいい。

500 ：仕様書無しさん：2008/08/10(日) 22:31:15 .net

>>464
HAYST法はヘイスト法だよ
秋山さんは意外とマンガ好きなんだ

501 ：仕様書無しさん：2008/08/10(日) 23:30:52 .net

>>490
＞よーは、開発者のテストなんて客からしたら気休めさ。

お前自身は何がどうなったら「製品として出荷できる品質だろう」と判断するんだ？
客に対して何かを証明するのでなく、開発側の判断基準はどこにある？

KKDで何となくやって期限が来たらリリース。
潜在してるバグはクレーム来てから直せば良いや。
とそういうことかい？

502 ：仕様書無しさん：2008/08/10(日) 23:44:57 .net

>>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ

>>388はソフトウェアの信頼性を定義したぞ。そして、俺自身の中で>>388の主張に腑が落ちた。

503 ：仕様書無しさん：2008/08/10(日) 23:52:23 .net

90人が作成したコードを、実装内容も知らない、実装言語にも詳しくないようなテスター10人が
効率のよい品質の高いテストができるのだとすると、どう考えてもそれを各プログラマが実行
したほうが、より効率のよい品質の高いテストができる気がする。

504 ：仕様書無しさん：2008/08/11(月) 23:50:38 .net

>>503
プログラマは自分のプログラムには異常に寛容なので、無理です。

505 ：仕様書無しさん：2008/08/12(火) 06:39:29 .net

>>503
それも完全じゃないんよね
PGが仕様を把握してないとダメやし

506 ：仕様書無しさん：2008/08/12(火) 13:53:17 .net

ホワイトボックス、グレーボックス、ブラックボックス
どれがテストとして質が高いかなんて話に意味あるの？

それぞれに目的が違うんだから比べてもしょうがないと思うんだけど。

507 ：仕様書無しさん：2008/08/12(火) 14:31:51 .net

グレーって初めて聞いたよ

508 ：仕様書無しさん：2008/08/13(水) 03:50:17 .net

http://www5f.biglobe.ne.jp/~h-it/mlcont/mc0269.htm
>>507たまにはぐぐろうな

509 ：仕様書無しさん：2008/08/13(水) 10:49:09 .net

>>508
thx
ただ、現場で聞かないなー、と思ったんだ

510 ：80：2008/08/16(土) 08:02:49 .net

>>502
>今日初めて見たが、みんな何か勘違いしてないか？
>テストで信頼性は上げられない、テストは
>「このプログラムにはバグがあるます」を実証するもので
>バグを沢山検出したからと言って、そのプログラムには
>もうバグが存在しないと言う実証にはならない。
>実際は逆で、統計的に見るとバグ密度の多いプログラムほど
>残りの潜在バグが多く含まれている。

テストはバグを発見するためのもだけじゃない。これはプログラマーの視点
だな。

テストはむしろ、要求したとおりに動作するか？が重要だ。
テストにパスすれば、そのシナリオ（操作手順）で、少なくとも
動作するという事を証明できる。

目的を見失った状態で、統計とか客観的な手法とかを持ち出すから
本質を見失う。統計は手段。バグ発見は、テスト結果。
ちゃんと整理した方がいいぞ。

テストの目的は、要求を満たしているかどうかを確認すること。

511 ：仕様書無しさん：2008/08/16(土) 19:50:07 .net

>>80はユニットテストを重視も軽視もしてないと言ってたが、
もしかして重視してるんだけどただ>>80だけがそれを理解していないんでは？

512 ：仕様書無しさん：2008/08/16(土) 20:45:36 .net

もだけ？

513 ：511：2008/08/16(土) 21:19:04 .net

>>511は　>>80の会社は重視してるけど　ってことね。

514 ：80：2008/08/16(土) 22:56:34 .net

>>511
ユニットテスト（単体テスト）は当たり前。軽視も重視もしていない。
重視したところで精度が上がるわけでもない。プログラマーの能力に依存
するからな。

プログラマーは忙しい。プログラマーに負担を増やしても全体的に品質が
落ちる。

ユニットテストを強化して効果が出るかどうかはその組織しだい。
俺は、限定的だと考えている。

プログラマーは均質ではない。
分析能力のある者、観察能力のあるも者、創造力のある者、忍耐力のある者
十人十色だと思う。分析能力や創造力はあっても観察能力がない奴も居る。
チーム開発は、各人の能力を補完し合って結果を出すものだと思うがな。

ごちゃごちゃ言わずに、優秀なプログラマーを金で雇ってきて、
自由にやってもらう方が結果が出たりもする。

515 ：仕様書無しさん：2008/08/16(土) 23:39:43 .net

重視・軽視 って言葉の基準があいまいだな。
ユニットテストだけを特別重視しているわけではない。くらいの意味合いかな？

516 ：仕様書無しさん：2008/08/16(土) 23:44:02 .net

>>515
特別重視しているわけではないってのも十分曖昧だと思うがな。
重視とか軽視とかは、相対的なもので基準を云々言うこと自体ナンセンス。
よーは、515が馬鹿だってこと。

517 ：仕様書無しさん：2008/08/16(土) 23:56:02 .net

相対的なものだからこそ、基準をはっきりさせろってことだろ。
他のテストと比べてユニットテストだけってことじゃん。

518 ：仕様書無しさん：2008/08/17(日) 00:09:50 .net

>>517
いくら頑張ってもお前の言ってることも80の言ってることも
曖昧なんだよ。お前らがテストをしても品質は上がらねーよ。

ということで終わり。

519 ：仕様書無しさん：2008/08/17(日) 00:27:10 .net

>>1
３割方終わった風な顔で、「コーディング終わりました。後はテストするだけです。」
これなら満足なのか？

520 ：仕様書無しさん：2008/08/17(日) 00:36:04 .net

プログラマーより身分の低いテスターが愚痴を言ってるだけだろ。

521 ：仕様書無しさん：2008/08/17(日) 00:44:24 .net

>>1
おれが言いたかったことを、代弁してくれて
心からありがとう( ´v｀)

522 ：仕様書無しさん：2008/08/17(日) 01:32:59 .net

>>519
そりゃどんな顔なんだよ

523 ：仕様書無しさん：2008/08/17(日) 02:12:09 .net

この業界に20年以上いるが、グレーボックステストなんて言葉初めて聞いた
そんなのがあるんだ

524 ：仕様書無しさん：2008/08/17(日) 02:38:38 .net

>>523
あるかどうかグレーです

525 ：仕様書無しさん：2008/08/17(日) 08:14:37 .net

>>523
みんなが勝手に名前を付けているだけで何が正しいとかはないと思うな。

526 ：仕様書無しさん：2008/08/17(日) 09:03:09 .net

ブラックホールテスト

527 ：80：2008/08/17(日) 09:41:22 .net

モデルベーステスト
非モデルベーステスト
モンキーテスト（アドホックテスト）
静的テスト
動的テスト
単体テスト
結合テスト
システム・テスト
受入テスト
回帰テスト

機能テスト／機能網羅テスト
パフォーマンス・テスト
負荷テスト
障害テスト
セキュリティ・テスト

色々あるな。でもな。分類とかしてる時点で間違いの方向に行ってる
気がする。バグは細部に潜んでることが多い。これらの分類にすべての
バグが綺麗にあてはまらないから「想定外のバグ」が出荷後に問題になる。

528 ：仕様書無しさん：2008/08/17(日) 10:07:05 .net

bp = malloc(sizeof(Buff *));
これはどのテストで検知するべきバグだろね？

529 ：仕様書無しさん：2008/08/17(日) 11:30:29 .net

その手続きを持つ関数の単体テスト

530 ：仕様書無しさん：2008/08/17(日) 11:47:12 .net

じゃ東証は･･･

531 ：仕様書無しさん：2008/08/17(日) 11:54:56 .net

テストに関していえばtestabilityとかが末端まで広まる前のコードだった

532 ：仕様書無しさん：2008/08/17(日) 13:02:29 .net

>>527
でかいシステムの場合、分類しないとテストの目的がはっきりしなくなるのよ

533 ：仕様書無しさん：2008/08/17(日) 13:03:25 .net

>>528
ソースコードレビュー

534 ：仕様書無しさん：2008/08/17(日) 18:37:00 .net

>>527
例えば、パフォーマンステストとか負荷テストとかは所謂バグつぶし目的じゃない気がするが。

ていうかちゃんと分類されてないとまともにテストできないだろ・・・

535 ：仕様書無しさん：2008/08/17(日) 19:05:50 .net

おじゃばにそんなこと言っても無理

536 ：80：2008/08/17(日) 21:41:00 .net

いや、いたって普通に分類してテストしてるよ。でもバグが減らないから
今やっているやり方が間違っているのかな？って考えているところさ。
よーは、学術的なアプローチに限界を感じてるんよ。

>>527
どのテストも、バグ潰しを目的としているわけではない。
バグ潰しは、デバッグでやるものだ。

> bp = malloc(sizeof(Buff *));
この手のバグは、デバッグの時にみつけるべきもの。
うちでは、Purifyとか使ってるけどね。

メモリリークチェックやメモリフットプリント、関数プロファイリング
などはツールでやるのが効率的だと思う。

537 ：仕様書無しさん：2008/08/17(日) 22:05:10 .net

529に１票
malloc()に渡すパラメータのサイズをチェックすべき

"デバッグ時"なんて、動作させて妙な状況が発生しないかぎりチェックしようが無いよ...

538 ：仕様書無しさん：2008/08/17(日) 22:06:36 .net

>>536
>うちでは、Purifyとか使ってるけどね。
I社の製品使うんだｗ

>この手のバグは、デバッグの時にみつけるべきもの。
デバッグの意味分かってるか、アホだろうｗ

539 ：仕様書無しさん：2008/08/17(日) 22:25:01 .net

ググってみた。

デバッグ
　コンピュータプログラムの誤り(「バグ」と呼ばれる)を探し、
　取り除くこと。

テストでは、バグを取り除くことはしないので、>>534 の言う
「バグ潰し」は、話の流れ的におかしい。

540 ：80：2008/08/17(日) 22:27:13 .net

> bp = malloc(sizeof(Buff *));
> これはどのテストで検知するべきバグだろね？
このコードを書いたプログラマーの採用試験に一票。

541 ：仕様書無しさん：2008/08/17(日) 22:29:32 .net

軽視するわけじゃないけど、GUIのテストってむずくね？
どうすればいいんだぜ

542 ：仕様書無しさん：2008/08/17(日) 22:47:02 .net

>>540
その採用試験に
>この手のバグは、デバッグの時にみつけるべきもの。
と回答したら、その人は合格するか？

543 ：仕様書無しさん：2008/08/17(日) 23:49:45 .net

>>539
安価ミス？

544 ：仕様書無しさん：2008/08/18(月) 01:22:44 .net

偽物が湧いてるんじゃね？

545 ：仕様書無しさん：2008/08/18(月) 09:11:25 .net

>>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ

546 ：仕様書無しさん：2008/08/18(月) 15:12:15 .net

>>536
＞いや、いたって普通に分類してテストしてるよ。でもバグが減らないから
＞今やっているやり方が間違っているのかな？って考えているところさ。
＞よーは、学術的なアプローチに限界を感じてるんよ。

学術的アプローチが何か知らないけど、単にテスト設計がショボいだけじゃね？

とりあえず、ITとSTの命令網羅率と条件網羅率は幾つよ？
網羅率も出してないなら、テスト仕様の質をどういう「学術的アプローチ」で出してみたんだ？
（網羅率が全てじゃないと思うが、うちのテストの評価では基本的な指標の1つとしてるので）

テスト仕様の質を評価してなかったら、
たとえどんな(学術的な？)手法でテスト結果を評価してみても意味無いぞ。

547 ：仕様書無しさん：2008/08/18(月) 22:12:36 .net

>>545
おじゃばは都合の悪いことはスルーデフォ

548 ：仕様書無しさん：2008/08/19(火) 11:25:08 .net

お前ら楽しそうだな、システム組むってやっぱ分業してナンボだよな
一人で設計して一人で組んで一人でテストしてデバッグする俺ってなんなんだろう
こんなんでいいシステムが組めるわけないよな。何が少数精鋭だよ
社長はそんなもん一人で出来るとか言ってるが、アンタ自身が一人でやったことないだろ
自分でやったこともない事を人に押し付けるなっつーの。ホント意味わかんねーな。どーよこれ

549 ：仕様書無しさん：2008/08/19(火) 11:28:19 .net

俺も、一人で設計して一人で組んで一人でテストしてデバッグする俺。

550 ：仕様書無しさん：2008/08/19(火) 12:57:02 .net

自分からテスト専門です、って宣言してる派遣テスターって何なの？

将来プログラマとかSEになりたい、とかならわかるけど。
向上心ないよね、頑固だし。
そういう派遣テスターって、仕様書は読めない、
テスト仕様書も作れない、テストプログラムも作れない
やれることは「テキトーにプログラムを触る」ことだけ。

俺は派遣プだけどさ、こういう派遣テスターがいると
派遣全体がバカにされるんだよ。
テスト専門派遣なんて氏んで欲しいよ、まったく。

今日も正社員の人が派遣テスターに仕様書を読んで
テスト仕様書を作ってください、って説教してたよ。
その派遣は頑固に「何故、仕様書が必要なんですか？」って
反論してたから、きっとテスト専門派遣テスターだな。
仕様書も読まず、テスト仕様書も作らず、ただテキトーに
プログラム触るだけで給料もらおうなんて頭おかしいんじゃねーの？

あ〜あ、あの派遣テスターが3ヵ月後に切られるまで、
仕様書も読まねーでテキトーにテストしたバグ票がまわってくんのかよ。
そんな糞なもん、読んで処理する派遣プの身にもなってくれよ。
うわ〜、しかもそいつが切られる3ヵ月以内に中間納品あるじゃねーか！
テスト仕様書もなしにテキトーにテストして納品か。
中間納品後にソッコウクレームでデスマ必至だな。俺の休みも返上かよ。

派遣専門テスターさんよ、少しは向上心持てよ！
頑固な性格直して仕様書読めよ！テスト仕様書作れよ！

551 ：仕様書無しさん：2008/08/19(火) 13:12:01 .net

長い

552 ：仕様書無しさん：2008/08/19(火) 14:00:38 .net

>>550
低レベルな話だなあ

そんなバカ派遣テスターなんか契約終了を待たずにに切ればすむ話だろ

正社員がテスト仕様書を書くように指示をだしているのに反抗しているんだから
即日クビでもなんの問題もないよ

553 ：仕様書無しさん：2008/08/19(火) 14:39:18 .net

>>551-552
>>550 はコピペだよ

554 ：仕様書無しさん：2008/08/19(火) 15:00:16 .net

【頑固】派遣テスターの人格問題【向上心ゼロ】
http://pc11.2ch.net/test/read.cgi/prog/1207581904/

555 ：仕様書無しさん：2008/08/21(木) 22:15:55 .net

まずはテストの工数を軽視する者どもをなんとかしないとな

556 ：仕様書無しさん：2008/08/24(日) 19:39:07 .net

急に80が来なくなったな

557 ：仕様書無しさん：2008/08/26(火) 10:28:36 .net

おじゃばはOOスレに戻りました

558 ：仕様書無しさん：2008/08/26(火) 11:31:38 .net

相変わらず羞恥心の欠片もないんだな

559 ：80：2008/08/27(水) 09:48:30 .net

>>556
お久しぶり。さすがに、２ちゃんばっかやってるわけじゃないし・・・。

近頃のプログラマーも「未経験者歓迎！」で採用されたど素人が
平気で派遣でやってくる時代だからな。テスターにプロ意識を
強要しても無駄。

金だけ欲しいなら、テスターになっていっぱい残業したらいいわけで。
リリースしたものにバグがあったらプログラマーの責任って言い張れば
良いわけで・・・。

テストを軽視するな！とか理屈でごちゃごちゃ言っても仕方ないと思うんよ。
重視しても仕事は楽にならないし給料が増えるわけじゃないし。。。
結局、テスターは頑張らないよ。プログラマーだってテストする十分な時間
ないしね。

俺は、そういう人たちを管理してたりしてるんだけど。
人数が多いプロジェクトでは、1/3は頑張るけど1/3の人はさぼる。

全員優秀なチームは存在しない。予算も潤沢に無い。
仕事のやり方をそのままにすれば、何かを重視し何かを軽視せざるを得ない。
となると、テストがどうしても軽視されてしまう。
仕事のやり方を変えるのは、製品開発より難しい・・・。
このジレンマからのがれる方法はないものかねぇ。

560 ：仕様書無しさん：2008/08/27(水) 22:31:38 .net

>>559
残りの1/3は？

561 ：80：2008/08/28(木) 23:30:31 .net

以下を参照のこと

働きアリの法則
2-8の法則
2-6-2の法則
パレートの法則

562 ：仕様書無しさん：2008/08/28(木) 23:38:18 .net

未経験者歓迎で入ったド素人コーダーだけど単体テストだけは念入りにやってるよ
というか馬鹿だからテストから書かないとコードが書けない罠ｗ
人より手間かけてる分作業の速度は遅くなるけど多分省いても大して速くならんとも思う

563 ：仕様書無しさん：2008/08/29(金) 00:08:58 .net

>>562
単体を大事にするその気持ちが大事なのです

　　　　　　　　　　　　　　　　　　　　　　　　みつぬ

いつかみんなに認められるよ、その努力は

564 ：80：2008/08/30(土) 07:58:58 .net

優秀なプログラマーを確保できないプロジェクトチームでは、
テストを重視しているのかもしれないなぁ。
プログラミング能力ってすぐに向上しないから、テストくらい
ちゃんとしろよってことなのかな。

565 ：仕様書無しさん：2008/08/30(土) 08:42:24 .net

そういえば俺も初めてのプロジェクトではまずテスト書くのから始めたなあ。
まあそれは勉強の意味合いがほぼ100%だったけど。

566 ：仕様書無しさん：2008/08/30(土) 09:50:27 .net

事務より簡単で誰でもできる仕事なのに時給は技術者！
ITテスターで稼ぐための情報を交換しましょう。

☆派遣先は大企業じゃないと駄目です。中小だとテスターもプログラムの仕様が
　わからないといけないとかテストプログラムを書けとか言われちゃいますよ。
　大企業ならプログラムを触るだけのテスターでも大丈夫。

☆派遣先ではテスターはプログラムを触るだけでいい、
　そんな空気を作っていきましょう。仕様書読んでください、
　とか言われたら「なんでテスターが仕様書読むんですか」って食い下がって。
　プログラムの仕様書を読んだり、テストの仕様書を書いたりするのは大変ですよ。

☆普通にプログラムを触ってテストしてると、何をテストしているのかわからない、
　とか言い出す人、いるんですよ。プログラマとかってこういう人多いです。
　そういう人は上司にあることないこと告げ口して追い出しちゃいましょ。
　人事権のある人とは仲良くしておくことが大切。
　
☆納品して何かあったら大変だからとプログラムの仕様書を読んだり、
　テスト仕様書を書いちゃうテスターがいますけど、
　こっちもやることになるからすごく迷惑。
　テスト結果の責任は担当の正社員にありますよね。
　納品後のクレームは最終チェックを怠った正社員が悪いんだから
　派遣は関係ないです。　

567 ：仕様書無しさん：2008/08/30(土) 10:57:01 .net

>>559
＞このジレンマからのがれる方法はないものかねぇ。

軽視して良い工程なんて開発に存在しない。

十分な金と期間を客から引っ張って、ちゃんと人をアサイン出来ない
営業と管理層が悪い風にしか見えないが。
改善すんのはソコからでしょ。

「何かを重視し何かを軽視せざるを得ない。 」と管理している自分が言う状況なら、
出だしから「これは無理じゃね？」っていう開発期間で仕事を受けてるってことでしょ？

1/3サボるのが分かってるなら、2/3で出来るスケジュールで受けろよ。
何そんな意味無い数字書いてんだ。

＞近頃のプログラマーも「未経験者歓迎！」で採用されたど素人が
＞平気で派遣でやってくる時代だからな。テスターにプロ意識を
＞強要しても無駄。

なら派遣使うなよ。

568 ：80：2008/08/30(土) 17:38:42 .net

>>567

>軽視して良い工程なんて開発に存在しない。
正論だけどね。そこを一歩踏み込んで考えないと実践では通用しないよ。

昔は「設計」「実装」が重視されていた。プログラマーのスキルと
モチベーションが高かったから、それで、結構うまくいっていた。
単体テストは、当たり前だったから特に話題にもならなかった。

でも、今では、ソフト技術者は3Kで「不人気」となり優秀な技術者は別の
業界へ流れて行く。インド、中国、ロシアの安いソフト労働力の台頭も
追い討ちをかけている。

日本のプログラマーのレベルは、以前からするとずいぶん下がった。

そもそも、「単体テストを重視する」という事自体が、俺からすると
滑稽なんよ。「うんこしたら手を洗う」くらい当たり前のことを
ワザワザ言わなくてはいけない時代になったのが残念だな。

言わなきゃ出来ないレベルの低い奴に、言って分かると思うか？
出来るやつは、言わなくてもやるもんだ。

単体テストをしないプログラマーにいくらプレッシャーを与えても
良い結果は得られないよ。それなら、仕事のやり方を工夫する方が
よっぽどましさ。

569 ：仕様書無しさん：2008/08/30(土) 19:34:30 .net

>とか言われたら「なんでテスターが仕様書読むんですか」って食い下がって。
食い下がる以前に正社員に逆らったらクビだろｗ

570 ：仕様書無しさん：2008/08/30(土) 20:22:54 .net

>正社員に逆らったらクビだろｗ
>正社員に逆らったらクビだろｗ
>正社員に逆らったらクビだろｗ

バカ？

571 ：仕様書無しさん：2008/09/02(火) 00:33:04 .net

>>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ

572 ：８０：2008/09/02(火) 00:41:51 .net

>>571
さみしいんだねｗ

573 ：仕様書無しさん：2008/09/02(火) 00:51:25 .net

おじゃばくさい返しだな

574 ：仕様書無しさん：2008/09/02(火) 10:28:46 .net

>>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ

575 ：仕様書無しさん：2008/09/05(金) 01:57:40 .net

テスターって気楽でいいよね。
自分のバグじゃないし、動かしてダメダメ言っておけばOKみたいな感じ。

576 ：仕様書無しさん：2008/09/05(金) 19:17:53 .net

その代わり、実装周りの人間が帰った夕方から、
その日の更新分含めたテストやってたりして、
夜間シフト状態になってたりした事あったけどｗ

577 ：仕様書無しさん：2008/09/06(土) 00:27:24 .net

>>575
嫌われるのが仕事だからｗ
プログラマーは絶対にバグを出す。
悪いのはプログラマー。

>>576
プログラマーは24時間労働がデフォ。
夜間シフトは、金儲けにうってつけ。

578 ：仕様書無しさん：2008/09/06(土) 00:29:40 .net

まだやってんのか・・・糞スレはsageでやれ

579 ：仕様書無しさん：2008/09/06(土) 01:20:26 .net

おまえもな

580 ：仕様書無しさん：2008/09/06(土) 18:46:21 .net

お前2chは初めてか？
力抜けよ

581 ：仕様書無しさん：2008/09/07(日) 07:59:03 .net

おまえもな。

582 ：仕様書無しさん：2008/09/07(日) 08:24:02 .net

私見だがテスターって基地外な奴のほうが優秀だと思う。
・常識では思いつかないような操作をする。
・人の話を聞かない。（話で誤魔化すことができない）
・理解力が無い。（おのずとヘルプ等を細かくしてしまう）
・集団の中で浮いてる。（無駄話をせず黙々と作業）

開発としては関わりたくないのだけど、
客観的に考えると良い製品ができるような気がする。

583 ：仕様書無しさん：2008/09/07(日) 10:48:23 .net

変わり者くらいにしておけよ
基地外が適している仕事なんかねえよｗ

584 ：仕様書無しさん：2008/09/07(日) 15:13:20 .net

本物の基地外と接した事が無いからそんな事言ってるんだと思うけど。
先ず、仕事として何かをやらせる事自体が無理。

585 ：仕様書無しさん：2008/09/07(日) 15:49:24 .net

>先ず、仕事として何かをやらせる事自体が無理。
それは派遣テスターも一緒だろ
「まず仕様書を読んでテスト仕様書を作れ」と仕事の指示を出しても
まったく手も足も出ないバカばっか

586 ：仕様書無しさん：2008/09/07(日) 16:05:00 .net

それは契約で仕事の範囲をちゃんと決めてないんじゃないか？

テストオペレータとして雇ってるのか、
テスト設計からやる技術者として雇ってるのか、
はっきりしない限りはなんとも言えない。

587 ：仕様書無しさん：2008/09/07(日) 16:11:13 .net

>>586
つ「作業内容：テスト一式」

588 ：仕様書無しさん：2008/09/07(日) 16:26:21 .net

オペレートしかテスターなんてイラネ

589 ：仕様書無しさん：2008/09/07(日) 19:32:30 .net

>>588
おまいのようなケアレスミスの多いマにはテスターは必要だろｗ

590 ：仕様書無しさん：2008/09/07(日) 19:37:50 .net

逆に適当に触るだけのテスターじゃケアレスミス位しか発見できんな

591 ：仕様書無しさん：2008/09/07(日) 23:45:37 .net

仕様策定の段階からテスターと一緒にレビューしてる人いるの？

592 ：仕様書無しさん：2008/09/09(火) 18:12:48 .net

>>585
派遣テスターで、テスト仕様書から作れるヤツなんて使ったことねーけど
流石にテスト仕様は、仕様策定した連中が書くでしょ
要求仕様わかってない連中にテスト仕様書かせてどうすんのさ

593 ：仕様書無しさん：2008/09/09(火) 20:16:18 .net

なんのために仕様書があるんだよ

594 ：仕様書無しさん：2008/09/09(火) 22:11:37 .net

>>593
お客さんに古紙回収してもらうため

595 ：仕様書無しさん：2008/09/10(水) 00:59:36 .net

>>592
典型的な底辺低賃金会社の発想だな

596 ：仕様書無しさん：2008/09/10(水) 18:03:45 .net

俺の名前をテストデータに使うなバカ上司
俺は全然タッチしてないシステムなのに
マジで頭おかしいだろ

597 ：仕様書無しさん：2008/09/10(水) 18:24:38 .net

>>591
ちゃんとやってる所は必ずと言っていい程参加させてるね。
テスト設計者を

598 ：仕様書無しさん：2008/09/10(水) 21:07:59 .net

>>596
名前覚えて貰ってるんなら結構なことではござらぬか

599 ：仕様書無しさん：2008/09/10(水) 23:11:39 .net

画面見て結合テスト仕様書つくってください
って同僚がベンダさんに言ってた

何をテストするんだろういったい

600 ：仕様書無しさん：2008/09/10(水) 23:52:49 .net

要求される「品質」にも拠るんだよな。

100万単位の人間が使うようなブツなら、テストは万単位でガッツリやらんとヤバいことになる。
万単位のテストをやるなら、まず8割9割のテストは自動化しないと何ともならんわ。
で、コードを修正したら一度自動テストを回す感じ。
理想としては、テスト設計書の概要はWordとかでもいいんだけど、詳細設計はExcelとかでマクロ組んで
テストデータを自動で吐いてくれるような感じにする。

業務系の仕事とかで、客とねんごろって世界なら、テストが適当でも何とかなる場合がある。
DBのデータが�d�jみたいなのさえ出なければ、まああとは酒の場の寝技。
こういうのを技術者とは言わんけど、それが通じる世界もあるんで。
ただ、業務系だけだね、これが通る世界は。

601 ：仕様書無しさん：2008/09/11(木) 01:05:05 .net

>>390
「クリーンルーム」じゃね？
徹底的に個々のコードレビューをやるって奴。
IN入れてOUTの結果が期待通りか否かを見る、って方式じゃなくて、
コードのロジックに誤りがあるかないかをプロが検査するって感じか。

OpenBSDはそういう手法だと聞いたことはある。

602 ：仕様書無しさん：2008/09/11(木) 01:21:31 .net

>>601
プロの定義がおかしい希ガス

603 ：仕様書無しさん：2008/09/11(木) 13:35:53 .net

>>598
テストしながら「(俺の名前)がおかしい」ってブツブツ言ってるんよ
呼び捨てで

普段からそういう人間だってのは知ってたが、
そういう嫌がらせされたのは初めてだ

604 ：仕様書無しさん：2008/09/11(木) 16:34:05 .net

>>603
名前にダメ文字入ってるんじゃね？　「十」とか。

ダメ文字チェックなら「図『表』」「『能』力」「『十』番」あたりを使えば
いいだけなんだけどさ。

605 ：仕様書無しさん：2008/09/27(土) 22:11:07 .net

>>1
コーディングが終わってやっと３割終わったかどうかってところだろが。

てことはさ、テストファーストでテストコードを書き終われば
本体のコードは進捗ゼロでも７割終わったと言っておｋ？

606 ：仕様書無しさん：2008/09/27(土) 22:40:13 .net

テストで初めて発覚した仕様の洩れを、いまさら作り込めと言われて、最近鬱。

607 ：仕様書無しさん：2008/09/30(火) 01:03:30 .net

>>605
テストファーストはテストコードだけを
最初にコーディングするものでは無い訳だが？

言葉ばっかり一人歩きすると勘違いする奴が多くて困る

608 ：仕様書無しさん：2008/09/30(火) 06:12:10 .net

そもそも本体コードをテストしないことには終わらんだろw

609 ：仕様書無しさん：2008/09/30(火) 06:44:53 .net

派遣テスターによるいい加減なテストが衰退しつつある

610 ：仕様書無しさん：2008/09/30(火) 13:04:12 .net

テストを一切せずにリリースする国産MMORPGもあるのにな

611 ：仕様書無しさん：2008/09/30(火) 13:39:47 .net

ファイナルファンタジーXIの話はもういいから・・・
あれは試験ゼロにすることで経費浮かして利益あげてるんだよ。

612 ：仕様書無しさん：2008/09/30(火) 14:37:05 .net

それにしても、実装してない機能のバージョンアップしました報告はすごかったよなww >FF11

613 ：仕様書無しさん：2008/09/30(火) 15:22:15 .net

某銀行合併時もATMとかちゃんとテストしてなかったぽいしね

614 ：仕様書無しさん：2008/09/30(火) 16:30:39 .net

>>611-612
これか・・・すげぇな。アップデート項目チェックとかしてないんだろうか？
ゲーム開発って楽そう。

ttp://www.playonline.com/ff11/polnews/news12783.shtml

>■一部アイテムのアイコングラフィックが変更されたお知らせに
>　おいて、実装されていないアイテムが一覧に含まれておりました。
>　脳汁／狡賢い脳汁／幸せの人参汁／まろやかな鳥汁／濁った血汁

615 ：仕様書無しさん：2008/09/30(火) 17:13:52 .net

>>605
それだとまだテストコードのテストが7割残っているから、
実は全体の7割の3割、つまり2割強しか終わってないんだな。

616 ：仕様書無しさん：2008/09/30(火) 17:23:26 .net

テストコードの正しさはテストしながら検証されていくという、
テスト結果がNGなら、テストか実装かどっちかが間違っているわけ
だから。全部OKになった時点で実装とテストの信憑性もあがるけど、
これで安心できるかどうかは、テストの網羅性にもよるわな。
あと間違った実装を間違ったテストに通してOKになる可能性もなき
にしもあらずだな。

617 ：仕様書無しさん：2008/10/02(木) 23:21:01 .net

テストの正しさを検証するのはテストのレビューじゃねの？
うちじゃやるけど、他んとこじゃあんまりテストのレビューってやんないのかね。

618 ：仕様書無しさん：2008/10/03(金) 01:29:41 .net

>>617
書類に関するレビューは必ずやる。
それがソースコードでもテスト検査書でも同じ事。

619 ：仕様書無しさん：2008/10/03(金) 01:53:34 .net

>>618
休暇届もやるのか・・・・

ムチャクチャNG出されそうだ･･･・・

620 ：仕様書無しさん：2008/10/03(金) 01:59:14 .net

>>619
ああ、休暇届に不備があってプログラムに不具合が出るならやるさ。

621 ：仕様書無しさん：2008/10/03(金) 08:10:34 .net

この日確かレビューだったよね？よってNG。

とかか。

622 ：仕様書無しさん：2008/10/03(金) 09:23:34 .net

>>618
俺の前の会社は「テスト検査書なんかいらないんだ！テストというものはどんどん触るのが仕事なんだ！」
という社長の方針でレビュー以前にテスト検査書が存在しなかったけどね。

まあ、結局倒産して社長一家は行方不明だがｗ

623 ：仕様書無しさん：2008/10/03(金) 09:46:04 .net

俺的にはまず全体できに荒くテストしてから
細かいところをテストするのがいいと思う。

624 ：仕様書無しさん：2008/10/03(金) 13:26:55 .net

テスト検査書の正しさは誰が検証するんだ

625 ：仕様書無しさん：2008/10/03(金) 22:37:27 .net

SQA部門とコレまでに改善されてきた(はずの)システムが検証する。

626 ：仕様書無しさん：2008/10/04(土) 18:01:37 .net

テスタがプログラマからテスト仕様書を貰えると思ってる時点でおかしい。

折れの職場はこうだからバグが減らない。
んで営業がキレる。折れのせいじゃねえよ。構造的欠陥だ。

627 ：仕様書無しさん：2008/10/04(土) 18:09:53 .net

テスト仕様をプログラムから起こしちゃあ、プログラムの正当性が判断できないよね。
そりゃそうだ。
テスト仕様はシステム設計書やシステム仕様書から起こす物だよな。

628 ：仕様書無しさん：2008/10/04(土) 18:15:27 .net

>>623だけが素人くさいな

629 ：仕様書無しさん：2008/10/05(日) 00:15:15 .net

項目Aを実行する　テスト内容Aの結果が○○になる
項目Bを実行する　テスト内容Bの結果が○○になる
...

これをテスト仕様書とかいってももってくる35ぐらいのおっさん
いるんだけど、テスト軽視とかのれべるじゃねーよｗ

630 ：仕様書無しさん：2008/10/05(日) 00:42:27 .net

>>629 その人に、それ1回やってみましたか？って言ってみたらどうかな。

631 ：仕様書無しさん：2008/10/05(日) 03:35:07 .net

UTが内部設計、Itaが外部設計、STが要件定義書のテストだよね？

632 ：仕様書無しさん：2008/10/05(日) 04:55:09 .net

仕様書書いたあとに仕様書からテスト紙を起こす
そのあとコーディング
こっちの方が絶対バグが減る

633 ：仕様書無しさん：2008/10/05(日) 05:05:40 .net

>>632
設計はどのタイミングで

634 ：仕様書無しさん：2008/10/05(日) 05:08:09 .net

>>633
用件定義はどのタイミングで

635 ：仕様書無しさん：2008/10/05(日) 05:21:49 .net

>>634
契約金額はどのタイミングで

636 ：仕様書無しさん：2008/10/05(日) 10:23:33 .net

>>631
ItaとかItbってIBMかなんかの方言だったような

637 ：仕様書無しさん：2008/10/05(日) 10:29:50 .net

省略表現とか横文字を無意味に乱発する奴は
折れはあまり好きじゃないな。

日本語で適切な表現があれば、最初からそれを使えば
沢山の人に読んでもらえる。

638 ：仕様書無しさん：2008/10/06(月) 10:34:19 .net

>>629
ファイナルファンタジーXIスタッフ乙

639 ：仕様書無しさん：2008/10/06(月) 20:24:24 .net

>>582
その基地外に関わる奴のストレスを考えたら大変なものだろうな。
うちの優秀な人間を潰されたくないからそー言う奴は使わない方が無難。

下請けに基地外が紛れ込んでる分にはOKだが、失敗したら賠償請求するよ？

640 ：仕様書無しさん：2008/11/02(日) 23:55:58 .net

ソニー系列で仕事した人に聞きたいんだけど、
ソニーって、ぜんっぜんテストしてなくね？
俺の部署の上司が元ソニーなんだが、テスト工数を全く見込んでくれない。
PS3のファームバージョンアップにも、
ちょっと動かせばわからないバグが平気で仕込まれてるし

641 ：仕様書無しさん：2008/11/02(日) 23:56:31 .net

×ちょっと動かせばわからない
○ちょっと動かせばわかるような

642 ：仕様書無しさん：2008/11/03(月) 00:02:50 .net

テストしてないは言い過ぎ

643 ：仕様書無しさん：2008/11/03(月) 00:25:07 .net

テストしていない＝検仕無しでプログラムが動けばOKとしている

644 ：仕様書無しさん：2008/11/03(月) 02:38:18 .net

ソフトウェアが存在しない時代からあった古い会社ではありがち

645 ：仕様書無しさん：2008/11/03(月) 02:49:53 .net

>>644
そういうテストをしていると会社自体が存在不可能になり、
消滅していくので、実際にはほとんどない

たとえなんとか存在できても結局受託じゃ
瑕疵保証で採算が合わず、社員は毎日他人に会社に出勤してるｗ

646 ：仕様書無しさん：2008/11/03(月) 17:36:40 .net

S◯NYってソフト関係は丸投げしてるでしょ？
日立系あたりに。
そっちでテストはしてるんじゃねえの？

647 ：仕様書無しさん：2008/11/03(月) 17:53:59 .net

>>646
目立から関連情報システムに○投げしてるよｗ

648 ：仕様書無しさん：2008/11/04(火) 08:39:51 .net

で、勉強するのにおぬぬめの本はあるの？
何かスクール的なのとか行けって？

649 ：仕様書無しさん：2008/11/04(火) 23:46:45 .net

実戦＆実践あるのみじゃね？

650 ：仕様書無しさん：2008/11/05(水) 00:16:02 .net

本は自分で見て選ぶ
スクールは基本的に金の無駄
ただし、時間を金で買うなら、物によっては選択肢に入れても良い

651 ：仕様書無しさん：2008/11/05(水) 00:24:50 .net

仕様書どおりのテストをするのが仕事。＞つまらん
いやらしい境界条件や設定条件を組み合わせて、バグを見つけるのが趣味な俺。

652 ：仕様書無しさん：2008/11/05(水) 00:56:25 .net

>>651
至って正常だから安心しろ。
変態的なバグ出しだと、動作中にコンセント抜くとか平気でやるからw

653 ：仕様書無しさん：2008/11/05(水) 01:15:40 .net

>>652
フォールトトレラントシステムでは準正常系試験かとｗ

654 ：仕様書無しさん：2008/11/05(水) 17:11:49 .net

カスSEが書いた試験書通りに試験するよりも、
ベテランPGがランダム試験したほうが効率的にバグ出せるよな。
でもそれを認めて生かしてるテストプロセスって世界的に見ても存在しないような。
日本人の職人技をプロセスとして体系的に確立することは出来ないんだろうな

655 ：仕様書無しさん：2008/11/05(水) 20:54:27 .net

JCBカード決済に障害

656 ：仕様書無しさん：2008/11/05(水) 22:25:50 .net

>>654
バグ取りとしてはその方が効率いいんだろうけど
客へのテスト実施内容報告としては愚鈍なやつが書いたような
単に全U/Iに同じことするような網羅系テストの結果資料が
絶対必要なんだよな・・・

特に最近に品管きどり連中はうるさい

657 ：648：2008/11/05(水) 23:25:57 .net

亀だが>>649 >>650�dｸｽ。

意識改革やってみるわ。燃えてきた。
俺をテストしてやるっ！！

658 ：仕様書無しさん：2008/11/07(金) 01:36:55 .net

>>656
同意。
泳がせとくだけで勝手にバグ見つけるテスタって居る。
しかし、クライアントへの提出物として程々網羅率の高い項目書って要る。

で、ランダムテストでバグが出てからその手順を項目書に織り込むなんて
アホらしいこともやらざるをえないことがあるよ。

659 ：仕様書無しさん：2008/11/08(土) 00:36:54 .net

>>658
テスト項目にない内容が不具合票にあがってるぞ！
とかつっこむ品管とかもう、巣へ(・∀・)ｶｴﾚ!!と・・・

660 ：仕様書無しさん：2008/11/08(土) 01:14:05 .net

>>659
客先からバグの報告が来ると
テスタは何やってんだ、とか言い出すんだろ？

661 ：仕様書無しさん：2008/11/08(土) 01:28:27 .net

最初からザル試験書なんだろ。

662 ：仕様書無しさん：2008/11/09(日) 16:25:12 .net

>>654
ランダムテストのほうがバグが出るってw

そりゃ単にテスト仕様が低レベルなんだよw

お前の会社、年収500万前後で頭打ちだろw

663 ：仕様書無しさん：2008/11/09(日) 16:28:42 .net

テスターで1000万超えてるやつっている？

664 ：仕様書無しさん：2008/11/10(月) 00:28:19 .net

常に悲愴感
自分のチームを守りたいのは分かるけど
最後まで人の話を聞いてくれ

665 ：仕様書無しさん：2008/11/10(月) 00:37:21 .net

ニートにバグ１個３００円でやらせろ

666 ：仕様書無しさん：2008/11/27(木) 23:26:08 .net

SEが試験書なんて作らずにテストコードを直接書けばいいのに
仕様→試験書→テストコードなんて伝言ゲームみたな事なんかありえん
で、上に提出する書類はテストコードから自動生成すればいい
どうせ碌に読まないんだからBDD用フレームワーク使って書いたテストから
辞書をチューンしたコリャ英和とmecabを使って生成してバレないだろうし

667 ：仕様書無しさん：2008/11/27(木) 23:48:58 .net

SEが違えばテストコードも違うんだなこれが
それだと上に提出する書類はSEの数だけシナリオができて
支離滅裂な文章の羅列になっちゃう

668 ：仕様書無しさん：2008/12/06(土) 03:46:41 .net

SEの書く試験書なんて、

○○機能テスト・・・○○機能が正しく動く
△△機能テスト・・・△△機能が正しく動く
××機能テスト・・・××機能が正しく動く

こんなもんですから。

669 ：仕様書無しさん：2008/12/06(土) 12:11:27 .net

SEXXテストか

670 ：仕様書無しさん：2008/12/06(土) 12:38:13 .net

SEXとは
SEがX(ﾊﾞﾂ=ｲﾗﾈ)という意味ですか

671 ：仕様書無しさん：2008/12/06(土) 13:07:00 .net

境界テストとか、異常値テストとかしないの？

672 ：仕様書無しさん：2008/12/06(土) 13:27:43 .net

運用開始後テストの為のテストですよ。

673 ：仕様書無しさん：2008/12/06(土) 13:33:30 .net

検収でこのSEﾂｶｴﾈということです。

674 ：仕様書無しさん：2008/12/08(月) 18:09:09 .net

>>666
上でExcelとpowerpointいじくってるだけのクズが、
開発で使う言語でテストケース書くとか、出来るわけないし

要求しても、VBAでよく解らないコードが出てくるのが関の山ｗ

675 ：仕様書無しさん：2008/12/24(水) 20:37:58 .net

テストは軽視してはいかんぜよ

676 ：仕様書無しさん：2008/12/26(金) 00:57:13 .net

俺はあえてバグを残したままテストする時あるな。

その方が油断しないのでテストがきめ細かくなる。

677 ：仕様書無しさん：2008/12/26(金) 01:32:26 .net

最近、まともな仕様書も書けないようなのが上にいるからな
そもそも仕様書もないからユニットテストもやりにくい
ユニットテストをＰＧに強引にやらせるのはかまわんけど
項目もこっちで作らなきゃいけないのは話が違うよね？

めちゃくちゃに追加したコントロール一覧はお前が作れよ

678 ：仕様書無しさん：2008/12/26(金) 01:34:08 .net

って問題もあって開発の請負は絶対にやりたくないな
作ってやるけどそれにかかる金と時間は全部お前が出せって感じ
そうでないとやりたくない

679 ：仕様書無しさん：2008/12/26(金) 11:46:13 .net

コードが全て
仕様書とか書き物は意味なし
よってテスト不要
作ったもんを使え
…そう抜かすアホが居る。

要件を仕様として書き出して合意を得たうえでコードに起こし仕様どおりに動くことを確認するのがテスト。
バグを見つけるためのものでは無い。
あのアホにはテストはバグを見つけることとしか見えてない。

680 ：仕様書無しさん：2008/12/26(金) 12:18:04 .net

制約論理プログラミング言語とか使っている人なんだよ多分
コードが書けた時点でドメイン内で正しく動作するのが証明されている、または
コードが形式的な証明と1対1対応しているような言語
まさかalgol派生の手続型言語を使ってそんな事を言うような人はいないでしょう

681 ：仕様書無しさん：2008/12/26(金) 15:35:56 .net

仕様を紙に起こしたりされると拒絶するかバカ正直に実装する。
せめてテストで確認しようと項目を挙げるとアホかと罵る。
要するに何の制約もされずに気ままにコーディングして自己満足したいだけ。
自分仕様で実装する。
そして出来上がってから仕様が固まると我が物顔で胸張って言う。
｢すごい手戻りですね｣

682 ：仕様書無しさん：2008/12/26(金) 19:18:32 .net

ドキュメントも重要。
テストも重要。

683 ：仕様書無しさん：2008/12/26(金) 19:27:06 .net

仕様書がしっかりしてりゃＰＧ側はなんの問題もないけどね
でも、作ってみなきゃ矛盾が見えないってのもわからなくもない
でも、それを全部に責任にしようとするから戦争がおこる
仕様書ないのにこっちにテスト仕様書作らせようとか
結構キレるのわかる気がする

684 ：仕様書無しさん：2008/12/26(金) 19:29:29 .net

ユニットテストで横に全画面のコントロール
縦にチェック項目５０個ぐらいで１００００個超えるテスト作って
とても流用できないような表を作るのが俺の趣味
貼り付けて仕様書完成なんて絶対にさせない

685 ：仕様書無しさん：2008/12/26(金) 21:18:16 .net

テストの対象はコードじゃなくて仕様や要件だということ。

686 ：仕様書無しさん：2008/12/26(金) 21:50:20 .net

単体テストと結合テスト、機能テストは目的が違う。

687 ：仕様書無しさん：2008/12/26(金) 21:59:00 .net

>>685
仕様書に全コントロールの仕様が書いてあればそれも可能だけどねｗ
全角、半角、ひらがな、カタカナ、英数、少数、文字数、
最小、最大、タブ、エラーメッセージ、補正、・・・
全部かけるもんなら書いてみればいい

688 ：仕様書無しさん：2008/12/26(金) 22:18:10 .net

>>686
違うのは範囲だよ。
テストの目的はひとつ。
単体→結合→機能と分けるとするならば、
それらは通過点。

>>687
コーディングが終わる時点で仕様に抜けがあるようでは仕様書をまとめる人間もプログラマも失格。
その先を急ぐばかりに後に時間とカネを浪費する。

689 ：仕様書無しさん：2008/12/27(土) 00:16:34 .net

>>688
ちょっと俺んとこの職場きて担当者に言ってやってくれ

690 ：仕様書無しさん：2008/12/28(日) 21:37:14 .net

ちょっとスレ違いだけど、コードレビューしてたらPMが乱入してきて、
どうせテストするんだからそんな無駄なことすんな
馬鹿な働き者は何もしない馬鹿より害が大きいんだぜ
って妨害しやがった。

ちなみにそいつはプロジェクトも末期になってから思いつきで
仕様変更して、現場を混乱させる悪癖があることで有名だ。

691 ：仕様書無しさん：2008/12/28(日) 21:38:16 .net

killしろ

692 ：仕様書無しさん：2008/12/29(月) 14:30:25 .net

テストってのは、その前にちゃんとしたクオリティで作ったものが、
ちゃんと「動くこと」を確認するステージであって、
とにかく形だけそれっぽいものを作って、テストでちゃんと動かないところを
洗い出すってのは間違いだと思うんだ。

うちの会社、後者のやり方だから、もういや。

693 ：仕様書無しさん：2008/12/29(月) 20:34:16 .net

テスト自体にもいろいろステージがあると思うんだが


まあシステムテストの段階で単体テストやってるようだと大問題だが

694 ：仕様書無しさん：2008/12/30(火) 19:05:29 .net

ステージが限量されてないのが前提で

>とにかく形だけそれっぽいものを作って
スタブのことね
>テストでちゃんと動かないところを
>洗い出すってのは間違いだと思うんだ。
TDD否定ですか？
>うちの会社、後者のやり方だから
TDDを実践してる会社か、なかなかいい所じゃないの？

695 ：仕様書無しさん：2008/12/30(火) 19:18:24 .net

おまい、TDD言いたいだけちゃうんかと…

696 ：仕様書無しさん：2008/12/30(火) 22:58:40 .net

TDDってなんですか？
もちろんググったりなんかしません

697 ：仕様書無しさん：2008/12/30(火) 23:08:14 .net

Tokyo
Disney
Destroyer

698 ：仕様書無しさん：2008/12/31(水) 01:21:19 .net

>>697
通報しました

699 ：仕様書無しさん：2008/12/31(水) 11:02:57 .net

>>696
逆DDT

700 ：仕様書無しさん：2009/01/01(木) 20:22:50 .net

>>694
お前全然わかってないんだな

いや待てよ、単にネタなのか
こりゃ騙されたなｗ

701 ：仕様書無しさん：2009/01/02(金) 09:56:59 .net

なにがわかってないのか詳しく

702 ：仕様書無しさん：2009/01/02(金) 11:15:56 .net

ユニットテストって明らかに成り立つ場合でもいちいちテストケースって書かなくちゃダメなの？たとえば、引数に範囲外の数値を入れたらXXXというエラーコード返すとか。関数にそういうif文あるんだから返すに決まってると思うんだが・・・やっぱり明示的に書きます？

703 ：仕様書無しさん：2009/01/02(金) 12:05:40 .net

そういうコードができてから書くテストってあまり書く気がしないんだよね
なんというか事務的処理のような面倒臭さがある
それならば逆転の発想でコード書く前にテストを書けとか言われてるけどそれもそれで面倒だし

704 ：仕様書無しさん：2009/01/02(金) 12:30:26 .net

>>701
おれの気持ち

ってかこの業界、相手の気持ちなんて考えたらやってられねー

705 ：仕様書無しさん：2009/01/02(金) 13:15:58 .net

>>703
やっぱりすごく事務的だね。。。
実際はエラーコード返すif文が本当に書かれてるかテストで確かめるってのが正当な方法なんだよなあ。

706 ：仕様書無しさん：2009/01/02(金) 18:14:48 .net

ブラックボックス

707 ：仕様書無しさん：2009/01/02(金) 20:15:01 .net

Javadoc等の為に、コメントに仕様を丁寧に記述して…

あぁぁ・・・　ああぁぁぁああーーー…

うわぁぁああぁぁーーっっ！！！

708 ：仕様書無しさん：2009/01/03(土) 11:47:38 .net

>>707
javadocってそんな分かりやすいか？
（まあ、分かりやすいかは記述している内容次第、といわれればそれまでだけど）

昔のVBなんかで使ったhotdogを思い出してしょうがない・・・


って、>>707が叫んだのは1/02だからか？？

709 ：仕様書無しさん：2009/01/03(土) 12:19:05 .net

>>708
＞javadocってそんな分かりやすいか？

規定のフォーマットで書けば、規定の出力が出てくれるのでｳﾘｼﾞﾅﾙなものよりかは
分かりやすい。

710 ：仕様書無しさん：2009/01/03(土) 18:38:22 .net

今行ってる現場のPLがなんか勘違いしている。
コーディング8割完了って報告したら、「じゃあ単体試験は5割ぐらい完了ってことかな？」ってさ・・・
コーディング中のTry&Errorはテストではないですよ？
こいつ、40近くにもなって何を言ってるんだろうって思いました。

711 ：仕様書無しさん：2009/01/03(土) 18:46:17 .net

>>710
>コーディング中のTry&Errorはテストではないですよ
至極まっとうじゃねーかw

712 ：仕様書無しさん：2009/01/03(土) 19:19:25 .net

コーディング完了＝単体試験完了だってさ

713 ：仕様書無しさん：2009/01/03(土) 19:36:47 .net

>>712
絶対確実に100%達成は不可能だが、TDDしていれば
単体試験完了＝コーディング完了に限りなく近づくだろ

抜けたところは、結合までにテストケース追加すれば
いいだけだし。

お前が糞だってことをきちんと理解しろ、この豚野郎が

714 ：仕様書無しさん：2009/01/04(日) 01:07:01 .net

テストの本で初心者に一番良い本教えてください

715 ：仕様書無しさん：2009/01/04(日) 19:39:51 .net

>>702
書くべきだろ
実は不等号の方向間違えててっていうのがチェックできないじゃん
っていうか俺それ何度もやってるしｗ

テストデータを作るのも困難なんだよね
でも、そのデータ作ってるうちに別の問題も発覚したりするから
あながちなめたものでもないな

716 ：仕様書無しさん：2009/01/04(日) 20:09:58 .net

テスト期間はほんと面白くないね。
これを楽しくするアイデアを下さいな。

717 ：仕様書無しさん：2009/01/04(日) 20:22:55 .net

>>716
レアバグを発見したらみんなで胴上げ
経費で昼飯代を出す（カレー限定）
とか特典をつける

718 ：仕様書無しさん：2009/01/05(月) 06:03:24 .net

エロ掲示板にあるような、殿堂入り機能付き掲示板でバグを晒すとか。
殿堂入りしたバグ発見者に何か褒美やるとかw

719 ：仕様書無しさん：2009/01/06(火) 08:40:35 .net

茶番劇にまた付き合わされる俺の身にもなれ

720 ：仕様書無しさん：2009/01/06(火) 10:35:40 .net

>710
うちの40代園児ニアもまさにそれ。

何度テストの重要性とか説いても「そんなの実機で動かせばいーじゃん？」であっさり却下。
ユニットテストという単語すら知らない癖に「これ使ったらソフトの品質が上がるんだぜ！セミナーの人が言ってた。」という理由だけで
某社のテストフレームワークを買おうとしているうちの上司。。。

最近さっさとこいつら見限ったほうがいいかもと思いつつある。

721 ：仕様書無しさん：2009/01/06(火) 15:26:04 .net

>>720
>「これ使ったらソフトの品質が上がるんだぜ！セミナーの人が言ってた。」
権威に弱いだけな性向が透けて見えるね
なんという騙されやすい人間

722 ：仕様書無しさん：2009/01/06(火) 23:54:48 .net

>>720
お前はそんな糞上司使われて
成果も出せない。結局調子の言い権威的な
セミナーのおっさんにすらまける糞野郎ってことだろｗ

上司が上司なら部下も糞だｗもっと自分がアホで
糞だということを自覚しろｗ

723 ：仕様書無しさん：2009/01/11(日) 17:16:32 .net

>>716
自分が作ったものを自分でテストするとひじょーにつまらんし、モチベーションが全く上がらん
人が作ったものを、色んなパターンで試験してバグ票をバシバシ発行すると、それなりに楽しめるぞ

724 ：仕様書無しさん：2009/01/11(日) 22:06:43 .net

みんなどんなソフトに関わってるの？
俺はWebブラウザとかだけど

725 ：仕様書無しさん：2009/01/11(日) 22:23:44 .net

家電全般

726 ：仕様書無しさん：2009/01/11(日) 22:37:30 .net

POSあぷりとか

727 ：仕様書無しさん：2009/01/12(月) 00:25:55 .net

Webアプリ関係と
FAX関係（ファーム寄りじゃなくて通信より）
あとはDBクライアントアプリ（VB）とかをちょぼちょぼ

728 ：仕様書無しさん：2009/01/24(土) 15:12:41 .net

スパムジェネレータはwebアプリって言ってもいいのかなぁ

729 ：仕様書無しさん：2009/11/10(火) 11:16:51 ?2BP(0).net

テスト

730 ：仕様書無しさん：2010/05/08(土) 21:43:30 .net

ユニットテストで中途半端なテスト書いて満足してるゴミは死ね

731 ：仕様書無しさん：2010/05/09(日) 08:50:02 .net

たしかに、どんな簡単なコード(たった一行)でも
そこから予想もしなかった事態が引き起こされることはある(あった)
テストを怠るとえらい目にあう

732 ：仕様書無しさん：2010/06/03(木) 00:08:09 .net

テストは開発だね。

もうテストなしの開発なんて考えられないよ。

733 ：仕様書無しさん：2010/06/06(日) 22:02:27 .net

半端にプログラミングが上手くなるとテストサボるようになるな。

734 ：仕様書無しさん：2010/06/06(日) 23:04:51 .net

単体テストは手間がかかる上に、楽しくないんだよな

735 ：仕様書無しさん：2010/07/25(日) 20:58:29 .net

テストしたくないから開発したくない
中途半端な開発しかしたこと無いやつに限って、開発楽しいじゃん〜とか言って
技術系ぶるから腹立つ

736 ：仕様書無しさん：2010/07/25(日) 21:29:54 .net

仕事したくないから出社したくない
中途半端に残業しかしたこと無いやつに限って、仕事楽しいじゃん〜とか言って
社会人ぶるから腹立つ

737 ：仕様書無しさん：2010/07/25(日) 22:40:35 .net

テストはつまらん
なんでハード屋はどんどん楽になるのに
ソフト屋はコード量が増えてるんだ

738 ：仕様書無しさん：2010/07/31(土) 15:04:51 .net

それはお前が減らす努力をしないからだ。

739 ：仕様書無しさん：2010/08/05(木) 00:04:56 .net

仕様を把握し理解できてる人間ならテストする箇所は絞れるだろ
デスマで儲けてるクズ専業テスターとかはしょーもない項目までテスト対象にしてしまうけど
彼らが提出するテスト仕様書は項目の水増しが酷すぎる

740 ：仕様書無しさん：2010/08/05(木) 00:07:54 .net

だがその水増し部分をテストしなかったら
文句言うんだろう？

741 ：仕様書無しさん：2010/08/05(木) 20:14:46 .net

核心をついてないテストで鬼の首をとったように騒ぐのは
時間がない時には止めてほしい

742 ：仕様書無しさん：2010/08/06(金) 04:05:16 .net

いや、時間がある時でも止めてほしい

743 ：仕様書無しさん：2010/08/06(金) 06:55:27 .net

とれたのは鬼の首ではなくてＰＧのやる気

744 ：仕様書無しさん：2010/08/06(金) 07:52:13 .net

製品仕様的にそこは絶対に通らないって所をつついて悦に浸る

745 ：仕様書無しさん：2010/08/06(金) 13:16:41 .net

カバレッジは通せよｗ

746 ：仕様書無しさん：2010/08/06(金) 14:11:24 .net

動けばいいんだよ

747 ：仕様書無しさん：2010/08/06(金) 18:34:12 .net

いいわけないだろ？ほんとにテストしたのか！

・・・で最初からテストを全部やり直し

748 ：仕様書無しさん：2010/08/07(土) 01:03:42 .net

動けばいいんだよ。

ただ要求が、365日24時間不具合無しで、期待するパフォーマンスが得られるって
条件だけどな。 金も時間も全然よこさないのに要求だけは高いからな。

749 ：仕様書無しさん：2010/09/11(土) 22:55:32 .net

そら要求は高く出すに決まってるだろｗ
そこで工数見積もれずに見栄張るから後で悲惨なことになる

750 ：仕様書無しさん：2010/09/17(金) 23:47:30 .net

テスターの地位は向上させるべきだと思うよ。
オレはテスター歴１５年のベテランだけど、
実際問題、テスターの方がプログラマーより数段上。
プログラマーはニートやヒッキー、学生でもできるが、
テスターはスキルと常識のある社会人にしか勤まらない。
しかも、テスターは高い知識が求められる一方、プログラマーは
ルンペンにもできるし、ルンペンっぽいプログラマーも多数存在してる。
なのに、プログラマーは自分達がＳＥの次に偉いとか、
プライドだけは一人前。だから使えない。
オレらテスターのおかげでシステムが成り立っているのにね！

751 ：仕様書無しさん：2010/09/18(土) 01:31:54 .net

そうだね

752 ：仕様書無しさん：2010/09/18(土) 10:43:58 .net

test

753 ：仕様書無しさん：2010/09/18(土) 10:47:10 .net

TestComplete

754 ：仕様書無しさん：2010/09/18(土) 11:35:15 .net

正直なところ、昨今（というか昔からだが）の
「テスト偏重主義」には食傷気味。

「テストで品質を担保する」という考えは
ブスがゴテゴテの厚化粧をして男の目を誤魔化そうとするのと同じで
根本的に好きになれない。
・・・実際、やっている事といえば検収時に
客の目を誤魔化しているようなもんだし。

いや、言い直そう。テストが悪いのではなくて
修正が必要となった時に「修正の影響範囲を小さくする」事を優先し、
その結果、小手先の修正しかさせない文化が嫌なのかも
（その根本にある考え方が「テスト偏重主義」な訳だが）。
何だよ？「再テストが大変だから修正するな」って。
そんなに「テスト結果」って偉いのか？
100回の試行結果が合格だったとしても、101回目に失敗しない事を
「テスト結果」は保証してくれるのか？

実際、そういう修正を積み重ねた結果「良いシステムが出来た」という例を
見たことある奴いるか？

755 ：仕様書無しさん：2010/09/18(土) 12:59:46 .net

>>754
マジレスするとお前はテストの基本的なことがわかってない
的外れなことを言っているから、ちゃんと勉強したほうが良い。

ヒントをやると、テストの自動化について調べて来い。

756 ：仕様書無しさん：2010/09/18(土) 14:22:03 .net

>>755
>マジレスするとお前はテストの基本的なことがわかってない
確かに！　まさに仰るとおり。
俺も「テストはこうあるべき」みたいな方法論や技法については、
色々調べたつもりだが、でも結局分からなかった。
どうやったら分かるようになるだろう？
もう殆ど悟りの域だね。不立文字、教外別伝。

いや、正直「俺が分かる」必要すら無くて、結局のところ、
現場がテストを「神」のように持ち上げなくなれば良いだけなんだが。
（俺の経験上「プログラミングはなぁ、テストに始まりテストに終わるんだよ」と
いう奴のコードは「動けば良いジャン」的なものになっている確率が高いので）

そんなコードであっても、最終的には複数の人間が
廻り持ちでメンテするようになる訳。
そんなのが自分に廻ってきてしまった日には、
もう気分は「ババ抜き」とか「黒ひげ危機一髪」をやっている感じ。

757 ：仕様書無しさん：2010/09/18(土) 14:53:57 .net

お前の周りにいる奴がテストをわかってないんじゃ、
お前がわからんのも仕方ないなｗ

758 ：仕様書無しさん：2010/09/18(土) 14:59:55 .net

>>754 テストを通過した商品でも
問題があれば全部テスタではなく設計者の責任になる

そんなテスタは要らない

759 ：仕様書無しさん：2010/09/18(土) 15:02:32 .net

>>755 ここはマ板なんだから、さくっと答え(もしくはお前の意見)を
3行で書けよ。書けないから煽ってるのかと疑う。

760 ：仕様書無しさん：2010/09/18(土) 15:03:25 .net

書いてるだろ。自動化テストと。

761 ：仕様書無しさん：2010/09/18(土) 15:05:45 .net

>758
テストはすべての仕様を
完全に熟知しているとでも？

762 ：仕様書無しさん：2010/09/18(土) 15:57:11 .net

>>760
>書いてるだろ。自動化テストと。

そういえば昔、父ちゃんが
「将来 "自動翻訳システム" が出来るから、
お前は英語なんか勉強しなくてもいいんだよ」
って言ってくれたっけ。

まだかなぁ・・・

763 ：仕様書無しさん：2010/09/18(土) 16:47:48 .net

>>761 テストはやることに意味があるのではなくて
欠陥を未然に防ぐことに意味があるんではなくて？

節穴テストなら何もしてないのと同じ

764 ：仕様書無しさん：2010/09/18(土) 16:59:45 .net

テストそのものが嫌っつーか
クライアントを納得させるための
馬鹿みたいに着飾ったエビデンスを作るのが
死ぬほど嫌だ

765 ：仕様書無しさん：2010/09/18(土) 17:10:03 .net

つい元の状態を撮り忘れたまま直しちゃったら
直す前に戻して撮ったり
直す前の状態をコラして捏造するんだぜ
アホくさいよね

もちろん撮り忘れたのがアホなんだが

766 ：仕様書無しさん：2010/09/18(土) 17:22:35 .net

>>763
>節穴テストなら何もしてないのと同じ

多分、何か変なもの(口だけ達者な先輩とか)に
影響されてそうなってしまったんだと思うけど。

これ、知ってる？
自動車のエアバッグとか落下傘とかさ、
本当に人命に関わる装置でも、
実際は「完全なテスト」なんてやっていないんだよ？
（実際問題、テストしたら使えなくなるし・・・）

そういうパラノイア的な態度って、
逃げの戦術としてはそれなりに有効だけどさ
（特にお馬鹿な客の場合、逆に
「さすが○○さん。プロフェッショナルだね！」
なんて褒めてくれるかもしれないしね）、
でも、本気で信じちゃ駄目でしょ。

767 ：仕様書無しさん：2010/09/18(土) 17:56:44 .net

>>766 意味がわかりません。

>実際は「完全なテスト」なんてやっていないんだよ

人間乗せて追突する試験をしてないってこと？
それとも製品を出荷する前に作動させてないってこと？

768 ：仕様書無しさん：2010/09/18(土) 17:56:55 .net

>>756
ソフトのメンテ系の仕事なんて全部ババだろ。

日本のサラリーマンは誰もテストが神なんて思っとらん。
品管とか検収のチェックを通らんからそこにこだわるだけだ。
そもそもその人種には「品質が良いものを作ろう」
とか本気で考えてる奴は居ない。
で、そういう人種がほとんどだ。

それを何とかしたいなら、出世するなり独立するなりして
しきる立場に行くのが一番早いと思う。

769 ：仕様書無しさん：2010/09/18(土) 18:44:01 .net

>>767
出荷する製品自体でテストはできないってことじゃね？

770 ：仕様書無しさん：2010/09/18(土) 18:44:31 .net

それは当たり前かと

771 ：仕様書無しさん：2010/09/18(土) 23:10:42 .net

世の中の食品は
全部食べて調べてるんだぞ。

772 ：仕様書無しさん：2010/09/19(日) 00:39:26 .net

問題が出てない時期、対象は抜き取り検査だよ。

773 ：仕様書無しさん：2010/09/19(日) 02:03:12 .net

>>762
テストの自動化という言葉が
誤解を招くものだと思うけどね。

でも、自動翻訳とは自動の意味が違うのを
知らないから、この業界におけるテストというものを
わかってないといわれるんだよ

774 ：仕様書無しさん：2010/09/19(日) 06:12:25 .net

自動化テストって何よJUNITみたいなものか？

775 ：仕様書無しさん：2010/09/19(日) 16:00:08 .net

この場合の自動化テスト＝ファイル更新時に自動でテストを走らせること
開発マシンでファイル編集時、バージョン管理のサーバーにコミット時、デプロイ時などのことでは？

776 ：仕様書無しさん：2010/09/22(水) 21:48:32 .net

>>774
多分、他システムとの結合テストの際に担当者間で交わす
「おはようございます。今日はよろしくお願いします」
なんていう挨拶まで自動化してくれるんじゃないかな？

777 ：仕様書無しさん：2010/09/22(水) 23:13:51 .net

ジョークのつもりなのかもしれんが面白くない。

778 ：仕様書無しさん：2010/09/27(月) 16:16:30 .net

テストとかする奴って何なの？
バカなの？
死ぬの？
そんなくだらない事やってる暇あったらコード書けやクズ！


って先輩が言ってますた

779 ：仕様書無しさん：2010/09/27(月) 23:18:45 .net

>>778
その先輩、今すぐクビにしないとその会社来年には無くなってるぞw

780 ：仕様書無しさん：2010/09/28(火) 06:22:39 .net

「テストは空いている時間にやれ　時間が無い？　残業しろよ」


そいつは、残業の時間が長い＝やる気があって立派、と考えるタイプ

781 ：仕様書無しさん：2010/10/02(土) 20:31:14 .net

バグなく作り上げてやっとコーディング完了なわけだが、
コーディングした後テストするとか意味が分からん。

782 ：仕様書無しさん：2010/10/02(土) 20:46:09 .net

>>781
バグが無くなったってどう証明するの？

783 ：仕様書無しさん：2010/10/02(土) 20:52:51 .net

>>782
自己申告w

784 ：仕様書無しさん：2010/10/02(土) 22:43:13 .net

単体テストは時間がないからできないと言うやつに限って、単純なコーディングミスレベルのバグを乱発して時間を無駄にする。
結果として単体テストで必要であったろう工数の数倍以上の工数が無駄になる。
単体テストをしたからってバグが０になるわけじゃないが、単体テストでみつかるはずのバグを結合以降のテストで見つけると修正コストは数倍から数十倍になるからな。

785 ：仕様書無しさん：2010/10/02(土) 23:37:38 .net

あからさまなバカがいるな
こんなのがいるから単体レベルのテストデータまで納品させられるんだよ
どうせ理解できる奴なんかいないのに

786 ：仕様書無しさん：2010/10/03(日) 00:35:17 .net

>>781
開発プロセスについてもう少し勉強した方がいい。
特にプロセス定義について辺り。

787 ：仕様書無しさん：2010/10/03(日) 06:59:34 .net

>>785
>どうせ理解出来る奴なんかいない

おいおい、どんだけ自分が天才だと思い込んでるんだ？
こういう馬鹿が一番手の付け用が無いなw

788 ：仕様書無しさん：2010/10/03(日) 08:00:01 .net

単体テストの結果なんて出したら会社がつぶれる
コーディング規約もコードレビューもしてない(それだけの能力のある同僚上司がいない)
ことがバレる

789 ：仕様書無しさん：2010/10/03(日) 09:29:34 .net

そんな底辺会社ベースで語られても・・・。

まぁ単体テストを納品するかは契約内容によって
ケースバイケースとしか言えんだろ。

790 ：仕様書無しさん：2010/10/03(日) 09:34:15 .net

まああれだよ
テストを軽視してるＰＧがいるのは確かだよ。
>>1は設計やコーディングと同じようにテストも重要だよっていうことを
いいたいんだと思うよ

791 ：仕様書無しさん：2010/10/03(日) 12:03:09 .net

テストをプログラマに丸投げしてる時点で意味がない。

792 ：仕様書無しさん：2010/10/03(日) 12:20:09 .net

だな。
コーディングの工数とテストの工数が事前に区別されてなくて、
コーディングした人間がコーディングの工数の中でテストケース作って、テストやって、テスト仕様書もエビデンスも出す必要なし、で
それがバグだらけだったとして「テストを軽視したのは誰か」って話で

793 ：仕様書無しさん：2010/10/03(日) 12:41:07 .net

もしテスト結果を偽造したとしよう
その場合に上司や会社は責任をとるんだろうか
最初にプログラマを絞め上げるのは目に見えてるけど

製品に責任を感じるなら
プログラマの給料をあげること
中間搾取してるカスを全員クビにすること
ちゃんとマネジメントしろ

日本は上が「私がわるかった御免なさい」と言ったのを
見たことがないんだが。部下の尻拭いで辞職します
なんてのは責任とったことにならねーよ。

794 ：仕様書無しさん：2010/10/03(日) 13:56:39 .net

ケータイがAndroidに移行してから、SE/PGから
テスターになった人が多いから、こんなスレが
繁盛するんだろうね。

でも、テスターは素人の女の子でもできる仕事だよ。
真実から目を背けてはダメだよ。

795 ：仕様書無しさん：2010/10/03(日) 14:09:28 .net

>>794
>テスターは素人の女の子でもできる

おいおい、ランダムテストしかしないのかお前はw
テスト仕様書を作れない素人なんて何千人雇っても品質向上につながらねえだろw

796 ：仕様書無しさん：2010/10/03(日) 15:12:27 .net

>>795
エクセルを使えればできる簡単なお仕事ｗ

スキル身に付かず、将来性ナシｗ

797 ：仕様書無しさん：2010/10/03(日) 16:08:22 .net

まっとうな開発現場なら単体テストは普通プログラムした人間がやるだろ。
テスト仕様書はＳＥが作るかもしれが。

798 ：仕様書無しさん：2010/10/03(日) 16:43:28 .net

モジュール単位でしか仕事しない人はいいだろうけど
製品の規模が小さいと商品まるごとのテストになるんだよ

テスト仕様書＝製品テスト　にすりかえられて

いつの間にか製品の責任まで負わされる。
迂闊に張り切ると命が危うい

799 ：仕様書無しさん：2010/10/03(日) 22:32:08 .net

どんなブラック企業だよw
製品の責任取るのは出荷判定にハンコ押した奴に決まってる。

800 ：仕様書無しさん：2010/10/04(月) 00:39:24 .net

うかつにはんこ押せないなあ

801 ：仕様書無しさん：2010/10/04(月) 23:10:50 .net

アップデータ配布するだけの仕事ですから無問題です。

802 ：仕様書無しさん：2010/10/06(水) 11:11:11 .net

単体テストなんか10分程で終わりますｗ

803 ：仕様書無しさん：2010/10/06(水) 16:57:17 .net

数行のプログラムで１０分はかかりすぎだｗ

804 ：仕様書無しさん：2010/10/06(水) 21:41:30 .net

>>803
たとえば、なんの事前知識もなしに
「デッカーのアルゴリズム」のソースを渡されて
いざ単体テストをやろうとした場合、
テスト項目って何件になるんだろ？

どれぐらい時間を掛けるべき？

805 ：仕様書無しさん：2010/10/06(水) 23:20:59 .net

通りすがりで知らんけど、テスト仕様作らせるなら設計仕様は出せよ。
なんでテスト仕様作成でモジュールの仕様を想像せにゃならんのだ。
明らかにおかしい。

806 ：仕様書無しさん：2010/10/06(水) 23:22:35 .net

>>805
仕様：ちゃんと排他できること。

以上。

807 ：仕様書無しさん：2010/10/07(木) 06:37:59 .net

>>796
できるよな
逆になんでできないとかいうのか聞きたいぐらい

808 ：仕様書無しさん：2010/10/07(木) 09:35:23 .net

>>806
こういう仕様書がホントにあるから笑えねぇ。
他には、正しく動くことを確認、とかな。

809 ：仕様書無しさん：2010/10/07(木) 21:32:53 .net

>>808
>こういう仕様書がホントにあるから笑えねぇ。
>他には、正しく動くことを確認、とかな。

世間一般の開発現場では、
「"正しく動くこと" って、どういう事？」という発言は許されるけど、
「"排他できる" って、どういう事？」なんて言ってしまったら、
即刻"戦力外通知"を喰らってしまうけどね。

810 ：仕様書無しさん：2010/10/07(木) 21:37:13 .net

やそうでなく、主語も無くて何をテストするのかという話

811 ：仕様書無しさん：2010/10/07(木) 21:42:49 .net

>>810
試験を行うに当たって必要なのは、
「試験対象」と「明確な合否の判断基準」だけだろ？

どうしてそんなに"主語"とやらが必要なの？

もしかして、いつも文章を書く時は
"拝啓"とか書かないと気が済まないタイプの人？

812 ：仕様書無しさん：2010/10/07(木) 22:04:59 .net

>>810
「X は Y が Z であること」みたいな言い回しの仕様書は駄目ですか？

ttp://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1012425280

813 ：仕様書無しさん：2010/10/07(木) 22:06:46 .net

>>811
おまいはマである前に国語を習い直した方がいいぞ。

主語ってのは、対象を指す言葉だ。何について書いているのか、それが文章における主語。
テスト仕様書の場合は、その対象がメモリーの特定箇所の事なのか、表示画面のどこの事なのか。

それが無くて単に排他であるとか、正しく動いているとか、そんなん言っても漠然としすぎ。

814 ：仕様書無しさん：2010/10/07(木) 22:08:15 .net

てst

815 ：仕様書無しさん：2010/10/07(木) 22:26:10 .net

>>813
>テスト仕様書の場合は、その対象がメモリーの特定箇所の事なのか、表示画面のどこの事なのか。
だから、「試しにそれを作ってみてね。項目は何件ぐらいになりますか？」と聞いているのに・・・

「試験仕様書」があれば「試験仕様書」を作れるのは、当たり前。

816 ：仕様書無しさん：2010/10/07(木) 22:27:25 .net

主語は対象ではないとおもう
いわんとすることには同意する

〜が〜という操作を与えた場合に〜というアクションを起こす

が明確でないと困るものな

817 ：仕様書無しさん：2010/10/07(木) 22:30:27 .net

>>815
ほえ？　あんた何を勘違いしてんのか知らんが、スレは１つ毎に他人が書いてるんだぞ。
何かのスレ主とは別人だから勘違いしないでくれ。

818 ：仕様書無しさん：2010/10/07(木) 22:39:02 .net

>>817
ほえ？ 何でそんなに勘違いされるのが厭なの？
勘違いされると困るような重要な主張をしたつもりだったの？
本当に厭ならば、名前を付ければ良いと思うよ。

819 ：仕様書無しさん：2010/10/07(木) 22:41:45 .net

>>818
真似スンナよ

820 ：仕様書無しさん：2010/10/07(木) 22:50:09 .net

主語霊様との対話は程々に切り上げるとして、
実際の所、この場合の試験項目って
どんな感じ（件数・内容）になるんだろう？
誰か書ける人いない？
多少の抜けや誤りががあっても良いからさ。

821 ：仕様書無しさん：2010/10/07(木) 23:23:44 .net

>>815
アホか。
最低限モジュールのI/O仕様を出せ。

単体が関数なのかクラスなのかすら分からんわksg
「ちゃんと排他出来る」ってのは
その関数をコールする排他なのか、
何かのリソースに対する排他機構なのか、
どっちだ？

排他制御を1つの関数で行うのか、
複数の関数で行うのか、どっちだ？

822 ：仕様書無しさん：2010/10/07(木) 23:37:55 .net

>>821
だから、一番最初に試験対象は
「デッカーのアルゴリズム」を実装したソースだって
言っているのだが・・・

823 ：仕様書無しさん：2010/10/07(木) 23:44:49 .net

>>822
単体テストは、
１．使用している関数の全部について、引数とその取り得る値の組み合わせで予想される結果を先に作成し、試験書１とする。
２．関数内部の分岐に着目して、分岐条件の境目での考えられる全組み合わせで予想される結果を先に作成し、試験書２とする。
３．１の試験書１に基づいて実際に動作させる。
４．２の試験書２に基づいて実際に動作させる。
５．成績を評価する。

ま、単一アルゴリズムのテストならこの辺まででいいんじゃね？

824 ：仕様書無しさん：2010/10/07(木) 23:50:12 .net

>>823
うんうん・・・
なるほどねぇ・・・

で、肝心の試験項目は？

825 ：仕様書無しさん：2010/10/07(木) 23:53:09 .net

>>824
ソースも仕様書も無しに試験項目が出せるか馬鹿たれ

826 ：仕様書無しさん：2010/10/08(金) 00:00:27 .net

>>825
なら、これで。

仕様:ちゃんと排他できること。

ソース:ttp://ja.wikipedia.org/wiki/%E3%83%87%E3%83%83%E3%82%AB%E3%83%BC%E3%81%AE%E3%82%A2%E3%83%AB%E3%82%B4%E3%83%AA%E3%82%BA%E3%83%A0

※関数の形にしたければ、適当に括弧でくくってあげてね。

827 ：仕様書無しさん：2010/10/08(金) 00:23:33 .net

>>826
あ、こういうの試験すんの結構厄介だわw
なんせ時系列に状況が変わってくんだろ？

特定の場所でそれぞれの出力が確認出来るような環境で、
どちらかの処理が動いている時にもう片方が止まっている事が確認できないとな。

簡単にやるなら、デバック用のログ吐かせたりするな。

828 ：仕様書無しさん：2010/10/08(金) 00:37:45 .net

>>826
825じゃないが。

pxをまず3つに分割するとする。
lock、クリティカルセクション、unlock。
単体テスト対象はlockとunlock。
入出力は共に外部変数。
異常な外部変数の状態についてはありえないとしてスキップ。
(仕様にないし)
項目1件でC1までカバーできるから、それで十分。
具体的にはlockでは各ループを2回以上回し
ifに入らない->入るパターンを作る。

p0のlockとunlock、p1のlockとunlock、
各1件ずつで計4件で単体テスト終了。
実際に排他出来るかどうかは結合テストの範疇。

まぁ実施だけなら5分ぐらいだな。

829 ：仕様書無しさん：2010/10/08(金) 00:48:42 .net

こうして Therac 25 の悲劇は
再び繰り返されるのであった。

830 ：仕様書無しさん：2010/10/08(金) 22:38:30 .net

>>822

> だから、一番最初に試験対象は
> 「デッカーのアルゴリズム」を実装したソースだって


デッカーのアルゴリズムって、なんでっかー？

831 ：仕様書無しさん：2010/10/09(土) 14:26:06 .net

【審議中】
　　　 ∧,,∧　 ∧,,∧
　∧ (´・ω・) (・ω・｀) ∧∧
(　´・ω)　Ｕ) ( つと ﾉ(ω・｀ )
｜　Ｕ (　　´・) (・｀　　)　と ﾉ
　ｕ-ｕ （l 　　 ) (　　　ﾉu-ｕ
　　　　 `ｕ-ｕ'.　`ｕ-u'

832 ：仕様書無しさん：2010/10/09(土) 17:20:08 .net

たしかSF作家だっけ？

833 ：仕様書無しさん：2010/10/11(月) 21:08:23 .net

結局某アルゴリズムにこだわってた奴は何が言いたかったんだ？

834 ：仕様書無しさん：2010/11/23(火) 18:56:01 .net

はぁ、なんで外注テスターってこんなに醜いんだろう。

自分でもの作りができないIT職って笑えるわ

835 ：仕様書無しさん：2010/11/23(火) 20:43:05 .net

>>834
お前の指示の出し方が悪いからじゃね？

836 ：仕様書無しさん：2010/11/24(水) 09:13:10 .net

>>1
テスター専属者を派遣する会社を作れば、儲かるんじゃね?
どうせマより給料安く済むのだから。

837 ：仕様書無しさん：2010/11/26(金) 03:10:28 .net

>>835
指示待ち前提とかうけるｗｗ

838 ：仕様書無しさん：2010/11/26(金) 09:18:28 .net

テスター後にPG入る予定だったが
テストするレベルじゃないってか出来てねぇじゃんか
テキトーに理由つけてトンズラしました

839 ：仕様書無しさん：2011/06/19(日) 02:10:07.34 .net

テストこそが一番重要だとか、テスト駆動してとかまで言わないから
せめて、鬱になってぶん投げるんなら最低限のテスト書いておいてくれ。
引き継いでも、テストなしの何千行ものコードを理解するのは厳しいよ。

840 ：仕様書無しさん：2011/07/06(水) 13:59:07.87 .net

Webで自動テストってどう思う？画面周りで嫌になるんだけど。コアなモジュールを自動テストするのはわかるが最終的に目視のほうが圧倒的に完成が早いとなると自動化する意欲が沸かない。自動化が向いてない業務を世にしらしめるのが後世のためだと思うのだが。

841 ：仕様書無しさん：2011/07/06(水) 14:01:28.53 .net

>>839
何千行とか超余裕。
へたしたら一つのメソッドの行数じゃんか。

842 ：仕様書無しさん：2011/07/06(水) 14:04:09.99 .net

>>840
UIのテストはいつでもやりづらいものだけど、だからといって、マニュアルで実行して目視が楽だからってのは
違うんじゃ無いか。
そうしなくても良いように、UIとロジックを分離させつつ、テスタビリティに気を配って設計・実装するのが今日の流儀。

843 ：840：2011/07/06(水) 14:28:24.24 .net

>>842
なんというか、自動化のアンチパターンみたいな話ってあまり聞かなくて推奨する人は100%自動化オケーってなるのが銀の弾はナイゼ理論上エネルギー保存の法則に反する危惧が、、、。

UIテストの自動化はやっぱあんまやらない、でオケー？
上流に安心して使ってもらうために中低レベルモジュールを自動テスト化するってことに注力し、人間様がIFポイントになる部分は目視を重要視するとかだとスッキリするんだけと。

844 ：仕様書無しさん：2011/07/06(水) 16:22:06.36 .net

>>843
> UIテストの自動化はやっぱあんまやらない、でオケー？

Webの自動テストの話だとすると、具体的に何をマニュアルテストでやった方が良いのか書いてくれ。
Seleniumとかは当然評価してるんだろうな？

>最終的に目視のほうが圧倒的に完成が早い

まぁ、初めて「うん、今完成した」と思える瞬間までは速いだろうけど、それ以降繰り返しテストしたり、
機能拡張したり、バグフィックスしたりするときに行うテスト工数を考えるとどう？
あと、対応するブラウザが増えたり、既存のブラウザの新バージョンで問題が無いかどうかテストしたりする工数とか。

845 ：840：2011/07/06(水) 19:24:04.91 .net

>>844
> Webの自動テストの話だとすると、具体的に何をマニュアルテストでやった方が良いのか書いてくれ。

デザインとか、結合レベルのものは期待してないよ。

意図した動的なテキストや画像が表示されているかどうか。
リンクが正しくたどれるかどうか。
ページ切替が正しく動作してるか。

とかかな。

> Seleniumとかは当然評価してるんだろうな？

してない。サンプルレベルで試したことはあるけど実務では使ったことない。
今から始める手頃なプロジェクトがあるから試してみるよ。


> 機能拡張したり、バグフィックスしたりするときに行うテスト工数を考えるとどう？

気持ちはわかるんだけど。
発注からリリースまで１〜3ヶ月とかいうプロジェクトばかりやってるせいかな。開始次期にもたつけない。
開発は8割動作を保障するまでの時間が勝負だと思ってる。品質と同じくらいスピードも大切なんだよ。

今余裕あるから色々試してしてみるわー
どうにか効率のいいやり方を見つけたいんだわ。

846 ：仕様書無しさん：2011/07/07(木) 12:43:17.94 .net

>>845
> 意図した動的なテキストや画像が表示されているかどうか。

これが、サーバ側で生成されるのか、クライアント側で生成されるのかで話はかわってくるな。

> リンクが正しくたどれるかどうか。
> ページ切替が正しく動作してるか。

これこそSelenium等の出番。

> 発注からリリースまで１〜3ヶ月とかいうプロジェクトばかりやってるせいかな。開始次期にもたつけない。

1ヶ月でリリースしてその後なんのメンテナンスもしない、というのと、
3ヶ月でリリースしてその後継続してメンテナンスするというのは大きな違いがあるが。

847 ：840：2011/07/07(木) 15:22:50.37 .net

>>846
ありがとう、頭の整理ができてきた。

なるほどね。規模が大きくて大規模のメンテが絡む場合は自動化が有効なのかな。

確かに若いころ、javaで半年150人月150kの作業を自動化なして作業組んだ時死んだわ。

ビジネスロジックをUIで自動テストするのがしんどいんでクラスに引っ込めて試験する。
UIはUIでDB、ビジネスロジックと切り離して試験できる手法ができたらいいと思わない？HTMLベースでブラウザなしで試験できそう。リンクチェックとかもできるようにして。あくまでリクエストも表示データもテスト関数で作成。

合体したときのビジネスロジック試験はサイクル的に項目が重複して無駄に思える。結合点のプログラムを別途自動化するとして残る障害は関数相互間のIF認識ミス。それを結合レベルの障害と認識してもらえるかどうかは顧客次第か。

すまん、独り言になってしまった。

単体試験=全てのコードを評価する 。と定義して結合リスクは無視。結合時の障害が気になるところだけど、低リスクで行えられればテストコードの作成コストは大幅に削減できるかな。

848 ：仕様書無しさん：2011/07/07(木) 16:57:52.68 .net

> UIはUIでDB、ビジネスロジックと切り離して試験できる手法ができたらいいと思わない？

たとえば、何かのパラメータを画面で入力して、サーバで検索してHTMLで表形式で表示するとき、
・サーバはJSONでデータを戻す
・JavascriptでJSONをパース
・さらにJavascriptでTABLEのDOMを動的に生成
とかやれば、自動テストが介入する余地がかなりある。

まぁ、サーバ側の言語の制約とか、フレームワークを使っているが故の何らかの制約とかが
ある場合は、また違うかもしれないけど。

849 ：840：2011/07/08(金) 01:33:56.35 .net

>>848
たぶんjava以外はview単体で実行させるのは難しくない。

Htmlをdomってチェックすればテストできるんじゃないかなと。
javaもjspじゃなくてvelocityとか使えばできるはず。

850 ：仕様書無しさん：2011/07/08(金) 11:00:11.97 .net

自分の環境だけで語る奴って何なの？

851 ：仕様書無しさん：2011/11/22(火) 14:24:08.46 .net

このスレタイってスクエニのゲームＢＧＭのタイトルみたいだよね

852 ：仕様書無しさん：2011/11/22(火) 18:54:04.29 .net

>>1 はプログラマじゃないことは確かだな。

土方だったら納品オサラバだし、綺麗事で飯食えるかっての。
責任ある高度な仕事を要求するなら、それなりの金払え。

853 ：仕様書無しさん：2011/11/22(火) 22:37:37.68 .net

>>852
土方だったらおさらばってことは、
>>1は土方じゃないってことにならないか？ｗ

854 ：仕様書無しさん：2011/11/23(水) 00:25:36.98 .net

テスト段階
http://www.youtube.com/watch?v=Op6B0vKC6fY

855 ：仕様書無しさん：2011/11/23(水) 01:00:37.01 .net

>>853 土方だったら、>>1みたいなこといわんだろ。

856 ：仕様書無しさん：2011/11/23(水) 15:07:53.73 .net

テストは大事だが、そこから本番てのはちょっと違うだろ
設計にミスがなきゃテストなんて穏やかに終わるもんだ

857 ：仕様書無しさん：2011/11/23(水) 16:29:49.06 .net

ミスの無い設計なんてお目にかかったことがないわ

858 ：仕様書無しさん：2011/11/23(水) 17:49:51.77 .net

うわぁ・・・

859 ：仕様書無しさん：2011/11/23(水) 18:39:36.28 .net

ミスではない。


仕様です。

860 ：仕様書無しさん：2011/11/24(木) 00:23:32.12 .net

そりゃテストしながら作ってりゃあ
コーディング終わった時点でほぼ終わりだわな

861 ：仕様書無しさん：2011/11/25(金) 09:32:08.81 .net

テストしかやらされていない奴も...。

862 ：仕様書無しさん：2012/01/20(金) 22:27:56.48 .net

ST終わって単体バグ出るとか杜撰すぎて笑えない

863 ：仕様書無しさん：2012/02/11(土) 10:38:57.07 .net

テスターをどうおもってる？

864 ：仕様書無しさん：2012/06/17(日) 12:37:14.39 .net

ずっとテスターであり続けたい

865 ：仕様書無しさん：2012/06/17(日) 18:53:25.40 .net

テスト計画書を作ろうという気持ちのないテスターとかいりません

866 ：仕様書無しさん：2012/10/10(水) 22:37:21.99 .net

SEさんにお願い

設計書の体裁にこだわるのもいいけどテストデータちゃんと作ってくれ

867 ：仕様書無しさん：2012/10/11(木) 12:40:04.94 .net

>>866
SEが本物っぽい偽データしか作らないんだったら、お前が作れ。
SEの役割は、本物のデータを入手すること。

868 ：仕様書無しさん：2012/10/29(月) 22:05:55.75 .net

テストは奥が深い

869 ：仕様書無しさん：2012/11/13(火) 08:02:24.46 .net

ユニットテストやる時間がない

870 ：仕様書無しさん：2012/11/13(火) 19:28:39.76 .net

>>862
出るもんは出る。
所詮テストなんて費用対効果での妥協の産物だよ。

871 ：仕様書無しさん：2012/11/14(水) 00:43:05.33 .net

これだけチェックして
これだけバグが出たから
品質バッチリです

という風習がいまだに理解できない

872 ：仕様書無しさん：2012/11/14(水) 02:29:53.79 .net

>>871
確率統計を理解してない人が大半だからね。　今までの蓄積してきたデータに
対して現在のプロジェクトだとこれくらいのバグが有ることが予測できます、
だったのが、いつの間にか捏造してでも予測値に実測値を当てはめて運用
するようになったから。　それを疑問に思わずに何十年も続けてるからね。

そもそも開発環境が劇的に変わっているのに、それについていけてないからね。
コードを書く以上にプロジェクト管理やら品質管理の方が変化し続けなくては
いけないのに、勉強もせずに変わろうともしないからね。

この世には3つの嘘があります、嘘、大嘘、統計ですってね。

サンプル値のとり方も、期待値の求め方もデタラメで、期待値に合うように
実測値をいじったらおかしくなるって。

873 ：仕様書無しさん：2013/01/27(日) 18:13:48.70 .net

業務系ってテストに工数かけないんだね。
組み込みだとテストに設計と同等程度の工数かけてたんでその感覚で
見積り作ったら笑われてしまった。

874 ：仕様書無しさん：2013/04/11(木) 00:02:42.82 .net

ちゃんとしたテストを知らない素人集団が多いほど軽視される
ガチガチにやる必要はないけど

875 ：仕様書無しさん：2013/12/04(水) 08:51:42.11 .net

テストが後回しにされんのは仕方ないんだろうが、適当なテストすんのは違うよね
少ない試験項目でできるだけ品質を確保すんのがテスト技術だろうに

876 ：仕様書無しさん：2013/12/05(木) 01:01:04.11 .net

>>875
項目減らすのに直交表やオールペア法とかあるけど、結局必要な絶対量ってのは
存在しているわけで、技術だなんだと言ってもどうしようもない部分があるんだけどな。

877 ：仕様書無しさん：2013/12/28(土) 18:00:38.61 .net

これ面白いけど、実用性はどうなんだろう？

コンピュータチェスの考えを応用したテスト自動化
http://www.aicp.co.jp/products/download/qtronic_silver&weaver.pdf#search='%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF%E3%83%81%E3%82%A7%E3%82%B9+%E5%AE%9F%E5%BF%9C%E7%94%A8'

シミュレーションベーステスト自動化ツールTestWeaver
http://www.aicp.co.jp/products/qtronic_testweaver.shtml

878 ：仕様書無しさん：2013/12/28(土) 18:35:39.33 .net

>>873
業務系だと異常があればすぐに人が飛んでくる
それにバッドノウハウを蓄積しやすいから
現場の人間だけでもバグ回避してだましだましやってくれる

ヘタすりゃ帳票系の出力テストぐらいしかやらないんじゃね

879 ：first123：2014/02/24(月) 16:52:34.89 .net

ちなみに単体テストを過分強調するやつはプロジェクト開発の初心者。
単なるバカ。工程という物は全然理解していません。
ただの経験ないです。
今の日本のアプリ開発は、お客様に出したUT結果は７０％以上に嘘！！！！
なぜなら完璧な単体テストと高いレベルの黒箱テストにあたる工期が日本中にはありません。

880 ：仕様書無しさん：2014/02/24(月) 22:53:36.57 .net

日本語で桶

881 ：仕様書無しさん：2014/02/25(火) 21:14:21.11 .net

>>871
そういう緩い作業で給料貰えるんなら、ある意味幸せじゃね？

882 ：仕様書無しさん：2014/03/17(月) 20:37:38.37 .net

なるべく上流でバグ発見したほうが工数は少なくて済むのは常識
だが逆に考えてみればどうだ？
下流でバグを発見したほうが工数を増やすことができる！！

883 ：仕様書無しさん：2014/03/18(火) 15:53:48.47 .net

>>882
公務員おつ。

884 ：仕様書無しさん：2014/03/19(水) 21:09:32.68 .net

ソフトウエア開発において、テストは非常に重要。

まともな開発期間を貰えない時は、馬鹿の一つ覚えのように
「これではテストの時間が足りません！」って言っておけば、
大概、スケジュールが伸びるものだ（ただし末期状態を除く）。

これ、本当の話。
こんなに便利なものは無い。まさに伝家の宝刀だよ。

885 ：仕様書無しさん：2014/03/19(水) 21:13:37.18 .net

それに対して「これでは開発期間が足りません！」だと、
なぜか絶対に認められないんだよな。

実に不思議・・・

886 ：仕様書無しさん：2014/03/19(水) 21:21:01.77 .net

テスト期間どれだけあれば完璧になるの？って聞かれると困らないか？

887 ：仕様書無しさん：2014/03/19(水) 21:30:31.81 .net

>>886
そう言わせればしめたもの。
１０年でも１００年でも、気の済むまで
上乗せすればよい。
そして「それは流石に長すぎる」言われれば
もっとしめたもの。
「では、分かりました」とそこで一旦身を引くが、
その後バグが出た時は「だって、テスト期間が・・・」
と言えばよい。

888 ：仕様書無しさん：2014/03/19(水) 21:32:22.78 .net

>>887
技術力の無いカス会社として一切仕事入ってこなくなるぞｗ

889 ：仕様書無しさん：2014/03/19(水) 21:42:17.01 .net

>>888
それが不思議な事にそうじゃないんだな・・・

テスト期間を長く取ればとる程
「品質を重視する優秀な人・会社」と見てくれる。

ブランド品も、値段が高ければ高いほど人気が出るだろ？

890 ：仕様書無しさん：2014/03/19(水) 23:42:38.10 .net

うーむ、一理あるようでないようなあるようなないような

891 ：仕様書無しさん：2014/03/30(日) 15:22:55.16 .net

見積もり時点で工数に余裕がないことがわかってるなら、足りない事を伝えておこう
足りないからテストを削ってスケジュールに収めるが、品質は悪くなることを了承させておけば
多少のバグはテスト時間の不足でごまかせる

っていうか、テストの軽視つーか、
UTとか昨今のテスト手法への理解がなさすぎる者どもが多すぎることのほうが問題だと思う
CIとかUnitテストツールとかそういうのまともに使えないレベルの奴多すぎ

892 ：仕様書無しさん：2014/04/03(木) 20:57:36.67 .net

>見積もり時点で工数に余裕がないことがわかってるなら、足りない事を伝えておこう

またまたご冗談を。
いつでも「足りていない」と言っているくせに。

>多少のバグはテスト時間の不足でごまかせる

そしてこれも"いつもの手口"。

やっぱりテスト厨ってヤラシイよ。
こういう奴を見かける度、「こいつ人間的にどうなのさ？」
って思ってしまう。

893 ：仕様書無しさん：2014/04/04(金) 08:59:07.87 .net

無理っていうスケジュールを押し通す上司って人間的にどうなのさ。
それさえ無ければ現場の人間がそんなアホな考えを持つはず無いだろ。

あ、今思い出したけど、もう4日くらい何も食べてないや。。
でも何でだかお腹が空かないんだけど、大丈夫かなあ？

894 ：仕様書無しさん：2014/04/04(金) 17:10:40.21 .net

>>892
単体テストなんかを手作業で「努力」してやる事をよしとするタイプの老害っぽい

895 ：仕様書無しさん：2014/04/04(金) 21:24:57.11 .net

>>893
>無理っていうスケジュールを押し通す上司って人間的にどうなのさ。
ならば素直に「無理」と言えばよい。

テストを重視（というか神聖視）する奴って、大概
「俺は凄いからモノなんてすぐに出来るんだけど、
テスト時間は削れないからなぁ」
みたいな態度を取るから面倒臭いんだよ。
もちろん、それに納得してしまう上司や客もダメな訳だが。

割れ鍋に綴じ蓋。お前ら勝手にやってくれ、と言いたいのだが、
全く関わらない訳にもいかない所がツライ。

>あ、今思い出したけど、もう4日くらい何も食べてないや。。
>でも何でだかお腹が空かないんだけど、大丈夫かなあ？
知るか。どんな劣悪な状況でも、４日間丸々
食事の時間が取れないなんてありえない。
仕事しながら、またはトイレの最中だって食事は出来る。
これで倒れたのであれば、それこそ自己管理が出来ていないか
または倒れることに逃げようとしてるだけだろ。

896 ：仕様書無しさん：2014/04/05(土) 23:06:49.97 .net

なんか変な人湧いてる…ｗ

897 ：仕様書無しさん：2014/04/30(水) 02:37:34.80 .net

>>895
それと、どうでもいい事に何故か噛みつかれたので、反論しておくよ。

> >あ、今思い出したけど、もう4日くらい何も食べてないや。。
> >でも何でだかお腹が空かないんだけど、大丈夫かなあ？
> 知るか。どんな劣悪な状況でも、４日間丸々
> 食事の時間が取れないなんてありえない。
> 仕事しながら、またはトイレの最中だって食事は出来る。
> これで倒れたのであれば、それこそ自己管理が出来ていないか
> または倒れることに逃げようとしてるだけだろ。

はあ。
あんたも、プロなら自己管理も仕事のうち、とか言い切っちゃうわけね？
なら言い返そう、プロなら道具や人材含めて自分が使役する対象を正常に保つのも仕事のうちだよ。
それを個々それぞれに完全に押し付けてるのであれば、マネージャーの資質はとりあえずゼロだね。
そしてこれに反論をしようとするなら、マネージャーの資質はマイナスだからマネジメントはやらない方がいい。

あとそれから、俺がメシ食ってなかったのは職場環境とまったく関係ない事とは言わないけど、
主原因じゃないから。
すべての情報が集まらないうちに判断を下すとか、あんた情報処理の仕事とか、そうでなくても
何か取りまとめする仕事とか、向いてないんじゃないの？

898 ：仕様書無しさん：2014/09/19(金) 03:55:21.27 .net

無理っていうスケジュールは大抵営業が作る側に配慮しないで仕事とってきたって時にありがち

899 ：仕様書無しさん：2015/07/14(火) 00:56:20.88 .net

設計の責任が重たくなる一方で
給料はテスターと同じってのは

全くイカれてる

900 ：仕様書無しさん：2015/10/14(水) 11:06:01.60 .net

>>899
設計がクソでテスターは尻拭いさせられるのに
設計と給料が一緒とかイカレてる

901 ：仕様書無しさん：2015/10/17(土) 07:22:19.11 .net

結合テストに全然時間を用意してない、というかしてくれない
なんで一発で100%うまくいく前提の時間しか取らないのかね
それテストじゃなくて、ただの動作確認

902 ：仕様書無しさん：2016/06/28(火) 01:52:19.20 .net

>>4
ですよねー

903 ：仕様書無しさん：2016/09/06(火) 23:00:28.26 .net

>>1
確かにあんたの言う事は一理あるとは思う。
しかし、肝心の上の連中がテストの重要性を理解していないじゃん。
いや、そもそも情報システムの重要性自体を理解してないのじゃないか？

904 ：仕様書無しさん：2016/09/21(水) 19:49:56.63 .net

>>903
理解もなにも
自分が作ってる情報システムが重要なものだとでも思ってるのか？
本当に重要なものを奴隷に任せるわけないだろ？

普段からこき使って痛めつけとかないと反乱するから
穴を掘って埋めるような無駄な仕事作って忙しくさせてるだけだよ。
仕事の進め方に不満を抱いて奴隷同士で対立してくれればしめたもんだ。

身の程を知れ

905 ：仕様書無しさん：2016/09/21(水) 20:05:33.86 .net

>>904
厨くせぇw

906 ：仕様書無しさん：2016/09/21(水) 23:07:19.18 .net

黙って何もいわずに働くのが大人です

907 ：仕様書無しさん：2016/09/28(水) 17:11:09.55 .net

なぜテスターがテスト仕様書を作るんですか？
ttp://freelance-programmer.com/test-siyousho

908 ：仕様書無しさん：2016/09/28(水) 23:56:07.47 .net

プログラマは「開発者テスト」という名前で自分の作った箇所を適当に動作させて
それをテストだと自称している
もしそれが是だとするならば、>>907の彼女が行っていることこそテストではないのか

909 ：仕様書無しさん：2016/09/29(木) 00:36:35.94 .net

仕様書程度の資料から作れるテスト項目なんてたかがしれてるし
そのレベルで不具合があれば開発した人間がヤバい

910 ：仕様書無しさん：2016/09/29(木) 00:40:00.51 .net

テストは仕様が満たされているか確認するものだよ
それ以上でも以下でもない

911 ：仕様書無しさん：2016/09/29(木) 06:13:16.27 .net

>>909
そのレベルで不具合のある製品が世の中には現実にあるからなあ
仕様書程度のテストすらしなれば>>907の最後の文章のような結末だと思うぞ

912 ：仕様書無しさん：2016/09/29(木) 22:19:20.53 .net

>>911
わかってないみたいだから、もう一度書こう

仕様書程度の資料から作れるテスト項目なんてたかがしれてる

要するに不十分ってこった
つまり開発に携わってもいない派遣にテスト仕様書を作らせるってのは希に見る阿呆

913 ：仕様書無しさん：2016/09/30(金) 00:13:52.25 .net

開発に関わっていないと「絶対に誤動作してはいけない場所」がわからない
カンが働かないからつまらないバグばかり見つけてしまう
そうじゃなくてどうしても譲れないところをテストするのであれば開発者が直接テストをしたほうがいい

ただ、それってテスト工数が足りなかったり、設計をまともにやってない（よくある）現場の話であって
設計署がないのに成果物が出来上がるのは工程のどこかがバグっている証拠

914 ：仕様書無しさん：2016/09/30(金) 04:07:42.33 .net

>>912
ホワイトボックステスティングって、知ってるか？

915 ：仕様書無しさん：2016/09/30(金) 22:12:27.97 .net

テスト仕様書なんて設計書がちゃんとしてたら誰が作っても似たようなもんになるでしょ
せいぜい手の抜き方が違うぐらいだ

916 ：仕様書無しさん：2016/09/30(金) 23:45:25.97 .net

テストだから単純に結果を確認できなきゃいけないと思って
極力ごりごりべた書きしてた
値のチェックもコードにべた書き

処理の共通化とか、値の外部化ってやっていいもんなの？

917 ：仕様書無しさん：2016/10/01(土) 00:20:39.41 .net

最初からテストを意識して書くのが正解
それを突き詰めると、最初にテストを書くのが一番楽っていう結論になる

918 ：仕様書無しさん：2016/10/28(金) 18:54:59.73 .net

>>917
テストしやすいように作るんだよ。

テスト駆動開発は小さなシステムにしか適用できない。

919 ：仕様書無しさん：2016/10/28(金) 21:21:26.87 .net

今は開発環境(たとえばVisualStudio)とかの機能が大幅に上がってやりやすいよね。

俺、基本はCで制御系、今はC#の画面系の仕事してるんだけど、C#とか楽だわ〜。
ちょろっと機能組み込む→動かす→あ、判定間違えてたｗ→直す→動かす→おｋ
なんていう流れでコーディングと単体試験がほぼ同時にこなせちゃう。

元となる機能組み込んで単体の単体動作確認までやっちまえば、
それを元にコピペ＆ちょろっと修正で流用した機能もほぼ単体試験おｋで出来上がっちゃうｗ
(もちろん作ったところは動かして確認するよｗ)

もちろん、単体試験は別途行うけど、判定間違えとかのバグはほぼ出ない。
別にナメているわけでも、ケンカ売っているわけでもなく、素直な感想です。

結合試験以降のバグは...アレ半分は設計バグだからｗ

920 ：仕様書無しさん：2016/10/29(土) 00:33:15.52 .net

>>919
もっと簡潔に話せや

921 ：仕様書無しさん：2016/10/29(土) 03:53:37.77 .net

>>919
それテストじゃないから。

922 ：仕様書無しさん：2016/10/29(土) 03:55:16.69 .net

>>919
というよりCだからうんぬんって話が不明。

923 ：仕様書無しさん：2016/10/29(土) 07:45:27.63 .net

制御からこの業界に入った奴が作る画面系って
コードも、設計も、あらゆる部分が崩壊してる
自社の一部の人間だけが使うものならいいけどとても客に出せるレベルじゃない

924 ：仕様書無しさん：2016/10/30(日) 20:27:20.73 .net

>>923
制御系の輩が作る画面形の具体的な崩壊例を教えてください。
そうならないようなコツもあれば教えてください。

925 ：仕様書無しさん：2016/10/30(日) 20:33:51.45 .net

>>924
他人が使うことが想定されてない系の不具合が異常に多い

926 ：仕様書無しさん：2016/10/30(日) 20:35:38.93 .net

要するに利用者が限定されてる物作りをしやがる
不特定多数の数百万人が利用することを想定して作っているのが
業務系Web系の開発者

927 ：仕様書無しさん：2016/10/30(日) 20:38:22.97 .net

利用者が限定されている×
利用者と使い方が限定されている○

928 ：仕様書無しさん：2016/10/30(日) 21:01:10.12 .net

>>924
即答してやったんだから礼くらい言えよ

929 ：仕様書無しさん：2016/10/30(日) 21:06:36.18 .net

>>928
具体的な例がない回答ありがとうございました。

930 ：仕様書無しさん：2016/10/30(日) 21:07:40.25 .net

>>928
そうならないようなコツもない回答ありがとうございました。

931 ：仕様書無しさん：2016/10/30(日) 21:08:26.18 .net

>>929
＞利用者と使い方が限定されている
これが具体的じゃなかったら、なんだ、実際の画面でも貼れってのか？

932 ：仕様書無しさん：2016/10/30(日) 21:09:40.32 .net

>>930
＞利用者と使い方が限定されている
利用者と使い方を限定しない物作りをしろってことだろ
制御屋ってバカ？

933 ：仕様書無しさん：2016/10/30(日) 23:14:10.36 .net

試験項目「不特定多数の数百万人が利用することを想定してあること」
結果：OK
ｗ

934 ：仕様書無しさん：2016/10/30(日) 23:23:02.87 .net

試験項目「利用者と使い方が限定されていないこと」
結果：NG（´・ω・｀）

935 ：仕様書無しさん：2016/10/31(月) 23:06:04.04 .net

必要なときにテスト用の機材がないわ
テストしたいのに場所も時間も制限付けられるわ
テストゼロで客先納入に向かう羽目になりながら
よく不具合が出なかったなと思う

その後は仕様追加だの仕様変更だのバタバタバタバタ慌ただしく来て
テストも糞もないほど杜撰で、トラブル頻発したが

936 ：仕様書無しさん：2017/06/12(月) 06:34:48.76 .net

・・・

937 ：仕様書無しさん：2017/12/21(木) 06:42:27.05 .net

完成したものの精査・テストをお願いしないで
詳しい進捗報告もなくガッツリ取説を作っちゃうのが最近のやり方なの？

938 ：仕様書無しさん：2017/12/21(木) 06:48:57.82 .net

というより、凝りすぎないようにとは言っても
これを完成と見切るには考えが甘過ぎるというか
あまりにも不完全すぎると思うんだが

939 ：仕様書無しさん：2017/12/29(金) 21:08:30.59 .net

誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒　『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。

グーグル検索⇒『宮本のゴウリエセレレ』

60D1K0A92F

940 ：仕様書無しさん：2018/05/22(火) 13:59:04.99 .net

とても簡単な自宅で稼げる方法
参考までに書いておきます
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

5A147

941 ：仕様書無しさん：2019/03/14(木) 15:23:35.06 .net

実装するたびに動確とるからバグゼロ
テストやるだけ無駄な時間を費やす

よくいるのは動確もせずにどんどん組んでいく奴な
あれは酷いわ、テストで動かしたら全く動かないなんてザラ

お前はうんこした後にすぐ拭かないタイプだろ
うんこついたままズボン履いて出かけるタイプな

942 ：仕様書無しさん：2020/01/04(土) 09:11:21.30 .net

話題のＪＳＴＱＢみてきた

なんかつらつらと持論が書いてあるが
具体的になにするのか一切わからん
なんじゃこりゃ