08/07/09 06:36:32
MT?
271:仕様書無しさん
08/07/09 07:00:15
いやいやいや、
>「問題の難しさ」を「問題の量」に転化したのだから
なんの証明も根拠もなしに、転化できましたなどと無邪気に主張されてもとても納得できない。
80の中で完結しているロジックが存在するとすれば、それはまだこの場では語られていない。
語ったつもりになっているとすれば、それは表現能力に問題があると言わざるを得ない。
272:仕様書無しさん
08/07/09 19:17:24
80来ないとつまんないね
273:仕様書無しさん
08/07/09 22:41:42
そもそも、UTとかMTとか、
必ずしも企業間で、示す実作業の統一が取れているとは言い切れない、
曖昧模糊とした略語で話を進めようとするのが問題ではないか？
274:仕様書無しさん
08/07/09 23:10:36
実作業としては統一されてないだろうけど、UTの概念は統一されてるだろ。知らない奴は論外。
MTは知らんｗ
275:仕様書無しさん
08/07/10 02:47:55
あとはPGはあると思う（ｗ。
UTとかPTとかは辺りも曖昧だし、当然それ以上はも場所によって違うだろうし。
276:仕様書無しさん
08/07/10 03:12:38
世の中にはテスト技術者資格認定とかいう資格があってだな、そこで公開されている
シラバスとか標準用語集位の事を知っておいてもらえるとありがたいなぁと思ったり
するわけですよ。
80みたいに自分理論で色々言われてもねぇ。
URLﾘﾝｸ(www.jstqb.jp)
277:仕様書無しさん
08/07/10 23:31:11
あら…
一つのモジュールがちゃんと動くかどうか…みたいなテストを
モジュールテストとかMTとか呼んでるんだけど一般的じゃないのかｗ
テストの種類は基本情報の勉強で覚えたくらいだな。
ユニットテストとか現場でのレベル感で縛られるな。
278:80
08/07/11 00:05:27
>>267
> 結局結論としては80の言ってるシステムテストと他の人の考えるシステムテストの定義が違ったってことでいい？
よいです。
> 一般的にテストはUT、IT、STという順番でやっていくはず。
> だからSTの観点はITより上のレベル。分割したモジュールを
> テストしてシステムテストとか、一般的じゃない。
UT, IT, STという３段階が一般的なのは理解している。
ただし、うちでは、これでは、うまくテストを定義できなかった。
質問１
巨大なシステムでも小さなシステムでも等しく
この3段階でテストを進めるので良いと考えているのか？
俺が聞きたいのは、一般論ではない。過去の経験から判断してほしい。
質問２
小規模の場合、UT->IT->STとするなら大規模だとどうなる？
1. UT->UT->UT->UT->UT->UT->UT->UT->UT->IT->ST
2. UT->IT->IT->IT->IT->IT->IT->IT->IT->IT->ST
3. UT->IT->ST->ST->ST->ST->ST->ST->ST->ST->ST
4. UT->IT->ST->IT->ST->IT->ST->IT->ST->IT->ST
5. UT->IT->ST->UT->IT->ST->UT->IT->ST->UT->IT
6. そのた。
279:仕様書無しさん
08/07/11 00:14:23
>>278
１．同じでないと困る。
２．テスト結果による。
全体的にはどんなプロジェクトも同じ工程じゃないと困るが、
そのテスト工程で発覚する不具合の深刻度と混入工程によって、
それぞれ小さな部分テストの反復があるんだよ。
修正する度に、部分的にUT→IT→が間に幾つも入るのさ。
280:仕様書無しさん
08/07/11 00:15:46
場合によっちゃSTまでを反復で何度も行う事だってあるしな。
281:80
08/07/11 00:23:30
つまり、仕様や性能を満たせているかを確認するテスト（ST）が
ずいぶん後回しになるやり方を皆は支持しているわけだ。
そもそも、仕様書は、システム全体に対してのみ書かれるのか？
282:仕様書無しさん
08/07/11 00:29:52
>>281
皆っておい、俺一人しか答えてねえよwww
279も280も俺、俺俺www
283:仕様書無しさん
08/07/11 00:31:51
>>282
いや、オレオレwww
284:仕様書無しさん
08/07/11 00:34:56
>>278
工程として考えたいのか、テスト手順と考えたいのかがよくわからない。
工程なら大規模小規模かかわらずUT＞IT＞STとなるべきだが、
実際に行われてるテストはいくらでも入り組むだろう。
バグ対応入った時とか。
もし工程として(もしくは工程に近いレベルで)
質問２みたいな手順になっているなら
>>78の言うとおり、機能単位で分けるべき。
すごく今更なんだが、>>80の
> 分割すると管理コストが増えるし組織が複雑になる。
> そして、意思疎通が難しくなる。
> 問題が形を変えるだけで何も解決したことにはならない。
なんというか…オブジェクト指向じゃない感じみたいな…
モジュール一つで表示から処理から遷移から何から何までって感じがする…
285:仕様書無しさん
08/07/11 00:40:03
>>80の言っている>>258には同意できる。
■機能要件
開発スタイルにもよるんだろうけどうちの顧客はころころ機能要件を
修正してくるから、機能にマッピングされるモジュール内の関数構成や
実装はそのたびに修正される。
=> ホワイトボックステストはコスト的に合わないので、モジュールの
入出力に相当するAPIだけをブラックボックステスト。
■再利用可能なコンポーネント
タスク・タスク間通信・メモリ管理周りといった部分がそれに含まれる？
不具合が全体に波及するのは勿論だし、そういったモジュールは
関数構成や実装が大きく変わることは無い。
=> ユニットテストで関数ごとにホワイトボックステスト。
コスト的に許されるんなら、全てにホワイトボックステストを用意するに
越した事は無いんだけど。
286:仕様書無しさん
08/07/11 00:48:20
>>258はよくわからなかったけど>>285には納得できる。
> => ホワイトボックステストはコスト的に合わないので、モジュールの
> 入出力に相当するAPIだけをブラックボックステスト。
コスト的にかどうか知らないんだけど、これが一番理想とするテストだと思ってる。
APIの所だけホワイトな、穴あきブラックボックステストみたいな。
287:仕様書無しさん
08/07/11 01:03:04
>>278
スパイラル型でもない限り結合超えてUTに戻る、ってのはないんじゃないの？
上位テストフェーズで不具合が見つかった瞬間はともかく
おれはスパイラルスキーなんだけどね。
ちなみに今関わってるPrjは大規模であっても
UT->IT->ST
これだけ。そして受け入れフェーズで多々トラブル。
おれ、どうしたらいい？
あ、
１．よくない。お客様との要件詰めが完全合致していて、仕様変更などが絶対入らない
前提でもない限りUT->IT->STのみではうまくいかない。
なぜなら、UT後に仕様変更なぞ入ろうものなら品質面での保証がまったく出来なくなってしまう、
客は触って初めて「違うぞこれ？」とか言い出す生き物、などなど。
２．同じことの繰り返し、と考えてしまうと、６．その他、が正解だと思う。
自動テストをUT,IT,STのくくりにいれず同時並行すべきかなー、とか。
288:仕様書無しさん
08/07/11 01:04:19
みんな考え方は現場経験や本人の考え方により違うんだろうけど
こうやってテストフェーズについて色々活発に話せることはよいことだナァ。
289:仕様書無しさん
08/07/11 01:05:31
>>288
なー。おれはよくわからんから読んでるだけだけどなー。
290:仕様書無しさん
08/07/11 01:14:59
>>289
実際現場でテストやその後フェーズで苦労しだすと結構分かってくるんじゃない？
ってか品質面で問題でない現場ならそれが一番の幸せだよ｡゜（ﾟ´Д｀ﾟ)゜｡
291:仕様書無しさん
08/07/11 01:15:27
>>281
仕様書はもちろん個々の機能についても書かれる。
そしてその仕様どおりの入出力を満たしていることの確認もする。
ただし、業務系ではそれをシステムテストとは呼ばない。
個々の機能の入出力を重点的にテストして、それより下位のテストは適当にするっていうのは
いいと思うよ。
本当にただ言葉の定義が違うために言ってることが分かりづらいだけ。
292:仕様書無しさん
08/07/11 01:20:39
今回うけた仕事、システム全体の中の1カ所の開発(というかリファクタ)なんだが
自分たちが受けた部分はともかく、他のところはいきなりシステムテストらしい。
ちゃんとモジュールテストされてない・・・
そのせいで、システムテストで
他の会社が作った部分のデバッグをやらされてる。
293:仕様書無しさん
08/07/11 01:22:10
>>292
そういう段取り／スケジュール考えた奴は軽蔑していいよ
294:仕様書無しさん
08/07/11 02:33:59
>>290
テスト後フェーズは幾度となく経験してるし、
修正後のテスト堂々巡りも経験してるけど、
大規模開発というものを経験したことがないので、
UT→IT→ST が同時進行ならまだしも、何度も巡る
というのが理解できず、議論についていけないｗ
というかあれだな、読んでいて思ったけど、
言葉の定義や論点がずれているだけで、
本質はみんな同じ認識の様な気がする。
295:仕様書無しさん
08/07/11 06:03:21
>言葉の定義や論点がずれているだけで、
>本質はみんな同じ認識の様な気がする。
いや、違うね。俺だけが違ってるという可能性もあるが。
>>281
テストフェーズの定義について、素直に間違っていたと認めた80は評価する。
同じように「仕様書」に関しても、他とずれていると認識してほしいのだが。
そうでないと、>>281の後半部分には答えられない。
>つまり、仕様や性能を満たせているかを確認するテスト（ST）が
>ずいぶん後回しになるやり方を皆は支持しているわけだ。
何度も言うように、システムテストは機能テストと「性能を測る」テストだけではない。
後回しになる（後でやらないと意味がない）テスト（ケース）もあれば、先にやるものもある。
機能テストのことをずいぶん気にしているようだが、「皆」がどう取り組んでいるかは、
「受け入れテスト 自動化」でググってみるとわかるかもね。
296:仕様書無しさん
08/07/11 06:12:26
俺が80と違っている（と思っている）点は、
・ユニットテストは軽視してはならない。むしろ重視すべき。
・ユニットテストはプログラマが行うべき
・ユニットテストを重視することは、顧客のメリットになる
・（おまけ）外部設計と内部設計という考え方はある
80に同意する点もいくつもあるが、それは列挙しない。
297:仕様書無しさん
08/07/11 19:44:58
適当でいいんだよ適当で。
298:仕様書無しさん
08/07/12 02:15:00
適当、よりも、適度、がいいと思うんだ
299:仕様書無しさん
08/07/12 15:17:35
適当≠手抜き
300:仕様書無しさん
08/07/12 19:29:48
サンビャク！
301:80
08/07/13 08:07:03
>>296
>・ユニットテストは軽視してはならない。むしろ重視すべき。
->軽視はしていない。重視もしていない。
おれは、テスターじゃなくて、プログラマー上がりなので、
ユニットテストの大切さを知っている。ただ、組織としてユニットテストを
成功させる場合は、以下の前提条件を満たせないとだめだ。
1. バグが減ったことを評価して、ボーナス査定をUPさせる。
2. 機能実装よりバグが少ないことを重視する。
重要なのは、2 だ。ユニットテストを重視した結果開発のスピードが
落ちたのだ。つまり、機能的要件（フレームワーク、下位コンポーネント
を除く）を実装するチームに関しては、ユニットテストがボトルネックになる。
よーは、すべてがトレードオフなのだ。ユニットテストを重視しすぎると
逆に効率が落ちる開発フェーズがあることを俺は、経験で学んだ。
>・ユニットテストはプログラマが行うべき
-> ユニットテスト＝ホワイトボックステストなら同意。
>・ユニットテストを重視することは、顧客のメリットになる
-> 大規模開発では、顧客には理解されない。
業務系ではないうちでは、専門的すぎて説明するのが難しい。
>・（おまけ）外部設計と内部設計という考え方はある
-> うちの会社にも昔はあったよ。外部設計、内部設計という言葉が
間違っているのに気がついた。
確かに、システムというものを対象にした時にそれの外部について
記述したドキュメントと内部について記述したドキュメントはある。
ただ、外部か内部かという言葉は、対象物を前提としている。
システム、サブシステム、コンポーネント、ライブラリ・・・・などだ。
そして、これらは、整然と関連付けられる。内部設計とか外部設計という
言葉をこれに当てはめると間違いである事が理解できる。
外部は仕様書で、内部は設計書なんだ。これでもわからないなら。
仕様書と設計書の違いを説明してくれないか
302:80
08/07/13 08:17:57
補足だが、プログラマーとテスターの作業量を新規開発の初めから
終わりまで時間を追ってグラフにしてみると俺の言っていることが
分かるかもしれない。
理想を言えば、一番初めのインテグレートの時にテスターが
チームに参加すれば、コスト的にOKなのだが。
大抵は
1. 一番初めのインテグレートは遅れる。つまりテスターが遊ぶ。
2. テスターが開発初期から参加している場合、テスターは
プログラマーよりも暇である。
3. 機能要件は、よく変わる。せっかくユニットテストをばっちりしても
作り直しが多数発生する。さっさと、要求者に「うごく」ソフトを
見せるのは重要だ。
テスターを遊ばせないで、機能要件の間違いを早期に発見できる方法
を俺は支持しているんだ。
303:80
08/07/13 08:29:15
>>285
だいたい、同じ考えだ。
機能要件と再利用可能なコンポーネントでは、テストのやり方
を変えないとだめだ。
再利用可能なコンポーネントは、下位の層で人目につかない。
テスターに通信プロトコルや各種規格をすべて理解してもらうことは無理
なので、プログラマーしか「テストができない」と俺は思う。
違うところは、再利用可能なコンポーネントのテストは、
ホワイトボックステストと加えて回帰テスト（ブラックボックス）を
重視するところだ。
再利用可能コンポーネントは、最適化を繰り返すので、ソースコードが激変する。
つまり、ホワイトボックステストは毎回変わってしまう。
ホワイトボックステスト事態の品質を維持することは非常に難しい、
なので、回帰テストとの合わせ技が重要になる。
304:80
08/07/13 09:11:20
開発工程の中のボトルネックはどこにあるのか？によってやり方は異なる。
プログラマーのスキルが高い場合、テスターのスキルが高い場合など
状況は様々だ。
うちのボトルネックは、「実装」フェーズだった。
スケジュールの遅れは、プログラマーの責任だという認識が多数を占めていた。
なので、ユニットテストが流行したが、結局、失敗に終わった。
ボトルネックにさらに仕事を増やした（人は増えない）結果、開発そのもの
が遅れ、テスターが遊び始めた。設計者は次の設計に入っている。
しかし、ボトルネックが解消されなければ、実装されない設計が溜まる
ばかりだ。テスターは、空いた時間で別のプロジェクトのテストをしている。
リソースが有効活用されていないのは明らかだ。
ボトルネックを解消するのに設計者にテスターにできることはないのか？
そう考えるのが普通だろう。
設計者には、設計を洗練させた。結果、不要なソースコードをプログラマー
が書かなくても良いようになった。
ユニットテストを強要することはやめた。その代りテスターの負担が増えた
が、もともとテスターは遊んでいたのでプロジェクト全体のスループットは
向上した。テスターのストレスは増えたが・・・。
ユニットテストを完璧にやるという事は、ウォーターフォールの考え方
に近い。うちは、繰り返し型の開発をやっているので、たとえバグが残っても
開発の最後の方でプログラマーの手が空いてきたころに網羅性の高いテストを
行うので実質品質が下がるようなことはない。
ユニットテストは有効だが、使い方を間違ってはいけないと思う。
重要なのは、部分最適化（ユニットテストだけを協調する）のではなく
全体最適化（全ての開発工程を見直す）の方だと思う。
305:80
08/07/13 09:30:44
>>291
業務系は、書籍などで知っているだけで現場は知らない。
うちは、メカトロニクス。半分は制御系。ただし、大規模な制御系だ。
Web技術、データーベース、各種通信、など色々開発要素も多い、
言語もC++, C#, Java, その他が入り乱れている。
うちのシステムは、多層になっているシステムの集合体だ。
担当者は、自分の担当範囲だけどをシステムと呼んでいる。
つまり、人によって、システムの範囲（スコープ）が違うんだ。
そして、多段階にインテグレートしてテストを行う。
なので、スコープとレベルの違うシステムテストはチーム内の複数存在
することになる。
見方を変えれば、下位のシステムは、ユニットとも言えなくもないが、
よほどの下位でもない限り「一般論で言うユニット」とは違う。
うちでは以下のように定義している。
・（粒度はともかく）機能的要件を実現する単位をシステム
（サブシステム）と呼んでいる
・下位の原始的なメカニズムを提供するものを、ユニットと呼んでいる。
・機能外要求や、システムのアーキテクチャーをつかさどるものを
フレームワークと呼んでいる。
306:仕様書無しさん
08/07/13 11:05:04
>>301
>ユニットテストを重視した結果開発のスピードが落ちたのだ
結局ユニットテスト非重視と重視で品質面はどちらがあがったの？
非重視で品質落ち（最悪客先リリース後に不具合多々発現）だとしたら
開発スピードが落ちた、ではなく必要フェーズをはぶいてスピードあげてた、
ってだけでは？？
307:仕様書無しさん
08/07/13 11:10:26
みんなの会社で「専任テスター」っている？うちは
a.管理：チームMGR、PL
b.営業／客対応：客対応向けSE、営業
c.開発：開発向けSE、PG
みたいな位置づけになってて、テストは
「それ開発の一環だろ」って見方を上がしているから結局c.が全員で当たってる。
いい形とは思ってないけど、この場合、
フェーズによって「テスター」が暇になる、ってのはないけどなー
308:仕様書無しさん
08/07/13 12:54:44
80の方法だと、ユニットが細かい区分になるので、つまり単純化される。
つまり単純で小さなテストが沢山できる。
質の問題を量に転化したと言っている。
で、コスト削減の為にテストを自動化したと。
まあ、制御系で1000万コードってどんだけーって話だけど。
工場の制御丸ごとやったとしか思えんなぁ。
309:仕様書無しさん
08/07/13 18:02:22
グローバル変数が100万個位あるんだろ
310:80
08/07/13 20:32:06
>>306
品質は向上した。第三者テストの重要性を再認識することとなった。
多分、問題点や間違いを早期のうちに把握できたことと、プロジェクト管理
がやりやすくなったことなども良かったと思う。
プログラマーに、プレッシャーを与えることになったのと、
テスターの地位が向上したのも良かったのかもしれない。
311:80
08/07/13 20:40:06
>>307
うちは、専任のテスターがいる。
そして、開発の初めから開発に参加している。
要件定義が終わったら、これをもとにテストを作成しはじめる。
（テスターが要件を事細かに見るので要件は洗練されるというおまけもつく。）
312:仕様書無しさん
08/07/13 21:11:33
つーか、日本の現場にありがちな曖昧な部分を消したという事が重要だと思う。
グラマーのプライドなんて、邪魔ものだからなー（本人にとってもー）。
313:80
08/07/13 23:04:06
>>312
そういう見方もできるな。要件の曖昧さとテスターのカバレッジを
ユニットテストで補えるとプログラマーが考えているなら、
勘違いも甚だしいな。
314:仕様書無しさん
08/07/13 23:05:54
プログラマの常識は一般人の非常識って事ですね。わかります。
315:仕様書無しさん
08/07/14 01:12:09
>そういう見方もできるな。要件の曖昧さとテスターのカバレッジを
>ユニットテストで補えるとプログラマーが考えているなら、
>勘違いも甚だしいな。
いや、それに甘えてきたSEが問題でしょ。
厳密に言えば、曖昧さは発生しない為に仕様があるわけで、
仕様抜けとか仕様に考慮を入れていないというミスを
グラマーがプログラミングやユニットテストで吸収するのは
よくある風景だ。
単純にそれはSEの怠慢でしかない。
ちなみにそれやらないと、ユニットテストが上がらないっていう
話になって仕様書を押し戻すと作成元の責任になったりする
ので出来ないってのも基本。
316:仕様書無しさん
08/07/14 06:01:41
>>301
> よーは、すべてがトレードオフなのだ。ユニットテストを重視しすぎると
> 逆に効率が落ちる開発フェーズがあることを俺は、経験で学んだ。
バグを取り除くのが早ければ早いほど、トータルコストが少なくなるというのには同意してもらえるのかな？
もっと言えば、トータルコストが少なくなるような効果的なユニットテストを模索しなければならない。
> -> 大規模開発では、顧客には理解されない。
> 業務系ではないうちでは、専門的すぎて説明するのが難しい。
トータルコストが少なくなり、品質も安定するという意味で、顧客のメリットになる。
>-> うちの会社にも昔はあったよ。外部設計、内部設計という言葉が
>間違っているのに気がついた。
>そして、これらは、整然と関連付けられる。内部設計とか外部設計という
>言葉をこれに当てはめると間違いである事が理解できる。
君が間違っていると主張しても、それでも世界は回っているんだよ。
目をふさぐのは簡単だけどね。
317:80
08/07/14 06:56:34
>>316
>バグを取り除くのが早ければ早いほど、トータルコストが少なくなるというのには
>同意してもらえるのかな？
当然そうだが、早いというのは、開発のスケジュールの早い段階でという
意味でだ。うちはスパイラルだからできる芸当なんだが、早期の詳細な
テストが徒労に終わることを経験で知っている。
開発の初期で最低限の要件で開発して、さっさとインテグレート
してさっさとシステムテストをやることで早期にテストを行って
要件の問題を修正している。この場合、ユニットテストは簡単にしか
行われない。
318:80
08/07/14 07:10:39
>>316
>君が間違っていると主張しても、それでも世界は回っているんだよ。
>目をふさぐのは簡単だけどね。
世界って広いぞ。うちは外資系だからアメリカ、インド、ロシア・・・・
いろんな奴と一緒に仕事しているけど、ソフト開発なんてのは、世界的に
統一されたりしてないぞ。各国各様でばらばらだ。つまり、外部設計と
内部設計という言葉が通用しないのを、実際に経験で知っている。
319:仕様書無しさん
08/07/15 01:47:04
なんでシステムテストをやると
ユニットテストをサボれると思うのだろう？
320:仕様書無しさん
08/07/15 08:56:28
>>317
> 意味でだ。うちはスパイラルだからできる芸当なんだが、早期の詳細な
> テストが徒労に終わることを経験で知っている。
誰も、過剰なユニットテストをやれなんて言ってねーよ。ユニットテストをプログラマにやらせると
必ず過剰なものになるからやらせないってことか。
まぁ、お前のチームのプログラマがレベル低すぎて効果的なユニットテストをできないのならそれも仕方ないかもな。
>>318
どんだけ田舎者と仕事してんだよ。
internal designとexternal designも通じない奴と仕事してんのかよ。
321:仕様書無しさん
08/07/15 08:58:53
そろそろメトリックスベースで話さないと埒があかんな。
1000万行のシステムで、第三者検証チームが検出したバグは何件だったんだ？
322:仕様書無しさん
08/07/15 09:26:09
>>318
とりあえず、原著で読んだsoftware development processの本の題名を列挙してくれ。
323:80
08/07/15 23:50:38
>>320
シリコンバレーは、確かに田舎だな。。。。
ちなみに言うとうちでは設計書はあまりかかれない。仕様書を重視する。
うちの外人さんは、「設計書＝ソースコード」だと言い張る。
年収3000万を超えるプログラマーだからできる芸当なのかもしれない。
こいつらテストはしない。テストは、テスターの仕事だと言い張る。
324:仕様書無しさん
08/07/16 00:20:17
ダメだ、はったりにしか見えない｡゜（ﾟ´Д｀ﾟ)゜｡おれもうROMるわ
325:仕様書無しさん
08/07/16 01:51:18
「顧客のメリットになる」ことにこだわっている人が
いるけど、それが必ずしも自社にとってメリットになる
わけでは無いわけで。そういった意味で顧客との間で
落とし所をさぐる時にユニットテストを一部省くというのは
普通にあると思うけど？
やった作業に対して全て金を払ってくれる契約
（それって派遣？）なら全ソースに対してユニット
テストするのもありかもね。
326:仕様書無しさん
08/07/16 16:08:56
経験上の話だが、（良い）詳細設計というものは考えていても作れない。
そういう頭の中で考えただけの設計というものは実際に作るときに、
絶対に問題点やバグがある。パフォーマンスの問題なんか
実際に作らないで目標を達成することなんか不可能。
結局コーディングして、その結果をフィードバックして
設計を完成させなければならない。
ユニットテストってのは、その設計を完成させる為のチェックポイントなんだ。
これは重要なこと。
「設計・コードは簡単に変わるが、チェックポイント（テスト内容）は変わらない。」
ゲームに例えるとこうなる。
仕様・・・世界を平和にする。
ユニットテスト・・・各ステージのボスを倒す。（チェックポイント）
設計・・・どういうルートを通ると早くすすめるか。
コーディング・・・実際のキー操作
最初に仕様があるが、これはすごくあいまいなもの。
システムを作るうえでの大前提だが、コレを決めてもシステムは作れない。
個々の目標が、ユニットテスト。これがシステムを作るうえで一番重要なもの。
これがあれば、設計やコードを柔軟に変更することができるし、間違っていない証明になる。
そして、ユニットテストを作ってから、設計とコーディングを行いながら開発していく。
（実際にキー操作をしないと、考えたルートが通れるのか本当に早いかはわからないね）
327:仕様書無しさん
08/07/16 16:20:33
>>325
あなたが言っているのは、ユニットテストに限った話じゃないね。
「自社のメリットにならない場合はテストを省く。」
「やった作業に対して全て金を払ってくれる契約なら全部テストするのもありかもね。」
もし俺が客で、あなたの会社にシステム開発を依頼する立場なら、
お金を払って開発したシステムを、あなたがちゃんとテストしてくれるかどうか不安だけど。
> やった作業に対して全て金を払ってくれる契約
これは、全部のテストの作業量を見積もって、その金額で契約するわけだから、
全部テストするのが当たり前だと思うんだけど？(客が80%で良いとか言うのなら別）
328:仕様書無しさん
08/07/16 16:37:47
>>1
おれの作ったプログラムにはバグがない。
だからテストは不要。
と書きたいところだが、
Ｃ言語だと１万ステップに３カ所ぐらいは
バグがある。
ただし重要なところでバグがでないように
単体テストをしっかりとやってから納品している。
バグは意思の疎通が十分にできていれば
ほとんどでることはない。
バグのでる仕事というのは、だいたい意志の疎通がとれていない
ということ。
329:仕様書無しさん
08/07/16 16:45:46
俺も1万行に一回くらいしかコンパイルしないけど
ほとんどバグないな
330:仕様書無しさん
08/07/16 17:08:08
何この全力で釣られるスレは・・・
331:仕様書無しさん
08/07/16 19:24:52
>>327
>これは、全部のテストの作業量を見積もって、その金額で契約するわけだから、
>全部テストするのが当たり前だと思うんだけど？(客が80%で良いとか言うのなら別）
100%見積もれて、客が１つも仕様変更をしない場合の話だよね。それって。
そこら辺は開発スタイルの問題かと。俺が言いたいのは「仕様変更のリスクを設計や
計画に含めた形で客に説明しているし、客にもある程度納得してもらってる」
という事。
そういった意味でテストの手法や粒度をどうしましょうか？という事を>>80は言い
たいんじゃないの？
332:仕様書無しさん
08/07/16 19:37:34
>>331
でも、最初っから変更出来るって頭を顧客に植え付けちゃうのもどうかと思う。
費用込みなんだから一度くらいは変更できるよね？ とか言われないか？
333:仕様書無しさん
08/07/16 19:59:42
>>332
プロジェクトがある程度続いている or 続く事が期待できる
相手であればそれもありかと。いずれにしても開発・契約
スタイルによるわな。
334:仕様書無しさん
08/07/16 20:01:37
まあ、変更は一切出来ませんとか言っててもどうせ変更させられるんだけどなwww
335:仕様書無しさん
08/07/16 21:27:23
普通は1000行あたりバグが5～50個くらいかな。数え方やプロダクトの難易度にもよるが。
1000万行だったら、5万～50万個くらいか。
まぁ、正直、これだけのバグを10人でさばけるのなら大したもんだよ。
336:仕様書無しさん
08/07/16 23:05:12
>>335
ちょっと待て
最悪20行に一個出るのが普通か?
たとえ200行に一個でもかなり多いだろ
新人レベルがかなり混じってるならともかく･･･
337:仕様書無しさん
08/07/16 23:25:32
>>336
設計から実装までやれば、延べにしてそのくらいは出るよ。
設計ミスで全面入れ替えの所とか、パフォーマンス出なくてとか、必ず出てくるwww
338:仕様書無しさん
08/07/16 23:35:42
ここがコーディング界のネ申達がおわす所、バルハラですか（１万ステップに１バグあるかないかを誇るという）？
それにしては冴えない連中が多いのですが・・・
339:仕様書無しさん
08/07/16 23:37:43
あいつ使えねーからこっちで直しておこーぜ。
いいよ、バグ無しって言っておけよ。
340:仕様書無しさん
08/07/16 23:39:08
>>329
それはデータ込みの・・・むしろデータのみを扱ったコードですか？
社会保険庁よりは優秀ですねwww
341:仕様書無しさん
08/07/16 23:42:32
>>340
一般人には想像すらできない天才っているもんなのよ。
天才というか、障害というか。
342:仕様書無しさん
08/07/16 23:43:54
>>337
設計にしてもキモになる部分ならプロトタイプなりなんなりで
実装可能性やパフォーマンス検討するだろ。
それを実装まで持ち越しているなら設計工程が十分でないだけ。
ひょっとして手戻りが好きなのか？ｗ
343:80
08/07/16 23:46:47
>>324
はったりじゃないんだけど・・・。
それに、嘘ついても仕方がないじゃんか。
344:仕様書無しさん
08/07/16 23:48:32
>>342
やらねえよ。
だって動作環境が半年後じゃないと揃わないとかザラにあるからな。
パソコン上で幾ら理論構築しても、載せて初めて発覚するパフォーマンスなんてのは普通だし。
345:仕様書無しさん
08/07/16 23:54:42
まあ、何万行書いてもBUGなんて皆無と豪語してる奴は、信じられなくて当然。
そういうコードは結合後に醜い事になってる事が経験的に多いなw
要するに、俺様仕様でBUGゼロってだけだからwww
346:仕様書無しさん
08/07/17 00:05:34
入力がパンチカードとかだった時代ならともかく…
347:仕様書無しさん
08/07/17 00:07:03
どこかの会社の面接を受けて
特技「１万ステップのコーディングでバグが１件です」
って言ったら、さてどうなるか？
348:80
08/07/17 00:07:24
>>342
パフォーマンスに関するチューニングを急いではいけない。
これは、鉄則なので、いまさら説明する必要はないだろう。
パフォーマンスのチューニングは、設計ではなくて
測定に基づいて行われるべきである。
>>345
正論だな。俺様仕様で作ったプログラムを、俺様が作ったユニットテストを
しても、そりゃー合格するよ。そもそも、自分が理解したとおりのプログラム
を書けない奴はうちにはいない。
たいてい、俺様仕様が間違っている時にバグが埋め込まれる。
349:仕様書無しさん
08/07/17 00:10:11
///なんか80に正論とか言われると萎える・・・
350:仕様書無しさん
08/07/17 00:13:46
// 80は極論派だと思う
351:仕様書無しさん
08/07/17 00:15:48
/うわなんでコンパイルエラー！？
352:仕様書無しさん
08/07/17 00:38:06
>>1はいいこと書いてるな。
353:仕様書無しさん
08/07/17 00:49:15
でも、なんか>>1ってチンコ臭そう
354:仕様書無しさん
08/07/17 00:52:26
/* >>351 コメントとして間違っている！！ */
355:仕様書無しさん
08/07/17 01:26:10
まて、もしかするとマンコかもしれないじゃないか
356:仕様書無しさん
08/07/17 01:27:47
>>344
組み込みならモノがないのでやむを得ない面もあるが、
大概は前のチップや代替品を使って見当を付ければいい。
>>348
パフォーマンスを急げと言っているわけではない。
パフォーマンスがどれくらいでそうか当たりを付けて
速度重視にするかフットプリント重視にするかの設計方針に入れろと言っている。
それを設計工程で行わないで後に回すから手戻るんだよ。
357:仕様書無しさん
08/07/17 02:14:55
パフォーマンスって、チップ次第だし。
パソコンアプリ作ってればそのまま試せるだろうがな。
石のアクセス自体仕様通りじゃない場合だって普通にあるからさw
358:仕様書無しさん
08/07/17 02:22:35
>>356
設計段階でパフォーマンスのトレードオフ検討出来るってうらやましいな
たいていは、死守要求だったりするからな。
359:仕様書無しさん
08/07/17 02:47:00
>>358
排反事象なら一方を満たして他方を次善にして、後は交渉術でそ。
全部実現するにはこれこれのコスト(金額、開発期間)がかかりますと言うだけだし。
金払わない以上どこか諦めてね♥
360:仕様書無しさん
08/07/17 02:50:37
>>359
いや、払うだろ。
正当な追加費用ならなwww
361:仕様書無しさん
08/07/17 03:09:11
>>360
まともな客ならなぇ。。。
大概はより良く(まぁいい)より安く(切り詰めてんじゃねぇ)。
362:仕様書無しさん
08/07/18 02:24:12
たしかに>>1はいいこと書いてるな
先日面接で「ｘｘのシステムを作り直すとしたらどのくらい？」って聞かれて
「コアを作り直すなら２人月ぐらいですね、今まで自分らで作っていた部分が今ではライブラリとして提供されているから。
それよりも、テストの方に工数がかかると思いますよ。」って答えた。
でもよく考えたら、ｘｘを作り直す（完成させる）まで、ってのは当然テストが完了して、のことなんだよな。。。
どうも自分の中で実装とテストを別に考えてしまっていたわ・・・ちゃんとしたものを作る、っていう意味では
テストはものづくりの一部だわ、、、今ここで反省します m(^＿^;)m
遠足は家に帰るまでが遠足だかんね。
363:仕様書無しさん
08/07/18 21:10:41
>>362
ど素人さんですか？
今まで何やってたの？
364:仕様書無しさん
08/07/19 01:08:59
>>363
>>362はちゃんとテスト工数の話してるしちょっと区切り間違っちゃっただけだろ。
いじわるなんだからっ！
365:仕様書無しさん
08/07/19 11:20:47
たかだか二人月のゴミみたいなプロジェクトの例を出されましても・・・
366:仕様書無しさん
08/07/19 13:00:56
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
6000人のSEが同時期に集まったのであって，「6000人月」ではない。
開発工数は先に書いた通り，11万人月である。
このSEパワーは開発だけではなく，テストに惜しみなく使われた。
ざっと5000人が8カ月テストをしたとするとこれだけで4万人月，開発工数の3分の1がテストに費やされた計算になる。
本来なら有り得ない開発工数とマネジメント工数とテスト工数である。
本来なら有り得ない開発工数とマネジメント工数とテスト工数である。
本来なら有り得ない開発工数とマネジメント工数とテスト工数である。
367:80
08/07/19 17:11:42
URLﾘﾝｸ(sankei.jp.msn.com)
テスト段階では、全く想定していなかったトラブルが起きた
テスト段階では、全く想定していなかったトラブルが起きた
テスト段階では、全く想定していなかったトラブルが起きた
テストに開発工数の 1/3 を費やしてもシステム障害で行政処分。
部分最適化のもろさを露呈してしまう結果になった。
「全く想定していない」・・・要求定義者や分析・設計者のミスをテストで
カバーできないってこと。間違った仕様を完璧にコーディングしても
それは、バグ。
368:仕様書無しさん
08/07/19 17:22:10
6000人全員が派遣でしたwww って話？？
369:仕様書無しさん
08/07/19 20:48:04
コーディングは終わったので、あとは人海戦術で手動テストしてくださいって
パターンなら最初からうまくいくはずないよ。
370:仕様書無しさん
08/07/19 22:14:17
なんか、ぶっちゃけ私の方法ならうまくいくと間接的に言ってるように
見えるけど、ほんとそうなの？
371:仕様書無しさん
08/07/19 22:22:01
>>369
テストの際に出てくる不具合報告を眺めてるだけじゃ完成しないがなw
テストに入ってからが本当のコーディング作業が始まると思わなきゃ上手く行かない。
372:仕様書無しさん
08/07/20 02:22:31
>>371
メガプロジェクトじゃ、そんなの通用しないし。
373:仕様書無しさん
08/07/20 02:34:44
>>372
はあ？
メガプロジェクトじゃ、最後までコーディングしてる部署が必ずあるよ。
つうか、不具合改修はやらねえの？
374:仕様書無しさん
08/07/20 03:14:48
普通、やるでしょ
PSPの海腹川背みたいな例もあるけどw
375:仕様書無しさん
08/07/20 12:12:05
>>371
> テストに入ってからが本当のコーディング作業が始まると思わなきゃ上手く行かない。
だから、無駄なテスト前コーディングをしないで、
テストをやってコーディングをするんだよね。
376:仕様書無しさん
08/07/20 12:16:01
>>367
> 「全く想定していない」・・・要求定義者や分析・設計者のミスをテストで
> カバーできないってこと。間違った仕様を完璧にコーディングしても
> それは、バグ。
ですよね。だからちゃんと想定して、
その想定した内容をテストとして書くんですよね。
これであなたもユニットテストの重要性を理解したと思います。
377:仕様書無しさん
08/07/20 12:20:56
ついにマ板にも夏が来たか・・・
378:仕様書無しさん
08/07/20 14:21:36
>>376
ユニットテストじゃ、要求定義や設計時のミスは取り除けないよ。
それを元にテストが作られるんだからね。
だいたい、設計時の矛盾は最終的な総合テストまで残る。
要求定義の矛盾は製品にまで残る。
379:仕様書無しさん
08/07/20 15:00:32
>>373
「本当のコーディング作業」の定義次第だな。
そして、その定義を云々するのはくだらねー。
380:仕様書無しさん
08/07/20 17:13:26
80の言い分だけど、
うちの会社は1000万のコードで、
次に、基本証券・金融系では無い。制御系だといって、
最後に、国内最大の金融系の仕様段階での問題点を出している。
あ、あとシリコンバレーと仕事しているってのもあったな。
で、別に仕事のやり方は全否定する要素は無いが、具体例は
全否定されても仕方ないほど妄想力に満ちていると感じたの漏れだけ？
381:仕様書無しさん
08/07/20 19:23:59
>>374
あれは、「仕様です」
382:仕様書無しさん
08/07/23 01:01:35
とりあえずユニットテストやファンンクショナルテストをちゃんと書いていけば
設計時の矛盾とか普通にたくさんでてくるよ。
んで、短いサイクルでどんどんリファクタしていけばいい。
もちろん手動テストもするけど、ばかげた規模での人海戦術テストとかにはならないでしょ。
383:仕様書無しさん
08/07/23 01:06:30
またまた富士通！東証システム障害 プログラムミスが原因 2008/7/22
URLﾘﾝｸ(headlines.yahoo.co.jp)
41 名前：仕様書無しさん 投稿日：2008/07/23(水) 00:00:22
∧∧
富 ( ･ω･) ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
士 （つ/￣￣/ ＜ 1銘柄当たり1280バイトの作業用メモリー領域だから、
通 /＿＿/ ＼ ＼ 2万8000銘柄分、合計3万5000Kバイト・・・
||＼ TOWNS ＼ ＼ 4万バイトということで"PIC 9(40M)"ってことだな
||＼||￣￣￣￣￣|| ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
|| ||￣￣￣￣￣||
.|| ||
え～と40M・・と、 それ、ポチっとな
000230 01 WORKAREA.
000240 03 WORK PIC 9(04). <--- 4バイト
∧東∧
∧富∧ （´<_｀ ） さすがだな富士通
（ ´_ゝ`）/ ⌒i
＿(__つ/￣￣￣/i |＿ そんなこと言ってないで、チェックお願いしますよ、東証&NTTデータさん
＼/＿＿＿/ ヽ⊃
そして・・・・
. . : : : :: : : :: : ::: :: : :::: :: ::: ::: ::::::::::::::::::::::::::::::::::::::
. . .... ..: : :: :: ::: :::::: :::::::::::: : :::::::::::::::::::::::::::::::::::::::::::::
Λ＿Λ . . . .: : : ::: : :: ::::::::: :::::::::::::::::::::::::::::
/:彡ミ゛ヽ;）ー､ . . .: : : :::::: :::::::::::::::::::::::::::::::::
/ :::/:: ヽ、ヽ、 ::i . .:: :.: ::: . :::::::::::::::::::::::::::::::::::::::
/ :::/;;: ヽ ヽ ::ｌ . :. :. .:: : :: :: :::::::: : ::::::::::::::::::
￣￣￣（_,ノ ￣￣￣ヽ､_ノ￣￣￣￣
384:仕様書無しさん
08/07/23 01:06:41
【東証のシステム障害、設定ミスをテストでも見抜けず 2008/07/22 】
鈴木CIOは「設定をミスしたのはベンダーの富士通」とした上で、「多数の銘柄に対し板情報の
問い合わせがあった場合をテストケースに含んでいなかったのは我々の責任。もっと幅広く
テストすべきだった」と陳謝した。
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
【富士通の開発ミスの全責任は東証にある」とみずほ証券、株誤発注裁判 2008/05/09 】
2005年12月にみずほ証券がジェイコム株の誤発注で出した損失を巡って東京証券取引所を
訴えた裁判の第9回口頭弁論が2008年5月9日、東京地方裁判所で開かれた。
原告のみずほ証券側は、被告の東京証券取引所にシステムの発注者としての注意義務違反と
重過失があったことを改めて主張する準備書面を地裁に提出した。
みずほ証券側は「東証はシステムの発注者として、業務上の要求を富士通に伝え、富士通が
開発したプログラムが要求と整合しているかをテストする責任がある」と訴え、「誤発注の
取り消しができなかったのは東証の重過失だ」と主張した。
：
次回口頭弁論は2008年7月25日の予定だ。
~~~~~~~~~~~~~~~~~~~~~~~~~~
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
【「短期間で2回のシステム障害は、痛恨の極み」東証社長が会見 2008/03/25 】
証は2月8日の金融派生商品の取り引きを担う新派生売買システムの障害に続き、3月10日にも
株式売買システムで障害を起こした。
先月22日に新派生売買システムを中心とした障害の再発防止策を発表したばかりだが・・・
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
【特集・東証システム問題リンク】
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
385:仕様書無しさん
08/07/25 03:00:06
ユニットテストは詳細設計どおりにプログラムが稼働するテストと認識しているんだが、
詳細設計が１ＳＴＥＰ対応の設計書でない場合、全パステストの結果って
どういう扱いになるのかな？
386:仕様書無しさん
08/07/26 01:44:42
>詳細設計
の確認はうちではユニット-ユニットの結合テストだな
ユニットテスト対象はプログラム設計
ここ→URLﾘﾝｸ(msugai.fc2web.com)
のV字モデルに近い
なので全パステストなんて結合テストで考えない
387:386
08/07/26 01:57:35
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
の図1もプログラム設計が書いてないけど同じっぽい
388:仕様書無しさん
08/07/28 11:42:25
今日初めて見たが、みんな何か勘違いしてないか？
テストで信頼性は上げられない、テストは
「このプログラムにはバグがあるます」を実証するもので
バグを沢山検出したからと言って、そのプログラムには
もうバグが存在しないと言う実証にはならない。
実際は逆で、統計的に見るとバグ密度の多いプログラムほど
残りの潜在バグが多く含まれている。
テストでは信頼性は旦保できない為、極度に
信頼性が求められるシステムでは、テストをしない開発手法もある。
389:仕様書無しさん
08/07/28 15:31:02
>>388
asshole
390:仕様書無しさん
08/07/28 18:11:43
>>388
＞信頼性が求められるシステムでは、テストをしない開発手法もある。
kwsk
391:仕様書無しさん
08/07/28 18:23:16
耐震偽装と同じレベルだろwww
392:388
08/07/29 00:35:28
>>390
有名な所では、ダーリントン原子力発電所の緊急炉停止システム
393:仕様書無しさん
08/07/29 00:43:53
>>388
ソフトウェアの信頼性を定義してみな
394:仕様書無しさん
08/07/29 02:52:18
IEC読んで言ってるなら凄いけどね・・・
395:388
08/07/29 21:00:07
>>393,394
俺をテストしてどうする。しかし、なぜムキになるか分からん？
URLﾘﾝｸ(ja.wikipedia.org)
>ソフトウェアテストでは、欠陥が存在することを示すことはできるが、欠陥が存在しないことは証明できない。
Wikipediaにもにも書いてあるし、大半の「テスト」関連の書籍にも同じような意味の事が書かれている
いままで、その辺りの知識もなしにレスを書いていたのか？
396:仕様書無しさん
08/07/29 21:28:57
>>395
それは394への答えにはならないよ。
397:仕様書無しさん
08/07/29 21:32:30
>>395
だから、普通テストは
要求された機能が特定の条件下で要求通りの結果を示せるかをテストするんだぜ？
要求されてない（テストされてない）機能がどのように振る舞おうが知ったこっちゃ無いのはあたりまえ。
だからその理論は正しいが、そんな事は誰も要求していないんだよ。
想定外の欠陥は許されるが、想定内の欠陥はダメなの。
398:仕様書無しさん
08/07/30 00:31:54
>>397
＞想定外の欠陥は許されるが、想定内の欠陥はダメなの。
現実は想定外の欠陥でも許さない人間が大半だがな。 相乗りしている他システムが
異様にリソース使いまくって、それに巻き込まれて不具合起きて、それでも不具合が
おきない様にしろと言われかけたときは頭抱えたよ、、、
399:仕様書無しさん
08/07/30 00:34:35
>>398
もちろん納品前に発覚した不具合は想定内だよ。
400:仕様書無しさん
08/07/30 00:36:13
予想GUYダ！
401:仕様書無しさん
08/07/30 00:52:25
よそう、GAYﾀﾞ!
402:仕様書無しさん
08/07/30 02:14:08
>>399
納品後ですが、何か？
しかも納品後すぐとかじゃなくて、数ヶ月たってとかだったり、他の納品先だと
そんなこと起きなかったりとかで調査だけでも結構かかりましたが。
403:仕様書無しさん
08/07/30 02:16:01
>>402
受け入れ検査終了後なら別料金もらってんだろ。
いいじゃん仕事あって。
404:仕様書無しさん
08/07/30 18:45:40
>>388
＞信頼性が求められるシステムでは、テストをしない開発手法もある。
ネタにしてはよく出来てる手口。
405:仕様書無しさん
08/07/30 21:15:43
>>395
で、信頼性はどう定義するんだ？
406:388
08/07/30 23:03:31
>>397
限られた前提条件・限られた入力値・限られた入力値組み合わせでテストをして
その機能が、全て正しく動くと思ってる？ テストが何たる物か分かっていない証拠だな
>>404
自分の知識で分からないものはネタか！やっぱりこんな奴がいるんだ
例を出したんだから、調べれば分かると思うが。
>>405
俺に聞いても、プログラムの信頼性は上がらんだろう、自分で考えないと。
407:仕様書無しさん
08/07/30 23:07:51
>>406
誰も信頼性の上がる方法なんて聞いてない。
信頼性の定義を聞いているのがわからないのか？
408:仕様書無しさん
08/07/30 23:09:50
>>406
お前もちゃんと調べてから例出しな
409:仕様書無しさん
08/07/30 23:10:08
>>406
全て動くなんて言ってないが。
ファビョるのもたいがいにしろよ。
410:388
08/07/30 23:19:22
>>407
>信頼性の定義を聞いているのがわからないのか？
分かって書いているんだが、分からないのか？
>>408
調べても分からなかったのか？俺はこれ以上教えるつもりはないから
>>409
>全て動くなんて言ってないが。
だから、テストでは信頼性は確保出来
411:仕様書無しさん
08/07/30 23:20:59
>>信頼性の定義を聞いているのがわからないのか？
>分かって書いているんだが、分からないのか？
どこに書いたんだ？
412:仕様書無しさん
08/07/30 23:21:48
駄目だこいつ。
413:仕様書無しさん
08/07/30 23:22:33
テストの前にソースの読み直しをお願いします
先輩
414:仕様書無しさん
08/07/30 23:23:52
単純リプレースとか言って営業がとってくる仕事ほど
前の機能をちゃんと満たしてるか（正しく動作するか？）って意味で
テストが重要、
って口をすっぱくして言ったんだがヌルーされた。
マシン->マシンでコピーして、簡単に動作確認すればいい
だってさ
まぁ、うまくいけばいいんだけどね。。。その時期夏休みとって携帯電源切っとこう
415:仕様書無しさん
08/07/30 23:23:58
原子力発電所のソフトウェア開発について議論するスレじゃないよ
416:仕様書無しさん
08/07/30 23:24:26
>>410
394にまともに答えられない人に教えてもらう事無いと思うよｗ
417:仕様書無しさん
08/07/30 23:25:44
何手法だか知らないが、その手法でぬるいメガプロジェクトでも回してみればいいさ。
418:仕様書無しさん
08/07/30 23:40:28
KKDは勘と経験と度胸による見積もり法です
419:仕様書無しさん
08/07/30 23:40:45
それ
なんて
みずぽ？
420:388
08/07/31 00:05:03
>>411
>>どこに書いたんだ？
信頼性の定義は書いていない
>>412
>駄目だこいつ。
そうだな
>>413
>テストの前にソースの読み直しをお願いします
読み直しは大事だと思う、テストよりも
>>414
何処でも営業は同じ、そんなもん
>>415
ソフトウェアの話じゃないのか？
>>416
教えるつもりもないから大丈夫
>>417
そこまで信頼性を求められるプロジェクトは、ほとんどない
>>418
勘・経験・度胸は大切だと思うよ、マネジメントは人間性が一番重要だと思う
>>419
???
421:仕様書無しさん
08/07/31 00:10:24
>>420
聖徳太子現る
明日は合コンだってさ、木曜だしなーーー
女の子たちの接客上手をテストしてやるぜ～
422:仕様書無しさん
08/07/31 13:06:27
>>420 からおじゃば臭がするのは気のせいか？
423:仕様書無しさん
08/07/31 19:21:50
気のせいじゃなくね
424:仕様書無しさん
08/07/31 20:04:06
>>421
どこのキャバでやんの？
425:仕様書無しさん
08/07/31 20:39:41
>>420
おじゃばとしては、どういうテスト手法を理想としてんの？
426:仕様書無しさん
08/07/31 20:43:06
>>422
いや、ハカセじゃないのかシステム工学を語りたいんだろう
でもハカセはアホだから違うかｗ
427:仕様書無しさん
08/07/31 20:48:28
>>425
教えてやろう君にはすばらしい餌だなｗ
428:仕様書無しさん
08/07/31 20:52:52
>>426
お前、おじゃばだろ
429:仕様書無しさん
08/07/31 22:14:57
>>424
キャバじゃないし、今日でもなかった・・・
だれかおれの視力、聴力、記憶力をテストしてくれ
430:仕様書無しさん
08/07/31 22:18:40
>>429
つ URLﾘﾝｸ(homepage3.nifty.com)
431:仕様書無しさん
08/08/01 03:03:06
テストしてほしけりゃ金よこせ
432:仕様書無しさん
08/08/01 03:36:48
まともにテストできるか能力を示せ。
433:388
08/08/02 15:13:28
テストは限られたリソースの中で、いかに効率良く不具合を見つけるかが重要
例えば、同じプログラムをテストして
「Aは１０件のテストケースで５件のバグが見つけた」
「Bは１００件のテストケースで１０件のバグが見つけた」
では、Bの方がAより残りのバグも少ないので信頼性のあるプログラムになるが
テストとしては、半分の確率でバグを見つけたAの方が、「良いテスト」と言える
つまり、テストは効率性が重要で、プログラムの信頼性は考えない
（バグを多く見つけるかでは無く、「"効率的"」にバグを多く見つけるかが重要)
同値テストや限界値テストなどのテストテクニックも、バグを効率に見つける為に考え出されたもの
434:仕様書無しさん
08/08/02 16:18:18
なるほどね。
おじゃばという人物は、コミュニケートする気はないわけだ。
相手とちゃんとやりとりしたい訳じゃない。
単に「自分は知識があるのだ、おまえらより優れているのだ」と思っていて、
その優れた俺様の知識をひけらかし(たつもりになっ)て、気持ちよくなってるだけ。
その過剰な自己過信が揺らぐことも、基本的にはなくて、
それ故に、主張が基本的にいつでも一方的で、言いたいことを言うだけ。
使いようによっては、存在に意味を持たせる事は可能かもしれないけど、
人間的にはゴミだなぁ。ｗ
435:仕様書無しさん
08/08/02 16:23:25
Aの方が効率悪いじゃん？
なんでBは100件もこなせてるのに
Ａは10件しかこなせなかったんだ？
リソース一緒なのに。
436:仕様書無しさん
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時間労働がデフォ。
夜間シフトは、金儲けにうってつけ。