【テスト】品質管理について語ろう【QA】

コンピュータソフトウェアを開発する上で欠かせない各種試験・テストを
専門的に語りましょう。

あと、試験をする上で使用するツールについての情報も交換しましょう。
例えば、Test Director、Test Complete、PVCS、ClearQuest etc.

SPI

このすれは目立関係者の自作自演になる予感

４ゲット！

シリコンバレーで働いてるのだけれど、こちらではある程度の規模の
ソフトウェア会社ならば必ず品質管理部があって、開発とは独立して
ソフトウェアのテストをしている。

日本の場合はどうなのよ。

>>5
程度の規模のソフトウェア会社ならば開発とは独立してテストしてる。

>>5
2chって外国からのカキコできないんじゃなかったっけ？

>>6
それならこちらと同じですね。

昔居た会社で、開発チームがプログラムを書いた後、同じチームがシステムテストまでの
試験仕様書を書いてテストしたことを思い出してみた。

>>7
以前は出来なかったのだけれど、今日試してみたら書き込めました。

俺はテストチームをテストするためにワザとバグを混入する

1匹いれば30匹の原則に従って、開発側で
あと29個バグを検出してくださいの法則発動

>>8
>昔居た会社で、開発チームがプログラムを書いた後、同じチームがシステムテストまでの
>試験仕様書を書いてテストしたことを思い出してみた。
「6のような開発組織があるはず無い」とは言わないが、
俺の知る限り、貴方の記憶の状況から全然変化が無い。
品質管理と名のつく部署は存在するところもあるが、その部署が試験を行うのは見たこと無い
品質管理部署がすることは、バグ数の定性定量と、統計的時系列的な分析だけだ

あちらさんとは、テストの考え方が違うんだろうね。

日本では、テストする＝動くかどうか確認する、ってのが定義だと思う。
だから「使えないやつ」がテスタにまわされるんじゃないかな。

アメリカではQAエンジニアはプログラマーに比べたら給料は1-2割ほど安いようだ。

でも開発とは独立したQAの部署があるので、プログラマのー使えないやつがテストに回されるということはないし、
シニアQAエンジニアやマネージャーは相当な額の給料をもらっているようなので、QAは開発に比べて地位が低い
ということはそれほどなさそうです。

>>13
バグ発見。

>>13
むしろ年功序列の日本のほうが、給料差別はないんだな。
逆に専門卒のバリバリPGより、文系大卒のクズテスタのほうが給料が上というのもしばしば。

どうにも納得がいかないね。

>>15
アメリカでも昔からある企業は年功序列、学歴優先だよ。
ただ、優秀な奴が、どんどんベンチャーに逝ってしまったので
学歴優先の企業の大部分が淘汰されてしまい、IBMやHPのように
何とか行き残ったエスタブリッシュメントも実力優先に
移行せざるを得なくなったということだろう。

つまり、>>15のような天才プログラマーが、ベンチャー企業に
移籍して大企業を追い詰めれば、日本も変わるってことだな。

テストって品質管理じゃないだろ?
どっちかっつーと検証とか保証だろ?

ソフトウエアでいう品質管理って実際どーゆー活動なの?
バージョン管理?(w

>>17
知らねぇのか。何が(ｗだ。
ttp://village.infoweb.ne.jp/~fwgf2942/process/Proc.QA&QM.html

>知らねぇのか
うん、知らねぇ(w

>適当な品質特性について目標を設定
>結果を目標と比べて、達成したのかどうかを判断
> - 目標に達していなければ、プロセスを調整して再び取り組む
> - 目標に達していれば、そのプロセスを使用する

やっぱテストとかんけーない(w

品質を計測するためにテストが存在するのだ
それ以外のテストと呼ばれているのは単なる動作確認だろ

この業界はものづくりしてるって自覚が無いから、無理。

テストは、バグを見つけるためのものだよ。
バグが見つからなかったら失敗のつもりでやんないと。

保証をとるために、とか、動作確認のために、とか言ってると
テストを通すこと、項目を消化することが目的になってしまう。
そうすると無意識的にOKになりやすい手順を選択したりする。
（意図的に避けるヤツもいるしな）

それじゃあよい品質にはならない。

>>22

ソフトウェアの仕様書に定義されていることを正確に反映したテスト仕様書を書き、
それにしたがって作られたテスト項目を作れば、そのテスト項目を消化するだけで、
必要な部分のテストを実施できるはず。

つまり、定義されている機能が、定義されているとおりに動作するかをテストする。


ま、SW仕様書がざっくりとに書かれていたら、テストもまたざっくりになるのだが。

>>23
本気で言ってるのかな。。。

>>24
上で書いたことは建前です。

RequisiteProというツールで、仕様-試験マトリックスを作って、すべての仕様に対して試験項目を作成し、
なおかつ、試験項目作成後に仕様が変更した場合、どの試験項目の見直しが必要かをマトリックスから
割り出し、必要に応じて試験項目をアップデートするということをやっているのですが...

まだ試行錯誤の状態なので、うまくいっているのかどうかよくわからないんだな。

>>24
方法論的には間違っていないと思うのだけれど、どう思う？

>>25
「仕様-試験マトリクス」なるものを作成するための手法はなんですか？
同値分割？原因結果グラフ？

>>26
ある意味、原因結果グラフといえるのかも。


そのツールに、エクセルシートのようなマトリックスを作る機能があって、
各詳細設計の項目にIDを振り、それらをテストする項目にもIDを振った後、
そのマトリックスの行側にに設計項目、列側にテスト項目を置き、
行と列の交わったところで、設計項目からテスト項目へリンクさせる。
リンクされたセルは矢印のアイコンが表示される。

この矢印の意味は、そのテスト項目はそのリンク元の設計項目をテストする
ということ。

リンクが張られた後に設計項目の内容が変更されたら、その矢印が別の
アイコンになって、そのテスト項目が書かれたときに使用された設計項目が
変更されたことを示すので、どのテスト項目が、設計項目の変更を反映させる
かどうかの検討を要するか、が判断が出来ます。


あと、そのテスト項目を作成するときは、どの詳細設計の項目をテストするのかが
事前にはっきりわかっていなければなりません。

そして、ひとつの設計項目に対してひとつ以上のテスト項目が存在し、その中で
その設計項目をテストするのに適した手法のテスト項目(例えば.同値分割)を作成
することになります。

>>25
>方法論的には間違っていないと思うのだけれど、どう思う？

23だけに突っ込むと、間違ってないけど、十分でないってところ。

続きを読む限りでは、そんなの釈迦に説法な人みたいだけど
仕様を満たすってのは最低限であって「必要な部分のテストができる」
ってのは言い過ぎだと思ったわけです。

もちろん、実際はその最低限レベルですらままならないのが現状ですな。

俺の知ってるところでもツールで強制的に抽出してたりしたけど、
1000のオーダが当たり前で、デスマるわりにテストが雑になって
逆に品質が悪くなったりしたりしてたから、ここらへん難しいですよね。

あ、そこを議論するスレなのか。。。

>>28
なるほどです。

ソフトウェアのどの部分ををどれだけテストしたらいいのか、定量的に把握することが出来ないのが難しいです。
ソフトウェアをリリースした後、お客様からのフィードバックの数と問題の程度で、どの部分がどの程度テストが
不足していたと分かることが多いですね。いわゆるCAPAです。

考え出すと奥が深い分野ですね。

とりあえずはJUnitを使え

テスト駆動開発で行け！

>>1はケントベックのテスト駆動開発入門を読むべきだ。

テスト駆動開発入門
ケント ベック (著), Kent Beck (原著), 長瀬 嘉秀 (翻訳), テクノロジックアート (翻訳)
http://www.amazon.co.jp/exec/obidos/ASIN/4894717115


「テスト駆動開発」はプログラマのストレスを軽減するか？
http://www.atmarkit.co.jp/fdotnet/special/tdd/tdd_01.html
株式会社ピーデー
川俣　晶(VB信者のデブ社長)
2003/11/08

>「テスト駆動開発」はプログラマのストレスを軽減するか？

本の内容は知らんが、この言葉、質問文と認識する！！！

ストレスは減るよ。もちろん減るさ、バグが減るんだから。
開発者がテスト駆動に慣れれば、もっと減る。
もっと開発効率は良くなるよ。 絶対に。
テスト駆動がこんなもので済ますものかよ。

ttp://images-jp.amazon.com/images/P/4797323361.09.LZZZZZZZ.jpg
これ読め。マジで。
ちと高いが。

>>33
アジャイルなんて釣りだろ！もう下火だけどな。

あのメンツなら、どんなやり方でもそこそこうまくいくだろ。

っつーか、テストは設計なんですよ

>>31
興味深い内容ですが、開発者向けですな、プログラマー板だから当たり前なのだが。
テスト/試験が本職の拙者はコーディングをする立場には無いので、関わりたくても
関われないエリアです。

>>31にあるような手法で、QAにリリースされるソフトウェア中のバグが減ることは大歓迎です。

っつーか、テストは設計なんですよ

>>35 と　>>37
含蓄深いが、もうすこし語ってくれ。

機能を定義する方法として、自然言語を使用せずに、
テストプログラム（あるいはテスト環境）によって定義するという手法なのか？
そのテストプログラム（あるいはテスト環境）の全てにパスする（あるいは失敗する）プログラムを
開発対象として定義するのか？

>テストプログラム（あるいはテスト環境）によって定義するという手法なのか？

テストファーストとか聞いたことないんか？
ttp://www.google.com/search?q=%83e%83X%83g%83t%83@%81%5B%83X%83g+or+%83e%83X%83g%8B%EC%93%AE&num=20&ie=Shift_JIS&oe=UTF-8&hl=ja&lr=lang_ja&btnG=Google+%8C%9F%8D%F5

ttp://images-jp.amazon.com/images/P/4797323361.09.LZZZZZZZ.jpg
これ読め。マジで。
ちと高いが。

とりあえずさ、
Q A に デ バ ッ グ さ せ る の や め て く れ な い ？
リリース前ならこまごまと手伝ってやってもいいんだけど。

>>41
デバッグする時間ないんだから仕方ないじゃん
（↑SI屋さんの今の現実）

>Q A に デ バ ッ グ

ぢゃ、なんかしらんけど動作がおかしい、とかって禅問答みたいなバグ票直れYo!

> 42
結局、単体テストをしっかりした方が時間の節約にならんか？

テスト実施
　↓↑
ストレス増加

の負のフィードバックループ
の事か？

テストの自動化について学びたいんだが、何か
良書はないだろうか。
特にGUIの自動テストってどうやっていいのかわからん。

>>46
Webだったら、WSHを使ってテストをした事がある。
WSHでモジュール作っておいて、外部XMLを読み込んで画面遷移テストとか行える。
かなり便利だよ。

あんまりxUnitを過信せずに、自分なりの要領でやるとすっきりする。
半年ぐらいの小さい案件なら、常に２人ぐらいテスト専用の人をつけておいて
その人にひたすら叩かせるのが経験上良い。

最近思うんだが、ソースに変更履歴うざい。
VSSとかCVSとかSubversionとかでなんとかならんのかね？

>>46
処理系によるだろうけど、GUIの自動テストにはイベントを擬似的に発生させるか、
予めテスト用のインターフェイスを仕込んでおくかの何れかが必要になってくるね。
コスト的には>>48さんが書いている通りひたすら叩いたほうが安くあがりそう。

>イベントを擬似的に発生させる

以外はダメだろ(w

PDCAについて調べてみました。現在の自分の理解を書くので、何が理解できていないのか教えてください。

１．PDCAサイクルは業種に関わらず、経営レベルから現場レベルまで適用可能な
　　継続的改善を推進するためのマネジメント手法である。そのプロセスは、
　　　　Plan（目標設定）→→→→→Do（実施）
　　　　　↑　　　　　　　　　　　　　　　　↓
　　　　Action（変更点の特定）←←Check（評価）
　　から成る。「Plan→Do」のみから成る原始的な手法と比較すると、
　　１．「Check→Action」があることで、継続可能なサイクルとなっている
　　２．「Check→Action」があることで、目標からの乖離を抑制する
　　などの特長がある。

２．　継続的改善と聞くと、なんとなく製品品質の向上や業務改善が目的に思えるかもしれないが、それは誤解。
　　PDCAサイクルは生産性の向上にも大きく貢献する。
　　　「生産性」というものは「目標の達成率」によって計られる。（これに異論は無いと思う。）
　　　PDCAサイクルを導入することにより、「生産能力が目標に沿わない行動に『消費』されずに、
　　目標に沿った行動にだけ『活用』されるようになる」。つまり、生産性が増えるのである。
　　　故に、PDCAサイクルは「品質」と「生産性」を同時に向上させることが可能な手法なのである。
　　50年を経てもPDCAサイクルが滅びない理由が、ここにある。

３．　テスト駆動開発（XPでは、テストファーストのプラクティスのみを指す）は、
　　PDCAサイクルを明らかに実現している。
　　　　Plan（テスト計画、テスト実装）→→→Do（テスト対象コードの実装）
　　　　　↑　　　　　　　　　　　　　　　　　　　　　↓
　　　　Action（変更すべき点の明確化）←←Check（自動テストの実行）
　　　他の業種への適用と比較すると、特に「Check」工程が自動化されていることが
　　大きく評価できる点である。（昼夜を問わず、定期的な自動実行さえ可能である！）
　　　結果として、極めて短い時間でPDCAサイクルを繰り返し適用することが可能であり、
　　これが「品質」と「生産性」の大幅な向上に貢献することは疑うべくもない。

PDCAをわざわざ調べたってことは知らなかったのか?
社会人の基本だろうが

[PDCA]

Personal Digital Cellular Association の事。

[ISO]

オレは今朝テレビで死んだ息子の死を悲しむオヤジ見ちゃったから
とても>>52みたいなこと書けん。

>>51
正しいが。ソフト業の場合、他の製造業と比べて少し複雑で。
言葉の定義からして共通認識が形成されていない。
　目標
目標とは何か？。納期に間に合う事か？売上か？顧客満足度か？
　生産性
単純に「売上と納期とコスト」から計算できるものなのか？
生産性向上という錦の御旗の下にいろいろな施策は行われるが、
果して「時間を短くする事」であるのか「コストを下げる事」であるのか
「品質を向上させること」であるのかを明言した文書は見た事が無い
　品質
品質とは何か？バグが無いことか？保守性の高い事か？操作性の良い事か？etc...
いったい誰にとっての品質なのか？

�@やばい奴の設計文書とソースをチェックする
�A訂正事項をテキストに箇条書きする
�BMailで送付する
�C修正したものに対して�@をおこなう

このような地道な作業もまたPDCA、しかしPDCAというと
何故か理論を展開したがる者が多い。
QC活動などは現場での地味な作業の積重ねの方が実利がある。

テスト段階に移行してから大量のBUGをみつけても仕方ない。そんだけ。

>地味な作業の積重ね
プロだねぇ。

>>51
３．において「明らかに実現している」や「疑うべくもない」に危うさを感じる。

学生時代に望ましい結果になるよう実験やレポート作成をやっていた連中の危うさだ。
開発の現場において「作業者の持論 ＞ 製品・業務フローの実際」で問題を発生させ
自身では問題解決できない状態に陥っている連中を多数みてきた。
もっとも、それで処罰された奴はみたことがないがな。

>>58
大丈夫。効果的な部分にしか使っていないから。

たとえば複雑な判定関数を書くときとか。
たとえば確実に動作する必要がある共通関数とか。

前もってテスト書いておくと、楽だよー。

51がきちんと適切な場所に適切な手法を用いてるんだとすれば、
58の指摘は誤ってというよりちょっと視点が違ったってことになるな。

>>51
確かにきちんと使ってれば「疑うべくもない」と言えるかも知れないが、
各手法には必ず度を過ぎて適応した場合の落とし穴があるんだから、
条件を限定しないまま完全であるかのような言い方をしちゃいけないよ。
「この手法は」「特定の条件下では」「品質と生産性を向上できる」
という三つの要素は三つで一つなんだ。
君がプロジェクトを管理する人間になって何らかの手法を取り入れ
実際に素晴らしい効果を発揮して、
部下に対してどれか一つが欠けた話の仕方をしてたとすると、
中身を正確に理解しないまま「なるほど効果的だ！」と思い込む人間が出来かねない。

この手法はこの条件下でしか使ってはならない
　→その結果どうなるの？→俺はこれで上手くいったんだから黙ってやれ
条件をこう限定すれば生産性を向上できる
　→何らかの手法での話じゃないの？→俺はこれで上手くいったんだから黙ってやれ
この手法は生産性を向上できるからあちこちに盛り込め
　→適応個所を限定した方がいいんじゃないの？→俺はこれで上手くいったんだから黙ってやれ

ちょっと長々突っ込みすぎたが、
こないだまでこういう考え方を押し付けてくるお客さんと仕事してたからさ、
ちょっと気になったんだ。
考え方ってのは伝播するらしくて、そのお客さんの会社には
同じような「欠落型論理」の人が多かったよ。
俺みたいにあんまり長々言っても鬱陶しいと思われるだけかも知れないけど、
必要なところは簡潔に述べておいた方がいいね。

ノウハウは中々教えてくれません。

昨日はコーディングレビューで「ここで使用しているライブラリがどんな
動作するかわからないので実行環境をもらってから動作確認しながら
完全な実装にします。」っていったらメタメタに怒られた。テスト始まって
からそんな修正は許されないって。

動作確認とテストが別になると幸せだなあ

うまく動くかどうかわからんソースをレビューに出して
「今はわからんけど，結果オーライだから」みたいな事言ったら
怒られるに決まってるじゃないか

>>63
言われてみればその通りだなあ。
レビューやらされるタイミング自体間違ってる気がするなあ。
こっちはやる前に実行環境無いから未完全って前もっていっといた
んだけど、レビューの相手はそのこと知らなかったからなあ。でも、
実行環境ないってこと知ってるはずだし、不完全でも許してもらえる
と思ったけど、俺甘かったよ。

ちなみに実行環境がないというのは本番環境がもらえないという意味
でなくて、ＶＳをインストールさせてもらえないってことです。

それは実行環境じゃなくて、「開発環境がもらえない」ってことじゃねぇ？
だとしたら大分終わってるな。

コンパイル通してもいないのか?
ひどいなぁ。

>>64
念のために確認するがVSはVisual Studio .NETのことじゃないよな。

んなもんレビューしてること自体がDQ・・・

>>64
試験環境にVisual Studioを入れたら、その試験はあまり意味が無いよな。
だって、そのソフトウェアはVSが入っていない試験環境で正常に動作するという保証が出来ない。
しかもまだ開発し終わってないし。

自前で実行環境を作って検証するべきだし、またレビュー相手か誰かに本番環境とは別に
エンジニアリングテスト用の実行環境を要求する権利もあるんじゃない？

>テスト始まってからそんな修正は許されないって。

お�hﾙ

開発メンバー９人中５人が言語未経験者なんだけど、
君ならまとめられるでしょって丸投げしたマネージャ殺害していいですか？
低スキルプロジェクトで品質保障なんてむりぽ。

>>71
まとめるんじゃなくて教育だな。
当然、自分ひとりでやったほうが効率いいが。

>71
そんな貴方に、テストドリブン

以前５人のプロジェクトでCactus使ってテストファーストやろうとしたんだけど、
低スキルプロジェクトでは銀の弾丸にはならなかったよ・・・
そもそもテストの意義から教育しなきゃならんガキ相手だと、
高尚な開発プロセスなど無意味で、結局はレビュー増やして、
全工程を管理下（監視下？）に置くという結論に達してました。

教育・・・日々色んな事を発信しながら仕事してるんだけど、
やっぱり戦力まで持って行くのは時間掛かるんだよなぁ。

一度でいいから十分なスキル者だけに囲まれて仕事したい。

派遣相手に教育してもしょうがないしね。

おれは偽装派遣で入って、
同い年くらいのプロパーを使って現場を染めていったよ。
CVS→Eclipse(1.0の頃)→TestFirstとだんだんと。

おかげで、去るときも責任者からまあ引止めがあった。
今はどうしてるだろうな、彼は。

結局地道な啓蒙活動しかない。
派遣で職場を転々としてる俺にはむりぽ。

テスト計画書のいいお手本ってありますか？

>>78
経験

>78
テストを計画するときは、

どこまでテストするのか（テストの範囲）

どのように不具合を効率的に発見するのか（テストの戦略）

といった視点が重要となります。

いろんな所の人間が入れ混ざっている中でテスト作業していると、試験結果と責任関係にやたらナーバスになってきて滅入ってくる。そんなことないですか？
自分のバグを人に見つけれられるのを異常に嫌がる人とか。
教科書どおりには行かないといいつつも、うんざりしてくることが多いです。

>>81
いるねぇ。QA管理部の指摘を気にしすぎている上司とか最悪。
バグを発見したら喜ぶぐらいの勢いで良いのに･･･と思う。

稼動前の場合はね。

>>自分のバグを人に見つけれられるのを異常に嫌がる人とか。
>QA管理部の指摘を気にしすぎている上司とか

話ずれてるぞ。>>82
自分のバグを自分以外の人間に見つけられる＝自分で見つけられなかった
を恥と思うのは非常に健全。というか当たり前の感情。

いけないのは、指摘されるのを恐れて隠したり逆切れすること
開きなおること、鬼の首を取ったように攻撃することだ。

テスト駆動開発(TDD)はテストを書くことによって開発(実装)を進めます。
つまり、テストを成功させるためだけに実装していき、テストの無い実装は無いことになります。
あくまでもテストを書き、そのテストを成功させるためだけに注力を注ぐ所がポイントです。

設計が完全だからといってテストがおろそかな方がよっぽどいい加減で、
実際に動作しない机上の設計よりも確実に動作する項目のリストがテストとして存在する方が信頼性は圧倒的に高いでしょう。

テストは品質保証上必要とされる工程です。それに対して、デバッグは、バグさえなければ発生しない工程です。
しかし、これは机上の空論に思えるでしょう。人間は間違いを犯す生き物であるから、バグのないプログラムなどというものを作ることは不可能です。
なお、単体テストは、テスト・プログラムにより自動でクラスやメソッドなどを個々に実行して
結果をチェックします。クラスやメソッドが正常に動いているかどうかを、コンピュータが自ら
チェックできるプログラムを用意すれば、バグの早期検出は可能になります。

TDD厨多すぎ

>>85
ああそうだね。
TDDとてone of them に過ぎないと言う事を認識していない人間は多すぎる。
でもテストについてのスレだし。
許してやれよｗ

構造化厨多すぎ

ISO9126

つか、ヲーターフォール厨多すぎ。
ヲーターフォールできっちりやれば品質が高いものが出来るとかいうアフォ多すぎ

おまいら、QAは品質管理じゃなくて品質保証ですよ

QA(Quality Assurance)品質保証
QC(Quality control)品質管理
でいいのか?

しかし盛り上がらないスレだね。

>>91
そうだね。この「盛り上がらない」ってところが、
業界全体の品質に対する意識を、
見事に表現しているわけだ

・事前にテストの設計を行うので，自分がどんなプログラムを作るべきかがよく分かる
　やめてくれ。
　どんなプログラムを作るべきか分からないから，プログラミングは楽しいのだ。
　そのだいご味を奪うな。

・単体テストを頻繁に繰り返すことで早期にバグが見つかる
　何を言っているんだ。
　誰もが自分のプログラムの中にバグがないことを願っているのだ。
　バグなんて見つからないほうがいい。余計な仕事が増えるだけだから。

・早期に問題が解決することで，後工程からの手戻りが減って開発スケジュールが円滑に進む
　おいおい，手戻りが減ったら開発が予定より早く終わっちゃうかもしれないじゃないか。
　人月計算でやっている限り，少しでも開発期間を延長して開発費をいただかないと
　赤字になるぞ。
　それに，開発途中の品質の低さが，ハラハラドキドキしてたまらないのに。

・テスト・プログラムを先に作っておけば，本体のプログラムを変更（リファクタリング）しやすい
　リファクタリングだって？
　なんでわざわざ動くプログラムを修正する必要があるんだ。
　動いてるものには触るな，と習わなかったのか？
　プログラムなんて動けばいい。中身がスパゲッティでも構わない。
　メンテナンス？ どうせそのプログラムを修正するのは私じゃないさ。

・テスト・ファーストを行えば，品質に対する安心感とテストをパスする達成感が得られる
　安心？ 達成感？ 何を寝ぼけたことを言っている。
　劣悪な環境で不安を抱えながら仕事をするのがソフトウエア開発じゃないか。
　私なんかもう1週間も家に帰っていないぞ。
　いつもニコニコしてプログラミングするような奴と一緒に仕事をするのは願い下げだ。

プログラムをどのようにテストすればよいかという点を欠いたままの今のテストファーストではバグは減りません。

じゃあtestの心得でもまとめるか

・手順書は霞ヶ関でも通用するような完璧な形式に。
・テストログは紀元前までさかのぼって完全に調べる事。
・テストが完了しても細部にこだわってできるだけ完了報告しない。
・仕様自体は無視して手順書の間違いの指摘に熱中する事。
・バグ報告は１行以内で簡潔に。 例：うまくうごかない

試験項目（パラメータ）が1000あるって事はそれにMin,Max,中間値等を入れて
テストすると組み合わせは3(or4)の1000乗あるって事だろ？力ずくじゃできんよな？
どうやって組み合わせを決めるんだ？
実験計画法か何か使うのか？
もちろん。正確に言うと実験計画法そのものではないけれど、
基礎知識としては必要だな。

ちなみに手間がかかるのは
テストシナリオの作成とシナリオの自動化。
毎回同じことを手で繰り返して喜んでる奴らに
ソフトウェアなんて開発できるわけがないｗ

去年、バンガロールで見たテスト環境では
自動化されたシナリオを２０台ぐらいのテスト機で
パラメータを変えて並列で走らせても
数十時間かかるものも多かったけど、
金曜の夕方に仕掛ければ、月曜の朝にはテストマシンからの
レポートがメールで届いていたよ。

インドでももはや人海戦術なんてやってないｗ

「動作検証」と「QAテスティング」の違いが今一つわからないんですが。。。
「動作検証」は動作確認だけのテスト(?)で、QA(品質保証)テストは全体を結合した
テスト(?)、という理解で正しいんでしょうか？

TDDって、どれくらい普及してる？みんなのとこの実情聞かせて。
まず、俺から。俺のところは、TDDを知ってる上司はいない。以上。
いや、ネタじゃなくて。TDDでやりたいと言えば、たぶん、嫌味を
言われた上で、「ちゃんと間に合わせてくれるんなら何やっても
いいよ」（じゃあ、はじめの嫌味は何だったんだ？）となりそう。
やりゃいいだけなんだが、まわりに一人も相談相手がいないと。

作るだけ作って納品する。

バグは客が見つけてくれる。

全体はウォーターフォール、要件定義とシステムテストは１回。
そうじゃないと、大きいシステムでは進まないことが多い。

で、内部的にイテレートを繰り返して、リスク軽減を図る。
リリースは客に対してではなく、システム内での目標として行う。

TDD=ﾄｰｷｮｰ ﾃﾞｾﾞﾆｰﾗﾝﾄﾞ で。

みんな単体テストってやってるの？
以前いた会社では新人教育の時しかやらないんだけど。。。

もうこの業界から足洗った者だが。

プログラムによる

画面のテストなんかだと単体テストはしない（できない？）

画面は単体じゃねーし。

その疑問って、普通にテストをやってる人からしたら、質問する思考からして理解できん。

プログラミング作業ってのは、最低でもコーディングと単体試験がセット。
それ以外のものはプログラミングとは言わん。キーパンチ、ワープロと一緒。

しかし世の中にはコンパイル通ったらプログラミング完了って言う輩もいるからなぁ・・

いや、できましたつって持ってきた奴がコンパイル通らないなんてざらに…

>102
少なからずそういう会社あるんだよな。
それでも「テストしない」ならまだマシで。
「テストできない」って所も多い。
最低ラインの構造化すら出来ていないから、テストできない。
1つの関数にあれもこれも詰め込んで、それをレビューすらしない。
辞めて正解。

テストはコード書くより奥が深いよ。

バグを出せるように、物凄く意地悪なケース（通常使用じゃありえないようなケースも）
をばんばん叩きつける。メモリーリークしたりデータ壊れたり、状態遷移が
おかしくなるバグを見つけると快感ｗ

コーディングのミスじゃなくて、そもそも設計不良で、仕様書書き直させる
くらいのバグ見つけるとさらに快感。

ただテストデータ作るのが大変ね。

意地悪つったって理論的に起こり得る場合なら予期できる振る舞いをするコードを書くのがふつうだし
そんなところでバグだしたら少なくともうちの会社では笑いものになる

そもそもテストしてないのに、バグだ！いや違う！とやっている奴を見ると悲しくなる。

>>109
そういう意地悪な動作に限って、リリース後にユーザが見つけるんだよなぁ

本人とか、チーム内とか、プログラマがやると、
先入観とかが邪魔して、本当の異常系とかが甘くなるよね。
その辺が上手い人がテストで品質を上げられる優秀な人だと思える。

そうじゃないと、単にプログラムをなんとなくなぞる程度のテストになる。
操作とか変なデータ入力とかも、想定される範囲内のものでしかない。
そんなの正常系だと。

何するものなのかよくわからん（説明不足）、中身の設計書がペラ１ぐらい
しかない、単体試験も「〜の設計書どおりか？」の１行だけ。

これを渡されてどうやってテストしろと？結局、コード読んで１から設計書
書く羽目になったり。

仕様書がないのにテスト項目起こすって、いったいどうやって？
なぞだ。

そもそも何を作ったんだろ？

>>113
うちは、メンバのプログラム能力にバラつきがないときは、設計・実装担当者以外の人に、
設計書を基にテスト項目作ってもらってるよ。
で、テスト後のバグは、テスト項目作った人が修正するの。

もう、設計書レビューが熱いよ。

当たり前のことを当たり前のときにやってる人には理解できない場ってあるんだよ。
単体テストしてないのに結合にソース回したり。
そもそも仕様が明確じゃないのに作ったり。

そういう場にいる人って、愚痴るけど改善はしないんだよね。言い訳色々して。

そうじゃない人は普通に仕事してるだけだから、悩んでるレベルがそもそも違う。
品質を上げる努力をするのと、そもそも品質概念が存在しない人では議論にならんよ。

>品質を上げる努力をするのと、そもそも品質概念が存在しない人
違和感あったのでちょっと揚げ足取ってみるね。怒らないでね。

「当たり前の事を当たり前にやってる人」＝品質を上げる努力してる人
「単体テストしてないのに〜仕様が明確じゃないのに〜でも愚痴は言う人」＝品質概念が存在しない人
っていいたいんだよね？

でも品質概念がなければそもそも愚痴りもしないでしょ。逃げてるだけだよね。
もちろん逃げてる人だってどうかと思うけど、自分の守備範囲だけしっかりテストして
そういう人達を見下してるだけの人が「品質を上げる努力をしている」とは思えない。

自分でも言ってるじゃない。自分のソースの品質上げるのは当たり前の事だって。
当たり前の事をして普通の仕事をしてる人は出来上がるコードの品質が高いからって
「品質をあげる努力をしている」人になるのかな？

#まぁたぶん118は自分の手の届く範囲で品質を上げる努力をしてる人だとは思うけどね。

部分最適は悪

>>120
同意。だけどあなたは皮肉屋だな。部分最適化、この場合は「局所的な品質向上」だろ。
個々の担当者が自分の担当範囲の品質を向上させても意味がないばかりか
「悪」であると言っているのだろ？
・・・まあ確かにスレタイの「品質管理」自体は、個々の担当者レベルで行うものではない

だいたいさ、あるパーツだけ良くたって全然お話にならんのよ。
例えば自動車。いっくらエンジンが最高でもシャーシやタイヤ、サスペンションが
ボロボロなら乗らないよw

全体で語ってね

>>122は全体がボロだな

>>119
>でも品質概念がなければそもそも愚痴りもしないでしょ。

ちがうと思うぞ。
おそらく後者のパターンはエンドからのクレーム→保守作業でデスマ→愚痴って
コンボじゃないか？
少なくとも品質概念があれば単体テストしないなんてありえないし、仕様が明確
じゃなかったら明確にするアプローチを取るよ。
（つうか普通のPGなら単体テストをしないなんてありえないけどな）

部分最適は悪じゃないだろ？
品質＝性能ならそれは認めるけど、ここで言ってる品質ってのは最低限の仕様を満たすレベルでしょ？
そうならば、個々の積み上げが品質向上の基本だと思う。

ただ、その個々が勝手に品質向上手法を発揮しても無駄で、それを明確に示すのが組織なりだと思う。

>>125
・・・まあその種のことを「明確に示す組織があまりに少ない」という事実が、
「品質の定義も定まっていない」という現状の背景であるわけだ。

でーもさ、単体テストしてないものを結合に流していい組織なんてないだろ。
そんなの開発手法が何であれ、常識の範疇だと思うんだが。

>>127
そのとうり。「生産物の品質」ではなく、「生産プロセスの品質自体」に問題があるｗ
#論外に分類されるケースについて延々と論じていても意味があろうとは思えないなぁ

いや、我々が知らない世界ってのがどうもあるらしくて。ｗ
そこの住人に言わせれば、単体してないモジュールでも結合に来てたり・・・。
それでデスマとか徹夜とかいってるんだからお笑いですけどね。

論外がまかり通っている例が多い所がなんとも凄い業界だな。
どっとにしろそんな所淘汰されていく訳だがなかなか浄化されない。
淘汰される傍から沸いてきてるんじゃないかとｗ

そんな事言ってるあなたの後ろにも、魔の手は忍び寄っているのです。
設計書 0枚、テスト項目 0項目、バグの発生 endless。
お金で買えない品質がある。

とてもプログラマだけで100人近くいるプロジェクトとは思えない。
もうだめぽ＿|￣|○

>>130
まともなヤツは嫌気が差すとすぐ辞めちゃうからねぇ。

別にそれほどひどくなくて、レベルがちょっと低いなぁって職場でも
新技術を広めようとか啓蒙しようとかしないで
適当に資格とか取って頃合見て辞めちゃう人多いんじゃない？

…うちの会社がそうなんだよなぁ。

>>131
でも、上手い人の条件としてそういう危機・危険を事前に察知する能力、危険に入らない政治力もあるからね。ｗ
ファイアーマンで入る場合にも、発言権を予め確保しておいて改善できるようにしたり。
まあ、最悪はどこいっても喰っていけるから辞めるだけだな。

>>132
その会社に残ってるあなたは・・・ってことになるから、自己の鍛錬、確立を目指してください。

俺はレベルの低い会社に10年間居座って
まじめに働いて自分が居ないと保守も新規開発もままならない体制を整えたよ
おかげで今は実働日に3時間の遅刻早退当たり前でもクビにならないw

それもある意味不幸じゃないか?
偽装派遣で売り飛ばされるよりはマシだけどさ。

>125
>品質ってのは最低限の仕様を満たすレベルでしょ？

(120ではないがカキコ)
そもそも"仕様"の質が悪いケースでプログラム単体テストしないから品質がうんぬん、ってのは悪ではないのか？

>>136
125じゃないけど、言ってる意味がよくわからん。
「悪い仕様通りに作ると品質が悪くなるので単体でコードの品質をあげろ」ってこと？
「品質が悪いのを仕様のせいにするな」ってこと？
どっちみち仕様の事言っていいのは結合以降だと思うんだけど…

まぁ単体試験の定義も場所によってまちまちだけどね。
関数単位だったり、クラスorモジュール単位だったり。
全モジュール結合してもシミュレータなら単体試験ってルールのとこもあったな。

>137
>「悪い仕様通りに作ると品質が悪くなる
　のに単体でコードの品質をあげて、ってのは無意味

>「品質が悪い
　のは仕様のせいの場合もある

ってこと

年末なのであげてみる

今年一年振り返って品質を語ってみようじゃないか

品質はテンパってると落ちるばかり。
無理な納期だと優秀な人間でも不具合は多くなる。
トップダウン的な取り組みが必要。

ってゆーか納期があるかないかで作り方変えるだろ

ってゆーか作り方同じではありえないだろw

同じやり方しかできん奴もおるしなぁ

納期が無いなんてありえない

>納期が無い

まぁ延長できるかどうか、ってニュアンスで
ここは一つ

文字通り有るか無いかじゃなくて「充分に」が省略されていると思いねぇ

なんか盛り上がって松
ttp://pc5.2ch.net/test/read.cgi/prog/1100896833/201-

235 ：仕様書無しさん ：05/01/07 01:42:00
テスト担当者は
1.故障(症状)の発見とその報告
だけに関係し、開発者は
2.欠陥(病気)の診断とその対処
に責任を持つ

ある故障は複数の欠陥によるかもしれないし
ある欠陥は複数の故障を引き起こすかもしれない
ある故障は欠陥によるものではなく、テストデータやテストケース自体のせいかもしれないし
あるいは必要とされている事・要求されている事に対する誤解によるものかもしれない

期間がきつくても関係者（顧客含む）間の意志の疎通がしっかり取れてる
状態なら何とかなります。

何時も疑問に思っていた事をお尋ねします。

実装までの開発工程では、各工程の意義や手法、全体像から見た枠定義など考えられるのに
対する検証における工程は、かなり疎かで場合によりテストと言う一括りで片付けられる面がありますよね。

その例として、単体テストはガッチリするのにそれ以降テスト工程はショボショボだったり。
各テスト工程の作業が被って非効率的だったりすると思います。

この明らかに偏った状況はどう思われますか？

共通関数が古いバージョンで単体テストをしていて、
受入テストは共通関数のバージョンや環境が単体テスト時と全然違って動きません。
テスト仕様書も単体テスト分しかありません。
これで受入テスト、結合テストやれって普通ですか？

>受入テストは共通関数のバージョンや環境が単体テスト時と全然違って動きません。
これはダメ

>テスト仕様書も単体テスト分しかありません。
これはよい(っつーかしかたないじゃん)

>>150
残念ながらその質問に総括的に回答する事は出来ないが。
テスト／試験についての方法論の研究／開発が、
実装段階までのそれより遅れていることは確かであると思う。
「試験は現段階でのソフトウェア生産／保守において最重要に注力すべき開拓地だ」
と常々、思っている。
一般に試験がリリース前の最後の工程であるという事実を背景として、
試験の重要性を充分に理解しない者の横車や、前工程の遅れにより、
「試験に必要充分な工数をかけられない」という事態は頻発している。
このような事態が起こらない様に日々、戦っているのだが

上流がちゃんとしてるなんてのは思い込みだけどな。

実際上はそうであっても、テスト計画上は上流が完了してるのは当然としないと計画が成立しない。
多少の漏れは想定しても、前工程未完を前提にテストなんて考えられない。

>単体テストはガッチリするのにそれ以降テスト工程はショボショボだったり。

1. 「全てのテスト項目」がちゃんと見える
2. 政治的な世界と関係なく進められる
3. PGの趣味の世界で試験ができる
から、単体だけカッチリするのは当然と言えば当然かと。

結合テスト以降がショボショボになる事を見越して
「せめて単体は完璧に」と頑張るPGの姿を想像すると泣ける。

>>153
>テスト／試験についての方法論の研究／開発が、
>実装段階までのそれより遅れていることは確かである

実装段階までの方法論が進んでる例を教えて欲しいぞ。

それにテストは方法論を研究すればいいってもんでもないんじゃねーか。
理屈をこねてもやるべきテストは減りはしないんだし。

>>157
やるべきテスト。
つまりテストケースの設計手法が1種類だと思っていないか？

>>158
「抽出」手法だよね。別に思ってないよ。

xUnitによる単体テスト、あれはテストではない、仕様だ。なのに「テスト」と
呼んでしまっている。だから、従来からの伝統的なテストの概念やQA部門と
開発チームとのあいだに混乱と軋轢が生じる。
名前重要。
テストケースと呼ぶから、プロダクトコードの後にユニットテスト書くような
輩が絶えない。テストではなくスペック(仕様)と呼べばよい。仕様をプロダクト
コードの前に書くのはフツウだ。
これまでだってそうしていたはず。

いや・・・だから、仕様->実装->テストの流れで、
実務上仕様と実装、仕様とテストが乖離している現場が多いことから、
入り口の仕様と出口のテストを一体化させた方法論がｘUnitなわけで・・・。

コーディングのミスはプログラムの単体テストで発見されることが多く、
設計上のミスは結合テストや機能テストで見つかることが多い。しかし、
要求仕様に間違いがあった場合には、納品直前の顧客による受入テスト
段階まで発見されないことが多いのである。

こうした場合、プロジェクトは最初の工程からやり直しになる。

>>162
で？そんなん一連のテストブームのときに、入門部分で散々書かれてることだが。

ソフトの致命的なバグは誰の責任か？
テスターの責任？ そのバグを発見できなかったから？
プログラマの責任？ プログラムを正しく書かなかったから？

会社の製品なら会社の責任だ
個人の責任を問う奴が一番使えん奴

やることやってるヤツしか言えないセリフだけどな。

会社の責任＝社員全員の責任だから勘違いしないようにね。

責任を取るから責任者って言うんだけどね。

ソフトベンダの業績悪化はトラブルプロジェクトに起因しているケースが多い。
一旦トラブルが起こると対策のために大量の人員投入など予算枠を超えて対応
せざるを得ない。これが火に油を注ぐ結果になりQCDは大きく超過する。
企業は防止策として見積時のリスクチェック強化を行い、無理な注文は取りに
行かないよう努力している。

しかし、その努力も虚しく受注してから業務に精通していない、
プロマネ力がない、技術力がないなどでトラブルとなるケースも多い。
品質保証活動は、トラブルを軽減する策の一つである。

品質保証計画を立て、一つ一つの活動を地道に実施していけば防止できる。

>>163
いつブームがあったの？

>>169
一昨年あたりから。
単体テストツールや、そもそもの工程管理の方法など。
日経ＢＰあたりが腐るほど本をだしてるっしょ。

age

誰の責任というのは基本的にあってはいけない
業務は組織で遂行するものだから、連帯責任。
個人のせいにしても何の解決にもならない。

>>172
対外的にはね。
組織内ではその責任が細分化すべき

不具合内容：
不具合発生日時：
不具合発生場所：
不具合発生件数：
発生原因の現状把握：
なぜ不具合が発生したか？最低五回なぜなぜを繰り返す。
現状把握から原因を導き出す。複合要因がある場合は因果関係を明確にする。
原因が判明したら本当にその原因で不具合が発生したか検証する。
検証結果明確な原因であれば、その原因に対して対策案を検討する。
検討案はひとつ以上提案する。
その対策案を実行して問題が解決するか検証する。
その対策方法が他の業務等に水平展開できるなら適用する。
この時、懸念する点があれあばあげておく。
その懸念内容（発生するかも知れない不具合）に対して対策（予想効果）案を
検討しておく。

>> 170
テストといえば、マイヤーの古典か、原発制御ソフトや宇宙ロケット
制御ソフトのテスト用？にかかれたバイザーの数学的理論書以外に専
門書がない時代（６年くらい前）にくらべれば、今は大分恵まれてい
ると思う。

マイヤーの古典って
http://www.amazon.co.jp/exec/obidos/ASIN/4764900599/249-4854165-6226734
のこと？。今確認して見たら1980年だね。確かに古典だなぁ

>>172
そんな共産主義みたいな仕事してたら、会社潰れるべ

うちの会社なんか毎回責任の押し付け合いしてるよ（´・ω・｀）
だから本当の原因がいつもうやむやにされて、毎度同じことを繰り返してる
まあ、みんな年俸評価を意識してるんだけどね。。orz

今、IT業界でテストの重要性が非常に大きく認知されてきている。
とくにインド、中国はその勢いが非常に激しい。
日本はものを作ることだけを考えていたため
ソフトウェア管理品質についてはろくに考える能力がなかった。
そのため日本はテスト開発についてインド、中国に後れを取っている。
このままでは、日本のソフトウェアの信頼度がインド、中国に負けてしまい、
日本のソフトウェアの人気が低下し、価値が下がってしまう。
それは大変なことだ。日本のプログラマをますます窮地に陥れることになってしまう。

さあ、いまこそテストファースト、テスト駆動開発を実践しよう！！！！！

>>93
> ・事前にテストの設計を行うので，自分がどんなプログラムを作るべきかがよく分かる
> 　やめてくれ。
> 　どんなプログラムを作るべきか分からないから，プログラミングは楽しいのだ。
> 　そのだいご味を奪うな。

ふざけるな！
おまえのくだらん我が儘のために多くの若き後継者が苦労するんだ！
このIT業界の癌め！

52 名前：仕様書無しさん 本日のレス 投稿日：05/03/03 08:18:45
Perl厨はPerlUnit
PHP厨はPHPUnit
C++厨はCppUnit
ＶＢ厨はVBUnit



53 名前：仕様書無しさん 本日のレス 投稿日：05/03/03 08:19:38
JunitX
Jakarta Cactus
MockObject
HttpUnit
XMLUnit
HtmlUNit
DbUnit


これらを使いこなせ！

-----
$ java junit.samuraiui.TestRunner sample.RedTest
ユニットテースト ユニットテスト♪
すべてのテストを自動で実行するんだぜ！ って言うじゃな〜い？
.F.F.E.E
Time: 0.01
でもあんたのテスト、2個エラー発生してますから！
1) test3(sample.RedTest)java.lang.ArithmeticException: / by zero
at ...
2) test4(sample.RedTest)java.lang.ArithmeticException: / by zero
at ...
でもあんたのテスト、2個失敗してますから！
1) test1(sample.RedTest)junit.framework.AssertionFailedError: expected:＜1＞ but was:＜2＞
at ...
2) test2(sample.RedTest)junit.framework.AssertionFailedError: expected:＜2＞ but was:＜3＞
at ...
残念！！
4個のテストで、エラー2個、失敗2個、斬り！

$ java junit.samuraiui.TestRunner sample.GreenTest
ユニットテースト ユニットテスト♪
すべてのテストを自動で実行するんだぜ！ って言うじゃな〜い？
..
Time: 0

...拙者、ダミーの実装のままリリースしたこと2回ありますから。
切腹！
-----

http://akiyah.bglb.jp/blog/484

age

あげとく。

afw

QA氏ね
おまえら客でもねーのに客が決めた仕様にまで口出して
修正すべきとか抜かすな
おまえに金もらってんじゃねーんだ

つーかたまには純粋なバグ検出しろ。主観オンリーの指摘はうぜーからやめろ
おまえらに付き合ってたら
サグラダファミリアみてーに永久に物 完成しねーんだよカス
そしてその偉そうな文体のメールも吐き気がするからやめろ
あとできれば人間もやめてください

新人が「ＱＡってなんですか」と聞いたら、
上司は「テストで判明した質問疑問について答えていく期間です」

>>186
>永久に物 完成しねーんだよカス
誰が完成させろなんつった？
完成したが最後お前も俺も飯くえねーんだよ。
仕事なくなんだよボケ！
生かさず殺さずじわじわ金とってくんじゃボケ！

>>186
ちょっと考えが古いんじゃないの？
品質＝バグなしってのは最低限で当然。
品質＝顧客満足を満たすってのが普通の考え。

純粋なバグ検出は単体レベルはプログラマの仕事、結合ならばQAだとは思うけど。

まあ、客に出せないもの作っても、金貰えないからね。

>>186
漏れとしてはかなりまともなQAのいる会社だと思うが？

つうかQAに駄目出しされるような仕様受けるなよ。
喪前の決めた仕様に問題があるだけだろ。
人に責任なすりつける前にきっちりと仕切れよ。

よく読めや

>>89
ウォータフォールできっちりやれば品質が高いものはできますよ？
RUPも然り。

ただ、最近のソフトウェア要求の傾向として、ウォーターフォールでは
答えられなくなってきているのでは、というのがトレンドなだけ。

むしろ余計なタスク切り替えのオーバーヘッドが少ない分、
ウォーターフォールの方が効率が良い場合も多々あるのでは。

後工程になるほど修正にはコストがかかるってのは定説ですよね？

すると、テストフェーズでの不具合発見てのは修正にかなりコストがかかるわけで、
本来であればより前のフェーズで見つけられるべきものは見つけておかなければならないはず。


品質管理のスレで、テストの話ばっかりなのはちょと如何か、と思った次第。

>>180
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20020904/1/
ページ下のリンク「皆様の評価を見る」も参照のこと。

今だに品質管理規格ってないよな

>>192
> ウォータフォールできっちりやれば品質が高いものはできますよ？

ウォータフォールって私の理解では、フェーズ移行審査をきちんと
実施して条件に満たなければ移行してはならないってプロセスの事だと
思うのですが、大人数で開発してると各フェーズの終了時期をそろえる
なんて困難ですし、大規模開発だと、開発後半で仕様変更要求が入って
上流工程と並行して進めないとならないので厳密な実施は難しいと思い
ます。

で、フェーズ移行の度に「条件付で移行可」なんて言われて、リリース後
問題が多いと「フェーズ移行をきっちりしなかったからだ」なんてレビュー
されてしまうんだけど、そんなことを何年も何年も繰り返しているんだよなぁ。

うちの会社だけかもしれないけどさ。

>>196

　フェーズ移行管理というのはその昔、IBMが提唱していた
局面化開発というやつですね。

　条件付で移行というのは、リスクを含んでおけばいいのでは
ないでしょうか。完全に移行管理をすることは開発コストを
考慮すると難しいです。

　リスクをどの程度見込むかということではないでしょうか。

>>197
おっしゃるとおりですね。
ただ、リスクの評価は、実際には非常に難しいので、できていません。

たとえば、システムの一部（うーん。フェリカのリーダとかね）ができて
ない状況で次のフェーズに【条件付】で移行してしまったとします。

その時は、フェリカリーダなんて独立してるから、ま、たいしたリスクには
ならないだろうなんて話になるわけですよ。勘だけでね。

で、テスト途中にフェリカリーダが届いたって言うんでつないで見ると
あらら、データ構造変えないとだめじゃんって分かってインパクトでか
かったり。。。

では、フェリカリーダが来るまでフェーズを止めておくべきだったかという
とそんなことはないんですよね。>>197さんのおっしゃるとおりリスク管理
技術がちゃんとしてればいいだけの話なんでしょう。でも大変。

>198
>止めておくべきだったかというとそんなことはない

本当か？
手直しの手間を考えると後で作った方がよっぽどましだったのでは？
どうもそこんところがわかってない香具師大杉

>>199
後から作ると、フェリカリーダが届いた時点では0だよ？
手直しだと、一応出来てる部分もあるわけだから、0(やマイナス)ではないだろう。

大体、フェリカリーダが来てないことを理由として
次のフェーズに進まなかった場合にどんなメリットが？

　フェリカリーダがシステム開発のどれだけの割合を占めているかを
考慮する必要がありますね。

　私ならその部分は放置して（擬似的に結果だけを返すようなスタブを
作って）それ以外の開発を進めるでしょうね。フェリカの開発部分が
大きいようだと開発を一時中断してフェリカリーダの仕様の確認が
最優先ですね。（30%を超えたら開発は止めてしまいますね）

　これはスケジュールや開発メンバーの工数との兼ね合いもあり、
プロジェクトリーダーの腕の見せ所ですね。

>>200

　できればいくらか作っておくという状況は避けたいところですね。
改造を前提に作ってしまうとバグを作りこむ原因になるからです。
　これもプログラムの複雑さによるもので、全否定するつもりは
ありません。（私は、読むだけ書くだけというのであれば問題ないと
考えます）

　改造を前提とした場合には、改造前と後の相違点について明解に
して、テストする必要があります。この部分の工数を見積もって
おかねばならないですね。テストの要不要も検討しておかねば
なりません。

　199さんはそういう工数を考慮しなくてもいいということを言いたかった
のではないでしょうか。いずれにせよ、影響度を検討すればいいと
思います。

ねえ。ありえないデータぶちこんで無理やり不具合を発生させる
「鬼テスター」の人はどのように社内で活用させれば良いの？・・・。

>>202
> いずれにせよ、影響度を検討すればいいと思います。
はい。ずっとそれ（リスク評価）には同意なのですが、現実には
外れることもままありましてという例を書いたつもりでした。

フェリカのケースではスタブも作っていましたし、仕様ももちろん
確認していました。

しかし、フェリカの仕様書自体が間違っていたんですね（笑）。
それで、フェリカの仕様書が間違っていたとしても、「HWは修正に
コストが沢山かかるからSWの方で対応してよ」といった理由で
SW側で対処することになりました。

天変地異をリスク管理表に入れないのと同じでフェース移行の時に
は「フェリカの仕様書が間違っている」リスクは計上しませんでした。
しかし、終わってみれば、初めてつなげる周辺装置であることから、
リスクとして計上し、相手の工場に出向いて完動品でもいいから
つなげて確認しておくべきだったという事がわかります。

経験が足りないんでしょうね。

自作自演ぽくね？

>>204

　あぁ、そうですか。なんか想定外のことがいろいろ起こったのですね。
お気の毒です。

　出来る限りのことをやって、さらに想定外のことが連発したとなると
あとは力技に頼らざるを得ないんじゃないでしょうか。ｗｗｗ
私もそうなったときには、死ぬ思いでその場を乗り越えることにして
います。（苦笑）

>>205

　自作自演ではないですｗｗｗ

本番でバグを１件出すごとに、日勤教育１０日、ってのはどうだろう？

>>203

　普通のテストケースを流してもらうようにお願いした方がいいでしょうね。
レアケースのバグ見つけたってしょうがない（こともないか）

　たぶん、「テストの鬼」は簡単に見つかるものをバグだとは思っていない
んだとおもう。203さんのところではどれだけのバグが開発中に見つかるのか
わかりませんが、テスターは指摘したバグを修正してもらうことで仕事を
していることになるので、
　「発生率（出現率）が低いので修正を見送る」
ということを何度か繰り返せば判ってくれると思う。（説明も必要です）

　かくいう私も再現困難なバグを発生させる手順を見せて、驚かしたり
すると快感が走ったりするわけでｗｗｗ
いまはそういうのは暇なときにやりますね。そうして快感を感じているわけで。
　次のテストが始まる前に、できるだけ意地の悪いテストをすることに
してます。

　そういう「いいテスター」と仕事をしておられる203さんは幸せです。
（使えないテスターの方が世の中には多いです）　

>>203
そのデータが本当にありえないかどうかの統一された判断基準で評価できる
仕組みを作る。
個人で判断なんてしてたら、ありえるデータも削ってしまい兼ねないでしょう。

>>203
本当にありえないデータならバグの重要度は低くなるはずだから直さなければよい。
ただし、入力データのチェックが甘くないかどうか開発サイドでも調査が必要。

で、件の「鬼テスター」には絶対にバグがあっては困る領域（セキュリティ関係
とか）のテストに回ってもらうというのがいいんじゃないかな。

>>203
日勤教育。

テスターがデータ作って入力できてる時点で
「ありえないデータ」じゃないと思うのは俺だけですか？

まー言葉のアヤなんじゃろうけど

ビルの建築CADソフトのデータ数字に、「虚数」打ち込むのも
ありえないデータかな？・・・。詳しくなくてスマン。

つーか、しょせんビットなんだから「ありえない」もなにもないわけで
「想定している形式」か、「想定していない」かのいずれか

無視する、(そんなデータがあった事を)教える、ゲロを吐く、
「措定していない」ものをどう処理するか、ってだけだ

措定 age

『ありえない』データもテストできる時点で『ありうる』データに変わると思うんだけど。

>>216
そうかもしれんな。確かに・・・。

>>216

　というようなデータがあっても、テストの優先順位は低いですね。

　CADのデータに虚数を入れるテストはあってもいいと思いますが、
時間があったらテストするというレベルになるのではないでしょうか。

>218
ってゆーか、想定しているデータ以外の場合こうするよ、ってだけだ

>>180
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20020904/1/

虚数入力って例がちょっとな
そもそも入力値がでかすぎるとか小さすぎるとかは
単体レベルで確認しとくものじゃないかと

ありえないっつーと
同じ信号の２度送りとかデータ欠落とかファイル壊れとかビット化けとか
OSのリソース枯渇とか
そんな感じか？

対向ノードがちゃんとしてるはずだから
ＯＳがちゃんとしてるはずだから
ハード故障だから
ありえませーんって感じだよな

>ＯＳがちゃんとしてる

ありえませーん

SCLの意味わかるやついる？
一般にUTITPTとか試験工程を熟知してる香具師はおるか？

秀丸でありえないマクロ組んだ奴...。

Label:
message "ぬるぽ";
beep;beep;beep;beep;
goto Label;

http://YahooBB219169016004.bbtec.net/
うはっｗｗｗうはっｗｗｗｗｗｗっｗｗｗｗｗｗおｋｗｗｗ

っｗっｗｗｗｗｗｗｗｗｗｗｗｗｗうぇｗｗｗ
ｗおｋｗｗｗｗｗｗｗっうはっｗｗｗｗｗｗｗｗｗっうぇ

引っかかった奴がいる・・・。

http://pc8.2ch.net/test/read.cgi/hp/1115573674/l50
山田ウィルスをだます囮スレ

>>223
お前のせいでこのスレ止まったじゃねえか！
UTITPT検索したらこのスレしかHITしねえじゃねえか！

…でSCLとUTITPTって何？

UT(unit test)
IT(interface test)
PT(product test)
かな?

SCL （SOAP Contract Language）
【エス・シー・エル】
Web Serviceが提供する機能を記述するために、マイクロソフトによって開発されたXMLベースの言語仕様の1つ。
同様の目的を持ち、このSCLとよく似た仕様を持つ言語としてSDL（Service Description Language）があるが、
このSCLではSDLをさらに発展させ、Web Serviceの単純なパラメータや戻り値に関する情報だけでなく、
オーケストレーションなど、Web Service同士がさらに緊密に連携するための機能が強化されている。

これのことかなぁ

サンチアゴ？

ちなみにATLはアトランタだそうだ。

SDEM 名称

PT
プログラムテスト

IT
結合テスト

ST
システムテスト

OT
運用テスト

だな

SDEMをググってみた。
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20030516/1/

富士通が採用しているウォーターフォール型開発プロセス、だそうだ。
あれ？富士通ってPTとかITとかじゃなくて日本語の読みをローマ字に直した略称を
使ってなかったっけ？

正確にはどんなのか忘れたけど、
KT
結合テスト(Ketsugo Tesuto)
みたいな。

>日本語の読みをローマ字に直した略称

SDEMぢゃねーな

>228

単体試験ＵＴ UnitTest
結合試験ＩＴ IntegrationTest
総合試験ＰＴ ProductTest

ＮＴＴコムウェア では

>>233のページでは、データの方はウォーターフォール否定しとりますな。

IBMはITAやらITBとかいう名前で呼んでたな。
結合テストと総合テスト(システムテスト)のことだっけ？

単体テスト UT
結合テストa ITa
結合テストb ITb

システムテスト
運用テスト

だねIBM

名前はどうでもいいから
どういう住み分けしてるのかとか教えてほしい

こう対応している。
UI - ST
SS - IT
PS - PT
PG - MT

>PG - MT

ここちがう

>>240
PではPG-MTなんだよ。

いまどきはテストドリブンなんで
PS　--　PT
　＼　／
　　PG
だよ
テストを考えながら設計しながらコーディングしながらテストしながら。。。

外の人間にはさっぱりわかんねぇよ

>>242
いやいや、>>233に書いてある通り、
ウォーターフォールの話だろ？

設計から製造→テストって順番に工程をやっていく点ではいまだにウォーターフォールだが
製造(PS-PG-PT)のパートについては>242になってるな

じゃあ成果物にMTないの？

磁気テープは流石に無いんじゃないかｗ

ツマンネ

>>247
マジレスすると磁気テープはメディアであって成果物ではないよ、オペレータ君。

マジレスするが、
成果物がメディアであることも有り得るのではないだろうか。

>>250
そういう場合、メディアの「中のデータ」が成果物なんじゃないの？

新メディアの開発とかなら話は別だろうけど、それなら板違いだしね。

>>250
あんたマジでオペレータでしょ？

3Mとか…

>>252
いや、磁気メディアの研究職です。

↑そんな香具師はマ板に来ない。

世を忍ぶ仮の姿かも知れないじゃんか

はいはいもういいよ。

>>1
品質なんて話は厨房ばかりのマ板では無理って事ですな。

テストドリブン開発なんてどうも信用できないんだよな。
テスト項目漏れとか絶対出てくるって。

最初から完璧なテストを用意しろってことではないでしょ＞テストドリブン開発

最後まで行っても項目漏れ多そうな罠。

テストドリブンて仕様作ったらそれに対する検査方法も考えとけ、っていう方法でしょ？
今まで仕様漏れしてたプロジェクトが、TDD導入すりゃ漏れなくなる、とか思ってたわけ？

> テストドリブンて仕様作ったらそれに対する検査方法も考えとけ、っていう方法でしょ？

違うと思うぞ？
ウォーターフォールだって仕様からテスト項目起こしたりするし

ＴＤＤって「ちゃんと単体試験しましょうね」って言ってるだけだよね？

単体試験てMTじゃないの？

磁気テープは(r

テスト設計からのフィードバックを実装時、設計時へと反映させるような構造転換、
これがテスト駆動開発（TDD）もしくはテストファーストの根本思想

>>263
テストドリブンて単体テストだけじゃないんじゃ？
テストファーストは単体テストが主だと思うけど。

>267
んなこたーない
単にテストが先、ってだけだ

だから
テスト先に考えるだけならウォーターフォールでもやるから

ＴＤＤは要するに
テストを作る→コードを書く（無意識にバグを回避するテストをするのを防ぐ）
いじるたびに同じテストを動かす（エンバグやデグレードを防ぐ）
ついでにテストありきだからスパイラルしやすいですぜー 品質もあがりますぜー
って方法論でしょう

単体だけに限ってないけど ポイントは単体だよね

漏れは昔は（学生の時は）XPだのTDDだのがいいものだと思っていた。
ウォーターフォールなんぞ時代遅れだと思っていた。
ぶっちゃけTDDが導入できないのは、現場の人間の勉強不足だと思ってた。

実装の現場で仕事するようになってから数年たって、マジで思うのが品質を
決めるのは仕切りだなぁと。
実際テストファーストよりも仕様確定（凍結）ファーストの方が大事だし。
品質管理には開発手法よりも仕切り手法の方が重要だと思うんだが・・・実際
はなかなか難しいよね。

一番の問題はいつまで経っても仕様が確定しない事だと思う。

>>268
テストを先にしようってことは、
大規模なテストは作っても意味が無い、ってことですよね？

>>269
そりゃTDDじゃなくてテストファーストでしょ？

>>273
じゃあどこが違うか教えてくれないかい?

テストも十分やったつもり。テスターからも「問題なし」の指摘。
んでもって工場の連続運転に使い始めたら半年後に「突然停止」し、
「作っていた半製品は全部破棄された」・・・という恐怖を味わった
奴っている？

>>274
http://www.google.co.jp/search?q=%28TDD+OR+%22%E3%83%86%E3%82%B9%E3%83%88%E9%A7%86%E5%8B%95%E9%96%8B%E7%99%BA%22%29+%E3%83%86%E3%82%B9%E3%83%88%E3%83%95%E3%82%A1%E3%83%BC%E3%82%B9%E3%83%88%E3%80%80%E9%81%95%E3%81%84
あたりを。

------
http://www.objectclub.jp/ml-arch/magazine/51.html
DaveにとってTDDとは「設計と実装についての見通しを得るためにテストを利用
する」ものだそうです。曰く「テストが語りかけてくるものに耳を傾け、その
声にコードを従わせる」と。テストが設計を駆動し、かつその設計を検証する。

一方のテストファーストは、TDDを先鋭化したものであり、テストに失敗した
コードをテストに通るように修正する場合以外には一行たりとも本番コードを
記述してはならない、というプラクティスです。
------
http://www.wikihouse.com/withoutEJB/index.php?%B5%C4%BB%F6%CF%BF%2F%C2%E807%B2%F3
TDDは必ずしもテストを先に書くとは限らない。TDDとはテストからフィードバックを受けて開発を進めることを指す。
------
など。
マーチンファウラーだかケントベックの本にも違いが書かれてなかったっけ？

>大規模なテストは作っても意味が無い
はぁ？
まぁ小さい単位でやれってのは正しい

>>276
どうでもいいけど こういう「〜読んでこい」ってのは卑怯だと思うな
議論スレなんだし

http://www.objectclub.jp/ml-arch/magazine/51.html
http://www.wikihouse.com/withoutEJB/index.php?%B5%C4%BB%F6%CF%BF%2F%C2%E807%B2%F3
があなたの言いたいことなんだろうね
「テストの結果をフィードバックしていくことこそTDD」ってことかね
（でもウォーターフォールだってテストの結果うけて仕様変更くらいやるよな？）

でも、最初のぐぐる先生が教えてくれたサイト（IT Proと結城浩）を見ると
テストファーストありきで解説してるんだよな

「テスト駆動開発＝テストファーストしてリファクタリングすること」って感じ
おれの解釈と一致するんだけどね（バイアスかかってるのかな）

> マーチンファウラーだかケントベックの本にも違いが書かれてなかったっけ？

読んでないわい

なんとなく みんな勘違いしてるんだなぁとは思いました
付け焼刃は駄目ってことかな みんな書いてること違うしね

テスト駆動開発＝テストファースト＆シンプル設計＆リファクタリング
リズムにのって
レッド グリーン リファクター
フェイルイット フェイクイット メイクイット リファクターイット
Red Green Refactor
Fail It
Fake It
Make It
Refactor It

>>278
> 読んでないわい
読めよ。

> >>276
> どうでもいいけど こういう「〜読んでこい」ってのは卑怯だと思うな
> 議論スレなんだし
程度の低い奴なんか知ったことかよ。議論の土俵に上がる以前の問題だ。

>>278
いや>>276はかなり親切な方だと思うが。

>>270
禿堂。

>>270
あなたの言っている「仕切り手法」というのは、開発手法に含まれますよ。
開発手法、というのを誤解している(あるいは拙い開発手法を用いた
現場しか経験していない)のでは？

>>284
あなたの言っている「開発手法」というのは、仕切り手法を含むのですね？
仕切り手法、というのを誤解している（あるいは拙い仕切り手法を用いた
経験しかない）のでは？

>>285
> >>284
> あなたの言っている「開発手法」というのは、仕切り手法を含むのですね？
その通り。そして一般的に言われる開発手法に置いてもその通りです。

例えば、アジャイル宣言には
「契約交渉よりも、ユーザとの協調」を重視することが盛り込まれています。
(参考：http://www.tech-arts.co.jp/agile/agile2.html)
これは、アジャイル以前の開発手法にも(良い悪いはともかく)>>270の言うところの
仕切り手法が含まれていることを意味します。

> 仕切り手法、というのを誤解している
というより、>>270の自分用語を誤解しているのかどうか他人には分かりません。
出来るのは最大限善意に解釈することだけです。
他人と概念を共有したいのであればもう少し明確な定義を行ってください。

つまり、

　プログラム設計の確認＝単体テスト
　内部設計の確認＝結合テスト
　機能設計の確認＝システムテスト

という形でテストが実施されます。

テストだけが品質を保証できるって

>>288
それはさすがにレベル低すぎ。

組込みは単体で動かないものが多い
テストいるでしょ

>>290
テストはもちろん必要だが、
テスト以外にも品質を保証する手段はあるし、そちらの方が効率的であることが多い。
ということでは？

テストは「品質向上のコア技術」。テストをおろそかにすると上流でバグをつぶすことができず、だんだん品質が悪くなる。

>>292
いやいや、テストフェーズでの修正は上流での修正よりコストがかかる
ってのは定説では？

案件ベースで考えると、プロジェクトだめだめで
基本設計から遅れてて結局仕様決まんないままコーディング入って
ぐちゃぐちゃな単体テスト〜システムテストまでやってやっつけでリリースって
案件がかなり多いと思うんだが（俺がいくのそんなんばっか(つД`))

まともにやってるとこも結構ある？

普通まともにやることの方が多い。

>基本設計から遅れてて結局仕様決まんないままコーディング入って
>ぐちゃぐちゃな単体テスト〜システムテストまでやってやっつけでリリース
これ、手法に何使ってんの？

繰り返しちょっとずつ作ってくイテレータ的な手法ならだめだめにはならんな

>>293
その定説を否定することこそがXPの背景／根源なのだ。
・・・まあ個人的にどちらに組するかはまだ決めていないのだが

確か
　/
／

な曲線が
　＿
／
になるって話だよね？

バグ累積が？

修正のコストがでしょ

>>296
RUPの教科書みたいな本でも読んでみれば分かると思うけど、
その考えでは全然駄目。

仕様が確定しないのは、
仕様の内容により何がどう影響を受けるのかを
素早く、的確に判断できないからじゃないのかなあ

システムが大きくなると全体を頭に入れることは難しくなるし
困ったもんだねえ

>>296
一応当初のスケジュール表みるとウォーターフローを目指していたらしいｗ

要件分析　基本設計　詳細設計　製造　単体　結合　システム　平行運用
→→→→　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　→→→→
　　　　　　　→→→→　　　　　　　　　　　　　　　　　　　　→→→→
　　　　　　　　　　　　　　→→→→　　　　　　　　　→→
　　　　　　　　　　　　　　　　　　　　　→→　→→
てのが
→→→→→→→→→→→→→→→→→→→→→→→→→→→
　　　　　　　→→→→→→→→→→→→→→→→→→→→→→→→（Doc後付)
　　　　　　　　　　　　　→→→→→→→→→→→→→→→→→→→→（Doc後付)
　　　　　　　　　　　　　　　　　　　　　→→→→→→→→→→→→→→→（Doc後付)
　　　　　　　　　　　　　　　　　　　　　→→→→→→→→→→→→→→→→（Doc後付)
こんな感じ

RUPの教科書みたいな本でも読んでみれば分かると思うけど
スケジュールは、
「方向付け」に3カ月間、
「推敲（すいこう）」に3カ月間、
「作成」に3カ月間、
「移行」に3カ月間
みたいな感じで 分析・設計・実装を繰り返す

>>304
RUPってそんなに長い周期は推奨してなかった気が…

１カ月〜数カ月間のミニプロジェクトの繰り返し

>>306
やったことないから想像つかないんだけど
1ヶ月位の開発が終わって次のモジュール作ってる時に
前作った機能で使ったテーブル使わなきゃとかでレイアウト変わって
前に作ったところにも手が入ってとかスパイラルに終わらないとかないの？

>前作った機能で使ったテーブル使わなきゃとかでレイアウト変わって
>前に作ったところにも手が入ってとか
コントロールできてれば別に困らんと思うが？

リリース前に変更に次ぐ変更を続けていったいいつ終わるの？ってのと
リリースした後で変更していくのとでは、精神的にもよろしいな

自称「鬼テスター」を自称するオレはマイクロソフトとの戦いに明け暮れて
いる。無理やり不具合を発生させるオレは単なる「悪魔」なのか？

http://oca.microsoft.com/ja/response.aspx?SGD=670b014a-d0b2-49ff-9fa5-3d3f3153c2b3&SID=1501
Windows XP のシャットダウン時のエラー : 解決策を開発中です

>>309
これ何？さっき初めてうちのPCでも発生したんだけど。

>>309
仕事が増えて大変ですね。

309です。シャットダウン時にパソコンにイタズラすると、ほぼ100%に近い
確率でメッセージが出る。MSにプレッシャーかけ続けてやろう。

テストのバイトをしてますが、質問。
経験なしの素人です。

開発から回ってきたソフトをテストしてますが、
開発の時点である程度バグ取りってしないものなんですか？
バージョンアップした割にはちっとも直ってないんですが。
根幹的な基本動作確認でフリーズしてるのを見るたびにため息出ます。

実際のテストと言えば、

テストのシート内容はボロボロ
リーダー毎に対応がバラバラ
対応が聞ければいい方通常たらい回し多し
見てると誰も総合的に把握してない


全部の皺寄せが一度に来るかと思うと何だかなぁ。。。。

>>313
まず、テストの目的によってそれぞれだから、プロジェクト管理側に聞け。
で、テスト業務ってのはそういう総合的な取りまとめ、交通整理も仕事だ。
まあ、バイト風情はそんなの関係なく、自動テスト装置のちょっと賢い版だけどね。

自動化テストよりもダメなバイトさん多いけどね。。
テスト業務って人によってすごい差が出るからね〜

>開発の時点である程度バグ取りってしないものなんですか？
え？だってバグ出しがその工程での役割じゃん

>314 >316

レスどうもです。そういうもんなんですね。

うちはきちんと修正されているか確認するけど、デグレ報告もしばしば来るお

デグレ、ってどういう意味で使ってる？
a.今回の修正したら、前に直していたのが直す前の状態に戻っていた
b.今回の修正したら、新しいバグがでた

一応、a.はデグレだが
b.はバグを新たに埋め込むと言う意味で"エンバグ"(エンコードバグ？)と言われるw

品質うんぬんはどうでもいいから早くプロジェクト終わってほすい。

>品質うんぬんはどうでもいいから
品質よけりゃすぐ終わりになるんだが？

>319
前に直したかどうかは関係なくて
いじった後修正部分と一見関係ない部分がおかしくなると「デグレ」
処理が遅くなったとかリソース食うようになったとかそういう品質低下?も指す

修正部分が機能不全を起こしたりバグを入れるのは「修正ミス」

エンバグは正しくない実装をすること

デグレは以前通っていたテストに通らなくなること

ﾃﾞｸﾞﾚって言うと実装漏れって言うより響きがいいから使ってるｱﾌｫが多い

デグレしか普段言わないな
うちの場合は実装が全て終わってからテストしているからかな？

まあ、仕様変更は当然のように入るわけだが・・・orz

「エンバグ」という言葉を知らない人も多いと思う
むしろ「バグ」すら正しく使えない人も多少いる

でもバグの定義って難しいよね。
たまに「仕様」か「バグ」かでもめることがあるよ（´・ω・｀）
やっぱり設計が重要なんだよね

どのように動けば合格なのか教えてくれればそのように作るのに...

そのように作ろうとしたなら教えてくれればちゃんと言ったのに...

結局仕様書がすべてという事か・・・。

わかんないんです（＞＜）

和姦ナイン？
あぁ、あの

スレとあまり関係ないのだけど。

科学技術振興機構の失敗知識データベースのページで、キーワードに「コンピュータ」とか「ソフト」とか入力すると、
ソフトウェアの仕様の欠陥やバグが原因で生じたそれはそれは恐ろしい最悪の事態の事例が幾つか見られます。

ここを見るたびに、同じような事例が自分の会社の製品で起きないようテストをがんばろうと思いますよ。
ttp://shippai.jst.go.jp/fkd/Search


脱線ついでに、あなたの会社でソフトウェアのリリース後に起きたありえない障害とかバグとかってありますか？

> あなたの会社でソフトウェアのリリース後に起きたありえない障害

する仕事がなくなった

> あなたの会社でソフトウェアのリリース後に

リリース前、開発途中に会社がつぶれた...

リリース前のソフトウェアがなぜかすでに客先に入ってた。
いいのか？ひとつ誤ると人死ぬぜ？

営業が勝手にながしたのか？

QAって言葉はあまり知られてないな。
QAって何ですか？って聞かれた。

そういや仕様書に論理的に起こりえない場合の処理が書いてあったので
その部分実装しなかったら後で文句言われたな

あれは実装するべきだったのか、今でも悩む

>>338
お前、クビだよ。マジで。

>338
こんな感じ？
if(a==0){
　if(a!=0){ /* 念のための処理 */
　　...

>>338
>>あれは実装するべきだったのか、今でも悩む

コミュニケーションは取れない人でつか？

>>340
それはif文のダーリントン接続と言ってだな(ry

>>340
そこまであからさまではないが、
確かユーザーが入力するフィールドが３つあって、
その平均値を計算するところで
計算結果が０になったらメッセージを表示するんだったっけな

ところが入力フィールドには独自の入力チェックがあって、
そのせいで平均値は０には絶対ならないのね

まあ黙って作っとくべきだったんだろうな、
テストもできない処理を。

>>343
そのケースなら無駄でも作っとくのが正解でしょうな。

客の要望で入力フィールド仕様変更
→平均値0が発生しうるようになる
→「入力フィールド直すだけだよね?」
→「加えてメッセージ表示の改修が必要です」
→「既存機能だろ?」
→「起きえないので作ってませんでした」
→「仕様通り作れゴルァ」

なんてこともありうるし。

>344
なかなか奥が深いですな〜

>ところが入力フィールドには独自の入力チェックがあって、
>そのせいで平均値は０には絶対ならないのね

仕様変更もそうだけど入力処理のバグとか
別のところから呼ばれることになるかもしれないし
論理的に起こりえるじゃんw

ユーザインタフェイス側とサーバ側で両方チェックかけるのは基本だぞ

サーバー側で？何で？

自作クライアントとか、XSSとか、SQLインジェクションとか
有るでない

ライセンスの関係でモジュールが手に入らなかったり。

隣の部屋でライブラリ作ってんのに、なぜかアクセス不可で、
それを必要とする俺らはまったく別のスタブを作ってたり。

俺らがライブラリを作ってると、
このライブラリを、誰がどんな条件で使うのか
分からなかったり。
# 出荷直前に「スレッド跨いで使うから排他処理を入れろ」だと！？

あのぅ…。

大手メーカーのソフト品質保証部隊に、２次請けでフリーランスで入っているのですが、
時間単価2700ってどう思いますか…？
月150hとしたら405,000…。

30過ぎたし、子供だっているし、正直品保のキャリアパスが見えてこない…。

テスト部隊のリーダーにでもなればハクはつくんだろうけど、
自信はあってもチャンスがない…。

昔取った杵柄でJavaのPGにでもなった方が、女房子供にいいもん食わせられるんじゃ
ないのかな…。

でも、やっとスキになったのよ。テスト…。
マイヤーさんの本読んで鳥肌たって、テストPRESS読んで「開発の手下なんじゃ？」
っていう自分で嵌めた手錠からやっと解放されたのよ。

ねぇ、テスターって成り上がれるの？
進化して深化して神化して何になれるの？

路頭に迷うか、仙人かな

>>351
英語覚えて渡米しな。
あちらじゃ品質保証部隊は重要なポジションとして認識されているから。
下手な開発より給料もらえるよ。
今の君じゃ派遣PGがいいところだろうけど、それだと今以上にドツボだぞ。

日本じゃ疎まれることはあっても尊敬されることは滅多にないなｗ

>>351

　気長に待てばいいんじゃないかな。ISOやCMMなどが
世間一般に認知されて、品質そのものが議論されるように
なってきているじゃない？
　テスト関係の出版物はここ何年かで偉い勢いで増えてる
でしょ。

　私もテストチームでいろいろな製品のテストをしているが、
社内のポジションは低い。もう出世は諦めた。

　でもテストは好きなんだよなぁ。プログラムのように方法論が
確立しているわけでもないし、自分で工夫の余地があるし、
誇りもある。

　がんばっていきましょ

http://l.pic.to/2nlga

http://pc8.2ch.net/test/read.cgi/prog/1088135300/356

http://pc8.2ch.net/test/read.cgi/prog/1088135300/356

http://pc8.2ch.net/test/read.cgi/prog/1088135300/356

http://pc8.2ch.net/test/read.cgi/prog/1088135300/356

>>350
> 隣の部屋でライブラリ作ってんのに、なぜかアクセス不可で、
> それを必要とする俺らはまったく別のスタブを作ってたり。

ユニットテストするのならスタブ作るのなんて当然では？

「ユニットテストするのならスタブ作るのなんて当然」
フーン

最近よく雑誌とか出るし、アメリカじゃ重用されているし、
これから旬かも、って思うんだけど、自分の後から開発で
やってるフリーランス友達に
「え！？そんな安いの？」
とかいわれると焦っちゃいますよね。

しかも「品保って…コードとか書けない人が集まるところでしょ？」とか言われたり。
カチィィン、って感じ。

まぁ、今となっては「そりゃ違うな。開発だけで品質保てるなら別だけど」ぐらい言えるけど。

でも、自分も哲学科でやっと方法論って言葉を理解したけど、
テストの世界だったら確かにまだ方法論者になれる気がしますな。
…もちろん独自のテスト体系なんて大層なもんは持ち合わせてないけど。

でも、設計段階のモデリングで論理バグをなくしたり、
ユニットテストで安全性の高いコードをくんだり、
品保がソフトをもらう前段階の技術向上が盛んなのは
うれしいようなおまんまの食い上げのような。

品保も設計から参画すべきと思うんだけどなぁ。

つうか
ネットセキュリティが設計段階から深く関わってくるこの時代、
品保が設計から積極的に関わらんでどうかと思うが。
本当にソフトの品質を考える品保なら、どこも大歓迎だ。


実際はくだらない書類の提出ばっか気にする品保が多くてなあ。
口を開いてライブラリ論語りゃ、大NGを自慢げに話したり。

品質管理の会社を立ち上げて講習とかサポートとかすると良い感じかもね
あと、本とかも出して箔ををつける
「品質管理を委託するのがが当たり前」って風潮を自分で作って小さな会社に売り込んでいくのも良いかも
金額も吹っかけてから値引きすれ良い訳だし

なんかですね、メーカーの品保辞めてその会社の下請け会社
興したシャチョメンが言うには、

「みんなそう思うんだよ。あのIBMだって日本でやろうとしたんだよ。
でもやっぱ日本じゃダメなんだよ。
大手の口座でももってればその会社専門の子会社がいいところ。
徒手空拳で息巻いたって誰も鼻にもかけてくれないよ」

みたいな夢のないことをいうんですよね。

でも、本当こういう業界意識に風穴を開けられるのは品保からかも
しれないですなぁ。
そうすると団塊世代が総辞職する2007年ショックも、チャンスに
思えてくるかも。
本当、技術そのものじゃなくて、方法論を勉強しておけば良かったなぁ。

この手の動きの参考になるのは、インターネット黎明期（９７〜９９）に起きた初期セキュリティビジネスかな？

ハッカー（クラッカー）に御社のサーバがクラックされて
データを取られたり改ざんされたりクラッシュさせられますよ
と、啓蒙や営業したにも関わらず
ほとんどの会社は
・ＦＷなんて高いし要らない
・ウチにはそんな重要なデータは無い
・クラッシュしても復旧すれば良い
って感じで相手にもしなかった

０１〜０２年くらいに大量にクラックされて
ＦＷやセキュリティに関する意識が高まって
その手の雑誌やテクニックが普及してきた
そして、ここ数年で個人情報保護法が立ち上がったりして
法的な部分が追いついてきたわけですよ

そんなわけで、品質管理ビジネスも
経営者が切羽詰らない限りは動きが遅いわけだな

>>351
>時間単価2700ってどう思いますか…？
　税金込みのようなのでどうか知らないけど、 テスター
としては破格と考えます。

普通半分ぐらいかなと思います。

>>369
そうですか…。確かにパソナテックの「テスティングエンジニア」とかで
案件を見ても、しょっぱい数字が並んでますね…。

とにかく、
テストは開発リーダーが設計してバイトか下請けに肉体労働させるもの、
って風潮を変えたい…。

今は勉強するするしかないなぁ。

>>370

　そういえば、今年の開発環境展でエンピレックスが製品のデモをしている
ときにも

　テストをしてくれるバイト君に・・・

というようなプレゼンをしていたからなぁ。

　エンピレックスの製品はともかく、彼らはテストのことをわかってないんじゃ
ないかな。それとも開発会社の現場に沿ったプレゼンをしたことになっている
のか。

エンピなんてテストエンジニアを育成するのが
会社としての社会的役割でしょうに。

e-testなんてテストスクリプトが難解な上に
バグまであるくせにっ。

にしても、ATMのオンラインが信用できないからって、
お上が東京三菱とUFJの統合まで遅らせるご時世で、
>>368のご指摘通り切羽詰まらない
この業界（顧客？）のなんと足の遅いことか。

セキュリティとか品質なんて、金も時間もかかるもんだしねー。
開発「社」側からすりゃ、うざったいだけ
顧客「社」側からすりゃ、金取って遅れる言い訳
にしか見えないんだよな、実際。
開発スパンがメチャクチャに短期化されてきてるしな。

品質と開発か乖離してる開発会社って何？

コーディングも済んでテストしてるっていうのに
顧客側から正式な仕様書がこない…(ﾟДﾟ)ﾎﾟｶｰﾝ

客の口頭での仕様伝達をきちんと取ってあるかが勝負だな。
立場的にあってもしょうがないっていう場合もあるが、無いよりはマシ。

数字じゃないんだよ･･･　数字じゃ

>>375
怖いねぇ。出来上がっちゃっているとなるとなおさら、
仕様について言った言わないの不毛な争いが起きそう。
議事録がちゃんととれているかが本当に問題ですな。

それとも顧客はアジャイルな感覚の人？
余計まずいけどw

ところで、単体テストを本人以外がやる、って方法を
経験したことある人います？

xUnitのコードを他人、もっといえばテスト担当者が書いている
なんてところありますかね？

いや、独自フレームワークとかAPIのシステムテストなんて、
あって無きが如しじゃんすか？

単体テストもQAが引き受けちゃうのってどうだろうと思って。

単体にそんな手間暇かけられないかなぁ。
でもここでバグをつぶせたら相当なコスト削減ですぜ？

つか、〜手法〜手法ってでてくるけどググって意味を調べても俺はそんな問題で苦しんだことは無い。
やっぱ、論文ってなんか現場とは遠いんだよね。

と、いうわけで俺がテストでぶち当たった問題
�@仕様書が無い（取説すらない）
�Aどうでもいい詳細仕様が多すぎる（過剰品質）
�B重要な機能がわからない
�Cプログラム側からのアプローチが無い

だな。

つづき

�@はテストのやりようが無い。
そもそもこれじゃ何に基づいて、どうやって判断していいかわからない。
しかし、誰がみても「まあ、こんな結果になればいいんじゃね？」みたいなモンがあると
さほど問題にならなかったりする。（場合もある）
一見最悪のようだけど、テスト執行者がだいたいの動きさえわかっていれば大した問題ではないかもしれない。

�Aはあっても役に立たない。
どれが重要なのかわからない時点で無い方がまし。
大体、ここまで膨れあがっているとプログラムと一致してる項目の方がめずらしい。
すげーむかついたから、ちょっとでも仕様書と違う箇所をみつけたら全部バグ扱いにして提出したら
担当者がすげー怒りまくって特攻んで来たｗ（書いたのお前ﾀﾞﾛｗ責任もてよｗ）

�B�Aの派生。
つーかさ、小さい部分の定義があいまいなのはわかったけど、
要するに何ができてればＯＫなのよ？それができりゃべつにバグじゃないんでしょ？
ならそれを書いてよ。それだけを書いてよ。

�Cこれがないとどうでもいいところのバグをちょっと直しただけで
また、テストを最初から全部やれとほざき始める馬鹿がいる。
まったく関係無い場所のテストをもう１サイクルまわすよりはプログラマ側である程度
限定してくれない？そりゃすべてをチェックすればいいけどさ。お金も時間も有限なんだからさ。

と、まあ、みんなこんな問題なら似たような目にあった人いるんじゃね？

よくある話なんだけど、テスターの仕様の不理解で
バグ扱いされまくる時はちょっとイライラする。

>>382
わかり難い仕様書が悪いと反省するのか、
テスタがよっぽどアホなのか悩むところではあるな。

でも、まあ、「じゃあ、仕様書はそんなに完璧なのか？」っていわれたら
そこまでの自信もないわけで結局はお互い様ってことで説明責任はこっちにくるよね。
どっちが悪いにしてもそこで過去にこんな質問がありました。とか、こんな勘違いが起きちゃいました。
なんてまとめてあると今後の為に役に立つ。
１人、わからないってきたら当然２人目もくると思ってまず間違いない。
まあ、こっちの負担になっちゃうけどそこは譲りあい宇宙ｗ

うぅむ。「だからこそQAという考え方が存在する」という話題が続いていてよさげ。
#ここでいうQAは部署の呼称の事ではないよ。念の為。
でも品質に対する認識ってCMMみたいに多層だから、
各個人は各レスに対して「なに言っているかわかんない」とか
「レベル低いなぁ」とかの印象を持つような

>>384
なんとなくわかる気がする。
議論の発展のさせかたが難しいというか。
QAってその製品なり会社なりチームなりで風土の違いが色濃い部門だと思う。

たとえば仕様書。
自分のところ（少なくともオレ）は仕様書は評価の基準でもあり、
評価の対象でもあると思ってる。
だってシステムテストの段階ででも、仕様書がきっちりしているってのは
そうそう無いと思うんよ。
だから>>383のいう仕様の質問のまとめはこっちの仕事だし、メールなり
データベースなりで開発もQAも見られるところで共有してる。

UIがその会社のローカルルールに則ってないとかはばんばん出てくるから、
「仕様直せ」ってバグレポートも切るし。

でも、がっちがちのウォーターフォールで、「仕様書絶対。仕様書神。」ってのを
出してくるところもあるっちゃある。そういうところはさすがに仕様書もきっちりしてる。
＃開発手法はどれがいいかって議論はおいといてね。

関係ないけど、マニュアルチェックってつらい…。
読み物読んでるとすぐ意識が遠のく…。

【サッチャンのレス】
このレスを見た方は３日以内にサッチャンに異世界へ引きずり込まれます。
サッチャンの特徴は口が裂けていて内蔵が全て飛び出した女の子です。
死にたくない方は３日以内にこのコピペを１０個別のスレッドに書き込んでください。
僕の友達のY・T君もサッチャンに殺されました。

↑
実はコピペしてもしなくても変わらないのは>386にはナイショです。

どっちみちみんな不幸だからな。

�_�g�a�d�a�d　←これの下だけ読め

ブラック企業に勤めてる１年目なんですけど、ブラック企業のテスト部隊にいっちゃったら、３年働いてもホワイト企業に転職できなくなっちゃいますか・・？？
一応、３年以内に最低限の資格は取るつもりですけどねっ。ソフトウェア開発技術者

>　ソフトウェア開発技術者
目標低すぎ

>>391
ブラック企業にいる奴は一部を除いて大抵そんなモンだ。
まともな技術と頭がある奴がブラック企業になんか就職するかよ。

最低限って言ったじゃん。>>391-392
もちろん、資格ばかり勉強しても意味ないし業務についても勉強するさ。
で、ホワイト企業に転職するの難しい？今の会社はサービス残業があまりにも多くて不満タラタラなんやけど・・・

>393
>391はその最低限のラインが低すぎって言ってるんだろ。

学生でも余裕で取れるような資格が最低限って…。
程度に見合った職業に付けるようになっているとは、世の中って良く出来てるな。

> で、ホワイト企業に転職するの難しい？
スレタイを 100 回ぐらい読み直して出直してくるといいよ。

フリーのテスト管理ツールありますか？

あります。Web&DB Press　とかどう考えても思いつきでつくった テスト何とかプレスを参照。

ベンチャー系で単体試験をやらない所って結構あるみたいなんだが、どうなってんだあれば？
単体試験項目表のフォーマットはありますかって聞いたら、「なんですか単体試験って」って言われた。

あと単体試験をJUnitだけで済ませて、XPのおかげで品質が上がりましたとか言ってるアホいない？

XUnitさえ使わせないで、コンパイルエラーレベルからバグ票切りまくるアホはたくさん知ってる。

ブラック企業のテスト部隊にいっちゃったらって言ったでしょ。>>395

みんな真面目に答えてよ！！！ソフ開は調子よければ、今年の秋で受かっちゃうよ？
毎日夜遅いから全然勉強してないけど・・・。でも、前回のソフ開で合格点取ってます。

テスターは使い捨て
上がれることはないw

もうｵ�hﾙ

>>398
規模によるよ。
ベンチャーに限らず、数人でやっている会社なら、開発もQAもサポートも
同じ人や同じチームで担当することが殆ど。
中には同じ人が営業までやる会社もあるくらい。
そういう場合は開発プロセスもそれに適した形になるから、開発しながら
機能テストをして、最後に通しで全体のテストをして終わりってプロセスの
ところが結構ある。
まぁ開発費用もそれなりの金額しかもらえていないって現実もあるけどね。
ベンチャーや中小の場合、大手と違ってテストを細分化したり、ドキュメント
を嵩上げしても費用請求がしにくい現実があるから、しょうがないんだけどね。

君が単体テストのドキュメントを欲しかったり、単体テストをやって欲しい
のなら、「費用負担するから単体テストやって、このフォーマットに従って
ドキュメントを作ってださい」って言えばいいだけだよ。

>401
真面目に答えてるだろ。ソフ開じゃ最低限より下。
秋の試験はＡＥを取って、ベンダー系の中位資格を２つ。これが最低限。

>>403
テスト形式を指定してテストしてもらう分にはその通りと思うが、
品質に関しては単純にそんな会社に二度と頼まなければいいだけ。

最初はテスターが無難だよ。
暇があればソースを追ってデバック出来るようになれ。
最初はただ少しでも多く、色々な人の作ったソース見た方がいい。
資格はあと1年やったら、基本情報処理取れ。

>>401
俺、現役大学生だけど、基本情報とソフ開持ってるが履歴書に書かなかった。
理由は恥ずかしいから(笑)。Oracle Gold と CCNP は書いたけどな。

こんなもん社会人になって必死こいて取るなんてどうかしてるよ。

>401はなにがしたいのだろう。
開発？QA技術者？
前者だったらスレ違いだし、
後者だったら資格以前にすることがあるだろうに。

目的より手段が先になっちゃってる人っているね。>オレ

>>407

実務経験＋資格＝その人のレベル
資格のみ＝ふーん。がんばってるんだね。で？

も一つ。実務付いている人が資格取得すると、自己研鑽やってるんだな、という判断材料の一つになる。

あぁ、途中で送っちまった。

も一つ。実務付いている人が資格取得すると、自己研鑽やってるんだな、という判断材料の一つになる。
中には、業務が忙しいということを盾に、まったく自己研鑽しない馬鹿がいるから。

>>409
学生なら資格取ってりゃそれなりに評価されるだろ。実務できないんだから。
アルバイトなんか多少評価対象にはなるだろうが、実務に入らんしな。資格は
あるけど実務経験皆無 or 糞企業のみ、で評価されないのは新卒じゃない場合。

学生がORACLEの資格とかとっても、英検とかの同じにしか見ないよ。
実務で一月みっちりやれば知識レベルはそこまで十分いくし。
そもそも、資格もってるからっていってその学習端折るわけにも行かないし。

大体、ペーパーORACLE資格者にDBサーバ触らせられるか？
結局、実務の伴わない資格は、がんばったで賞でしかない。

>>413
話をしているのは評価の対象になるかならないか、だ。
現場で使えるか使えないかとは別の話で、切り離して考えないと。

一方は現場でソフ開取って御満悦の実務者。一方は新卒の「頑張った子」。
どっちが会社のためになるか。どっちが使えるエンジニアになるか。
どっちが「先がある」のか。

大抵の人事は新卒の学生を評価するんじゃないかと思う。
資格なんか持ってなくても評価できるような凄腕のエンジニアは評価されるべき、
という主張があるだろうが、テスター１年生君がそういう奴だとは俺には思えないな。

>>414
だから評価してるじゃん、がんばったで賞だって。

> 一方は現場でソフ開取って御満悦の実務者。

1年生が「目標はソフ開です！」って言っただけで
「ご満悦」なんて言っちゃうほうがどうかしてると思う。

>>416
>>401 は資格取ったら満足する。
資格取れなくてもホワイト企業に行ったら満足する。
そういうのって文体から滲み出るんだよなぁ‥‥‥。

スレ違いの話だからここで切るか。

>>417は自分の欠点を他人に投影して叩くタイプだな。

>>411
>>中には、業務が忙しいということを盾に、まったく自己研鑽しない馬鹿がいるから。

すいませんね。

やはりこれからの競争時代、品質管理や出荷後バグのクレーム処理は
これ位割り切らないと駄目だよな。
　　　↓
ttp://sinjya.milkcafe.to/cgi/up/log/1741.xxx

>>420
個人ならＯＫだが、会社としてはＮＧ。
しかも、「いただきじゃんがりあんR」はゲハ板でも聞いた事がある。
３Ｄまわりのバグよりも、麻雀にすらなってないくせに
グラボのせいにするなんて言語道断。嘘は駄目。

>>420
割り切りというよりも開き直りだろ。
まぁいってることが本当なら、新技術を導入するのに、ろくなテストもしないで
導入しているあたり論外だけどね。

>>420
ﾜﾛｽw

業界がこういう馬鹿ばっかりだったら
まじめにQAに取り組んでいる人の給料も上がるだろうになぁ。

でも、こういう元請けっていそうで怖いね。
「まず外注に文句言えっての」みたいなのね。

エロゲじゃあ当たり前の世界なのか…。怖いなぁ。

＞「バグ報告についてもメールでくれといっても、サポートBBSに書くんですよね。
＞あれを見た何も知らない人は、『ああ、いたじゃんRはバグが多いんだな』
＞と思って買わなくなる。それで何割か売り上げが落ちてるのは確実なんですよ」

おいおい、実際にバグが多いソフトを買わせる気マンマンですか。

これで食っている　という事実が素で羨ましいねぇ

おまいらの会社から製品買いたくなくなるのは俺だけか？
オッソロシー会社が多いな。

どこもそんなもんさ

カミングアウトしてるやつはまだましなのさ
本当にやばいやつは匿名掲示板でさえかけない

ヤバイ。宇宙麻雀ヤバイ。まじでヤバイよ、マジヤバイ。
宇宙麻雀ヤバイ。
まず異常。もう異常なんてもんじゃない。超異常。
異常とかっても
「バグをそのまま入れちゃった感じ？」
とか、もう、そういうレベル。
何しろ仕様。スゲェ！なんか七対子とか無いの。
何翻とか何符とかを超越してる。仕様にしては超異常。
しかも数牌がループしてるらしい。ヤバイよ、ループだよ。
だって普通の麻雀はループとかしないじゃん。
待ち牌が増えすぎて、普通の麻雀のときはロンできたのに、
宇宙麻雀のときは待ち牌がわかんなくてフリテンとか泣くっしょ。
だから普通の麻雀とかではめったにフリテンしない。話のわかるヤツだ。
けど宇宙麻雀はヤバイ。そんなの気にしない。フリテンしまくり。
自分の捨て牌とか観測してもよくわかんないくらい待ち牌多い。
ヤバすぎ。 仕様っていたけど、もしかしたらバグかもしんない。
でもバグって事にすると
「じゃあ、宇宙麻雀をあえてそのまま導入するメリットってナニよ？」
って事になるし、それは誰もわからない。ヤバイ。
誰にも分からないなんて凄すぎる。
あと超電波。マジカルリンスでマックスハート。
ヤバイ。電波すぎ。聴牌でリーチする暇もなく死ぬ。怖い。
それに超聴牌速い。誰からでもチーできる。ドラのみで和了れる。
ドラのみでロンとか平気で出てくる。ドラのみて。初心者でも言わねぇよ、最近。
なんつっても宇宙麻雀は馬力が凄い。字牌だらけの配牌とか平気だし。
うちらなんて字牌とかたかだか役がつくときにポンするだけで
上手く扱えないから対子にしたり、地獄待ちに使ってみたり、
国士無双狙ったりするのに、 宇宙麻雀は全然平気。
字牌を順子のまま扱ってる。凄い。ヤバイ。
とにかく貴様ら、宇宙麻雀のヤバさをもっと知るべきだと思います。
そんなヤバイ宇宙麻雀を創ったすたじおみりすとか超偉い。
もっとがんばれ。超がんばれ。

>>429
なげーよ。一行に纏めろ

>>430
宇宙麻雀最高！

>430
麻雀のルールが奇妙なのは、Direct3Dのせい。Microsoftが悪い。

麻雀用APIかぁ。作ったら面白そうだな。
少なくともそのDirect3Dに含まれる麻雀ルールクラスライブラリよりは
QAのオレでもましなのが作れる自信があるなw

そんなAPIのテストだったら面白いのになぁ…。

てゆうか、麻雀の役のチェック方法ぐらい調べればすぐにでてきただろうに・・・。

点数計算ライブラリと、配牌XMLスキーマをお願いします。

>>435
役判定だけならすぐみつかったけど点数計算ってむずかしいのけ？
http://www.onionsoft.net/hsp/mahjong.txt

>>436
作ったことあるけど、別に。
青天井だと、最高得点の手見付けるのだ面倒かな。

つか不完全情報型のゲームなんて探索しなくて済むから簡単なのにな。

だれかニッカギレンのシンポジウム行く人いない？
ttp://www.juse.or.jp/software/symposium_20050908_1.html

仕事休んでいくんだけど、プログラムが多すぎてどれを受けていいやら。
「この人・この講演だけはガチ」ってのがあったら教えて〜。

そうだ選挙に行こう

>>438
漏れがつくったマージャンでは、見えてる牌のみから探索。

最近、客先でクレームがでんたです。クレーム。
そしたらなんかバグがいっぱいあって使えないらしいんです。
で、よく調べたらなんか派遣PG達がコーディングだけして設計やテストしてないんです。
もうね、アホかと。馬鹿かと。
お前らな、コーダー如きの実力でPGのふりをしてんじゃねーよ、ボケが。
偽装だよ、偽装。
なんか上司は別担当の俺に最終チェックしろとかいうし。責任範囲は無視か。おめでてーな。
誰ならサポートできる?とか不安そうに質問してくるの。もう見てらんない。

お前らな、派遣元にクレームいれてやるからその席空けろと。
派遣ってのはな、もっとプロ集団であるべきなんだよ。
派遣PGの机の向かいに座ったプロパーSEといつ設計・テストの議論が始まってもおかしくない。
指摘するか指摘されるか、そんな雰囲気がいいんじゃねーか。PG偽装コーダーは、すっこんでろ。
で、やっと緊急リリースまで終了かと思ったら、上司が徹底した品質管理を、とか言ってるんです。
そこでまたぶち切れですよ。
あのな、品質管理なんてきょうび流行んねーんだよ。ボケが。
得意げな顔して何が、品質管理を、だ。
お前は本当に周知徹底のコストを分かっているのか問いたい。問い詰めたい。小１人月問い詰めたい。
お前、品質管理って言いたいだけちゃうんかと。

SEの俺から言わせてもらえば今、SEの間での最新流行はやっぱり
人質管理、これだね。
職責への意識、スキルが低いと分かったら即メンバチェンジ。これが通の派遣社員の使い方。
業務系PGってのは程度の低い奴が多めにいる。そん代わり優秀な奴も単価が同じ。これ。
で、そこからダメな奴は派遣元へクレームいれてまともな奴へチェンジ。これ最強。
しかしこれをやると次から斡旋してくる上司や部署にマークされるという危険も伴う、諸刃の剣。
保身重視の奴にはお薦め出来ない。
まあプロジェクトチームを開発のソフトウェア製品とした時にバグは除去しなさいってこった。

おもろない。

じんしつ　と読むのかな
ひとじち　と読んだけど

テストしとらんAさんに
しゃあないからテストケース作って渡した。
「できました。ソースあげときます。」
いうたが、嫌な予感したんでこっちでも
テストしたらテストケースの半分以上NG
になってもた。

厳重注意して、やりなおしさせた。
「ソースあげときましたから・・」
いうたが、まだ何ケースかダメやねん。

メンバチェンジしたいけど権限ないねん。
やっぱ自分でソース直すしかないんか。

>テストしたらテストケースの半分以上NG

ここがおかしいだろ
なんでテスト全てパスしないとできたことにならない、ってしてないんだ?
もまえバカなのか?

>>446
それはAさんは勤務中に居眠りするほどの
「人外」の域に達しているお方やからや。
本番障害でお客さんに
「ボタン押すと必ずエラーでますよね。動作確認大丈夫なの。」
いわれたことがある。
確認シートには確かにAさんが結果「○」をいれとる。
つまり、Aさんにとっては間違いなくパスしたんや。
だからAさんも「あれ？おかしですね」と不思議がって
おられた。

日本人はやさしい民族やからAさん切れんのやけど
仮に切ったとしても、別の案件に参画してくだけやな。

やってはいかんと思いつつ、リリース期日の都合上で
自分でソース直した。とりあえず、Aさんは放置や。
今日帰り際にお客さんから別件の障害連絡があったん
で至急対応せなあかん。これはBさんが作ったところや。

ペアプロみたいにペアテストが必要かのう。
まあ試験結果にエビデンスの添付を義務付けるという方法もあるが

> 確認シートには確かにAさんが結果「○」をいれとる。

目視で手書きってことなのか
いまどきw

xUnitつかいなさい

昔、協力会社が仕上げてくるプログラムの品質があまりに酷くて
上司が品質向上のためにエヴィデンスの添付を義務づけたら
上がってきたエヴィデンスが偽装されてたことがあったり。

>>451
普通そうなる。
てゆうか、絶対そうなる。
ただでさえ、一杯一杯のところにさらに追加作業を送っただけに過ぎない。

レビューではより多くの改善や問題抽出をするのを信条として
個人の能力や責任を追及することは避ける。
しかし、IT景気にのって低質・悪質な作業者が増えた現状では
責任追及や処罰も明確にしておく必要がある。
うっかりではなく、ちゃっかりミスしてることを見抜くべきだ。

一番の問題点が「赤字になってしまうこと」だとしても
契約主体である組織の担当者の責任は追求できないけどね。
>>453
責任追及や処罰って何をするの？
具体的に言及してくれないとｗ

技術者の品質管理をしないで、生産物の品質管理しても無駄だってことに早く気づけよ

>>455
逆じゃないか？

上司にバグ要員の存在を報告しましたが
「今から人を変えるのは現実的でない。」
との返答でした。
悲しいけど、これ現実なのよね。

ガンダムヲタは氏ね

あんなの飾りです。偉い人にはそれが分からんのです！

今日、
品質管理（QC）と品質保証（QA）の違いが
わかったよ。

オレも大人になったなぁ。

うむ、モレも
森と林
サスペンスとミステリー
クッキーとビスケット
ワンタンとギョウザ
の違いがわかったよ。

大人になった。

んじゃその境界はどのあたりよ？とか言ってみる試験。

1.皮が四角であること
2.ニンニクが入っていないこと
3.揚げるか、スープに入っていること

ぐらいをテストすればよい？

4.肉を入れない
5.生で食す

とか異常系もやっておいた方がいいかな？

6.小麦粉を洗剤で洗わない
7.針を混入しない

もやっておいた方がいいと思う。

QCもQAもしったこっちゃないって２，３年生が職場を牛耳ってる会社からきましたよ・・

なんとかやっつけコード書きの連中を更正・・・
むりぽ。

それにしても、役人って絶対、要件定義書に承認印押さないよなー。
無茶苦茶だよ。

めちゃくちゃな品質

作るもの、作業標準、社内ルール、を明確にせずに

ただやらせて成果物で儲けるだけ。
そんな都合の良いものづくりは在り得ません。


自分が育てられた、時間を与えられて今に至った・・・
その過程を与えずに、成果を咎めるだけなら
全部自分でやれよ。

社外アウトプットが全て。

ウチの社内 Web に用意された QA 掲示板が
Q&A 掲示板に成り下がっている件

今更な仕様の確認とかされると萎えるな
仕様書作って確認とって開発を進めてるんだから、仕様書読み直せと。
担当者が変わった場合でも、これまで交換したプロジェクトに関するメールくらい引き継いどけと。

仕様書を作った、という事実を作るための仕様書に
品質管理やってますよ、という為だけに作られる品質管理。

えーと、ニホンゴッテミズカシイﾈｰ

役に立つ仕様書はみんなの心の中にある。

仕様書って、ちょっと切ないものなんですね。

SQL> SELECT COUNT(*) FROM 作業者テーブル
　WHERE 自分のコードは責任もって全てのパスは一回は通すぞ区分 = '1'

COUNT(*)
----------
0

セットアップデータの不正でトラブルことはよくある。

自分で記述したコードの全てのパスは確認してほしいものです。

全パスやってるかは知らんが・・・
先日、eclipseでWebAPのデバッグのやり方を
教えてもらって舞上がっていた奴がいたぞ。

今までは System.out で大変だったそうだ。
これからのプロジェクトの貢献に期待したい。

「僕にとっては突然すぎて」
「私にとっては遅すぎたのよ」

似たようなコードを量産する人は
全パスの確認などするわけもなし。

品質は納期に勝てない宿命なのです。

MS って製品のリリース延期して
ぎゃーぎゃー言われるけど、
MS の中のプログラマにとっては優しいよな。

>>481
それは・・・少し違う。リリースすると企業生命にかかわるからリリースしないだけで。
延期はMSが自分の身を守るために決定される事項に過ぎないんだ

> MS の中のプログラマにとっては優しいよな。
そうだな。
あの品質で許されるのはうらやましいよ。

>>483
その品質はどこと比べて？
世界最高レベルかと思うが。

>>484
メインフレーム

>>485
>>480-484

>>485
あぁ、ハードウェアと比べてんだ・・・・

>>488
おーい。
何が悪いか分かりやすく端的に表現することも、
テスターの役目の基本だぞー。

COBOLのバッチのプログラムにたいしてだったらＴＤＤって有効かしら？

COBOLのバッチのプログラムにたいしてだったらＴＤＤって有効かしら？

テスト仕様書を書くうえで参考になるような書籍を教えてください。

ttp://store.nikkeibp.co.jp/item/contents/m_482228154X.html

最近はそっくり真似することを参考にする、と言うの？ｗ

あるいはインスパイアとも

インスパイアと言えば、日立のプラズマのCM
パナとどっちがインスパイア？
w

目立のサ技師はだまっとれ

Inspire The Next

↑
未来を見つめて現実逃避。

俺の屍を越えてゆけ、ってことなんだよきっと

原子力発電所 ( 以下、原発 ) についてもっと知ってほしい
http://members.at.infoseek.co.jp/genpatsu_shinsai/hirai/pageall.html

・原発は地震が発生すると壊れて大事故がおきる。
・原発は放射能を海に流している : 原発を冷やすための冷却水は放射能を含むようになり、それを海に捨てている。
・原発は放射能を海に流している : 放射能がついた放射能防護服を水で洗っている。
・日本ではチェルノブイリに匹敵する大事故が起きそうになった ( 最高に運がよくて助かった ) 。
・原発で発生する放射性廃棄物を捨てるところがない。
・原発で発生する放射性廃棄物は昔は海に捨てていた。
・原発で発生する放射性廃棄物はドラム缶に詰めているがドラム缶の耐久性は低い ( いつかは崩れて漏れる )
・放射性廃棄物を管理するのに原発で生み出す以上の電力 ( そして石油 ) が必要になる。
・そしてその放射性廃棄物は日に日に増えている。
・放射性廃棄物を詰めた「ドラム缶の近く」にいただけでも数時間で死ぬ ( 数秒で死ぬほど高レベルのものもある ) 。
・原発の煙突から放射能は漏れている。

http://members.at.infoseek.co.jp/genpatsu_shinsai/hirai/pageall.html

テスト計画責任者っつー、一番嫌な担当を押し付けられた漏れが来ましたよ。
まだ製造も始まってないんだが、結合試験計画＆項目抽出はまあ出来るとして、
単体試験計画＆項目抽出ってどうすんだよ ('A`)
項目抽出に耐えうるだけの設計書が無いんだが、、、


ていうか、今まで鯖サイドとか組込みとかのプロジェクトだったんだけど、Web画面
系？のCTでも項目抽出の観点は変わらない？

プロマネは机上の空論プロマネは机上の空論プロマネは机上の空論プロマネは机上の空論
プロマネは机上の空論プロマネは机上の空論プロマネは机上の空論プロマネは机上の空論
プロマネは机上の空論プロマネは机上の空論プロマネは机上の空論プロマネは机上の空論
プロマネは机上の空論プロマネは机上の空論プロマネは机上の空論プロマネは机上の空論
プロマネは机上の空論プロマネは机上の空論プロマネは机上の空論プロマネは机上の空論
プロマネは机上の空論プロマネは机上の空論プロマネは机上の空論プロマネは机上の空論
プロマネは机上の空論プロマネは机上の空論プロマネは机上の空論プロマネは机上の空論
プロマネは机上の空論プロマネは机上の空論プロマネは机上の空論プロマネは机上の空論
プロマネは机上の空論プロマネは机上の空論プロマネは机上の空論プロマネは机上の空論
プロマネは机上の空論プロマネは机上の空論プロマネは机上の空論プロマネは机上の空論

>>502
文句言ってるヒマがあったらソース読もうね　(^O^")/

>>502
開発に投げれば？

●ソフトウェア・テストの技法 第２版
http://www.kindaikagaku.co.jp/bookdata/ISBN4-7649-0329-6.htm

テストの古典っていったらこれ？

PGから修正をもらってエラー出すのがたのしかったなぁ
対策してもらう度にCPUがだんだん強くなって行く感じ

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●
プログラマーになってみたい人は、まずこの本を読んでみて下さい
●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

＜仕事に必要なスキルのチェック＞
http://www.amazon.co.jp/dp/489100455X/
Code Complete第2版〈上〉―完全なプログラミングを目指して
http://www.amazon.co.jp/dp/4891004568/
Code Complete第2版〈下〉―完全なプログラミングを目指して

プログラムのうまい書き方がキッチリと紹介されています。
逆に言えばこれを知らないと、プログラマーになってもプログラムがうまく作れなくて苦労する可能性があります。

＜仕事に必要なやる気のチェック＞
http://www.amazon.co.jp/dp/4822281108/
ピープルウエア 第2版 - ヤル気こそプロジェクト成功の鍵

（どんな仕事でもそうですが）仕事に対して「感謝」の気持ち、「喜び」の気持ちが持てなければ、やる気がなくなります。
プログラミングが楽しい＝「喜び」、関係者のみんなありがとう＝「感謝」の気持ちが持てれば、多分長続きしますよ。

Code Completeの日本語訳って上下に分かれてるのか。足すと一万越えそうだな。

CodeComplete上下揃えるのがつらいなら、達人プログラマ1冊きっちり読めばいいよ
そこからテスト技法やらプロジェクト管理に手を伸ばせばいいだろうさ

いや普通に品質会計やれば大概OKなんだが、いまだにやってない会社あるもんなぁ。

あげてみる

>>46
Windows なら WinBatch でやってるよ。

行政管理室に電話をしました。中渡瀬氏のことも聞くために。
担当者、西氏と電話が繋がりました。
流出の件を聞くと、担当の者（上の者）がいないと言われました（まただｗ）
担当者は、何名いるのか聞くと4名だと回答をもらいました。
中渡瀬氏については、今回の処分で最終だということでしたが、任天堂のROMの件。
被害者女性の画像を削除しないで、自分だけの画像を削除した件や、県の職員が第一発見者なのか聞いた所、私個人はそこまでわかりませんという回答でした。

中渡瀬氏に電話を代わるように伝えると、えつだ氏という人が電話にでました。（さっき上の方はいないといってましたが、いましたね。また嘘ですか＾＾；）
中渡瀬氏は、行政管理室にいないので代われないと言われました。
熊毛支庁に電話をすれば対応してもらえるみたいです。

今回の1300名〜1400名の情報流出と裏金の資料について問い詰めました。
そうすると調査中とのことでした。
情報を流出した疑惑の人についても事実確認と調査中との回答でした。
電話は、17分（録音済み）しましたが、まぁ予想通りの回答でした。
流出した件についての対応はどうするのか聞くと、個人については、対応を検証中。
流出した情報は一生ネット上で出回りますが、どう対処するのか聞くと、それについてはそのような専門部署があるのでそちらでと言ってました。

嘘で固められた鹿児島。
身内擁護の鹿児島。
県民の皆さんには大変失礼ですが、この鹿児島県庁は、本当に終わっています。
腐れすぎです。
今後も間違いなく、流出は続くと断定しておきます。
http://www.mudaijp.com/wp/?p=405

話題無い？

やる事さえやってれば話題は無い

じゃ、こっそり相談。

うちはWFな工程で開発を行っている。
最近自分が品質を品質判定会議の開発側資料を作成してる。
前任者はデータをグラフにまとめて終わりって感じだった
んだけど、もう少し何とかまとめたいって思うんだよね。

で、問題が各工程の検出バグ数やらドキュメント量やらと
品質保証グループのテストのバグ数の因果関係を明確に出
来ないって事。
せいぜいコーディング量が多いとバグが多くなるっていう
ぐらい。

統計に関しては二変数の分析が出来るぐらいしか知識は無
いんですが、皆さんの所では各開発の品質をどう判断する
べく分析されてるんですか？

とりあえずあげる。

>>517
テンプレからバグ原因とか選ばせるやつか？
あんなのインチキだよ。直感的にわかれよ

もしインチキならインチキで構わない。
ただ、それを直感ではなく数字で示す為の努力をしたいんだ。

遡って読んだけど、ここは実装系が多い。
どちらかというと、ここじゃなく情報システムで訊いた方が良いかもしれないという気がする。
それと多変量解析ぐらい出来ないと駄目かもね。

>>520
インチキでも構わないって、あんた面白いこというねえ
いったいそれってなんのための努力なの？

そういう方向に走り出すと、やることばっかりどんどん増えて
利益率が低下するだけで碌なことがない

このバグは仕様書が曖昧だったことに起因する→仕様書を
もっと詳細に記述しよう、なんつってな

「決められた工数の中で」高い品質を得ることが出来なきゃ
意味が無いのにな。

工数そのままで品質上げたきゃ
傘でも回してろと言いたくなる事はあるｗ

いつもより多く仕様書書いてまーす
いつもより多くテストしてまーす

でも、結果は（ry

勘違いされたようだが。
自分の立ち位置は明確で、品質管理の門外漢で在るが故に会議で語られる数字の意味が信用出来ないんだよ。

だから分析したいんだ。
その結果、統計的な意味を持たない事が証明されなら定量的な分析を止めさせたい。それこそ誰も救われないだろ。
逆に意味ある結果が出るならそれに従うべきだろうと思う。

前者をインチキな結果と表現した。
誤解を招いたかもしれないが、自分自身がソフト屋だから楽したいってだけだ。

申し訳ないが、知恵を貸してはくれないか？

>>524
何を甘ちゃんみたいなことを言っている

意味の無い数字を出す→誰も救われない
ここには論理の飛躍があるだろ。わかってるはずだ

済まん。意味がない数を出すというのは同時に数字の分析に意味
がないって事を証明するって事が言いたかったんだ。
数字はドキュメント枚数やら評価項目数やら上流比率やらね。
（うちはWFやってるんだ）

伝わるかな？
数字に意味がないというのは品質向上施策ってやつにに効果がな
いことを示しているんじゃないか？
にも関わらず上は分析に従って開発側を締め上げて、開発側は無
茶なスケジュールの中、工数をやり繰りしてる。
良かれと思って締め付けても結果が出ない。
救いが無いと思うんだけど。

>>517
○ うちの商品開発の場合
信頼度曲線書いて、予想バグ件数出して、
大体バグ検出率が95%超えたら商品レベルと見なしてる。
まぁそれだけで判断するわけじゃ無いけどな。
結構判断におけるウェイトはデカい。

仕様変更が頻繁に入ると収束しなくて困る。
仕様変更入った場合のバグメトリクス解析はまだノウハウがあんま無い。

とりあえず、品質管理の考え方、出来ればソフトウェアの品質管理
にも言及している本を紹介して貰えると助かる。

>>526
最終行がそのまま結論で問題無い

救いが無いんだよ、実際

測らないより測った方がマシ。

確かに今の分析能力では因果関係を導き出せてない。
所詮統計をかじりだして半年程度だからね。
いいアイディア無いモノでしょうか。


計った方がましって、その数字に振り回されて倒れるまでクリクリ
間抜けなダンスを踊りたいのか？

とりあえず何かを計ってみる。
計ってみて役に立たなかったら、なぜ役に立たなかったのかを分析する。
それを元に役に立ちそうなメトリクスを模索する。

計らなかったら何も変えられない。進歩しない。

間抜けなダンスを延々踊るハメになるのは、そいつが間抜けだから。

まぁでも計った結果『犯罪者の98%はパンを食べている』とか結論付ける奴ばかりだろ

・C言語では10行に1個のバグがある
・C++では15行に1個のバグがある
・Javaでは20行に1個のバグがある

とか、ソース上のCRLF記号の数を数えて真剣に議論するとかアホ以外の何者でもないぞ

その理屈もっともだ。
だからこそ、分析手法を訊いてみた。
話が最初に戻ったんですが、よろしくです。

何かを測定することが無意味といっているのでは無く、
「バグ数や故障原因をグロスで測定すること」が無意味と言っている。

バグ数や故障原因？
納期が短いからに決まってるじゃないか

測定すべきはプログラムの品質ではなくてテストの効果なわけだが、
テスタビリティはプログラムの問題という側面もあり、その辺は悩ましい

>>535
なんで無意味って分かる? 確かめたのか?

>>538
無いものは確かめられんぞ。悪魔の証明っていってな。

ならば、どういう意味があると思う？

>>537

極々当たり前な話だけど、データを解析する目的は予測する為だろ？

ここでは予測したいのは潜在するバグ数であって、テストが予測され
るバグを検出した事を持って品質を満たしているって判断するよね。
つまり計測するべきはテストの効果じゃ無いのではと思うんだけど。
あくまでソフトの品質を示すと思われる数値じゃないかな。
勿論、何処に着目するべきなのかが判断つかないんだけど。


良ければもう少しかみ砕いて説明して貰えないだろうか。

>>539
相関が無いことは統計的に否定できる。無意味と主張するには、無意味である
証拠が必要だ。

悪魔の証明って、何か勘違いしている奴が多いな。

品質管理の仕事は給料いいのかな？ＰＬやＰＭ、コンサルと比べて。
あと、ＰＬに向かないやつでもできそうかな？

潜在バグ数を予測し、検出したバグが予測したバグ数に達すれば合格とする


ってやると、示された分だけバグを作りむ
などという自作自演があったりするのが現場の恐ろしさだったりもするw

>>541
そりゃ「何かと」相関が無いことは否定できるだろ
「何か」は何だよ

>>540
COBOLじゃあるまいし、潜在するバグ数が何かの数字から本当に予測可能と思うか？

品質＝客先トラブル数÷販売数

>>545
百行書いたら十個バグが出るとは言えないが、バグの数は書いた量には比例
するでしょ。百行で十個の人間が千行書いても十個とかはありえんからな。

今は昔と違って、ローカルに環境作れて、UT以前の簡単な動作確認や検証で
昔なら故障表をきってたようなバグを事前に潰せるようになったんだよな。

だから、UT以前の稼動状態や、個人差がかなり出るようになって、それこそ
昔の感覚でステップ数に対して潜在バグ数なんてことをやったらバグを捏造
することにもなってるんだよね。

バグ数の自演ないし数字の操作があるとしても、品質管理グループ
は数字を求めてくるし、それを止めさせるには彼らに通じる言葉で
説明する必要があるだろう。

COBOLでも予測は困難だろうね。
無理という事を証明するのはこれまた難しいが少なくとも統計的に
無相関である事を示す必要があるという認識で正しいと思ってるが。

ベンチマークに>>546を使用した場合、各工程毎のアウトプットと
単相関係数を求めたが、ほぼ０に近い値になる。
分析のやり方について意見を求めたいんだけど。

これは、たいへ便利。使ってみて。

http://95.xmbs.jp/rnja3126/

>>517
＞で、問題が各工程の検出バグ数やらドキュメント量やらと
＞品質保証グループのテストのバグ数の因果関係を明確に出
＞来ないって事。

コレはね。
製品の品質ではなくて、開発のプロセス品質を評価するための物ではないかな？

各工程においてバグが混入された工程と発見修正された工程を調べる。
すると、どこ工程が悪いか見えてくる
(仕様書レビューが足りない、コードレビューが足りない、PT、ITが足りない)。
理想は混入した工程において発見されること。

例えば混入工程と発見工程の距離を点数化すると、定量的に評価できる。

この方法は1つの開発で完結するものではなくて、
いくつかの開発で計測を続けて比較することに意味がある。

>>548
>無理という事を証明するのはこれまた難しいが少なくとも統計的に
>無相関である事を示す必要があるという認識で正しいと思ってるが。

だからさ、何と何の相関の話をしてるの？

そこをきっちり定義しないと
「統計的に>無相関である事を示す必要があるという認識は正しい」
これって命題として成立してないよな。
つか、それを簡単に定義できるなら分析なんて楽なもんだわな。

単に無理ということを証明といっても「ありとあらゆる要素と」相関が無いことを
証明しろっていってるのに等しいだろ。だから悪魔の証明だといっている。

>>517はソフトウェアテストPRESSvol2を読めばいいんじゃないかな？
vol1以外はあんまり面白くないけど参考程度にはなるだろう

>>551
なんで証明出来ないと分かっていながら無意味であると断言するかね。
あんた、えらい不誠実な人間だな。

悪魔の証明云々っていうのは、主張(例えば有罪)を覆すのには
根拠が無い事を示せば良いのであって、逆の主張(悪魔の証明)を
する必要が無いって事だ。それなのに、わざわざ逆の主張を
するのであれば、根拠を示す必要がある。

>>553
常識的に考えて、バグ解析が無意味っていってるのが
そんな厳密な意味において「無意味」って言葉使ってるわけが無いじゃない

あなたがもし、どういう状況化で何かと何かの間には相関があるって主張してるんだったら
まずそれををきちんと定義してみてよ。

こっちは、その命題がどんなものであれ、命題が真であるって条件を満たすものであれば
それは相当限定的なコンテキストでのみ成立するものであり、現実問題役に立たない可能性が
高いんじゃないのって思ってるだけだよ。
ヒューリスティクスつか経験則でね。

>>550
幸いな事に10年以上蓄積してきたデータが存在している。

自分は開発工程と品質保証グループのテスト結果の因果関係を
明確にして、その結果によってユーザで発生するトラブル件数
を予測したい。
貴方の言葉を借りるなら開発のプロセス品質を元に製品の品質
を予測したいと言う事？
使用している用語が厳密には間違えてるかもしれないが、ニュ
アンスは伝わるでしょうか？

>>552
参考にしてみるよ。ありがとう。

>>551
フレーム問題を起こさない程度にフィルターはかけるが、今は
集計したデータ全て相関を求めようとしてる。

横から悪いが、議論の為の議論に興味は無いんだよね。

バグ解析自体には意味があると思っている。
ただし、設計が入力した情報には意味がない。そこには責任回避したい主観的な情報が含まれるから。
発生した機能、発生したI/F、発生させた人間等そういった客観的な統計データは意味がある。

もちろん、規模（サンプリング数）にもよるとは思うが。

主観が含まれない客観的なデータに着目したとして、それの解析に
どんな手法を使用すればいいと思う？

組み合わせで単相関係数を計算する程度ではぶれて意味あるように
見えない。
明らかに線形的な因果関係が読み取れない。
自分には。

仮に分析に必要なデータが無条件に取得できると仮定して、じゃあ
どんな分析手法を取れば良いだろうか？

当然複数の要因を考慮すると、多変量解析なども視野に入れるべきだ
ろう。
ところで統計にこだわる必要が無いかもしれない。

良い案希望。
ひとまず550の案に着手するべく出社します。

>>559
> ところで統計にこだわる必要が無いかもしれない。

うん。
あくまで顧客や上司に説明するためのネタでしかなくて、それで単純に品質があがるとかはないと思う。
品質は設計時に作りこむもので、生産物から摘出することで向上するものじゃないと考えている。

バグが多い機能とかが見えてれば、そこを重点的に見直し実施するなど、ある程度の意味はあるかと思うけど。

１．コンサルタントがやってくる。
２．過去のプロジェクトが数字で示される。
３．ありがたい助言を頂く。
４．新規プロジェクトにおいても数字がはじかれる。

どんなプロジェクトにおいても、なぜか常に改善されている。
これ、コンサルタントの常套手段なｗｗｗ

>>561
統計に拘る理由は定量的に示す事が出来るから。
愚痴になるが、ソフト開発を経験していない人間が上に立って、
実体を伴わない数字を振りかざして周囲を振り回している状況
は何処も変わらないんじゃないか。
彼らも良かれと思ってやっているし、正しいと信じてるだろう
けど。そうじゃないと言うにはそれなりの武装が必要だ。

申し訳ないけど、プロセス品質を評価する為にはどんなデータに
着目するべきか、そのデータを分析する統計手法にはどんな種類
があるのか、以上の2点に関して意見が欲しいんだ。ヒントやキ
ーワードだけでも構わないんで。

>>562
何処も変わらないみたいだ。
会議室で実態を伴ってない数字が踊っているのを目の当たりにす
ると、正直腹が立つぞ。

>>563
ソフトウェアメトリクス

>>563
CMM/CMMI

もうすこし何とかならない？

>>566大先生に期待age

>>563

開発者？で品質管理に興味もつ奴はめずらしいな。
プログラマの俺としては、勝手に応援する。

有名な本
- ソフトウェア品質のガイドライン
　なんか、バグ数/ファンクションポイントをやたら推薦している。
- ソフトウェア・テストの技法 第2版
　テスト自体に知識が無ければ、これでも読んどけ。ついでに、"ソフトウェアテスト293の鉄則"も日本の現状を良く書いている。

バグ曲線・信頼度曲線なんかは、正しく使われたらそれなりに信頼の置けるもの。
個人的には、"デグレ数/1つの修正"の値・偏移も役立つと感じている。

あと、バグ原因のテンプレは非難されやすいが、俺は悪くない思う。
まとめた結果、「設計が原因」のバグが多かったら、設計工程を反省するだろ？
問題は使われ方だ。

反省は品質管理とどのような関係が

フィードバック

反省だけなら（ry

バグを全部出した後で日付調節してバグ数が日々減っているかのようにみせるツールが必要になるな
安心しろ俺はＶＢＡも使える

>>568
> 問題は使われ方だ。

たぶん、これに帰着するとオモ

ならばどの様に使うべきなのか

>>568
プロセス品質について聞いてるのに
ソフトウェア品質について答えてる姿にﾜﾛﾀ

>>568
>"ソフトウェアテスト293の鉄則"も日本の現状を良く書いている。

「ソフトウェアテスト293の鉄則」は外国書籍の訳のはずだが、
日本のことも書いているの？

>>574
使えると思ったら使う。そうでないなら使わない。
全部のプロジェクトを画一的にテンプレにはめようとするのが間違いの元。

とにかく設計も品証も、双方とも相手の事をもう少し意識しようぜ。
設計は約束守れ。今日中って言ったら定時基準。それ過ぎるなら時間を指定しる。
品証は設計段階から参画して、設計不良を摘出しる。誤字脱字指摘して喜んでんじゃねーぞ。

動かないのに品証をパスするから困る。

データの捏造が横行してザルザルです。

PDCAの中のPDCA

バグの目標数とか決められたら捏造するにきまってるのにな。

対ステップ数バグ検出件数とか、無意味の極みだと思うわ。マジで。

>>569
> 反省は品質管理とどのような関係が
>>570の通り。
品質管理の目的とは、現状の品質・障害となる問題点を認識し、それをフィードバックして今後の品質を向上させることでは？

>>571
> 反省だけなら（ry
間違いを認めることは、サルには出来るかもしれないが、人間には中々難しい。

>>575
> プロセス品質について聞いてるのに
> ソフトウェア品質について答えてる姿にﾜﾛﾀ
CMMの話（ソフトウェア開発プロセスのレベルの話）だったのか？
ソフトウェア品質向上のプロセスで使われている値に関して、客観的な根拠がほしいという話だったので、ソフトウェア品質・テストの基礎の話をしたんだが。

>>574
> 「ソフトウェアテスト293の鉄則」は外国書籍の訳のはずだが、
> 日本のことも書いているの？
今、本見たら、嘘だった。
日本の現状に関しては、訳注に書いてあるだけだな。
日本の現状を知るには、TEF(日本のテストエンジニアの大きな団体)のML見るのがよさそうだな。

>>574
同感だぜ。

>>581
> バグの目標数とか決められたら捏造するにきまってるのにな。
周りのエンジニアの意見を聞いて評価がされる職場ならば、問題ない。
修正したバグ数の捏造なんて、BTSでばれるし、
わざとバグの多いコードを作成したら、コーディングのレベルが低いと同僚に認識されて、
周りのエンジニアからの評価が下がる。

>>583
暇なので絡んでみる。

568→575の流れ。
>>563>申し訳ないけど、プロセス品質を評価する為にはどんなデータに(ry
>>568>ソフトウェア品質向上のプロセスで使われている値に関して、客観的な根拠がほしいという話(ry
プロセス品質をググって見ていただきたい。

あと
>>568>開発者？で品質管理に興味もつ奴はめずらしいな。
開発者が品質に興味持つのは、アタリマエの流れだと思うがどうか。

オープンソースで日本語化されたテスト管理ツールが出たらしいね

PDCAの中のPDCA

SRATS
http://www.rel.hiroshima-u.ac.jp/~okamu/SRATS/
Excel 上でフォールトデータからソフトウェア信頼度を測るツール．

日ごとのバグ発生数を入力すると各種予測法に基づいて信頼度や残バグ数を予想するソフトだ

広島大学の大学院のシステム信頼性工学研究室が公開している。

結局、無駄骨に終わった。
一応報告。

ごくろうさまでした。

当然の結果

age

今度入ったプロジェクト。
本番環境でバグが発生してもバグ票発行せずに
その場でソース修正して即リリース。
正直面食らっています。
バグ票は不具合情報を収集するというQCの基本なのに(と思っていた)
こんなプロジェクトにいる人他にいますか？

>>592
運用・保守フェーズか・・・
おまえがTrac立てて運用フロー作ってやれｗ

>運用・保守フェーズか・・・
新規開発案件もあるのですが、バグ報告はおざなりになっています。
(バグ報告がないと後からちゃんと試験やったのか疑われるので
何か書いておくという感じ。当然PDCAを成していません)
>おまえがTrac立てて運用フロー作ってやれｗ
バグ追跡管理システムですか。
職場では私にはマシン・ネットワークの管理権限がないので
勝手にサービスを立てられないのですが調べてみます。

(開発環境はVB.NET)今NUnitを導入しようと企み中
PLがマイクロソフト信者な上、OSSの成果物の導入にも消極的な方なので
こっそり使い始めて既成事実化しようと思ってまつ

>>594
BTSは開発サーバや自分のPC使っても可能だが、マシン一台すら要求通せない奴には厳しいと思うぞ
あとxunitは設計絡むから設計者が適応考えないと無駄になる可能性が高い

経験から言わせて貰えば、会社の技術がVB6→VB.NETならxunit使用自体諦めた方がいい

>>595
レスありがとうございます
>BTSは開発サーバや自分のPC使っても可能だが、マシン一台すら要求通せない奴には厳しいと思うぞ
職場にバグ追跡管理システムを導入するのは現在の所あきらめてます。
バグ発生・改修情報を共有するという意識が希薄な雰囲気なので
うまく機能するとも思えませんし。

>あとxunitは設計絡むから設計者が適応考えないと無駄になる可能性が高い
PL、サブリーダは顧客から要件を取りまとめるのが主で(御用聞きSE?)、
設計、実装にはほとんど関与せずメンバーに任せきりなっているので
xunitの採用の余地があると思ったのですが。
私自身、自動化されたテスト資産を蓄積した
プロジェクトに以前居たことがあり、そのご利益はよく理解している
つもりなのですが...

>経験から言わせて貰えば、会社の技術がVB6→VB.NETならxunit使用自体諦めた方がいい
おっしゃる通りVB6→VB.NETです。
そうですか。諦めた方がいいですかorz
言われてみれば既存のVB.NETのソースコードは
クラスを使わず、VB6からコピペしてきたような力ずくなコードばかり...

http://www.kyoto-customized.com/
ハッキングできますか？

>>596
開発時も運用時も障害に対して対処が在る訳だ、特に運用時は改修入れない限り、障害が再現し同一対応が必要。
それがチケットとして管理（障害内容〜対処まで）されてたら調査・対処考慮工数が削減できる。
個人的にTracレベルのBTSは開発時より運用時に力を発揮すると考えてる。
自社BtoCとかだとほんとに実感できるよ、開発側まで来るケースが激減する。
その分運用からの改修要求が的確になって逃げ道が減るつー話も出てくるけどねｗ

>私自身、自動化されたテスト資産を蓄積した
>プロジェクトに以前居たことがあり、そのご利益はよく理解しているつもりなのですが...
使った事があるのは重要だけど構築・普及させるとなると別もんだよ。
設計がテスト駆動意識して無いのに適用したら逆に単体カバレッジ下がるし

>おっしゃる通りVB6→VB.NETです。
>クラスを使わず、VB6からコピペしてきたような力ずくなコードばかり...
OOPへの移行すらできてないのに、いきなりテスト駆動ってのはハードル高すぎじゃね？
よほどのリーダーシップと信頼を持ってないと、ハードルの高さはそのまま拒否反応になる。

>開発側まで来るケースが激減する。
(まだ短期間ながら)今のプロジェクトの周りを観察すると開発チームの中核が
運用障害の対処にかなり多くの時間が割かれているように見受けられます。
しかもどんな障害が起きているか周囲に居る人(私も含む)に伝わってこない
ので、後日別の問題が発生した時点で(個人的に)知らされるという状態です。
PLはVisual Studio Team System のバグ管理機能を使うつもりでいたよう
ですが、おそらくそれでは運用チームとの情報共有はできないでしょうし。
(しかも開発メンバー分のライセンス数も用意できてないｗ)

>使った事があるのは重要だけど構築・普及させるとなると別もんだよ。
>設計がテスト駆動意識して無いのに適用したら逆に単体カバレッジ下がるし
>OOPへの移行すらできてないのに、いきなりテスト駆動ってのはハードル高すぎじゃね？
>よほどのリーダーシップと信頼を持ってないと、ハードルの高さはそのまま拒否反応になる。
確かにおっしゃる通りです。
以前いたプロジェクトでは
開発物本体の設計側にもテスト資産の構築側にも居ましたが。
確かにテスト資産構築を念頭に置いた設計は必要でした。
ただ、それが今居るプロジェクトで受け入れられるかどうかは
わからないですね。拒否反応される可能性は大きいと思います。

さて、私のすべきことは何でしょう...?
今更ながら(今だからこそ？)OOPの利点を地道に周りに説くことからでしょうか

なんだか愚痴になってしまいｽｲﾏｾﾝ

>>599
どの位置にいるのか見えんけど、とりあえず運用フロー定義して、設定楽な影舞辺り使って運用側にBTSに慣れさせるかな。
少なくとも今のProjectで開発側に適用すべき物は無いと思うよ、障害が多すぎる。
次を見据えて現行運用に引っ張られる工数少しでも減らさないと改善・色々普及まで手が出せない。

>さて、私のすべきことは何でしょう...?
自社の話なら転職？ｗ

次に向けてOOP理解してるコアなメンバーを集めてチーム作る。
言ってる通りのスキルなら同レベルもう一人、OOP理解しサポートしてくれるPG1、BTS使用に賛同してくれるQA1くらいでいいんじゃない？
規模、モチベーションにもよるけどね
あとは理解あるPM（もしくは実績上げたいPM）探して、このメンバーでやれば品質向上・実質工数削減できると大まかでいいから数値で見せる。

>今更ながら(今だからこそ？)OOPの利点を地道に周りに説くことからでしょうか
VB6→OOP言語移行者は何人も知ってるけど、慣れた今でもあの時は・・・って話する位だしなぁ。
OOP布教は個人のセンス依存だから難しいと思う、その会社で半分付いてきたら布教者はとんでもない才能だと思うよ。

>>600
>どの位置にいるのか見えんけど
サブリーダ候補ってところです。

>運用側にBTSに慣れさせるかな。
働きかけてみます。

>自社の話なら転職？ｗ
Σ(ﾟДﾟ；)ｷﾞｸｯ

参考にさせていただきます。
相手してくれてありがとう！

役なし歩兵社員だけど
基本は仕様どおりに動作するか
仕様外のことを行ったらどうなるか
問題発生時は問題の切り分け
こういうのじゃないの？

時々、問題回避の方法を調べろとか言われるけどさ

>>602
>問題発生時は問題の切り分け
これは運用フローじゃない？
それ以外は合ってると思うよ。他にも環境依存、負荷とかあるけど。

ちょっと上辺りのは
如何にテストを楽にしようか
xunit使うなら設計に依存するよね
とかって話。

>>603
運用時ももちろん、開発時にも切り分ける必要に迫られる事はあるよ。
例えばC/Sシステムや、複数システムが連動して動作している場合のI/Fとか。
大規模な開発だとしばしばクライアントとサーバ（もちろん各システム）で
別々の会社が開発してたりするし、切り分けは結構重要。っつうか死活問題。

>>604
スマソ
スレの進行ちゃんと読んでなかったわ。筋違いな発言してるかも。
逝ってくる。

あれ？俺ガイル？
>604
その通りですな、嫌な事を思い出したよ・・・

さて今年も就職活動で品質管理希望者がきますよ

age

ウォーターフォール型の開発手法って多く使われているのかねぇ
融通が利かないのでイヤだぁ

障害対応でその場で直す、なんていうのはQC云々という以前に
「理詰めで考えるべき人たちが(何にも考えずに）出たとこ勝負してる」
みたいなものすごい格好悪さがあるなぁｗ

これからテスト仕様書を作るんだけど、経験が乏しくって、どんな風に作ればいいのかよく分からん。

これだけは押さえとけって点や、参考になる書籍やサイトがあったら教えて欲しいです。

>>611
とりあえず、次の、サイトを読んで概要を抑える。
http://gihyo.jp/dev/serial/01/test_newface

続いて『体系的ソフトウェアテスト入門』でしっかり学ぶ。
http://www.amazon.co.jp/dp/4822282074

>>612
ありがとうございます!!
熟読して来ます

開発したソフトウェアやドライバを、様々な種類のPC(Windows)を使って、自分自身（第三者ではない）で検証できる施設およびサービスってご存知の方いますでしょうか？

ググったのですが、なかなか良いサービスってないんですよね。「SONYがVAIOを無料で動作検証用に貸してくれる。」などでもよいですが、そんなのありますかね？

様々な種類のPCを買えば良いんでね？

あるとすれば国の検証研究機関だな
民間だと自分自身で検証とはいかんだろ

ソフトウェアやドライバの検証なら
OSとハードの規格検証だろ？

やっぱ買えば良いんでね？

「Designed For Windows - Windows Logo Program」
http://www.microsoft.com/japan/winlogo/default.mspx

ロゴ取得しておけば、もし相性の悪いデバイスやソフトに遭遇しても
“ウチは検証にパスしてますから、あちらが原因でしょ”で逃げられるかと。

BluetoothとかWi-Fiみたいに異機種間の相互接続が重要な分野なら
各社が機材持ち寄って検証するラボとかあるけど、>>614に沿えるラボは
知らんなー。ロゴでいいんじゃね？

>>614
ベリサーブでレンタルラボやってるはず。
その代わり高いぞ。

>>617
これがいいな

>>615
本当はそれで解決するのですが、そのような施設／環境を構築するのは大変でして、、、

>>616
やっぱ買うしかないですかね。

>>617
なるほど。そういう逃げ道もありますね（笑）

>>618
ベリサーブですね。調べてみます。

有名コンピュータ会社に問い合わせて無料で一週間貸して貰えるとかあればよいのですが。

ベリサーブ
http://www.veriserve.co.jp/solution/embedded/test/price.html

こんなところがあるんですね。知りませんでした。

こんなところもありました。既に終わってそうですが、、、。
http://www.csk.com/press/his/2001/1176648_1584.html

東証１部ぐらいおさえておけ

いつ全部上場するんですか？

デバッグめんどくせ
何かすっげー技術生まれないかな

>デバッグめんどくせ
>何かすっげー技術生まれないかな

「プログラムめんどくせ
何かすっげー技術生まれないかな」

とすれば、何故生まれないかが判るかな？ｗ

コードを書かないことくらいかな

1bsfbsdggdgweg





tettjrtrjtjr





ututtut5eue




twetwttewtwewe




dsggdsgdsgdss




eyyerreerer

プギャハハハハーーーー、形骸化、有名無実化、負担増大で
品質管理が簡略化、効果覿面だってよ。
品質保証専任部隊解散されて開発に回されてやんの。
品質保証が金になるって言ってた奴出てこいよ！！
バグはすぐに修正できるようになったし、つまらねー報告書もいらなくなって
大助かりだわ。

QAかぁ。
俺の作った機能を俺が作ったテスト仕様書でやってバグ出るわけないじゃん。
時間の無駄だからもうちょい頭使って仕事しなよ

緊縮体制だから生産性を上げる。これは良いよ。
で、必要工数を計算すると今使える人員の２倍を越えました。

その対策が「ベースがある場合は規模に0.25を乗ずる」ってなんだよ。
しかもそれでスケジュール組んじまってるし。品質どころか
破綻する可能性１００％だろこれ。お前らはここには突っ込まないのか？

いきなり「お前らはここには突っ込まないのか？」言われても、うち困るわぁ・・・ポンデライオンやし

やっぱり直交表とか使うの？

fusianasan

ポリテク京都の

工場管理技術課の高橋でーーーすｗｗｗ　うぜぇｗｗｗｗｗｗｗｗｗｗｗｗ

ウンコ高橋悟 は授業中隣の席の眉毛が異常安藤と話するな　授業の邪魔ですよｗｗｗｗｗｗ
安藤は３７年製造経験あるらしいけど
眉毛がアレじゃね〜〜〜ｗｗｗｗｗｗｗ　面接落ちますよｗｗｗｗｗｗｗｗｗｗ
豊島は眉毛安藤がお気に入りみたいだけど安藤は言語障害があるためいっている意味わかりましぇーーーんｗｗｗｗｗ

ウンコ高橋悟は　今日の昼休憩に香月とオタクの津崎の誹謗中傷言っていたｗｗｗｗｗ
「津崎はダメ幹事！あいつはダメや！！」とか大声で盛り上がっていたけど
お前が幹事やったら全員不参加だっただろうねｗｗｗｗｗｗｗｗｗ　気がつかないけどお前の声は、うざいよｗｗｗｗｗｗ　マネーゲームでクラス全員に嫌われてるよｗｗｗｗｗｗｗｗ
オタクデブ津崎と仲良く話しているけど裏では誹謗中傷しているｗｗｗｗｗｗｗｗ　津崎は馬鹿だからきがつかねーんだろうなｗｗｗｗｗｗ
オタクデブ津崎さ〜〜ん　鈍感だけどそろそろ気づきましょうね〜〜　高橋悟の悪意をねｗｗｗｗｗｗ　m9｡ﾟ(ﾟ^Д^ﾟ)ﾟ｡ﾌﾟｷﾞｬｰﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ / ＼/ ＼

高橋悟軍団

ノーパンの白石
ホモの川合
キモヲタデブ津崎
ガイコツ清水
ニヤニヤキモ橋富
早く離婚してください香月

ポリテク京都の

工場管理技術課の高橋でーーーすｗｗｗ　うぜぇｗｗｗｗｗｗｗｗｗｗｗｗ

ウンコ高橋悟 は授業中隣の席の眉毛が異常安藤と話するな　授業の邪魔ですよｗｗｗｗｗｗ
安藤は３７年製造経験あるらしいけど
眉毛がアレじゃね〜〜〜ｗｗｗｗｗｗｗ　面接落ちますよｗｗｗｗｗｗｗｗｗｗ
豊島は眉毛安藤がお気に入りみたいだけど安藤は言語障害があるためいっている意味わかりましぇーーーんｗｗｗｗｗ

ウンコ高橋悟は　今日の昼休憩に香月とオタクの津崎の誹謗中傷言っていたｗｗｗｗｗ
「津崎はダメ幹事！あいつはダメや！！」とか大声で盛り上がっていたけど
お前が幹事やったら全員不参加だっただろうねｗｗｗｗｗｗｗｗｗ　気がつかないけどお前の声は、うざいよｗｗｗｗｗｗ　マネーゲームでクラス全員に嫌われてるよｗｗｗｗｗｗｗｗ
オタクデブ津崎と仲良く話しているけど裏では誹謗中傷しているｗｗｗｗｗｗｗｗ　津崎は馬鹿だからきがつかねーんだろうなｗｗｗｗｗｗ
オタクデブ津崎さ〜〜ん　鈍感だけどそろそろ気づきましょうね〜〜　高橋悟の悪意をねｗｗｗｗｗｗ　m9｡ﾟ(ﾟ^Д^ﾟ)ﾟ｡ﾌﾟｷﾞｬｰﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ / ＼/ ＼

高橋悟軍団

ノーパンの白石
ホモの川合
キモヲタデブ津崎
ガイコツ清水
ニヤニヤキモ橋富
早く離婚してください香月

ポリテク京都の

工場管理技術課の高橋でーーーすｗｗｗ　うぜぇｗｗｗｗｗｗｗｗｗｗｗｗ

ウンコ高橋悟 は授業中隣の席の眉毛が異常安藤と話するな　授業の邪魔ですよｗｗｗｗｗｗ
安藤は３７年製造経験あるらしいけど
眉毛がアレじゃね〜〜〜ｗｗｗｗｗｗｗ　面接落ちますよｗｗｗｗｗｗｗｗｗｗ
豊島は眉毛安藤がお気に入りみたいだけど安藤は言語障害があるためいっている意味わかりましぇーーーんｗｗｗｗｗ

ウンコ高橋悟は　今日の昼休憩に香月とオタクの津崎の誹謗中傷言っていたｗｗｗｗｗ
「津崎はダメ幹事！あいつはダメや！！」とか大声で盛り上がっていたけど
お前が幹事やったら全員不参加だっただろうねｗｗｗｗｗｗｗｗｗ　気がつかないけどお前の声は、うざいよｗｗｗｗｗｗ　マネーゲームでクラス全員に嫌われてるよｗｗｗｗｗｗｗｗ
オタクデブ津崎と仲良く話しているけど裏では誹謗中傷しているｗｗｗｗｗｗｗｗ　津崎は馬鹿だからきがつかねーんだろうなｗｗｗｗｗｗ
オタクデブ津崎さ〜〜ん　鈍感だけどそろそろ気づきましょうね〜〜　高橋悟の悪意をねｗｗｗｗｗｗ　m9｡ﾟ(ﾟ^Д^ﾟ)ﾟ｡ﾌﾟｷﾞｬｰﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ / ＼/ ＼

高橋悟軍団

ノーパンの白石
ホモの川合
キモヲタデブ津崎
ガイコツ清水
ニヤニヤキモ橋富
早く離婚してください香月

>>634-636 法人としての削除依頼でしたら対象区分を法人・団体にした方が良いと思います。
http://qb5.2ch.net/test/read.cgi/saku2ch/1032017835/115
> 115 名前：杉原**/訓練第一課長[*********@ehdo.go.jp] 投稿日：10/02/26 18:52 HOST:61.205.122.129
> 対象区分：［個人・三種］優先削除あり
> 削除対象アドレス：
> http://pc11.2ch.net/test/read.cgi/prog/1088135300/+634-636
> 削除理由・詳細・その他：
> 本削除要請中の
> >>113
> を記述させていただきました杉原です。
>
> >>114
> に対して削除の再依頼となりますが、よろしかったでしょうか。
>
> 本日、被害者のかたより削除の再依頼を受けました。
>
> 冒頭に記載されている用語から場所が限定されること。その中のどこに所属しているかも限定されているため個人特定が容易であり、個人の誹謗中傷に該当することからぜひ削除いただくようお願いいたします。
>
> 先日2/1810:30〜向日町警察署のスミタニ相談員に相談させていだきました。
> その中では、この記述は、名誉毀損等にあたり、被害者よりの訴えいかんでは、個人特定の捜査に入ることが可能である旨の回答を得ております。
>
> 当施設は、被害者の方より、警察への訴えはさけたいとの要望を受けておりますが、被害者から削除依頼を受けていることから、再度削除依頼させていただきました。
>
> 当施設を利用いただいている方が被害者となっており施設としても、説明責任があることから「様子見」となるのであれば、明確な理由を示していただきたいと思っております。
>
> 個人の誹謗中傷にあたると思うのですが…
>
> 何卒、善処いただきますようお願いいたします。

設計書の品質管理ってどうやればいいんだろ

>>638
うーん。
こんな発言が出ること自体が・・・・

つJIS Q 90001

>639
間違えた。

誤：JIS Q 90001
正：JIS Q 9001

テストって、底辺がやる仕事やろ。

物作りを楽しめない、なんちゃってIT屋さんなんだね。

ろくにテストもしないで得体の知れないオプソ組み込んで
ゴソゴソ客だますのもなんちゃってではないかと・・・・

>>641
何か劣等感でもあるのですか？（藁）

>>643
いや、テストしか出来ない君らの人生がかわいそうで。

物作りの技術は掛け算で日々進化してるのに、君らは足し算で横に膨らむだけだろ。

掛け算で進化？
局所的には引き算で前の枠に押さえ込んでるけど？
んで。
５０代のドカタはろくすっぽ設計しない、テストもさせない。
新でほしいマジで

アイデア出せない、要件定義できない、詳細設計できない、インフラ&DB構築できない、開発できない、サーバー保守運用トラブル対応できない、
できるのはテストだけだから相手からのレスポンス待ちで、自分から動けない。

いやぁ、『これしかできない』という君らが本当にかわいそうだ。
不満をあれこれ言う前に、相手を納得させられる仕事のProcessの意味を言えるようになりたまえ。

いいじゃん、嫁いるし、給料安定してるし、趣味充実してるし、
少なくとも>>646より幸せだしw

>>647
今が幸せなら君はそれでいいんじゃない^^
君はそれまでの人間ってことで^^

>>646=648は孤独死直行コースだね^^
それまでの人間みたいだし^^

>>646は今の自分に満足できてないんだろう。
だから周りにとやかく言うんだろう。
精神的なゆとりが感じられない。
多分派遣とかじゃないのか？

ちょうど今、WEBアプリ改修のヘルプに入って
試験項目作ってるけど、つまらなすぎて死にそう。

基本設計とか詳細設計の内容を、試験項目に
落としていくんだけど、繰り返す内容が大杉・・

マトリクスで書きたいけど、読むときに一本筋で
読めないと困るし、お客のレビューもそれじゃ
通らないと。

中身詳しくないアプリで興味も持てないし、
ひたすら文言おっかける作業で脳が焼けそうです。
Excelの印刷でまた死に掛けた。

テストはたしかに底辺の仕事だと思う。
テストチームとか作ったら鬱病患者が出るんじゃなかろうか。

>>650
水掛け論になると思うからハッキリ言うけど、俺は派遣じゃなくGoogleの役員でモバイルアーキテクト。
別に知られてもいい範囲なら証明も可能(名刺うpとか)。

なんで今の自分に満足しないかは、満足したらそこで成長が止まると思ってるから。数年後に眼を出すために好奇心を持ってアイデアを紡ぎあげて新規開発を続けている。
メインの仕事以外に研究開発もやれる環境が整っているから、仕事が楽しくてしかたがない。

>>650はまるで自分のことを言っているみたいだ。

>>652
>別に知られてもいい範囲なら証明も可能(名刺うpとか)。
でも、こういうところに関しては
「自分から動かず、他人からの指示待ち」
になってしまう訳なのね。

>>652
仕事が充実してるならこんなところで愚痴ってないだろ
四の五の御託を並べてないで証拠をはやくうｐしろよクズ

おたくのモバイルアーキテクト役員が、2chのスレでテスターを叩いてるぞ
とGoogleに通報してくるわw

スルーされて役員さんの人気に嫉妬 orz

>>652
いくらなんでもその見栄の張り方はマズイだろう？
冗談じゃなくマズイだろう？
Google黙ってないと思うぜ。

これ、抗議とかされるかな？

>>652はなんで名刺うpしないの？
それとも訴えられることを恐れて部屋の隅で震えているの？

>>659
出す・・・・・・！
出すが・・・
今回　まだ　その時と場所の
指定まではしていない

そのことを
どうか諸君らも
思い出していただきたい

つまり・・・・
我々がその気になれば
名刺うpは
10年後　20年後ということも
可能だろう・・・・・・・・・・ということ・・・・！

携帯用ゲームでさ
社内で絵描きに2,3回プレイさせて（端末変えたりもしない）
動いたと言われる→デバッグ終わり、完成です
というのは普通じゃないよな？

大丈夫かこの会社・・・

試験計画を提出してください。

>>662
あんたの上司に提出して検収印もとっくにもらってるよ。
あんたは使い物にならないから無視していいって言われてるからw

目上の人が開発者で、上がってきた試験報告書の誤字脱字がひどい場合って、
どうやったら角をたたせずに修正させる事ができるのかな。
以前も実際の動作とシナリオの内容が異なってて、
それを指摘した時に舌打ちされて怖かった。
ちなみに、上司はその開発者に全幅の信頼を寄せてるから、
俺が何か言っても多分聞く耳を持つどころか、俺の態度が悪いって説教される。

このままでは俺の寿命がストレスでマッハなんだが・・・

ソフトウェアの試験のことを今まで「ソフト検証」と言っていたが、
最近「検査」という用語を使う人が入ってきた。
なんか違和感あって気持ち悪いんだが、
これって単なる言葉の違いだけなんだろうか。
社風によって変わったりするのかな。

おそらく、
検証：技術者用語
検査：購買の事務用語
じゃないかな？

メーカーに納品にいったら購買部が「検査」
するということを知った。
最初違和感があったけど、もう慣れたよ！

>>666
そうなんだよ、「検査」って設計行為じゃない感じがするんだ。

検査せずにリリース

>>664
そのまま提出しろ。