- 1 名前：仕様書無しさん [2008/06/28(土) 19:49:20 ]
- 何だよ、８割方終わった風な顔で、「コーディング終わりました。後はテストするだけです。」
って...
コーディングが終わってやっと３割終わったかどうかってところだろが。
コーディングが終わってからが本番だっちゅーの。テスト仕様書に従い、テストデータ用意して、
正常系、異常系含めて、抜かりなく全網羅テストすること。これがどれだけ大変なことか。
本当に理解してんのか？ コーディングが終わってやっとスタートラインに立ったぐらいの気持ち
でいろよ、ってくヘラヘラしやがって。
こういう、テストを軽視する輩共が、プログラミングという作業を軽んじ、工数見積りを誤り、
徒に製造を急かし、バグの混入率を間接的に高めているということに気づかんのか。
どんな優秀な奴だって、人間だもの、間違いを犯す。バグを生み出す。それを極力未然に防ぐのが
テストだろ。いつバグが判明するかとドキドキしながら納品後の時間を過ごすか、自信と満足感を
もって笑顔で過ごすか。どちらがいいか自明のことだろ。
プログラミングはなぁ、テストに始まりテストに終わるんだよ。要件を理解し、その中に潜む異常
パターンを見抜き、どんだけ抜かりなくテストをやれるかが一流とカスを分かつ分水嶺だ。
コーディングなんかできてあたり前、肝心なのはテストだ。テストを極めてこそ、一流のプログラ
マーって呼べるんだよ。
この馬鹿者どもが。
- 94 名前：仕様書無しさん mailto:sage [2008/06/30(月) 20:18:54 ]
- 単体テスト工程を自動にしない奴って、それ以降のテスト工程でコードに修正が入ったとき、
どうやってリグレッションテストをやるんだろうか。
まぁ、やらないんだろうけど。
- 95 名前：80 mailto:sage [2008/06/30(月) 20:26:47 ]
- >>89
導入を考えているのか？正確にはHPに聞いた方がいいぞ。
一概には言えないからね。ライセンス形態もいろいろだし。
アプリにもよるし。
10名程度のテストチームで運用するとして、
数千万円くらいかかるんじゃないかな。
>>90
C0を100%にしたからといって、万事OKではない。
逆にC0が50%でも全体としては、OKかもしれない。
必須かどうかと言われれば、必須だが。1000万行を超すコードで
どこまでできるかが問題だ。
逆に、質問なんだが。
C++で言うテンプレート、C#とかで言うジェネリクスを使ったコードを
テストするのにカバレッジはどう考えたらいい？
>>91
文面から見て、そんな気がしたんだが。
- 96 名前：仕様書無しさん mailto:sage [2008/06/30(月) 20:31:13 ]
- 100人で1000万行？
一人10万行？
一体、何人月のシステムなんだよ？
- 97 名前：仕様書無しさん mailto:sage [2008/06/30(月) 20:31:28 ]
- >>92
「限りのあるリソースで膨大なテストを作って挫折するやり方」と
「与えられたリソースで最も効果的にテストを行うやり方」
なら俺は後者を選ぶ。
- 98 名前：仕様書無しさん mailto:sage [2008/06/30(月) 20:33:28 ]
- >>95
> 10名程度のテストチームで運用するとして、
ありゃ？
開発者（プログラマ）がQTP使うんじゃないの？
> 逆に、質問なんだが。
> C++で言うテンプレート、C#とかで言うジェネリクスを使ったコードを
> テストするのにカバレッジはどう考えたらいい？
どう考えるも何も、C0カバレッジに考えることなんてあるのか？
- 99 名前：仕様書無しさん mailto:sage [2008/06/30(月) 20:34:41 ]
- >>97
その後者を実現させる一つの方法が、ユニットテストだと思ってるんだよ。
だから、その点は全く同意できない。
- 100 名前：仕様書無しさん mailto:sage [2008/06/30(月) 20:39:08 ]
- テストチームがQTPでテストするとして、プログラマはどうやって単体テストしてるんだ？
- 101 名前：80 mailto:sage [2008/06/30(月) 20:40:20 ]
- >>98
プログラマーとテスターに別に壁はないので、テスターが管理している
QTPをプログラマーが使わせてもらうことも可能。テストコード自分で
書いてテスターによろしくーってのもあり。柔軟にやってる。
>>99
ユニットテストってどういうものを言ってるんだ？
xUnit?、単なる単体テスト、テストファーストの考え方？アジャイル？
- 102 名前：仕様書無しさん mailto:sage [2008/06/30(月) 20:42:24 ]
- え？QTPってテストコード書くのか？
だったらなぜQTPはよくてUnitTestが悪いのか、わけわからん。
- 103 名前：80 mailto:sage [2008/06/30(月) 20:50:11 ]
- >>102
xUnitだとテスト用のコードを書くのに時間がかかるし、テスターには無理。
QTPのテストコードは、VBScriptでテスターでも書こうと思えばかける。
しかも、自動的にVBScriptのテストコードを生成する機能も付いている。
- 104 名前：仕様書無しさん mailto:sage [2008/06/30(月) 20:53:54 ]
- え？テスターとプログラマに壁はないけどスキルの壁はあるのか？
どうでもいいけど、>>100の回答プリーズ。
- 105 名前：仕様書無しさん mailto:sage [2008/06/30(月) 20:55:25 ]
- QTPだと時間がかからないのは、使いなれてるから。
どんなツールでも慣れれば時間がかからなくなる。
xUnitが時間がかかると思ってるのは、よく知らないか、慣れてないから。
- 106 名前：99 mailto:sage [2008/06/30(月) 20:59:06 ]
- >>101
ユニットテストとは、テストの種類。イコール単体テスト。
使うツールは何でもよいが、アドホックなものや繰り返し不可なものは駄目（俺的に）。
- 107 名前：80 mailto:sage [2008/06/30(月) 22:01:59 ]
- >>104
一般論を言うと、QTPは、システムテスト用のツールでそもそもユニット
テスト用ではない。が、うちでは、ユニットテストにも使ってる。
テストコードは、プログラマが書くが、テストはテスターがやっている。
テストコードは、テスト用データを入力できるようになっている。
テスト用データを用意するのはテスター。
・・・つーかうちの会社の特殊事情聞いてどうするんだ？一般的だとは
言ってないぞ。
- 108 名前：80 mailto:sage [2008/06/30(月) 22:04:42 ]
- >>106
システムテストはやらないのか？
たぶんやるだろ。
ユニットテストとシステムテストはどちらが大切だと思うんだ？
俺はシステムテストだと思っているんだが・・・。
ユニットテストだけでまさか出荷していないよな。
- 109 名前：仕様書無しさん mailto:sage [2008/06/30(月) 22:18:22 ]
- >>12
鉄道動かすプログラムですが、客にバグ出しさせますね＾＾ｖ
- 110 名前：仕様書無しさん mailto:sage [2008/06/30(月) 22:37:47 ]
- テストできない仕様は作らない設計。
- 111 名前：仕様書無しさん mailto:sage [2008/06/30(月) 23:13:53 ]
- テストはそこそこでいいよ
- 112 名前：仕様書無しさん mailto:sage [2008/06/30(月) 23:26:02 ]
- >>107
>テストコードは、プログラマが書くが、テストはテスターがやっている。
なぁ、これテストのプロなのか？
>・・・つーかうちの会社の特殊事情聞いてどうするんだ？一般的だとは
>言ってないぞ。
一般論としてユニットテストを否定してるんだろ？だからどうやってるのか聞いてるんだけど。
>>108
>ユニットテストとシステムテストはどちらが大切だと思うんだ？
どっちも大事に決まってるじゃん。
従来のウォーターフォール的なテストのやり方だと工数が膨らむから、ユニットテストに
力を入れようぜって話だ。
つか、はっきり言って、お前がPMだとしたら、その下でできた1000万行のシステムなんか
受け入れたくないわ。
- 113 名前：仕様書無しさん [2008/07/01(火) 00:24:29 ]
- あげてみるテスト
- 114 名前：仕様書無しさん mailto:sage [2008/07/01(火) 00:35:37 ]
- >>107
> テストコードは、プログラマが書くが、テストはテスターがやっている。
テストコードをプログラマが書くだって?
テストの品質がばらつくからそりゃ駄目だって主張してるんじゃないのか?
>>80
> - 優秀な奴とそうでない奴の差が激しく、属人的でテストの品質がばらつく。
- 115 名前：仕様書無しさん mailto:sage [2008/07/01(火) 01:27:50 ]
- プログラマが書くテストコードは、実際のソースコードの前提条件みたいなもんだよ
「テストの品質」っていうテストは受け入れテストみたいな顧客に近いレベルのテストだね
つまりテスターがやるテストはプログラマがやるテストとは別ってこと
- 116 名前：仕様書無しさん mailto:sage [2008/07/01(火) 01:54:44 ]
- ブラックボックスとホワイトボックスの違い？
- 117 名前：80 mailto:sage [2008/07/01(火) 06:28:14 ]
- >>114
ユニットテストのテストコード -> テスター＆プログラマー
システムテストのテストコード -> テスター
うちのテスターは、すべての仕様書や設計書を読む。
全てのテストは、テスターの監視下で行われる。
もちろん、プログラマーの書いたテストコードも監視下に置かれている。
ユニットテストよりもシステムテストに重きを置いている。
システムテストのカバレッジは100%必須。未達成ならリリースはない。
ユニットテストに関しては、残念ながらカバレッジ100%を待てない。
大抵のプログラマーは、時間切れに陥る。十分な時間を与えてもだ。
プログラマーは、余った時間があればコードを洗練させるがテストは
しない。プログラマーは、テストが嫌いな生き物だ。
- 118 名前：80 mailto:sage [2008/07/01(火) 06:40:46 ]
- >>115
同意。顧客はテストにも金を払っている。ユニットテストは、顧客にとって
のテストではない。プログラマーの失敗を補うものと思われるので
なかなか顧客には納得が得られない。単体テストとデバッグの違いを
明確に区別して作業しているプログラマーがどれだけいることか・・・。
テスターは、あくまでもシステムテストに主眼を置いている。
ただし、うちはテスターが開発初期からアサインされ、
要求把握、分析、設計、ユニットテスト・・・といろいろな工程を
監視している。
一般的には、ユニットテストは、テスターの仕事ではない。
しかし、ユニットテストが本当に重要だというのなら。
プロに監視してもらうのも一案だし、うちでは、効果があった。
- 119 名前：仕様書無しさん mailto:sage [2008/07/01(火) 08:51:27 ]
- 優秀なテスターは、外部テストだけでプログラムの構造、BUGの場所と実装具合が分かる。
- 120 名前：仕様書無しさん mailto:sage [2008/07/01(火) 19:54:57 ]
- テストの経験を積ませてくれない90人は不幸だよな
- 121 名前：80 mailto:sage [2008/07/01(火) 23:47:14 ]
- >>119
同意。さらに言うなら、外部テスト（ブラックボックステスト）で
問題をちゃんと把握できるシステムは良いシステムだと思う。
「テスト可能なシステム」とうわけだ。
ユニットテストに主眼を置かなければ品質を保てないシステムは、どこか
おかしいと思うのだが・・・。
- 122 名前：仕様書無しさん [2008/07/01(火) 23:59:12 ]
- 良くわからんが、テスト駆動の
テスト→実装→レビュー→コミットしてデイリービルドへ
の「テスト」と、完成後の受け入れテストは違うモンだろ？
両方やるんじゃないのか普通。
うちは受け入れテスト（というか、納入前の自社内受け入れテスト）は、専門のテストチームがやってるが。
テスト駆動開発とそうじゃないので、バグ発生件数が如実に違ったから、社内でテスト駆動流行りだした。
- 123 名前：仕様書無しさん mailto:sage [2008/07/02(水) 00:07:17 ]
- 仕様が明確な場合は有効だと思うが...仕様がなぁ...ころころ変わるぐらい
ならまだしも、がらっと変わるときあるからなぁ。根底から。せっかく作った
テストもぱぁ。せっかくいい調子でやってたのに、モチベーションを木端微塵
にしてくれるよなぁ... あ、スレチスマソ
- 124 名前：仕様書無しさん mailto:sage [2008/07/02(水) 00:30:44 ]
- 80はユニットテストに主眼を置けと言われてると思ってるみたいだな。
ユニットテストを軽視するなっつーのが大半の意見だと思うけどな。
ユニットテストの自動化を意識してる所は、当然、機能テストもシステムテストも
受け入れテストも自動化を意識してると思う。ユニットテストやってるから、テスト
可能なシステムになってないとでも思ってるんかいな。
それと、機能テスト以外の話が出てこないが、本当のテストのプロは、機能テスト
以外に力を入れるもんだけどな。たとえばISO 9126に基づく品質保証をめざすとかな。
（蛇足だが、テストチームを外部委託すると、確かに数割はテストのプロがいるが、
残りは二重派遣とかが多いぞ。会社名は出さないが、TEF協賛の品質保証専門の
会社のいくつかはそうだ。全部と付き合いがあるわけじゃないから、全部がそうだとは
言わんが）
それから、はっきり言って、コード書けないテスターは「プロ」とは言いたくない。
テスト対象の言語特性も標準ライブラリの仕様も知らずに、効率の良いテストなんか
できるはずない。
プログラマは、本質的にはテストが好きだと俺は思うぞ。まぁこれは定量的な
評価ができないから水かけ論になるだろうが。
ユニットテストが重要なのは、それが設計という意味でのコードの品質を上げる手段に
なるからだ。自分でユニットテストをやらなくては、真の意味でのTestabilityを
考えられるようにはならないと思うぞ。詳しくは説明しないが、ユニットテストは
保守性を大きく向上させる手段になりうる。
80のプロジェクトでは、たまたまうまくいってるんだろうが、ユニットテストレベルのバグが
ぼろぼろ出るプロジェクトは、テスト技術者のモチベーションを著しく落としめて、
プログラマ対テスターという対立構造を生みやすい。
- 125 名前：仕様書無しさん mailto:sage [2008/07/02(水) 00:35:08 ]
- 長い
- 126 名前：仕様書無しさん mailto:sage [2008/07/02(水) 00:38:17 ]
- すまねー。
でも言い足りん。
またどこかで。
- 127 名前：125 mailto:sage [2008/07/02(水) 00:39:30 ]
- いや、すまん。
俺以外の住人は待ってるのかも知れん。
続けてくれ。
- 128 名前：>123 mailto:sage [2008/07/02(水) 01:24:09 ]
- 使えなくなった(使わなくなった)コードは"習作"と割り切って捨てるが吉
下手に利用しようとして傷口を広げるべからず
- 129 名前：仕様書無しさん mailto:sage [2008/07/02(水) 03:03:17 ]
- >>117
> システムテストのカバレッジは100%必須。
そんなことをやっていたら時間がいくらあっても足りない。
たいていのテスターは時間切れに陥る。十分な時間を与えてもだ。
- 130 名前：仕様書無しさん mailto:sage [2008/07/02(水) 03:08:56 ]
- > ユニットテストよりもシステムテストに重きを置いている。
> システムテストのカバレッジは100%必須。未達成ならリリースはない。
> ユニットテストに関しては、残念ながらカバレッジ100%を待てない。
これはどういうことを意味するか。
それは、システムテストのカバレッジが100%でも
ユニットテストのカバレッジは100%ではないということ。
つまり、バグがあったとしても、システムテストの
カバレッジが100%になるということを意味する。
これが最近巷でよく発生している「ごくまれな事例において発生する不具合」に
つながっている。つまりテスト不足。
そしてそのいいわけがこれ。
> ユニットテストに関しては、残念ながらカバレッジ100%を待てない。
> 大抵のプログラマーは、時間切れに陥る。十分な時間を与えてもだ。
言い換えると、時間が足りないからテストを省くという意味である。
- 131 名前：仕様書無しさん mailto:sage [2008/07/02(水) 08:12:27 ]
- よくある現実
マ「すいません、これ以上仕様変更があると改修はともかく
テストが間に合いません」
上司「テストなんて現地ですればいいよ」
・・・
客「なんだこの不具合だらけのシステムは！こんなものをリリースするなんて
おたくはいったいry)」
- 132 名前：仕様書無しさん mailto:sage [2008/07/02(水) 08:50:19 ]
- >>131
それで上司が
「俺は関係ない、部下の独断だ」
とか言ったら最悪だな。
- 133 名前：仕様書無しさん mailto:sage [2008/07/02(水) 13:10:02 ]
- >>132
それに近いことは言うけどな
「すいません、開発担当のものたちがスケジュールの調整でうんぬん」
結局自分以外の誰かを悪人にしないとすまないらしい
- 134 名前：80 mailto:sage [2008/07/02(水) 21:26:47 ]
- >>124
「テストファースト」は賛成だが、「テスト駆動」は反対だ。
前者は、ソフトを作る時に先にテストを考えるというアプローチだ。
後者は、テストに基づいてプログラミングをするということなんだろう。
- 135 名前：仕様書無しさん mailto:sage [2008/07/02(水) 21:35:17 ]
- >>134
テストに基づいたプログラミングが、イコール設計に基づいたプログラミングと読めないうちは素人だな。
- 136 名前：仕様書無しさん mailto:sage [2008/07/02(水) 21:36:21 ]
- テスト＝設計書という前提だがな。
- 137 名前：80 mailto:sage [2008/07/02(水) 21:42:14 ]
- >>135
プログラミング可能なテストということなんだろ。
コード化が可能なほど詳細に書かれているテストってどうやって記述
してあるんだ？
設計とテストがイコールということは、設計書のタイトルをテスト仕様書
に変更しても問題ないということか？
テストは、設計からすると客観的な別の存在であるべきではないのか？
- 138 名前：仕様書無しさん mailto:sage [2008/07/02(水) 21:44:10 ]
- 世の中には外部設計と内部設計とがあってだな（ry
- 139 名前：80 mailto:sage [2008/07/02(水) 21:53:46 ]
- >>138
外部設計と内部設計は、誤った用語で今は死語になっている。
設計に内部も外部もない。
作りたい対象の詳細が書かれているものが設計書。
外部と内部の区別はない。
- 140 名前：80 mailto:sage [2008/07/02(水) 22:16:44 ]
- >>130
>それは、システムテストのカバレッジが100%でも
>ユニットテストのカバレッジは100%ではないということ。
>つまり、バグがあったとしても、システムテストの
>カバレッジが100%になるということを意味する。
システムテストのカバレッジが100%＝ユーザーに発見できるバグは0個と
言う定義なので、もしバグが見つかったらシステムテストのカバレッジ
が100%ではなかったということになる。
ユーザーがバグを発見できるということは、それは、システムテストで
テスターでも発見できるはずのバグと言える。
ユニットテストをちゃんとしておくとテスターは楽になる。
でもユーザーには関係がない。
- 141 名前：仕様書無しさん mailto:sage [2008/07/02(水) 22:29:57 ]
- >>139
顧客に言えよw
- 142 名前：124 mailto:sage [2008/07/02(水) 23:27:10 ]
- うーんと、とても100人で1000万行のシステムを作ってる人の発言とは思えないんだよなぁ。
反論するのもアホらしいというか。
かまってちゃんの学生さんって気がしてきた。
- 143 名前：仕様書無しさん mailto:sage [2008/07/02(水) 23:34:18 ]
- 100人で1000万行が本当だとしても、多分>>80は、まともにコードが書けなくてVBScriptくらいでしか
テストが書けない10人いるテスターの下っ端だろ。
しかも、派遣テスターｗｗｗ
- 144 名前：仕様書無しさん mailto:sage [2008/07/02(水) 23:54:15 ]
- アナログ（エンドユーザ） と デジタル（プログラム）
の間をとりもつのがテスト。
それぞれ言い分や希望、得手不得手、好き嫌いが異なるのは
当り前。そこはお互いを尊重し譲歩すべきは譲歩し、テスト
という愛の証、いわば結婚指輪があってこそ両者は結ばれる。
テストのない結納（納品）は、すぐに破局を招くのが必定。
ワハハハハハハハッ なんのこっちゃ
- 145 名前：仕様書無しさん mailto:sage [2008/07/03(木) 00:06:52 ]
- 100人で1000万行のシステムで、外部設計も内部設計もない設計書しか作らないってどういうこった。
クライアントとレビューして承認してもらうというマイルストーンは無いのか？
仮にあったとして、実装仕様てんこ盛りの仕様書をレビューしてもらってるとかか？
それとも、実装仕様がほとんど書かれてない仕様書しか作らないのか？
それで、スキルがばらばらなプログラマ９０人で、ちゃんとしたユニットテストも行われず、
どうやって品質を担保してんだよ。
その回答が、プロ１０人によるシステムテスト？
- 146 名前：仕様書無しさん mailto:sage [2008/07/03(木) 00:24:57 ]
- >>117
> システムテストのカバレッジは100%必須。未達成ならリリースはない。
>>140
> システムテストのカバレッジが100%＝ユーザーに発見できるバグは0個と
> 言う定義なので、もしバグが見つかったらシステムテストのカバレッジ
> が100%ではなかったということになる。
カバレッジが100%に達成したことを証明できる人は誰もいないので、
リリースは永遠にないのですね。わかります。
- 147 名前：仕様書無しさん mailto:sage [2008/07/03(木) 00:53:15 ]
- プログラマの心理とすれば、テストってめんどくさいんだよね。
特に結果が分かりきってる（と自分で思い込んでいる）メソッドのテストコード
をいちいち書くのがね。
で、俺がこの前ミスったのは、Cのコードで
double some_calc(int a, int b) {
return d = a / b * 12.34;
}
みたいな感じの奴。 こんな四則演算なんて間違えようがないだろって高を括ってた。
ちょっとした油断でバグって生まれるんだよなぁ。
上の書き方だと、
some_calc(6, 2) だと問題無いが、
some_calc(2, 6) だと期待した結果にならないわけで。当り前だけど。
正解は、return d = (double)a / (double)b * 12.34;
などとキャストするか、引数をdoubleにしとくべきでした。
と、あらためてユニットテストの重要性を認識したしだい。デグレを起こさないため
にもね。
- 148 名前：仕様書無しさん mailto:sage [2008/07/03(木) 00:55:48 ]
- うわ、間違ってた。
return d = a / b * 12.34;
じゃなくて、
return a / b * 12.34;
ね。下の奴も同じく。
- 149 名前：仕様書無しさん mailto:sage [2008/07/03(木) 00:58:01 ]
- 投下するレスのユニットテストも必要だな
- 150 名前：仕様書無しさん mailto:sage [2008/07/03(木) 01:02:24 ]
- 面目ない。。。。
- 151 名前：仕様書無しさん mailto:sage [2008/07/03(木) 01:06:44 ]
- >>80のおかげでユニットテストの重要性を再認識できました。
ありがとう！！>>80
- 152 名前：仕様書無しさん mailto:sage [2008/07/03(木) 20:39:02 ]
- >>149
俺たちがバグ出しするから問題ないよ
- 153 名前：80 mailto:sage [2008/07/03(木) 23:58:00 ]
- >>151
いったんユニットテストを頑張って本当にバグが無くなるかを
試せばいい。経験は大切だと思う。
そのためには、ユニットテストのおかげでバグが減ったことを証明する
方法、つまり指標を決定しなくてはいけない。
まさか闇雲にユニットテストを行うわけじゃないだろ。
>>147
プログラミング能力の低さを、ユニットテストで補うつもりなら
よした方がいい。プログラミングスキル向上の方に力を注いだ方がいい。
> double some_calc(int a, int b) {
> return (double)a / (double)b * 12.34
> }
問題点１：
関数の仕様がありえない。
int -> double
問題点２：
b の 0 かどうかのチェックが必要。0 除算くらいは避けよう。
問題点３：
掛け算から先にする。説明が面倒だからググれ。浮動小数点
で演算する場合は、精度を意識しよう。
以上３つの問題点は、ユニットテストでは見つからない。
なぜかって？プログラマーのレベルを超えるユニットテストが行われる
事は不可能だからだ。
- 154 名前：仕様書無しさん mailto:sage [2008/07/04(金) 00:03:14 ]
- ＞問題点３
＞掛け算から先にする。
え？
- 155 名前：仕様書無しさん mailto:sage [2008/07/04(金) 00:04:08 ]
- つかユニットテストコードは先に書け
- 156 名前：仕様書無しさん mailto:sage [2008/07/04(金) 00:08:45 ]
- なんかとんでもないこと言い出したな・・・
調子に乗らずにちょっと前までのレスで終わりにしてれば締まってたのに
- 157 名前：80 mailto:sage [2008/07/04(金) 00:13:45 ]
- >>155
テストファーストの事だな。
>>154
よーく考えてみよう。
ちなみに掛け算から先にする理由は２つある。
- 158 名前：仕様書無しさん [2008/07/04(金) 00:14:57 ]
- >>147
プログラミングを軽視する者ども
というスレ立てても良いですか？
- 159 名前：仕様書無しさん mailto:sage [2008/07/04(金) 00:19:57 ]
- >>158
「マを侮るなかれ」
ってスレがいいと思います
- 160 名前：仕様書無しさん mailto:sage [2008/07/04(金) 00:29:17 ]
- 80さんよ
一応言っておくが>154は「かけ算から先」がコードの解説と勘違いしてると思われ
俺もそう勘違いしたけどね
問題点と書きながらいきなり修正案を書くのはアホだろ
- 161 名前：80 mailto:sage [2008/07/04(金) 00:37:43 ]
- >>160
なるほど。そこまで意識していなかった。
確かにその通りだ。
一応、掛け算を先にする理由を書いておく。
掛け算を先にするとたとえ引数がintでもキャストする必要がなくなる。
演算子は、暗黙のうちにオーバーロードされるからね。
あと、割り算してすごい小さな値になったらその時点で精度が
落ちてしまうから先に掛け算をする方が良いのだ。
分かっている人からすると「何をいまさら・・・。」だろうけど
念のためにね。
- 162 名前：80 mailto:sage [2008/07/04(金) 00:43:03 ]
- 話はそれたけど、結局、プログラマーがユニットテストで解消される
バグは、プログラマーの能力に依存することは分かったと思う。
それでも、ユニットテストは必要だ。ただし、あまり依存しすぎては
いけない。
アジャイルとか、テストファーストとか言っているカリスマプログラマーの
意見は、「天才プログラマーだからこそできる芸当である。」という事を
念頭に置くべきだ。
ユニットテストで成果を出すための前提条件は「高度なプログラミング
能力に裏付けされた分析・設計能力を備えた人材が揃うこと。」
だと俺は思う。
- 163 名前：仕様書無しさん mailto:sage [2008/07/04(金) 00:44:22 ]
- どっかの糞コテの文体に似てきたなあ・・・
- 164 名前：仕様書無しさん mailto:sage [2008/07/04(金) 00:45:08 ]
- おれは３．５流ＰＧだけど、
だからこそ
作ることよりちゃんと仕様を満たすことの確認こそに命をかける
もってっけー
- 165 名前：仕様書無しさん mailto:sage [2008/07/04(金) 00:59:16 ]
- 正常系なんて客にやらせる
異常系は自分でやる
これだけやりゃ十分
- 166 名前：仕様書無しさん [2008/07/04(金) 02:24:20 ]
- >>162
>話はそれたけど、結局、プログラマーがユニットテストで解消される
>バグは、プログラマーの能力に依存することは分かったと思う。
そこが、まず間違えで、ユニットテストはバグを解消するモノではなくて、
外部仕様（入力・出力・副作用の具体例）そのもの。
今時、テストファーストではない開発は、「ゴールの決まっていないマラソン」
とおなじようにナンセンスだと思うけど、、、
>ユニットテストで成果を出すための前提条件は
>「高度なプログラミング能力に裏付けされた分析・設計能力を
>備えた人材が揃うこと。」
仕様を網羅するユニットテストを作れないということは、
設計できないということと同義。
ユニットテストを作れるくらい全然「高度な人材」ではないと思う。
# 最後はレビュアーの腕次第とはいえ、コード・カバレッジの自動計測
# など網羅性をはかるツールもいろいろ出てきているし、、、
- 167 名前：仕様書無しさん mailto:sage [2008/07/04(金) 02:40:19 ]
- >話はそれたけど、結局、プログラマーがユニットテストで解消される
>バグは、プログラマーの能力に依存することは分かったと思う。
テストファーストという言葉があるように、
バグが発生する前から、テストを書くことができるわけなんだよな。
バグが発生する前というのは、コードをかくまえってこと。
ということは当然、コードを書く人ではなく、
仕様を書く人がテストを書いて、あとは実装者に任せるということも可能なわけだ。
だから仕様書を作る人が、テストコード書けばいいんじゃね？
プログラミングができない人が、設計をするのがどれだけナンセンスなことか。
- 168 名前：仕様書無しさん mailto:sage [2008/07/04(金) 02:47:02 ]
- 携帯電話なんて、発売後に顧客が実地テストさせられてるよなw
- 169 名前：仕様書無しさん mailto:sage [2008/07/04(金) 02:49:50 ]
- あれは顧客じゃない
βテスター
- 170 名前：仕様書無しさん mailto:sage [2008/07/04(金) 02:53:07 ]
- いや、あの製品とか、あの製品とか。あの製品とかの話だよ。
- 171 名前：仕様書無しさん mailto:sage [2008/07/04(金) 02:54:15 ]
- 金払ってまでβテスタに立候補するなんてステキ
- 172 名前：仕様書無しさん mailto:sage [2008/07/04(金) 03:00:04 ]
- カネ貰ってもお断りしますってカンジだな
- 173 名前：仕様書無しさん mailto:sage [2008/07/04(金) 05:16:42 ]
- >>80
>>145にコメントしろ、カス
- 174 名前：仕様書無しさん mailto:sage [2008/07/04(金) 05:26:42 ]
- 携帯なんて所詮おもちゃ。品質は一番あとまわし。
軍事・航空宇宙・医療機器・発電所とかだと品質が命。
80は何作ってるんだろうね？候補は大体想像つくけど。
- 175 名前：仕様書無しさん mailto:sage [2008/07/04(金) 05:46:53 ]
- 1000万行のうち、スケルトン・自動生成が700万行なので、UnitTest軽視なんですよ。
- 176 名前：仕様書無しさん mailto:sage [2008/07/04(金) 07:23:13 ]
- 80はユニットテストは属人性が高いと言っているが、なぜだかシステムテストは属人性が高くない
ような前提になっている。
ユニットテストが成功する前提条件として高度な能力を持ったプログラマが必要としておきながら、
なぜだかシステムテストさえやれば、テスタの能力は関係ないような記述になっている。
また、もっとも効率の良いテストケースを導き出せるのはホワイトボックスの視点を持ったプログラマ
であるにも関わらず、それを全く無視してる。
単体テストは必要であると言いながら、どのように実行しているかを曖昧にして具体的な説明を
避けている。
バグはできるだけ早く解決するのが、もっともコストが低いのは常識なのだが、システムテストまで
解決を遅延させても平気なのはなぜだろうか。
プログラマを育てる気はないのだろうか。全員派遣かSESなのか。
- 177 名前：仕様書無しさん mailto:sage [2008/07/04(金) 20:44:02 ]
- > することは分かったと思う。
この辺りの言い回しが非常にうさんくさい
某アホコテっぽいし
- 178 名前：仕様書無しさん mailto:sage [2008/07/04(金) 21:21:15 ]
- 1000万行ってのが胡散臭いんだよな。
システムテスト件数30万件で、バグは3〜6万件くらいか？
10人じゃさばけないよなぁ、コミュニケーションコスト的に。
ちなみに、Windows 2000は2900万行で、出荷前のバグ件数は数十万件だったらしいぞ。
80のシステムは多分業務系だろうから件数は甘めに見積もった。
- 179 名前：仕様書無しさん mailto:sage [2008/07/04(金) 23:17:16 ]
- 早めにバグを潰した方がトータルコストが安くなる
↓
プログラマはうれしい
↓
テスターもうれしい
↓
でも会社はぼったくるよ
↓
クライアントのためにならない
- 180 名前：仕様書無しさん mailto:sage [2008/07/05(土) 01:38:16 ]
- > クライアントのためにならない
ここちょっと違くね？
時間を金で買うクライアントもいるよ
- 181 名前：仕様書無しさん mailto:sage [2008/07/05(土) 08:05:40 ]
- トラブルシステムを経験してるクライアントは
品質面についての時間、工数をちゃんと理解してくれることが多いけど
「ハァ？品質？金払ってるんだから問題ない
システム入れんのは当然だろ？スケジュール見直し？
ふざけんな、こっちはお客様だぞ！」
というお客様は多い。
- 182 名前：仕様書無しさん [2008/07/05(土) 11:57:14 ]
- 同じ物作りでも、H/Wは徹底的にテストするんだよなぁ。
ちゃんとスケジュールを確保し、テスト項目をドキュメント化し、
何回も精査を重ね、それこそ、しつこいぐらいにテストする。
要件や性能の確認ははもちろん、耐久性、動作限界（温度、湿度、
etc..）、危険の可能性はないか、等々。
それにH/Wの場合は、テストだけでなくマニュアルもしっかりして
いる。人命に関わるケースも多いし、法令化されているから当然と
いえば当然なんだけど。
しかし、これほどの徹底したテストを実施しても、品質不良や車の
リコールなどたまにあるわけだけど。
S/W、特に受託型アプリケーション開発の場合は、何故かねぇ...
テストをやらないわけじゃないけど、個人の技量に依存しちゃって
る場合が多いよなぁ。
- 183 名前：仕様書無しさん mailto:sage [2008/07/05(土) 16:05:21 ]
- >>162
お前のとこのプロジェクトはテストケースレビューしないのか？
低能一人じゃ無理でも、低能三人集まれば1.5倍の能力にはなる
- 184 名前：仕様書無しさん [2008/07/05(土) 16:14:06 ]
- >>183
テストケースレビューって必要か？仕様書がこなれてないだけじゃね？
テストに落とせない仕様書は悪い仕様書。
「URLが開けなかったら、エラーを吐く」←悪い仕様書
「200〜206番以外のステータスコードが返ってきたらエラーを吐く」←良い仕様書
良い仕様書は「おいおい、じゃあタイムアウトは別か？俺が担当すんのか？」みたいなツッコミに繋がる。
- 185 名前：仕様書無しさん mailto:sage [2008/07/05(土) 16:15:12 ]
- >>183
低能一人増える毎に0.5倍なので0.75倍です。1.5倍になるんなら紛れもなく有能な方です。
ちなみに−倍になるのは無能です。
-倍は成果物が0もしくは、焼き直しの仕様が無い成果物しかつくれないって事ね。
低能は一応引き継ぎ出来る。無能は無駄な作業してから結局破棄して一からやり直すので−倍。
落ち目の会社で人が減っていくのは一番有能な連中が消えて低能や無能が増えるので作業効率が落ちる。
それはまだ言いのだが、上が人月取りたい為にさらに人を増やして作業効率を落とす事するので次に有能な連中が消える。
これのスパイラルが有能が一人もいなくなるまで続く。
(ちなみに、低能が有能に化けるので意外に長く続く 無能は低能にも有能にもならない)
いえ、そのスパイラルの最終段階に移行中なんで > 給料遅配。
- 186 名前：仕様書無しさん [2008/07/05(土) 16:17:58 ]
- >>185
会社潰れるとgdgdになるから、今のうちに転職した方が良いよ
責任感から動くと、周りを巻き込んで崩壊するぜ
- 187 名前：仕様書無しさん mailto:sage [2008/07/05(土) 17:48:19 ]
- >>184
良い仕様書から作り出すテストって
ほぼ全てがユニットテストで書けるんだよね。
ユニットテストが苦手だといわれていたGUIでさえ、
GUI操作の自動化により、かなりのことが可能になっている。
出来ないのは見た目のデザインぐらいじゃないかな。
（ここの背景はもっと明るい色でとか）
システムテスト？ よくわからないな。
それはユニットテストで出来ないものなのかね？
- 188 名前：仕様書無しさん [2008/07/05(土) 17:54:19 ]
- >>187
単なる名称とかやりかたの違いで、システムテストもユニットテストも同じ様なもんだよ。
いくつかのチームで作ってると、単体同士では良くても、全体としてパフォーマンスがでなかったりするから。
デザインのテストみたいな感性系は、テスターが大量にいるからなあ
- 189 名前：仕様書無しさん mailto:sage [2008/07/05(土) 17:55:26 ]
- 仕様書のテストはどうやるんだ
- 190 名前：仕様書無しさん mailto:sage [2008/07/05(土) 18:17:43 ]
- >>189
その仕様書には、どんなことが書いてあるの？
そして、その書いてあることが正しいかどうかは
誰が判断できるの？
この二つの質問に答えることができれば、
おのずとどうやるかがわかると思う。
- 191 名前：仕様書無しさん mailto:sage [2008/07/05(土) 18:32:10 ]
- ところで、仕様書の内容だけで、バグが無いソフトが作れるのかな？
理想としてはそうあるべきなのだろうが、仕様書を書く人に聞きたい。
本当に漏れの無い（全ての例外的な事象を考慮している）仕様書を書いていますか？
結局はプログラマがユニットテストという形で仕様書を書いていませんか？
こういう場合にはこうなるという仕様書がユニットテストの中にしか無いってことありませんか？
たぶんね。仕様書の内容を変更があるたびに短時間で
全て見直すことが出来ない限り漏れが無い仕様書を書くことは
出来ないと思うよ。
ユニットテストのように、OK/NGって表示されないのなら、間違っていてもいいもんね。
だから絶対仕様書のテストをサボるでしょ？ 漏れの無い仕様書書かないでしょ？
だからプログラムコードではない自動的に何度も検証できない仕様書は、
あくまで参考資料のために作るのであって
ユニットテストを本当の仕様書＆テストコードにするべきだよ。
時間は限られているからね。何万とある検証項目を何度もする時間は無いんだよ。
- 192 名前：仕様書無しさん mailto:sage [2008/07/05(土) 18:34:03 ]
- ユニットテストを書く人をプログラマーと呼ぶか
テスターと呼ぶか設計者と呼ぶかはこの際問題じゃない。
ユニットテストを書く人が一番重要なのさ。
- 193 名前：仕様書無しさん mailto:sage [2008/07/05(土) 18:50:33 ]
- シングルタスクのプロセスのテストはまぁ簡単。
だけど、これがマルチタスク、マルチユーザの環境になるととたんに
複雑になる。
排他のことやら、負荷の集中や、リソース不足やら、アクセス制御や
セキュリティー関連やら、想定されるケースが指数関数的に増える。
ファイルひとつアクセスするのにも、DBのトランザクション処理の場合
でも、いろんなケースを想定し、異常ケースでどう振舞うのが正しい
のか考えないといけない。そして普通、仕様書にはそこまで細かく書
いてなく、「このファイルのここをこの値で更新する」ぐらいしか書
いてない。ファイルが無かったらどうするのとか、オープンで失敗した
ら?とか、書き込みで失敗したら? とか。人によってそこを確認する人
もいるけど、だいたいエラーメッセージ出すとか、例外を投げるとか、
アボートさしちゃうとか、PG任せなケースも多いわけで、仕様書とプロ
グラムのギャップってどうしてもあるのよねぇ。ま俺から言わせれば設
計者の怠慢なんだけど、それをいちいち突っ込むのも、時間がなかった
り、面倒くさかったり、人間関係に気を使ったりとかいろいろあってで
きなかったりとか。はぁーとにかくめんどいよ、この業界。
自分でスケジューリングして、自分で設計して、自分でつくって、自分
でテストして、全部自分で責任持つのが一番楽だね。
- 194 名前：仕様書無しさん mailto:sage [2008/07/05(土) 18:51:43 ]
- >>193
どこを盾読み?w
|
 |
