テストを軽視する者ども

ニートにバグ１個３００円でやらせろ

>>367
> 「全く想定していない」・・・要求定義者や分析・設計者のミスをテストで
> カバーできないってこと。間違った仕様を完璧にコーディングしても
> それは、バグ。

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

これであなたもユニットテストの重要性を理解したと思います。

>>1
おれが言いたかったことを、代弁してくれて
心からありがとう( ´v｀)

>>551-552
>>550 はコピペだよ

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

テストでは信頼性は旦保できない為、極度に
信頼性が求められるシステムでは、テストをしない開発手法もある。

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

>>9
それ、ユニットテストじゃん。ユニットテストは普通テスターがやるもの
じゃないっしょ。ユニットテストは、設計レベルの確認でしょ。そのやり方
は、開発規模が大きくなった場合は、現実的には無理だと思うぞ。

顧客の要求レベルのテスト、すなわち、システムテスト（ホワイトボック
ステスト）が、最重要でしょ。

サブシステムやコンポーネントやレイヤーを合わせてテストするのは、普通、結合テストと言います。

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

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

【審議中】
　　　 ∧,,∧　 ∧,,∧
　∧ (´・ω・) (・ω・｀) ∧∧
(　´・ω)　Ｕ) ( つと ﾉ(ω・｀ )
｜　Ｕ (　　´・) (・｀　　)　と ﾉ
　ｕ-ｕ （l 　　 ) (　　　ﾉu-ｕ
　　　　 `ｕ-ｕ’.　`ｕ-u’

>>189
その仕様書には、どんなことが書いてあるの？

そして、その書いてあることが正しいかどうかは
誰が判断できるの？

この二つの質問に答えることができれば、
おのずとどうやるかがわかると思う。

>>66
>>42とか

> クライアントのためにならない
ここちょっと違くね？
時間を金で買うクライアントもいるよ

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

>>397
＞想定外の欠陥は許されるが、想定内の欠陥はダメなの。

現実は想定外の欠陥でも許さない人間が大半だがな。　相乗りしている他システムが
異様にリソース使いまくって、それに巻き込まれて不具合起きて、それでも不具合が
おきない様にしろと言われかけたときは頭抱えたよ、、、

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

今行ってる現場のPLがなんか勘違いしている。
コーディング8割完了って報告したら、「じゃあ単体試験は5割ぐらい完了ってことかな？」ってさ・・・
コーディング中のTry&Errorはテストではないですよ？
こいつ、40近くにもなって何を言ってるんだろうって思いました。

>>235
マ辞めちまえ。おまい迷惑。

>>618
俺の前の会社は「テスト検査書なんかいらないんだ！テストというものはどんどん触るのが仕事なんだ！」
という社長の方針でレビュー以前にテスト検査書が存在しなかったけどね。

まあ、結局倒産して社長一家は行方不明だがｗ

>>424
キャバじゃないし、今日でもなかった・・・

だれかおれの視力、聴力、記憶力をテストしてくれ

日本語で桶

テストを重視して、ただでさえ疲れ切った技術者にさらに仕事を
積む。そーやって、現場をさらに混乱に陥れる。

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

技術者は、常に理屈で何とかなると思っている、何か良い手法があると
考えている。ただ、その手法を実行する人の振る舞いについては関心がない。

その手続きを持つ関数の単体テスト

>>1 はプログラマじゃないことは確かだな。

土方だったら納品オサラバだし、綺麗事で飯食えるかっての。
責任ある高度な仕事を要求するなら、それなりの金払え。

>>716
レアバグを発見したらみんなで胴上げ
経費で昼飯代を出す（カレー限定）
とか特典をつける

>>611-612
これか・・・すげぇな。アップデート項目チェックとかしてないんだろうか？
ゲーム開発って楽そう。

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

>■一部アイテムのアイコングラフィックが変更されたお知らせに
>　おいて、実装されていないアイテムが一覧に含まれておりました。
>　脳汁／狡賢い脳汁／幸せの人参汁／まろやかな鳥汁／濁った血汁

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

MTは知らんｗ

>>82
数百人もいない。100人強だな。そして、全員が精鋭ではない。

あと、実際には分割される。協力企業もいる。
協力企業に開発プロセスを強要できない。請負だからね。

ユニットテストは、CppUnit, JUnitとか単体テストを自動的に行う
あれのことを言っていると思ってるのだが。
単なる単体テストの事なら、今まで俺が書いた事は忘れてくれ。
単体テストは必須だ。

テストを自動的に行うために、テスト自動化用のコードを書いて
メンテナンスを行うのはコストが高くて現実的でないというのが
俺の意見だ。
工数のかかる言語、たとえば、C++/CLIで書いたコードを
工数のかからない言語、VBでテストを書くならまだ納得だ。
テスト用のコードをいかに少ない工数で書くかが重要だと思う。

ブラックボックスとホワイトボックスの違い？

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

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

>>48
頭冷やせ。
ソフトウェア開発は、機械だけ相手にしていたら良いわけではない。
金を払う顧客、それを使うユーザー、他人の作ったコンポーネント。

厳密さを求めるがゆえに大切なものを排除してはいけない。
曖昧なもの、変わるものをコントロールする事の方が重要だ。

ユニットテストはゴールではない。
顧客の要求を満たすことがゴールだ。

日本人はすぐに問題個所を血祭りにあげて「部分最適化」を試みる。
本当に必要なのは、開発プロセス全般の「全体最適化」だ。
その全体に影響を及ぼすのが「要件」じゃないのか？

ユニットテストだけをパーフェクトにしても、大した成果は出ないと
思うがな。

>>37
「ちゃんと動くプログラム」と「テスト」と「仕様書」をなぜに比べる？
一蓮托生だろ。
テストも出来ていない腐った仕様のプログラムは、ちゃんと動いているとは
言えない。

>>362
ど素人さんですか？
今まで何やってたの？

そういう情報を後出ししてるようだからダメなんだよ

>>32
うちは、QTPを単体テストで使用している。
開発の初期からテストを意識している。
つまり、テストはテスターだけの仕事じゃない。

設計者は、単体テストでテスト自動化を導入できるようにはじめから
設計する。目標は、すべてのテストの自動化と管理だ。
テストは設計の一部だ。

いわゆるユニットテストでは、カバレッジを評価できないし、
達成度も不明確だ。

うちは、ユニットテストからすべてQC/QTPで一元管理している。
そして、統計を取ってシステムやチームの弱点を洗い出す。

QTPは単なるツール。どう使うかは使う側による。

>>369
テストの際に出てくる不具合報告を眺めてるだけじゃ完成しないがなw

テストに入ってからが本当のコーディング作業が始まると思わなきゃ上手く行かない。

必要なときにテスト用の機材がないわ
テストしたいのに場所も時間も制限付けられるわ
テストゼロで客先納入に向かう羽目になりながら
よく不具合が出なかったなと思う

その後は仕様追加だの仕様変更だのバタバタバタバタ慌ただしく来て
テストも糞もないほど杜撰で、トラブル頻発したが

>>88
C0カバレッジ100%は必須なの？必須じゃないの？

単体テストと結合テスト、機能テストは目的が違う。

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

ついにマ板にも夏が来たか・・・

ST終わって単体バグ出るとか杜撰すぎて笑えない

テスト工数が軽んじられる傾向にあるのは確かだな。
テストにかかる時間と手間がちゃんと工数に考慮されたら、
そして経験と勘に頼るような人任せなやり方が改善されて、
テスト手法がちゃんと確立されて標準化されたら、みんな
定時で帰れるし、トラブルも減って、もう少しみんながハッ
ピーになれると思うんだけど。
でも現実は、製造とテストは一緒くたに丸投げされて、やら
される方もただ盲目的に「テストOK」の印をつけることだけ
が目的になっている。自分で製造もやってるから隙もできる。
これじゃぁ、質があがるわけない。せめて製造とテストは実施
者を分けるべきじゃないかと思う。

>>107
>テストコードは、プログラマが書くが、テストはテスターがやっている。
なぁ、これテストのプロなのか？

>・・・つーかうちの会社の特殊事情聞いてどうするんだ？一般的だとは
>言ってないぞ。
一般論としてユニットテストを否定してるんだろ？だからどうやってるのか聞いてるんだけど。

>>108
>ユニットテストとシステムテストはどちらが大切だと思うんだ？
どっちも大事に決まってるじゃん。
従来のウォーターフォール的なテストのやり方だと工数が膨らむから、ユニットテストに
力を入れようぜって話だ。

つか、はっきり言って、お前がPMだとしたら、その下でできた1000万行のシステムなんか
受け入れたくないわ。

>>58とかも

>>256

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

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

■再利用可能なコンポーネント
レイヤーの低い位置にいる、再利用可能なコンポーネントは、
不具合が全体に波及するので、ユニットテストからコツコツ積み上げる。
ユニットテストは低レベルのコンポーネント（ライブラリ）開発で役に立つ。

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

ImageGear許すマジ

おまえもな

信頼性に興味がないのでしょう。

>>388
ソフトウェアの信頼性を定義してみな