08/08/02 16:44:08
>>388
節子、それ、テストやない。デバッグや。
437:仕様書無しさん
08/08/02 19:52:15
>>435
１０件辺り５件も不具合出りゃあ、テスト中止だろwww
５０％なんてどんだけボロボロなんだよwww
438:80
08/08/03 00:48:44
>>437
>>435 の例は、
・同じプログラムなら網羅できたとしてテストケースの数は同じになる。
・テストケース数＝1000件
・実際の不具合の数＝20件
テストA：
テストケースの中から10件を選択してテストを実施->不具合5件発見
テストB：
テストケースの中から100件を選択してテストを実施->不具合10件発見
プログラマーが嫌うような意地悪なテストから実施すると不具合は見つかり
やすいとか、やりようによっては早期に不具合を発見できるという意味なのでは？
さらに、テストケースの粒度や内容をコントロールすれば効率はさらに
上がると思う。
439:80
08/08/03 01:17:35
屁理屈といわれそうだが、言葉の定義だけで言うなら
「信頼性＝故障しにくい事」
故障とは
1. 機械や身体などの機能が正常に働かなくなること。
2. 物事の進行が損なわれるような事情。
3. 異議。苦情。
1. の意味だと
ハードウェアシステムの場合は、劣化などでそのうち故障する。
ソフトウェアシステム（プログラム）の場合は、劣化などはしないので
故障しない。
ソフトウェアの不具合は、2. の意味と考えられる。で、実際には、
3の苦情を指すんじゃなかろうか？
つまり、苦情の件数が少ないほど信頼性が高いと考えられる。
で、
A. 頻繁に使用されるある1つの機能に不具合がある
B. たまに使用されるある2つの機能に不具合がある
C. 滅多に使用されないある10の機能に不具合がある
を考えた場合、A, B, Cのどれを見つけるのが実際に利益があるのか？
を考えるとわかりやすいかもしれない。
なので、 >>435 の言う「テストの効率」は、もっと深く考慮されるべき
だと思う。
蛇足だが、
あるボタンを連打すると発生する不具合をテスト自動化で見つけたが
人間業では決して発生させることができない不具合だったので修正を
見送った経験がある。
440:仕様書無しさん
08/08/03 01:21:11
>>435じゃなくて>>433な。
441:仕様書無しさん
08/08/03 01:25:14
>>438
そんな机上論、幾ら並べても無意味。
何故って？
不具合の数に全容なんて無いからさ
その「実際の不具合の数」自体が空論
テスト方法変えて出てくるのは、異なる不具合であり、全容の一部が見えたわけではない。
442:80
08/08/03 01:36:54
>>440
訂正サンキュー。
ついでに補足
滅多に使用されない機能に致命的な不具合がある場合が一番厄介。
しかも、要求にはない機能が盛り込まれる場合、つまり、想定外の使い方
をされるのは、本当に厄介だ。
要求に無い機能（設計の段階で暗に入り込んだ機能）は、テストから漏れる
事が多いと思う。で、うちでは、繰り返し型なので、この手の潜在的な機能は、
（気付けば）要求としてとらえることにしている。
443:80
08/08/03 01:53:57
>>441
「ソフトウェアの信頼性ほど信頼性の低いものはない」と俺も思う。
不具合密度がどーとか経営陣や顧客に嘘くさい説明はできても自分自身は
納得していない。なので、実際には、統計的な手法からは距離を置いている。
持論で申し訳ないが、俺は、
「ソフトウェアの信頼性＝クレーム処理にかかった費用の少なさ」
と考えている。
極論すると
・ユーザが発見できない不具合は不具合とはみなさない。
（無実ではないが無罪。飲酒運転も逮捕されなければOK的な・・・）
・要求にない機能は、一切入り込まないようにする。
てな感じかな。
444:仕様書無しさん
08/08/03 02:21:12
>>443
そういうプログラム引き継がされて爆弾爆発させたら
爆弾仕込んだヤツは無罪で爆発させたヤツが
全部罪をかぶることになる
この図式はなんとかならないかなあ
445:仕様書無しさん
08/08/03 02:24:47
まあ、完全にBUGを潰す作業をいつまでも行っていたら、永久に製品が出せないからね。
完全にBUGの無いプログラムなんて存在しないからね。
もしBUGが一切無いプログラムがあったとしたら、それは検査方法が間違っているかテスト結果にねつ造があるかのどちらかさ。
446:80
08/08/03 02:45:56
以前にも書いたけど、テストだけを頑張るだけではだめだと思う。
部分最適化じゃなくて全体最適化ね。
以下は、テストではなく設計で逃げたケースの事例。
要求
「何年も24時間連続稼働させないといけないシステム」
設計
・非稼働時に定期的にこっそり再起動
・異常終了した場合はこっそり再起動
100%絶対に異常終了しない設計にするとテストが大変（証明できない）ので
設計で対策をこうじた。画面はあれ？ってな感じになるけどしばらくすると
復帰する。今のところクレームは無い。
447:仕様書無しさん
08/08/03 10:42:24
>>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ
448:仕様書無しさん
08/08/03 10:56:30
>>446
死ぬほどよくあるインフラ構成を偉そうに語る辺り働いてないか末端PGでしょ。
しかも、いきなり「非稼働時」とかまともに説明出来てないしｗ
インフラ構成に頼ったシステム安定性なんて無いに等しい
449:仕様書無しさん
08/08/03 11:04:28
>>436
なるほど。>>388を直してみた。
--------
今日初めて見たが、みんな何か勘違いしてないか？
デバッグで信頼性は上げられない、デバッグは
「このプログラムにはバグがあるます」を実証するもので
バグを沢山検出したからと言って、そのプログラムには
もうバグが存在しないと言う実証にはならない。
実際は逆で、統計的に見るとバグ密度の多いプログラムほど
残りの潜在バグが多く含まれている。
デバッグでは信頼性は旦保できない為、極度に
信頼性が求められるシステムでは、デバッグをしない開発手法もある。
450:仕様書無しさん
08/08/03 11:45:31
>>449
あ すげーまともな文章になったww
451:80
08/08/03 16:25:33
>>448
インフラじゃないけど・・・。全然、意味通じてないみたい。
俺、文章力自信なくしてきた。
452:80
08/08/03 16:51:01
>>448
真面目に読んでくれているみたいだな。
非稼働ってのは変だな。よーは、ユーザーがシステムを使用していない
隙間の時間ということ。
あと、システムと書いたけど厳密には、ソフトウェアシステムね。
自己診断機能と自己修復機能を連携させてるよーな感じのシステム。
実際には、ソフトが原因で異常終了することはないんだけど、
うちは、デバイスがくっついてるからそいつらのせいでシステムが
落ちたりする。
デバイス側の不具合により通信系が異常をきたした場合・・・・
ごめん、長文になりそうだから説明止めとく。
453:388
08/08/03 18:19:20
>>439
>つまり、苦情の件数が少ないほど信頼性が高いと考えられる。
それは違う「原子力発電所の緊急炉停止システム」みたいな
稼動する事がまれで、稼動での不具合が致命的になるケースもある
苦情の件数など関係なく、信頼性は稼動前から求められている
>>436,449,450
テストとデバッグは別もの
454:448
08/08/03 18:41:06
>>452
余計おかしいだろ。
>要求「何年も24時間連続稼働させないといけないシステム」
>非稼働ってのは変だな。よーは、ユーザーがシステムを使用していない隙間の時間ということ。
要求満たしてないのはお話しにならないよね？
上の文が出るって事は仕様を修正した訳でもないし。
>うちは、デバイスがくっついてるからそいつらのせいでシステムが
>落ちたりする。
この1行でもうお腹一杯です・・・
455:仕様書無しさん
08/08/03 19:18:07
最近話題の地震速報とかか？
456:仕様書無しさん
08/08/03 20:03:05
>>453
> テストとデバッグは別もの
正解。よくできました。
お前自分が書いたレスよく読んでみろ。
テストとデバッグの違いの何たるかが解ってない奴の発言だ。
勉強して出直して来い。
457:388
08/08/03 22:14:06
>>456
それは間違い、俺が書いたものを理解出来ないだけの話
458:仕様書無しさん
08/08/03 22:33:42
>>457
だとしたら日本語の書き方を勉強して出直して来い。
459:388
08/08/03 23:17:19
>>458
それも違う、そっちが知識が無いから理解出来ないだけの話
システム工学系の話だから、知識がない人とは話が噛み合わない
460:仕様書無しさん
08/08/03 23:27:23
理解出来てたら簡潔に説明できる。
理解出来てないから伝わらないと教わった俺はいい先生に出会えてたんだなｗ
461:仕様書無しさん
08/08/03 23:35:54
なんかいつのまにか80：その他大勢
みたいな流れになってしまったな
おれとしては80みたいな特異な例よりも
ふつーに自分の現場では・・・みたいなノリが好きなんだが・
462:仕様書無しさん
08/08/04 00:34:05
自分の話が分かってもらえないなら
まずどうすれば分かってもらうかを考えるべき
分かってもらいたいのであればな。
463:仕様書無しさん
08/08/04 01:15:35
「信頼性」の定義が述べられない以上
>>388の話には何の主張も存在していない。
故に誰にも理解できるはずがない。
464:仕様書無しさん
08/08/04 01:27:15
『HAYST法』ってなんて読むのか知っている方いますか？？
465:80
08/08/04 07:01:35
>>453
繰り返すが、ソフトの信頼性は、苦情の件数ではなくて以下と
俺は、考えている。
「ソフトウェアの信頼性＝クレーム処理にかかった費用の少なさ」
「原子力発電所の緊急炉停止システム」のような重要な機能は、
不具合が現実のものとなった時、クレーム処理に相当金がかかるだろう。
よって、網羅的にテストすべきだと思う。
対投資効果的に
誤解があるようだけど、クレームは、あくまでも結果。
「クレーム処理費用が高くつきそうな不具合を発生させる可能性のある
機能のテストケースをきっちりやれば、絶望的な数のテストケース全部
はやらなくてもいいんじゃないか？」と言ってるだけ。
クレーム処理で高くつく機能は、顧客要求にある機能とリスクに関する機能
とかね。
466:80
08/08/04 07:04:16
>>454
悪いが、たぶん俺と >>454 はドメインが違いすぎると思う。
「顧客要求≒真の要求」とだけ書いとく。
467:80
08/08/04 07:25:53
>>460
横やりで悪いが。
そんなに単純なものじゃないと思うぞ。
システムのアーキテクチャは複数のビューで相補的にモデル化される事が
ある。エンドユーザ、プログラマー、システムエンジニア、アナリスト・・・
といった立場によって、「見方」が違うわけ。
話題がプログラミングならビューは「プログラマ」だけで済むので
混乱は少ないが、「テスト」は裏返すと要求でもあるので、いろんな利害
関係者が混ざってややこしい。
理解にも種類があるんじゃないか？
468:80
08/08/04 07:44:33
>>464
俺は、ヘイストと読んでるが・・・。自信はない。
別に否定するつもりはないが、数あるテスト手法の一つだな。
HAYST法は、上流工程がパーフェクトな場合に生きる手法だと思う。
469:仕様書無しさん
08/08/04 21:23:22
隔離スレが必要なレベルだな・・・
470:仕様書無しさん
08/08/04 22:22:55
>>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ
>>338
能書き垂れる前に、ソフトウェアの信頼性を定義しろ
471:仕様書無しさん
08/08/04 22:29:31
なぁ、なんで>>80は粘着しとんの？
それプログラマやない、評論家気取りの厨房や
472:仕様書無しさん
08/08/04 22:42:26
>>459-471
お前らみたいに釣られるカモがいるからじゃねーか？
しかも連投だしｗ。ごくろうさん。
473:仕様書無しさん
08/08/04 23:25:02
>>466
要求分類出来てないよ。
≒にならざるおえない要求とそうでない要求がある。
君が例で出した要求は後者。
コテ酉つけて専スレ立ててもらいなよ。
みんな弄るの飽きたみたいだし、このスレではもう君は不要。
474:仕様書無しさん
08/08/05 00:46:38
を
475:388
08/08/05 07:50:21
>>465
書いている事は分かるが、それは受注企業の論理だ
企業である以上、費用対効果を考えるのは当然だが
絶対の安全が求められるシステムでは通用出来ない
「人が死んでも生命保険に入っているから大丈夫」とは、絶対にならない
俺の考える信頼性は、当事者の論理では無く、第三者も納得出来る
科学的根拠、例えば
「プログラム正当性の証明」(数理論理学的根拠)
「運用実績」（統計的根拠)
当事者の論理では、信頼性の根拠にならない
476:仕様書無しさん
08/08/06 23:03:41
>>475
人が死ぬ不具合は、「クレーム処理費用が高くつきそうな不具合」の
典型だろ。
科学的根拠は、ユーザからしたら「当事者の論理」となんら変わらない。
ユーザーが理系なら納得もしてくれるだろうが・・・。
「プログラム正当性の証明」が理解されることはないだろう。
「運用実績」は唯一の不具合で崩壊する。
「統計的根拠」って天気予報で降水確率100%でも晴れる日があるだろ。
天気予報が外れても訴えられることはないのは、みんなが納得しているからだ。
ただ、ソフトウェアの不具合は、統計的に信頼性が高いと何度言っても、
不具合は不具合なわけで客は決して「統計」を重要視しない。
プログラム正当性証明をバグを生む開発者がどーせやるんだろ。
「正当性を証明できる」なら「もともとバグはない」というパラドックスに
ハマるのが落ちだと思うがな。
477:仕様書無しさん
08/08/07 22:07:06
テストは全ルート試験です。
もちろんifやswitchならば全てを網羅。
試験項目数が1000を軽く越えます。
478:仕様書無しさん
08/08/07 23:52:07
夏休みだなぁ
479:仕様書無しさん
08/08/08 20:36:54
全網羅で「1000を軽く越える」程度なら楽勝だろ
480:仕様書無しさん
08/08/08 21:07:59
開発規模・期間に対しては辛すぎる
一日400件消化しろと？
常識的に考えてくれ・・・
481:仕様書無しさん
08/08/08 21:09:17
そういう情報を後出ししてるようだからダメなんだよ
482:仕様書無しさん
08/08/08 23:20:20
>>480
そんなん普通だろ
何自分だけ不幸のつもりになってんだよwww
テスト自体の効率のいい作業順番とか考えれ
まさか項目上から順番にやってたりしないよな？
483:仕様書無しさん
08/08/09 21:19:18
作業順番を変えても期限は変わらない件
484:仕様書無しさん
08/08/09 21:32:46
>>80のおじゃば
うざいし
485:仕様書無しさん
08/08/09 21:43:04
一日400件なんて新人レベル
486:仕様書無しさん
08/08/09 21:50:21
アプリのテストを言ってるようだが、
異常系や例外系のテストなんか網羅できんだろ
487:仕様書無しさん
08/08/09 23:13:48
スレは読んじゃないけどさ。
>>476
そうは言っても、ある程度定量的に評価出来ないと、
成果物の信頼性が属人的になってしまって、管理出来なくなるだろよ。
475で言うところの「第三者も納得出来る」というのは、
客観的に評価しているということの表現であって、
ユーザが納得できるかどうかでは無いと思うよ。
個人的には根拠は何でも良い。
>>443なら「ソフトウェアの信頼性＝クレーム処理にかかった費用の少なさ」
それをどのように評価し、どのように見積もって、
これから出荷するソフトウェアの信頼性を評価するのか、
という話。
「出荷したソフトの信頼性が高かった」だけでは意味が無い。
大事なのは「これから出荷するソフトの信頼性は高いのか？」
既に運用されているシステムの販売であるとかであれば、
それはつまり「運用実績」であるかな。
「プログラム正当性の証明」ってのはサッパリ意味不明。
488:仕様書無しさん
08/08/09 23:54:11
>>486
最近のテストツールは出来が良くて、異常系や例外系のテストなんかもできるらしいね。
ぶっちゃけ、80が言っていたのはプログラムを細切れにして、単純化されたものを
テストツールでガリガリすると言っている。
489:仕様書無しさん
08/08/10 11:19:43
なんで別人になりすますの？
490:80
08/08/10 21:23:12
>>489
いや悪いが、最近、忙しくてレスしてない。
>>488
こま切れまですると、管理コストが逆に増えるから、
ほどほどに分割している。テストのために分割するのではなくて、
チーム開発なので結果的にそうなるだけかもしれないけど。
「ソフトウェアの信頼性＝クレーム処理にかかった費用の少なさ」
だけど、財務部門がほっといても評価してくれる。奴らはソフトを
金でしか見てない。
「これから出荷するソフトの信頼性が高いのか？」
なんて出荷しなくちゃ分からねい。これは、あらゆる手段を講じても
無理だ。できるという奴がいても俺は一生信じない。
運用実績は、極めて重要だ。実際に客が使って納得して信頼性って言う。
客と開発者のギャップが信頼性の欠如を生む。
よーは、開発者のテストなんて客からしたら気休めさ。
建築、機械、電気・・・・いろんなものになぞられてソフトウェアは
とらえられてきたが、結局のところ「ソフトはソフト」でしかないと思う。
ソフトは、極めて人間くさくて、泥臭い、だから厄介だと俺は思う。
客観的手法や統計で何とかなると本気で考えている奴を否定はしないが
俺はあんまり関心がない。
491:80
08/08/10 21:28:23
統計とか客観的な事実とかを突き詰めるのにすげー金使っても、
結局、プロジェクト内の「過労で疲れた技術者のミスの積み重ね」で
大バグは埋め込まれる。
100万件のテストケースを、休日返上でテスターにやらせたとしたらどうなる？
テストケースがいくら素晴らしくても、「疲れ切ったテスターの判断ミス」
で、バグは見過ごされる。
人間系を見直さないとだめだと俺は思っている。で、テスト自動化に
取り組んだってわけだ。少なくとも、テスターや開発者に対する
負担は減った。彼らに余裕ができた。良い仕事ができるようになり始めた。
テスト自動化による副次的効果の方が、重要なのかもしれん。
492:仕様書無しさん
08/08/10 21:29:35
自動化されたテスト環境にもBUGはあるよｗｗｗ
493:80
08/08/10 21:32:19
テストを重視して、ただでさえ疲れ切った技術者にさらに仕事を
積む。そーやって、現場をさらに混乱に陥れる。
部分最適化だけじゃだめだ。バグを見つけた奴には給料を倍払うとか
しないとな。
技術者は、常に理屈で何とかなると思っている、何か良い手法があると
考えている。ただ、その手法を実行する人の振る舞いについては関心がない。
494:80
08/08/10 21:34:17
>>492
開発者が楽して結果的にバグがあるのと
開発者が死ぬ気でテストしてバグがあるのでは意味が違う。
テスト自動化で手の空いた技術者が、自動テストで取りきれなかった
バグを取る。
テスト自動化だけをやってるわけじゃない。
495:仕様書無しさん
08/08/10 21:35:21
テスト環境をテストするのに同じだけ人と金がかかるんだよぉ♪
496:仕様書無しさん
08/08/10 21:36:10
どうしてこう次から次へとマ板は自己陶酔するコテが湧くのか。
>80がおじゃばならまだいいけど、別人ならこんなのが複数いると思うだけでいやだ。
497:80
08/08/10 21:37:59
この業界の奴らは、頭は良いが、利口じゃない。
つくづくそう思う。不器用で要領が悪い。
498:80
08/08/10 21:41:38
>>496
おじゃばって誰のことかわからない。
おまえは「おじゃば」のファンなのか？なら、「おじゃば」のいるスレに行け。
俺はお前の相手をしてやれない。
499:仕様書無しさん
08/08/10 21:44:30
難しい事を書くから頭の悪い >>496 が嫉妬してるんだろｗ
ほっときゃいい。
500:仕様書無しさん
08/08/10 22:31:15
>>464
HAYST法はヘイスト法だよ
秋山さんは意外とマンガ好きなんだ
501:仕様書無しさん
08/08/10 23:30:52
>>490
＞よーは、開発者のテストなんて客からしたら気休めさ。
お前自身は何がどうなったら「製品として出荷できる品質だろう」と判断するんだ？
客に対して何かを証明するのでなく、開発側の判断基準はどこにある？
KKDで何となくやって期限が来たらリリース。
潜在してるバグはクレーム来てから直せば良いや。
とそういうことかい？
502:仕様書無しさん
08/08/10 23:44:57
>>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ
>>388はソフトウェアの信頼性を定義したぞ。そして、俺自身の中で>>388の主張に腑が落ちた。
503:仕様書無しさん
08/08/10 23:52:23
90人が作成したコードを、実装内容も知らない、実装言語にも詳しくないようなテスター10人が
効率のよい品質の高いテストができるのだとすると、どう考えてもそれを各プログラマが実行
したほうが、より効率のよい品質の高いテストができる気がする。
504:仕様書無しさん
08/08/11 23:50:38
>>503
プログラマは自分のプログラムには異常に寛容なので、無理です。
505:仕様書無しさん
08/08/12 06:39:29
>>503
それも完全じゃないんよね
PGが仕様を把握してないとダメやし
506:仕様書無しさん
08/08/12 13:53:17
ホワイトボックス、グレーボックス、ブラックボックス
どれがテストとして質が高いかなんて話に意味あるの？
それぞれに目的が違うんだから比べてもしょうがないと思うんだけど。
507:仕様書無しさん
08/08/12 14:31:51
グレーって初めて聞いたよ
508:仕様書無しさん
08/08/13 03:50:17
URLﾘﾝｸ(www5f.biglobe.ne.jp)
>>507たまにはぐぐろうな
509:仕様書無しさん
08/08/13 10:49:09
>>508
thx
ただ、現場で聞かないなー、と思ったんだ
510:80
08/08/16 08:02:49
>>502
>今日初めて見たが、みんな何か勘違いしてないか？
>テストで信頼性は上げられない、テストは
>「このプログラムにはバグがあるます」を実証するもので
>バグを沢山検出したからと言って、そのプログラムには
>もうバグが存在しないと言う実証にはならない。
>実際は逆で、統計的に見るとバグ密度の多いプログラムほど
>残りの潜在バグが多く含まれている。
テストはバグを発見するためのもだけじゃない。これはプログラマーの視点
だな。
テストはむしろ、要求したとおりに動作するか？が重要だ。
テストにパスすれば、そのシナリオ（操作手順）で、少なくとも
動作するという事を証明できる。
目的を見失った状態で、統計とか客観的な手法とかを持ち出すから
本質を見失う。統計は手段。バグ発見は、テスト結果。
ちゃんと整理した方がいいぞ。
テストの目的は、要求を満たしているかどうかを確認すること。
511:仕様書無しさん
08/08/16 19:50:07
>>80はユニットテストを重視も軽視もしてないと言ってたが、
もしかして重視してるんだけどただ>>80だけがそれを理解していないんでは？
512:仕様書無しさん
08/08/16 20:45:36
もだけ？
513:511
08/08/16 21:19:04
>>511は >>80の会社は重視してるけど ってことね。
514:80
08/08/16 22:56:34
>>511
ユニットテスト（単体テスト）は当たり前。軽視も重視もしていない。
重視したところで精度が上がるわけでもない。プログラマーの能力に依存
するからな。
プログラマーは忙しい。プログラマーに負担を増やしても全体的に品質が
落ちる。
ユニットテストを強化して効果が出るかどうかはその組織しだい。
俺は、限定的だと考えている。
プログラマーは均質ではない。
分析能力のある者、観察能力のあるも者、創造力のある者、忍耐力のある者
十人十色だと思う。分析能力や創造力はあっても観察能力がない奴も居る。
チーム開発は、各人の能力を補完し合って結果を出すものだと思うがな。
ごちゃごちゃ言わずに、優秀なプログラマーを金で雇ってきて、
自由にやってもらう方が結果が出たりもする。
515:仕様書無しさん
08/08/16 23:39:43
重視・軽視 って言葉の基準があいまいだな。
ユニットテストだけを特別重視しているわけではない。くらいの意味合いかな？
516:仕様書無しさん
08/08/16 23:44:02
>>515
特別重視しているわけではないってのも十分曖昧だと思うがな。
重視とか軽視とかは、相対的なもので基準を云々言うこと自体ナンセンス。
よーは、515が馬鹿だってこと。
517:仕様書無しさん
08/08/16 23:56:02
相対的なものだからこそ、基準をはっきりさせろってことだろ。
他のテストと比べてユニットテストだけってことじゃん。
518:仕様書無しさん
08/08/17 00:09:50
>>517
いくら頑張ってもお前の言ってることも80の言ってることも
曖昧なんだよ。お前らがテストをしても品質は上がらねーよ。
ということで終わり。
519:仕様書無しさん
08/08/17 00:27:10
>>1
３割方終わった風な顔で、「コーディング終わりました。後はテストするだけです。」
これなら満足なのか？
520:仕様書無しさん
08/08/17 00:36:04
プログラマーより身分の低いテスターが愚痴を言ってるだけだろ。
521:仕様書無しさん
08/08/17 00:44:24
>>1
おれが言いたかったことを、代弁してくれて
心からありがとう( ´v｀)
522:仕様書無しさん
08/08/17 01:32:59
>>519
そりゃどんな顔なんだよ
523:仕様書無しさん
08/08/17 02:12:09
この業界に20年以上いるが、グレーボックステストなんて言葉初めて聞いた
そんなのがあるんだ
524:仕様書無しさん
08/08/17 02:38:38
>>523
あるかどうかグレーです
525:仕様書無しさん
08/08/17 08:14:37
>>523
みんなが勝手に名前を付けているだけで何が正しいとかはないと思うな。
526:仕様書無しさん
08/08/17 09:03:09
ブラックホールテスト
527:80
08/08/17 09:41:22
モデルベーステスト
非モデルベーステスト
モンキーテスト（アドホックテスト）
静的テスト
動的テスト
単体テスト
結合テスト
システム・テスト
受入テスト
回帰テスト
機能テスト／機能網羅テスト
パフォーマンス・テスト
負荷テスト
障害テスト
セキュリティ・テスト
色々あるな。でもな。分類とかしてる時点で間違いの方向に行ってる
気がする。バグは細部に潜んでることが多い。これらの分類にすべての
バグが綺麗にあてはまらないから「想定外のバグ」が出荷後に問題になる。
528:仕様書無しさん
08/08/17 10:07:05
bp = malloc(sizeof(Buff *));
これはどのテストで検知するべきバグだろね？
529:仕様書無しさん
08/08/17 11:30:29
その手続きを持つ関数の単体テスト
530:仕様書無しさん
08/08/17 11:47:12
じゃ東証は･･･
531:仕様書無しさん
08/08/17 11:54:56
テストに関していえばtestabilityとかが末端まで広まる前のコードだった
532:仕様書無しさん
08/08/17 13:02:29
>>527
でかいシステムの場合、分類しないとテストの目的がはっきりしなくなるのよ
533:仕様書無しさん
08/08/17 13:03:25
>>528
ソースコードレビュー
534:仕様書無しさん
08/08/17 18:37:00
>>527
例えば、パフォーマンステストとか負荷テストとかは所謂バグつぶし目的じゃない気がするが。
ていうかちゃんと分類されてないとまともにテストできないだろ・・・
535:仕様書無しさん
08/08/17 19:05:50
おじゃばにそんなこと言っても無理
536:80
08/08/17 21:41:00
いや、いたって普通に分類してテストしてるよ。でもバグが減らないから
今やっているやり方が間違っているのかな？って考えているところさ。
よーは、学術的なアプローチに限界を感じてるんよ。
>>527
どのテストも、バグ潰しを目的としているわけではない。
バグ潰しは、デバッグでやるものだ。
> bp = malloc(sizeof(Buff *));
この手のバグは、デバッグの時にみつけるべきもの。
うちでは、Purifyとか使ってるけどね。
メモリリークチェックやメモリフットプリント、関数プロファイリング
などはツールでやるのが効率的だと思う。
537:仕様書無しさん
08/08/17 22:05:10
529に１票
malloc()に渡すパラメータのサイズをチェックすべき
"デバッグ時"なんて、動作させて妙な状況が発生しないかぎりチェックしようが無いよ...
538:仕様書無しさん
08/08/17 22:06:36
>>536
>うちでは、Purifyとか使ってるけどね。
I社の製品使うんだｗ
>この手のバグは、デバッグの時にみつけるべきもの。
デバッグの意味分かってるか、アホだろうｗ
539:仕様書無しさん
08/08/17 22:25:01
ググってみた。
デバッグ
コンピュータプログラムの誤り(「バグ」と呼ばれる)を探し、
取り除くこと。
テストでは、バグを取り除くことはしないので、>>534 の言う
「バグ潰し」は、話の流れ的におかしい。
540:80
08/08/17 22:27:13
> bp = malloc(sizeof(Buff *));
> これはどのテストで検知するべきバグだろね？
このコードを書いたプログラマーの採用試験に一票。
541:仕様書無しさん
08/08/17 22:29:32
軽視するわけじゃないけど、GUIのテストってむずくね？
どうすればいいんだぜ
542:仕様書無しさん
08/08/17 22:47:02
>>540
その採用試験に
>この手のバグは、デバッグの時にみつけるべきもの。
と回答したら、その人は合格するか？
543:仕様書無しさん
08/08/17 23:49:45
>>539
安価ミス？
544:仕様書無しさん
08/08/18 01:22:44
偽物が湧いてるんじゃね？
545:仕様書無しさん
08/08/18 09:11:25
>>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ
546:仕様書無しさん
08/08/18 15:12:15
>>536
＞いや、いたって普通に分類してテストしてるよ。でもバグが減らないから
＞今やっているやり方が間違っているのかな？って考えているところさ。
＞よーは、学術的なアプローチに限界を感じてるんよ。
学術的アプローチが何か知らないけど、単にテスト設計がショボいだけじゃね？
とりあえず、ITとSTの命令網羅率と条件網羅率は幾つよ？
網羅率も出してないなら、テスト仕様の質をどういう「学術的アプローチ」で出してみたんだ？
（網羅率が全てじゃないと思うが、うちのテストの評価では基本的な指標の1つとしてるので）
テスト仕様の質を評価してなかったら、
たとえどんな(学術的な？)手法でテスト結果を評価してみても意味無いぞ。
547:仕様書無しさん
08/08/18 22:12:36
>>545
おじゃばは都合の悪いことはスルーデフォ
548:仕様書無しさん
08/08/19 11:25:08
お前ら楽しそうだな、システム組むってやっぱ分業してナンボだよな
一人で設計して一人で組んで一人でテストしてデバッグする俺ってなんなんだろう
こんなんでいいシステムが組めるわけないよな。何が少数精鋭だよ
社長はそんなもん一人で出来るとか言ってるが、アンタ自身が一人でやったことないだろ
自分でやったこともない事を人に押し付けるなっつーの。ホント意味わかんねーな。どーよこれ
549:仕様書無しさん
08/08/19 11:28:19
俺も、一人で設計して一人で組んで一人でテストしてデバッグする俺。
550:仕様書無しさん
08/08/19 12:57:02
自分からテスト専門です、って宣言してる派遣テスターって何なの？
将来プログラマとかSEになりたい、とかならわかるけど。
向上心ないよね、頑固だし。
そういう派遣テスターって、仕様書は読めない、
テスト仕様書も作れない、テストプログラムも作れない
やれることは「テキトーにプログラムを触る」ことだけ。
俺は派遣プだけどさ、こういう派遣テスターがいると
派遣全体がバカにされるんだよ。
テスト専門派遣なんて氏んで欲しいよ、まったく。
今日も正社員の人が派遣テスターに仕様書を読んで
テスト仕様書を作ってください、って説教してたよ。
その派遣は頑固に「何故、仕様書が必要なんですか？」って
反論してたから、きっとテスト専門派遣テスターだな。
仕様書も読まず、テスト仕様書も作らず、ただテキトーに
プログラム触るだけで給料もらおうなんて頭おかしいんじゃねーの？
あ～あ、あの派遣テスターが3ヵ月後に切られるまで、
仕様書も読まねーでテキトーにテストしたバグ票がまわってくんのかよ。
そんな糞なもん、読んで処理する派遣プの身にもなってくれよ。
うわ～、しかもそいつが切られる3ヵ月以内に中間納品あるじゃねーか！
テスト仕様書もなしにテキトーにテストして納品か。
中間納品後にソッコウクレームでデスマ必至だな。俺の休みも返上かよ。
派遣専門テスターさんよ、少しは向上心持てよ！
頑固な性格直して仕様書読めよ！テスト仕様書作れよ！
551:仕様書無しさん
08/08/19 13:12:01
長い
552:仕様書無しさん
08/08/19 14:00:38
>>550
低レベルな話だなあ
そんなバカ派遣テスターなんか契約終了を待たずにに切ればすむ話だろ
正社員がテスト仕様書を書くように指示をだしているのに反抗しているんだから
即日クビでもなんの問題もないよ
553:仕様書無しさん
08/08/19 14:39:18
>>551-552
>>550 はコピペだよ
554:仕様書無しさん
08/08/19 15:00:16
【頑固】派遣テスターの人格問題【向上心ゼロ】
ｽﾚﾘﾝｸ(prog板)
555:仕様書無しさん
08/08/21 22:15:55
まずはテストの工数を軽視する者どもをなんとかしないとな
556:仕様書無しさん
08/08/24 19:39:07
急に80が来なくなったな
557:仕様書無しさん
08/08/26 10:28:36
おじゃばはOOスレに戻りました
558:仕様書無しさん
08/08/26 11:31:38
相変わらず羞恥心の欠片もないんだな
559:80
08/08/27 09:48:30
>>556
お久しぶり。さすがに、２ちゃんばっかやってるわけじゃないし・・・。
近頃のプログラマーも「未経験者歓迎！」で採用されたど素人が
平気で派遣でやってくる時代だからな。テスターにプロ意識を
強要しても無駄。
金だけ欲しいなら、テスターになっていっぱい残業したらいいわけで。
リリースしたものにバグがあったらプログラマーの責任って言い張れば
良いわけで・・・。
テストを軽視するな！とか理屈でごちゃごちゃ言っても仕方ないと思うんよ。
重視しても仕事は楽にならないし給料が増えるわけじゃないし。。。
結局、テスターは頑張らないよ。プログラマーだってテストする十分な時間
ないしね。
俺は、そういう人たちを管理してたりしてるんだけど。
人数が多いプロジェクトでは、1/3は頑張るけど1/3の人はさぼる。
全員優秀なチームは存在しない。予算も潤沢に無い。
仕事のやり方をそのままにすれば、何かを重視し何かを軽視せざるを得ない。
となると、テストがどうしても軽視されてしまう。
仕事のやり方を変えるのは、製品開発より難しい・・・。
このジレンマからのがれる方法はないものかねぇ。
560:仕様書無しさん
08/08/27 22:31:38
>>559
残りの1/3は？
561:80
08/08/28 23:30:31
以下を参照のこと
働きアリの法則
2-8の法則
2-6-2の法則
パレートの法則
562:仕様書無しさん
08/08/28 23:38:18
未経験者歓迎で入ったド素人コーダーだけど単体テストだけは念入りにやってるよ
というか馬鹿だからテストから書かないとコードが書けない罠ｗ
人より手間かけてる分作業の速度は遅くなるけど多分省いても大して速くならんとも思う
563:仕様書無しさん
08/08/29 00:08:58
>>562
単体を大事にするその気持ちが大事なのです
みつぬ
いつかみんなに認められるよ、その努力は
564:80
08/08/30 07:58:58
優秀なプログラマーを確保できないプロジェクトチームでは、
テストを重視しているのかもしれないなぁ。
プログラミング能力ってすぐに向上しないから、テストくらい
ちゃんとしろよってことなのかな。
565:仕様書無しさん
08/08/30 08:42:24
そういえば俺も初めてのプロジェクトではまずテスト書くのから始めたなあ。
まあそれは勉強の意味合いがほぼ100%だったけど。
566:仕様書無しさん
08/08/30 09:50:27
事務より簡単で誰でもできる仕事なのに時給は技術者！
ITテスターで稼ぐための情報を交換しましょう。
☆派遣先は大企業じゃないと駄目です。中小だとテスターもプログラムの仕様が
わからないといけないとかテストプログラムを書けとか言われちゃいますよ。
大企業ならプログラムを触るだけのテスターでも大丈夫。
☆派遣先ではテスターはプログラムを触るだけでいい、
そんな空気を作っていきましょう。仕様書読んでください、
とか言われたら「なんでテスターが仕様書読むんですか」って食い下がって。
プログラムの仕様書を読んだり、テストの仕様書を書いたりするのは大変ですよ。
☆普通にプログラムを触ってテストしてると、何をテストしているのかわからない、
とか言い出す人、いるんですよ。プログラマとかってこういう人多いです。
そういう人は上司にあることないこと告げ口して追い出しちゃいましょ。
人事権のある人とは仲良くしておくことが大切。
☆納品して何かあったら大変だからとプログラムの仕様書を読んだり、
テスト仕様書を書いちゃうテスターがいますけど、
こっちもやることになるからすごく迷惑。
テスト結果の責任は担当の正社員にありますよね。
納品後のクレームは最終チェックを怠った正社員が悪いんだから
派遣は関係ないです。
567:仕様書無しさん
08/08/30 10:57:01
>>559
＞このジレンマからのがれる方法はないものかねぇ。
軽視して良い工程なんて開発に存在しない。
十分な金と期間を客から引っ張って、ちゃんと人をアサイン出来ない
営業と管理層が悪い風にしか見えないが。
改善すんのはソコからでしょ。
「何かを重視し何かを軽視せざるを得ない。 」と管理している自分が言う状況なら、
出だしから「これは無理じゃね？」っていう開発期間で仕事を受けてるってことでしょ？
1/3サボるのが分かってるなら、2/3で出来るスケジュールで受けろよ。
何そんな意味無い数字書いてんだ。
＞近頃のプログラマーも「未経験者歓迎！」で採用されたど素人が
＞平気で派遣でやってくる時代だからな。テスターにプロ意識を
＞強要しても無駄。
なら派遣使うなよ。
568:80
08/08/30 17:38:42
>>567
>軽視して良い工程なんて開発に存在しない。
正論だけどね。そこを一歩踏み込んで考えないと実践では通用しないよ。
昔は「設計」「実装」が重視されていた。プログラマーのスキルと
モチベーションが高かったから、それで、結構うまくいっていた。
単体テストは、当たり前だったから特に話題にもならなかった。
でも、今では、ソフト技術者は3Kで「不人気」となり優秀な技術者は別の
業界へ流れて行く。インド、中国、ロシアの安いソフト労働力の台頭も
追い討ちをかけている。
日本のプログラマーのレベルは、以前からするとずいぶん下がった。
そもそも、「単体テストを重視する」という事自体が、俺からすると
滑稽なんよ。「うんこしたら手を洗う」くらい当たり前のことを
ワザワザ言わなくてはいけない時代になったのが残念だな。
言わなきゃ出来ないレベルの低い奴に、言って分かると思うか？
出来るやつは、言わなくてもやるもんだ。
単体テストをしないプログラマーにいくらプレッシャーを与えても
良い結果は得られないよ。それなら、仕事のやり方を工夫する方が
よっぽどましさ。
569:仕様書無しさん
08/08/30 19:34:30
>とか言われたら「なんでテスターが仕様書読むんですか」って食い下がって。
食い下がる以前に正社員に逆らったらクビだろｗ
570:仕様書無しさん
08/08/30 20:22:54
>正社員に逆らったらクビだろｗ
>正社員に逆らったらクビだろｗ
>正社員に逆らったらクビだろｗ
バカ？
571:仕様書無しさん
08/09/02 00:33:04
>>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ
572:８０
08/09/02 00:41:51
>>571
さみしいんだねｗ
573:仕様書無しさん
08/09/02 00:51:25
おじゃばくさい返しだな
574:仕様書無しさん
08/09/02 10:28:46
>>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ
575:仕様書無しさん
08/09/05 01:57:40
テスターって気楽でいいよね。
自分のバグじゃないし、動かしてダメダメ言っておけばOKみたいな感じ。
576:仕様書無しさん
08/09/05 19:17:53
その代わり、実装周りの人間が帰った夕方から、
その日の更新分含めたテストやってたりして、
夜間シフト状態になってたりした事あったけどｗ
577:仕様書無しさん
08/09/06 00:27:24
>>575
嫌われるのが仕事だからｗ
プログラマーは絶対にバグを出す。
悪いのはプログラマー。
>>576
プログラマーは24時間労働がデフォ。
夜間シフトは、金儲けにうってつけ。
578:仕様書無しさん
08/09/06 00:29:40
まだやってんのか・・・糞スレはsageでやれ
579:仕様書無しさん
08/09/06 01:20:26
おまえもな
580:仕様書無しさん
08/09/06 18:46:21
お前2chは初めてか？
力抜けよ
581:仕様書無しさん
08/09/07 07:59:03
おまえもな。
582:仕様書無しさん
08/09/07 08:24:02
私見だがテスターって基地外な奴のほうが優秀だと思う。
・常識では思いつかないような操作をする。
・人の話を聞かない。（話で誤魔化すことができない）
・理解力が無い。（おのずとヘルプ等を細かくしてしまう）
・集団の中で浮いてる。（無駄話をせず黙々と作業）
開発としては関わりたくないのだけど、
客観的に考えると良い製品ができるような気がする。
583:仕様書無しさん
08/09/07 10:48:23
変わり者くらいにしておけよ
基地外が適している仕事なんかねえよｗ
584:仕様書無しさん
08/09/07 15:13:20
本物の基地外と接した事が無いからそんな事言ってるんだと思うけど。
先ず、仕事として何かをやらせる事自体が無理。
585:仕様書無しさん
08/09/07 15:49:24
>先ず、仕事として何かをやらせる事自体が無理。
それは派遣テスターも一緒だろ
「まず仕様書を読んでテスト仕様書を作れ」と仕事の指示を出しても
まったく手も足も出ないバカばっか
586:仕様書無しさん
08/09/07 16:05:00
それは契約で仕事の範囲をちゃんと決めてないんじゃないか？
テストオペレータとして雇ってるのか、
テスト設計からやる技術者として雇ってるのか、
はっきりしない限りはなんとも言えない。
587:仕様書無しさん
08/09/07 16:11:13
>>586
つ「作業内容：テスト一式」
588:仕様書無しさん
08/09/07 16:26:21
オペレートしかテスターなんてイラネ
589:仕様書無しさん
08/09/07 19:32:30
>>588
おまいのようなケアレスミスの多いマにはテスターは必要だろｗ
590:仕様書無しさん
08/09/07 19:37:50
逆に適当に触るだけのテスターじゃケアレスミス位しか発見できんな
591:仕様書無しさん
08/09/07 23:45:37
仕様策定の段階からテスターと一緒にレビューしてる人いるの？
592:仕様書無しさん
08/09/09 18:12:48
>>585
派遣テスターで、テスト仕様書から作れるヤツなんて使ったことねーけど
流石にテスト仕様は、仕様策定した連中が書くでしょ
要求仕様わかってない連中にテスト仕様書かせてどうすんのさ
593:仕様書無しさん
08/09/09 20:16:18
なんのために仕様書があるんだよ
594:仕様書無しさん
08/09/09 22:11:37
>>593
お客さんに古紙回収してもらうため
595:仕様書無しさん
08/09/10 00:59:36
>>592
典型的な底辺低賃金会社の発想だな
596:仕様書無しさん
08/09/10 18:03:45
俺の名前をテストデータに使うなバカ上司
俺は全然タッチしてないシステムなのに
マジで頭おかしいだろ
597:仕様書無しさん
08/09/10 18:24:38
>>591
ちゃんとやってる所は必ずと言っていい程参加させてるね。
テスト設計者を
598:仕様書無しさん
08/09/10 21:07:59
>>596
名前覚えて貰ってるんなら結構なことではござらぬか
599:仕様書無しさん
08/09/10 23:11:39
画面見て結合テスト仕様書つくってください
って同僚がベンダさんに言ってた
何をテストするんだろういったい
600:仕様書無しさん
08/09/10 23:52:49
要求される「品質」にも拠るんだよな。
100万単位の人間が使うようなブツなら、テストは万単位でガッツリやらんとヤバいことになる。
万単位のテストをやるなら、まず8割9割のテストは自動化しないと何ともならんわ。
で、コードを修正したら一度自動テストを回す感じ。
理想としては、テスト設計書の概要はWordとかでもいいんだけど、詳細設計はExcelとかでマクロ組んで
テストデータを自動で吐いてくれるような感じにする。
業務系の仕事とかで、客とねんごろって世界なら、テストが適当でも何とかなる場合がある。
DBのデータが㌧㌦みたいなのさえ出なければ、まああとは酒の場の寝技。
こういうのを技術者とは言わんけど、それが通じる世界もあるんで。
ただ、業務系だけだね、これが通る世界は。
601:仕様書無しさん
08/09/11 01:05:05
>>390
「クリーンルーム」じゃね？
徹底的に個々のコードレビューをやるって奴。
IN入れてOUTの結果が期待通りか否かを見る、って方式じゃなくて、
コードのロジックに誤りがあるかないかをプロが検査するって感じか。
OpenBSDはそういう手法だと聞いたことはある。
602:仕様書無しさん
08/09/11 01:21:31
>>601
プロの定義がおかしい希ガス
603:仕様書無しさん
08/09/11 13:35:53
>>598
テストしながら「(俺の名前)がおかしい」ってブツブツ言ってるんよ
呼び捨てで
普段からそういう人間だってのは知ってたが、
そういう嫌がらせされたのは初めてだ
604:仕様書無しさん
08/09/11 16:34:05
>>603
名前にダメ文字入ってるんじゃね？ 「十」とか。
ダメ文字チェックなら「図『表』」「『能』力」「『十』番」あたりを使えば
いいだけなんだけどさ。
605:仕様書無しさん
08/09/27 22:11:07
>>1
コーディングが終わってやっと３割終わったかどうかってところだろが。
てことはさ、テストファーストでテストコードを書き終われば
本体のコードは進捗ゼロでも７割終わったと言っておｋ？
606:仕様書無しさん
08/09/27 22:40:13
テストで初めて発覚した仕様の洩れを、いまさら作り込めと言われて、最近鬱。
607:仕様書無しさん
08/09/30 01:03:30
>>605
テストファーストはテストコードだけを
最初にコーディングするものでは無い訳だが？
言葉ばっかり一人歩きすると勘違いする奴が多くて困る
608:仕様書無しさん
08/09/30 06:12:10
そもそも本体コードをテストしないことには終わらんだろw
609:仕様書無しさん
08/09/30 06:44:53
派遣テスターによるいい加減なテストが衰退しつつある
610:仕様書無しさん
08/09/30 13:04:12
テストを一切せずにリリースする国産MMORPGもあるのにな
611:仕様書無しさん
08/09/30 13:39:47
ファイナルファンタジーXIの話はもういいから・・・
あれは試験ゼロにすることで経費浮かして利益あげてるんだよ。
612:仕様書無しさん
08/09/30 14:37:05
それにしても、実装してない機能のバージョンアップしました報告はすごかったよなww >FF11
613:仕様書無しさん
08/09/30 15:22:15
某銀行合併時もATMとかちゃんとテストしてなかったぽいしね
614:仕様書無しさん
08/09/30 16:30:39
>>611-612
これか・・・すげぇな。アップデート項目チェックとかしてないんだろうか？
ゲーム開発って楽そう。
URLﾘﾝｸ(www.playonline.com)
>■一部アイテムのアイコングラフィックが変更されたお知らせに
> おいて、実装されていないアイテムが一覧に含まれておりました。
> 脳汁／狡賢い脳汁／幸せの人参汁／まろやかな鳥汁／濁った血汁
615:仕様書無しさん
08/09/30 17:13:52
>>605
それだとまだテストコードのテストが7割残っているから、
実は全体の7割の3割、つまり2割強しか終わってないんだな。
616:仕様書無しさん
08/09/30 17:23:26
テストコードの正しさはテストしながら検証されていくという、
テスト結果がNGなら、テストか実装かどっちかが間違っているわけ
だから。全部OKになった時点で実装とテストの信憑性もあがるけど、
これで安心できるかどうかは、テストの網羅性にもよるわな。
あと間違った実装を間違ったテストに通してOKになる可能性もなき
にしもあらずだな。
617:仕様書無しさん
08/10/02 23:21:01
テストの正しさを検証するのはテストのレビューじゃねの？
うちじゃやるけど、他んとこじゃあんまりテストのレビューってやんないのかね。
618:仕様書無しさん
08/10/03 01:29:41
>>617
書類に関するレビューは必ずやる。
それがソースコードでもテスト検査書でも同じ事。
619:仕様書無しさん
08/10/03 01:53:34
>>618
休暇届もやるのか・・・・
ムチャクチャNG出されそうだ･･･・・
620:仕様書無しさん
08/10/03 01:59:14
>>619
ああ、休暇届に不備があってプログラムに不具合が出るならやるさ。
621:仕様書無しさん
08/10/03 08:10:34
この日確かレビューだったよね？よってNG。
とかか。
622:仕様書無しさん
08/10/03 09:23:34
>>618
俺の前の会社は「テスト検査書なんかいらないんだ！テストというものはどんどん触るのが仕事なんだ！」
という社長の方針でレビュー以前にテスト検査書が存在しなかったけどね。
まあ、結局倒産して社長一家は行方不明だがｗ
623:仕様書無しさん
08/10/03 09:46:04
俺的にはまず全体できに荒くテストしてから
細かいところをテストするのがいいと思う。
624:仕様書無しさん
08/10/03 13:26:55
テスト検査書の正しさは誰が検証するんだ
625:仕様書無しさん
08/10/03 22:37:27
SQA部門とコレまでに改善されてきた(はずの)システムが検証する。
626:仕様書無しさん
08/10/04 18:01:37
テスタがプログラマからテスト仕様書を貰えると思ってる時点でおかしい。
折れの職場はこうだからバグが減らない。
んで営業がキレる。折れのせいじゃねえよ。構造的欠陥だ。
627:仕様書無しさん
08/10/04 18:09:53
テスト仕様をプログラムから起こしちゃあ、プログラムの正当性が判断できないよね。
そりゃそうだ。
テスト仕様はシステム設計書やシステム仕様書から起こす物だよな。
628:仕様書無しさん
08/10/04 18:15:27
>>623だけが素人くさいな
629:仕様書無しさん
08/10/05 00:15:15
項目Aを実行する テスト内容Aの結果が○○になる
項目Bを実行する テスト内容Bの結果が○○になる
...
これをテスト仕様書とかいってももってくる35ぐらいのおっさん
いるんだけど、テスト軽視とかのれべるじゃねーよｗ
630:仕様書無しさん
08/10/05 00:42:27
>>629 その人に、それ1回やってみましたか？って言ってみたらどうかな。
631:仕様書無しさん
08/10/05 03:35:07
UTが内部設計、Itaが外部設計、STが要件定義書のテストだよね？
632:仕様書無しさん
08/10/05 04:55:09
仕様書書いたあとに仕様書からテスト紙を起こす
そのあとコーディング
こっちの方が絶対バグが減る
633:仕様書無しさん
08/10/05 05:05:40
>>632
設計はどのタイミングで
634:仕様書無しさん
08/10/05 05:08:09
>>633
用件定義はどのタイミングで
635:仕様書無しさん
08/10/05 05:21:49
>>634
契約金額はどのタイミングで
636:仕様書無しさん
08/10/05 10:23:33
>>631
ItaとかItbってIBMかなんかの方言だったような
637:仕様書無しさん
08/10/05 10:29:50
省略表現とか横文字を無意味に乱発する奴は
折れはあまり好きじゃないな。
日本語で適切な表現があれば、最初からそれを使えば
沢山の人に読んでもらえる。
638:仕様書無しさん
08/10/06 10:34:19
>>629
ファイナルファンタジーXIスタッフ乙
639:仕様書無しさん
08/10/06 20:24:24
>>582
その基地外に関わる奴のストレスを考えたら大変なものだろうな。
うちの優秀な人間を潰されたくないからそー言う奴は使わない方が無難。
下請けに基地外が紛れ込んでる分にはOKだが、失敗したら賠償請求するよ？
640:仕様書無しさん
08/11/02 23:55:58
ソニー系列で仕事した人に聞きたいんだけど、
ソニーって、ぜんっぜんテストしてなくね？
俺の部署の上司が元ソニーなんだが、テスト工数を全く見込んでくれない。
PS3のファームバージョンアップにも、
ちょっと動かせばわからないバグが平気で仕込まれてるし
641:仕様書無しさん
08/11/02 23:56:31
×ちょっと動かせばわからない
○ちょっと動かせばわかるような
642:仕様書無しさん
08/11/03 00:02:50
テストしてないは言い過ぎ
643:仕様書無しさん
08/11/03 00:25:07
テストしていない＝検仕無しでプログラムが動けばOKとしている
644:仕様書無しさん
08/11/03 02:38:18
ソフトウェアが存在しない時代からあった古い会社ではありがち
645:仕様書無しさん
08/11/03 02:49:53
>>644
そういうテストをしていると会社自体が存在不可能になり、
消滅していくので、実際にはほとんどない
たとえなんとか存在できても結局受託じゃ
瑕疵保証で採算が合わず、社員は毎日他人に会社に出勤してるｗ
646:仕様書無しさん
08/11/03 17:36:40
S◯NYってソフト関係は丸投げしてるでしょ？
日立系あたりに。
そっちでテストはしてるんじゃねえの？
647:仕様書無しさん
08/11/03 17:53:59
>>646
目立から関連情報システムに○投げしてるよｗ
648:仕様書無しさん
08/11/04 08:39:51
で、勉強するのにおぬぬめの本はあるの？
何かスクール的なのとか行けって？
649:仕様書無しさん
08/11/04 23:46:45
実戦＆実践あるのみじゃね？
650:仕様書無しさん
08/11/05 00:16:02
本は自分で見て選ぶ
スクールは基本的に金の無駄
ただし、時間を金で買うなら、物によっては選択肢に入れても良い
651:仕様書無しさん
08/11/05 00:24:50
仕様書どおりのテストをするのが仕事。＞つまらん
いやらしい境界条件や設定条件を組み合わせて、バグを見つけるのが趣味な俺。
652:仕様書無しさん
08/11/05 00:56:25
>>651
至って正常だから安心しろ。
変態的なバグ出しだと、動作中にコンセント抜くとか平気でやるからw
653:仕様書無しさん
08/11/05 01:15:40
>>652
フォールトトレラントシステムでは準正常系試験かとｗ
654:仕様書無しさん
08/11/05 17:11:49
カスSEが書いた試験書通りに試験するよりも、
ベテランPGがランダム試験したほうが効率的にバグ出せるよな。
でもそれを認めて生かしてるテストプロセスって世界的に見ても存在しないような。
日本人の職人技をプロセスとして体系的に確立することは出来ないんだろうな
655:仕様書無しさん
08/11/05 20:54:27
JCBカード決済に障害
656:仕様書無しさん
08/11/05 22:25:50
>>654
バグ取りとしてはその方が効率いいんだろうけど
客へのテスト実施内容報告としては愚鈍なやつが書いたような
単に全U/Iに同じことするような網羅系テストの結果資料が
絶対必要なんだよな・・・
特に最近に品管きどり連中はうるさい
657:648
08/11/05 23:25:57
亀だが>>649 >>650㌧ｸｽ。
意識改革やってみるわ。燃えてきた。
俺をテストしてやるっ！！
658:仕様書無しさん
08/11/07 01:36:55
>>656
同意。
泳がせとくだけで勝手にバグ見つけるテスタって居る。
しかし、クライアントへの提出物として程々網羅率の高い項目書って要る。
で、ランダムテストでバグが出てからその手順を項目書に織り込むなんて
アホらしいこともやらざるをえないことがあるよ。
659:仕様書無しさん
08/11/08 00:36:54
>>658
テスト項目にない内容が不具合票にあがってるぞ！
とかつっこむ品管とかもう、巣へ(・∀・)ｶｴﾚ!!と・・・
660:仕様書無しさん
08/11/08 01:14:05
>>659
客先からバグの報告が来ると
テスタは何やってんだ、とか言い出すんだろ？
661:仕様書無しさん
08/11/08 01:28:27
最初からザル試験書なんだろ。
662:仕様書無しさん
08/11/09 16:25:12
>>654
ランダムテストのほうがバグが出るってw
そりゃ単にテスト仕様が低レベルなんだよw
お前の会社、年収500万前後で頭打ちだろw
663:仕様書無しさん
08/11/09 16:28:42
テスターで1000万超えてるやつっている？
664:仕様書無しさん
08/11/10 00:28:19
常に悲愴感
自分のチームを守りたいのは分かるけど
最後まで人の話を聞いてくれ
665:仕様書無しさん
08/11/10 00:37:21
ニートにバグ１個３００円でやらせろ
666:仕様書無しさん
08/11/27 23:26:08
SEが試験書なんて作らずにテストコードを直接書けばいいのに
仕様→試験書→テストコードなんて伝言ゲームみたな事なんかありえん
で、上に提出する書類はテストコードから自動生成すればいい
どうせ碌に読まないんだからBDD用フレームワーク使って書いたテストから
辞書をチューンしたコリャ英和とmecabを使って生成してバレないだろうし
667:仕様書無しさん
08/11/27 23:48:58
SEが違えばテストコードも違うんだなこれが
それだと上に提出する書類はSEの数だけシナリオができて
支離滅裂な文章の羅列になっちゃう
668:仕様書無しさん
08/12/06 03:46:41
SEの書く試験書なんて、
○○機能テスト・・・○○機能が正しく動く
△△機能テスト・・・△△機能が正しく動く
××機能テスト・・・××機能が正しく動く
こんなもんですから。
669:仕様書無しさん
08/12/06 12:11:27
SEXXテストか
670:仕様書無しさん
08/12/06 12:38:13
SEXとは
SEがX(ﾊﾞﾂ=ｲﾗﾈ)という意味ですか
671:仕様書無しさん
08/12/06 13:07:00
境界テストとか、異常値テストとかしないの？
672:仕様書無しさん
08/12/06 13:27:43
運用開始後テストの為のテストですよ。
673:仕様書無しさん
08/12/06 13:33:30
検収でこのSEﾂｶｴﾈということです。
674:仕様書無しさん
08/12/08 18:09:09
>>666
上でExcelとpowerpointいじくってるだけのクズが、
開発で使う言語でテストケース書くとか、出来るわけないし
要求しても、VBAでよく解らないコードが出てくるのが関の山ｗ
675:仕様書無しさん
08/12/24 20:37:58
テストは軽視してはいかんぜよ
676:仕様書無しさん
08/12/26 00:57:13
俺はあえてバグを残したままテストする時あるな。
その方が油断しないのでテストがきめ細かくなる。
677:仕様書無しさん
08/12/26 01:32:26
最近、まともな仕様書も書けないようなのが上にいるからな
そもそも仕様書もないからユニットテストもやりにくい
ユニットテストをＰＧに強引にやらせるのはかまわんけど
項目もこっちで作らなきゃいけないのは話が違うよね？
めちゃくちゃに追加したコントロール一覧はお前が作れよ
678:仕様書無しさん
08/12/26 01:34:08
って問題もあって開発の請負は絶対にやりたくないな
作ってやるけどそれにかかる金と時間は全部お前が出せって感じ
そうでないとやりたくない
679:仕様書無しさん
08/12/26 11:46:13
コードが全て
仕様書とか書き物は意味なし
よってテスト不要
作ったもんを使え
…そう抜かすアホが居る。
要件を仕様として書き出して合意を得たうえでコードに起こし仕様どおりに動くことを確認するのがテスト。
バグを見つけるためのものでは無い。
あのアホにはテストはバグを見つけることとしか見えてない。
680:仕様書無しさん
08/12/26 12:18:04
制約論理プログラミング言語とか使っている人なんだよ多分
コードが書けた時点でドメイン内で正しく動作するのが証明されている、または
コードが形式的な証明と1対1対応しているような言語
まさかalgol派生の手続型言語を使ってそんな事を言うような人はいないでしょう
681:仕様書無しさん
08/12/26 15:35:56
仕様を紙に起こしたりされると拒絶するかバカ正直に実装する。
せめてテストで確認しようと項目を挙げるとアホかと罵る。
要するに何の制約もされずに気ままにコーディングして自己満足したいだけ。
自分仕様で実装する。
そして出来上がってから仕様が固まると我が物顔で胸張って言う。
｢すごい手戻りですね｣
682:仕様書無しさん
08/12/26 19:18:32
ドキュメントも重要。
テストも重要。
683:仕様書無しさん
08/12/26 19:27:06
仕様書がしっかりしてりゃＰＧ側はなんの問題もないけどね
でも、作ってみなきゃ矛盾が見えないってのもわからなくもない
でも、それを全部に責任にしようとするから戦争がおこる
仕様書ないのにこっちにテスト仕様書作らせようとか
結構キレるのわかる気がする
684:仕様書無しさん
08/12/26 19:29:29
ユニットテストで横に全画面のコントロール
縦にチェック項目５０個ぐらいで１００００個超えるテスト作って
とても流用できないような表を作るのが俺の趣味
貼り付けて仕様書完成なんて絶対にさせない
685:仕様書無しさん
08/12/26 21:18:16
テストの対象はコードじゃなくて仕様や要件だということ。
686:仕様書無しさん
08/12/26 21:50:20
単体テストと結合テスト、機能テストは目的が違う。
687:仕様書無しさん
08/12/26 21:59:00
>>685
仕様書に全コントロールの仕様が書いてあればそれも可能だけどねｗ
全角、半角、ひらがな、カタカナ、英数、少数、文字数、
最小、最大、タブ、エラーメッセージ、補正、・・・
全部かけるもんなら書いてみればいい
688:仕様書無しさん
08/12/26 22:18:10
>>686
違うのは範囲だよ。
テストの目的はひとつ。
単体→結合→機能と分けるとするならば、
それらは通過点。
>>687
コーディングが終わる時点で仕様に抜けがあるようでは仕様書をまとめる人間もプログラマも失格。
その先を急ぐばかりに後に時間とカネを浪費する。
689:仕様書無しさん
08/12/27 00:16:34
>>688
ちょっと俺んとこの職場きて担当者に言ってやってくれ
690:仕様書無しさん
08/12/28 21:37:14
ちょっとスレ違いだけど、コードレビューしてたらPMが乱入してきて、
どうせテストするんだからそんな無駄なことすんな
馬鹿な働き者は何もしない馬鹿より害が大きいんだぜ
って妨害しやがった。
ちなみにそいつはプロジェクトも末期になってから思いつきで
仕様変更して、現場を混乱させる悪癖があることで有名だ。
691:仕様書無しさん
08/12/28 21:38:16
killしろ
692:仕様書無しさん
08/12/29 14:30:25
テストってのは、その前にちゃんとしたクオリティで作ったものが、
ちゃんと「動くこと」を確認するステージであって、
とにかく形だけそれっぽいものを作って、テストでちゃんと動かないところを
洗い出すってのは間違いだと思うんだ。
うちの会社、後者のやり方だから、もういや。
693:仕様書無しさん
08/12/29 20:34:16
テスト自体にもいろいろステージがあると思うんだが
まあシステムテストの段階で単体テストやってるようだと大問題だが
694:仕様書無しさん
08/12/30 19:05:29
ステージが限量されてないのが前提で
>とにかく形だけそれっぽいものを作って
スタブのことね
>テストでちゃんと動かないところを
>洗い出すってのは間違いだと思うんだ。
TDD否定ですか？
>うちの会社、後者のやり方だから
TDDを実践してる会社か、なかなかいい所じゃないの？
695:仕様書無しさん
08/12/30 19:18:24
おまい、TDD言いたいだけちゃうんかと…
696:仕様書無しさん
08/12/30 22:58:40
TDDってなんですか？
もちろんググったりなんかしません
697:仕様書無しさん
08/12/30 23:08:14
Tokyo
Disney
Destroyer
698:仕様書無しさん
08/12/31 01:21:19
>>697
通報しました
699:仕様書無しさん
08/12/31 11:02:57
>>696
逆DDT
700:仕様書無しさん
09/01/01 20:22:50
>>694
お前全然わかってないんだな
いや待てよ、単にネタなのか
こりゃ騙されたなｗ
701:仕様書無しさん
09/01/02 09:56:59
なにがわかってないのか詳しく
702:仕様書無しさん
09/01/02 11:15:56
ユニットテストって明らかに成り立つ場合でもいちいちテストケースって書かなくちゃダメなの？たとえば、引数に範囲外の数値を入れたらXXXというエラーコード返すとか。関数にそういうif文あるんだから返すに決まってると思うんだが・・・やっぱり明示的に書きます？
703:仕様書無しさん
09/01/02 12:05:40
そういうコードができてから書くテストってあまり書く気がしないんだよね
なんというか事務的処理のような面倒臭さがある
それならば逆転の発想でコード書く前にテストを書けとか言われてるけどそれもそれで面倒だし
704:仕様書無しさん
09/01/02 12:30:26
>>701
おれの気持ち
ってかこの業界、相手の気持ちなんて考えたらやってられねー
705:仕様書無しさん
09/01/02 13:15:58
>>703
やっぱりすごく事務的だね。。。
実際はエラーコード返すif文が本当に書かれてるかテストで確かめるってのが正当な方法なんだよなあ。
706:仕様書無しさん
09/01/02 18:14:48
ブラックボックス
707:仕様書無しさん
09/01/02 20:15:01
Javadoc等の為に、コメントに仕様を丁寧に記述して…
あぁぁ・・・ ああぁぁぁああーーー…
うわぁぁああぁぁーーっっ！！！
708:仕様書無しさん
09/01/03 11:47:38
>>707
javadocってそんな分かりやすいか？
（まあ、分かりやすいかは記述している内容次第、といわれればそれまでだけど）
昔のVBなんかで使ったhotdogを思い出してしょうがない・・・
って、>>707が叫んだのは1/02だからか？？
709:仕様書無しさん
09/01/03 12:19:05
>>708
＞javadocってそんな分かりやすいか？
規定のフォーマットで書けば、規定の出力が出てくれるのでｳﾘｼﾞﾅﾙなものよりかは
分かりやすい。
710:仕様書無しさん
09/01/03 18:38:22
今行ってる現場のPLがなんか勘違いしている。
コーディング8割完了って報告したら、「じゃあ単体試験は5割ぐらい完了ってことかな？」ってさ・・・
コーディング中のTry&Errorはテストではないですよ？
こいつ、40近くにもなって何を言ってるんだろうって思いました。
711:仕様書無しさん
09/01/03 18:46:17
>>710
>コーディング中のTry&Errorはテストではないですよ
至極まっとうじゃねーかw
712:仕様書無しさん
09/01/03 19:19:25
コーディング完了＝単体試験完了だってさ
713:仕様書無しさん
09/01/03 19:36:47
>>712
絶対確実に100%達成は不可能だが、TDDしていれば
単体試験完了＝コーディング完了に限りなく近づくだろ
抜けたところは、結合までにテストケース追加すれば
いいだけだし。
お前が糞だってことをきちんと理解しろ、この豚野郎が
714:仕様書無しさん
09/01/04 01:07:01
テストの本で初心者に一番良い本教えてください
715:仕様書無しさん
09/01/04 19:39:51
>>702
書くべきだろ
実は不等号の方向間違えててっていうのがチェックできないじゃん
っていうか俺それ何度もやってるしｗ
テストデータを作るのも困難なんだよね
でも、そのデータ作ってるうちに別の問題も発覚したりするから
あながちなめたものでもないな
716:仕様書無しさん
09/01/04 20:09:58
テスト期間はほんと面白くないね。
これを楽しくするアイデアを下さいな。
717:仕様書無しさん
09/01/04 20:22:55
>>716
レアバグを発見したらみんなで胴上げ
経費で昼飯代を出す（カレー限定）
とか特典をつける
718:仕様書無しさん
09/01/05 06:03:24
エロ掲示板にあるような、殿堂入り機能付き掲示板でバグを晒すとか。
殿堂入りしたバグ発見者に何か褒美やるとかw
719:仕様書無しさん
09/01/06 08:40:35
茶番劇にまた付き合わされる俺の身にもなれ
720:仕様書無しさん
09/01/06 10:35:40
>710
うちの40代園児ニアもまさにそれ。
何度テストの重要性とか説いても「そんなの実機で動かせばいーじゃん？」であっさり却下。
ユニットテストという単語すら知らない癖に「これ使ったらソフトの品質が上がるんだぜ！セミナーの人が言ってた。」という理由だけで
某社のテストフレームワークを買おうとしているうちの上司。。。
最近さっさとこいつら見限ったほうがいいかもと思いつつある。
721:仕様書無しさん
09/01/06 15:26:04
>>720
>「これ使ったらソフトの品質が上がるんだぜ！セミナーの人が言ってた。」
権威に弱いだけな性向が透けて見えるね
なんという騙されやすい人間
722:仕様書無しさん
09/01/06 23:54:48
>>720
お前はそんな糞上司使われて
成果も出せない。結局調子の言い権威的な
セミナーのおっさんにすらまける糞野郎ってことだろｗ
上司が上司なら部下も糞だｗもっと自分がアホで
糞だということを自覚しろｗ
723:仕様書無しさん
09/01/11 17:16:32
>>716
自分が作ったものを自分でテストするとひじょーにつまらんし、モチベーションが全く上がらん
人が作ったものを、色んなパターンで試験してバグ票をバシバシ発行すると、それなりに楽しめるぞ
724:仕様書無しさん
09/01/11 22:06:43
みんなどんなソフトに関わってるの？
俺はWebブラウザとかだけど
725:仕様書無しさん
09/01/11 22:23:44
家電全般
726:仕様書無しさん
09/01/11 22:37:30
POSあぷりとか
727:仕様書無しさん
09/01/12 00:25:55
Webアプリ関係と
FAX関係（ファーム寄りじゃなくて通信より）
あとはDBクライアントアプリ（VB）とかをちょぼちょぼ
728:仕様書無しさん
09/01/24 15:12:41
スパムジェネレータはwebアプリって言ってもいいのかなぁ
729:仕様書無しさん
09/11/10 11:16:51 BE:2734790786-2BP(0)
テスト
730:仕様書無しさん
10/05/08 21:43:30
ユニットテストで中途半端なテスト書いて満足してるゴミは死ね
731:仕様書無しさん
10/05/09 08:50:02
たしかに、どんな簡単なコード(たった一行)でも
そこから予想もしなかった事態が引き起こされることはある(あった)
テストを怠るとえらい目にあう
732:仕様書無しさん
10/06/03 00:08:09
テストは開発だね。
もうテストなしの開発なんて考えられないよ。
733:仕様書無しさん
10/06/06 22:02:27
半端にプログラミングが上手くなるとテストサボるようになるな。
734:仕様書無しさん
10/06/06 23:04:51
単体テストは手間がかかる上に、楽しくないんだよな