テストを軽視する者ども

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

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

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

この馬鹿者どもが。

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

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

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

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

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

テストが仕様書

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

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

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

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

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

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

上流工程こそ最重要だよ

テスト？やって当然だろ

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

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

>客にバグ出し

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

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

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

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

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

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

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

逆だろ。

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

馬鹿 と断言していい。

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

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

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

パンチってなに？

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

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

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

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

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

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

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

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

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

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

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

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

>>25
は？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>40
ま、普通だな。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

118:以下、名無しにかわりましてVIPがお送りします :2008/06/29(日) 21:22:15.60 ID:hxmEELXAO
転載

1:☆ばぐた☆◆JSGFLSFOXQ＠☆ばぐ太☆φ ★ :2008/06/28(土) 11:28:32 ID:???0 [[email protected]]
インターネット上には、今回の処分とは全く関係のない複数の女性記者、社員個人の人格を著しく
誹謗（ひぼう）・中傷する映像や書き込みが相次いでいる。毎日新聞はこうした名誉を棄損するなど
明らかな違法行為に対しては、法的措置を取る方針でいる。

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

どうせしないだろう？

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

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

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

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

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

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

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

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

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

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

>>65
コスト？

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

>>66
>>42とか

>>58とかも

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

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

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

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

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

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

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

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

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

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

>>74
結論から言おう。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

だが断る

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

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

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

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

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

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

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

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

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

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

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

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

無いよ、絶対に。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

あげてみるテスト

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

長い

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

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

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

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

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

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

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

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

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

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

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

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

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

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

・・・

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>139
顧客に言えよw

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

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

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

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

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

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

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

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

プログラマの心理とすれば、テストってめんどくさいんだよね。
特に結果が分かりきってる（と自分で思い込んでいる）メソッドのテストコード
をいちいち書くのがね。
で、俺がこの前ミスったのは、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にしとくべきでした。

と、あらためてユニットテストの重要性を認識したしだい。デグレを起こさないため
にもね。

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

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

面目ない。。。。

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

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

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

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


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

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

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

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

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

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

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

え？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



もってっけー

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

これだけやりゃ十分

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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




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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>193
どこを盾読み?w

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

だから何？

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

まあ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

それだけの話。

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

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

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

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

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

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

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

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

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

>>231
机上の空論。

実戦経験をつめ。

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

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

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

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

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

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

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

>>239
言うと思ったｗ

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

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

レス先間違えてね？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（少し追加）

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

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

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

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

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

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

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

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

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

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

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

>>253
thx

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

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

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

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

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

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

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

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

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

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

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

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

>>256

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

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

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

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

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

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

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

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

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

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

ImageGear許すマジ

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

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

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

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

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

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

MT?

いやいやいや、

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

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

80来ないとつまんないね

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

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

MTは知らんｗ

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

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

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

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

テストの種類は基本情報の勉強で覚えたくらいだな。
ユニットテストとか現場でのレベル感で縛られるな。

>>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. そのた。

>>278
１．同じでないと困る。

２．テスト結果による。


全体的にはどんなプロジェクトも同じ工程じゃないと困るが、
そのテスト工程で発覚する不具合の深刻度と混入工程によって、
それぞれ小さな部分テストの反復があるんだよ。

修正する度に、部分的にUT→IT→が間に幾つも入るのさ。

場合によっちゃSTまでを反復で何度も行う事だってあるしな。

つまり、仕様や性能を満たせているかを確認するテスト（ST）が
ずいぶん後回しになるやり方を皆は支持しているわけだ。

そもそも、仕様書は、システム全体に対してのみ書かれるのか？

>>281
皆っておい、俺一人しか答えてねえよwww

279も280も俺、俺俺www

>>282
いや、オレオレwww

>>278
工程として考えたいのか、テスト手順と考えたいのかがよくわからない。
工程なら大規模小規模かかわらずUT＞IT＞STとなるべきだが、
実際に行われてるテストはいくらでも入り組むだろう。
バグ対応入った時とか。

もし工程として(もしくは工程に近いレベルで)
質問２みたいな手順になっているなら
>>78の言うとおり、機能単位で分けるべき。


すごく今更なんだが、>>80の
> 分割すると管理コストが増えるし組織が複雑になる。
> そして、意思疎通が難しくなる。
> 問題が形を変えるだけで何も解決したことにはならない。
なんというか…オブジェクト指向じゃない感じみたいな…
モジュール一つで表示から処理から遷移から何から何までって感じがする…

>>80の言っている>>258には同意できる。

■機能要件
開発スタイルにもよるんだろうけどうちの顧客はころころ機能要件を
修正してくるから、機能にマッピングされるモジュール内の関数構成や
実装はそのたびに修正される。
=> ホワイトボックステストはコスト的に合わないので、モジュールの
入出力に相当するAPIだけをブラックボックステスト。

■再利用可能なコンポーネント
タスク・タスク間通信・メモリ管理周りといった部分がそれに含まれる？
不具合が全体に波及するのは勿論だし、そういったモジュールは
関数構成や実装が大きく変わることは無い。
=> ユニットテストで関数ごとにホワイトボックステスト。

コスト的に許されるんなら、全てにホワイトボックステストを用意するに
越した事は無いんだけど。

>>258はよくわからなかったけど>>285には納得できる。

> => ホワイトボックステストはコスト的に合わないので、モジュールの
> 入出力に相当するAPIだけをブラックボックステスト。
コスト的にかどうか知らないんだけど、これが一番理想とするテストだと思ってる。
APIの所だけホワイトな、穴あきブラックボックステストみたいな。

>>278
スパイラル型でもない限り結合超えてUTに戻る、ってのはないんじゃないの？
上位テストフェーズで不具合が見つかった瞬間はともかく

おれはスパイラルスキーなんだけどね。

ちなみに今関わってるPrjは大規模であっても
UT->IT->ST
これだけ。そして受け入れフェーズで多々トラブル。
おれ、どうしたらいい？

あ、
１．よくない。お客様との要件詰めが完全合致していて、仕様変更などが絶対入らない
　　前提でもない限りUT->IT->STのみではうまくいかない。
　　なぜなら、UT後に仕様変更なぞ入ろうものなら品質面での保証がまったく出来なくなってしまう、
　　客は触って初めて「違うぞこれ？」とか言い出す生き物、などなど。
２．同じことの繰り返し、と考えてしまうと、６．その他、が正解だと思う。
　　自動テストをUT,IT,STのくくりにいれず同時並行すべきかなー、とか。

みんな考え方は現場経験や本人の考え方により違うんだろうけど
こうやってテストフェーズについて色々活発に話せることはよいことだナァ。

>>288
なー。おれはよくわからんから読んでるだけだけどなー。

>>289
実際現場でテストやその後フェーズで苦労しだすと結構分かってくるんじゃない？
ってか品質面で問題でない現場ならそれが一番の幸せだよ｡゜（ﾟ´Д｀ﾟ)゜｡

>>281
仕様書はもちろん個々の機能についても書かれる。
そしてその仕様どおりの入出力を満たしていることの確認もする。
ただし、業務系ではそれをシステムテストとは呼ばない。
個々の機能の入出力を重点的にテストして、それより下位のテストは適当にするっていうのは
いいと思うよ。
本当にただ言葉の定義が違うために言ってることが分かりづらいだけ。

今回うけた仕事、システム全体の中の1カ所の開発(というかリファクタ)なんだが
自分たちが受けた部分はともかく、他のところはいきなりシステムテストらしい。
ちゃんとモジュールテストされてない・・・

そのせいで、システムテストで
他の会社が作った部分のデバッグをやらされてる。

>>292
そういう段取り／スケジュール考えた奴は軽蔑していいよ

>>290
テスト後フェーズは幾度となく経験してるし、
修正後のテスト堂々巡りも経験してるけど、
大規模開発というものを経験したことがないので、
UT→IT→ST が同時進行ならまだしも、何度も巡る
というのが理解できず、議論についていけないｗ

というかあれだな、読んでいて思ったけど、
言葉の定義や論点がずれているだけで、
本質はみんな同じ認識の様な気がする。

>言葉の定義や論点がずれているだけで、
>本質はみんな同じ認識の様な気がする。

いや、違うね。俺だけが違ってるという可能性もあるが。

>>281
テストフェーズの定義について、素直に間違っていたと認めた80は評価する。
同じように「仕様書」に関しても、他とずれていると認識してほしいのだが。
そうでないと、>>281の後半部分には答えられない。

>つまり、仕様や性能を満たせているかを確認するテスト（ST）が
>ずいぶん後回しになるやり方を皆は支持しているわけだ。

何度も言うように、システムテストは機能テストと「性能を測る」テストだけではない。
後回しになる（後でやらないと意味がない）テスト（ケース）もあれば、先にやるものもある。

機能テストのことをずいぶん気にしているようだが、「皆」がどう取り組んでいるかは、
「受け入れテスト 自動化」でググってみるとわかるかもね。

俺が80と違っている（と思っている）点は、
・ユニットテストは軽視してはならない。むしろ重視すべき。
・ユニットテストはプログラマが行うべき
・ユニットテストを重視することは、顧客のメリットになる
・（おまけ）外部設計と内部設計という考え方はある

80に同意する点もいくつもあるが、それは列挙しない。

適当でいいんだよ適当で。

適当、よりも、適度、がいいと思うんだ

適当≠手抜き

サンビャク！

>>296
>・ユニットテストは軽視してはならない。むしろ重視すべき。
->軽視はしていない。重視もしていない。
　おれは、テスターじゃなくて、プログラマー上がりなので、
ユニットテストの大切さを知っている。ただ、組織としてユニットテストを
　成功させる場合は、以下の前提条件を満たせないとだめだ。
1. バグが減ったことを評価して、ボーナス査定をUPさせる。
　2. 機能実装よりバグが少ないことを重視する。
重要なのは、2 だ。ユニットテストを重視した結果開発のスピードが
　落ちたのだ。つまり、機能的要件（フレームワーク、下位コンポーネント
　を除く）を実装するチームに関しては、ユニットテストがボトルネックになる。
　よーは、すべてがトレードオフなのだ。ユニットテストを重視しすぎると
　逆に効率が落ちる開発フェーズがあることを俺は、経験で学んだ。
　
>・ユニットテストはプログラマが行うべき
-> ユニットテスト＝ホワイトボックステストなら同意。

>・ユニットテストを重視することは、顧客のメリットになる
　-> 大規模開発では、顧客には理解されない。
　 業務系ではないうちでは、専門的すぎて説明するのが難しい。

>・（おまけ）外部設計と内部設計という考え方はある
-> うちの会社にも昔はあったよ。外部設計、内部設計という言葉が
間違っているのに気がついた。
　　 確かに、システムというものを対象にした時にそれの外部について
記述したドキュメントと内部について記述したドキュメントはある。
ただ、外部か内部かという言葉は、対象物を前提としている。
システム、サブシステム、コンポーネント、ライブラリ・・・・などだ。
そして、これらは、整然と関連付けられる。内部設計とか外部設計という
言葉をこれに当てはめると間違いである事が理解できる。
外部は仕様書で、内部は設計書なんだ。これでもわからないなら。
　　 仕様書と設計書の違いを説明してくれないか

補足だが、プログラマーとテスターの作業量を新規開発の初めから
終わりまで時間を追ってグラフにしてみると俺の言っていることが
分かるかもしれない。
理想を言えば、一番初めのインテグレートの時にテスターが
チームに参加すれば、コスト的にOKなのだが。
大抵は
1. 一番初めのインテグレートは遅れる。つまりテスターが遊ぶ。
2. テスターが開発初期から参加している場合、テスターは
プログラマーよりも暇である。
3. 機能要件は、よく変わる。せっかくユニットテストをばっちりしても
作り直しが多数発生する。さっさと、要求者に「うごく」ソフトを
見せるのは重要だ。

テスターを遊ばせないで、機能要件の間違いを早期に発見できる方法
を俺は支持しているんだ。

>>285
だいたい、同じ考えだ。
機能要件と再利用可能なコンポーネントでは、テストのやり方
を変えないとだめだ。

再利用可能なコンポーネントは、下位の層で人目につかない。
テスターに通信プロトコルや各種規格をすべて理解してもらうことは無理
なので、プログラマーしか「テストができない」と俺は思う。


違うところは、再利用可能なコンポーネントのテストは、
ホワイトボックステストと加えて回帰テスト（ブラックボックス）を
重視するところだ。

再利用可能コンポーネントは、最適化を繰り返すので、ソースコードが激変する。
つまり、ホワイトボックステストは毎回変わってしまう。
ホワイトボックステスト事態の品質を維持することは非常に難しい、
なので、回帰テストとの合わせ技が重要になる。

開発工程の中のボトルネックはどこにあるのか？によってやり方は異なる。
プログラマーのスキルが高い場合、テスターのスキルが高い場合など
状況は様々だ。

うちのボトルネックは、「実装」フェーズだった。
スケジュールの遅れは、プログラマーの責任だという認識が多数を占めていた。
なので、ユニットテストが流行したが、結局、失敗に終わった。

