テストを軽視する者ども

**仕様書無しさん** · 2008/06/28(土) 19:49:20

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

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

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

この馬鹿者どもが。

**仕様書無しさん** · 2008/07/30(水) 23:09:50

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

**仕様書無しさん** · 2008/07/30(水) 23:10:08

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

**388** · 2008/07/30(水) 23:19:22

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

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

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

**仕様書無しさん** · 2008/07/30(水) 23:20:59

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

どこに書いたんだ？

**仕様書無しさん** · 2008/07/30(水) 23:21:48

駄目だこいつ。

**仕様書無しさん** · 2008/07/30(水) 23:22:33

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

**仕様書無しさん** · 2008/07/30(水) 23:23:52

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

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

だってさ

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

**仕様書無しさん** · 2008/07/30(水) 23:23:58

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

**仕様書無しさん** · 2008/07/30(水) 23:24:26

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

**仕様書無しさん** · 2008/07/30(水) 23:25:44

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

**仕様書無しさん** · 2008/07/30(水) 23:40:28

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

**仕様書無しさん** · 2008/07/30(水) 23:40:45

それ
なんて
みずぽ？

**388** · 2008/07/31(木) 00:05:03

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

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

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

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

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

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

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

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

>>419
???

**仕様書無しさん** · 2008/07/31(木) 00:10:24

>>420
聖徳太子現る

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

**仕様書無しさん** · 2008/07/31(木) 13:06:27

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

**仕様書無しさん** · 2008/07/31(木) 19:21:50

気のせいじゃなくね

**仕様書無しさん** · 2008/07/31(木) 20:04:06

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

**仕様書無しさん** · 2008/07/31(木) 20:39:41

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

**仕様書無しさん** · 2008/07/31(木) 20:43:06

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

**仕様書無しさん** · 2008/07/31(木) 20:48:28

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

**仕様書無しさん** · 2008/07/31(木) 20:52:52

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

**仕様書無しさん** · 2008/07/31(木) 22:14:57

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

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

**仕様書無しさん** · 2008/07/31(木) 22:18:40

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

**仕様書無しさん** · 2008/08/01(金) 03:03:06

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

**仕様書無しさん** · 2008/08/01(金) 03:36:48

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

**388** · 2008/08/02(土) 15:13:28

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

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

**仕様書無しさん** · 2008/08/02(土) 16:18:18

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

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

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

**仕様書無しさん** · 2008/08/02(土) 16:23:25

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

**仕様書無しさん** · 2008/08/02(土) 16:44:08

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

**仕様書無しさん** · 2008/08/02(土) 19:52:15

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

80 · 2008/08/03(日) 00:48:44

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

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

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

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

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

80 · 2008/08/03(日) 01:17:35

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

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

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

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

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

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

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

**仕様書無しさん** · 2008/08/03(日) 01:21:11

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

**仕様書無しさん** · 2008/08/03(日) 01:25:14

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

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

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

80 · 2008/08/03(日) 01:36:54

>>440
訂正サンキュー。

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

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

80 · 2008/08/03(日) 01:53:57

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

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

**仕様書無しさん** · 2008/08/03(日) 02:21:12

>>443
そういうプログラム引き継がされて爆弾爆発させたら
爆弾仕込んだヤツは無罪で爆発させたヤツが
全部罪をかぶることになる

この図式はなんとかならないかなあ

**仕様書無しさん** · 2008/08/03(日) 02:24:47

まあ、完全にBUGを潰す作業をいつまでも行っていたら、永久に製品が出せないからね。

完全にBUGの無いプログラムなんて存在しないからね。

もしBUGが一切無いプログラムがあったとしたら、それは検査方法が間違っているかテスト結果にねつ造があるかのどちらかさ。

80 · 2008/08/03(日) 02:45:56

以前にも書いたけど、テストだけを頑張るだけではだめだと思う。
部分最適化じゃなくて全体最適化ね。

以下は、テストではなく設計で逃げたケースの事例。

要求
「何年も24時間連続稼働させないといけないシステム」

設計
・非稼働時に定期的にこっそり再起動
・異常終了した場合はこっそり再起動

100%絶対に異常終了しない設計にするとテストが大変（証明できない）ので
設計で対策をこうじた。画面はあれ？ってな感じになるけどしばらくすると
復帰する。今のところクレームは無い。

