テストを軽視する者ども

[1 仕様書無しさん 2008/06/28(土) 19:49:20]

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

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

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

この馬鹿者どもが。

[261 仕様書無しさん 2008/07/08(火) 02:10:45]

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

[262 仕様書無しさん 2008/07/08(火) 02:22:06]

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

[263 仕様書無しさん 2008/07/08(火) 03:28:11]

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

[264 仕様書無しさん 2008/07/08(火) 08:41:06]

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

ImageGear許すマジ

[265 仕様書無しさん 2008/07/08(火) 08:43:02]

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

[266 仕様書無しさん 2008/07/09(水) 00:48:04]

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

[267 仕様書無しさん 2008/07/09(水) 01:13:20]

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

[268 仕様書無しさん 2008/07/09(水) 01:16:38]

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

[269 仕様書無しさん 2008/07/09(水) 01:40:34]

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

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

[270 仕様書無しさん 2008/07/09(水) 06:36:32]

MT?

[271 仕様書無しさん 2008/07/09(水) 07:00:15]

いやいやいや、

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

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

[272 仕様書無しさん 2008/07/09(水) 19:17:24]

80来ないとつまんないね

[273 仕様書無しさん 2008/07/09(水) 22:41:42]

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

[274 仕様書無しさん 2008/07/09(水) 23:10:36]

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

MTは知らんｗ

[275 仕様書無しさん 2008/07/10(木) 02:47:55]

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

[276 仕様書無しさん 2008/07/10(木) 03:12:38]

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

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

[277 仕様書無しさん 2008/07/10(木) 23:31:11]

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

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

[278 80 2008/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 仕様書無しさん 2008/07/11(金) 00:14:23]

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

２．テスト結果による。


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

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

[280 仕様書無しさん 2008/07/11(金) 00:15:46]

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

[281 80 2008/07/11(金) 00:23:30]

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

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

[282 仕様書無しさん 2008/07/11(金) 00:29:52]

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

279も280も俺、俺俺www

[283 仕様書無しさん 2008/07/11(金) 00:31:51]

>>282
いや、オレオレwww

[284 仕様書無しさん 2008/07/11(金) 00:34:56]

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

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


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

[285 仕様書無しさん 2008/07/11(金) 00:40:03]

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

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

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

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

[286 仕様書無しさん 2008/07/11(金) 00:48:20]

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

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

[287 仕様書無しさん 2008/07/11(金) 01:03:04]

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

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

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

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

[288 仕様書無しさん 2008/07/11(金) 01:04:19]

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

[289 仕様書無しさん 2008/07/11(金) 01:05:31]

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

[290 仕様書無しさん 2008/07/11(金) 01:14:59]

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

[291 仕様書無しさん 2008/07/11(金) 01:15:27]

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

[292 仕様書無しさん 2008/07/11(金) 01:20:39]

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

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

[293 仕様書無しさん 2008/07/11(金) 01:22:10]

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

[294 仕様書無しさん 2008/07/11(金) 02:33:59]

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

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

[295 仕様書無しさん 2008/07/11(金) 06:03:21]

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

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

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

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

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

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

[296 仕様書無しさん 2008/07/11(金) 06:12:26]

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

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

[297 仕様書無しさん 2008/07/11(金) 19:44:58]

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

[298 仕様書無しさん 2008/07/12(土) 02:15:00]

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

[299 仕様書無しさん 2008/07/12(土) 15:17:35]

適当≠手抜き

[300 仕様書無しさん 2008/07/12(土) 19:29:48]

サンビャク！

[301 80 2008/07/13(日) 08:07:03]

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

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

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

[302 80 2008/07/13(日) 08:17:57]

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

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

[303 80 2008/07/13(日) 08:29:15]

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

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


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

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

[304 80 2008/07/13(日) 09:11:20]

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

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

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

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

[305 80 2008/07/13(日) 09:30:44]

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

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

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

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

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

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

[306 仕様書無しさん 2008/07/13(日) 11:05:04]

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

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

[307 仕様書無しさん 2008/07/13(日) 11:10:26]

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

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

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

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