ボトルネックにさらに仕事を増やした（人は増えない）結果、開発そのもの
が遅れ、テスターが遊び始めた。設計者は次の設計に入っている。
しかし、ボトルネックが解消されなければ、実装されない設計が溜まる
ばかりだ。テスターは、空いた時間で別のプロジェクトのテストをしている。
リソースが有効活用されていないのは明らかだ。
ボトルネックを解消するのに設計者にテスターにできることはないのか？
そう考えるのが普通だろう。
設計者には、設計を洗練させた。結果、不要なソースコードをプログラマー
が書かなくても良いようになった。
ユニットテストを強要することはやめた。その代りテスターの負担が増えた
が、もともとテスターは遊んでいたのでプロジェクト全体のスループットは
向上した。テスターのストレスは増えたが・・・。

ユニットテストを完璧にやるという事は、ウォーターフォールの考え方
に近い。うちは、繰り返し型の開発をやっているので、たとえバグが残っても
開発の最後の方でプログラマーの手が空いてきたころに網羅性の高いテストを
行うので実質品質が下がるようなことはない。
ユニットテストは有効だが、使い方を間違ってはいけないと思う。
重要なのは、部分最適化（ユニットテストだけを協調する）のではなく
全体最適化（全ての開発工程を見直す）の方だと思う。

>>291
業務系は、書籍などで知っているだけで現場は知らない。

うちは、メカトロニクス。半分は制御系。ただし、大規模な制御系だ。
Web技術、データーベース、各種通信、など色々開発要素も多い、
言語もC++, C#, Java, その他が入り乱れている。

うちのシステムは、多層になっているシステムの集合体だ。
担当者は、自分の担当範囲だけどをシステムと呼んでいる。
つまり、人によって、システムの範囲（スコープ）が違うんだ。
そして、多段階にインテグレートしてテストを行う。

なので、スコープとレベルの違うシステムテストはチーム内の複数存在
することになる。

見方を変えれば、下位のシステムは、ユニットとも言えなくもないが、
よほどの下位でもない限り「一般論で言うユニット」とは違う。

うちでは以下のように定義している。
・（粒度はともかく）機能的要件を実現する単位をシステム
　（サブシステム）と呼んでいる
・下位の原始的なメカニズムを提供するものを、ユニットと呼んでいる。
・機能外要求や、システムのアーキテクチャーをつかさどるものを
フレームワークと呼んでいる。

>>301
>ユニットテストを重視した結果開発のスピードが落ちたのだ

結局ユニットテスト非重視と重視で品質面はどちらがあがったの？
非重視で品質落ち（最悪客先リリース後に不具合多々発現）だとしたら
開発スピードが落ちた、ではなく必要フェーズをはぶいてスピードあげてた、
ってだけでは？？

みんなの会社で「専任テスター」っている？うちは

a.管理：チームMGR、PL
b.営業／客対応：客対応向けSE、営業
c.開発：開発向けSE、PG

みたいな位置づけになってて、テストは
「それ開発の一環だろ」って見方を上がしているから結局c.が全員で当たってる。

いい形とは思ってないけど、この場合、
フェーズによって「テスター」が暇になる、ってのはないけどなー

80の方法だと、ユニットが細かい区分になるので、つまり単純化される。
つまり単純で小さなテストが沢山できる。

質の問題を量に転化したと言っている。
で、コスト削減の為にテストを自動化したと。

まあ、制御系で1000万コードってどんだけーって話だけど。
工場の制御丸ごとやったとしか思えんなぁ。

グローバル変数が100万個位あるんだろ

>>306
品質は向上した。第三者テストの重要性を再認識することとなった。
多分、問題点や間違いを早期のうちに把握できたことと、プロジェクト管理
がやりやすくなったことなども良かったと思う。

プログラマーに、プレッシャーを与えることになったのと、
テスターの地位が向上したのも良かったのかもしれない。

>>307
うちは、専任のテスターがいる。
そして、開発の初めから開発に参加している。
要件定義が終わったら、これをもとにテストを作成しはじめる。
（テスターが要件を事細かに見るので要件は洗練されるというおまけもつく。）

つーか、日本の現場にありがちな曖昧な部分を消したという事が重要だと思う。
グラマーのプライドなんて、邪魔ものだからなー（本人にとってもー）。

>>312
そういう見方もできるな。要件の曖昧さとテスターのカバレッジを
ユニットテストで補えるとプログラマーが考えているなら、
勘違いも甚だしいな。

プログラマの常識は一般人の非常識って事ですね。わかります。

>そういう見方もできるな。要件の曖昧さとテスターのカバレッジを
>ユニットテストで補えるとプログラマーが考えているなら、
>勘違いも甚だしいな。

いや、それに甘えてきたSEが問題でしょ。
厳密に言えば、曖昧さは発生しない為に仕様があるわけで、
仕様抜けとか仕様に考慮を入れていないというミスを
グラマーがプログラミングやユニットテストで吸収するのは
よくある風景だ。
単純にそれはSEの怠慢でしかない。

ちなみにそれやらないと、ユニットテストが上がらないっていう
話になって仕様書を押し戻すと作成元の責任になったりする
ので出来ないってのも基本。

>>301
>　よーは、すべてがトレードオフなのだ。ユニットテストを重視しすぎると
>　逆に効率が落ちる開発フェーズがあることを俺は、経験で学んだ。
バグを取り除くのが早ければ早いほど、トータルコストが少なくなるというのには同意してもらえるのかな？
もっと言えば、トータルコストが少なくなるような効果的なユニットテストを模索しなければならない。

>　-> 大規模開発では、顧客には理解されない。
>　 業務系ではないうちでは、専門的すぎて説明するのが難しい。
トータルコストが少なくなり、品質も安定するという意味で、顧客のメリットになる。

>-> うちの会社にも昔はあったよ。外部設計、内部設計という言葉が
>間違っているのに気がついた。
>そして、これらは、整然と関連付けられる。内部設計とか外部設計という
>言葉をこれに当てはめると間違いである事が理解できる。
君が間違っていると主張しても、それでも世界は回っているんだよ。
目をふさぐのは簡単だけどね。

>>316
>バグを取り除くのが早ければ早いほど、トータルコストが少なくなるというのには
>同意してもらえるのかな？
当然そうだが、早いというのは、開発のスケジュールの早い段階でという
意味でだ。うちはスパイラルだからできる芸当なんだが、早期の詳細な
テストが徒労に終わることを経験で知っている。
開発の初期で最低限の要件で開発して、さっさとインテグレート
してさっさとシステムテストをやることで早期にテストを行って
要件の問題を修正している。この場合、ユニットテストは簡単にしか
行われない。

>>316
>君が間違っていると主張しても、それでも世界は回っているんだよ。
>目をふさぐのは簡単だけどね。
世界って広いぞ。うちは外資系だからアメリカ、インド、ロシア・・・・
いろんな奴と一緒に仕事しているけど、ソフト開発なんてのは、世界的に
統一されたりしてないぞ。各国各様でばらばらだ。つまり、外部設計と
内部設計という言葉が通用しないのを、実際に経験で知っている。

なんでシステムテストをやると
ユニットテストをサボれると思うのだろう？

>>317
> 意味でだ。うちはスパイラルだからできる芸当なんだが、早期の詳細な
> テストが徒労に終わることを経験で知っている。

誰も、過剰なユニットテストをやれなんて言ってねーよ。ユニットテストをプログラマにやらせると
必ず過剰なものになるからやらせないってことか。
まぁ、お前のチームのプログラマがレベル低すぎて効果的なユニットテストをできないのならそれも仕方ないかもな。

>>318
どんだけ田舎者と仕事してんだよ。
internal designとexternal designも通じない奴と仕事してんのかよ。

そろそろメトリックスベースで話さないと埒があかんな。
1000万行のシステムで、第三者検証チームが検出したバグは何件だったんだ？

>>318
とりあえず、原著で読んだsoftware development processの本の題名を列挙してくれ。

>>320
シリコンバレーは、確かに田舎だな。。。。

ちなみに言うとうちでは設計書はあまりかかれない。仕様書を重視する。
うちの外人さんは、「設計書＝ソースコード」だと言い張る。
年収3000万を超えるプログラマーだからできる芸当なのかもしれない。
こいつらテストはしない。テストは、テスターの仕事だと言い張る。

ダメだ、はったりにしか見えない｡゜（ﾟ´Д｀ﾟ)゜｡おれもうROMるわ

「顧客のメリットになる」ことにこだわっている人が
いるけど、それが必ずしも自社にとってメリットになる
わけでは無いわけで。そういった意味で顧客との間で
落とし所をさぐる時にユニットテストを一部省くというのは
普通にあると思うけど？

やった作業に対して全て金を払ってくれる契約
（それって派遣？）なら全ソースに対してユニット
テストするのもありかもね。

経験上の話だが、（良い）詳細設計というものは考えていても作れない。

そういう頭の中で考えただけの設計というものは実際に作るときに、
絶対に問題点やバグがある。パフォーマンスの問題なんか
実際に作らないで目標を達成することなんか不可能。

結局コーディングして、その結果をフィードバックして
設計を完成させなければならない。

ユニットテストってのは、その設計を完成させる為のチェックポイントなんだ。

これは重要なこと。
「設計・コードは簡単に変わるが、チェックポイント（テスト内容）は変わらない。」

ゲームに例えるとこうなる。
仕様・・・世界を平和にする。
ユニットテスト・・・各ステージのボスを倒す。（チェックポイント）
設計・・・どういうルートを通ると早くすすめるか。
コーディング・・・実際のキー操作


最初に仕様があるが、これはすごくあいまいなもの。
システムを作るうえでの大前提だが、コレを決めてもシステムは作れない。
個々の目標が、ユニットテスト。これがシステムを作るうえで一番重要なもの。
これがあれば、設計やコードを柔軟に変更することができるし、間違っていない証明になる。
そして、ユニットテストを作ってから、設計とコーディングを行いながら開発していく。
（実際にキー操作をしないと、考えたルートが通れるのか本当に早いかはわからないね）

>>325
あなたが言っているのは、ユニットテストに限った話じゃないね。

「自社のメリットにならない場合はテストを省く。」
「やった作業に対して全て金を払ってくれる契約なら全部テストするのもありかもね。」

もし俺が客で、あなたの会社にシステム開発を依頼する立場なら、
お金を払って開発したシステムを、あなたがちゃんとテストしてくれるかどうか不安だけど。