**仕様書無しさん** · 2008/08/03(日) 10:42:24

>>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ

**仕様書無しさん** · 2008/08/03(日) 10:56:30

>>446
死ぬほどよくあるインフラ構成を偉そうに語る辺り働いてないか末端PGでしょ。
しかも、いきなり「非稼働時」とかまともに説明出来てないしｗ
インフラ構成に頼ったシステム安定性なんて無いに等しい

**仕様書無しさん** · 2008/08/03(日) 11:04:28

>>436
なるほど。>>388を直してみた。

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

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

**仕様書無しさん** · 2008/08/03(日) 11:45:31

>>449
あ　すげーまともな文章になったww

80 · 2008/08/03(日) 16:25:33

>>448
インフラじゃないけど・・・。全然、意味通じてないみたい。
俺、文章力自信なくしてきた。

80 · 2008/08/03(日) 16:51:01

>>448
真面目に読んでくれているみたいだな。
非稼働ってのは変だな。よーは、ユーザーがシステムを使用していない
隙間の時間ということ。

あと、システムと書いたけど厳密には、ソフトウェアシステムね。
自己診断機能と自己修復機能を連携させてるよーな感じのシステム。
実際には、ソフトが原因で異常終了することはないんだけど、
うちは、デバイスがくっついてるからそいつらのせいでシステムが
落ちたりする。

デバイス側の不具合により通信系が異常をきたした場合・・・・
ごめん、長文になりそうだから説明止めとく。

**388** · 2008/08/03(日) 18:19:20

>>439
>つまり、苦情の件数が少ないほど信頼性が高いと考えられる。
それは違う「原子力発電所の緊急炉停止システム」みたいな
稼動する事がまれで、稼動での不具合が致命的になるケースもある
苦情の件数など関係なく、信頼性は稼動前から求められている

>>436,449,450
テストとデバッグは別もの

**448** · 2008/08/03(日) 18:41:06

>>452
余計おかしいだろ。

>要求「何年も24時間連続稼働させないといけないシステム」
>非稼働ってのは変だな。よーは、ユーザーがシステムを使用していない隙間の時間ということ。
要求満たしてないのはお話しにならないよね？
上の文が出るって事は仕様を修正した訳でもないし。

>うちは、デバイスがくっついてるからそいつらのせいでシステムが
>落ちたりする。
この1行でもうお腹一杯です・・・

**仕様書無しさん** · 2008/08/03(日) 19:18:07

最近話題の地震速報とかか？

**仕様書無しさん** · 2008/08/03(日) 20:03:05

>>453
> テストとデバッグは別もの

正解。よくできました。
お前自分が書いたレスよく読んでみろ。
テストとデバッグの違いの何たるかが解ってない奴の発言だ。
勉強して出直して来い。

**388** · 2008/08/03(日) 22:14:06

>>456
それは間違い、俺が書いたものを理解出来ないだけの話

**仕様書無しさん** · 2008/08/03(日) 22:33:42

>>457
だとしたら日本語の書き方を勉強して出直して来い。

**388** · 2008/08/03(日) 23:17:19

>>458
それも違う、そっちが知識が無いから理解出来ないだけの話
システム工学系の話だから、知識がない人とは話が噛み合わない

**仕様書無しさん** · 2008/08/03(日) 23:27:23

理解出来てたら簡潔に説明できる。
理解出来てないから伝わらないと教わった俺はいい先生に出会えてたんだなｗ

**仕様書無しさん** · 2008/08/03(日) 23:35:54

なんかいつのまにか80：その他大勢
みたいな流れになってしまったな

おれとしては80みたいな特異な例よりも
ふつーに自分の現場では・・・みたいなノリが好きなんだが・

**仕様書無しさん** · 2008/08/04(月) 00:34:05

自分の話が分かってもらえないなら
まずどうすれば分かってもらうかを考えるべき

分かってもらいたいのであればな。

**仕様書無しさん** · 2008/08/04(月) 01:15:35

「信頼性」の定義が述べられない以上
>>388の話には何の主張も存在していない。
故に誰にも理解できるはずがない。

**仕様書無しさん** · 2008/08/04(月) 01:27:15

『HAYST法』ってなんて読むのか知っている方いますか？？

80 · 2008/08/04(月) 07:01:35