[308 仕様書無しさん 2008/07/13(日) 12:54:44]

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

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

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

[309 仕様書無しさん 2008/07/13(日) 18:02:22]

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

[310 80 2008/07/13(日) 20:32:06]

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

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

[311 80 2008/07/13(日) 20:40:06]

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

[312 仕様書無しさん 2008/07/13(日) 21:11:33]

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

[313 80 2008/07/13(日) 23:04:06]

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

[314 仕様書無しさん 2008/07/13(日) 23:05:54]

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

[315 仕様書無しさん 2008/07/14(月) 01:12:09]

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

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

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

[316 仕様書無しさん 2008/07/14(月) 06:01:41]

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

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

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

[317 80 2008/07/14(月) 06:56:34]

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

[318 80 2008/07/14(月) 07:10:39]

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

[319 仕様書無しさん 2008/07/15(火) 01:47:04]

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

[320 仕様書無しさん 2008/07/15(火) 08:56:28]

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

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

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

[321 仕様書無しさん 2008/07/15(火) 08:58:53]

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

[322 仕様書無しさん 2008/07/15(火) 09:26:09]

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

[323 80 2008/07/15(火) 23:50:38]

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

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

[324 仕様書無しさん 2008/07/16(水) 00:20:17]

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

[325 仕様書無しさん 2008/07/16(水) 01:51:18]

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

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

[326 仕様書無しさん 2008/07/16(水) 16:08:56]

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

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

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

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

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

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


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

[327 仕様書無しさん 2008/07/16(水) 16:20:33]

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

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

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

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

[328 仕様書無しさん 2008/07/16(水) 16:37:47]

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

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

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

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

[329 仕様書無しさん 2008/07/16(水) 16:45:46]

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

[330 仕様書無しさん 2008/07/16(水) 17:08:08]

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

[331 仕様書無しさん 2008/07/16(水) 19:24:52]

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

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

[332 仕様書無しさん 2008/07/16(水) 19:37:34]

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

[333 仕様書無しさん 2008/07/16(水) 19:59:42]

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

[334 仕様書無しさん 2008/07/16(水) 20:01:37]

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

[335 仕様書無しさん 2008/07/16(水) 21:27:23]

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

[336 仕様書無しさん 2008/07/16(水) 23:05:12]

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

[337 仕様書無しさん 2008/07/16(水) 23:25:32]

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

[338 仕様書無しさん 2008/07/16(水) 23:35:42]

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

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

[339 仕様書無しさん 2008/07/16(水) 23:37:43]

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

[340 仕様書無しさん 2008/07/16(水) 23:39:08]

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

[341 仕様書無しさん 2008/07/16(水) 23:42:32]

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

[342 仕様書無しさん 2008/07/16(水) 23:43:54]

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

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

[343 80 2008/07/16(水) 23:46:47]

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

[344 仕様書無しさん 2008/07/16(水) 23:48:32]

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

[345 仕様書無しさん 2008/07/16(水) 23:54:42]

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

[346 仕様書無しさん 2008/07/17(木) 00:05:34]

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

[347 仕様書無しさん 2008/07/17(木) 00:07:03]

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

[348 80 2008/07/17(木) 00:07:24]

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


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

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

[349 仕様書無しさん 2008/07/17(木) 00:10:11]

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

[350 仕様書無しさん 2008/07/17(木) 00:13:46]

// 80は極論派だと思う

[351 仕様書無しさん 2008/07/17(木) 00:15:48]

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

[352 仕様書無しさん 2008/07/17(木) 00:38:06]

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

[353 仕様書無しさん 2008/07/17(木) 00:49:15]

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

[354 仕様書無しさん 2008/07/17(木) 00:52:26]

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

[355 仕様書無しさん 2008/07/17(木) 01:26:10]

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

[356 仕様書無しさん 2008/07/17(木) 01:27:47]

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

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

[357 仕様書無しさん 2008/07/17(木) 02:14:55]

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

[358 仕様書無しさん 2008/07/17(木) 02:22:35]

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

[359 仕様書無しさん 2008/07/17(木) 02:47:00]

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

[360 仕様書無しさん 2008/07/17(木) 02:50:37]

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