> やった作業に対して全て金を払ってくれる契約
これは、全部のテストの作業量を見積もって、その金額で契約するわけだから、
全部テストするのが当たり前だと思うんだけど？(客が80%で良いとか言うのなら別）

>>1
おれの作ったプログラムにはバグがない。
だからテストは不要。

と書きたいところだが、
Ｃ言語だと１万ステップに３カ所ぐらいは
バグがある。

ただし重要なところでバグがでないように
単体テストをしっかりとやってから納品している。

バグは意思の疎通が十分にできていれば
ほとんどでることはない。
バグのでる仕事というのは、だいたい意志の疎通がとれていない
ということ。

俺も1万行に一回くらいしかコンパイルしないけど
ほとんどバグないな

何この全力で釣られるスレは・・・

>>327
>これは、全部のテストの作業量を見積もって、その金額で契約するわけだから、
>全部テストするのが当たり前だと思うんだけど？(客が80%で良いとか言うのなら別）
100%見積もれて、客が１つも仕様変更をしない場合の話だよね。それって。
そこら辺は開発スタイルの問題かと。俺が言いたいのは「仕様変更のリスクを設計や
計画に含めた形で客に説明しているし、客にもある程度納得してもらってる」
という事。

そういった意味でテストの手法や粒度をどうしましょうか？という事を>>80は言い
たいんじゃないの？

>>331
でも、最初っから変更出来るって頭を顧客に植え付けちゃうのもどうかと思う。
費用込みなんだから一度くらいは変更できるよね？　とか言われないか？

>>332
プロジェクトがある程度続いている or 続く事が期待できる
相手であればそれもありかと。いずれにしても開発・契約
スタイルによるわな。

まあ、変更は一切出来ませんとか言っててもどうせ変更させられるんだけどなwww

普通は1000行あたりバグが5〜50個くらいかな。数え方やプロダクトの難易度にもよるが。
1000万行だったら、5万〜50万個くらいか。
まぁ、正直、これだけのバグを10人でさばけるのなら大したもんだよ。

>>335
ちょっと待て
最悪20行に一個出るのが普通か?
たとえ200行に一個でもかなり多いだろ
新人レベルがかなり混じってるならともかく･･･

>>336
設計から実装までやれば、延べにしてそのくらいは出るよ。
設計ミスで全面入れ替えの所とか、パフォーマンス出なくてとか、必ず出てくるwww

ここがコーディング界のネ申達がおわす所、バルハラですか（１万ステップに１バグあるかないかを誇るという）？

それにしては冴えない連中が多いのですが・・・

あいつ使えねーからこっちで直しておこーぜ。
いいよ、バグ無しって言っておけよ。

>>329
それはデータ込みの・・・むしろデータのみを扱ったコードですか？
社会保険庁よりは優秀ですねwww

>>340
一般人には想像すらできない天才っているもんなのよ。
天才というか、障害というか。

>>337
設計にしてもキモになる部分ならプロトタイプなりなんなりで
実装可能性やパフォーマンス検討するだろ。
それを実装まで持ち越しているなら設計工程が十分でないだけ。

ひょっとして手戻りが好きなのか？ｗ

>>324
はったりじゃないんだけど・・・。
それに、嘘ついても仕方がないじゃんか。

>>342
やらねえよ。
だって動作環境が半年後じゃないと揃わないとかザラにあるからな。
パソコン上で幾ら理論構築しても、載せて初めて発覚するパフォーマンスなんてのは普通だし。

まあ、何万行書いてもBUGなんて皆無と豪語してる奴は、信じられなくて当然。
そういうコードは結合後に醜い事になってる事が経験的に多いなw
要するに、俺様仕様でBUGゼロってだけだからwww

入力がパンチカードとかだった時代ならともかく…

どこかの会社の面接を受けて
特技「１万ステップのコーディングでバグが１件です」
って言ったら、さてどうなるか？

>>342
パフォーマンスに関するチューニングを急いではいけない。
これは、鉄則なので、いまさら説明する必要はないだろう。
パフォーマンスのチューニングは、設計ではなくて
測定に基づいて行われるべきである。


>>345
正論だな。俺様仕様で作ったプログラムを、俺様が作ったユニットテストを
しても、そりゃー合格するよ。そもそも、自分が理解したとおりのプログラム
を書けない奴はうちにはいない。

たいてい、俺様仕様が間違っている時にバグが埋め込まれる。

///なんか80に正論とか言われると萎える・・・

// 80は極論派だと思う

/うわなんでコンパイルエラー！？

>>1はいいこと書いてるな。

でも、なんか>>1ってチンコ臭そう

/* >>351 コメントとして間違っている！！ */

まて、もしかするとマンコかもしれないじゃないか

>>344
組み込みならモノがないのでやむを得ない面もあるが、
大概は前のチップや代替品を使って見当を付ければいい。

>>348
パフォーマンスを急げと言っているわけではない。
パフォーマンスがどれくらいでそうか当たりを付けて
速度重視にするかフットプリント重視にするかの設計方針に入れろと言っている。
それを設計工程で行わないで後に回すから手戻るんだよ。

パフォーマンスって、チップ次第だし。
パソコンアプリ作ってればそのまま試せるだろうがな。
石のアクセス自体仕様通りじゃない場合だって普通にあるからさw

>>356
設計段階でパフォーマンスのトレードオフ検討出来るってうらやましいな
たいていは、死守要求だったりするからな。

>>358
排反事象なら一方を満たして他方を次善にして、後は交渉術でそ。
全部実現するにはこれこれのコスト(金額、開発期間)がかかりますと言うだけだし。
金払わない以上どこか諦めてね♥

>>359
いや、払うだろ。
正当な追加費用ならなwww

>>360
まともな客ならなぇ。。。
大概はより良く(まぁいい)より安く(切り詰めてんじゃねぇ)。

たしかに>>1はいいこと書いてるな


先日面接で「ｘｘのシステムを作り直すとしたらどのくらい？」って聞かれて
「コアを作り直すなら２人月ぐらいですね、今まで自分らで作っていた部分が今ではライブラリとして提供されているから。
それよりも、テストの方に工数がかかると思いますよ。」って答えた。

でもよく考えたら、ｘｘを作り直す（完成させる）まで、ってのは当然テストが完了して、のことなんだよな。。。

どうも自分の中で実装とテストを別に考えてしまっていたわ・・・ちゃんとしたものを作る、っていう意味では
テストはものづくりの一部だわ、、、今ここで反省します m(^＿^;)m


遠足は家に帰るまでが遠足だかんね。

>>362
ど素人さんですか？
今まで何やってたの？

>>363
>>362はちゃんとテスト工数の話してるしちょっと区切り間違っちゃっただけだろ。
いじわるなんだからっ！

たかだか二人月のゴミみたいなプロジェクトの例を出されましても・・・

ttp://itpro.nikkeibp.co.jp/article/OPINION/20080423/299886/
6000人のSEが同時期に集まったのであって，「6000人月」ではない。
開発工数は先に書いた通り，11万人月である。
このSEパワーは開発だけではなく，テストに惜しみなく使われた。
ざっと5000人が8カ月テストをしたとするとこれだけで4万人月，開発工数の3分の1がテストに費やされた計算になる。

　本来なら有り得ない開発工数とマネジメント工数とテスト工数である。
　本来なら有り得ない開発工数とマネジメント工数とテスト工数である。
　本来なら有り得ない開発工数とマネジメント工数とテスト工数である。

ttp://sankei.jp.msn.com/economy/finance/080512/fnc0805122000013-n1.htm

テスト段階では、全く想定していなかったトラブルが起きた
テスト段階では、全く想定していなかったトラブルが起きた
テスト段階では、全く想定していなかったトラブルが起きた

テストに開発工数の 1/3 を費やしてもシステム障害で行政処分。
部分最適化のもろさを露呈してしまう結果になった。

「全く想定していない」・・・要求定義者や分析・設計者のミスをテストで
カバーできないってこと。間違った仕様を完璧にコーディングしても
それは、バグ。

6000人全員が派遣でしたwww　って話？？

コーディングは終わったので、あとは人海戦術で手動テストしてくださいって
パターンなら最初からうまくいくはずないよ。

なんか、ぶっちゃけ私の方法ならうまくいくと間接的に言ってるように
見えるけど、ほんとそうなの？

>>369
テストの際に出てくる不具合報告を眺めてるだけじゃ完成しないがなw

テストに入ってからが本当のコーディング作業が始まると思わなきゃ上手く行かない。

>>371
メガプロジェクトじゃ、そんなの通用しないし。

>>372
はあ？
メガプロジェクトじゃ、最後までコーディングしてる部署が必ずあるよ。

つうか、不具合改修はやらねえの？

普通、やるでしょ
PSPの海腹川背みたいな例もあるけどw

>>371
> テストに入ってからが本当のコーディング作業が始まると思わなきゃ上手く行かない。
だから、無駄なテスト前コーディングをしないで、
テストをやってコーディングをするんだよね。

>>367
> 「全く想定していない」・・・要求定義者や分析・設計者のミスをテストで
> カバーできないってこと。間違った仕様を完璧にコーディングしても
> それは、バグ。

ですよね。だからちゃんと想定して、
その想定した内容をテストとして書くんですよね。

これであなたもユニットテストの重要性を理解したと思います。

ついにマ板にも夏が来たか・・・

>>376
ユニットテストじゃ、要求定義や設計時のミスは取り除けないよ。

それを元にテストが作られるんだからね。

だいたい、設計時の矛盾は最終的な総合テストまで残る。
要求定義の矛盾は製品にまで残る。

>>373
「本当のコーディング作業」の定義次第だな。
そして、その定義を云々するのはくだらねー。

80の言い分だけど、

うちの会社は1000万のコードで、

次に、基本証券・金融系では無い。制御系だといって、

最後に、国内最大の金融系の仕様段階での問題点を出している。

あ、あとシリコンバレーと仕事しているってのもあったな。

で、別に仕事のやり方は全否定する要素は無いが、具体例は
全否定されても仕方ないほど妄想力に満ちていると感じたの漏れだけ？

>>374
あれは、「仕様です」

とりあえずユニットテストやファンンクショナルテストをちゃんと書いていけば
設計時の矛盾とか普通にたくさんでてくるよ。
んで、短いサイクルでどんどんリファクタしていけばいい。
もちろん手動テストもするけど、ばかげた規模での人海戦術テストとかにはならないでしょ。

またまた富士通！東証システム障害　プログラムミスが原因 　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 . .:: :.: ::: . :::::::::::::::::::::::::::::::::::::::
　　 　　 / :::/;;: 　 ヽ　ヽ ::ｌ　. :. :. .:: : :: :: :::::::: : ::::::::::::::::::
￣￣￣（_,ノ ￣￣￣ヽ､_ノ￣￣￣￣

　【東証のシステム障害、設定ミスをテストでも見抜けず　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

ユニットテストは詳細設計どおりにプログラムが稼働するテストと認識しているんだが、
詳細設計が１ＳＴＥＰ対応の設計書でない場合、全パステストの結果って
どういう扱いになるのかな？

>詳細設計
の確認はうちではユニット-ユニットの結合テストだな

ユニットテスト対象はプログラム設計
ここ→ttp://msugai.fc2web.com/pgm/test.html
のV字モデルに近い

なので全パステストなんて結合テストで考えない

ttp://itpro.nikkeibp.co.jp/article/COLUMN/20051102/223934/
の図1もプログラム設計が書いてないけど同じっぽい

今日初めて見たが、みんな何か勘違いしてないか？
テストで信頼性は上げられない、テストは
「このプログラムにはバグがあるます」を実証するもので
バグを沢山検出したからと言って、そのプログラムには
もうバグが存在しないと言う実証にはならない。
実際は逆で、統計的に見るとバグ密度の多いプログラムほど
残りの潜在バグが多く含まれている。

テストでは信頼性は旦保できない為、極度に
信頼性が求められるシステムでは、テストをしない開発手法もある。

>>388
asshole

>>388
＞信頼性が求められるシステムでは、テストをしない開発手法もある。
kwsk

耐震偽装と同じレベルだろwww

>>390
有名な所では、ダーリントン原子力発電所の緊急炉停止システム

>>388
ソフトウェアの信頼性を定義してみな

IEC読んで言ってるなら凄いけどね・・・

>>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にもにも書いてあるし、大半の「テスト」関連の書籍にも同じような意味の事が書かれている
いままで、その辺りの知識もなしにレスを書いていたのか？

>>395
それは394への答えにはならないよ。

>>395
だから、普通テストは
要求された機能が特定の条件下で要求通りの結果を示せるかをテストするんだぜ？
要求されてない（テストされてない）機能がどのように振る舞おうが知ったこっちゃ無いのはあたりまえ。

だからその理論は正しいが、そんな事は誰も要求していないんだよ。
想定外の欠陥は許されるが、想定内の欠陥はダメなの。

>>397
＞想定外の欠陥は許されるが、想定内の欠陥はダメなの。

現実は想定外の欠陥でも許さない人間が大半だがな。　相乗りしている他システムが
異様にリソース使いまくって、それに巻き込まれて不具合起きて、それでも不具合が
おきない様にしろと言われかけたときは頭抱えたよ、、、

>>398
もちろん納品前に発覚した不具合は想定内だよ。

予想GUYダ！

よそう、GAYﾀﾞ!

>>399
納品後ですが、何か？
しかも納品後すぐとかじゃなくて、数ヶ月たってとかだったり、他の納品先だと
そんなこと起きなかったりとかで調査だけでも結構かかりましたが。

>>402
受け入れ検査終了後なら別料金もらってんだろ。
いいじゃん仕事あって。

>>388
＞信頼性が求められるシステムでは、テストをしない開発手法もある。
ネタにしてはよく出来てる手口。

>>395
で、信頼性はどう定義するんだ？

>>397
限られた前提条件・限られた入力値・限られた入力値組み合わせでテストをして
その機能が、全て正しく動くと思ってる？　テストが何たる物か分かっていない証拠だな

>>404
自分の知識で分からないものはネタか！やっぱりこんな奴がいるんだ
例を出したんだから、調べれば分かると思うが。

>>405
俺に聞いても、プログラムの信頼性は上がらんだろう、自分で考えないと。

>>406
誰も信頼性の上がる方法なんて聞いてない。
信頼性の定義を聞いているのがわからないのか？

>>406
お前もちゃんと調べてから例出しな

>>406
全て動くなんて言ってないが。
ファビョるのもたいがいにしろよ。

>>407
>信頼性の定義を聞いているのがわからないのか？
分かって書いているんだが、分からないのか？

>>408
調べても分からなかったのか？俺はこれ以上教えるつもりはないから

>>409
>全て動くなんて言ってないが。
だから、テストでは信頼性は確保出来

>>信頼性の定義を聞いているのがわからないのか？
>分かって書いているんだが、分からないのか？

どこに書いたんだ？

駄目だこいつ。

テストの前にソースの読み直しをお願いします
先輩

単純リプレースとか言って営業がとってくる仕事ほど
前の機能をちゃんと満たしてるか（正しく動作するか？）って意味で
テストが重要、

って口をすっぱくして言ったんだがヌルーされた。
マシン->マシンでコピーして、簡単に動作確認すればいい

だってさ


まぁ、うまくいけばいいんだけどね。。。その時期夏休みとって携帯電源切っとこう

原子力発電所のソフトウェア開発について議論するスレじゃないよ

>>410
394にまともに答えられない人に教えてもらう事無いと思うよｗ

何手法だか知らないが、その手法でぬるいメガプロジェクトでも回してみればいいさ。

KKDは勘と経験と度胸による見積もり法です

それ
なんて
みずぽ？

>>411
>>どこに書いたんだ？
信頼性の定義は書いていない

>>412
>駄目だこいつ。
そうだな

>>413
>テストの前にソースの読み直しをお願いします
読み直しは大事だと思う、テストよりも

>>414
何処でも営業は同じ、そんなもん

>>415
ソフトウェアの話じゃないのか？

>>416
教えるつもりもないから大丈夫

>>417
そこまで信頼性を求められるプロジェクトは、ほとんどない

>>418
勘・経験・度胸は大切だと思うよ、マネジメントは人間性が一番重要だと思う

>>419
???

>>420
聖徳太子現る

明日は合コンだってさ、木曜だしなーーー
女の子たちの接客上手をテストしてやるぜ〜

>>420 からおじゃば臭がするのは気のせいか？

気のせいじゃなくね

>>421
どこのキャバでやんの？

>>420
おじゃばとしては、どういうテスト手法を理想としてんの？

>>422
いや、ハカセじゃないのかシステム工学を語りたいんだろう
でもハカセはアホだから違うかｗ

>>425
教えてやろう君にはすばらしい餌だなｗ

>>426
お前、おじゃばだろ

>>424
キャバじゃないし、今日でもなかった・・・

だれかおれの視力、聴力、記憶力をテストしてくれ

>>429
つ　http://homepage3.nifty.com/funahashi/game/game693.html

テストしてほしけりゃ金よこせ

まともにテストできるか能力を示せ。

テストは限られたリソースの中で、いかに効率良く不具合を見つけるかが重要
例えば、同じプログラムをテストして
　「Aは１０件のテストケースで５件のバグが見つけた」
　「Bは１００件のテストケースで１０件のバグが見つけた」
では、Bの方がAより残りのバグも少ないので信頼性のあるプログラムになるが
テストとしては、半分の確率でバグを見つけたAの方が、「良いテスト」と言える

つまり、テストは効率性が重要で、プログラムの信頼性は考えない
（バグを多く見つけるかでは無く、「"効率的"」にバグを多く見つけるかが重要)
同値テストや限界値テストなどのテストテクニックも、バグを効率に見つける為に考え出されたもの

なるほどね。
おじゃばという人物は、コミュニケートする気はないわけだ。
相手とちゃんとやりとりしたい訳じゃない。

単に「自分は知識があるのだ、おまえらより優れているのだ」と思っていて、
その優れた俺様の知識をひけらかし(たつもりになっ)て、気持ちよくなってるだけ。
その過剰な自己過信が揺らぐことも、基本的にはなくて、
それ故に、主張が基本的にいつでも一方的で、言いたいことを言うだけ。

使いようによっては、存在に意味を持たせる事は可能かもしれないけど、
人間的にはゴミだなぁ。ｗ

Aの方が効率悪いじゃん？
なんでBは100件もこなせてるのに
Ａは10件しかこなせなかったんだ？
リソース一緒なのに。

>>388
節子、それ、テストやない。デバッグや。

>>435
１０件辺り５件も不具合出りゃあ、テスト中止だろwww
５０％なんてどんだけボロボロなんだよwww

>>437
>>435 の例は、
・同じプログラムなら網羅できたとしてテストケースの数は同じになる。
・テストケース数＝1000件
・実際の不具合の数＝20件

テストA：
　テストケースの中から10件を選択してテストを実施->不具合5件発見

テストB：
　テストケースの中から100件を選択してテストを実施->不具合10件発見

プログラマーが嫌うような意地悪なテストから実施すると不具合は見つかり
やすいとか、やりようによっては早期に不具合を発見できるという意味なのでは？

さらに、テストケースの粒度や内容をコントロールすれば効率はさらに
上がると思う。

屁理屈といわれそうだが、言葉の定義だけで言うなら
「信頼性＝故障しにくい事」

故障とは
1. 機械や身体などの機能が正常に働かなくなること。
2. 物事の進行が損なわれるような事情。
3. 異議。苦情。

1. の意味だと
ハードウェアシステムの場合は、劣化などでそのうち故障する。
ソフトウェアシステム（プログラム）の場合は、劣化などはしないので
故障しない。

ソフトウェアの不具合は、2. の意味と考えられる。で、実際には、
3の苦情を指すんじゃなかろうか？
つまり、苦情の件数が少ないほど信頼性が高いと考えられる。

で、
A. 頻繁に使用されるある1つの機能に不具合がある
B. たまに使用されるある2つの機能に不具合がある
C. 滅多に使用されないある10の機能に不具合がある
を考えた場合、A, B, Cのどれを見つけるのが実際に利益があるのか？
を考えるとわかりやすいかもしれない。

なので、 >>435 の言う「テストの効率」は、もっと深く考慮されるべき
だと思う。

蛇足だが、
あるボタンを連打すると発生する不具合をテスト自動化で見つけたが
人間業では決して発生させることができない不具合だったので修正を
見送った経験がある。

>>435じゃなくて>>433な。

>>438
そんな机上論、幾ら並べても無意味。
何故って？

不具合の数に全容なんて無いからさ

その「実際の不具合の数」自体が空論
テスト方法変えて出てくるのは、異なる不具合であり、全容の一部が見えたわけではない。

>>440
訂正サンキュー。

ついでに補足
滅多に使用されない機能に致命的な不具合がある場合が一番厄介。
しかも、要求にはない機能が盛り込まれる場合、つまり、想定外の使い方
をされるのは、本当に厄介だ。

要求に無い機能（設計の段階で暗に入り込んだ機能）は、テストから漏れる
事が多いと思う。で、うちでは、繰り返し型なので、この手の潜在的な機能は、
（気付けば）要求としてとらえることにしている。

>>441
「ソフトウェアの信頼性ほど信頼性の低いものはない」と俺も思う。
不具合密度がどーとか経営陣や顧客に嘘くさい説明はできても自分自身は
納得していない。なので、実際には、統計的な手法からは距離を置いている。

持論で申し訳ないが、俺は、
「ソフトウェアの信頼性＝クレーム処理にかかった費用の少なさ」
と考えている。
極論すると
・ユーザが発見できない不具合は不具合とはみなさない。
（無実ではないが無罪。飲酒運転も逮捕されなければOK的な・・・）
・要求にない機能は、一切入り込まないようにする。
てな感じかな。

>>443
そういうプログラム引き継がされて爆弾爆発させたら
爆弾仕込んだヤツは無罪で爆発させたヤツが
全部罪をかぶることになる

この図式はなんとかならないかなあ

まあ、完全にBUGを潰す作業をいつまでも行っていたら、永久に製品が出せないからね。

完全にBUGの無いプログラムなんて存在しないからね。

もしBUGが一切無いプログラムがあったとしたら、それは検査方法が間違っているかテスト結果にねつ造があるかのどちらかさ。

以前にも書いたけど、テストだけを頑張るだけではだめだと思う。
部分最適化じゃなくて全体最適化ね。

以下は、テストではなく設計で逃げたケースの事例。

要求
「何年も24時間連続稼働させないといけないシステム」

設計
・非稼働時に定期的にこっそり再起動
・異常終了した場合はこっそり再起動

100%絶対に異常終了しない設計にするとテストが大変（証明できない）ので
設計で対策をこうじた。画面はあれ？ってな感じになるけどしばらくすると
復帰する。今のところクレームは無い。

>>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ

>>446
死ぬほどよくあるインフラ構成を偉そうに語る辺り働いてないか末端PGでしょ。
しかも、いきなり「非稼働時」とかまともに説明出来てないしｗ
インフラ構成に頼ったシステム安定性なんて無いに等しい

>>436
なるほど。>>388を直してみた。

--------
今日初めて見たが、みんな何か勘違いしてないか？
デバッグで信頼性は上げられない、デバッグは
「このプログラムにはバグがあるます」を実証するもので
バグを沢山検出したからと言って、そのプログラムには
もうバグが存在しないと言う実証にはならない。
実際は逆で、統計的に見るとバグ密度の多いプログラムほど
残りの潜在バグが多く含まれている。

デバッグでは信頼性は旦保できない為、極度に
信頼性が求められるシステムでは、デバッグをしない開発手法もある。

>>449
あ　すげーまともな文章になったww

>>448
インフラじゃないけど・・・。全然、意味通じてないみたい。
俺、文章力自信なくしてきた。

>>448
真面目に読んでくれているみたいだな。
非稼働ってのは変だな。よーは、ユーザーがシステムを使用していない
隙間の時間ということ。

あと、システムと書いたけど厳密には、ソフトウェアシステムね。
自己診断機能と自己修復機能を連携させてるよーな感じのシステム。
実際には、ソフトが原因で異常終了することはないんだけど、
うちは、デバイスがくっついてるからそいつらのせいでシステムが
落ちたりする。

デバイス側の不具合により通信系が異常をきたした場合・・・・
ごめん、長文になりそうだから説明止めとく。

>>439
>つまり、苦情の件数が少ないほど信頼性が高いと考えられる。
それは違う「原子力発電所の緊急炉停止システム」みたいな
稼動する事がまれで、稼動での不具合が致命的になるケースもある
苦情の件数など関係なく、信頼性は稼動前から求められている

>>436,449,450
テストとデバッグは別もの

>>452
余計おかしいだろ。

>要求「何年も24時間連続稼働させないといけないシステム」
>非稼働ってのは変だな。よーは、ユーザーがシステムを使用していない隙間の時間ということ。
要求満たしてないのはお話しにならないよね？
上の文が出るって事は仕様を修正した訳でもないし。

>うちは、デバイスがくっついてるからそいつらのせいでシステムが
>落ちたりする。
この1行でもうお腹一杯です・・・

最近話題の地震速報とかか？

>>453
> テストとデバッグは別もの

正解。よくできました。
お前自分が書いたレスよく読んでみろ。
テストとデバッグの違いの何たるかが解ってない奴の発言だ。
勉強して出直して来い。

>>456
それは間違い、俺が書いたものを理解出来ないだけの話

>>457
だとしたら日本語の書き方を勉強して出直して来い。

>>458
それも違う、そっちが知識が無いから理解出来ないだけの話
システム工学系の話だから、知識がない人とは話が噛み合わない

理解出来てたら簡潔に説明できる。
理解出来てないから伝わらないと教わった俺はいい先生に出会えてたんだなｗ

なんかいつのまにか80：その他大勢
みたいな流れになってしまったな


おれとしては80みたいな特異な例よりも
ふつーに自分の現場では・・・みたいなノリが好きなんだが・

自分の話が分かってもらえないなら
まずどうすれば分かってもらうかを考えるべき




分かってもらいたいのであればな。

「信頼性」の定義が述べられない以上
>>388の話には何の主張も存在していない。
故に誰にも理解できるはずがない。

『HAYST法』ってなんて読むのか知っている方いますか？？

>>453
繰り返すが、ソフトの信頼性は、苦情の件数ではなくて以下と
俺は、考えている。
「ソフトウェアの信頼性＝クレーム処理にかかった費用の少なさ」

「原子力発電所の緊急炉停止システム」のような重要な機能は、
不具合が現実のものとなった時、クレーム処理に相当金がかかるだろう。
よって、網羅的にテストすべきだと思う。

対投資効果的に

誤解があるようだけど、クレームは、あくまでも結果。
「クレーム処理費用が高くつきそうな不具合を発生させる可能性のある
機能のテストケースをきっちりやれば、絶望的な数のテストケース全部
はやらなくてもいいんじゃないか？」と言ってるだけ。

クレーム処理で高くつく機能は、顧客要求にある機能とリスクに関する機能
とかね。

>>454
悪いが、たぶん俺と >>454 はドメインが違いすぎると思う。
「顧客要求≒真の要求」とだけ書いとく。

>>460
横やりで悪いが。
そんなに単純なものじゃないと思うぞ。

システムのアーキテクチャは複数のビューで相補的にモデル化される事が
ある。エンドユーザ、プログラマー、システムエンジニア、アナリスト・・・
といった立場によって、「見方」が違うわけ。

話題がプログラミングならビューは「プログラマ」だけで済むので
混乱は少ないが、「テスト」は裏返すと要求でもあるので、いろんな利害
関係者が混ざってややこしい。

理解にも種類があるんじゃないか？

>>464
俺は、ヘイストと読んでるが・・・。自信はない。
別に否定するつもりはないが、数あるテスト手法の一つだな。
HAYST法は、上流工程がパーフェクトな場合に生きる手法だと思う。

隔離スレが必要なレベルだな・・・

>>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ

>>338
能書き垂れる前に、ソフトウェアの信頼性を定義しろ

なぁ、なんで>>80は粘着しとんの？

それプログラマやない、評論家気取りの厨房や

>>459-471
お前らみたいに釣られるカモがいるからじゃねーか？
しかも連投だしｗ。ごくろうさん。

>>466
要求分類出来てないよ。
≒にならざるおえない要求とそうでない要求がある。
君が例で出した要求は後者。

コテ酉つけて専スレ立ててもらいなよ。
みんな弄るの飽きたみたいだし、このスレではもう君は不要。

を

>>465
書いている事は分かるが、それは受注企業の論理だ
企業である以上、費用対効果を考えるのは当然だが
絶対の安全が求められるシステムでは通用出来ない
「人が死んでも生命保険に入っているから大丈夫」とは、絶対にならない

俺の考える信頼性は、当事者の論理では無く、第三者も納得出来る
科学的根拠、例えば
「プログラム正当性の証明」(数理論理学的根拠)
「運用実績」（統計的根拠)