>>453
繰り返すが、ソフトの信頼性は、苦情の件数ではなくて以下と
俺は、考えている。
「ソフトウェアの信頼性＝クレーム処理にかかった費用の少なさ」

「原子力発電所の緊急炉停止システム」のような重要な機能は、
不具合が現実のものとなった時、クレーム処理に相当金がかかるだろう。
よって、網羅的にテストすべきだと思う。

対投資効果的に

誤解があるようだけど、クレームは、あくまでも結果。
「クレーム処理費用が高くつきそうな不具合を発生させる可能性のある
機能のテストケースをきっちりやれば、絶望的な数のテストケース全部
はやらなくてもいいんじゃないか？」と言ってるだけ。

クレーム処理で高くつく機能は、顧客要求にある機能とリスクに関する機能
とかね。

80 · 2008/08/04(月) 07:04:16

>>454
悪いが、たぶん俺と >>454 はドメインが違いすぎると思う。
「顧客要求≒真の要求」とだけ書いとく。

80 · 2008/08/04(月) 07:25:53

>>460
横やりで悪いが。
そんなに単純なものじゃないと思うぞ。

システムのアーキテクチャは複数のビューで相補的にモデル化される事が
ある。エンドユーザ、プログラマー、システムエンジニア、アナリスト・・・
といった立場によって、「見方」が違うわけ。

話題がプログラミングならビューは「プログラマ」だけで済むので
混乱は少ないが、「テスト」は裏返すと要求でもあるので、いろんな利害
関係者が混ざってややこしい。

理解にも種類があるんじゃないか？

80 · 2008/08/04(月) 07:44:33

>>464
俺は、ヘイストと読んでるが・・・。自信はない。
別に否定するつもりはないが、数あるテスト手法の一つだな。
HAYST法は、上流工程がパーフェクトな場合に生きる手法だと思う。

**仕様書無しさん** · 2008/08/04(月) 21:23:22

隔離スレが必要なレベルだな・・・

**仕様書無しさん** · 2008/08/04(月) 22:22:55

>>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ

>>338
能書き垂れる前に、ソフトウェアの信頼性を定義しろ

**仕様書無しさん** · 2008/08/04(月) 22:29:31

なぁ、なんで>>80は粘着しとんの？

それプログラマやない、評論家気取りの厨房や

**仕様書無しさん** · 2008/08/04(月) 22:42:26

>>459-471
お前らみたいに釣られるカモがいるからじゃねーか？
しかも連投だしｗ。ごくろうさん。

**仕様書無しさん** · 2008/08/04(月) 23:25:02

>>466
要求分類出来てないよ。
≒にならざるおえない要求とそうでない要求がある。
君が例で出した要求は後者。

コテ酉つけて専スレ立ててもらいなよ。
みんな弄るの飽きたみたいだし、このスレではもう君は不要。

**仕様書無しさん** · 2008/08/05(火) 00:46:38

を

**388** · 2008/08/05(火) 07:50:21

>>465
書いている事は分かるが、それは受注企業の論理だ
企業である以上、費用対効果を考えるのは当然だが
絶対の安全が求められるシステムでは通用出来ない
「人が死んでも生命保険に入っているから大丈夫」とは、絶対にならない

俺の考える信頼性は、当事者の論理では無く、第三者も納得出来る
科学的根拠、例えば
「プログラム正当性の証明」(数理論理学的根拠)
「運用実績」（統計的根拠)

当事者の論理では、信頼性の根拠にならない

**仕様書無しさん** · 2008/08/06(水) 23:03:41

>>475
人が死ぬ不具合は、「クレーム処理費用が高くつきそうな不具合」の
典型だろ。

科学的根拠は、ユーザからしたら「当事者の論理」となんら変わらない。
ユーザーが理系なら納得もしてくれるだろうが・・・。
「プログラム正当性の証明」が理解されることはないだろう。
「運用実績」は唯一の不具合で崩壊する。

「統計的根拠」って天気予報で降水確率100%でも晴れる日があるだろ。
天気予報が外れても訴えられることはないのは、みんなが納得しているからだ。
ただ、ソフトウェアの不具合は、統計的に信頼性が高いと何度言っても、
不具合は不具合なわけで客は決して「統計」を重要視しない。

プログラム正当性証明をバグを生む開発者がどーせやるんだろ。
「正当性を証明できる」なら「もともとバグはない」というパラドックスに
ハマるのが落ちだと思うがな。

