テストを軽視する者ども

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 2chのread.cgiへ]
Update time : 05/09 17:10 / Filesize : 237 KB / Number-of Response : 735
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

テストを軽視する者ども

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

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

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

この馬鹿者どもが。
237 名前：仕様書無しさん mailto:sage [2008/07/07(月) 11:40:51 ]: >>235
マ辞めちまえ。おまい迷惑。
238 名前：仕様書無しさん mailto:sage [2008/07/07(月) 11:45:04 ]: >>237
俺が辞めたら客が困るんだぜ
239 名前：仕様書無しさん mailto:sage [2008/07/07(月) 11:47:57 ]: >>238
そう思っているのはおまいだけw
240 名前：仕様書無しさん mailto:sage [2008/07/07(月) 12:01:08 ]: >>239
言うと思ったｗ
241 名前：仕様書無しさん mailto:sage [2008/07/07(月) 12:30:29 ]: わたしが死んでもわたしの代わり(にテストさせられる可哀想なヤツ)は居るもの
242 名前：仕様書無しさん mailto:sage [2008/07/07(月) 12:40:45 ]: >>239
勘違いも甚だしいな。
お前が辞めた方が客は喜ぶぞ。
テストの不十分な商品渡されるよりよっぽど安心だろ。
243 名前：仕様書無しさん mailto:sage [2008/07/07(月) 12:43:34 ]: レス先間違えてね？
244 名前：仕様書無しさん mailto:sage [2008/07/07(月) 12:55:08 ]: 専ブラの番号ズレたんじゃね？
245 名前：仕様書無しさん mailto:sage [2008/07/07(月) 16:29:11 ]: >>241
そんな（おれらに被害が及ぶような）こと言うなよ
246 名前：仕様書無しさん mailto:sage [2008/07/07(月) 16:34:17 ]: >>245
だって（めんどくさいんだもの）仕方ないじゃない
247 名前：仕様書無しさん mailto:sage [2008/07/07(月) 19:53:15 ]: >>210
> 仕様書・・・システムが、ユーザー（人、外部システム）に提供する利益
> 　　　　　　が記されている。

世間では、その部分を要件定義書と外部設計書にわけてるんだよ。
例えばユーザインターフェース仕様。これはクライアントが要件として出す場合もあるが
それはまれで、普通はシステムを作る方が設計する。

> 仕様書に基づいたテスト・・・システムテスト
> 設計書に基づいたテスト・・・ユニットテスト

なるほど、「俺定義」で今まで話してたのはわかった。

> 仕様書や設計書はシステム、サブシステム、コンポーネントといった
> 開発対象それぞれに対して作成される。

サブシステム分割や、何をコンポーネント化するかというのは、内部設計と普通は言う。
なので顧客レビューはせず、80定義で言う所の仕様書は書かない。

> ユニットテストはもろ刃の剣で、プログラマーのレベルが高い事が前提だ。
> それに、テストコードを書くのはコスト高だ。

ユニットテストのケースレビューやコードレビューをするという概念は全くないの？

顧客はユニットテストにはお金を出さないというようなことを繰り返し言ってるが、
まったくそんなことない。顧客は品質にもお金を払ってる。
ユニットテストでバグを潰そうが、システムテストでバグを潰そうが、顧客が知ったこっちゃ
ないのは同意する。
248 名前：仕様書無しさん mailto:sage [2008/07/07(月) 20:02:58 ]: （続き）
「効率の悪いユニットテスト」や「品質の低いユニットテスト」は確かに否定されるべきだが、
だからと言って、ユニットテストが否定されるものではない。
バグは潰すのが早ければ早いほど、その修正コストは低くなる。これには80も同意してくれる
ものと思う。
「効率の悪いユニットテスト」や「品質の低いユニットテスト」が、開発コストを押し上げている
のであれば、「効率の良いユニットテスト」「品質の高いユニットテスト」に出来ないかを考えるのが
まず第一だ。なぜなら、バグは潰すのが早ければ早いほど修正コストが低いからだ。
修正コストが低ければ、開発コスト全体も低くなり、それが顧客のメリットになる。

ユニットテストをほとんどやらずに、第三者によるシステムテストに力を入れるという方法論も
あるだろう。

俺自身は、この方法論を全く支持しないが、スキルの低いプログラマが多数いるチームであれば
そのような方法論を取った方が、全体のコストが下がるのかもしれない。

しかし、方法論として提示するのであれば、システムテスト重視の方が品質が高くなる理由（根拠）と
ある程度のメトリクスを提示しなければ、第三者を納得させることはできないと思う。
249 名前：仕様書無しさん mailto:sage [2008/07/07(月) 20:18:40 ]: サブシステムやコンポーネントやレイヤーを合わせてテストするのは、普通、結合テストと言います。
250 名前：仕様書無しさん mailto:sage [2008/07/07(月) 20:28:37 ]: （少し追加）

>>231
> これを、テスト自動化によりコストを減らしているわけだ。

今のところ、80の発言から読み取れる「削減できているもの」は、このシステムテスト
（ブラックボックステスト）実行コストのみだ。

本気でテストの自動化をやってるところは、自動化されたテストの実行コストなど、
テスト全体のコストにほとんど影響を与えないことを知っている。
つまり、本当に自動化されているなら、実行するPCの台数を増やし、夜間に動作
させればよいのである。

問題は、自動化にかかるコストと、第三者検証の場合は、テスタ－プログラマ間の
コミュニケーションコスト、プログラマチームからテスタチームへ引き渡すリソース管理、
出荷判定（100%バグを修正できない場合の判定という意味での）などのコストをどう
減らすかなんだよ。
251 名前：仕様書無しさん mailto:sage [2008/07/07(月) 20:31:23 ]: （書き忘れ）
テストのコストを引き上げる要因をひとつ忘れていた。
自動化テストの場合、それが正しいテストかどうかのチェックに非常に時間を取られる。
事前条件は正しいのか、テストの内容は正しいのか、事後条件は正しいのか、（自動）確認は
正しく行えているかなど。
252 名前：仕様書無しさん mailto:sage [2008/07/07(月) 20:43:11 ]: ・PGが作ったものが「作ったとおりに」動く事（あるパス通したら落ちる、ボタンはあるけど反応がない、など）
　単体としてはまともに動く事を確認するのが単体テスト

・１PGから複数PG、はては複数チームが作ったものが、ちゃんと連動すること
　お客様にうたった仕様どおりの動作をしている事を確認するのが結合テスト

・（結合との位置づけがあいまいなんだけど）
　お客様レベルでの操作をしてもらって、「うん、ちゃんと動いてますね」
　って確認を本番環境、現地レベルで取るのがシステムテスト、そして最終的な運用テスト

とか位置づけちゃってたわ、ワタシ

>>248の言うように、単体レベルでの不備はテスト初期（というか開発途中）のレベルで
とっておいた方がいいと思う、コストというより、後の方のテストはざるの目が粗いから
思わぬ不具合（ある異常系パスを通るとシステム全体がダウンしてしまう、など）を
見逃してしまう可能性が高い（下位のレベルの不具合は上位のテストからはブラックボックスなので）
253 名前：仕様書無しさん mailto:sage [2008/07/07(月) 21:08:02 ]: 最後のは、普通、受け入れテストと言いますね。
254 名前：仕様書無しさん mailto:sage [2008/07/07(月) 21:17:01 ]: >>253
thx
255 名前：仕様書無しさん mailto:sage [2008/07/07(月) 21:58:28 ]: テストが億劫になるｽﾚだなぁ
256 名前：仕様書無しさん mailto:sage [2008/07/07(月) 23:25:27 ]: 「システムテスト」が設計(design)ではなく、仕様(specification)に基づくものだという80の意見には同意する。
80が言う方法論には同意しないが。

依然として機能テスト以外のテストに関する話が出てこないが、よくまとまっているページを見つけたので
紹介しておく。
en.wikipedia.org/wiki/System_testing

システムテストでは、機能的に要件とマッチしていることを保証するとともに、上記ページにあるようなテストを
行うのが一般的だと思う。

まぁ普通は機能外要件を要件定義書に書けるチームはほとんど無いと思うが、「システムテスト」工程で
行うもんなんだよね。

また、いわゆる「内部設計」以外を「仕様書」におこして、それをクライアントレビューにかけるというのは、
双方にとって負担が大きいと思うね。工事進行基準が始まれば、「要件定義書」の範囲も、業界的に合意が
形成されていくのかもしれないね。
257 名前：仕様書無しさん mailto:sage [2008/07/08(火) 00:11:34 ]: >>256
wikiを良く纏まったページって紹介するのはなんだと思う。

80の言っている事だけど
一つの方法論だけど・・・、

>「問題の難しさ」を「問題の量」に転化したのだから、当然、
>ブラックボックステストの件数がかなり多くなる。
>これを、テスト自動化によりコストを減らしているわけだ。

テスト項目表作成も自動化しないとコストかかるね。
正確には「正しい｣テスト項目表の作成。

ぶっちゃけ、テストにコストがかかるのではなくて、
テスト項目の洗い出しにコストがかかり、
さらにその妥当性をだすのにコストがかかる。

半年後のユーザの意見を聞きたいな、ボトルネックが山に
様にできてそうだ。
（まあ、最近のPCは出来が良いので問題おこんないって前提だろうけど）
258 名前：80 mailto:sage [2008/07/08(火) 01:01:27 ]: >>256

■機能要件
機能要件は、インクリメンタル型で開発している。仕様書に基づいて
要求が満たされているかをチェックするのに重点が置かれる。

■フレームワーク
非機能要件は、フレームワークに含まれるのがほとんどで、イテレーティブ
型で開発をしている。
実際には、リファクタリングをしまくるわけだ。つまり、外的な
ふるまいだけをテストして、内部はガンガン変えていくのだ。
なので、単体テストは軽視され回帰テストが重要視される傾向がある。

■再利用可能なコンポーネント
レイヤーの低い位置にいる、再利用可能なコンポーネントは、
不具合が全体に波及するので、ユニットテストからコツコツ積み上げる。
ユニットテストは低レベルのコンポーネント（ライブラリ）開発で役に立つ。
259 名前：80 mailto:sage [2008/07/08(火) 01:09:01 ]: >>256
>また、いわゆる「内部設計」以外を「仕様書」におこして、それを
>クライアントレビューにかけるというのは、双方にとって負担が
>大きいと思うね。工事進行基準が始まれば、「要件定義書」の範囲も、
>業界的に合意が形成されていくのかもしれないね。

開発プロジェクト内で閉じるレビューがほとんど。レビューは、一種の
テストだから軽視してはいけない。それに、ドキュメント
に関しては、CMMとかISOとかやってるので結局書かなくてはいけない。
260 名前：仕様書無しさん mailto:sage [2008/07/08(火) 01:58:40 ]: 80は一体誰と闘い、何が目的なんだ
261 名前：仕様書無しさん mailto:sage [2008/07/08(火) 02:10:45 ]: >>259
>>210の内容と、思いっきり矛盾してるのに気がつかないのか？
262 名前：仕様書無しさん mailto:sage [2008/07/08(火) 02:22:06 ]: 80をやり込めても、誰も何も得しないよ。逆もまた真なり。
263 名前：仕様書無しさん mailto:sage [2008/07/08(火) 03:28:11 ]: つまり、80にやり込められても、誰も何も得しないw
264 名前：仕様書無しさん mailto:sage [2008/07/08(火) 08:41:06 ]: >>257
システム／ネットワークのパフォーマンス的なボトルネックは生まれにくくなってきてるけど
利用するライブラリ／パッケージ自体は未だに流行に合わせどんどん入れ替わり立ち替わりな
うちのPrjでは、半年以内に「原因不明系」のトラブルが多発してるよ。