当事者の論理では、信頼性の根拠にならない

>>475
人が死ぬ不具合は、「クレーム処理費用が高くつきそうな不具合」の
典型だろ。

科学的根拠は、ユーザからしたら「当事者の論理」となんら変わらない。
ユーザーが理系なら納得もしてくれるだろうが・・・。
「プログラム正当性の証明」が理解されることはないだろう。
「運用実績」は唯一の不具合で崩壊する。

「統計的根拠」って天気予報で降水確率100%でも晴れる日があるだろ。
天気予報が外れても訴えられることはないのは、みんなが納得しているからだ。
ただ、ソフトウェアの不具合は、統計的に信頼性が高いと何度言っても、
不具合は不具合なわけで客は決して「統計」を重要視しない。

プログラム正当性証明をバグを生む開発者がどーせやるんだろ。
「正当性を証明できる」なら「もともとバグはない」というパラドックスに
ハマるのが落ちだと思うがな。

テストは全ルート試験です。
もちろんifやswitchならば全てを網羅。
試験項目数が1000を軽く越えます。

夏休みだなぁ

全網羅で「1000を軽く越える」程度なら楽勝だろ

開発規模・期間に対しては辛すぎる
一日400件消化しろと？
常識的に考えてくれ・・・

そういう情報を後出ししてるようだからダメなんだよ