**仕様書無しさん** · 2008/08/07(木) 22:07:06

テストは全ルート試験です。
もちろんifやswitchならば全てを網羅。
試験項目数が1000を軽く越えます。

**仕様書無しさん** · 2008/08/07(木) 23:52:07

夏休みだなぁ

**仕様書無しさん** · 2008/08/08(金) 20:36:54

全網羅で「1000を軽く越える」程度なら楽勝だろ

**仕様書無しさん** · 2008/08/08(金) 21:07:59

開発規模・期間に対しては辛すぎる
一日400件消化しろと？
常識的に考えてくれ・・・

**仕様書無しさん** · 2008/08/08(金) 21:09:17

そういう情報を後出ししてるようだからダメなんだよ

**仕様書無しさん** · 2008/08/08(金) 23:20:20

>>480
そんなん普通だろ
何自分だけ不幸のつもりになってんだよwww
テスト自体の効率のいい作業順番とか考えれ
まさか項目上から順番にやってたりしないよな？

**仕様書無しさん** · 2008/08/09(土) 21:19:18

作業順番を変えても期限は変わらない件

**仕様書無しさん** · 2008/08/09(土) 21:32:46

>>80のおじゃば
うざいし

**仕様書無しさん** · 2008/08/09(土) 21:43:04

一日400件なんて新人レベル

**仕様書無しさん** · 2008/08/09(土) 21:50:21

アプリのテストを言ってるようだが、
異常系や例外系のテストなんか網羅できんだろ

**仕様書無しさん** · 2008/08/09(土) 23:13:48

スレは読んじゃないけどさ。

>>476
そうは言っても、ある程度定量的に評価出来ないと、
成果物の信頼性が属人的になってしまって、管理出来なくなるだろよ。

475で言うところの「第三者も納得出来る」というのは、
客観的に評価しているということの表現であって、
ユーザが納得できるかどうかでは無いと思うよ。

個人的には根拠は何でも良い。
>>443なら「ソフトウェアの信頼性＝クレーム処理にかかった費用の少なさ」
それをどのように評価し、どのように見積もって、
これから出荷するソフトウェアの信頼性を評価するのか、
という話。
「出荷したソフトの信頼性が高かった」だけでは意味が無い。
大事なのは「これから出荷するソフトの信頼性は高いのか？」

既に運用されているシステムの販売であるとかであれば、
それはつまり「運用実績」であるかな。

「プログラム正当性の証明」ってのはサッパリ意味不明。

**仕様書無しさん** · 2008/08/09(土) 23:54:11

>>486
最近のテストツールは出来が良くて、異常系や例外系のテストなんかもできるらしいね。

ぶっちゃけ、80が言っていたのはプログラムを細切れにして、単純化されたものを
テストツールでガリガリすると言っている。

**仕様書無しさん** · 2008/08/10(日) 11:19:43

なんで別人になりすますの？

80 · 2008/08/10(日) 21:23:12

>>489
いや悪いが、最近、忙しくてレスしてない。

>>488
こま切れまですると、管理コストが逆に増えるから、
ほどほどに分割している。テストのために分割するのではなくて、
チーム開発なので結果的にそうなるだけかもしれないけど。

「ソフトウェアの信頼性＝クレーム処理にかかった費用の少なさ」
だけど、財務部門がほっといても評価してくれる。奴らはソフトを
金でしか見てない。

「これから出荷するソフトの信頼性が高いのか？」
なんて出荷しなくちゃ分からねい。これは、あらゆる手段を講じても
無理だ。できるという奴がいても俺は一生信じない。

運用実績は、極めて重要だ。実際に客が使って納得して信頼性って言う。
客と開発者のギャップが信頼性の欠如を生む。
よーは、開発者のテストなんて客からしたら気休めさ。

建築、機械、電気・・・・いろんなものになぞられてソフトウェアは
とらえられてきたが、結局のところ「ソフトはソフト」でしかないと思う。

ソフトは、極めて人間くさくて、泥臭い、だから厄介だと俺は思う。

客観的手法や統計で何とかなると本気で考えている奴を否定はしないが
俺はあんまり関心がない。

80 · 2008/08/10(日) 21:28:23