ImageGear許すマジ
265 名前：仕様書無しさん mailto:sage [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 名前：仕様書無しさん mailto:sage [2008/07/09(水) 00:48:04 ]: 作業指示出してる人が「テスト嫌い。あんなもん無駄だしやってると苛々してくんだよね。」とか言っててこっちが苛々ですよ。
267 名前：仕様書無しさん mailto:sage [2008/07/09(水) 01:13:20 ]: 結局結論としては80の言ってるシステムテストと他の人の考えるシステムテストの定義が違ったってことでいい？
俺的には80が言ってるシステムテストは単体テストレベル。
一般的にテストはUT、IT、STという順番でやっていくはず。
だからSTの観点はITより上のレベル。分割したモジュールをテストしてシステムテストとか、一般的じゃない。
268 名前：仕様書無しさん mailto:sage [2008/07/09(水) 01:16:38 ]: >>267
同じ同じ。
UTってMTと一緒なのかな？
269 名前：仕様書無しさん mailto:sage [2008/07/09(水) 01:40:34 ]: 80は業務系じゃないらしいから考え方が違うんだと思う。

UT：作ったものが仕様書どおりだよねってことをIF含めて確認するテスト。
⇒コードのチェック
IT：それぞれが作ったものをつなげても動くよね？ってことを確認するテスト。
⇒仕様書の整合性のチェック
ST：とりあえず動くもの作ったけど、そもそもこんなんでよかったんだっけ？ってのを確認するテスト。
⇒要件を満たしてることのチェック。
受け入れテスト：STまでやってるけど、レビューとか適当な客もいるので後で文句を言わせないために
実際に動かしてもらって、確かに要件満たしてますよね？って確認するテスト。
⇒保険。
270 名前：仕様書無しさん mailto:sage [2008/07/09(水) 06:36:32 ]: MT?
271 名前：仕様書無しさん mailto:sage [2008/07/09(水) 07:00:15 ]: いやいやいや、

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

なんの証明も根拠もなしに、転化できましたなどと無邪気に主張されてもとても納得できない。
80の中で完結しているロジックが存在するとすれば、それはまだこの場では語られていない。
語ったつもりになっているとすれば、それは表現能力に問題があると言わざるを得ない。
272 名前：仕様書無しさん mailto:sage [2008/07/09(水) 19:17:24 ]: 80来ないとつまんないね
273 名前：仕様書無しさん mailto:sage [2008/07/09(水) 22:41:42 ]: そもそも、UTとかMTとか、
必ずしも企業間で、示す実作業の統一が取れているとは言い切れない、
曖昧模糊とした略語で話を進めようとするのが問題ではないか？
274 名前：仕様書無しさん mailto:sage [2008/07/09(水) 23:10:36 ]: 実作業としては統一されてないだろうけど、UTの概念は統一されてるだろ。知らない奴は論外。

MTは知らんｗ
275 名前：仕様書無しさん mailto:sage [2008/07/10(木) 02:47:55 ]: あとはPGはあると思う（ｗ。
UTとかPTとかは辺りも曖昧だし、当然それ以上はも場所によって違うだろうし。
276 名前：仕様書無しさん mailto:sage [2008/07/10(木) 03:12:38 ]: 世の中にはテスト技術者資格認定とかいう資格があってだな、そこで公開されている
シラバスとか標準用語集位の事を知っておいてもらえるとありがたいなぁと思ったり
するわけですよ。
80みたいに自分理論で色々言われてもねぇ。

ttp://www.jstqb.jp/syllabus.html
277 名前：仕様書無しさん mailto:sage [2008/07/10(木) 23:31:11 ]: あら…
一つのモジュールがちゃんと動くかどうか…みたいなテストを
モジュールテストとかMTとか呼んでるんだけど一般的じゃないのかｗ

テストの種類は基本情報の勉強で覚えたくらいだな。
ユニットテストとか現場でのレベル感で縛られるな。
278 名前：80 mailto:sage [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 名前：仕様書無しさん mailto:sage [2008/07/11(金) 00:14:23 ]: >>278
１．同じでないと困る。

２．テスト結果による。

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

修正する度に、部分的にUT→IT→が間に幾つも入るのさ。
280 名前：仕様書無しさん mailto:sage [2008/07/11(金) 00:15:46 ]: 場合によっちゃSTまでを反復で何度も行う事だってあるしな。
281 名前：80 mailto:sage [2008/07/11(金) 00:23:30 ]: つまり、仕様や性能を満たせているかを確認するテスト（ST）が
ずいぶん後回しになるやり方を皆は支持しているわけだ。

そもそも、仕様書は、システム全体に対してのみ書かれるのか？
282 名前：仕様書無しさん mailto:sage [2008/07/11(金) 00:29:52 ]: >>281
皆っておい、俺一人しか答えてねえよwww

279も280も俺、俺俺www
283 名前：仕様書無しさん mailto:sage [2008/07/11(金) 00:31:51 ]: >>282
いや、オレオレwww
284 名前：仕様書無しさん mailto:sage [2008/07/11(金) 00:34:56 ]: >>278
工程として考えたいのか、テスト手順と考えたいのかがよくわからない。
工程なら大規模小規模かかわらずUT＞IT＞STとなるべきだが、
実際に行われてるテストはいくらでも入り組むだろう。
バグ対応入った時とか。

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

すごく今更なんだが、>>80の
> 分割すると管理コストが増えるし組織が複雑になる。
> そして、意思疎通が難しくなる。
> 問題が形を変えるだけで何も解決したことにはならない。
なんというか…オブジェクト指向じゃない感じみたいな…
モジュール一つで表示から処理から遷移から何から何までって感じがする…
285 名前：仕様書無しさん mailto:sage [2008/07/11(金) 00:40:03 ]: >>80の言っている>>258には同意できる。

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

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

コスト的に許されるんなら、全てにホワイトボックステストを用意するに
越した事は無いんだけど。
286 名前：仕様書無しさん mailto:sage [2008/07/11(金) 00:48:20 ]: >>258はよくわからなかったけど>>285には納得できる。

> => ホワイトボックステストはコスト的に合わないので、モジュールの
> 入出力に相当するAPIだけをブラックボックステスト。
コスト的にかどうか知らないんだけど、これが一番理想とするテストだと思ってる。
APIの所だけホワイトな、穴あきブラックボックステストみたいな。
287 名前：仕様書無しさん mailto:sage [2008/07/11(金) 01:03:04 ]: >>278
スパイラル型でもない限り結合超えてUTに戻る、ってのはないんじゃないの？
上位テストフェーズで不具合が見つかった瞬間はともかく

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

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

あ、
１．よくない。お客様との要件詰めが完全合致していて、仕様変更などが絶対入らない
　　前提でもない限りUT->IT->STのみではうまくいかない。
　　なぜなら、UT後に仕様変更なぞ入ろうものなら品質面での保証がまったく出来なくなってしまう、
　　客は触って初めて「違うぞこれ？」とか言い出す生き物、などなど。
２．同じことの繰り返し、と考えてしまうと、６．その他、が正解だと思う。
　　自動テストをUT,IT,STのくくりにいれず同時並行すべきかなー、とか。
288 名前：仕様書無しさん mailto:sage [2008/07/11(金) 01:04:19 ]: みんな考え方は現場経験や本人の考え方により違うんだろうけど
こうやってテストフェーズについて色々活発に話せることはよいことだナァ。
289 名前：仕様書無しさん mailto:sage [2008/07/11(金) 01:05:31 ]: >>288
なー。おれはよくわからんから読んでるだけだけどなー。
290 名前：仕様書無しさん mailto:sage [2008/07/11(金) 01:14:59 ]: >>289
実際現場でテストやその後フェーズで苦労しだすと結構分かってくるんじゃない？
ってか品質面で問題でない現場ならそれが一番の幸せだよ｡゜（ﾟ´Д｀ﾟ)゜｡
291 名前：仕様書無しさん mailto:sage [2008/07/11(金) 01:15:27 ]: >>281
仕様書はもちろん個々の機能についても書かれる。
そしてその仕様どおりの入出力を満たしていることの確認もする。
ただし、業務系ではそれをシステムテストとは呼ばない。
個々の機能の入出力を重点的にテストして、それより下位のテストは適当にするっていうのは
いいと思うよ。
本当にただ言葉の定義が違うために言ってることが分かりづらいだけ。
292 名前：仕様書無しさん mailto:sage [2008/07/11(金) 01:20:39 ]: 今回うけた仕事、システム全体の中の1カ所の開発(というかリファクタ)なんだが
自分たちが受けた部分はともかく、他のところはいきなりシステムテストらしい。
ちゃんとモジュールテストされてない・・・

そのせいで、システムテストで
他の会社が作った部分のデバッグをやらされてる。
293 名前：仕様書無しさん mailto:sage [2008/07/11(金) 01:22:10 ]: >>292
そういう段取り／スケジュール考えた奴は軽蔑していいよ
294 名前：仕様書無しさん mailto:sage [2008/07/11(金) 02:33:59 ]: >>290
テスト後フェーズは幾度となく経験してるし、
修正後のテスト堂々巡りも経験してるけど、
大規模開発というものを経験したことがないので、
UT→IT→ST が同時進行ならまだしも、何度も巡る
というのが理解できず、議論についていけないｗ

というかあれだな、読んでいて思ったけど、
言葉の定義や論点がずれているだけで、
本質はみんな同じ認識の様な気がする。
295 名前：仕様書無しさん mailto:sage [2008/07/11(金) 06:03:21 ]: >言葉の定義や論点がずれているだけで、
>本質はみんな同じ認識の様な気がする。

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

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

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

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

機能テストのことをずいぶん気にしているようだが、「皆」がどう取り組んでいるかは、
「受け入れテスト自動化」でググってみるとわかるかもね。
296 名前：仕様書無しさん mailto:sage [2008/07/11(金) 06:12:26 ]: 俺が80と違っている（と思っている）点は、
・ユニットテストは軽視してはならない。むしろ重視すべき。
・ユニットテストはプログラマが行うべき
・ユニットテストを重視することは、顧客のメリットになる
・（おまけ）外部設計と内部設計という考え方はある

80に同意する点もいくつもあるが、それは列挙しない。
297 名前：仕様書無しさん [2008/07/11(金) 19:44:58 ]: 適当でいいんだよ適当で。
298 名前：仕様書無しさん mailto:sage [2008/07/12(土) 02:15:00 ]: 適当、よりも、適度、がいいと思うんだ
299 名前：仕様書無しさん mailto:sage [2008/07/12(土) 15:17:35 ]: 適当≠手抜き
300 名前：仕様書無しさん mailto:sage [2008/07/12(土) 19:29:48 ]: サンビャク！
301 名前：80 mailto:sage [2008/07/13(日) 08:07:03 ]: >>296
>・ユニットテストは軽視してはならない。むしろ重視すべき。
->軽視はしていない。重視もしていない。
　おれは、テスターじゃなくて、プログラマー上がりなので、
ユニットテストの大切さを知っている。ただ、組織としてユニットテストを
　成功させる場合は、以下の前提条件を満たせないとだめだ。
1. バグが減ったことを評価して、ボーナス査定をUPさせる。
　2. 機能実装よりバグが少ないことを重視する。
重要なのは、2 だ。ユニットテストを重視した結果開発のスピードが
　落ちたのだ。つまり、機能的要件（フレームワーク、下位コンポーネント
　を除く）を実装するチームに関しては、ユニットテストがボトルネックになる。
　よーは、すべてがトレードオフなのだ。ユニットテストを重視しすぎると
　逆に効率が落ちる開発フェーズがあることを俺は、経験で学んだ。
　
>・ユニットテストはプログラマが行うべき
-> ユニットテスト＝ホワイトボックステストなら同意。

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

>・（おまけ）外部設計と内部設計という考え方はある
-> うちの会社にも昔はあったよ。外部設計、内部設計という言葉が
間違っているのに気がついた。
　　確かに、システムというものを対象にした時にそれの外部について
記述したドキュメントと内部について記述したドキュメントはある。
ただ、外部か内部かという言葉は、対象物を前提としている。
システム、サブシステム、コンポーネント、ライブラリ・・・・などだ。
そして、これらは、整然と関連付けられる。内部設計とか外部設計という
言葉をこれに当てはめると間違いである事が理解できる。
外部は仕様書で、内部は設計書なんだ。これでもわからないなら。
　　仕様書と設計書の違いを説明してくれないか
302 名前：80 mailto:sage [2008/07/13(日) 08:17:57 ]: 補足だが、プログラマーとテスターの作業量を新規開発の初めから
終わりまで時間を追ってグラフにしてみると俺の言っていることが
分かるかもしれない。
理想を言えば、一番初めのインテグレートの時にテスターが
チームに参加すれば、コスト的にOKなのだが。
大抵は
1. 一番初めのインテグレートは遅れる。つまりテスターが遊ぶ。
2. テスターが開発初期から参加している場合、テスターは
プログラマーよりも暇である。
3. 機能要件は、よく変わる。せっかくユニットテストをばっちりしても
作り直しが多数発生する。さっさと、要求者に「うごく」ソフトを
見せるのは重要だ。

テスターを遊ばせないで、機能要件の間違いを早期に発見できる方法
を俺は支持しているんだ。
303 名前：80 mailto:sage [2008/07/13(日) 08:29:15 ]: >>285
だいたい、同じ考えだ。
機能要件と再利用可能なコンポーネントでは、テストのやり方
を変えないとだめだ。

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

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

再利用可能コンポーネントは、最適化を繰り返すので、ソースコードが激変する。
つまり、ホワイトボックステストは毎回変わってしまう。
ホワイトボックステスト事態の品質を維持することは非常に難しい、
なので、回帰テストとの合わせ技が重要になる。
304 名前：80 mailto:sage [2008/07/13(日) 09:11:20 ]: 開発工程の中のボトルネックはどこにあるのか？によってやり方は異なる。
プログラマーのスキルが高い場合、テスターのスキルが高い場合など
状況は様々だ。

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

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

ユニットテストを完璧にやるという事は、ウォーターフォールの考え方
に近い。うちは、繰り返し型の開発をやっているので、たとえバグが残っても
開発の最後の方でプログラマーの手が空いてきたころに網羅性の高いテストを
行うので実質品質が下がるようなことはない。
ユニットテストは有効だが、使い方を間違ってはいけないと思う。
重要なのは、部分最適化（ユニットテストだけを協調する）のではなく
全体最適化（全ての開発工程を見直す）の方だと思う。
305 名前：80 mailto:sage [2008/07/13(日) 09:30:44 ]: >>291
業務系は、書籍などで知っているだけで現場は知らない。

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

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

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

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

うちでは以下のように定義している。
・（粒度はともかく）機能的要件を実現する単位をシステム
　（サブシステム）と呼んでいる
・下位の原始的なメカニズムを提供するものを、ユニットと呼んでいる。
・機能外要求や、システムのアーキテクチャーをつかさどるものを
フレームワークと呼んでいる。
306 名前：仕様書無しさん mailto:sage [2008/07/13(日) 11:05:04 ]: >>301
>ユニットテストを重視した結果開発のスピードが落ちたのだ

結局ユニットテスト非重視と重視で品質面はどちらがあがったの？
非重視で品質落ち（最悪客先リリース後に不具合多々発現）だとしたら
開発スピードが落ちた、ではなく必要フェーズをはぶいてスピードあげてた、
ってだけでは？？
307 名前：仕様書無しさん mailto:sage [2008/07/13(日) 11:10:26 ]: みんなの会社で「専任テスター」っている？うちは

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

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

いい形とは思ってないけど、この場合、
フェーズによって「テスター」が暇になる、ってのはないけどなー
308 名前：仕様書無しさん mailto:sage [2008/07/13(日) 12:54:44 ]: 80の方法だと、ユニットが細かい区分になるので、つまり単純化される。
つまり単純で小さなテストが沢山できる。

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

まあ、制御系で1000万コードってどんだけーって話だけど。
工場の制御丸ごとやったとしか思えんなぁ。
309 名前：仕様書無しさん mailto:sage [2008/07/13(日) 18:02:22 ]: グローバル変数が100万個位あるんだろ
310 名前：80 mailto:sage [2008/07/13(日) 20:32:06 ]: >>306
品質は向上した。第三者テストの重要性を再認識することとなった。
多分、問題点や間違いを早期のうちに把握できたことと、プロジェクト管理
がやりやすくなったことなども良かったと思う。

プログラマーに、プレッシャーを与えることになったのと、
テスターの地位が向上したのも良かったのかもしれない。
311 名前：80 mailto:sage [2008/07/13(日) 20:40:06 ]: >>307
うちは、専任のテスターがいる。
そして、開発の初めから開発に参加している。
要件定義が終わったら、これをもとにテストを作成しはじめる。
（テスターが要件を事細かに見るので要件は洗練されるというおまけもつく。）
312 名前：仕様書無しさん mailto:sage [2008/07/13(日) 21:11:33 ]: つーか、日本の現場にありがちな曖昧な部分を消したという事が重要だと思う。
グラマーのプライドなんて、邪魔ものだからなー（本人にとってもー）。
313 名前：80 mailto:sage [2008/07/13(日) 23:04:06 ]: >>312
そういう見方もできるな。要件の曖昧さとテスターのカバレッジを
ユニットテストで補えるとプログラマーが考えているなら、
勘違いも甚だしいな。
314 名前：仕様書無しさん mailto:sage [2008/07/13(日) 23:05:54 ]: プログラマの常識は一般人の非常識って事ですね。わかります。
315 名前：仕様書無しさん mailto:sage [2008/07/14(月) 01:12:09 ]: >そういう見方もできるな。要件の曖昧さとテスターのカバレッジを
>ユニットテストで補えるとプログラマーが考えているなら、
>勘違いも甚だしいな。

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

ちなみにそれやらないと、ユニットテストが上がらないっていう
話になって仕様書を押し戻すと作成元の責任になったりする
ので出来ないってのも基本。
316 名前：仕様書無しさん mailto:sage [2008/07/14(月) 06:01:41 ]: >>301
>　よーは、すべてがトレードオフなのだ。ユニットテストを重視しすぎると
>　逆に効率が落ちる開発フェーズがあることを俺は、経験で学んだ。
バグを取り除くのが早ければ早いほど、トータルコストが少なくなるというのには同意してもらえるのかな？
もっと言えば、トータルコストが少なくなるような効果的なユニットテストを模索しなければならない。

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

>-> うちの会社にも昔はあったよ。外部設計、内部設計という言葉が
>間違っているのに気がついた。
>そして、これらは、整然と関連付けられる。内部設計とか外部設計という
>言葉をこれに当てはめると間違いである事が理解できる。
君が間違っていると主張しても、それでも世界は回っているんだよ。
目をふさぐのは簡単だけどね。
317 名前：80 mailto:sage [2008/07/14(月) 06:56:34 ]: >>316
>バグを取り除くのが早ければ早いほど、トータルコストが少なくなるというのには
>同意してもらえるのかな？
当然そうだが、早いというのは、開発のスケジュールの早い段階でという
意味でだ。うちはスパイラルだからできる芸当なんだが、早期の詳細な
テストが徒労に終わることを経験で知っている。
開発の初期で最低限の要件で開発して、さっさとインテグレート
してさっさとシステムテストをやることで早期にテストを行って
要件の問題を修正している。この場合、ユニットテストは簡単にしか
行われない。
318 名前：80 mailto:sage [2008/07/14(月) 07:10:39 ]: >>316
>君が間違っていると主張しても、それでも世界は回っているんだよ。
>目をふさぐのは簡単だけどね。
世界って広いぞ。うちは外資系だからアメリカ、インド、ロシア・・・・
いろんな奴と一緒に仕事しているけど、ソフト開発なんてのは、世界的に
統一されたりしてないぞ。各国各様でばらばらだ。つまり、外部設計と
内部設計という言葉が通用しないのを、実際に経験で知っている。
319 名前：仕様書無しさん mailto:sage [2008/07/15(火) 01:47:04 ]: なんでシステムテストをやると
ユニットテストをサボれると思うのだろう？
320 名前：仕様書無しさん mailto:sage [2008/07/15(火) 08:56:28 ]: >>317
> 意味でだ。うちはスパイラルだからできる芸当なんだが、早期の詳細な
> テストが徒労に終わることを経験で知っている。

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

>>318
どんだけ田舎者と仕事してんだよ。
internal designとexternal designも通じない奴と仕事してんのかよ。
321 名前：仕様書無しさん mailto:sage [2008/07/15(火) 08:58:53 ]: そろそろメトリックスベースで話さないと埒があかんな。
1000万行のシステムで、第三者検証チームが検出したバグは何件だったんだ？
322 名前：仕様書無しさん mailto:sage [2008/07/15(火) 09:26:09 ]: >>318
とりあえず、原著で読んだsoftware development processの本の題名を列挙してくれ。
323 名前：80 mailto:sage [2008/07/15(火) 23:50:38 ]: >>320
シリコンバレーは、確かに田舎だな。。。。

ちなみに言うとうちでは設計書はあまりかかれない。仕様書を重視する。
うちの外人さんは、「設計書＝ソースコード」だと言い張る。
年収3000万を超えるプログラマーだからできる芸当なのかもしれない。
こいつらテストはしない。テストは、テスターの仕事だと言い張る。
324 名前：仕様書無しさん mailto:sage [2008/07/16(水) 00:20:17 ]: ダメだ、はったりにしか見えない｡゜（ﾟ´Д｀ﾟ)゜｡おれもうROMるわ
325 名前：仕様書無しさん mailto:sage [2008/07/16(水) 01:51:18 ]: 「顧客のメリットになる」ことにこだわっている人が
いるけど、それが必ずしも自社にとってメリットになる
わけでは無いわけで。そういった意味で顧客との間で
落とし所をさぐる時にユニットテストを一部省くというのは
普通にあると思うけど？

やった作業に対して全て金を払ってくれる契約
（それって派遣？）なら全ソースに対してユニット
テストするのもありかもね。
326 名前：仕様書無しさん [2008/07/16(水) 16:08:56 ]: 経験上の話だが、（良い）詳細設計というものは考えていても作れない。

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

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

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

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

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

最初に仕様があるが、これはすごくあいまいなもの。
システムを作るうえでの大前提だが、コレを決めてもシステムは作れない。
個々の目標が、ユニットテスト。これがシステムを作るうえで一番重要なもの。
これがあれば、設計やコードを柔軟に変更することができるし、間違っていない証明になる。
そして、ユニットテストを作ってから、設計とコーディングを行いながら開発していく。
（実際にキー操作をしないと、考えたルートが通れるのか本当に早いかはわからないね）
327 名前：仕様書無しさん mailto:sage [2008/07/16(水) 16:20:33 ]: >>325
あなたが言っているのは、ユニットテストに限った話じゃないね。

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

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