>>480
そんなん普通だろ
何自分だけ不幸のつもりになってんだよwww
テスト自体の効率のいい作業順番とか考えれ
まさか項目上から順番にやってたりしないよな？

作業順番を変えても期限は変わらない件

>>80のおじゃば
うざいし

一日400件なんて新人レベル

アプリのテストを言ってるようだが、
異常系や例外系のテストなんか網羅できんだろ

スレは読んじゃないけどさ。

>>476
そうは言っても、ある程度定量的に評価出来ないと、
成果物の信頼性が属人的になってしまって、管理出来なくなるだろよ。

475で言うところの「第三者も納得出来る」というのは、
客観的に評価しているということの表現であって、
ユーザが納得できるかどうかでは無いと思うよ。

個人的には根拠は何でも良い。
>>443なら「ソフトウェアの信頼性＝クレーム処理にかかった費用の少なさ」
それをどのように評価し、どのように見積もって、
これから出荷するソフトウェアの信頼性を評価するのか、
という話。
「出荷したソフトの信頼性が高かった」だけでは意味が無い。
大事なのは「これから出荷するソフトの信頼性は高いのか？」

既に運用されているシステムの販売であるとかであれば、
それはつまり「運用実績」であるかな。

「プログラム正当性の証明」ってのはサッパリ意味不明。

>>486
最近のテストツールは出来が良くて、異常系や例外系のテストなんかもできるらしいね。

ぶっちゃけ、80が言っていたのはプログラムを細切れにして、単純化されたものを
テストツールでガリガリすると言っている。

なんで別人になりすますの？

>>489
いや悪いが、最近、忙しくてレスしてない。

>>488
こま切れまですると、管理コストが逆に増えるから、
ほどほどに分割している。テストのために分割するのではなくて、
チーム開発なので結果的にそうなるだけかもしれないけど。

「ソフトウェアの信頼性＝クレーム処理にかかった費用の少なさ」
だけど、財務部門がほっといても評価してくれる。奴らはソフトを
金でしか見てない。

「これから出荷するソフトの信頼性が高いのか？」
なんて出荷しなくちゃ分からねい。これは、あらゆる手段を講じても
無理だ。できるという奴がいても俺は一生信じない。

運用実績は、極めて重要だ。実際に客が使って納得して信頼性って言う。
客と開発者のギャップが信頼性の欠如を生む。
よーは、開発者のテストなんて客からしたら気休めさ。

建築、機械、電気・・・・いろんなものになぞられてソフトウェアは
とらえられてきたが、結局のところ「ソフトはソフト」でしかないと思う。

ソフトは、極めて人間くさくて、泥臭い、だから厄介だと俺は思う。

客観的手法や統計で何とかなると本気で考えている奴を否定はしないが
俺はあんまり関心がない。

統計とか客観的な事実とかを突き詰めるのにすげー金使っても、
結局、プロジェクト内の「過労で疲れた技術者のミスの積み重ね」で
大バグは埋め込まれる。

100万件のテストケースを、休日返上でテスターにやらせたとしたらどうなる？
テストケースがいくら素晴らしくても、「疲れ切ったテスターの判断ミス」
で、バグは見過ごされる。

人間系を見直さないとだめだと俺は思っている。で、テスト自動化に
取り組んだってわけだ。少なくとも、テスターや開発者に対する
負担は減った。彼らに余裕ができた。良い仕事ができるようになり始めた。

テスト自動化による副次的効果の方が、重要なのかもしれん。

自動化されたテスト環境にもBUGはあるよｗｗｗ

テストを重視して、ただでさえ疲れ切った技術者にさらに仕事を
積む。そーやって、現場をさらに混乱に陥れる。

部分最適化だけじゃだめだ。バグを見つけた奴には給料を倍払うとか
しないとな。

技術者は、常に理屈で何とかなると思っている、何か良い手法があると
考えている。ただ、その手法を実行する人の振る舞いについては関心がない。

>>492
開発者が楽して結果的にバグがあるのと
開発者が死ぬ気でテストしてバグがあるのでは意味が違う。

テスト自動化で手の空いた技術者が、自動テストで取りきれなかった
バグを取る。

テスト自動化だけをやってるわけじゃない。

テスト環境をテストするのに同じだけ人と金がかかるんだよぉ♪

どうしてこう次から次へとマ板は自己陶酔するコテが湧くのか。
>80がおじゃばならまだいいけど、別人ならこんなのが複数いると思うだけでいやだ。

この業界の奴らは、頭は良いが、利口じゃない。
つくづくそう思う。不器用で要領が悪い。

>>496
おじゃばって誰のことかわからない。

おまえは「おじゃば」のファンなのか？なら、「おじゃば」のいるスレに行け。
俺はお前の相手をしてやれない。

難しい事を書くから頭の悪い >>496 が嫉妬してるんだろｗ
ほっときゃいい。

>>464
HAYST法はヘイスト法だよ
秋山さんは意外とマンガ好きなんだ

>>490
＞よーは、開発者のテストなんて客からしたら気休めさ。

お前自身は何がどうなったら「製品として出荷できる品質だろう」と判断するんだ？
客に対して何かを証明するのでなく、開発側の判断基準はどこにある？

KKDで何となくやって期限が来たらリリース。
潜在してるバグはクレーム来てから直せば良いや。
とそういうことかい？

>>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ

>>388はソフトウェアの信頼性を定義したぞ。そして、俺自身の中で>>388の主張に腑が落ちた。

90人が作成したコードを、実装内容も知らない、実装言語にも詳しくないようなテスター10人が
効率のよい品質の高いテストができるのだとすると、どう考えてもそれを各プログラマが実行
したほうが、より効率のよい品質の高いテストができる気がする。

>>503
プログラマは自分のプログラムには異常に寛容なので、無理です。

>>503
それも完全じゃないんよね
PGが仕様を把握してないとダメやし

ホワイトボックス、グレーボックス、ブラックボックス
どれがテストとして質が高いかなんて話に意味あるの？

それぞれに目的が違うんだから比べてもしょうがないと思うんだけど。

グレーって初めて聞いたよ

http://www5f.biglobe.ne.jp/~h-it/mlcont/mc0269.htm
>>507たまにはぐぐろうな

>>508
thx
ただ、現場で聞かないなー、と思ったんだ

>>502
>今日初めて見たが、みんな何か勘違いしてないか？
>テストで信頼性は上げられない、テストは
>「このプログラムにはバグがあるます」を実証するもので
>バグを沢山検出したからと言って、そのプログラムには
>もうバグが存在しないと言う実証にはならない。
>実際は逆で、統計的に見るとバグ密度の多いプログラムほど
>残りの潜在バグが多く含まれている。

テストはバグを発見するためのもだけじゃない。これはプログラマーの視点
だな。

テストはむしろ、要求したとおりに動作するか？が重要だ。
テストにパスすれば、そのシナリオ（操作手順）で、少なくとも
動作するという事を証明できる。

目的を見失った状態で、統計とか客観的な手法とかを持ち出すから
本質を見失う。統計は手段。バグ発見は、テスト結果。
ちゃんと整理した方がいいぞ。

テストの目的は、要求を満たしているかどうかを確認すること。

>>80はユニットテストを重視も軽視もしてないと言ってたが、
もしかして重視してるんだけどただ>>80だけがそれを理解していないんでは？

もだけ？

>>511は　>>80の会社は重視してるけど　ってことね。

>>511
ユニットテスト（単体テスト）は当たり前。軽視も重視もしていない。
重視したところで精度が上がるわけでもない。プログラマーの能力に依存
するからな。

プログラマーは忙しい。プログラマーに負担を増やしても全体的に品質が
落ちる。

ユニットテストを強化して効果が出るかどうかはその組織しだい。
俺は、限定的だと考えている。

プログラマーは均質ではない。
分析能力のある者、観察能力のあるも者、創造力のある者、忍耐力のある者
十人十色だと思う。分析能力や創造力はあっても観察能力がない奴も居る。
チーム開発は、各人の能力を補完し合って結果を出すものだと思うがな。

ごちゃごちゃ言わずに、優秀なプログラマーを金で雇ってきて、
自由にやってもらう方が結果が出たりもする。

重視・軽視 って言葉の基準があいまいだな。
ユニットテストだけを特別重視しているわけではない。くらいの意味合いかな？

>>515
特別重視しているわけではないってのも十分曖昧だと思うがな。
重視とか軽視とかは、相対的なもので基準を云々言うこと自体ナンセンス。
よーは、515が馬鹿だってこと。

相対的なものだからこそ、基準をはっきりさせろってことだろ。
他のテストと比べてユニットテストだけってことじゃん。

>>517
いくら頑張ってもお前の言ってることも80の言ってることも
曖昧なんだよ。お前らがテストをしても品質は上がらねーよ。

ということで終わり。

>>1
３割方終わった風な顔で、「コーディング終わりました。後はテストするだけです。」
これなら満足なのか？

プログラマーより身分の低いテスターが愚痴を言ってるだけだろ。

>>1
おれが言いたかったことを、代弁してくれて
心からありがとう( ´v｀)

>>519
そりゃどんな顔なんだよ

この業界に20年以上いるが、グレーボックステストなんて言葉初めて聞いた
そんなのがあるんだ

>>523
あるかどうかグレーです

>>523
みんなが勝手に名前を付けているだけで何が正しいとかはないと思うな。

ブラックホールテスト

モデルベーステスト
非モデルベーステスト
モンキーテスト（アドホックテスト）
静的テスト
動的テスト
単体テスト
結合テスト
システム・テスト
受入テスト
回帰テスト

機能テスト／機能網羅テスト
パフォーマンス・テスト
負荷テスト
障害テスト
セキュリティ・テスト

色々あるな。でもな。分類とかしてる時点で間違いの方向に行ってる
気がする。バグは細部に潜んでることが多い。これらの分類にすべての
バグが綺麗にあてはまらないから「想定外のバグ」が出荷後に問題になる。

bp = malloc(sizeof(Buff *));
これはどのテストで検知するべきバグだろね？

その手続きを持つ関数の単体テスト

じゃ東証は･･･

テストに関していえばtestabilityとかが末端まで広まる前のコードだった

>>527
でかいシステムの場合、分類しないとテストの目的がはっきりしなくなるのよ

>>528
ソースコードレビュー

>>527
例えば、パフォーマンステストとか負荷テストとかは所謂バグつぶし目的じゃない気がするが。

ていうかちゃんと分類されてないとまともにテストできないだろ・・・

おじゃばにそんなこと言っても無理

いや、いたって普通に分類してテストしてるよ。でもバグが減らないから
今やっているやり方が間違っているのかな？って考えているところさ。
よーは、学術的なアプローチに限界を感じてるんよ。

>>527
どのテストも、バグ潰しを目的としているわけではない。
バグ潰しは、デバッグでやるものだ。

> bp = malloc(sizeof(Buff *));
この手のバグは、デバッグの時にみつけるべきもの。
うちでは、Purifyとか使ってるけどね。

メモリリークチェックやメモリフットプリント、関数プロファイリング
などはツールでやるのが効率的だと思う。

529に１票
malloc()に渡すパラメータのサイズをチェックすべき

"デバッグ時"なんて、動作させて妙な状況が発生しないかぎりチェックしようが無いよ...

>>536
>うちでは、Purifyとか使ってるけどね。
I社の製品使うんだｗ

>この手のバグは、デバッグの時にみつけるべきもの。
デバッグの意味分かってるか、アホだろうｗ

ググってみた。

デバッグ
　コンピュータプログラムの誤り(「バグ」と呼ばれる)を探し、
　取り除くこと。

テストでは、バグを取り除くことはしないので、>>534 の言う
「バグ潰し」は、話の流れ的におかしい。

> bp = malloc(sizeof(Buff *));
> これはどのテストで検知するべきバグだろね？
このコードを書いたプログラマーの採用試験に一票。

軽視するわけじゃないけど、GUIのテストってむずくね？
どうすればいいんだぜ

>>540
その採用試験に
>この手のバグは、デバッグの時にみつけるべきもの。
と回答したら、その人は合格するか？

>>539
安価ミス？

偽物が湧いてるんじゃね？

>>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ

>>536
＞いや、いたって普通に分類してテストしてるよ。でもバグが減らないから
＞今やっているやり方が間違っているのかな？って考えているところさ。
＞よーは、学術的なアプローチに限界を感じてるんよ。

