＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
テストは楽しい
| 投稿者 | 投稿内容 | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-05-21 17:30
こんにちは。
うちの会社の品質保証部隊の人たちは、仕様書に書かれていないことを 徹底的にテストしますね。 仕様書に書かれているようなレベルのテストは作成者がやってますから。 「マニュアル？そんなものユーザが読むわけないだろ」を合言葉に むちゃくちゃなテストをしてくれますので助かります（？） 例：インストール後、いきなり必要なファイルをいくつか削除して、 起動してみるとか。 とはいえ、理不尽な不具合報告も結構あって困りモノではありますが、 そのくらいやらないとOSやDBを製品として売ることはできませんよね・・・。 | ||||||||||||||||||||
|
投稿日時: 2004-05-21 17:33
あ〜テストですか？
ATMのテストやってた時は地獄でしたね〜 なかなか減らないテスト項目･･･ 焦燥感に駆られるプログラマー･･･ あても無く場内をさまよい歩くリーダー･･･ やたらと怒鳴り散らすようになった管理職･･･ 次々と去っていくメンバー･･･ これを乗り越えて現在の私があるのですね〜 [ メッセージ編集済み 編集者: たーぞう 編集日時 2004-05-21 17:36 ] | ||||||||||||||||||||
|
投稿日時: 2004-05-21 17:34
NAL-6295です。
この場合、プログラマが勝手に「A でも B でもなかったら？」 の仕様をきめて、コーディングをするわけにはいかないので、設計者と相談の上、仕様書に追記する必要がありますね。 よくある仕様記述漏れです。 で、まぁ、このあたりは、プログラマがちゃんと設計者にフィードバックしないとね。といったあたりで、同意です。 個人的には、設計→テストケース作成→実装が理想かなぁと思っています。 テストケース作成作業は、設計の矛盾、漏れを浮き彫りにするテストも兼ねているからです。 #スレッドから脱線しますが、このあたりの仕様書の記述について、他スレッドで紹介した「ソフトウェアピープルVol4」の特集で言及されていますので、参考になるかもしれません。 | ||||||||||||||||||||
|
投稿日時: 2004-05-21 18:05
はにまるです。
一般に仕様書と言うと、静的モデルの仕様設計書が多いのですが、 最終工程までテスト漏れとなるのは、動的モデルの仕様に対する箇所と プログラム内部ロジック固有のバグが非常に多いです。 前者の理由は簡単で、動的モデルの仕様設計書を記述しないからなんですね。 ^^;てへ 基本設計レベルであれば、プロセス及びデータの関連図と 制御に関連する区分情報の組み合わせでテストケースを済ませる事が多いです。 簡単かつ即効で出来る動的モデルの設計手段って無いですかね？ また、動的モデルも記述しようと思えば無限に記述出来るので 効果性の高い動的モデル対象の抜粋方法とか... そこら変ってオブジェクト指向の設計関連の本で取り扱ますか？ 後、後者についてはＰＧさんが責任を持ってテストして欲しいです。 内部ロジック固有のバグに対するテストは、開発者自身しか思いつかないのだから．．． 説明： ＜内部ロジック固有のバグ＞について 繰返処理で１回目と２回目以降のロジックが異なる場合等。 [ メッセージ編集済み 編集者: はにまる 編集日時 2004-05-21 18:07 ] | ||||||||||||||||||||
|
投稿日時: 2004-05-22 13:52
もうちょっと書きたくなってきた…。
ちょっと脱線になるのかもしれませんが。(^^; テストって、モノが出来上がってからやるじゃないですか。 結合テストなんて、そのまた先ですし。 そんなときに抜けが発覚して、
なことが 同時多発＆連続爆撃 で発生すると、
のようになってしまいます…。 （たーぞう さんのおっしゃるような現場は、私も経験しています。よく死人が出なかったよな…） 仕様の範囲内で起きたバグであれば、開発者側のみで対応ができるはずですよね。 （もちろん工数は膨らみますけど） 開発者は 「また仕様変更かよ！設計悪すぎ！」 と文句をつけ、 お客さまは 「今更そんな細かいことをイチイチ聞いてくるなよ！だったらこうしてよ！」 と根底から覆るようなことを言いだし、 管理者は 「どうしてこんなことになったんだ！」 と喚き、 設計者は 「開発者のスキルが低いからだ、お客がわがままだからだ、管理者は俺の立場を分かっていない」 と嘆く。 そうして、できる or 諦めた人から会社を去っていき、そんな環境で有望な若い方が育つはずもなく、残った人もやがては疲れて気力を失くしてしまう。 そんな状況を、いくつか見てきました。 …そんなの、やめません？ 一人じゃ作れないモノなんだから、みんなで力を合わせれば、何とかなるんじゃないの？ ということで、「テスト」 に着目してみたのでした。(^^; 七味唐辛子 さんや nori さん、okutin さんのところの品質保証部隊の方々は、どんなテストの勉強をされているのでしょう？ とても興味があります。 
NAL-6295 さんへ＞ これから実家に帰省するので、移動がてらオススメの雑誌を読んでみますね☆ [ メッセージ編集済み 編集者: はゆる 編集日時 2004-05-22 13:54 ] | ||||||||||||||||||||
|
投稿日時: 2004-05-22 14:11
こんにちは。 これは、おかしいですね〜。ソフトウエアは種類によってそういう 嫌がらせ？無知？に対する防御策を取る必要があるものとないものが あると思います。この場合は、デスクトップ用アプリケーションのようですので やりすぎです。これでも対策をとらなければならないなら、切りがありませんよね。 コンピュータはユーザーさんのところにあるんですから、どうにでも出来てしまいますよね。 いきなり電源コンセントを抜くことも可能ですし。。。 逆に、WEBサーバのような不特定多数のアクセスがありえるソフトウエアなら、 テストのやりすぎはないですね。ありえないケースも含めてテストすべきですね。 _________________ | ||||||||||||||||||||
|
投稿日時: 2004-05-22 15:48
はゆるさん、takuさんお返事ありがとうございます。
完全に脱線でごめんなさい。
同じ設計書を見れば誰でも同じものが作れるのが仕様書だと思っています。 工業製品ならそうですよね？ 工数が膨らんだら、その責任（追加費用）は仕様漏れを起こした会社（部門？）が 負担すべきで、そもそもそういう会社は「SEの技術力がない」という評判が広まりますし、 追加費用を払わないところだと見積もり時に仕様変更分を最初から計上しておいたりと、 開発者側が自衛しないといけませんし。
管理者なら喚くだけじゃダメですね。 コストと利益が明らかに見合わない状態なら賠償金を払って手を引くのも一つの手です。
力は合わせますが、「（無償の）労力を出し合って」は会社として機能していない 状態だと思います。 この業界ってコストとリスクの見積もりが恐ろしく甘いような･･･って人のこと言えませんが。 でもたぶんはゆるさんみたいな方がプロジェクトリーダーならみんな頑張って働こうと 思うのだと思います。なんだかうらやましくなりました。（嫌味じゃなくて、本当にです） まったくの脱線でごめんなさい。。。 | ||||||||||||||||||||
|
投稿日時: 2004-05-22 20:23
そうですか？ ユーザの誤操作とか、全く関係の無い他のプログラムが なにかしでかしたとか、その他いろいろな理由でそういう状況になる ことはあり得ますが。 その状況においても、たとえば「ファイルシステムを破壊する」といった ような致命的な動作をしないことはチェックすべきかと。
システムまわりのプログラムなら、その場合でもできるだけ不具合が 発生しないようにすべきですね。 # 現代のHDDを使っている限り、「絶対に発生しない」というところまで # もってゆくのは不可能ですが。 | ||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.