« 地デジ、血出ジ? | トップページ | アメリカのレストランでの注文の心得 »

2006/10/09

テスティング -テスティングの勘所-

 “勘所” というとなにか漠然とした感じがする。そして、今回の内容も漠然としたものになっている。申し訳ない。

 ここで言う “勘所” とは、「なんとなくこのへんがあやしい」 「このへんにバグが潜んでいそうだ」 という、どちらかというと非論理的な推察をいう。であるからして、あまり論理的に説明できない。
ただ、たしかに経験を積み重ねていくと、バグがありそうな場所が “見える” のである。某超有名ロボットアニメの主人公のように。(^^ゞ

 まず、一般的な話としては、よくバグが発生する条件というものがある。

“境界条件”: 例えば、あるエディットボックスで 1~10 のみを許容する仕様としたときの、0や11。65536 (2の16乗)など。
“文字コード問題”: 今はあまり使われないが、ShiftJIS のときの 0x5c など。昔はこれでよく文字化けしたものである。
“ストレス下”: 物理メモリやシステムリソースを使い切ったときの挙動。動作が極端に遅くなるのであまりやりたくないテスト。自動化テストがお勧め。ただし、自動テスト ツールが先に根負けする場合あり。(汗)
“巨大ファイルの読み込み”: データベースは別として、ワープロとかスプレッドシートの場合、1GB とかの巨大なファイルを読み込んでみる。これも自動的にやらせるのがお勧め。

これ以外にもいくつかの条件がある。
慣れたテスターであれば、まず真っ先にこういった条件でテストをするようになる。

 ある意味ここからが本編である。
ソフトウェアも人間がくみ上げるものであるから、バグの出方にも当然個性が出てくる。あるプログラマーは偉ー処理を軽視する。別なプログラマーはルーチン処理でよく無限ループにはまってしまう。などなど。
(余談になるが、少し前にやはり某超有名ロボットアニメの世界を使った MMORPG のベータに参加していた。そこで新しい機能が実装されるとまったく違う関係のない機能であっても、なぜか毎回似たようなバグが組み込まれていた。そのことから私は、その MMORPG の実装を担当しているのが実は一人なのではないかと予想していた。)
話を戻そう。バグのくせを見つけるためには、まずプログラマーの性格を知ることが重要となる。そのために私はよくプログラマーに話を聞きにいった。仕様をどう理解しているのか、その理解をどういうアルゴリズムで実装しようとしているのか、自分でも自信がないところ、などなど。雑談を織り交ぜながら、しょっちゅう話を聞きにいった。
これの問題は、やりすぎるとプログラマの邪魔をしてしまうところである。また、周りからプロジェクトの邪魔をしているやつと見られてしまうことである。それを回避するためには、やはりきちんとバグを見つけて、報告して実績を示すことである。そうすれば、「あ~、あいつはあーやって多くのバグを見つける努力をしているんだな」と見てくれるようになる。
そうやって、担当プログラマの性格=実装パターンが見えてくればしめたものである。某超有名アニメの腐海に遊びにいく主人公が風が見えるように、目の前のソフトウェアにバグが見えるようになってくる。

|
|

« 地デジ、血出ジ? | トップページ | アメリカのレストランでの注文の心得 »

テスティング」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/61641/12043763

この記事へのトラックバック一覧です: テスティング -テスティングの勘所-:

» プログラマーとテスターのコミュニケーションをベースにした品質向上について [ソフトウェアテストの勉強室]
各方面でソフトウェアテストについてのブログ記事が登場してて、それを読むだけでも勉 [続きを読む]

受信: 2006/10/12 13:29

« 地デジ、血出ジ? | トップページ | アメリカのレストランでの注文の心得 »