学術的アプローチが何か知らないけど、単にテスト設計がショボいだけじゃね？

とりあえず、ITとSTの命令網羅率と条件網羅率は幾つよ？
網羅率も出してないなら、テスト仕様の質をどういう「学術的アプローチ」で出してみたんだ？
（網羅率が全てじゃないと思うが、うちのテストの評価では基本的な指標の1つとしてるので）

テスト仕様の質を評価してなかったら、
たとえどんな(学術的な？)手法でテスト結果を評価してみても意味無いぞ。

>>545
おじゃばは都合の悪いことはスルーデフォ

お前ら楽しそうだな、システム組むってやっぱ分業してナンボだよな
一人で設計して一人で組んで一人でテストしてデバッグする俺ってなんなんだろう
こんなんでいいシステムが組めるわけないよな。何が少数精鋭だよ
社長はそんなもん一人で出来るとか言ってるが、アンタ自身が一人でやったことないだろ
自分でやったこともない事を人に押し付けるなっつーの。ホント意味わかんねーな。どーよこれ

俺も、一人で設計して一人で組んで一人でテストしてデバッグする俺。

自分からテスト専門です、って宣言してる派遣テスターって何なの？

将来プログラマとかSEになりたい、とかならわかるけど。
向上心ないよね、頑固だし。
そういう派遣テスターって、仕様書は読めない、
テスト仕様書も作れない、テストプログラムも作れない
やれることは「テキトーにプログラムを触る」ことだけ。

俺は派遣プだけどさ、こういう派遣テスターがいると
派遣全体がバカにされるんだよ。
テスト専門派遣なんて氏んで欲しいよ、まったく。

今日も正社員の人が派遣テスターに仕様書を読んで
テスト仕様書を作ってください、って説教してたよ。
その派遣は頑固に「何故、仕様書が必要なんですか？」って
反論してたから、きっとテスト専門派遣テスターだな。
仕様書も読まず、テスト仕様書も作らず、ただテキトーに
プログラム触るだけで給料もらおうなんて頭おかしいんじゃねーの？

あ〜あ、あの派遣テスターが3ヵ月後に切られるまで、
仕様書も読まねーでテキトーにテストしたバグ票がまわってくんのかよ。
そんな糞なもん、読んで処理する派遣プの身にもなってくれよ。
うわ〜、しかもそいつが切られる3ヵ月以内に中間納品あるじゃねーか！
テスト仕様書もなしにテキトーにテストして納品か。
中間納品後にソッコウクレームでデスマ必至だな。俺の休みも返上かよ。

派遣専門テスターさんよ、少しは向上心持てよ！
頑固な性格直して仕様書読めよ！テスト仕様書作れよ！

長い

>>550
低レベルな話だなあ

そんなバカ派遣テスターなんか契約終了を待たずにに切ればすむ話だろ

正社員がテスト仕様書を書くように指示をだしているのに反抗しているんだから
即日クビでもなんの問題もないよ

>>551-552
>>550 はコピペだよ

【頑固】派遣テスターの人格問題【向上心ゼロ】
http://pc11.2ch.net/test/read.cgi/prog/1207581904/

まずはテストの工数を軽視する者どもをなんとかしないとな

急に80が来なくなったな

おじゃばはOOスレに戻りました

相変わらず羞恥心の欠片もないんだな

>>556
お久しぶり。さすがに、２ちゃんばっかやってるわけじゃないし・・・。

近頃のプログラマーも「未経験者歓迎！」で採用されたど素人が
平気で派遣でやってくる時代だからな。テスターにプロ意識を
強要しても無駄。

金だけ欲しいなら、テスターになっていっぱい残業したらいいわけで。
リリースしたものにバグがあったらプログラマーの責任って言い張れば
良いわけで・・・。

テストを軽視するな！とか理屈でごちゃごちゃ言っても仕方ないと思うんよ。
重視しても仕事は楽にならないし給料が増えるわけじゃないし。。。
結局、テスターは頑張らないよ。プログラマーだってテストする十分な時間
ないしね。

俺は、そういう人たちを管理してたりしてるんだけど。
人数が多いプロジェクトでは、1/3は頑張るけど1/3の人はさぼる。

全員優秀なチームは存在しない。予算も潤沢に無い。
仕事のやり方をそのままにすれば、何かを重視し何かを軽視せざるを得ない。
となると、テストがどうしても軽視されてしまう。
仕事のやり方を変えるのは、製品開発より難しい・・・。
このジレンマからのがれる方法はないものかねぇ。

>>559
残りの1/3は？

以下を参照のこと

働きアリの法則
2-8の法則
2-6-2の法則
パレートの法則

未経験者歓迎で入ったド素人コーダーだけど単体テストだけは念入りにやってるよ
というか馬鹿だからテストから書かないとコードが書けない罠ｗ
人より手間かけてる分作業の速度は遅くなるけど多分省いても大して速くならんとも思う

>>562
単体を大事にするその気持ちが大事なのです

　　　　　　　　　　　　　　　　　　　　　　　　みつぬ

いつかみんなに認められるよ、その努力は

優秀なプログラマーを確保できないプロジェクトチームでは、
テストを重視しているのかもしれないなぁ。
プログラミング能力ってすぐに向上しないから、テストくらい
ちゃんとしろよってことなのかな。

そういえば俺も初めてのプロジェクトではまずテスト書くのから始めたなあ。
まあそれは勉強の意味合いがほぼ100%だったけど。

事務より簡単で誰でもできる仕事なのに時給は技術者！
ITテスターで稼ぐための情報を交換しましょう。

☆派遣先は大企業じゃないと駄目です。中小だとテスターもプログラムの仕様が
　わからないといけないとかテストプログラムを書けとか言われちゃいますよ。
　大企業ならプログラムを触るだけのテスターでも大丈夫。

☆派遣先ではテスターはプログラムを触るだけでいい、
　そんな空気を作っていきましょう。仕様書読んでください、
　とか言われたら「なんでテスターが仕様書読むんですか」って食い下がって。
　プログラムの仕様書を読んだり、テストの仕様書を書いたりするのは大変ですよ。

☆普通にプログラムを触ってテストしてると、何をテストしているのかわからない、
　とか言い出す人、いるんですよ。プログラマとかってこういう人多いです。
　そういう人は上司にあることないこと告げ口して追い出しちゃいましょ。
　人事権のある人とは仲良くしておくことが大切。
　
☆納品して何かあったら大変だからとプログラムの仕様書を読んだり、
　テスト仕様書を書いちゃうテスターがいますけど、
　こっちもやることになるからすごく迷惑。
　テスト結果の責任は担当の正社員にありますよね。
　納品後のクレームは最終チェックを怠った正社員が悪いんだから
　派遣は関係ないです。　

>>559
＞このジレンマからのがれる方法はないものかねぇ。

軽視して良い工程なんて開発に存在しない。

十分な金と期間を客から引っ張って、ちゃんと人をアサイン出来ない
営業と管理層が悪い風にしか見えないが。
改善すんのはソコからでしょ。

「何かを重視し何かを軽視せざるを得ない。 」と管理している自分が言う状況なら、
出だしから「これは無理じゃね？」っていう開発期間で仕事を受けてるってことでしょ？

1/3サボるのが分かってるなら、2/3で出来るスケジュールで受けろよ。
何そんな意味無い数字書いてんだ。

＞近頃のプログラマーも「未経験者歓迎！」で採用されたど素人が
＞平気で派遣でやってくる時代だからな。テスターにプロ意識を
＞強要しても無駄。

なら派遣使うなよ。

>>567

>軽視して良い工程なんて開発に存在しない。
正論だけどね。そこを一歩踏み込んで考えないと実践では通用しないよ。

昔は「設計」「実装」が重視されていた。プログラマーのスキルと
モチベーションが高かったから、それで、結構うまくいっていた。
単体テストは、当たり前だったから特に話題にもならなかった。

でも、今では、ソフト技術者は3Kで「不人気」となり優秀な技術者は別の
業界へ流れて行く。インド、中国、ロシアの安いソフト労働力の台頭も
追い討ちをかけている。

日本のプログラマーのレベルは、以前からするとずいぶん下がった。

そもそも、「単体テストを重視する」という事自体が、俺からすると
滑稽なんよ。「うんこしたら手を洗う」くらい当たり前のことを
ワザワザ言わなくてはいけない時代になったのが残念だな。

言わなきゃ出来ないレベルの低い奴に、言って分かると思うか？
出来るやつは、言わなくてもやるもんだ。

単体テストをしないプログラマーにいくらプレッシャーを与えても
良い結果は得られないよ。それなら、仕事のやり方を工夫する方が
よっぽどましさ。

>とか言われたら「なんでテスターが仕様書読むんですか」って食い下がって。
食い下がる以前に正社員に逆らったらクビだろｗ

>正社員に逆らったらクビだろｗ
>正社員に逆らったらクビだろｗ
>正社員に逆らったらクビだろｗ

バカ？

>>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ

>>571
さみしいんだねｗ

おじゃばくさい返しだな

>>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ

テスターって気楽でいいよね。
自分のバグじゃないし、動かしてダメダメ言っておけばOKみたいな感じ。

その代わり、実装周りの人間が帰った夕方から、
その日の更新分含めたテストやってたりして、
夜間シフト状態になってたりした事あったけどｗ

>>575
嫌われるのが仕事だからｗ
プログラマーは絶対にバグを出す。
悪いのはプログラマー。

>>576
プログラマーは24時間労働がデフォ。
夜間シフトは、金儲けにうってつけ。

まだやってんのか・・・糞スレはsageでやれ

おまえもな

お前2chは初めてか？
力抜けよ

おまえもな。

私見だがテスターって基地外な奴のほうが優秀だと思う。
・常識では思いつかないような操作をする。
・人の話を聞かない。（話で誤魔化すことができない）
・理解力が無い。（おのずとヘルプ等を細かくしてしまう）
・集団の中で浮いてる。（無駄話をせず黙々と作業）

開発としては関わりたくないのだけど、
客観的に考えると良い製品ができるような気がする。

変わり者くらいにしておけよ
基地外が適している仕事なんかねえよｗ

本物の基地外と接した事が無いからそんな事言ってるんだと思うけど。
先ず、仕事として何かをやらせる事自体が無理。

>先ず、仕事として何かをやらせる事自体が無理。
それは派遣テスターも一緒だろ
「まず仕様書を読んでテスト仕様書を作れ」と仕事の指示を出しても
まったく手も足も出ないバカばっか

それは契約で仕事の範囲をちゃんと決めてないんじゃないか？

テストオペレータとして雇ってるのか、
テスト設計からやる技術者として雇ってるのか、
はっきりしない限りはなんとも言えない。

>>586
つ「作業内容：テスト一式」

オペレートしかテスターなんてイラネ

>>588
おまいのようなケアレスミスの多いマにはテスターは必要だろｗ

逆に適当に触るだけのテスターじゃケアレスミス位しか発見できんな

仕様策定の段階からテスターと一緒にレビューしてる人いるの？

>>585
派遣テスターで、テスト仕様書から作れるヤツなんて使ったことねーけど
流石にテスト仕様は、仕様策定した連中が書くでしょ
要求仕様わかってない連中にテスト仕様書かせてどうすんのさ

なんのために仕様書があるんだよ

>>593
お客さんに古紙回収してもらうため

>>592
典型的な底辺低賃金会社の発想だな

俺の名前をテストデータに使うなバカ上司
俺は全然タッチしてないシステムなのに
マジで頭おかしいだろ

>>591
ちゃんとやってる所は必ずと言っていい程参加させてるね。
テスト設計者を

>>596
名前覚えて貰ってるんなら結構なことではござらぬか

画面見て結合テスト仕様書つくってください
って同僚がベンダさんに言ってた

何をテストするんだろういったい

要求される「品質」にも拠るんだよな。

100万単位の人間が使うようなブツなら、テストは万単位でガッツリやらんとヤバいことになる。
万単位のテストをやるなら、まず8割9割のテストは自動化しないと何ともならんわ。
で、コードを修正したら一度自動テストを回す感じ。
理想としては、テスト設計書の概要はWordとかでもいいんだけど、詳細設計はExcelとかでマクロ組んで
テストデータを自動で吐いてくれるような感じにする。

業務系の仕事とかで、客とねんごろって世界なら、テストが適当でも何とかなる場合がある。
DBのデータが�d�jみたいなのさえ出なければ、まああとは酒の場の寝技。
こういうのを技術者とは言わんけど、それが通じる世界もあるんで。
ただ、業務系だけだね、これが通る世界は。

>>390
「クリーンルーム」じゃね？
徹底的に個々のコードレビューをやるって奴。
IN入れてOUTの結果が期待通りか否かを見る、って方式じゃなくて、
コードのロジックに誤りがあるかないかをプロが検査するって感じか。

OpenBSDはそういう手法だと聞いたことはある。

>>601
プロの定義がおかしい希ガス

>>598
テストしながら「(俺の名前)がおかしい」ってブツブツ言ってるんよ
呼び捨てで

普段からそういう人間だってのは知ってたが、
そういう嫌がらせされたのは初めてだ