> やった作業に対して全て金を払ってくれる契約
これは、全部のテストの作業量を見積もって、その金額で契約するわけだから、
全部テストするのが当たり前だと思うんだけど？(客が80%で良いとか言うのなら別）
328 名前：仕様書無しさん [2008/07/16(水) 16:37:47 ]: >>1
おれの作ったプログラムにはバグがない。
だからテストは不要。

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

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

バグは意思の疎通が十分にできていれば
ほとんどでることはない。
バグのでる仕事というのは、だいたい意志の疎通がとれていない
ということ。
329 名前：仕様書無しさん mailto:sage [2008/07/16(水) 16:45:46 ]: 俺も1万行に一回くらいしかコンパイルしないけど
ほとんどバグないな
330 名前：仕様書無しさん mailto:sage [2008/07/16(水) 17:08:08 ]: 何この全力で釣られるスレは・・・
331 名前：仕様書無しさん mailto:sage [2008/07/16(水) 19:24:52 ]: >>327
>これは、全部のテストの作業量を見積もって、その金額で契約するわけだから、
>全部テストするのが当たり前だと思うんだけど？(客が80%で良いとか言うのなら別）
100%見積もれて、客が１つも仕様変更をしない場合の話だよね。それって。
そこら辺は開発スタイルの問題かと。俺が言いたいのは「仕様変更のリスクを設計や
計画に含めた形で客に説明しているし、客にもある程度納得してもらってる」
という事。

そういった意味でテストの手法や粒度をどうしましょうか？という事を>>80は言い
たいんじゃないの？
332 名前：仕様書無しさん mailto:sage [2008/07/16(水) 19:37:34 ]: >>331
でも、最初っから変更出来るって頭を顧客に植え付けちゃうのもどうかと思う。
費用込みなんだから一度くらいは変更できるよね？　とか言われないか？
333 名前：仕様書無しさん mailto:sage [2008/07/16(水) 19:59:42 ]: >>332
プロジェクトがある程度続いている or 続く事が期待できる
相手であればそれもありかと。いずれにしても開発・契約
スタイルによるわな。
334 名前：仕様書無しさん mailto:sage [2008/07/16(水) 20:01:37 ]: まあ、変更は一切出来ませんとか言っててもどうせ変更させられるんだけどなwww
335 名前：仕様書無しさん mailto:sage [2008/07/16(水) 21:27:23 ]: 普通は1000行あたりバグが5～50個くらいかな。数え方やプロダクトの難易度にもよるが。
1000万行だったら、5万～50万個くらいか。
まぁ、正直、これだけのバグを10人でさばけるのなら大したもんだよ。
336 名前：仕様書無しさん mailto:sage [2008/07/16(水) 23:05:12 ]: >>335
ちょっと待て
最悪20行に一個出るのが普通か?
たとえ200行に一個でもかなり多いだろ
新人レベルがかなり混じってるならともかく･･･
337 名前：仕様書無しさん mailto:sage [2008/07/16(水) 23:25:32 ]: >>336
設計から実装までやれば、延べにしてそのくらいは出るよ。
設計ミスで全面入れ替えの所とか、パフォーマンス出なくてとか、必ず出てくるwww
338 名前：仕様書無しさん mailto:sage [2008/07/16(水) 23:35:42 ]: ここがコーディング界のネ申達がおわす所、バルハラですか（１万ステップに１バグあるかないかを誇るという）？

それにしては冴えない連中が多いのですが・・・
339 名前：仕様書無しさん mailto:sage [2008/07/16(水) 23:37:43 ]: あいつ使えねーからこっちで直しておこーぜ。
いいよ、バグ無しって言っておけよ。
340 名前：仕様書無しさん mailto:sage [2008/07/16(水) 23:39:08 ]: >>329
それはデータ込みの・・・むしろデータのみを扱ったコードですか？
社会保険庁よりは優秀ですねwww
341 名前：仕様書無しさん mailto:sage [2008/07/16(水) 23:42:32 ]: >>340
一般人には想像すらできない天才っているもんなのよ。
天才というか、障害というか。
342 名前：仕様書無しさん mailto:sage [2008/07/16(水) 23:43:54 ]: >>337
設計にしてもキモになる部分ならプロトタイプなりなんなりで
実装可能性やパフォーマンス検討するだろ。
それを実装まで持ち越しているなら設計工程が十分でないだけ。

ひょっとして手戻りが好きなのか？ｗ
343 名前：80 mailto:sage [2008/07/16(水) 23:46:47 ]: >>324
はったりじゃないんだけど・・・。
それに、嘘ついても仕方がないじゃんか。
344 名前：仕様書無しさん mailto:sage [2008/07/16(水) 23:48:32 ]: >>342
やらねえよ。
だって動作環境が半年後じゃないと揃わないとかザラにあるからな。
パソコン上で幾ら理論構築しても、載せて初めて発覚するパフォーマンスなんてのは普通だし。
345 名前：仕様書無しさん mailto:sage [2008/07/16(水) 23:54:42 ]: まあ、何万行書いてもBUGなんて皆無と豪語してる奴は、信じられなくて当然。
そういうコードは結合後に醜い事になってる事が経験的に多いなw
要するに、俺様仕様でBUGゼロってだけだからwww
346 名前：仕様書無しさん mailto:sage [2008/07/17(木) 00:05:34 ]: 入力がパンチカードとかだった時代ならともかく…
347 名前：仕様書無しさん mailto:sage [2008/07/17(木) 00:07:03 ]: どこかの会社の面接を受けて
特技「１万ステップのコーディングでバグが１件です」
って言ったら、さてどうなるか？
348 名前：80 mailto:sage [2008/07/17(木) 00:07:24 ]: >>342
パフォーマンスに関するチューニングを急いではいけない。
これは、鉄則なので、いまさら説明する必要はないだろう。
パフォーマンスのチューニングは、設計ではなくて
測定に基づいて行われるべきである。

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

たいてい、俺様仕様が間違っている時にバグが埋め込まれる。
349 名前：仕様書無しさん mailto:sage [2008/07/17(木) 00:10:11 ]: ///なんか80に正論とか言われると萎える・・・
350 名前：仕様書無しさん mailto:sage [2008/07/17(木) 00:13:46 ]: // 80は極論派だと思う
351 名前：仕様書無しさん mailto:sage [2008/07/17(木) 00:15:48 ]: /うわなんでコンパイルエラー！？
352 名前：仕様書無しさん [2008/07/17(木) 00:38:06 ]: >>1はいいこと書いてるな。
353 名前：仕様書無しさん mailto:sage [2008/07/17(木) 00:49:15 ]: でも、なんか>>1ってチンコ臭そう
354 名前：仕様書無しさん mailto:sage [2008/07/17(木) 00:52:26 ]: /* >>351 コメントとして間違っている！！ */
355 名前：仕様書無しさん mailto:sage [2008/07/17(木) 01:26:10 ]: まて、もしかするとマンコかもしれないじゃないか
356 名前：仕様書無しさん mailto:sage [2008/07/17(木) 01:27:47 ]: >>344
組み込みならモノがないのでやむを得ない面もあるが、
大概は前のチップや代替品を使って見当を付ければいい。

>>348
パフォーマンスを急げと言っているわけではない。
パフォーマンスがどれくらいでそうか当たりを付けて
速度重視にするかフットプリント重視にするかの設計方針に入れろと言っている。
それを設計工程で行わないで後に回すから手戻るんだよ。
357 名前：仕様書無しさん mailto:sage [2008/07/17(木) 02:14:55 ]: パフォーマンスって、チップ次第だし。
パソコンアプリ作ってればそのまま試せるだろうがな。
石のアクセス自体仕様通りじゃない場合だって普通にあるからさw
358 名前：仕様書無しさん mailto:sage [2008/07/17(木) 02:22:35 ]: >>356
設計段階でパフォーマンスのトレードオフ検討出来るってうらやましいな
たいていは、死守要求だったりするからな。
359 名前：仕様書無しさん mailto:sage [2008/07/17(木) 02:47:00 ]: >>358
排反事象なら一方を満たして他方を次善にして、後は交渉術でそ。
全部実現するにはこれこれのコスト(金額、開発期間)がかかりますと言うだけだし。
金払わない以上どこか諦めてね♥
360 名前：仕様書無しさん mailto:sage [2008/07/17(木) 02:50:37 ]: >>359
いや、払うだろ。
正当な追加費用ならなwww
361 名前：仕様書無しさん mailto:sage [2008/07/17(木) 03:09:11 ]: >>360
まともな客ならなぇ。。。
大概はより良く(まぁいい)より安く(切り詰めてんじゃねぇ)。
362 名前：仕様書無しさん mailto:sage [2008/07/18(金) 02:24:12 ]: たしかに>>1はいいこと書いてるな

先日面接で「ｘｘのシステムを作り直すとしたらどのくらい？」って聞かれて
「コアを作り直すなら２人月ぐらいですね、今まで自分らで作っていた部分が今ではライブラリとして提供されているから。
それよりも、テストの方に工数がかかると思いますよ。」って答えた。

でもよく考えたら、ｘｘを作り直す（完成させる）まで、ってのは当然テストが完了して、のことなんだよな。。。

どうも自分の中で実装とテストを別に考えてしまっていたわ・・・ちゃんとしたものを作る、っていう意味では
テストはものづくりの一部だわ、、、今ここで反省します m(^＿^;)m

遠足は家に帰るまでが遠足だかんね。
363 名前：仕様書無しさん [2008/07/18(金) 21:10:41 ]: >>362
ど素人さんですか？
今まで何やってたの？
364 名前：仕様書無しさん mailto:sage [2008/07/19(土) 01:08:59 ]: >>363
>>362はちゃんとテスト工数の話してるしちょっと区切り間違っちゃっただけだろ。
いじわるなんだからっ！
365 名前：仕様書無しさん mailto:sage [2008/07/19(土) 11:20:47 ]: たかだか二人月のゴミみたいなプロジェクトの例を出されましても・・・
366 名前：仕様書無しさん mailto:sage [2008/07/19(土) 13:00:56 ]: ttp://itpro.nikkeibp.co.jp/article/OPINION/20080423/299886/
6000人のSEが同時期に集まったのであって，「6000人月」ではない。
開発工数は先に書いた通り，11万人月である。
このSEパワーは開発だけではなく，テストに惜しみなく使われた。
ざっと5000人が8カ月テストをしたとするとこれだけで4万人月，開発工数の3分の1がテストに費やされた計算になる。

　本来なら有り得ない開発工数とマネジメント工数とテスト工数である。
　本来なら有り得ない開発工数とマネジメント工数とテスト工数である。
　本来なら有り得ない開発工数とマネジメント工数とテスト工数である。
367 名前：80 mailto:sage [2008/07/19(土) 17:11:42 ]: ttp://sankei.jp.msn.com/economy/finance/080512/fnc0805122000013-n1.htm

テスト段階では、全く想定していなかったトラブルが起きた
テスト段階では、全く想定していなかったトラブルが起きた
テスト段階では、全く想定していなかったトラブルが起きた

テストに開発工数の 1/3 を費やしてもシステム障害で行政処分。
部分最適化のもろさを露呈してしまう結果になった。

「全く想定していない」・・・要求定義者や分析・設計者のミスをテストで
カバーできないってこと。間違った仕様を完璧にコーディングしても
それは、バグ。
368 名前：仕様書無しさん mailto:sage [2008/07/19(土) 17:22:10 ]: 6000人全員が派遣でしたwww　って話？？
369 名前：仕様書無しさん mailto:sage [2008/07/19(土) 20:48:04 ]: コーディングは終わったので、あとは人海戦術で手動テストしてくださいって
パターンなら最初からうまくいくはずないよ。
370 名前：仕様書無しさん mailto:sage [2008/07/19(土) 22:14:17 ]: なんか、ぶっちゃけ私の方法ならうまくいくと間接的に言ってるように
見えるけど、ほんとそうなの？
371 名前：仕様書無しさん mailto:sage [2008/07/19(土) 22:22:01 ]: >>369
テストの際に出てくる不具合報告を眺めてるだけじゃ完成しないがなw

テストに入ってからが本当のコーディング作業が始まると思わなきゃ上手く行かない。
372 名前：仕様書無しさん mailto:sage [2008/07/20(日) 02:22:31 ]: >>371
メガプロジェクトじゃ、そんなの通用しないし。
373 名前：仕様書無しさん mailto:sage [2008/07/20(日) 02:34:44 ]: >>372
はあ？
メガプロジェクトじゃ、最後までコーディングしてる部署が必ずあるよ。

つうか、不具合改修はやらねえの？
374 名前：仕様書無しさん [2008/07/20(日) 03:14:48 ]: 普通、やるでしょ
PSPの海腹川背みたいな例もあるけどw
375 名前：仕様書無しさん mailto:sage [2008/07/20(日) 12:12:05 ]: >>371
> テストに入ってからが本当のコーディング作業が始まると思わなきゃ上手く行かない。
だから、無駄なテスト前コーディングをしないで、
テストをやってコーディングをするんだよね。
376 名前：仕様書無しさん mailto:sage [2008/07/20(日) 12:16:01 ]: >>367
> 「全く想定していない」・・・要求定義者や分析・設計者のミスをテストで
> カバーできないってこと。間違った仕様を完璧にコーディングしても
> それは、バグ。

ですよね。だからちゃんと想定して、
その想定した内容をテストとして書くんですよね。

これであなたもユニットテストの重要性を理解したと思います。
377 名前：仕様書無しさん mailto:sage [2008/07/20(日) 12:20:56 ]: ついにマ板にも夏が来たか・・・
378 名前：仕様書無しさん mailto:sage [2008/07/20(日) 14:21:36 ]: >>376
ユニットテストじゃ、要求定義や設計時のミスは取り除けないよ。

それを元にテストが作られるんだからね。

だいたい、設計時の矛盾は最終的な総合テストまで残る。
要求定義の矛盾は製品にまで残る。
379 名前：仕様書無しさん mailto:sage [2008/07/20(日) 15:00:32 ]: >>373
「本当のコーディング作業」の定義次第だな。
そして、その定義を云々するのはくだらねー。
380 名前：仕様書無しさん mailto:sage [2008/07/20(日) 17:13:26 ]: 80の言い分だけど、

うちの会社は1000万のコードで、

次に、基本証券・金融系では無い。制御系だといって、

最後に、国内最大の金融系の仕様段階での問題点を出している。

あ、あとシリコンバレーと仕事しているってのもあったな。

で、別に仕事のやり方は全否定する要素は無いが、具体例は
全否定されても仕方ないほど妄想力に満ちていると感じたの漏れだけ？
381 名前：仕様書無しさん mailto:sage [2008/07/20(日) 19:23:59 ]: >>374
あれは、「仕様です」
382 名前：仕様書無しさん [2008/07/23(水) 01:01:35 ]: とりあえずユニットテストやファンンクショナルテストをちゃんと書いていけば
設計時の矛盾とか普通にたくさんでてくるよ。
んで、短いサイクルでどんどんリファクタしていけばいい。
もちろん手動テストもするけど、ばかげた規模での人海戦術テストとかにはならないでしょ。
383 名前：仕様書無しさん [2008/07/23(水) 01:06:30 ]: またまた富士通！東証システム障害　プログラムミスが原因　2008/7/22
headlines.yahoo.co.jp/hl?a=20080722-00000027-maip-brf

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 名前：仕様書無しさん [2008/07/23(水) 01:06:41 ]: 　【東証のシステム障害、設定ミスをテストでも見抜けず　2008/07/22　】
　　鈴木CIOは「設定をミスしたのはベンダーの富士通」とした上で、「多数の銘柄に対し板情報の
　　問い合わせがあった場合をテストケースに含んでいなかったのは我々の責任。もっと幅広く
　　テストすべきだった」と陳謝した。
　　　itpro.nikkeibp.co.jp/article/NEWS/20080722/311271/

　【富士通の開発ミスの全責任は東証にある」とみずほ証券、株誤発注裁判　2008/05/09　】
　　2005年12月にみずほ証券がジェイコム株の誤発注で出した損失を巡って東京証券取引所を
　　訴えた裁判の第9回口頭弁論が2008年5月9日、東京地方裁判所で開かれた。
　　原告のみずほ証券側は、被告の東京証券取引所にシステムの発注者としての注意義務違反と
　　重過失があったことを改めて主張する準備書面を地裁に提出した。
　　みずほ証券側は「東証はシステムの発注者として、業務上の要求を富士通に伝え、富士通が
　　開発したプログラムが要求と整合しているかをテストする責任がある」と訴え、「誤発注の
　　取り消しができなかったのは東証の重過失だ」と主張した。
　　　　　：
　　次回口頭弁論は2008年7月25日の予定だ。
　　　　　　　　　　　　~~~~~~~~~~~~~~~~~~~~~~~~~~　　
　　　itpro.nikkeibp.co.jp/article/NEWS/20080509/301077/

　【「短期間で2回のシステム障害は、痛恨の極み」東証社長が会見 2008/03/25　】　
　　証は2月8日の金融派生商品の取り引きを担う新派生売買システムの障害に続き、3月10日にも
　　株式売買システムで障害を起こした。
　　先月22日に新派生売買システムを中心とした障害の再発防止策を発表したばかりだが・・・
　　　itpro.nikkeibp.co.jp/article/NEWS/20080325/297067/

　【特集・東証システム問題リンク】
　　　itpro.nikkeibp.co.jp/99/tousyou/index.html
385 名前：仕様書無しさん mailto:sage [2008/07/25(金) 03:00:06 ]: ユニットテストは詳細設計どおりにプログラムが稼働するテストと認識しているんだが、
詳細設計が１ＳＴＥＰ対応の設計書でない場合、全パステストの結果って
どういう扱いになるのかな？
386 名前：仕様書無しさん mailto:sage [2008/07/26(土) 01:44:42 ]: >詳細設計
の確認はうちではユニット-ユニットの結合テストだな

ユニットテスト対象はプログラム設計
ここ→ttp://msugai.fc2web.com/pgm/test.html
のV字モデルに近い

なので全パステストなんて結合テストで考えない
387 名前：386 mailto:sage [2008/07/26(土) 01:57:35 ]: ttp://itpro.nikkeibp.co.jp/article/COLUMN/20051102/223934/
の図1もプログラム設計が書いてないけど同じっぽい
388 名前：仕様書無しさん mailto:sage [2008/07/28(月) 11:42:25 ]: 今日初めて見たが、みんな何か勘違いしてないか？
テストで信頼性は上げられない、テストは
「このプログラムにはバグがあるます」を実証するもので
バグを沢山検出したからと言って、そのプログラムには
もうバグが存在しないと言う実証にはならない。
実際は逆で、統計的に見るとバグ密度の多いプログラムほど
残りの潜在バグが多く含まれている。

テストでは信頼性は旦保できない為、極度に
信頼性が求められるシステムでは、テストをしない開発手法もある。
389 名前：仕様書無しさん mailto:sage [2008/07/28(月) 15:31:02 ]: >>388
asshole
390 名前：仕様書無しさん [2008/07/28(月) 18:11:43 ]: >>388
＞信頼性が求められるシステムでは、テストをしない開発手法もある。
kwsk
391 名前：仕様書無しさん mailto:sage [2008/07/28(月) 18:23:16 ]: 耐震偽装と同じレベルだろwww
392 名前：388 mailto:sage [2008/07/29(火) 00:35:28 ]: >>390
有名な所では、ダーリントン原子力発電所の緊急炉停止システム
393 名前：仕様書無しさん mailto:sage [2008/07/29(火) 00:43:53 ]: >>388
ソフトウェアの信頼性を定義してみな
394 名前：仕様書無しさん mailto:sage [2008/07/29(火) 02:52:18 ]: IEC読んで言ってるなら凄いけどね・・・
395 名前：388 mailto:sage [2008/07/29(火) 21:00:07 ]: >>393,394
俺をテストしてどうする。しかし、なぜムキになるか分からん？
ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%86%E3%82%B9%E3%83%88
>ソフトウェアテストでは、欠陥が存在することを示すことはできるが、欠陥が存在しないことは証明できない。
Wikipediaにもにも書いてあるし、大半の「テスト」関連の書籍にも同じような意味の事が書かれている
いままで、その辺りの知識もなしにレスを書いていたのか？
396 名前：仕様書無しさん mailto:sage [2008/07/29(火) 21:28:57 ]: >>395
それは394への答えにはならないよ。
397 名前：仕様書無しさん mailto:sage [2008/07/29(火) 21:32:30 ]: >>395
だから、普通テストは
要求された機能が特定の条件下で要求通りの結果を示せるかをテストするんだぜ？
要求されてない（テストされてない）機能がどのように振る舞おうが知ったこっちゃ無いのはあたりまえ。

だからその理論は正しいが、そんな事は誰も要求していないんだよ。
想定外の欠陥は許されるが、想定内の欠陥はダメなの。
398 名前：仕様書無しさん mailto:sage [2008/07/30(水) 00:31:54 ]: >>397
＞想定外の欠陥は許されるが、想定内の欠陥はダメなの。

現実は想定外の欠陥でも許さない人間が大半だがな。　相乗りしている他システムが
異様にリソース使いまくって、それに巻き込まれて不具合起きて、それでも不具合が
おきない様にしろと言われかけたときは頭抱えたよ、、、
399 名前：仕様書無しさん mailto:sage [2008/07/30(水) 00:34:35 ]: >>398
もちろん納品前に発覚した不具合は想定内だよ。
400 名前：仕様書無しさん mailto:sage [2008/07/30(水) 00:36:13 ]: 予想GUYダ！
401 名前：仕様書無しさん mailto:sage [2008/07/30(水) 00:52:25 ]: よそう、GAYﾀﾞ!
402 名前：仕様書無しさん mailto:sage [2008/07/30(水) 02:14:08 ]: >>399
納品後ですが、何か？
しかも納品後すぐとかじゃなくて、数ヶ月たってとかだったり、他の納品先だと
そんなこと起きなかったりとかで調査だけでも結構かかりましたが。
403 名前：仕様書無しさん mailto:sage [2008/07/30(水) 02:16:01 ]: >>402
受け入れ検査終了後なら別料金もらってんだろ。
いいじゃん仕事あって。
404 名前：仕様書無しさん [2008/07/30(水) 18:45:40 ]: >>388
＞信頼性が求められるシステムでは、テストをしない開発手法もある。
ネタにしてはよく出来てる手口。
405 名前：仕様書無しさん mailto:sage [2008/07/30(水) 21:15:43 ]: >>395
で、信頼性はどう定義するんだ？
406 名前：388 mailto:sage [2008/07/30(水) 23:03:31 ]: >>397
限られた前提条件・限られた入力値・限られた入力値組み合わせでテストをして
その機能が、全て正しく動くと思ってる？　テストが何たる物か分かっていない証拠だな

>>404
自分の知識で分からないものはネタか！やっぱりこんな奴がいるんだ
例を出したんだから、調べれば分かると思うが。

>>405
俺に聞いても、プログラムの信頼性は上がらんだろう、自分で考えないと。
407 名前：仕様書無しさん mailto:sage [2008/07/30(水) 23:07:51 ]: >>406
誰も信頼性の上がる方法なんて聞いてない。
信頼性の定義を聞いているのがわからないのか？
408 名前：仕様書無しさん mailto:sage [2008/07/30(水) 23:09:50 ]: >>406
お前もちゃんと調べてから例出しな
409 名前：仕様書無しさん mailto:sage [2008/07/30(水) 23:10:08 ]: >>406
全て動くなんて言ってないが。
ファビョるのもたいがいにしろよ。
410 名前：388 mailto:sage [2008/07/30(水) 23:19:22 ]: >>407
>信頼性の定義を聞いているのがわからないのか？
分かって書いているんだが、分からないのか？

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

>>409
>全て動くなんて言ってないが。
だから、テストでは信頼性は確保出来
411 名前：仕様書無しさん mailto:sage [2008/07/30(水) 23:20:59 ]: >>信頼性の定義を聞いているのがわからないのか？
>分かって書いているんだが、分からないのか？

どこに書いたんだ？
412 名前：仕様書無しさん mailto:sage [2008/07/30(水) 23:21:48 ]: 駄目だこいつ。
413 名前：仕様書無しさん [2008/07/30(水) 23:22:33 ]: テストの前にソースの読み直しをお願いします
先輩
414 名前：仕様書無しさん mailto:sage [2008/07/30(水) 23:23:52 ]: 単純リプレースとか言って営業がとってくる仕事ほど
前の機能をちゃんと満たしてるか（正しく動作するか？）って意味で
テストが重要、

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

だってさ

まぁ、うまくいけばいいんだけどね。。。その時期夏休みとって携帯電源切っとこう
415 名前：仕様書無しさん mailto:sage [2008/07/30(水) 23:23:58 ]: 原子力発電所のソフトウェア開発について議論するスレじゃないよ
416 名前：仕様書無しさん mailto:sage [2008/07/30(水) 23:24:26 ]: >>410
394にまともに答えられない人に教えてもらう事無いと思うよｗ
417 名前：仕様書無しさん mailto:sage [2008/07/30(水) 23:25:44 ]: 何手法だか知らないが、その手法でぬるいメガプロジェクトでも回してみればいいさ。
418 名前：仕様書無しさん mailto:sage [2008/07/30(水) 23:40:28 ]: KKDは勘と経験と度胸による見積もり法です
419 名前：仕様書無しさん mailto:sage [2008/07/30(水) 23:40:45 ]: それ
なんて
みずぽ？
420 名前：388 mailto:sage [2008/07/31(木) 00:05:03 ]: >>411
>>どこに書いたんだ？
信頼性の定義は書いていない

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

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

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

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

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

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

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

>>419
???
421 名前：仕様書無しさん mailto:sage [2008/07/31(木) 00:10:24 ]: >>420
聖徳太子現る

明日は合コンだってさ、木曜だしなーーー
女の子たちの接客上手をテストしてやるぜ～
422 名前：仕様書無しさん mailto:sage [2008/07/31(木) 13:06:27 ]: >>420 からおじゃば臭がするのは気のせいか？
423 名前：仕様書無しさん mailto:sage [2008/07/31(木) 19:21:50 ]: 気のせいじゃなくね
424 名前：仕様書無しさん mailto:sage [2008/07/31(木) 20:04:06 ]: >>421
どこのキャバでやんの？
425 名前：仕様書無しさん mailto:sage [2008/07/31(木) 20:39:41 ]: >>420
おじゃばとしては、どういうテスト手法を理想としてんの？
426 名前：仕様書無しさん mailto:sage [2008/07/31(木) 20:43:06 ]: >>422
いや、ハカセじゃないのかシステム工学を語りたいんだろう
でもハカセはアホだから違うかｗ
427 名前：仕様書無しさん mailto:sage [2008/07/31(木) 20:48:28 ]: >>425
教えてやろう君にはすばらしい餌だなｗ
428 名前：仕様書無しさん mailto:sage [2008/07/31(木) 20:52:52 ]: >>426
お前、おじゃばだろ
429 名前：仕様書無しさん mailto:sage [2008/07/31(木) 22:14:57 ]: >>424
キャバじゃないし、今日でもなかった・・・

だれかおれの視力、聴力、記憶力をテストしてくれ
430 名前：仕様書無しさん mailto:sage [2008/07/31(木) 22:18:40 ]: >>429
つ　homepage3.nifty.com/funahashi/game/game693.html
431 名前：仕様書無しさん mailto:sage [2008/08/01(金) 03:03:06 ]: テストしてほしけりゃ金よこせ
432 名前：仕様書無しさん mailto:sage [2008/08/01(金) 03:36:48 ]: まともにテストできるか能力を示せ。
433 名前：388 mailto:sage [2008/08/02(土) 15:13:28 ]: テストは限られたリソースの中で、いかに効率良く不具合を見つけるかが重要
例えば、同じプログラムをテストして
　「Aは１０件のテストケースで５件のバグが見つけた」
　「Bは１００件のテストケースで１０件のバグが見つけた」
では、Bの方がAより残りのバグも少ないので信頼性のあるプログラムになるが
テストとしては、半分の確率でバグを見つけたAの方が、「良いテスト」と言える

つまり、テストは効率性が重要で、プログラムの信頼性は考えない
（バグを多く見つけるかでは無く、「"効率的"」にバグを多く見つけるかが重要)
同値テストや限界値テストなどのテストテクニックも、バグを効率に見つける為に考え出されたもの
434 名前：仕様書無しさん mailto:sage [2008/08/02(土) 16:18:18 ]: なるほどね。
おじゃばという人物は、コミュニケートする気はないわけだ。
相手とちゃんとやりとりしたい訳じゃない。

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

使いようによっては、存在に意味を持たせる事は可能かもしれないけど、
人間的にはゴミだなぁ。ｗ
435 名前：仕様書無しさん mailto:sage [2008/08/02(土) 16:23:25 ]: Aの方が効率悪いじゃん？
なんでBは100件もこなせてるのに
Ａは10件しかこなせなかったんだ？
リソース一緒なのに。
436 名前：仕様書無しさん mailto:sage [2008/08/02(土) 16:44:08 ]: >>388
節子、それ、テストやない。デバッグや。
437 名前：仕様書無しさん mailto:sage [2008/08/02(土) 19:52:15 ]: >>435
１０件辺り５件も不具合出りゃあ、テスト中止だろwww
５０％なんてどんだけボロボロなんだよwww
438 名前：80 mailto:sage [2008/08/03(日) 00:48:44 ]: >>437
>>435 の例は、
・同じプログラムなら網羅できたとしてテストケースの数は同じになる。
・テストケース数＝1000件
・実際の不具合の数＝20件

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

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

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

さらに、テストケースの粒度や内容をコントロールすれば効率はさらに
上がると思う。
439 名前：80 mailto:sage [2008/08/03(日) 01:17:35 ]: 屁理屈といわれそうだが、言葉の定義だけで言うなら
「信頼性＝故障しにくい事」

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

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

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

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

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

蛇足だが、
あるボタンを連打すると発生する不具合をテスト自動化で見つけたが
人間業では決して発生させることができない不具合だったので修正を
見送った経験がある。
440 名前：仕様書無しさん mailto:sage [2008/08/03(日) 01:21:11 ]: >>435じゃなくて>>433な。
441 名前：仕様書無しさん mailto:sage [2008/08/03(日) 01:25:14 ]: >>438
そんな机上論、幾ら並べても無意味。
何故って？

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

その「実際の不具合の数」自体が空論
テスト方法変えて出てくるのは、異なる不具合であり、全容の一部が見えたわけではない。
442 名前：80 mailto:sage [2008/08/03(日) 01:36:54 ]: >>440
訂正サンキュー。

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

要求に無い機能（設計の段階で暗に入り込んだ機能）は、テストから漏れる
事が多いと思う。で、うちでは、繰り返し型なので、この手の潜在的な機能は、
（気付けば）要求としてとらえることにしている。
443 名前：80 mailto:sage [2008/08/03(日) 01:53:57 ]: >>441
「ソフトウェアの信頼性ほど信頼性の低いものはない」と俺も思う。
不具合密度がどーとか経営陣や顧客に嘘くさい説明はできても自分自身は
納得していない。なので、実際には、統計的な手法からは距離を置いている。

持論で申し訳ないが、俺は、
「ソフトウェアの信頼性＝クレーム処理にかかった費用の少なさ」
と考えている。
極論すると
・ユーザが発見できない不具合は不具合とはみなさない。
（無実ではないが無罪。飲酒運転も逮捕されなければOK的な・・・）
・要求にない機能は、一切入り込まないようにする。
てな感じかな。
444 名前：仕様書無しさん mailto:sage [2008/08/03(日) 02:21:12 ]: >>443
そういうプログラム引き継がされて爆弾爆発させたら
爆弾仕込んだヤツは無罪で爆発させたヤツが
全部罪をかぶることになる

この図式はなんとかならないかなあ
445 名前：仕様書無しさん mailto:sage [2008/08/03(日) 02:24:47 ]: まあ、完全にBUGを潰す作業をいつまでも行っていたら、永久に製品が出せないからね。

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

もしBUGが一切無いプログラムがあったとしたら、それは検査方法が間違っているかテスト結果にねつ造があるかのどちらかさ。
446 名前：80 mailto:sage [2008/08/03(日) 02:45:56 ]: 以前にも書いたけど、テストだけを頑張るだけではだめだと思う。
部分最適化じゃなくて全体最適化ね。

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

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

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

100%絶対に異常終了しない設計にするとテストが大変（証明できない）ので
設計で対策をこうじた。画面はあれ？ってな感じになるけどしばらくすると
復帰する。今のところクレームは無い。
447 名前：仕様書無しさん mailto:sage [2008/08/03(日) 10:42:24 ]: >>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ
448 名前：仕様書無しさん mailto:sage [2008/08/03(日) 10:56:30 ]: >>446
死ぬほどよくあるインフラ構成を偉そうに語る辺り働いてないか末端PGでしょ。
しかも、いきなり「非稼働時」とかまともに説明出来てないしｗ
インフラ構成に頼ったシステム安定性なんて無いに等しい
449 名前：仕様書無しさん mailto:sage [2008/08/03(日) 11:04:28 ]: >>436
なるほど。>>388を直してみた。

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

デバッグでは信頼性は旦保できない為、極度に
信頼性が求められるシステムでは、デバッグをしない開発手法もある。
450 名前：仕様書無しさん mailto:sage [2008/08/03(日) 11:45:31 ]: >>449
あ　すげーまともな文章になったww
451 名前：80 mailto:sage [2008/08/03(日) 16:25:33 ]: >>448
インフラじゃないけど・・・。全然、意味通じてないみたい。
俺、文章力自信なくしてきた。
452 名前：80 mailto:sage [2008/08/03(日) 16:51:01 ]: >>448
真面目に読んでくれているみたいだな。
非稼働ってのは変だな。よーは、ユーザーがシステムを使用していない
隙間の時間ということ。

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

デバイス側の不具合により通信系が異常をきたした場合・・・・
ごめん、長文になりそうだから説明止めとく。
453 名前：388 mailto:sage [2008/08/03(日) 18:19:20 ]: >>439
>つまり、苦情の件数が少ないほど信頼性が高いと考えられる。
それは違う「原子力発電所の緊急炉停止システム」みたいな
稼動する事がまれで、稼動での不具合が致命的になるケースもある
苦情の件数など関係なく、信頼性は稼動前から求められている

>>436,449,450
テストとデバッグは別もの
454 名前：448 mailto:sage [2008/08/03(日) 18:41:06 ]: >>452
余計おかしいだろ。

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

>うちは、デバイスがくっついてるからそいつらのせいでシステムが
>落ちたりする。
この1行でもうお腹一杯です・・・
455 名前：仕様書無しさん mailto:sage [2008/08/03(日) 19:18:07 ]: 最近話題の地震速報とかか？
456 名前：仕様書無しさん mailto:sage [2008/08/03(日) 20:03:05 ]: >>453
> テストとデバッグは別もの

正解。よくできました。
お前自分が書いたレスよく読んでみろ。
テストとデバッグの違いの何たるかが解ってない奴の発言だ。
勉強して出直して来い。
457 名前：388 mailto:sage [2008/08/03(日) 22:14:06 ]: >>456
それは間違い、俺が書いたものを理解出来ないだけの話
458 名前：仕様書無しさん mailto:sage [2008/08/03(日) 22:33:42 ]: >>457
だとしたら日本語の書き方を勉強して出直して来い。
459 名前：388 mailto:sage [2008/08/03(日) 23:17:19 ]: >>458
それも違う、そっちが知識が無いから理解出来ないだけの話
システム工学系の話だから、知識がない人とは話が噛み合わない
460 名前：仕様書無しさん mailto:sage [2008/08/03(日) 23:27:23 ]: 理解出来てたら簡潔に説明できる。
理解出来てないから伝わらないと教わった俺はいい先生に出会えてたんだなｗ
461 名前：仕様書無しさん mailto:sage [2008/08/03(日) 23:35:54 ]: なんかいつのまにか80：その他大勢
みたいな流れになってしまったな

おれとしては80みたいな特異な例よりも
ふつーに自分の現場では・・・みたいなノリが好きなんだが・
462 名前：仕様書無しさん mailto:sage [2008/08/04(月) 00:34:05 ]: 自分の話が分かってもらえないなら
まずどうすれば分かってもらうかを考えるべき

分かってもらいたいのであればな。
463 名前：仕様書無しさん mailto:sage [2008/08/04(月) 01:15:35 ]: 「信頼性」の定義が述べられない以上
>>388の話には何の主張も存在していない。
故に誰にも理解できるはずがない。
464 名前：仕様書無しさん [2008/08/04(月) 01:27:15 ]: 『HAYST法』ってなんて読むのか知っている方いますか？？
465 名前：80 mailto:sage [2008/08/04(月) 07:01:35 ]: >>453
繰り返すが、ソフトの信頼性は、苦情の件数ではなくて以下と
俺は、考えている。
「ソフトウェアの信頼性＝クレーム処理にかかった費用の少なさ」

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

対投資効果的に

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

クレーム処理で高くつく機能は、顧客要求にある機能とリスクに関する機能
とかね。
466 名前：80 mailto:sage [2008/08/04(月) 07:04:16 ]: >>454
悪いが、たぶん俺と >>454 はドメインが違いすぎると思う。
「顧客要求≒真の要求」とだけ書いとく。
467 名前：80 mailto:sage [2008/08/04(月) 07:25:53 ]: >>460
横やりで悪いが。
そんなに単純なものじゃないと思うぞ。

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

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

理解にも種類があるんじゃないか？
468 名前：80 mailto:sage [2008/08/04(月) 07:44:33 ]: >>464
俺は、ヘイストと読んでるが・・・。自信はない。
別に否定するつもりはないが、数あるテスト手法の一つだな。
HAYST法は、上流工程がパーフェクトな場合に生きる手法だと思う。
469 名前：仕様書無しさん mailto:sage [2008/08/04(月) 21:23:22 ]: 隔離スレが必要なレベルだな・・・
470 名前：仕様書無しさん mailto:sage [2008/08/04(月) 22:22:55 ]: >>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ

>>338
能書き垂れる前に、ソフトウェアの信頼性を定義しろ
471 名前：仕様書無しさん mailto:sage [2008/08/04(月) 22:29:31 ]: なぁ、なんで>>80は粘着しとんの？

それプログラマやない、評論家気取りの厨房や
472 名前：仕様書無しさん [2008/08/04(月) 22:42:26 ]: >>459-471
お前らみたいに釣られるカモがいるからじゃねーか？
しかも連投だしｗ。ごくろうさん。
473 名前：仕様書無しさん mailto:sage [2008/08/04(月) 23:25:02 ]: >>466
要求分類出来てないよ。
≒にならざるおえない要求とそうでない要求がある。
君が例で出した要求は後者。

コテ酉つけて専スレ立ててもらいなよ。
みんな弄るの飽きたみたいだし、このスレではもう君は不要。
474 名前：仕様書無しさん mailto:sage [2008/08/05(火) 00:46:38 ]: を
475 名前：388 mailto:sage [2008/08/05(火) 07:50:21 ]: >>465
書いている事は分かるが、それは受注企業の論理だ
企業である以上、費用対効果を考えるのは当然だが
絶対の安全が求められるシステムでは通用出来ない
「人が死んでも生命保険に入っているから大丈夫」とは、絶対にならない

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

当事者の論理では、信頼性の根拠にならない
476 名前：仕様書無しさん [2008/08/06(水) 23:03:41 ]: >>475
人が死ぬ不具合は、「クレーム処理費用が高くつきそうな不具合」の
典型だろ。

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

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

プログラム正当性証明をバグを生む開発者がどーせやるんだろ。
「正当性を証明できる」なら「もともとバグはない」というパラドックスに
ハマるのが落ちだと思うがな。
477 名前：仕様書無しさん mailto:sage [2008/08/07(木) 22:07:06 ]: テストは全ルート試験です。
もちろんifやswitchならば全てを網羅。
試験項目数が1000を軽く越えます。
478 名前：仕様書無しさん mailto:sage [2008/08/07(木) 23:52:07 ]: 夏休みだなぁ
479 名前：仕様書無しさん mailto:sage [2008/08/08(金) 20:36:54 ]: 全網羅で「1000を軽く越える」程度なら楽勝だろ
480 名前：仕様書無しさん mailto:sage [2008/08/08(金) 21:07:59 ]: 開発規模・期間に対しては辛すぎる
一日400件消化しろと？
常識的に考えてくれ・・・
481 名前：仕様書無しさん mailto:sage [2008/08/08(金) 21:09:17 ]: そういう情報を後出ししてるようだからダメなんだよ
482 名前：仕様書無しさん mailto:sage [2008/08/08(金) 23:20:20 ]: >>480
そんなん普通だろ
何自分だけ不幸のつもりになってんだよwww
テスト自体の効率のいい作業順番とか考えれ
まさか項目上から順番にやってたりしないよな？
483 名前：仕様書無しさん mailto:sage [2008/08/09(土) 21:19:18 ]: 作業順番を変えても期限は変わらない件
484 名前：仕様書無しさん mailto:sage [2008/08/09(土) 21:32:46 ]: >>80のおじゃば
うざいし
485 名前：仕様書無しさん mailto:sage [2008/08/09(土) 21:43:04 ]: 一日400件なんて新人レベル
486 名前：仕様書無しさん mailto:sage [2008/08/09(土) 21:50:21 ]: アプリのテストを言ってるようだが、
異常系や例外系のテストなんか網羅できんだろ
487 名前：仕様書無しさん mailto:sage [2008/08/09(土) 23:13:48 ]: スレは読んじゃないけどさ。

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

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

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

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

「プログラム正当性の証明」ってのはサッパリ意味不明。
488 名前：仕様書無しさん mailto:sage [2008/08/09(土) 23:54:11 ]: >>486
最近のテストツールは出来が良くて、異常系や例外系のテストなんかもできるらしいね。

ぶっちゃけ、80が言っていたのはプログラムを細切れにして、単純化されたものを
テストツールでガリガリすると言っている。
489 名前：仕様書無しさん mailto:sage [2008/08/10(日) 11:19:43 ]: なんで別人になりすますの？
490 名前：80 [2008/08/10(日) 21:23:12 ]: >>489
いや悪いが、最近、忙しくてレスしてない。

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

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

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

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

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

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

客観的手法や統計で何とかなると本気で考えている奴を否定はしないが
俺はあんまり関心がない。
491 名前：80 mailto:sage [2008/08/10(日) 21:28:23 ]: 統計とか客観的な事実とかを突き詰めるのにすげー金使っても、
結局、プロジェクト内の「過労で疲れた技術者のミスの積み重ね」で
大バグは埋め込まれる。

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

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

テスト自動化による副次的効果の方が、重要なのかもしれん。
492 名前：仕様書無しさん mailto:sage [2008/08/10(日) 21:29:35 ]: 自動化されたテスト環境にもBUGはあるよｗｗｗ
493 名前：80 mailto:sage [2008/08/10(日) 21:32:19 ]: テストを重視して、ただでさえ疲れ切った技術者にさらに仕事を
積む。そーやって、現場をさらに混乱に陥れる。

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

技術者は、常に理屈で何とかなると思っている、何か良い手法があると
考えている。ただ、その手法を実行する人の振る舞いについては関心がない。
494 名前：80 mailto:sage [2008/08/10(日) 21:34:17 ]: >>492
開発者が楽して結果的にバグがあるのと
開発者が死ぬ気でテストしてバグがあるのでは意味が違う。

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

テスト自動化だけをやってるわけじゃない。
495 名前：仕様書無しさん mailto:sage [2008/08/10(日) 21:35:21 ]: テスト環境をテストするのに同じだけ人と金がかかるんだよぉ♪
496 名前：仕様書無しさん mailto:sage [2008/08/10(日) 21:36:10 ]: どうしてこう次から次へとマ板は自己陶酔するコテが湧くのか。
>80がおじゃばならまだいいけど、別人ならこんなのが複数いると思うだけでいやだ。
497 名前：80 mailto:sage [2008/08/10(日) 21:37:59 ]: この業界の奴らは、頭は良いが、利口じゃない。
つくづくそう思う。不器用で要領が悪い。
498 名前：80 mailto:sage [2008/08/10(日) 21:41:38 ]: >>496
おじゃばって誰のことかわからない。

おまえは「おじゃば」のファンなのか？なら、「おじゃば」のいるスレに行け。
俺はお前の相手をしてやれない。
499 名前：仕様書無しさん mailto:sage [2008/08/10(日) 21:44:30 ]: 難しい事を書くから頭の悪い >>496 が嫉妬してるんだろｗ
ほっときゃいい。
500 名前：仕様書無しさん [2008/08/10(日) 22:31:15 ]: >>464
HAYST法はヘイスト法だよ
秋山さんは意外とマンガ好きなんだ
501 名前：仕様書無しさん mailto:sage [2008/08/10(日) 23:30:52 ]: >>490
＞よーは、開発者のテストなんて客からしたら気休めさ。

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

KKDで何となくやって期限が来たらリリース。
潜在してるバグはクレーム来てから直せば良いや。
とそういうことかい？
502 名前：仕様書無しさん mailto:sage [2008/08/10(日) 23:44:57 ]: >>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ

>>388はソフトウェアの信頼性を定義したぞ。そして、俺自身の中で>>388の主張に腑が落ちた。
503 名前：仕様書無しさん mailto:sage [2008/08/10(日) 23:52:23 ]: 90人が作成したコードを、実装内容も知らない、実装言語にも詳しくないようなテスター10人が
効率のよい品質の高いテストができるのだとすると、どう考えてもそれを各プログラマが実行
したほうが、より効率のよい品質の高いテストができる気がする。
504 名前：仕様書無しさん mailto:sage [2008/08/11(月) 23:50:38 ]: >>503
プログラマは自分のプログラムには異常に寛容なので、無理です。
505 名前：仕様書無しさん mailto:sage [2008/08/12(火) 06:39:29 ]: >>503
それも完全じゃないんよね
PGが仕様を把握してないとダメやし
506 名前：仕様書無しさん mailto:sage [2008/08/12(火) 13:53:17 ]: ホワイトボックス、グレーボックス、ブラックボックス
どれがテストとして質が高いかなんて話に意味あるの？

それぞれに目的が違うんだから比べてもしょうがないと思うんだけど。
507 名前：仕様書無しさん mailto:sage [2008/08/12(火) 14:31:51 ]: グレーって初めて聞いたよ
508 名前：仕様書無しさん [2008/08/13(水) 03:50:17 ]: www5f.biglobe.ne.jp/~h-it/mlcont/mc0269.htm
>>507たまにはぐぐろうな
509 名前：仕様書無しさん mailto:sage [2008/08/13(水) 10:49:09 ]: >>508
thx
ただ、現場で聞かないなー、と思ったんだ
510 名前：80 mailto:sage [2008/08/16(土) 08:02:49 ]: >>502
>今日初めて見たが、みんな何か勘違いしてないか？
>テストで信頼性は上げられない、テストは
>「このプログラムにはバグがあるます」を実証するもので
>バグを沢山検出したからと言って、そのプログラムには
>もうバグが存在しないと言う実証にはならない。
>実際は逆で、統計的に見るとバグ密度の多いプログラムほど
>残りの潜在バグが多く含まれている。

テストはバグを発見するためのもだけじゃない。これはプログラマーの視点
だな。

テストはむしろ、要求したとおりに動作するか？が重要だ。
テストにパスすれば、そのシナリオ（操作手順）で、少なくとも
動作するという事を証明できる。

目的を見失った状態で、統計とか客観的な手法とかを持ち出すから
本質を見失う。統計は手段。バグ発見は、テスト結果。
ちゃんと整理した方がいいぞ。

テストの目的は、要求を満たしているかどうかを確認すること。
511 名前：仕様書無しさん mailto:sage [2008/08/16(土) 19:50:07 ]: >>80はユニットテストを重視も軽視もしてないと言ってたが、
もしかして重視してるんだけどただ>>80だけがそれを理解していないんでは？
512 名前：仕様書無しさん mailto:sage [2008/08/16(土) 20:45:36 ]: もだけ？
513 名前：511 mailto:sage [2008/08/16(土) 21:19:04 ]: >>511は　>>80の会社は重視してるけど　ってことね。
514 名前：80 mailto:sage [2008/08/16(土) 22:56:34 ]: >>511
ユニットテスト（単体テスト）は当たり前。軽視も重視もしていない。
重視したところで精度が上がるわけでもない。プログラマーの能力に依存
するからな。

プログラマーは忙しい。プログラマーに負担を増やしても全体的に品質が
落ちる。

ユニットテストを強化して効果が出るかどうかはその組織しだい。
俺は、限定的だと考えている。

プログラマーは均質ではない。
分析能力のある者、観察能力のあるも者、創造力のある者、忍耐力のある者
十人十色だと思う。分析能力や創造力はあっても観察能力がない奴も居る。
チーム開発は、各人の能力を補完し合って結果を出すものだと思うがな。

ごちゃごちゃ言わずに、優秀なプログラマーを金で雇ってきて、
自由にやってもらう方が結果が出たりもする。
515 名前：仕様書無しさん mailto:sage [2008/08/16(土) 23:39:43 ]: 重視・軽視って言葉の基準があいまいだな。
ユニットテストだけを特別重視しているわけではない。くらいの意味合いかな？
516 名前：仕様書無しさん [2008/08/16(土) 23:44:02 ]: >>515
特別重視しているわけではないってのも十分曖昧だと思うがな。
重視とか軽視とかは、相対的なもので基準を云々言うこと自体ナンセンス。
よーは、515が馬鹿だってこと。
517 名前：仕様書無しさん mailto:sage [2008/08/16(土) 23:56:02 ]: 相対的なものだからこそ、基準をはっきりさせろってことだろ。
他のテストと比べてユニットテストだけってことじゃん。
518 名前：仕様書無しさん [2008/08/17(日) 00:09:50 ]: >>517
いくら頑張ってもお前の言ってることも80の言ってることも
曖昧なんだよ。お前らがテストをしても品質は上がらねーよ。

ということで終わり。
519 名前：仕様書無しさん mailto:sage [2008/08/17(日) 00:27:10 ]: >>1
３割方終わった風な顔で、「コーディング終わりました。後はテストするだけです。」
これなら満足なのか？
520 名前：仕様書無しさん [2008/08/17(日) 00:36:04 ]: プログラマーより身分の低いテスターが愚痴を言ってるだけだろ。
521 名前：仕様書無しさん [2008/08/17(日) 00:44:24 ]: >>1
おれが言いたかったことを、代弁してくれて
心からありがとう( ´v｀)
522 名前：仕様書無しさん mailto:sage [2008/08/17(日) 01:32:59 ]: >>519
そりゃどんな顔なんだよ
523 名前：仕様書無しさん mailto:sage [2008/08/17(日) 02:12:09 ]: この業界に20年以上いるが、グレーボックステストなんて言葉初めて聞いた
そんなのがあるんだ
524 名前：仕様書無しさん mailto:sage [2008/08/17(日) 02:38:38 ]: >>523
あるかどうかグレーです
525 名前：仕様書無しさん [2008/08/17(日) 08:14:37 ]: >>523
みんなが勝手に名前を付けているだけで何が正しいとかはないと思うな。
526 名前：仕様書無しさん mailto:sage [2008/08/17(日) 09:03:09 ]: ブラックホールテスト
527 名前：80 mailto:sage [2008/08/17(日) 09:41:22 ]: モデルベーステスト
非モデルベーステスト
モンキーテスト（アドホックテスト）
静的テスト
動的テスト
単体テスト
結合テスト
システム・テスト
受入テスト
回帰テスト

機能テスト／機能網羅テスト
パフォーマンス・テスト
負荷テスト
障害テスト
セキュリティ・テスト

色々あるな。でもな。分類とかしてる時点で間違いの方向に行ってる
気がする。バグは細部に潜んでることが多い。これらの分類にすべての
バグが綺麗にあてはまらないから「想定外のバグ」が出荷後に問題になる。
528 名前：仕様書無しさん mailto:sage [2008/08/17(日) 10:07:05 ]: bp = malloc(sizeof(Buff *));
これはどのテストで検知するべきバグだろね？
529 名前：仕様書無しさん mailto:sage [2008/08/17(日) 11:30:29 ]: その手続きを持つ関数の単体テスト
530 名前：仕様書無しさん mailto:sage [2008/08/17(日) 11:47:12 ]: じゃ東証は･･･
531 名前：仕様書無しさん mailto:sage [2008/08/17(日) 11:54:56 ]: テストに関していえばtestabilityとかが末端まで広まる前のコードだった
532 名前：仕様書無しさん mailto:sage [2008/08/17(日) 13:02:29 ]: >>527
でかいシステムの場合、分類しないとテストの目的がはっきりしなくなるのよ
533 名前：仕様書無しさん mailto:sage [2008/08/17(日) 13:03:25 ]: >>528
ソースコードレビュー
534 名前：仕様書無しさん mailto:sage [2008/08/17(日) 18:37:00 ]: >>527
例えば、パフォーマンステストとか負荷テストとかは所謂バグつぶし目的じゃない気がするが。

ていうかちゃんと分類されてないとまともにテストできないだろ・・・
535 名前：仕様書無しさん mailto:sage [2008/08/17(日) 19:05:50 ]: おじゃばにそんなこと言っても無理
536 名前：80 [2008/08/17(日) 21:41:00 ]: いや、いたって普通に分類してテストしてるよ。でもバグが減らないから
今やっているやり方が間違っているのかな？って考えているところさ。
よーは、学術的なアプローチに限界を感じてるんよ。

>>527
どのテストも、バグ潰しを目的としているわけではない。
バグ潰しは、デバッグでやるものだ。

> bp = malloc(sizeof(Buff *));
この手のバグは、デバッグの時にみつけるべきもの。
うちでは、Purifyとか使ってるけどね。

メモリリークチェックやメモリフットプリント、関数プロファイリング
などはツールでやるのが効率的だと思う。
537 名前：仕様書無しさん mailto:sage [2008/08/17(日) 22:05:10 ]: 529に１票
malloc()に渡すパラメータのサイズをチェックすべき

"デバッグ時"なんて、動作させて妙な状況が発生しないかぎりチェックしようが無いよ...
538 名前：仕様書無しさん mailto:sage [2008/08/17(日) 22:06:36 ]: >>536
>うちでは、Purifyとか使ってるけどね。
I社の製品使うんだｗ

>この手のバグは、デバッグの時にみつけるべきもの。
デバッグの意味分かってるか、アホだろうｗ
539 名前：仕様書無しさん [2008/08/17(日) 22:25:01 ]: ググってみた。

デバッグ
　コンピュータプログラムの誤り(「バグ」と呼ばれる)を探し、
　取り除くこと。

テストでは、バグを取り除くことはしないので、>>534 の言う
「バグ潰し」は、話の流れ的におかしい。
540 名前：80 mailto:sage [2008/08/17(日) 22:27:13 ]: > bp = malloc(sizeof(Buff *));
> これはどのテストで検知するべきバグだろね？
このコードを書いたプログラマーの採用試験に一票。
541 名前：仕様書無しさん mailto:sage [2008/08/17(日) 22:29:32 ]: 軽視するわけじゃないけど、GUIのテストってむずくね？
どうすればいいんだぜ
542 名前：仕様書無しさん [2008/08/17(日) 22:47:02 ]: >>540
その採用試験に
>この手のバグは、デバッグの時にみつけるべきもの。
と回答したら、その人は合格するか？
543 名前：仕様書無しさん mailto:sage [2008/08/17(日) 23:49:45 ]: >>539
安価ミス？
544 名前：仕様書無しさん mailto:sage [2008/08/18(月) 01:22:44 ]: 偽物が湧いてるんじゃね？
545 名前：仕様書無しさん mailto:sage [2008/08/18(月) 09:11:25 ]: >>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ
546 名前：仕様書無しさん mailto:sage [2008/08/18(月) 15:12:15 ]: >>536
＞いや、いたって普通に分類してテストしてるよ。でもバグが減らないから
＞今やっているやり方が間違っているのかな？って考えているところさ。
＞よーは、学術的なアプローチに限界を感じてるんよ。

学術的アプローチが何か知らないけど、単にテスト設計がショボいだけじゃね？

とりあえず、ITとSTの命令網羅率と条件網羅率は幾つよ？
網羅率も出してないなら、テスト仕様の質をどういう「学術的アプローチ」で出してみたんだ？
（網羅率が全てじゃないと思うが、うちのテストの評価では基本的な指標の1つとしてるので）

テスト仕様の質を評価してなかったら、
たとえどんな(学術的な？)手法でテスト結果を評価してみても意味無いぞ。
547 名前：仕様書無しさん mailto:sage [2008/08/18(月) 22:12:36 ]: >>545
おじゃばは都合の悪いことはスルーデフォ
548 名前：仕様書無しさん mailto:sage [2008/08/19(火) 11:25:08 ]: お前ら楽しそうだな、システム組むってやっぱ分業してナンボだよな
一人で設計して一人で組んで一人でテストしてデバッグする俺ってなんなんだろう
こんなんでいいシステムが組めるわけないよな。何が少数精鋭だよ
社長はそんなもん一人で出来るとか言ってるが、アンタ自身が一人でやったことないだろ
自分でやったこともない事を人に押し付けるなっつーの。ホント意味わかんねーな。どーよこれ
549 名前：仕様書無しさん mailto:sage [2008/08/19(火) 11:28:19 ]: 俺も、一人で設計して一人で組んで一人でテストしてデバッグする俺。
550 名前：仕様書無しさん [2008/08/19(火) 12:57:02 ]: 自分からテスト専門です、って宣言してる派遣テスターって何なの？

将来プログラマとかSEになりたい、とかならわかるけど。
向上心ないよね、頑固だし。
そういう派遣テスターって、仕様書は読めない、
テスト仕様書も作れない、テストプログラムも作れない
やれることは「テキトーにプログラムを触る」ことだけ。

俺は派遣プだけどさ、こういう派遣テスターがいると
派遣全体がバカにされるんだよ。
テスト専門派遣なんて氏んで欲しいよ、まったく。

今日も正社員の人が派遣テスターに仕様書を読んで
テスト仕様書を作ってください、って説教してたよ。
その派遣は頑固に「何故、仕様書が必要なんですか？」って
反論してたから、きっとテスト専門派遣テスターだな。
仕様書も読まず、テスト仕様書も作らず、ただテキトーに
プログラム触るだけで給料もらおうなんて頭おかしいんじゃねーの？

あ～あ、あの派遣テスターが3ヵ月後に切られるまで、
仕様書も読まねーでテキトーにテストしたバグ票がまわってくんのかよ。
そんな糞なもん、読んで処理する派遣プの身にもなってくれよ。
うわ～、しかもそいつが切られる3ヵ月以内に中間納品あるじゃねーか！
テスト仕様書もなしにテキトーにテストして納品か。
中間納品後にソッコウクレームでデスマ必至だな。俺の休みも返上かよ。

派遣専門テスターさんよ、少しは向上心持てよ！
頑固な性格直して仕様書読めよ！テスト仕様書作れよ！
551 名前：仕様書無しさん mailto:sage [2008/08/19(火) 13:12:01 ]: 長い
552 名前：仕様書無しさん mailto:sage [2008/08/19(火) 14:00:38 ]: >>550
低レベルな話だなあ

そんなバカ派遣テスターなんか契約終了を待たずにに切ればすむ話だろ

正社員がテスト仕様書を書くように指示をだしているのに反抗しているんだから
即日クビでもなんの問題もないよ
553 名前：仕様書無しさん mailto:sage [2008/08/19(火) 14:39:18 ]: >>551-552
>>550 はコピペだよ
554 名前：仕様書無しさん mailto:sage [2008/08/19(火) 15:00:16 ]: 【頑固】派遣テスターの人格問題【向上心ゼロ】
pc11.2ch.net/test/read.cgi/prog/1207581904/
555 名前：仕様書無しさん mailto:sage [2008/08/21(木) 22:15:55 ]: まずはテストの工数を軽視する者どもをなんとかしないとな
556 名前：仕様書無しさん mailto:sage [2008/08/24(日) 19:39:07 ]: 急に80が来なくなったな
557 名前：仕様書無しさん mailto:sage [2008/08/26(火) 10:28:36 ]: おじゃばはOOスレに戻りました
558 名前：仕様書無しさん mailto:sage [2008/08/26(火) 11:31:38 ]: 相変わらず羞恥心の欠片もないんだな
559 名前：80 mailto:sage [2008/08/27(水) 09:48:30 ]: >>556
お久しぶり。さすがに、２ちゃんばっかやってるわけじゃないし・・・。

近頃のプログラマーも「未経験者歓迎！」で採用されたど素人が
平気で派遣でやってくる時代だからな。テスターにプロ意識を
強要しても無駄。

金だけ欲しいなら、テスターになっていっぱい残業したらいいわけで。
リリースしたものにバグがあったらプログラマーの責任って言い張れば
良いわけで・・・。

テストを軽視するな！とか理屈でごちゃごちゃ言っても仕方ないと思うんよ。
重視しても仕事は楽にならないし給料が増えるわけじゃないし。。。
結局、テスターは頑張らないよ。プログラマーだってテストする十分な時間
ないしね。

俺は、そういう人たちを管理してたりしてるんだけど。
人数が多いプロジェクトでは、1/3は頑張るけど1/3の人はさぼる。

全員優秀なチームは存在しない。予算も潤沢に無い。
仕事のやり方をそのままにすれば、何かを重視し何かを軽視せざるを得ない。
となると、テストがどうしても軽視されてしまう。
仕事のやり方を変えるのは、製品開発より難しい・・・。
このジレンマからのがれる方法はないものかねぇ。
560 名前：仕様書無しさん mailto:sage [2008/08/27(水) 22:31:38 ]: >>559
残りの1/3は？
561 名前：80 mailto:sage [2008/08/28(木) 23:30:31 ]: 以下を参照のこと

働きアリの法則
2-8の法則
2-6-2の法則
パレートの法則
562 名前：仕様書無しさん mailto:sage [2008/08/28(木) 23:38:18 ]: 未経験者歓迎で入ったド素人コーダーだけど単体テストだけは念入りにやってるよ
というか馬鹿だからテストから書かないとコードが書けない罠ｗ
人より手間かけてる分作業の速度は遅くなるけど多分省いても大して速くならんとも思う
563 名前：仕様書無しさん mailto:sage [2008/08/29(金) 00:08:58 ]: >>562
単体を大事にするその気持ちが大事なのです

　　　　　　　　　　　　　　　　　　　　　　　　みつぬ

いつかみんなに認められるよ、その努力は
564 名前：80 mailto:sage [2008/08/30(土) 07:58:58 ]: 優秀なプログラマーを確保できないプロジェクトチームでは、
テストを重視しているのかもしれないなぁ。
プログラミング能力ってすぐに向上しないから、テストくらい
ちゃんとしろよってことなのかな。
565 名前：仕様書無しさん mailto:sage [2008/08/30(土) 08:42:24 ]: そういえば俺も初めてのプロジェクトではまずテスト書くのから始めたなあ。
まあそれは勉強の意味合いがほぼ100%だったけど。
566 名前：仕様書無しさん [2008/08/30(土) 09:50:27 ]: 事務より簡単で誰でもできる仕事なのに時給は技術者！
ITテスターで稼ぐための情報を交換しましょう。

☆派遣先は大企業じゃないと駄目です。中小だとテスターもプログラムの仕様が
　わからないといけないとかテストプログラムを書けとか言われちゃいますよ。
　大企業ならプログラムを触るだけのテスターでも大丈夫。

☆派遣先ではテスターはプログラムを触るだけでいい、
　そんな空気を作っていきましょう。仕様書読んでください、
　とか言われたら「なんでテスターが仕様書読むんですか」って食い下がって。
　プログラムの仕様書を読んだり、テストの仕様書を書いたりするのは大変ですよ。

☆普通にプログラムを触ってテストしてると、何をテストしているのかわからない、
　とか言い出す人、いるんですよ。プログラマとかってこういう人多いです。
　そういう人は上司にあることないこと告げ口して追い出しちゃいましょ。
　人事権のある人とは仲良くしておくことが大切。
　
☆納品して何かあったら大変だからとプログラムの仕様書を読んだり、
　テスト仕様書を書いちゃうテスターがいますけど、
　こっちもやることになるからすごく迷惑。
　テスト結果の責任は担当の正社員にありますよね。
　納品後のクレームは最終チェックを怠った正社員が悪いんだから
　派遣は関係ないです。　
567 名前：仕様書無しさん mailto:sage [2008/08/30(土) 10:57:01 ]: >>559
＞このジレンマからのがれる方法はないものかねぇ。

軽視して良い工程なんて開発に存在しない。

十分な金と期間を客から引っ張って、ちゃんと人をアサイン出来ない
営業と管理層が悪い風にしか見えないが。
改善すんのはソコからでしょ。

「何かを重視し何かを軽視せざるを得ない。」と管理している自分が言う状況なら、
出だしから「これは無理じゃね？」っていう開発期間で仕事を受けてるってことでしょ？

1/3サボるのが分かってるなら、2/3で出来るスケジュールで受けろよ。
何そんな意味無い数字書いてんだ。

＞近頃のプログラマーも「未経験者歓迎！」で採用されたど素人が
＞平気で派遣でやってくる時代だからな。テスターにプロ意識を
＞強要しても無駄。

なら派遣使うなよ。
568 名前：80 mailto:sage [2008/08/30(土) 17:38:42 ]: >>567

>軽視して良い工程なんて開発に存在しない。
正論だけどね。そこを一歩踏み込んで考えないと実践では通用しないよ。

昔は「設計」「実装」が重視されていた。プログラマーのスキルと
モチベーションが高かったから、それで、結構うまくいっていた。
単体テストは、当たり前だったから特に話題にもならなかった。

でも、今では、ソフト技術者は3Kで「不人気」となり優秀な技術者は別の
業界へ流れて行く。インド、中国、ロシアの安いソフト労働力の台頭も
追い討ちをかけている。

日本のプログラマーのレベルは、以前からするとずいぶん下がった。

そもそも、「単体テストを重視する」という事自体が、俺からすると
滑稽なんよ。「うんこしたら手を洗う」くらい当たり前のことを
ワザワザ言わなくてはいけない時代になったのが残念だな。

言わなきゃ出来ないレベルの低い奴に、言って分かると思うか？
出来るやつは、言わなくてもやるもんだ。

単体テストをしないプログラマーにいくらプレッシャーを与えても
良い結果は得られないよ。それなら、仕事のやり方を工夫する方が
よっぽどましさ。
569 名前：仕様書無しさん [2008/08/30(土) 19:34:30 ]: >とか言われたら「なんでテスターが仕様書読むんですか」って食い下がって。
食い下がる以前に正社員に逆らったらクビだろｗ
570 名前：仕様書無しさん mailto:sage [2008/08/30(土) 20:22:54 ]: >正社員に逆らったらクビだろｗ
>正社員に逆らったらクビだろｗ
>正社員に逆らったらクビだろｗ

バカ？
571 名前：仕様書無しさん mailto:sage [2008/09/02(火) 00:33:04 ]: >>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ
572 名前：８０ mailto:sage [2008/09/02(火) 00:41:51 ]: >>571
さみしいんだねｗ
573 名前：仕様書無しさん mailto:sage [2008/09/02(火) 00:51:25 ]: おじゃばくさい返しだな
574 名前：仕様書無しさん mailto:sage [2008/09/02(火) 10:28:46 ]: >>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ
575 名前：仕様書無しさん [2008/09/05(金) 01:57:40 ]: テスターって気楽でいいよね。
自分のバグじゃないし、動かしてダメダメ言っておけばOKみたいな感じ。
576 名前：仕様書無しさん mailto:sage [2008/09/05(金) 19:17:53 ]: その代わり、実装周りの人間が帰った夕方から、
その日の更新分含めたテストやってたりして、
夜間シフト状態になってたりした事あったけどｗ
577 名前：仕様書無しさん [2008/09/06(土) 00:27:24 ]: >>575
嫌われるのが仕事だからｗ
プログラマーは絶対にバグを出す。
悪いのはプログラマー。

>>576
プログラマーは24時間労働がデフォ。
夜間シフトは、金儲けにうってつけ。
578 名前：仕様書無しさん mailto:sage [2008/09/06(土) 00:29:40 ]: まだやってんのか・・・糞スレはsageでやれ
579 名前：仕様書無しさん [2008/09/06(土) 01:20:26 ]: おまえもな
580 名前：仕様書無しさん mailto:sage [2008/09/06(土) 18:46:21 ]: お前2chは初めてか？
力抜けよ
581 名前：仕様書無しさん [2008/09/07(日) 07:59:03 ]: おまえもな。
582 名前：仕様書無しさん mailto:sage [2008/09/07(日) 08:24:02 ]: 私見だがテスターって基地外な奴のほうが優秀だと思う。
・常識では思いつかないような操作をする。
・人の話を聞かない。（話で誤魔化すことができない）
・理解力が無い。（おのずとヘルプ等を細かくしてしまう）
・集団の中で浮いてる。（無駄話をせず黙々と作業）

開発としては関わりたくないのだけど、
客観的に考えると良い製品ができるような気がする。
583 名前：仕様書無しさん mailto:sage [2008/09/07(日) 10:48:23 ]: 変わり者くらいにしておけよ
基地外が適している仕事なんかねえよｗ
584 名前：仕様書無しさん mailto:sage [2008/09/07(日) 15:13:20 ]: 本物の基地外と接した事が無いからそんな事言ってるんだと思うけど。
先ず、仕事として何かをやらせる事自体が無理。
585 名前：仕様書無しさん [2008/09/07(日) 15:49:24 ]: >先ず、仕事として何かをやらせる事自体が無理。
それは派遣テスターも一緒だろ
「まず仕様書を読んでテスト仕様書を作れ」と仕事の指示を出しても
まったく手も足も出ないバカばっか
586 名前：仕様書無しさん mailto:sage [2008/09/07(日) 16:05:00 ]: それは契約で仕事の範囲をちゃんと決めてないんじゃないか？

テストオペレータとして雇ってるのか、
テスト設計からやる技術者として雇ってるのか、
はっきりしない限りはなんとも言えない。
587 名前：仕様書無しさん mailto:sage [2008/09/07(日) 16:11:13 ]: >>586
つ「作業内容：テスト一式」
588 名前：仕様書無しさん [2008/09/07(日) 16:26:21 ]: オペレートしかテスターなんてイラネ
589 名前：仕様書無しさん mailto:sage [2008/09/07(日) 19:32:30 ]: >>588
おまいのようなケアレスミスの多いマにはテスターは必要だろｗ
590 名前：仕様書無しさん mailto:sage [2008/09/07(日) 19:37:50 ]: 逆に適当に触るだけのテスターじゃケアレスミス位しか発見できんな
591 名前：仕様書無しさん mailto:sage [2008/09/07(日) 23:45:37 ]: 仕様策定の段階からテスターと一緒にレビューしてる人いるの？
592 名前：仕様書無しさん mailto:sage [2008/09/09(火) 18:12:48 ]: >>585
派遣テスターで、テスト仕様書から作れるヤツなんて使ったことねーけど
流石にテスト仕様は、仕様策定した連中が書くでしょ
要求仕様わかってない連中にテスト仕様書かせてどうすんのさ
593 名前：仕様書無しさん mailto:sage [2008/09/09(火) 20:16:18 ]: なんのために仕様書があるんだよ
594 名前：仕様書無しさん mailto:sage [2008/09/09(火) 22:11:37 ]: >>593
お客さんに古紙回収してもらうため
595 名前：仕様書無しさん [2008/09/10(水) 00:59:36 ]: >>592
典型的な底辺低賃金会社の発想だな
596 名前：仕様書無しさん [2008/09/10(水) 18:03:45 ]: 俺の名前をテストデータに使うなバカ上司
俺は全然タッチしてないシステムなのに
マジで頭おかしいだろ
597 名前：仕様書無しさん mailto:sage [2008/09/10(水) 18:24:38 ]: >>591
ちゃんとやってる所は必ずと言っていい程参加させてるね。
テスト設計者を
598 名前：仕様書無しさん mailto:sage [2008/09/10(水) 21:07:59 ]: >>596
名前覚えて貰ってるんなら結構なことではござらぬか
599 名前：仕様書無しさん [2008/09/10(水) 23:11:39 ]: 画面見て結合テスト仕様書つくってください
って同僚がベンダさんに言ってた

何をテストするんだろういったい
600 名前：仕様書無しさん mailto:sage [2008/09/10(水) 23:52:49 ]: 要求される「品質」にも拠るんだよな。

100万単位の人間が使うようなブツなら、テストは万単位でガッツリやらんとヤバいことになる。
万単位のテストをやるなら、まず8割9割のテストは自動化しないと何ともならんわ。
で、コードを修正したら一度自動テストを回す感じ。
理想としては、テスト設計書の概要はWordとかでもいいんだけど、詳細設計はExcelとかでマクロ組んで
テストデータを自動で吐いてくれるような感じにする。

業務系の仕事とかで、客とねんごろって世界なら、テストが適当でも何とかなる場合がある。
DBのデータが㌧㌦みたいなのさえ出なければ、まああとは酒の場の寝技。
こういうのを技術者とは言わんけど、それが通じる世界もあるんで。
ただ、業務系だけだね、これが通る世界は。
601 名前：仕様書無しさん mailto:sage [2008/09/11(木) 01:05:05 ]: >>390
「クリーンルーム」じゃね？
徹底的に個々のコードレビューをやるって奴。
IN入れてOUTの結果が期待通りか否かを見る、って方式じゃなくて、
コードのロジックに誤りがあるかないかをプロが検査するって感じか。

OpenBSDはそういう手法だと聞いたことはある。
602 名前：仕様書無しさん mailto:sage [2008/09/11(木) 01:21:31 ]: >>601
プロの定義がおかしい希ガス
603 名前：仕様書無しさん mailto:sage [2008/09/11(木) 13:35:53 ]: >>598
テストしながら「(俺の名前)がおかしい」ってブツブツ言ってるんよ
呼び捨てで

普段からそういう人間だってのは知ってたが、
そういう嫌がらせされたのは初めてだ
604 名前：仕様書無しさん mailto:sage [2008/09/11(木) 16:34:05 ]: >>603
名前にダメ文字入ってるんじゃね？　「十」とか。

ダメ文字チェックなら「図『表』」「『能』力」「『十』番」あたりを使えば
いいだけなんだけどさ。
605 名前：仕様書無しさん mailto:sage [2008/09/27(土) 22:11:07 ]: >>1
コーディングが終わってやっと３割終わったかどうかってところだろが。

てことはさ、テストファーストでテストコードを書き終われば
本体のコードは進捗ゼロでも７割終わったと言っておｋ？
606 名前：仕様書無しさん mailto:sage [2008/09/27(土) 22:40:13 ]: テストで初めて発覚した仕様の洩れを、いまさら作り込めと言われて、最近鬱。
607 名前：仕様書無しさん mailto:sage [2008/09/30(火) 01:03:30 ]: >>605
テストファーストはテストコードだけを
最初にコーディングするものでは無い訳だが？

言葉ばっかり一人歩きすると勘違いする奴が多くて困る
608 名前：仕様書無しさん [2008/09/30(火) 06:12:10 ]: そもそも本体コードをテストしないことには終わらんだろw
609 名前：仕様書無しさん [2008/09/30(火) 06:44:53 ]: 派遣テスターによるいい加減なテストが衰退しつつある
610 名前：仕様書無しさん [2008/09/30(火) 13:04:12 ]: テストを一切せずにリリースする国産MMORPGもあるのにな
611 名前：仕様書無しさん [2008/09/30(火) 13:39:47 ]: ファイナルファンタジーXIの話はもういいから・・・
あれは試験ゼロにすることで経費浮かして利益あげてるんだよ。
612 名前：仕様書無しさん mailto:sage [2008/09/30(火) 14:37:05 ]: それにしても、実装してない機能のバージョンアップしました報告はすごかったよなww >FF11
613 名前：仕様書無しさん mailto:sage [2008/09/30(火) 15:22:15 ]: 某銀行合併時もATMとかちゃんとテストしてなかったぽいしね
614 名前：仕様書無しさん [2008/09/30(火) 16:30:39 ]: >>611-612
これか・・・すげぇな。アップデート項目チェックとかしてないんだろうか？
ゲーム開発って楽そう。

ttp://www.playonline.com/ff11/polnews/news12783.shtml

>■一部アイテムのアイコングラフィックが変更されたお知らせに
>　おいて、実装されていないアイテムが一覧に含まれておりました。
>　脳汁／狡賢い脳汁／幸せの人参汁／まろやかな鳥汁／濁った血汁
615 名前：仕様書無しさん mailto:sage [2008/09/30(火) 17:13:52 ]: >>605
それだとまだテストコードのテストが7割残っているから、
実は全体の7割の3割、つまり2割強しか終わってないんだな。
616 名前：仕様書無しさん mailto:sage [2008/09/30(火) 17:23:26 ]: テストコードの正しさはテストしながら検証されていくという、
テスト結果がNGなら、テストか実装かどっちかが間違っているわけ
だから。全部OKになった時点で実装とテストの信憑性もあがるけど、
これで安心できるかどうかは、テストの網羅性にもよるわな。
あと間違った実装を間違ったテストに通してOKになる可能性もなき
にしもあらずだな。
617 名前：仕様書無しさん mailto:sage [2008/10/02(木) 23:21:01 ]: テストの正しさを検証するのはテストのレビューじゃねの？
うちじゃやるけど、他んとこじゃあんまりテストのレビューってやんないのかね。
618 名前：仕様書無しさん mailto:sage [2008/10/03(金) 01:29:41 ]: >>617
書類に関するレビューは必ずやる。
それがソースコードでもテスト検査書でも同じ事。
619 名前：仕様書無しさん mailto:sage [2008/10/03(金) 01:53:34 ]: >>618
休暇届もやるのか・・・・

ムチャクチャNG出されそうだ･･･・・
620 名前：仕様書無しさん mailto:sage [2008/10/03(金) 01:59:14 ]: >>619
ああ、休暇届に不備があってプログラムに不具合が出るならやるさ。
621 名前：仕様書無しさん mailto:sage [2008/10/03(金) 08:10:34 ]: この日確かレビューだったよね？よってNG。

とかか。
622 名前：仕様書無しさん [2008/10/03(金) 09:23:34 ]: >>618
俺の前の会社は「テスト検査書なんかいらないんだ！テストというものはどんどん触るのが仕事なんだ！」
という社長の方針でレビュー以前にテスト検査書が存在しなかったけどね。

まあ、結局倒産して社長一家は行方不明だがｗ
623 名前：仕様書無しさん mailto:sage [2008/10/03(金) 09:46:04 ]: 俺的にはまず全体できに荒くテストしてから
細かいところをテストするのがいいと思う。
624 名前：仕様書無しさん mailto:sage [2008/10/03(金) 13:26:55 ]: テスト検査書の正しさは誰が検証するんだ
625 名前：仕様書無しさん mailto:sage [2008/10/03(金) 22:37:27 ]: SQA部門とコレまでに改善されてきた(はずの)システムが検証する。
626 名前：仕様書無しさん [2008/10/04(土) 18:01:37 ]: テスタがプログラマからテスト仕様書を貰えると思ってる時点でおかしい。

折れの職場はこうだからバグが減らない。
んで営業がキレる。折れのせいじゃねえよ。構造的欠陥だ。
627 名前：仕様書無しさん mailto:sage [2008/10/04(土) 18:09:53 ]: テスト仕様をプログラムから起こしちゃあ、プログラムの正当性が判断できないよね。
そりゃそうだ。
テスト仕様はシステム設計書やシステム仕様書から起こす物だよな。
628 名前：仕様書無しさん mailto:sage [2008/10/04(土) 18:15:27 ]: >>623だけが素人くさいな
629 名前：仕様書無しさん mailto:sage [2008/10/05(日) 00:15:15 ]: 項目Aを実行する　テスト内容Aの結果が○○になる
項目Bを実行する　テスト内容Bの結果が○○になる
...

これをテスト仕様書とかいってももってくる35ぐらいのおっさん
いるんだけど、テスト軽視とかのれべるじゃねーよｗ
630 名前：仕様書無しさん mailto:sage [2008/10/05(日) 00:42:27 ]: >>629 その人に、それ1回やってみましたか？って言ってみたらどうかな。
631 名前：仕様書無しさん [2008/10/05(日) 03:35:07 ]: UTが内部設計、Itaが外部設計、STが要件定義書のテストだよね？
632 名前：仕様書無しさん mailto:sage [2008/10/05(日) 04:55:09 ]: 仕様書書いたあとに仕様書からテスト紙を起こす
そのあとコーディング
こっちの方が絶対バグが減る
633 名前：仕様書無しさん mailto:sage [2008/10/05(日) 05:05:40 ]: >>632
設計はどのタイミングで
634 名前：仕様書無しさん mailto:sage [2008/10/05(日) 05:08:09 ]: >>633
用件定義はどのタイミングで
635 名前：仕様書無しさん mailto:sage [2008/10/05(日) 05:21:49 ]: >>634
契約金額はどのタイミングで
636 名前：仕様書無しさん mailto:sage [2008/10/05(日) 10:23:33 ]: >>631
ItaとかItbってIBMかなんかの方言だったような
637 名前：仕様書無しさん mailto:sage [2008/10/05(日) 10:29:50 ]: 省略表現とか横文字を無意味に乱発する奴は
折れはあまり好きじゃないな。

日本語で適切な表現があれば、最初からそれを使えば
沢山の人に読んでもらえる。
638 名前：仕様書無しさん [2008/10/06(月) 10:34:19 ]: >>629
ファイナルファンタジーXIスタッフ乙
639 名前：仕様書無しさん mailto:sage [2008/10/06(月) 20:24:24 ]: >>582
その基地外に関わる奴のストレスを考えたら大変なものだろうな。
うちの優秀な人間を潰されたくないからそー言う奴は使わない方が無難。

下請けに基地外が紛れ込んでる分にはOKだが、失敗したら賠償請求するよ？
640 名前：仕様書無しさん [2008/11/02(日) 23:55:58 ]: ソニー系列で仕事した人に聞きたいんだけど、
ソニーって、ぜんっぜんテストしてなくね？
俺の部署の上司が元ソニーなんだが、テスト工数を全く見込んでくれない。
PS3のファームバージョンアップにも、
ちょっと動かせばわからないバグが平気で仕込まれてるし
641 名前：仕様書無しさん mailto:sage [2008/11/02(日) 23:56:31 ]: ×ちょっと動かせばわからない
○ちょっと動かせばわかるような
642 名前：仕様書無しさん mailto:sage [2008/11/03(月) 00:02:50 ]: テストしてないは言い過ぎ
643 名前：仕様書無しさん mailto:sage [2008/11/03(月) 00:25:07 ]: テストしていない＝検仕無しでプログラムが動けばOKとしている
644 名前：仕様書無しさん mailto:sage [2008/11/03(月) 02:38:18 ]: ソフトウェアが存在しない時代からあった古い会社ではありがち
645 名前：仕様書無しさん [2008/11/03(月) 02:49:53 ]: >>644
そういうテストをしていると会社自体が存在不可能になり、
消滅していくので、実際にはほとんどない

たとえなんとか存在できても結局受託じゃ
瑕疵保証で採算が合わず、社員は毎日他人に会社に出勤してるｗ
646 名前：仕様書無しさん mailto:sage [2008/11/03(月) 17:36:40 ]: S◯NYってソフト関係は丸投げしてるでしょ？
日立系あたりに。
そっちでテストはしてるんじゃねえの？
647 名前：仕様書無しさん mailto:sage [2008/11/03(月) 17:53:59 ]: >>646
目立から関連情報システムに○投げしてるよｗ
648 名前：仕様書無しさん mailto:sage [2008/11/04(火) 08:39:51 ]: で、勉強するのにおぬぬめの本はあるの？
何かスクール的なのとか行けって？
649 名前：仕様書無しさん mailto:sage [2008/11/04(火) 23:46:45 ]: 実戦＆実践あるのみじゃね？
650 名前：仕様書無しさん mailto:sage [2008/11/05(水) 00:16:02 ]: 本は自分で見て選ぶ
スクールは基本的に金の無駄
ただし、時間を金で買うなら、物によっては選択肢に入れても良い
651 名前：仕様書無しさん mailto:sage [2008/11/05(水) 00:24:50 ]: 仕様書どおりのテストをするのが仕事。＞つまらん
いやらしい境界条件や設定条件を組み合わせて、バグを見つけるのが趣味な俺。
652 名前：仕様書無しさん mailto:sage [2008/11/05(水) 00:56:25 ]: >>651
至って正常だから安心しろ。
変態的なバグ出しだと、動作中にコンセント抜くとか平気でやるからw
653 名前：仕様書無しさん mailto:sage [2008/11/05(水) 01:15:40 ]: >>652
フォールトトレラントシステムでは準正常系試験かとｗ
654 名前：仕様書無しさん [2008/11/05(水) 17:11:49 ]: カスSEが書いた試験書通りに試験するよりも、
ベテランPGがランダム試験したほうが効率的にバグ出せるよな。
でもそれを認めて生かしてるテストプロセスって世界的に見ても存在しないような。
日本人の職人技をプロセスとして体系的に確立することは出来ないんだろうな
655 名前：仕様書無しさん [2008/11/05(水) 20:54:27 ]: JCBカード決済に障害
656 名前：仕様書無しさん mailto:sage [2008/11/05(水) 22:25:50 ]: >>654
バグ取りとしてはその方が効率いいんだろうけど
客へのテスト実施内容報告としては愚鈍なやつが書いたような
単に全U/Iに同じことするような網羅系テストの結果資料が
絶対必要なんだよな・・・

特に最近に品管きどり連中はうるさい
657 名前：648 mailto:sage [2008/11/05(水) 23:25:57 ]: 亀だが>>649 >>650㌧ｸｽ。

意識改革やってみるわ。燃えてきた。
俺をテストしてやるっ！！
658 名前：仕様書無しさん mailto:sage [2008/11/07(金) 01:36:55 ]: >>656
同意。
泳がせとくだけで勝手にバグ見つけるテスタって居る。
しかし、クライアントへの提出物として程々網羅率の高い項目書って要る。

で、ランダムテストでバグが出てからその手順を項目書に織り込むなんて
アホらしいこともやらざるをえないことがあるよ。
659 名前：仕様書無しさん mailto:sage [2008/11/08(土) 00:36:54 ]: >>658
テスト項目にない内容が不具合票にあがってるぞ！
とかつっこむ品管とかもう、巣へ(・∀・)ｶｴﾚ!!と・・・
660 名前：仕様書無しさん mailto:sage [2008/11/08(土) 01:14:05 ]: >>659
客先からバグの報告が来ると
テスタは何やってんだ、とか言い出すんだろ？
661 名前：仕様書無しさん mailto:sage [2008/11/08(土) 01:28:27 ]: 最初からザル試験書なんだろ。
662 名前：仕様書無しさん [2008/11/09(日) 16:25:12 ]: >>654
ランダムテストのほうがバグが出るってw

そりゃ単にテスト仕様が低レベルなんだよw

お前の会社、年収500万前後で頭打ちだろw
663 名前：仕様書無しさん [2008/11/09(日) 16:28:42 ]: テスターで1000万超えてるやつっている？
664 名前：仕様書無しさん mailto:sage [2008/11/10(月) 00:28:19 ]: 常に悲愴感
自分のチームを守りたいのは分かるけど
最後まで人の話を聞いてくれ
665 名前：仕様書無しさん mailto:sage [2008/11/10(月) 00:37:21 ]: ニートにバグ１個３００円でやらせろ
666 名前：仕様書無しさん mailto:sage [2008/11/27(木) 23:26:08 ]: SEが試験書なんて作らずにテストコードを直接書けばいいのに
仕様→試験書→テストコードなんて伝言ゲームみたな事なんかありえん
で、上に提出する書類はテストコードから自動生成すればいい
どうせ碌に読まないんだからBDD用フレームワーク使って書いたテストから
辞書をチューンしたコリャ英和とmecabを使って生成してバレないだろうし
667 名前：仕様書無しさん mailto:sage [2008/11/27(木) 23:48:58 ]: SEが違えばテストコードも違うんだなこれが
それだと上に提出する書類はSEの数だけシナリオができて
支離滅裂な文章の羅列になっちゃう
668 名前：仕様書無しさん mailto:sage [2008/12/06(土) 03:46:41 ]: SEの書く試験書なんて、

○○機能テスト・・・○○機能が正しく動く
△△機能テスト・・・△△機能が正しく動く
××機能テスト・・・××機能が正しく動く

こんなもんですから。
669 名前：仕様書無しさん mailto:sage [2008/12/06(土) 12:11:27 ]: SEXXテストか
670 名前：仕様書無しさん mailto:sage [2008/12/06(土) 12:38:13 ]: SEXとは
SEがX(ﾊﾞﾂ=ｲﾗﾈ)という意味ですか
671 名前：仕様書無しさん mailto:sage [2008/12/06(土) 13:07:00 ]: 境界テストとか、異常値テストとかしないの？
672 名前：仕様書無しさん mailto:sage [2008/12/06(土) 13:27:43 ]: 運用開始後テストの為のテストですよ。
673 名前：仕様書無しさん mailto:sage [2008/12/06(土) 13:33:30 ]: 検収でこのSEﾂｶｴﾈということです。
674 名前：仕様書無しさん mailto:sage [2008/12/08(月) 18:09:09 ]: >>666
上でExcelとpowerpointいじくってるだけのクズが、
開発で使う言語でテストケース書くとか、出来るわけないし

要求しても、VBAでよく解らないコードが出てくるのが関の山ｗ
675 名前：仕様書無しさん [2008/12/24(水) 20:37:58 ]: テストは軽視してはいかんぜよ
676 名前：仕様書無しさん [2008/12/26(金) 00:57:13 ]: 俺はあえてバグを残したままテストする時あるな。

その方が油断しないのでテストがきめ細かくなる。
677 名前：仕様書無しさん mailto:sage [2008/12/26(金) 01:32:26 ]: 最近、まともな仕様書も書けないようなのが上にいるからな
そもそも仕様書もないからユニットテストもやりにくい
ユニットテストをＰＧに強引にやらせるのはかまわんけど
項目もこっちで作らなきゃいけないのは話が違うよね？

めちゃくちゃに追加したコントロール一覧はお前が作れよ
678 名前：仕様書無しさん mailto:sage [2008/12/26(金) 01:34:08 ]: って問題もあって開発の請負は絶対にやりたくないな
作ってやるけどそれにかかる金と時間は全部お前が出せって感じ
そうでないとやりたくない
679 名前：仕様書無しさん mailto:sage [2008/12/26(金) 11:46:13 ]: コードが全て
仕様書とか書き物は意味なし
よってテスト不要
作ったもんを使え
…そう抜かすアホが居る。

要件を仕様として書き出して合意を得たうえでコードに起こし仕様どおりに動くことを確認するのがテスト。
バグを見つけるためのものでは無い。
あのアホにはテストはバグを見つけることとしか見えてない。
680 名前：仕様書無しさん mailto:sage [2008/12/26(金) 12:18:04 ]: 制約論理プログラミング言語とか使っている人なんだよ多分
コードが書けた時点でドメイン内で正しく動作するのが証明されている、または
コードが形式的な証明と1対1対応しているような言語
まさかalgol派生の手続型言語を使ってそんな事を言うような人はいないでしょう
681 名前：仕様書無しさん mailto:sage [2008/12/26(金) 15:35:56 ]: 仕様を紙に起こしたりされると拒絶するかバカ正直に実装する。
せめてテストで確認しようと項目を挙げるとアホかと罵る。
要するに何の制約もされずに気ままにコーディングして自己満足したいだけ。
自分仕様で実装する。
そして出来上がってから仕様が固まると我が物顔で胸張って言う。
｢すごい手戻りですね｣
682 名前：仕様書無しさん mailto:sage [2008/12/26(金) 19:18:32 ]: ドキュメントも重要。
テストも重要。
683 名前：仕様書無しさん mailto:sage [2008/12/26(金) 19:27:06 ]: 仕様書がしっかりしてりゃＰＧ側はなんの問題もないけどね
でも、作ってみなきゃ矛盾が見えないってのもわからなくもない
でも、それを全部に責任にしようとするから戦争がおこる
仕様書ないのにこっちにテスト仕様書作らせようとか
結構キレるのわかる気がする
684 名前：仕様書無しさん mailto:sage [2008/12/26(金) 19:29:29 ]: ユニットテストで横に全画面のコントロール
縦にチェック項目５０個ぐらいで１００００個超えるテスト作って
とても流用できないような表を作るのが俺の趣味
貼り付けて仕様書完成なんて絶対にさせない
685 名前：仕様書無しさん mailto:sage [2008/12/26(金) 21:18:16 ]: テストの対象はコードじゃなくて仕様や要件だということ。
686 名前：仕様書無しさん mailto:sage [2008/12/26(金) 21:50:20 ]: 単体テストと結合テスト、機能テストは目的が違う。
687 名前：仕様書無しさん mailto:sage [2008/12/26(金) 21:59:00 ]: >>685
仕様書に全コントロールの仕様が書いてあればそれも可能だけどねｗ
全角、半角、ひらがな、カタカナ、英数、少数、文字数、
最小、最大、タブ、エラーメッセージ、補正、・・・
全部かけるもんなら書いてみればいい
688 名前：仕様書無しさん mailto:sage [2008/12/26(金) 22:18:10 ]: >>686
違うのは範囲だよ。
テストの目的はひとつ。
単体→結合→機能と分けるとするならば、
それらは通過点。

>>687
コーディングが終わる時点で仕様に抜けがあるようでは仕様書をまとめる人間もプログラマも失格。
その先を急ぐばかりに後に時間とカネを浪費する。
689 名前：仕様書無しさん mailto:sage [2008/12/27(土) 00:16:34 ]: >>688
ちょっと俺んとこの職場きて担当者に言ってやってくれ
690 名前：仕様書無しさん mailto:sage [2008/12/28(日) 21:37:14 ]: ちょっとスレ違いだけど、コードレビューしてたらPMが乱入してきて、
どうせテストするんだからそんな無駄なことすんな
馬鹿な働き者は何もしない馬鹿より害が大きいんだぜ
って妨害しやがった。

ちなみにそいつはプロジェクトも末期になってから思いつきで
仕様変更して、現場を混乱させる悪癖があることで有名だ。
691 名前：仕様書無しさん mailto:sage [2008/12/28(日) 21:38:16 ]: killしろ
692 名前：仕様書無しさん mailto:sage [2008/12/29(月) 14:30:25 ]: テストってのは、その前にちゃんとしたクオリティで作ったものが、
ちゃんと「動くこと」を確認するステージであって、
とにかく形だけそれっぽいものを作って、テストでちゃんと動かないところを
洗い出すってのは間違いだと思うんだ。

うちの会社、後者のやり方だから、もういや。
693 名前：仕様書無しさん mailto:sage [2008/12/29(月) 20:34:16 ]: テスト自体にもいろいろステージがあると思うんだが

まあシステムテストの段階で単体テストやってるようだと大問題だが
694 名前：仕様書無しさん mailto:sage [2008/12/30(火) 19:05:29 ]: ステージが限量されてないのが前提で

>とにかく形だけそれっぽいものを作って
スタブのことね
>テストでちゃんと動かないところを
>洗い出すってのは間違いだと思うんだ。
TDD否定ですか？
>うちの会社、後者のやり方だから
TDDを実践してる会社か、なかなかいい所じゃないの？
695 名前：仕様書無しさん mailto:sage [2008/12/30(火) 19:18:24 ]: おまい、TDD言いたいだけちゃうんかと…
696 名前：仕様書無しさん mailto:sage [2008/12/30(火) 22:58:40 ]: TDDってなんですか？
もちろんググったりなんかしません
697 名前：仕様書無しさん mailto:sage [2008/12/30(火) 23:08:14 ]: Tokyo
Disney
Destroyer
698 名前：仕様書無しさん mailto:sage [2008/12/31(水) 01:21:19 ]: >>697
通報しました
699 名前：仕様書無しさん mailto:sage [2008/12/31(水) 11:02:57 ]: >>696
逆DDT
700 名前：仕様書無しさん mailto:sage [2009/01/01(木) 20:22:50 ]: >>694
お前全然わかってないんだな

いや待てよ、単にネタなのか
こりゃ騙されたなｗ
701 名前：仕様書無しさん mailto:sage [2009/01/02(金) 09:56:59 ]: なにがわかってないのか詳しく
702 名前：仕様書無しさん [2009/01/02(金) 11:15:56 ]: ユニットテストって明らかに成り立つ場合でもいちいちテストケースって書かなくちゃダメなの？たとえば、引数に範囲外の数値を入れたらXXXというエラーコード返すとか。関数にそういうif文あるんだから返すに決まってると思うんだが・・・やっぱり明示的に書きます？
703 名前：仕様書無しさん mailto:sage [2009/01/02(金) 12:05:40 ]: そういうコードができてから書くテストってあまり書く気がしないんだよね
なんというか事務的処理のような面倒臭さがある
それならば逆転の発想でコード書く前にテストを書けとか言われてるけどそれもそれで面倒だし
704 名前：仕様書無しさん mailto:sage [2009/01/02(金) 12:30:26 ]: >>701
おれの気持ち

ってかこの業界、相手の気持ちなんて考えたらやってられねー
705 名前：仕様書無しさん [2009/01/02(金) 13:15:58 ]: >>703
やっぱりすごく事務的だね。。。
実際はエラーコード返すif文が本当に書かれてるかテストで確かめるってのが正当な方法なんだよなあ。
706 名前：仕様書無しさん mailto:sage [2009/01/02(金) 18:14:48 ]: ブラックボックス
707 名前：仕様書無しさん mailto:sage [2009/01/02(金) 20:15:01 ]: Javadoc等の為に、コメントに仕様を丁寧に記述して…

あぁぁ・・・　ああぁぁぁああーーー…

うわぁぁああぁぁーーっっ！！！
708 名前：仕様書無しさん mailto:sage [2009/01/03(土) 11:47:38 ]: >>707
javadocってそんな分かりやすいか？
（まあ、分かりやすいかは記述している内容次第、といわれればそれまでだけど）

昔のVBなんかで使ったhotdogを思い出してしょうがない・・・

って、>>707が叫んだのは1/02だからか？？
709 名前：仕様書無しさん mailto:sage [2009/01/03(土) 12:19:05 ]: >>708
＞javadocってそんな分かりやすいか？

規定のフォーマットで書けば、規定の出力が出てくれるのでｳﾘｼﾞﾅﾙなものよりかは
分かりやすい。
710 名前：仕様書無しさん mailto:sage [2009/01/03(土) 18:38:22 ]: 今行ってる現場のPLがなんか勘違いしている。
コーディング8割完了って報告したら、「じゃあ単体試験は5割ぐらい完了ってことかな？」ってさ・・・
コーディング中のTry&Errorはテストではないですよ？
こいつ、40近くにもなって何を言ってるんだろうって思いました。
711 名前：仕様書無しさん mailto:sage [2009/01/03(土) 18:46:17 ]: >>710
>コーディング中のTry&Errorはテストではないですよ
至極まっとうじゃねーかw
712 名前：仕様書無しさん mailto:sage [2009/01/03(土) 19:19:25 ]: コーディング完了＝単体試験完了だってさ
713 名前：仕様書無しさん mailto:sage [2009/01/03(土) 19:36:47 ]: >>712
絶対確実に100%達成は不可能だが、TDDしていれば
単体試験完了＝コーディング完了に限りなく近づくだろ

抜けたところは、結合までにテストケース追加すれば
いいだけだし。

お前が糞だってことをきちんと理解しろ、この豚野郎が
714 名前：仕様書無しさん [2009/01/04(日) 01:07:01 ]: テストの本で初心者に一番良い本教えてください
715 名前：仕様書無しさん mailto:sage [2009/01/04(日) 19:39:51 ]: >>702
書くべきだろ
実は不等号の方向間違えててっていうのがチェックできないじゃん
っていうか俺それ何度もやってるしｗ

テストデータを作るのも困難なんだよね
でも、そのデータ作ってるうちに別の問題も発覚したりするから
あながちなめたものでもないな
716 名前：仕様書無しさん mailto:sage [2009/01/04(日) 20:09:58 ]: テスト期間はほんと面白くないね。
これを楽しくするアイデアを下さいな。
717 名前：仕様書無しさん mailto:sage [2009/01/04(日) 20:22:55 ]: >>716
レアバグを発見したらみんなで胴上げ
経費で昼飯代を出す（カレー限定）
とか特典をつける
718 名前：仕様書無しさん mailto:sage [2009/01/05(月) 06:03:24 ]: エロ掲示板にあるような、殿堂入り機能付き掲示板でバグを晒すとか。
殿堂入りしたバグ発見者に何か褒美やるとかw
719 名前：仕様書無しさん [2009/01/06(火) 08:40:35 ]: 茶番劇にまた付き合わされる俺の身にもなれ
720 名前：仕様書無しさん [2009/01/06(火) 10:35:40 ]: >710
うちの40代園児ニアもまさにそれ。

何度テストの重要性とか説いても「そんなの実機で動かせばいーじゃん？」であっさり却下。
ユニットテストという単語すら知らない癖に「これ使ったらソフトの品質が上がるんだぜ！セミナーの人が言ってた。」という理由だけで
某社のテストフレームワークを買おうとしているうちの上司。。。

最近さっさとこいつら見限ったほうがいいかもと思いつつある。
721 名前：仕様書無しさん mailto:sage [2009/01/06(火) 15:26:04 ]: >>720
>「これ使ったらソフトの品質が上がるんだぜ！セミナーの人が言ってた。」
権威に弱いだけな性向が透けて見えるね
なんという騙されやすい人間
722 名前：仕様書無しさん mailto:sage [2009/01/06(火) 23:54:48 ]: >>720
お前はそんな糞上司使われて
成果も出せない。結局調子の言い権威的な
セミナーのおっさんにすらまける糞野郎ってことだろｗ

上司が上司なら部下も糞だｗもっと自分がアホで
糞だということを自覚しろｗ
723 名前：仕様書無しさん mailto:sage [2009/01/11(日) 17:16:32 ]: >>716
自分が作ったものを自分でテストするとひじょーにつまらんし、モチベーションが全く上がらん
人が作ったものを、色んなパターンで試験してバグ票をバシバシ発行すると、それなりに楽しめるぞ
724 名前：仕様書無しさん mailto:sage [2009/01/11(日) 22:06:43 ]: みんなどんなソフトに関わってるの？
俺はWebブラウザとかだけど
725 名前：仕様書無しさん mailto:sage [2009/01/11(日) 22:23:44 ]: 家電全般
726 名前：仕様書無しさん mailto:sage [2009/01/11(日) 22:37:30 ]: POSあぷりとか
727 名前：仕様書無しさん mailto:sage [2009/01/12(月) 00:25:55 ]: Webアプリ関係と
FAX関係（ファーム寄りじゃなくて通信より）
あとはDBクライアントアプリ（VB）とかをちょぼちょぼ
728 名前：仕様書無しさん mailto:sage [2009/01/24(土) 15:12:41 ]: スパムジェネレータはwebアプリって言ってもいいのかなぁ
729 名前：仕様書無しさん mailto:sage [2009/11/10(火) 11:16:51 BE:2734790786-2BP(0)]: テスト
730 名前：仕様書無しさん mailto:sage [2010/05/08(土) 21:43:30 ]: ユニットテストで中途半端なテスト書いて満足してるゴミは死ね
731 名前：仕様書無しさん mailto:sage [2010/05/09(日) 08:50:02 ]: たしかに、どんな簡単なコード(たった一行)でも
そこから予想もしなかった事態が引き起こされることはある(あった)
テストを怠るとえらい目にあう
732 名前：仕様書無しさん [2010/06/03(木) 00:08:09 ]: テストは開発だね。

もうテストなしの開発なんて考えられないよ。
733 名前：仕様書無しさん [2010/06/06(日) 22:02:27 ]: 半端にプログラミングが上手くなるとテストサボるようになるな。
734 名前：仕様書無しさん mailto:sage [2010/06/06(日) 23:04:51 ]: 単体テストは手間がかかる上に、楽しくないんだよな

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef