テストってどれだけやってますか？ 301
ストーリー by wakatono
かかるものはかかる 部門より
かかるものはかかる 部門より
kom曰く、"@ITの特集で、ソフトウェアテストがいかに大切かということを説かれています。スラッシュドットの皆さんはソフトウェアのテストの重要性は
ひしひし感じていらっしゃると思いますが,
やはり軽視している上司やお客様が多いのも事実.
記事中,テストの工数は全体の工数の少なくとも3割,
多いと9割占めると書かれていました.
皆さんのプロジェクトではどの程度占めるのでしょうか.
また,ソフトウェアのテスト専任の技術者が会社にいるという方は
どの程度いらっしゃるのでしょうか.
アメリカの場合,テスト技術者はひとつの職種のようになっていますが,
日本では開発者がそのままテストを行うことも多いと聞きます.
それってほんとに正しくテストができるのでしょうか.
この春からソフト開発職に就くので,どんなものか気になるのです.
ちなみに私はできればテスト専任技術者になりたいなと思います."
テストは重要ではあるが、日本ではテスト専任のエンジニアという職種はまだまだ少ない。しかも開発における重要性はわかっているものの、いざというときには期間が短縮されたりということも多い。実際テストに関して思うところが多い人も多いはずだ。参加者の身の回りでの実態はこのあたりどうなのだろうか？
私が頭を勤める場合、 (スコア:4, 参考になる)
A) 事前に試験計画を作成し、査読を受けている事
B) 設計/開発を行った者と別の人間がテストをしている事
複数人で開発してお互い他人の受け持ち分をテストするのでも可
C) テストと開発の期間比率は1:2以上
D) 試験実施中のプログラム修正は行わず、全項目検査した後に
修正->再試験を行う事
F) 試験を可能な限り自動化して、顧客サイドでいつでも再実施可能
にすると。(捏造防止)
これらを満たしていないと、出荷（納品）不適格にしていますが、
顧客要望により常に不良品を納めております。
# バグが無ければ試験はいらないはずだから、必要な工数とは
# 認められないだってさ～。某総研の自称アナリストの人はまったく。。。
Re:私が頭を勤める場合、 (スコア:4, 興味深い)
「色々な評価試験をやって結果的に合格なんだったらその試験は無駄だったってことだよね。」
頭痛い。。。
Re:私が頭を勤める場合、 (スコア:1)
テストは結果として品質を高めるものだけど、その本質はテストをした範囲内においての動作保証をするものだと思うんだけどな。
だから、バグがないからテストをしないのではなく、テストをすることによりバグが無いことを客観的に示し、延いてはその品質を示す、なんだけど…。
あと、テストと製品品質の後日検証のためにはやはり自動化されたテストが必要なんだと思います。自動化されていない手動のテストでは、テストの再現ができないですから。元コメントで出ていますが、手動テストの結果なんていくらでも偽造できてしまいますし。
なんか昔のfj.comp.lang.cにおける「バグのないソフトウェア」についての議論を思い出してしまいました。
検証可能性とその重要性についてのいい議論の題材だと思います。
Re:私が頭を勤める場合、 (スコア:2, 興味深い)
> 偽造できないってもの重要だけど、試験手順の作業ミスが無い
> 事を証明できるメリットもありますしね。
そのことは、
という文で表現したつもりだったのですが、うまく伝わらなかったようですね。すいません。
個人的には偽造云々よりも、手順が明示されていていつでも再現可能であり検証可能であることの方が重要だと思っています。
# 意図的なミス(偽造)だろうが意図しないミスだろうが、
# そんなものは品質の前には同等だから。
> エンジニアの質が下がり続ける昨今、人間の手を信用しないって
> のが品質向上の近道だと真に痛感します。
人間の手、というか手作業ですよね。
それこそ、本当に優秀な人は極力手動はさけてスクリプトなどで対応するでしょうし。
作業の自動化は、単純に楽をするためだけではなく、一度行ったことを誤り無く繰り返すことができるのと、作業手順が確実に残るため誤った際問題個所の追跡が可能(もしくは容易)なこと、そして似た作業を行う場合の労力を減少させミスもすくなくすることにあると思います。
力技で行った作業でミスが出た場合悲惨ですよね。自動化しておけば、問題の個所を修正して実行するだけですむわけですし。件数が多ければそれだけ人力で行う場合にミスが発生しやすいわけで、その上問題発生個所の追跡も困難になります。
えーと、ACさんの最後の文に戻りますが、重要なのは自動化により良い意味で楽をすること( = 人間の手を信じない)だと思います。
# 自戒を込めて。
Re:ブレーキ不要? (スコア:2, おもしろおかしい)
ちょうどだと思っていたら、大幅に足りなくて、途中で力尽きたり
燃料が多すぎて、漏れ出して火がついたり…
そうか、「あのプロジェクトには火がついている」というのは
そういうことだったのか…
----------------------------------------
You can't always get what you want...
Re:私が頭を勤める場合、 (スコア:2, すばらしい洞察)
293の鉄則 (スコア:3, 参考になる)
テスト関係の書籍はあまり無いのですが、これは一読の価値があります。
日本ではまだテストの重要性やテスターの地位など、文化の違いで
片付けられない問題があると思う。
Re:293の鉄則 (スコア:2, おもしろおかしい)
条件はたった一つでも、それが「ネコミミ」だったり、法的に不可能な年齢だったりしませんかね?
タブレット中毒者。
品質保証部 (スコア:3, 興味深い)
品質保証部の合格が出ないと出荷できないので、
設計部と品質保証部の仲が悪くなると最悪です。
プロジェクトの最後は、修羅場になります。
品質保証部は出荷する製品に対する最終責任を持つ。
合格を出したからには、客先でバグが出たら、品質保証部に責任がある。
ということになっています。
現実には、結局設計が怒られます。
品質保証部からも、めためたに言われます。
世の中そんなもんです。
Re:品質保証部 (スコア:2)
オープンソースなプログラム・ライブラリが部品として認定されているのですが、バージョンアップなし、バグやセキュリティホールもそのままで使われています。パッチ当てるとまた認定試験を一から受け直さなきゃならないからという理由で、開発の方々が嫌がってパッチ当てさせてくれないのです。
もうちょっと融通を利かせてくれないと、逆に品質低下に繋がるのですけどねぇ。
組み込みネットでも (スコア:2, 参考になる)
技術解説：「品質」をつねに念頭に置きながらソフトウェアを開発する [kumikomi.net]
技術解説：テストの本質を探る―30年の歴史を持つ 「ソフトウェア工学」の知恵 [kumikomi.net]
色々言われていますが、結局の所、今までのソフトウェア開発モデルが破綻しつつあると言うことに尽きるのではないかと思います。
さらに、テストだけに限らず、三菱自動車のトラックのように、リスク管理というものができず、うまくいっても直接利益にならないリスクヘッジ的な分野に金を出したがらない風潮も原因でしょうね。
Re: ねこみみネットでも (スコア:1)
>ソフトウェア開発モデル >リスク管理
も。
まあ、けきょく、なんきょく、
どんなソフトウェア開発モデルメソッド方法論手法を使うとしても、
開発者が自ら行なう自己テストだけじゃ信頼性低！だし、
開発現場と全く分断された環境でテスト先任者だけで行なうテストも信頼性低！だし、
まああま、けきょくけきょく、なんきょくなんきょく、
「開発者」と「テスト先任者」がナイスなコンビとなって、
密に情報のやりとりをしながらテストすることのみが芯で軸。
今後、移り変わり続け、どんな開発メソッドがブーム（流行）となったとしても・・・。
人間は装置だし（だろうし）。（たぶん）なにもかも全て、装置間のミームデータ通信だし。
ナイスコンビだよ！トミーとマツだよ！噂の刑事だよ！
課長、ことアフォイフルオヤジもよろしく（清水省吾）。
ていうかサラ金は全業者、氏ねオアダイ。
借金をしてしまう前に読んでおきたい本。２冊。へのリンク
企業再生屋が書いた「借りたカネは返すな！」加治将一/八木宏之 著 [atc.ne.jp]
「住宅を手放さなくても借金は整理できるし、会社も守れます。生き抜くために必要な砦と武器を人手に渡してしまえば、再起が難しくなるだけなのです。」
「消費者金融 誰もが驚く裏オモテ」井上トシユキ 著 [archive.org]
70年代には「サラ金地獄（第一次サラ金パニック）」、90年代には「第二次サラ金パニック」「システム金融」、去年だと事件チャートをジャンプアップで賑わした「０９０金融」って。
_
# CheapGbE!GbE!!TheKLF!KLF!!TheRMS!RMS!! And a meme sparks...
お願いだからテストして・・・ (スコア:2, 参考になる)
テストしたことにはならないんです。お願いだから負荷テストをしてください。
実際にサービス開始して多数のユーザーが使い始めたら、すぐ止まったからといって、
ミドルウェアのせいにしてベンダーを呼びつけないでくだださい。
こんなにDBにロックかけまくるアプリケーション、止まって当然です。
＃ 徹夜で修正を手伝わされているのでAC
テスト専任 (スコア:2, 興味深い)
あと、設計がキッチリ決まってない場合は、開発者以外がテストコードを書くのは難しいんじゃないかな。コードに手を入れる権限がある程度必要になってくるから。ユニットテストの話をすると、全てのコードがテストできるってわけじゃないと思うんですよ。メソッドに何十行もずらーーっと書いてあるような酷いコードはテストのしようがない。ユニットテストを書くことで自然とリファクタリングが進むんだけど、ここで年上のオジサンプログラマが「俺のコードは動いてるんだから手入れるなよ」みたいな場合は困る。 しかも、ずらーーっと長い分、メソッドに期待されている振る舞いってのも理解しずらくて、テストを書くのにすごく時間がかかってしまう。
テスト書くよりも、コードの振る舞いを理解するのに時間がかかってしまうぐらいなら、開発者本人がテスト書いた方がよっぽど早いわけ。
あと、チーム全体がユニットテストの存在を認識して、更新していかないと、振る舞いの変更が行われて、テストが壊れまくってもそのままチェックインみたいな事が起こる。テストが壊れるってのは、再設計の必要がどこかであるわけで、場当たり的にクラスを拡張していくオジサンプログラマを説得して、新しいクラスを作ったり、継承を使ったりということが必要になる。OO のセンスのないオジサンプログラマが上司ってことは多いです。
ここで、腕が立つと認めてもらえれば、コードを書き換えたり再設計する権限が与えられるわけだけど、それは腕次第。
要するに、テスト以前に開発プロセスそのものが確立してない所が多いわけです。何をテストするかが明確じゃないとテストのしようがない。
適当にコード書いて、事後に UML を作って大量の Word を作るとか、そういう現場があるわけで。当然の事だけど、cvsなどのヴァージョン管理ソフト、バグ追跡ソフト、コード規定がまず必要だし。
最近、大学生のインターンを指導してるけど、ホワイトボードで UML 使って論議して、テストファーストって方法を導入してみた。 僕は、他人の書いたコードって信用できない性格なんだけど、テストがあることで少しは信用できるようになったと思う。
あと、ソフトの生涯ってのは大半を保守で過ごすわけで、ちゃんとした要件収集、設計、テストをやることで、長期的な生産性は上がります。バグだらけで、しかも誰も保守できないコードってゴミだから。 あと、データの状態によって出てくるバグってのも少なくなる。
Re:テスト専任 (スコア:2, 参考になる)
どこまで設計をするかってのも、規模によって変わってくるよね。
っていうか、困るのが、要件仕様がハッキリしない場合。How（どうやって実装するか）は事前に決まって無くても問題ないと思います。だけど、What（何を書くのか）を事前に決めないでプロジェクトが始まることが多い。あと、マネージャもリーダーも How と What を区別できてなかったり。
XP で言うところの、Planning Game とか User Story から生まれる Task Card が無いと、話にならない。XP やるとしても、コードだけで考えると煮詰まるのでスケッチモードの UML [amazon.co.jp] はお勧めです。
> 必ず合格する試験を記述するんでしょ？
これは、挙動がある程度複雑だと、いつでも合格というわけにはいかないと思います。凡ミスを拾うことも多い。
だけど、自動化されたテストの一番の強みは、将来コードに色々拡張が入ったり、ネットワークの設定を変えたりみたいな外部環境の変化があった時に実装したコードがちゃんと動いてるかを手軽にチェックできることにあると思います。極端な話、値をチェックしてなくても、ある部分を呼び出してるだけでも、テストとしての役割はあると思います。
>> データの状態によって出てくるバグってのも少なくなる。
って書いたのはその事で、例えば、名前が「j」で始まる記録をデータベースから削除した時のみに行われる一連の振る舞いがあったとして、運用中にそういう記録が稀にしかない場合とか。運用に入って、しばらくしてからキャスティングミスで突発バグ。
スタブとか (スコア:2, すばらしい洞察)
認証系とか基幹系とか金融系とか通信系とか。（全て通信系とも言えるけど
連係が肝のシステムなのに、システムに閉じた試験しかやってない、終いにいちかばちかで連係試験して大変なことになったり。人員や環境を再調整してリベンジなんてそう簡単に出来ない。
システムの規模に拠りけりでなんでもかんでもスタブってわけじゃないけど、I/F仕様を認識する意味でもスタブを作った方が精度が上がりそうですね。
その場の工数は大きくなっても精神的に利得があると思いますよ。
一番難しいのはスタブ込みでテスト工数を取れるかどうかでしょうが（汗
# 開発側はみんなスタブの有用性を分かってるとは思うが
---- 何ぃ！ザシャー
設計どれだけやってますか？ (スコア:2, 興味深い)
すでに期間と割り当てられる人員が決まってしまってます。
～月までで、使えるのは何人、と･･････
足りないから作りません、というわけにはいかないので、
（というか、言う権限が無いor言っても無駄）
結局、設計とテストしか切る部分がありません。
テストどれだけやってますか？という質問とともに、
おそらくテスト期間と同様に切られてしまっているであろう
設計期間についても「設計どれだけやってますか？」
と訊いてみたいところです。
--------------------
/* SHADOWFIRE */
TEF (スコア:2, 参考になる)
「テスト設計」なる言葉もここで初めて聞いたりして勉強になっております。
品質管理部門の人々がメインのような感じでしたが、昨今はプログラマの比率が増えてきたように思えます。開発プロセスからの改善はプログラマも巻き込まないと意味がないので、品質管理部門以外の人々の流入も望むところでしょう。
ちょっと注意事項：
「技術系メーリングリストで質問するときのパターン・ランゲージ」 [hyuki.com]で述べられてるようなネットリテラシーのない人が多かったり(全文引用や謎Subject)、入会の挨拶が推奨されてたりして、/.Jの皆さんが普段接するメーリングリストとちょっと雰囲気が違うと思います。層も企業に所属する人ばっかりです。が、特に資格に制限はないので誰でも入れると思います。
# 私は入会の挨拶してません(^_^;)
# JaSST'04行きたかったなぁ。
自分が書いたコードを信用しないという姿勢 (スコア:2, 興味深い)
書かれたコードをテストすると言うことは、書いた人を信用しないと思われがちでしょうが、要求仕様が曖昧で変更の可能性がいつもあり、納期も常に不確定な業界では、ある程度、コードを書き上げる速度を上げて、あとはテスターからのフィードバックを受けて作り込んでいく、という姿勢は必要なのかな、と思います。これは引用元の西氏の姿勢そのものですね。
そのときに、従来、物作り企業では品質保証部門を別に設立して、トップの意向を受けながら品質保証の啓蒙活動を仕切ったり、実際の工程に立ち入ったりしました。最終的には全社で品質を上げていく意思統一が必要で、そのための社内コンサルティングという立場に落ち着いているようです。ソフトウェア業界におけるテスト技術者も、啓蒙部門という立場になるか、あるいはその役割そのものがコードを書く現場に委ねられるか、していくのでしょうね。
いずれにせよ、まずは、自分が書いたコードを信用しない姿勢が大事なのでしょう。 製造工程よりももっとばらつきの多い人間の集団から生み出されるものですから。 素直にテスト技術の今後に期待します。
XP (スコア:1)
それと、ソフトウェアではありませんが、ネットワークの試験はよくやりますね。最近、ルータやL2SW、L3SWだけでなく、負荷分散装置、L4SW、ファイアウォールや、それらに伴う冗長化の仕組みなど、色々複雑になってますんで、可能な限り実環境に近い環境を組んで試験してますよ。金かけて冗長構成組んでるのに、サービス停止しちゃったらシャレになりませんから。
テストとコスト (スコア:1)
工数とは、そのまんま「人件費」です。
人件費は減らしたい、というのが客先の第一の要望です。
人件費は減らしたい、というのが開発会社の第一の要望です。
よって、テストは軽視、もしくは省かれる可能性が非常に高い工数の１つになります。
つまり、ご質問へのお答えは、ごく普通の会社であれば、
お金くれるならやってもいいよ
ということになります。
趣味ではなくて仕事である以上、お金とのかねあいを考えないシステム開発は不毛ですから、こういうことになるのが普通だと思います。
Re:テストとコスト (スコア:1, すばらしい洞察)
なんて考えを持っている発注側はもちろん、受注側にも大きな問題があるのでしょうねぇ。
本来外すことの出来ない工程を外すことを許容してるんだから。
なんなら、開発工程もさくっと削減してもらえませんか？
Re:テストとコスト (スコア:3, 興味深い)
「お金は払うから*ちゃんと*テストしてくれ」
ってのが偽らざる本音。 いや、正確に言うと
「何テストしたんだか教えれ」
って事でしょうか。
どぉぉぉぉ考えてもテストしてたら出ないだろそんなバグ、という「不具合」をポロポロと発見するにつけ、「やっぱ単体レベルのテスト仕様書も見せて欲しいなァ」と思う今日この頃。
あとサーバサイドのプログラムで（想像するに）if文1個の修正みたいな改修作業で「テスト1人日」とか見積もりに出てくると、頭を抱えざるを得ないです。テスト全項目通してもそんなに時間食わないだろうによ。
あー、みなさんのトコって客先に納品する時、テスト内容ってどの程度開示しているんでしょうか？ 激しく気になります……。
Re:テストとコスト (スコア:2, 参考になる)
>「お金は払うから*ちゃんと*テストしてくれ」
>ってのが偽らざる本音。 いや、正確に言うと
>「何テストしたんだか教えれ」
発注仕様書に納品資料として提出するよう記載すればいいだけでは？
#最近、仕様書にきっちり書くことを学んだので。
#しかし、打合せで仕様を決めようとすると後で打合せの内容を
#覚えていない業者の多いこと。おまえらメモとれー。
Re:テストとコスト (スコア:2, 興味深い)
＞いうことがさっぱりかかれていないんですよねぇ。
それははっきり言うとテスト項目が甘いだけ。
「誰がテストしても同じ結果が出る手順を並べたもの」が試験項目表だよ。
試験した人が後から理由を書かなきゃならない項目表は項目表としての品質が低い。
低い品質のものを使っても低い品質のものしか生まれないから。
試験項目表さえシッカリ作る事ができれば、
それこそ試験要員なんてパンチャーレベルでも問題ないんだけどね。
＃まあ、大体の人は「結果が1になること」が試験項目だと思ってるようだけど。
＃「○をして×をすると結果が１になること」としっかり提示できなきゃ、
＃「×を2回して○をやって結果が1になったからOK」と言われても文句が言えない。
Re:テストとコスト (スコア:2, おもしろおかしい)
>単体レベルのテスト仕様書も見せて欲しい
こういうお客さんに巡り会いたい(T_T)
＃会えてないのでG7
結局、「小難しい。なにいってんだか判らん。
そんなもんはいちいち見せるんじゃねえよ」なんていうお客は
自分の首を締めてるんだよね。
てか、確実に理解できる保証なんてものは無視して、
とりあえず「多め」に情報を納めさせるほうが、
絶対に有利であるはずだ。お客にとって。
だって理解できなくて「困ったら」、誰か理解できる人を掴まえて読ませりゃいいだけなんだもん。
でも情報そのものを納めさせていなけりゃ、永遠に読めない。
幸いにして現在は、多めの文書を仕舞っておく場所には(電子データなら)苦労しないんだしさ。
ただ、
>if文1個の修正みたいな改修作業で「テスト1人日」とか見積もりに出てくると
それは、アーキテクチャ(の不味さ)次第では、なんぼでもありえることです(T_T)
逆にいえば、作りかけの時点でも観察することは、
お客にとっても利益(つーか損害を無くす)のために重要だと思う。
「技術的負債」を抱えまくった開発を受注者がやってんじゃねーの？ってのを
建築^H^H開発途中にも頻繁に査察したほうが良い、と俺は思うっす。
＃無理の有る査察のしかただと困るけど、ね。
あ。そういう意味でも、XPは旨いよな。
Projectはお客に、常時査察されてるようなもんだもん。
>どの程度開示しているんでしょうか
ウチの社長が何考えてるかはともかく、開発者たる個人としての俺は(^^;、
相手が吐き気催すまで出すのもヤブサカじゃないですよ。
ほら。ここでのカキコみたいにさ(藁
＃最近、ソースごと納入な仕事ばっかりしてる気がするんだが、
＃お客がそのソースだのなんだのといった情報を有効活用してるのを、見た験しがないのでG7
Re:テストとコスト (スコア:1)
えーと…
>人件費は減らしたい、というのが開発会社の第一の要望です。
>よって、テストは軽視、もしくは省かれる可能性が非常に高い工数の１つになります。
貴方は「テストによって結果的に工数が削減できる可能性」の検討すらしてないということですか？
コスト云々を言うならリスクマネージメントの観点を抜かしていては、やらなくてもいい一か八かの勝負しか出来ない、
結果的に火だるまなプロジェクトを生み出す要因だと思いますが…
ジェネラリストばかりではよっぽどシェアを握るとか参入障壁があるとかいう業界で無い限り利益は薄くなるのではないでしょうか
（って自分も痛いな、これ。）
Re:テストとコスト (スコア:2, 興味深い)
回転ドアの件は設計ミスだろ。だって、センサに死角があることは事前に知っていたんだし。ついでに言えば、実運用に入った後も何件も事故が発生してたわけで。設計にミスがあることが判っていて、その上運用でも問題が出ているのに問題を放置したという、どうしようもない例。設計上、センサに死角があったことのだから、試験をやったとしても、今回のようなテストケースは出てこなかった可能性が高い。
Re:テストとコスト (スコア:2)
あの手の反射式のセンサーは、対象物の色で作動距離は変わる（産業機器で使っていて、誤動作防止のために透過式のセンサーに取り替えたことも何度かある）。
白と黒ではまったく作動距離は違う。これをカバーするために「地面から80cmも上で動作するように設定している」はず。
80cmも取っているのは、地面の反射率が変わると地面を対象物として拾ってしまうから。
白ならば地面から50cmでも拾うんじゃないの？
泥棒やスパイの映画やアニメで、赤外線スコープを使えば、線に見えるのが透過式で、シャワーの様に見えるのが反射式。
反射式は対象物の反射率や光の拡散などの要素に大きく左右されるし、センサーに砂埃が付けば感度は落ちる。
で、テストの話をするけど、セロテープをセンサーに貼るだけでも砂埃状況を再現出来るし、色や環境によって作動距離が変化するのは分かっていること。
その為に地面から80cmのマージンとっているのだから。
ついでに、セキュリティーは1ではなく2重にかけるべき。
機器は壊れたりするもの。セキュリティーホールが存在するのと一緒。
挟まれれば大怪我をする可能性があるものならば尚更。
Re:テストとコスト (スコア:2, 興味深い)
テストは確かにテストを行った部分に関しての問題のあぶり出しと通った結果による品質保証を行いうことができます。ですが、何をテストするかということについては何も保証されません。ようするにテスト漏れについてはテストでは解決しないのです。テストケースの充当性・正当性について、テストはできないのです。
今回はテストについての議論なのであまり触れられていませんが、レビューの効果も非常に大きいものがあるのではないでしょうか。もちろん、レビューですべてが解決するわけではありませんが、自分が気づかなかったことでも他人が気づくことがあるわけです。
ちょうどレビューについては今月の日経コンピュータで取り上げられているようですね。
それから、このスレッドで問題になっている森ビルの件については設計ミスだと思っています。今回の問題が起こり得るということを認識できなかった、もしくは認識していたが無視をしたかどちらかでしょう。
無視したのは論外として、認識できないということは非常に難しい話です。なんせ、当事者には問題が起きるかもしれないと想像することができなかったのですから。人は自分の想像の範囲内でしか思考することができないのです。だからこそ、自分以外の多くの人の意見を聞く、つまりレビューを行うべきだと私は思います。
ゲーム関係は (スコア:1)
ただ、テスト計画が綿密にあるかというとそうではないかなぁ。テストプレイヤーの能力によってしまっているところが強い気がします。自分のところはそんな感じです。よそはどうなんでしょう。
Re:ゲーム関係は (スコア:5, 興味深い)
プレイに関しては確かに考えようによってプレイヤーの能力に頼っているように見えますが、その間は上司の信頼度が高いと取れると思います。
会社にもよると思いますが、仕事の縛りがきつく無いという意味で綿密で無いように見えるのでしたら信頼され、自由度を与えられているだけだと思います。それに、各機能やイベント、ハードの組み合わせという仕様どおりかを確認すればいい箇所はは全てチェックさせられますよね。最低限必要な項目は日に少しずつ与えることで大半の時間が自由に見えます。
テストプレイヤーはただのバイトですが登録制です。上司は多くのプレイヤーをきちんと覚えて次回に優秀な人を採ってるはずです。そして意外性のあるバグを見逃さないためにも常に新人を絶やしていないはずです。
あまり具体的な内容を語ると守秘義務とか怖いのでこの辺にしておきますが、上司の腕力と姿勢、若さと活気、テストプレイヤーへの環境作りが素晴らしい力になっているのではないでしょうか。そうすれば我々は自然とついていきたくなるものです。テストプレイヤーがそれに気づいているかは別にして。
P.S.
書いてる間に上にコメントが増えてるようですが、永遠と同じゲームをやることは絶対楽しくありません。好きでも無いゲームや自由度の低いテストに当たればなお更です。如何に必要な項目を全てやらせつつ、自由度を増やして思いもよらないバグを見つけてもらい、部下に退屈させないか(必要な項目を挟んだり、多人数プレイ可能であればトーナメントしたりで気分転換)は上司の力にかかってるでしょう。
# どれだけ表現をぼかして語っても AC ったら AC に決まってる
Re:ゲーム関係は (スコア:2)
オンラインアップデートが出来るようになっています。
＃プラットフォームがPS2だったりWinXPだったりするんで。
で、アップデートが出来るようになってからバグが結構出てる
気がするのです。
＃ポップン11とか…。
ゲームのテストは鬼 (スコア:1, 興味深い)
バグが無いに等しいくらいになるそうです＜開発期間に匹敵するらしい
但し、それは半導体ＲＯＭの頃であってＣＤ－ＲＯＭ以降はどうだか、、、、
円盤のメディアになっての不具合がかなり多くなった感じは受けます。
それでも、各ソフトウエア会社が発注企業に納品するために作った
単品ソフトウエアよりはまともだとは思われ。
なんでか、納品期限ぎりぎりまで開発を行って
まともなチェックできなくなるのだろうか？
Re:ゲームのテストは鬼 (スコア:1, 興味深い)
> まともなチェックできなくなるのだろうか？
原因はいくつか考えられますが、私の経験上は以下の３つ
・開発会社が受注する時に出すスケジュールが既におかしい
・クライアントからの機能追加などの要望があっても、スケジュールは変えずに詰め込むから
・開発会社のせいで遅れが出ても、期限を延ばすわけには行かないので、単純に最後のステップ（テスト）が削られるから。
量も大事だけど質も大事 (スコア:1, 興味深い)
かつて、テストに一ヶ月もかけたくせに、300MB/日のペースでメモリを食いつぶすメモリリークを見逃したチームとか、仕様書の動作前提条件すら読まずにテストを書いた挙句、動作条件を満たさないテストケースで、数週間もテストを続けていた奴とかいたぞ。
しかも、どちらの事例も「テストケースのレビューをしていた」というから、ますますタチが悪い。精査をした奴は、いったい何を精査したんだ？
……で、なんで自分がその尻拭いをさせられたのは何で？ 自分は一切関わってないのに（滝涙）
＃悲しいのでＡＣ
Re:しろうとてすと (スコア:2, すばらしい洞察)
ただ、「テスト仕様書作成」と「テスト実施」は全く別の役割ですね。
新人には「テスト仕様書作成」は無理です。
--- （´-`）｡oO(平和な日常は私を鈍くする) ---
ゲームも？ (スコア:1)
外国に比べての日本のテスト事情もだいたい当てはまりますよね。
Re:PT/IT/ST (スコア:2, すばらしい洞察)
Re:PT/IT/ST (スコア:2, 参考になる)
IT = Integration Test? 結合試験のことかなぁ。
ST = System Test? 総合試験のことかなぁ。
調べると、こんなページ [hoyasv.com]が。
Re:PT/IT/ST (スコア:2, 興味深い)
お答えします。
自分たちの会社(やproject)で扱うことが可能な最小の単位を、「単体」と呼びます。
和訳：
設計が不味くて、不可分な部分が多くなればなるほど、
そのProjectの語彙で言うところの「単体」なるものは、巨大化します(藁
勘弁してくれや…(T_T)
＃とてつもなく長大なプログラムが、たった3つの「単体」から成っている、
＃と定義づけられたprojectを見たことが有るのでG7
>テスト工程において一般的な語など存在しない
基本的には一般語など「全く」無いと思うほうがいいです。
Re:Javaの場合工数が減る？ (スコア:1, すばらしい洞察)
Re:Javaの場合工数が減る？ (スコア:1)
富士通SDEMで見た記憶が。
（富士通SDEMを参考に社内用の作業標準を作ったとこも同様）
PSがプログラム設計、PGがプログラム実装、PTがプログラムテスト（単体テスト）の意味でしたっけ？
PTの後にも結合テスト以降（総合・運用とかユニット・ユーザとか方言あり）の工程があるのでそこだけ切り出すのは難しいかと。
---- 何ぃ！ザシャー
Re:今、テストと言うと (スコア:2, おもしろおかしい)
替え玉？
Re:テストもいいんだけど (スコア:2, おもしろおかしい)
# 読んでて本当にそう思った。
李 露星
Re:工程での「テスト」でなく (スコア:2, 興味深い)
「物を作る」って言ってるくせに「投入物」の検査をしないで平気という現状が異常なだけですよ。
さらには最終検査もチームのトップレベルの技術者が行なわないでペーペーが検査するに至っては。
一案として、
・客がリーダーに対して試験をするか、リーダー、サブリーダーがメンバーに対する試験問題を作って客がチェックする。
・リーダーもメンバーも試験問題を100点とるまで開発に参加させない（但しWebサイトを含めて持ち込みあり、人に聞くのは無し）。
・資材（つまりは開発者の頭脳の状態）の管理を疎かにしない。（他のプロジェクトと掛持ちのために徹夜するのは資材の横流し。）
・試験は必要に応じて何回も行なう。
やっぱりこれでも資材管理に無理がありそう。（開発者の方、資材扱いして失礼しました。）
Re:開発者でもなければ、 (スコア:2, すばらしい洞察)
買ってスグ壊れた、というのなら品質管理が悪いという話ですが、
ソニーの品は「保障期間が切れた途端」壊れるから「タイマー」なんです。
ちなみに今なお壊れず動いている骨董品、それは「当たり」の個体でしょう。同じモデルでも発売当初は（おそらく）現在の商品以上に故障していたと思いますよ。
Re:開発者でもなければ、 (スコア:3, 興味深い)
> 同じモデルでも発売当初は（おそらく）現在の商品以上に故障していたと思
> いますよ。
そういえば学生のころ、古い建造物に地震に強かったりするものがたくさんあ
るのは何故なのかと建築関係の教授に質問したら、壊れ易いと古くならないか
らだと教えられました。
あたりまえの話なんですけどね。
Re:開発者でもなければ、 (スコア:2, 興味深い)
お前なに偉そうに (スコア:2, 参考になる)
なに偉そうに言ってんだとか言われそうなので、
俺のオープン系開発の経験上学んだことを書いてみる。
○テスト項目を減らすように心がける
○項目書のコピペをするのではなく、パターン化したテストを再利用する
○テスト項目は、左から右へ並べる→デシジョンテーブルを活用する
○項目書には、バカでも理解できる日本語を書く
以上。
May the source be with you... always.