>>603
名前にダメ文字入ってるんじゃね？　「十」とか。

ダメ文字チェックなら「図『表』」「『能』力」「『十』番」あたりを使えば
いいだけなんだけどさ。

>>1
コーディングが終わってやっと３割終わったかどうかってところだろが。

てことはさ、テストファーストでテストコードを書き終われば
本体のコードは進捗ゼロでも７割終わったと言っておｋ？

テストで初めて発覚した仕様の洩れを、いまさら作り込めと言われて、最近鬱。

>>605
テストファーストはテストコードだけを
最初にコーディングするものでは無い訳だが？

言葉ばっかり一人歩きすると勘違いする奴が多くて困る

そもそも本体コードをテストしないことには終わらんだろw

派遣テスターによるいい加減なテストが衰退しつつある

テストを一切せずにリリースする国産MMORPGもあるのにな

ファイナルファンタジーXIの話はもういいから・・・
あれは試験ゼロにすることで経費浮かして利益あげてるんだよ。

それにしても、実装してない機能のバージョンアップしました報告はすごかったよなww >FF11

某銀行合併時もATMとかちゃんとテストしてなかったぽいしね

>>611-612
これか・・・すげぇな。アップデート項目チェックとかしてないんだろうか？
ゲーム開発って楽そう。

ttp://www.playonline.com/ff11/polnews/news12783.shtml

>■一部アイテムのアイコングラフィックが変更されたお知らせに
>　おいて、実装されていないアイテムが一覧に含まれておりました。
>　脳汁／狡賢い脳汁／幸せの人参汁／まろやかな鳥汁／濁った血汁

>>605
それだとまだテストコードのテストが7割残っているから、
実は全体の7割の3割、つまり2割強しか終わってないんだな。

テストコードの正しさはテストしながら検証されていくという、
テスト結果がNGなら、テストか実装かどっちかが間違っているわけ
だから。全部OKになった時点で実装とテストの信憑性もあがるけど、
これで安心できるかどうかは、テストの網羅性にもよるわな。
あと間違った実装を間違ったテストに通してOKになる可能性もなき
にしもあらずだな。

テストの正しさを検証するのはテストのレビューじゃねの？
うちじゃやるけど、他んとこじゃあんまりテストのレビューってやんないのかね。

>>617
書類に関するレビューは必ずやる。
それがソースコードでもテスト検査書でも同じ事。

>>618
休暇届もやるのか・・・・

ムチャクチャNG出されそうだ･･･・・

>>619
ああ、休暇届に不備があってプログラムに不具合が出るならやるさ。

この日確かレビューだったよね？よってNG。

とかか。

>>618
俺の前の会社は「テスト検査書なんかいらないんだ！テストというものはどんどん触るのが仕事なんだ！」
という社長の方針でレビュー以前にテスト検査書が存在しなかったけどね。

まあ、結局倒産して社長一家は行方不明だがｗ

俺的にはまず全体できに荒くテストしてから
細かいところをテストするのがいいと思う。

テスト検査書の正しさは誰が検証するんだ

SQA部門とコレまでに改善されてきた(はずの)システムが検証する。

テスタがプログラマからテスト仕様書を貰えると思ってる時点でおかしい。

折れの職場はこうだからバグが減らない。
んで営業がキレる。折れのせいじゃねえよ。構造的欠陥だ。

テスト仕様をプログラムから起こしちゃあ、プログラムの正当性が判断できないよね。
そりゃそうだ。
テスト仕様はシステム設計書やシステム仕様書から起こす物だよな。

>>623だけが素人くさいな

項目Aを実行する　テスト内容Aの結果が○○になる
項目Bを実行する　テスト内容Bの結果が○○になる
...

これをテスト仕様書とかいってももってくる35ぐらいのおっさん
いるんだけど、テスト軽視とかのれべるじゃねーよｗ

>>629 その人に、それ1回やってみましたか？って言ってみたらどうかな。

UTが内部設計、Itaが外部設計、STが要件定義書のテストだよね？

仕様書書いたあとに仕様書からテスト紙を起こす
そのあとコーディング
こっちの方が絶対バグが減る

>>632
設計はどのタイミングで

>>633
用件定義はどのタイミングで

>>634
契約金額はどのタイミングで

>>631
ItaとかItbってIBMかなんかの方言だったような

省略表現とか横文字を無意味に乱発する奴は
折れはあまり好きじゃないな。

日本語で適切な表現があれば、最初からそれを使えば
沢山の人に読んでもらえる。

>>629
ファイナルファンタジーXIスタッフ乙

>>582
その基地外に関わる奴のストレスを考えたら大変なものだろうな。
うちの優秀な人間を潰されたくないからそー言う奴は使わない方が無難。

下請けに基地外が紛れ込んでる分にはOKだが、失敗したら賠償請求するよ？

ソニー系列で仕事した人に聞きたいんだけど、
ソニーって、ぜんっぜんテストしてなくね？
俺の部署の上司が元ソニーなんだが、テスト工数を全く見込んでくれない。
PS3のファームバージョンアップにも、
ちょっと動かせばわからないバグが平気で仕込まれてるし

×ちょっと動かせばわからない
○ちょっと動かせばわかるような

テストしてないは言い過ぎ

テストしていない＝検仕無しでプログラムが動けばOKとしている

ソフトウェアが存在しない時代からあった古い会社ではありがち

>>644
そういうテストをしていると会社自体が存在不可能になり、
消滅していくので、実際にはほとんどない

たとえなんとか存在できても結局受託じゃ
瑕疵保証で採算が合わず、社員は毎日他人に会社に出勤してるｗ

S◯NYってソフト関係は丸投げしてるでしょ？
日立系あたりに。
そっちでテストはしてるんじゃねえの？

>>646
目立から関連情報システムに○投げしてるよｗ

で、勉強するのにおぬぬめの本はあるの？
何かスクール的なのとか行けって？

実戦＆実践あるのみじゃね？

本は自分で見て選ぶ
スクールは基本的に金の無駄
ただし、時間を金で買うなら、物によっては選択肢に入れても良い

仕様書どおりのテストをするのが仕事。＞つまらん
いやらしい境界条件や設定条件を組み合わせて、バグを見つけるのが趣味な俺。

>>651
至って正常だから安心しろ。
変態的なバグ出しだと、動作中にコンセント抜くとか平気でやるからw

>>652
フォールトトレラントシステムでは準正常系試験かとｗ

カスSEが書いた試験書通りに試験するよりも、
ベテランPGがランダム試験したほうが効率的にバグ出せるよな。
でもそれを認めて生かしてるテストプロセスって世界的に見ても存在しないような。
日本人の職人技をプロセスとして体系的に確立することは出来ないんだろうな

JCBカード決済に障害

>>654
バグ取りとしてはその方が効率いいんだろうけど
客へのテスト実施内容報告としては愚鈍なやつが書いたような
単に全U/Iに同じことするような網羅系テストの結果資料が
絶対必要なんだよな・・・

特に最近に品管きどり連中はうるさい

亀だが>>649 >>650�dｸｽ。

意識改革やってみるわ。燃えてきた。
俺をテストしてやるっ！！

>>656
同意。
泳がせとくだけで勝手にバグ見つけるテスタって居る。
しかし、クライアントへの提出物として程々網羅率の高い項目書って要る。

で、ランダムテストでバグが出てからその手順を項目書に織り込むなんて
アホらしいこともやらざるをえないことがあるよ。

>>658
テスト項目にない内容が不具合票にあがってるぞ！
とかつっこむ品管とかもう、巣へ(・∀・)ｶｴﾚ!!と・・・

>>659
客先からバグの報告が来ると
テスタは何やってんだ、とか言い出すんだろ？

最初からザル試験書なんだろ。

>>654
ランダムテストのほうがバグが出るってw

そりゃ単にテスト仕様が低レベルなんだよw

お前の会社、年収500万前後で頭打ちだろw

テスターで1000万超えてるやつっている？

常に悲愴感
自分のチームを守りたいのは分かるけど
最後まで人の話を聞いてくれ

ニートにバグ１個３００円でやらせろ

SEが試験書なんて作らずにテストコードを直接書けばいいのに
仕様→試験書→テストコードなんて伝言ゲームみたな事なんかありえん
で、上に提出する書類はテストコードから自動生成すればいい
どうせ碌に読まないんだからBDD用フレームワーク使って書いたテストから
辞書をチューンしたコリャ英和とmecabを使って生成してバレないだろうし

SEが違えばテストコードも違うんだなこれが
それだと上に提出する書類はSEの数だけシナリオができて
支離滅裂な文章の羅列になっちゃう

SEの書く試験書なんて、

○○機能テスト・・・○○機能が正しく動く
△△機能テスト・・・△△機能が正しく動く
××機能テスト・・・××機能が正しく動く

こんなもんですから。

SEXXテストか

SEXとは
SEがX(ﾊﾞﾂ=ｲﾗﾈ)という意味ですか

境界テストとか、異常値テストとかしないの？

運用開始後テストの為のテストですよ。

検収でこのSEﾂｶｴﾈということです。

>>666
上でExcelとpowerpointいじくってるだけのクズが、
開発で使う言語でテストケース書くとか、出来るわけないし

要求しても、VBAでよく解らないコードが出てくるのが関の山ｗ

テストは軽視してはいかんぜよ

俺はあえてバグを残したままテストする時あるな。

その方が油断しないのでテストがきめ細かくなる。

最近、まともな仕様書も書けないようなのが上にいるからな
そもそも仕様書もないからユニットテストもやりにくい
ユニットテストをＰＧに強引にやらせるのはかまわんけど
項目もこっちで作らなきゃいけないのは話が違うよね？

めちゃくちゃに追加したコントロール一覧はお前が作れよ

って問題もあって開発の請負は絶対にやりたくないな
作ってやるけどそれにかかる金と時間は全部お前が出せって感じ
そうでないとやりたくない

コードが全て
仕様書とか書き物は意味なし
よってテスト不要
作ったもんを使え
…そう抜かすアホが居る。

要件を仕様として書き出して合意を得たうえでコードに起こし仕様どおりに動くことを確認するのがテスト。
バグを見つけるためのものでは無い。
あのアホにはテストはバグを見つけることとしか見えてない。

制約論理プログラミング言語とか使っている人なんだよ多分
コードが書けた時点でドメイン内で正しく動作するのが証明されている、または
コードが形式的な証明と1対1対応しているような言語
まさかalgol派生の手続型言語を使ってそんな事を言うような人はいないでしょう

仕様を紙に起こしたりされると拒絶するかバカ正直に実装する。
せめてテストで確認しようと項目を挙げるとアホかと罵る。
要するに何の制約もされずに気ままにコーディングして自己満足したいだけ。
自分仕様で実装する。
そして出来上がってから仕様が固まると我が物顔で胸張って言う。
｢すごい手戻りですね｣

ドキュメントも重要。
テストも重要。

仕様書がしっかりしてりゃＰＧ側はなんの問題もないけどね
でも、作ってみなきゃ矛盾が見えないってのもわからなくもない
でも、それを全部に責任にしようとするから戦争がおこる
仕様書ないのにこっちにテスト仕様書作らせようとか
結構キレるのわかる気がする

ユニットテストで横に全画面のコントロール
縦にチェック項目５０個ぐらいで１００００個超えるテスト作って
とても流用できないような表を作るのが俺の趣味
貼り付けて仕様書完成なんて絶対にさせない

テストの対象はコードじゃなくて仕様や要件だということ。

単体テストと結合テスト、機能テストは目的が違う。

>>685
仕様書に全コントロールの仕様が書いてあればそれも可能だけどねｗ
全角、半角、ひらがな、カタカナ、英数、少数、文字数、
最小、最大、タブ、エラーメッセージ、補正、・・・
全部かけるもんなら書いてみればいい

>>686
違うのは範囲だよ。
テストの目的はひとつ。
単体→結合→機能と分けるとするならば、
それらは通過点。

>>687
コーディングが終わる時点で仕様に抜けがあるようでは仕様書をまとめる人間もプログラマも失格。
その先を急ぐばかりに後に時間とカネを浪費する。

>>688
ちょっと俺んとこの職場きて担当者に言ってやってくれ

ちょっとスレ違いだけど、コードレビューしてたらPMが乱入してきて、
どうせテストするんだからそんな無駄なことすんな
馬鹿な働き者は何もしない馬鹿より害が大きいんだぜ
って妨害しやがった。

ちなみにそいつはプロジェクトも末期になってから思いつきで
仕様変更して、現場を混乱させる悪癖があることで有名だ。

killしろ

テストってのは、その前にちゃんとしたクオリティで作ったものが、
ちゃんと「動くこと」を確認するステージであって、
とにかく形だけそれっぽいものを作って、テストでちゃんと動かないところを
洗い出すってのは間違いだと思うんだ。

うちの会社、後者のやり方だから、もういや。

テスト自体にもいろいろステージがあると思うんだが


まあシステムテストの段階で単体テストやってるようだと大問題だが

ステージが限量されてないのが前提で

>とにかく形だけそれっぽいものを作って
スタブのことね
>テストでちゃんと動かないところを
>洗い出すってのは間違いだと思うんだ。
TDD否定ですか？
>うちの会社、後者のやり方だから
TDDを実践してる会社か、なかなかいい所じゃないの？