統計とか客観的な事実とかを突き詰めるのにすげー金使っても、
結局、プロジェクト内の「過労で疲れた技術者のミスの積み重ね」で
大バグは埋め込まれる。

100万件のテストケースを、休日返上でテスターにやらせたとしたらどうなる？
テストケースがいくら素晴らしくても、「疲れ切ったテスターの判断ミス」
で、バグは見過ごされる。

人間系を見直さないとだめだと俺は思っている。で、テスト自動化に
取り組んだってわけだ。少なくとも、テスターや開発者に対する
負担は減った。彼らに余裕ができた。良い仕事ができるようになり始めた。

テスト自動化による副次的効果の方が、重要なのかもしれん。

**仕様書無しさん** · 2008/08/10(日) 21:29:35

自動化されたテスト環境にもBUGはあるよｗｗｗ

80 · 2008/08/10(日) 21:32:19

テストを重視して、ただでさえ疲れ切った技術者にさらに仕事を
積む。そーやって、現場をさらに混乱に陥れる。

部分最適化だけじゃだめだ。バグを見つけた奴には給料を倍払うとか
しないとな。

技術者は、常に理屈で何とかなると思っている、何か良い手法があると
考えている。ただ、その手法を実行する人の振る舞いについては関心がない。

80 · 2008/08/10(日) 21:34:17

>>492
開発者が楽して結果的にバグがあるのと
開発者が死ぬ気でテストしてバグがあるのでは意味が違う。

テスト自動化で手の空いた技術者が、自動テストで取りきれなかった
バグを取る。

テスト自動化だけをやってるわけじゃない。

**仕様書無しさん** · 2008/08/10(日) 21:35:21

テスト環境をテストするのに同じだけ人と金がかかるんだよぉ♪

**仕様書無しさん** · 2008/08/10(日) 21:36:10

どうしてこう次から次へとマ板は自己陶酔するコテが湧くのか。
>80がおじゃばならまだいいけど、別人ならこんなのが複数いると思うだけでいやだ。

80 · 2008/08/10(日) 21:37:59

この業界の奴らは、頭は良いが、利口じゃない。
つくづくそう思う。不器用で要領が悪い。

80 · 2008/08/10(日) 21:41:38

>>496
おじゃばって誰のことかわからない。

おまえは「おじゃば」のファンなのか？なら、「おじゃば」のいるスレに行け。
俺はお前の相手をしてやれない。

**仕様書無しさん** · 2008/08/10(日) 21:44:30

難しい事を書くから頭の悪い >>496 が嫉妬してるんだろｗ
ほっときゃいい。

**仕様書無しさん** · 2008/08/10(日) 22:31:15

>>464
HAYST法はヘイスト法だよ
秋山さんは意外とマンガ好きなんだ

**仕様書無しさん** · 2008/08/10(日) 23:30:52

>>490
＞よーは、開発者のテストなんて客からしたら気休めさ。

お前自身は何がどうなったら「製品として出荷できる品質だろう」と判断するんだ？
客に対して何かを証明するのでなく、開発側の判断基準はどこにある？

KKDで何となくやって期限が来たらリリース。
潜在してるバグはクレーム来てから直せば良いや。
とそういうことかい？

**仕様書無しさん** · 2008/08/10(日) 23:44:57

>>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ

>>388はソフトウェアの信頼性を定義したぞ。そして、俺自身の中で>>388の主張に腑が落ちた。

**仕様書無しさん** · 2008/08/10(日) 23:52:23

90人が作成したコードを、実装内容も知らない、実装言語にも詳しくないようなテスター10人が
効率のよい品質の高いテストができるのだとすると、どう考えてもそれを各プログラマが実行
したほうが、より効率のよい品質の高いテストができる気がする。

**仕様書無しさん** · 2008/08/11(月) 23:50:38

>>503
プログラマは自分のプログラムには異常に寛容なので、無理です。

**仕様書無しさん** · 2008/08/12(火) 06:39:29

>>503
それも完全じゃないんよね
PGが仕様を把握してないとダメやし

**仕様書無しさん** · 2008/08/12(火) 13:53:17

ホワイトボックス、グレーボックス、ブラックボックス
どれがテストとして質が高いかなんて話に意味あるの？

それぞれに目的が違うんだから比べてもしょうがないと思うんだけど。

**仕様書無しさん** · 2008/08/12(火) 14:31:51

グレーって初めて聞いたよ