おまい、TDD言いたいだけちゃうんかと…

TDDってなんですか？
もちろんググったりなんかしません

Tokyo
Disney
Destroyer

>>697
通報しました

>>696
逆DDT

>>694
お前全然わかってないんだな

いや待てよ、単にネタなのか
こりゃ騙されたなｗ

なにがわかってないのか詳しく

ユニットテストって明らかに成り立つ場合でもいちいちテストケースって書かなくちゃダメなの？たとえば、引数に範囲外の数値を入れたらXXXというエラーコード返すとか。関数にそういうif文あるんだから返すに決まってると思うんだが・・・やっぱり明示的に書きます？

そういうコードができてから書くテストってあまり書く気がしないんだよね
なんというか事務的処理のような面倒臭さがある
それならば逆転の発想でコード書く前にテストを書けとか言われてるけどそれもそれで面倒だし

>>701
おれの気持ち

ってかこの業界、相手の気持ちなんて考えたらやってられねー

>>703
やっぱりすごく事務的だね。。。
実際はエラーコード返すif文が本当に書かれてるかテストで確かめるってのが正当な方法なんだよなあ。

ブラックボックス

Javadoc等の為に、コメントに仕様を丁寧に記述して…

あぁぁ・・・　ああぁぁぁああーーー…

うわぁぁああぁぁーーっっ！！！

>>707
javadocってそんな分かりやすいか？
（まあ、分かりやすいかは記述している内容次第、といわれればそれまでだけど）

昔のVBなんかで使ったhotdogを思い出してしょうがない・・・


って、>>707が叫んだのは1/02だからか？？

>>708
＞javadocってそんな分かりやすいか？

規定のフォーマットで書けば、規定の出力が出てくれるのでｳﾘｼﾞﾅﾙなものよりかは
分かりやすい。

今行ってる現場のPLがなんか勘違いしている。
コーディング8割完了って報告したら、「じゃあ単体試験は5割ぐらい完了ってことかな？」ってさ・・・
コーディング中のTry&Errorはテストではないですよ？
こいつ、40近くにもなって何を言ってるんだろうって思いました。

>>710
>コーディング中のTry&Errorはテストではないですよ
至極まっとうじゃねーかw

コーディング完了＝単体試験完了だってさ

>>712
絶対確実に100%達成は不可能だが、TDDしていれば
単体試験完了＝コーディング完了に限りなく近づくだろ

抜けたところは、結合までにテストケース追加すれば
いいだけだし。

お前が糞だってことをきちんと理解しろ、この豚野郎が

テストの本で初心者に一番良い本教えてください

>>702
書くべきだろ
実は不等号の方向間違えててっていうのがチェックできないじゃん
っていうか俺それ何度もやってるしｗ

テストデータを作るのも困難なんだよね
でも、そのデータ作ってるうちに別の問題も発覚したりするから
あながちなめたものでもないな

テスト期間はほんと面白くないね。
これを楽しくするアイデアを下さいな。

>>716
レアバグを発見したらみんなで胴上げ
経費で昼飯代を出す（カレー限定）
とか特典をつける

エロ掲示板にあるような、殿堂入り機能付き掲示板でバグを晒すとか。
殿堂入りしたバグ発見者に何か褒美やるとかw

茶番劇にまた付き合わされる俺の身にもなれ

>710
うちの40代園児ニアもまさにそれ。

何度テストの重要性とか説いても「そんなの実機で動かせばいーじゃん？」であっさり却下。
ユニットテストという単語すら知らない癖に「これ使ったらソフトの品質が上がるんだぜ！セミナーの人が言ってた。」という理由だけで
某社のテストフレームワークを買おうとしているうちの上司。。。

最近さっさとこいつら見限ったほうがいいかもと思いつつある。

>>720
>「これ使ったらソフトの品質が上がるんだぜ！セミナーの人が言ってた。」
権威に弱いだけな性向が透けて見えるね
なんという騙されやすい人間

>>720
お前はそんな糞上司使われて
成果も出せない。結局調子の言い権威的な
セミナーのおっさんにすらまける糞野郎ってことだろｗ

上司が上司なら部下も糞だｗもっと自分がアホで
糞だということを自覚しろｗ

>>716
自分が作ったものを自分でテストするとひじょーにつまらんし、モチベーションが全く上がらん
人が作ったものを、色んなパターンで試験してバグ票をバシバシ発行すると、それなりに楽しめるぞ

みんなどんなソフトに関わってるの？
俺はWebブラウザとかだけど

家電全般

POSあぷりとか

Webアプリ関係と
FAX関係（ファーム寄りじゃなくて通信より）
あとはDBクライアントアプリ（VB）とかをちょぼちょぼ

スパムジェネレータはwebアプリって言ってもいいのかなぁ

テスト

ユニットテストで中途半端なテスト書いて満足してるゴミは死ね

たしかに、どんな簡単なコード(たった一行)でも
そこから予想もしなかった事態が引き起こされることはある(あった)
テストを怠るとえらい目にあう

テストは開発だね。

もうテストなしの開発なんて考えられないよ。

半端にプログラミングが上手くなるとテストサボるようになるな。

単体テストは手間がかかる上に、楽しくないんだよな

テストしたくないから開発したくない
中途半端な開発しかしたこと無いやつに限って、開発楽しいじゃん〜とか言って
技術系ぶるから腹立つ

仕事したくないから出社したくない
中途半端に残業しかしたこと無いやつに限って、仕事楽しいじゃん〜とか言って
社会人ぶるから腹立つ

テストはつまらん
なんでハード屋はどんどん楽になるのに
ソフト屋はコード量が増えてるんだ

それはお前が減らす努力をしないからだ。

仕様を把握し理解できてる人間ならテストする箇所は絞れるだろ
デスマで儲けてるクズ専業テスターとかはしょーもない項目までテスト対象にしてしまうけど
彼らが提出するテスト仕様書は項目の水増しが酷すぎる

だがその水増し部分をテストしなかったら
文句言うんだろう？

核心をついてないテストで鬼の首をとったように騒ぐのは
時間がない時には止めてほしい

いや、時間がある時でも止めてほしい

とれたのは鬼の首ではなくてＰＧのやる気

製品仕様的にそこは絶対に通らないって所をつついて悦に浸る

カバレッジは通せよｗ

動けばいいんだよ

いいわけないだろ？ほんとにテストしたのか！

・・・で最初からテストを全部やり直し

動けばいいんだよ。

ただ要求が、365日24時間不具合無しで、期待するパフォーマンスが得られるって
条件だけどな。 金も時間も全然よこさないのに要求だけは高いからな。

そら要求は高く出すに決まってるだろｗ
そこで工数見積もれずに見栄張るから後で悲惨なことになる

テスターの地位は向上させるべきだと思うよ。
オレはテスター歴１５年のベテランだけど、
実際問題、テスターの方がプログラマーより数段上。
プログラマーはニートやヒッキー、学生でもできるが、
テスターはスキルと常識のある社会人にしか勤まらない。
しかも、テスターは高い知識が求められる一方、プログラマーは
ルンペンにもできるし、ルンペンっぽいプログラマーも多数存在してる。
なのに、プログラマーは自分達がＳＥの次に偉いとか、
プライドだけは一人前。だから使えない。
オレらテスターのおかげでシステムが成り立っているのにね！

そうだね

test

TestComplete

正直なところ、昨今（というか昔からだが）の
「テスト偏重主義」には食傷気味。

「テストで品質を担保する」という考えは
ブスがゴテゴテの厚化粧をして男の目を誤魔化そうとするのと同じで
根本的に好きになれない。
・・・実際、やっている事といえば検収時に
客の目を誤魔化しているようなもんだし。

いや、言い直そう。テストが悪いのではなくて
修正が必要となった時に「修正の影響範囲を小さくする」事を優先し、
その結果、小手先の修正しかさせない文化が嫌なのかも
（その根本にある考え方が「テスト偏重主義」な訳だが）。
何だよ？「再テストが大変だから修正するな」って。
そんなに「テスト結果」って偉いのか？
100回の試行結果が合格だったとしても、101回目に失敗しない事を
「テスト結果」は保証してくれるのか？

実際、そういう修正を積み重ねた結果「良いシステムが出来た」という例を
見たことある奴いるか？

>>754
マジレスするとお前はテストの基本的なことがわかってない
的外れなことを言っているから、ちゃんと勉強したほうが良い。

ヒントをやると、テストの自動化について調べて来い。

>>755
>マジレスするとお前はテストの基本的なことがわかってない
確かに！　まさに仰るとおり。
俺も「テストはこうあるべき」みたいな方法論や技法については、
色々調べたつもりだが、でも結局分からなかった。
どうやったら分かるようになるだろう？
もう殆ど悟りの域だね。不立文字、教外別伝。

いや、正直「俺が分かる」必要すら無くて、結局のところ、
現場がテストを「神」のように持ち上げなくなれば良いだけなんだが。
（俺の経験上「プログラミングはなぁ、テストに始まりテストに終わるんだよ」と
いう奴のコードは「動けば良いジャン」的なものになっている確率が高いので）

そんなコードであっても、最終的には複数の人間が
廻り持ちでメンテするようになる訳。
そんなのが自分に廻ってきてしまった日には、
もう気分は「ババ抜き」とか「黒ひげ危機一髪」をやっている感じ。

お前の周りにいる奴がテストをわかってないんじゃ、
お前がわからんのも仕方ないなｗ

>>754 テストを通過した商品でも
問題があれば全部テスタではなく設計者の責任になる

そんなテスタは要らない

>>755 ここはマ板なんだから、さくっと答え(もしくはお前の意見)を
3行で書けよ。書けないから煽ってるのかと疑う。

書いてるだろ。自動化テストと。

>758
テストはすべての仕様を
完全に熟知しているとでも？

>>760
>書いてるだろ。自動化テストと。

そういえば昔、父ちゃんが
「将来 "自動翻訳システム" が出来るから、
お前は英語なんか勉強しなくてもいいんだよ」
って言ってくれたっけ。

まだかなぁ・・・

>>761 テストはやることに意味があるのではなくて
欠陥を未然に防ぐことに意味があるんではなくて？

節穴テストなら何もしてないのと同じ

テストそのものが嫌っつーか
クライアントを納得させるための
馬鹿みたいに着飾ったエビデンスを作るのが
死ぬほど嫌だ

つい元の状態を撮り忘れたまま直しちゃったら
直す前に戻して撮ったり
直す前の状態をコラして捏造するんだぜ
アホくさいよね

もちろん撮り忘れたのがアホなんだが

>>763
>節穴テストなら何もしてないのと同じ

多分、何か変なもの(口だけ達者な先輩とか)に
影響されてそうなってしまったんだと思うけど。

これ、知ってる？
自動車のエアバッグとか落下傘とかさ、
本当に人命に関わる装置でも、
実際は「完全なテスト」なんてやっていないんだよ？
（実際問題、テストしたら使えなくなるし・・・）

そういうパラノイア的な態度って、
逃げの戦術としてはそれなりに有効だけどさ
（特にお馬鹿な客の場合、逆に
「さすが○○さん。プロフェッショナルだね！」
なんて褒めてくれるかもしれないしね）、
でも、本気で信じちゃ駄目でしょ。

>>766 意味がわかりません。

>実際は「完全なテスト」なんてやっていないんだよ

人間乗せて追突する試験をしてないってこと？
それとも製品を出荷する前に作動させてないってこと？

>>756
ソフトのメンテ系の仕事なんて全部ババだろ。

日本のサラリーマンは誰もテストが神なんて思っとらん。
品管とか検収のチェックを通らんからそこにこだわるだけだ。
そもそもその人種には「品質が良いものを作ろう」
とか本気で考えてる奴は居ない。
で、そういう人種がほとんどだ。

それを何とかしたいなら、出世するなり独立するなりして
しきる立場に行くのが一番早いと思う。

>>767
出荷する製品自体でテストはできないってことじゃね？

それは当たり前かと

世の中の食品は
全部食べて調べてるんだぞ。

問題が出てない時期、対象は抜き取り検査だよ。

>>762
テストの自動化という言葉が
誤解を招くものだと思うけどね。

でも、自動翻訳とは自動の意味が違うのを
知らないから、この業界におけるテストというものを
わかってないといわれるんだよ

自動化テストって何よJUNITみたいなものか？

この場合の自動化テスト＝ファイル更新時に自動でテストを走らせること
開発マシンでファイル編集時、バージョン管理のサーバーにコミット時、デプロイ時などのことでは？

>>774
多分、他システムとの結合テストの際に担当者間で交わす
「おはようございます。今日はよろしくお願いします」
なんていう挨拶まで自動化してくれるんじゃないかな？

ジョークのつもりなのかもしれんが面白くない。

テストとかする奴って何なの？
バカなの？
死ぬの？
そんなくだらない事やってる暇あったらコード書けやクズ！


って先輩が言ってますた

>>778
その先輩、今すぐクビにしないとその会社来年には無くなってるぞw

「テストは空いている時間にやれ　時間が無い？　残業しろよ」


そいつは、残業の時間が長い＝やる気があって立派、と考えるタイプ

バグなく作り上げてやっとコーディング完了なわけだが、
コーディングした後テストするとか意味が分からん。