« アメリカのレストランでの注文の心得 | トップページ | ポケモン スタンプラリー 2006 »

2006/10/11

テスティング -テスターの心得-

 今回は、テスターの心得、心構えについて書いてみようと思う。
なお、記述している順番は、優先順位ではない。たんに私が思い出した順番というだけである。

 まず、悪役になるつもりでいること。
バグという相手の欠点を声高に訴えなければいけないという点で、テスターというのは損な役回りである。伝え方を間違えると、簡単に恨まれ役、憎まれ役になってしまう。
そうならないためには、常日頃からプログラマーとの交流を図り、プログラマーの揚げ足をとっているのではなく、プログラマーがあとで恥ずかしい思いをしないようにお手伝いをしている、というようなことをちゃんと伝えておくことが重要である。
そうは言っても、不興を覚悟で大量のバグを報告しなくてはいけない場合もある。そんなときは、自分が悪役になって憎まれ役になる覚悟が必要である。プログラマーに気を使い、見つけたバグも報告できないようでは、プログラマーを一時的に満足させられても、プロジェクト全体から見ればきわめて危険である。

 次は、プログラマーの言うことを鵜呑みにするな。
私の経験だけから言うと、お世辞にも優秀とはいえないプログラマーほど、変に根拠のない自信をもっている。曰く、「私の書いたプログラム完璧である。バグなどない。」と。しかし残念ながら、そういったプログラマーが書いたプログラムにこそ、それこそ山のようにバグが見つかるものである。優秀なプログラマーは常に慎重であり、常に自分がバグを作っているのではないかと不安をもっている。
大昔の話であるが、ある製品の最初、二番目、さらに三番目のバージョンで私は同じ機能のテストを任されていた。担当したプログラマーはバージョンごとに違っていた。三番目のバージョンを開発しているある日、三番目のプログラマーが私のところに来て、「機能を実装したのでテストして欲しい。私は過去のバグをきちんと把握して、二番目のバージョンの反省を生かして、まったく別なプログラムを書いたのでおそらくほとんどバグはないでしょう。特に同じよなバグはありません」 と自信満々であった。そこで私は早速テスト段階のプログラムをテストしてみるとはたして・・・。出るわ出るわ、一番目、二番目で行ったテストを、三番目のバージョンでテストしてみると、違う人が違うプログラムを書いているにもかかわらず、なぜか一番目や二番目とおんなじバグが見つかるのである。私はおかしくておかしくてしょうがなかった。
また別な日には、私が見つけたバグの話をしにきた。「これはシステムのバグだよ。俺のじゃないよ。80~90%の確率でシステムの問題だから、俺は治せないよ。」 といってきたのである。そこで私は、「それじゃ~、どんな風にシステムに問題があるのか報告しなくちゃいけないので、調べてもらえないかな?」 とお願いした。数日後、再び同じプログラマーが私のところに 「ゴメン。この間のバグ、やっぱり俺のバグだった。(^^ゞ」 と言いに来たのである。
それらの経験から私は、「プログラマの言うことを鵜呑みにしちゃいけないな~。ちゃんと自分で確認するようにしないといけないな。」 と学習したのである。上述のプログラマーもそこでずいぶんと反省したようで、以後は自信過剰になることなく、きわめて優秀なプログラマーとして、今も第一線で活躍している。

 上記の事例は別なことも示唆している。それは、プログラマーとテスターがうまく協調していければ、お互いにすばらしく成長することができる、ということである。
プログラマーとテスターというと、どうもよくない関係になる話をよく聞く。強い敵対関係となり、互いにののしりあうような関係。プログラマーがテスターを従属させて、テスターがプログラマーに気を使いながらのテストを強いられる。などなど。
テスターはプログラマーとうまい協調関係を築くべきである。プログラマーとテスターがうまく協調すれば、プログラムの品質は飛躍的によくなると、経験上から私はそう信じている。

 仕様を鵜呑みにするな。
プログラマーと同じく、仕様を絶対正しいものと信じてはいけない。仕様を作っているのは人間である。人間であればどこかに間違いはつき物である。
間違いといっても、1.仕様そのものに矛盾があったり、抜けがあったりする誤り、と 2.仕様が想定されるユーザーの要求を満たしていない場合の二種類ある。
1.については、論理的な思考があれば比較的簡単に気づくことができる。一方の 2.については、自分自身がユーザーの要求をきちんと理解していないと気がつきにくい。このことから、テスターも仕様策定者と同等かそれ以上にユーザーの要求を理解している必要がある。

 ユーザーやサポートの話をよく聞く。
私の場合、パッケージソフトに参加していたため、一般ユーザーからの問い合わせをサポートチームから聞くことが出来た。多くは、マニュアルに書いてあったり、ユーザーの勘違いであったりする。しかし、極稀にとても有用な、問題の本質を鋭く突くような質問をしてくるユーザーがいる。そういうわずかな鋭い質問を自分テストに生かすことでプログラム全体の質を上げていくことができる。
また、サポートと親しくすることには別の意味もある。サポートの人たちは当然製品を作っているわけではないので、製品の細かい部分や成り立ちを知らない場合が多い。そこで、製品開発に携わっているテスターが製品の細かい部分をサポートの人たちに教えてあげるのである。すると、サポートの人たちの知識レベルが上がり、一般ユーザーへの対応の質も上がってくる。サポートは一般ユーザーとの接点であることを忘れてはいけない。サポートの質が上がれば、バグや使い方がわからないことで製品に失望しかけているユーザーに、逆に満足感を与えることも可能となるのである。ユーザー間のコミュニケーションを軽く見てはいけない。小数の満足したユーザーがより多くの製品選択に影響を及ぼすことは十分にありえるのである。

 見つけたバグはすぐに報告する。
ゆめゆめ、あとでまとめて報告しよう、などとは思わないほうがいい。バグは速く直せば直すほど規模も小さく時間もかからずに直せる。もちろんバグを作らせなければ、バグの修正にかかるコストも時間も0である。
出荷間際になるとついついバグの報告を躊躇してしまうテスターがいる。「なぜ、今まで見つけられなかったのか?」 などと叱責されることを恐れたり、今まさに出荷しようとしているのにそれに水を差しかねないバグを報告することに、二の足を踏んでしまうのである。
冷たい言い方になるが、その程度のことを恐れるようならテスターをやめたほうがいい。最初に言ったように、テスターは時には悪者にならなければいけない。また、出荷直前に致命的なバグを見つけたからといって白い目で見られるようなチームからは早いところ抜けたほうがよい。
出荷してからバグを修正するのと、出荷を延期してでも出荷前にバグを修正するのでは、コストやブランドイメージの損失に桁違いな違いが出る。もちろん出荷後のほうが損失がはるかに大きい。
見つけたバグは、その大小にかかわらず、きちんと確認を取って、速やかに報告できること、がテスターにとってのだいじな資質の一つである。では、確証がすぐに取れない場合はどうすればいいのか? 簡単である。プロジェクトのリーダー、場合によっては全員に相談すればいいのである。例えば、「どうやら XXX なバグがありそうなのだが条件が見つからない。心当たりのある人は教えてください。」 といったぐあいである。

 聞きに行きやすい人ではなく、答えを知っている人に聞きにいけ。
こればテスターに限った話ではない。疑問が生じたときに、いつも決まった人に聞きにいくテスターがいる。それも、自分と同じぐらいの知識レベルの人にである。自分が知らないのだから、たいていは聞かれたほうも知らない。知らないもの同士が 「あ~なのか、こ~なのか」 と無駄な時間をすごしているのをよく見る。
確かに聞きに行きやすい人というのはある。しかし、それを優先していては時間を浪費するばかりである。疑問を持ったのなら、知っている人、あるいは知っている人を知っている人に真っ先に聞きにいくべきである。
「いや~、あの人なら知っているだろうけど、聞きにいくと怒鳴られたりいやみをいわれたりするんだよね~。」 との言い訳をよく聞く。バカ者である。疑問を解消することが最優先なのだから、怒鳴られたりいやなことをいわれたりすることを理由に時間を無駄に使うべきではない。この場合、「急がば回れ」 ということわざは当てはまらない。

 これ以外にも普段から心がけていたことがあったような気がするが、今は思い出せない。また思い出したときに続きを書くことにする。

 ソフトウェア・テスティング の個人的な文書にしにくいこと、あまり専門書などには書かれていなさそうなことは数回に分けて一通り書いたつもりである。私は現場を離れてしばらくたつことから、最新の技術的なことについては、最新の書籍や他の現役のテスターのブログを見てもらったほうが参考になるはずである。
次回からは、数回に分けて “ユーザビリティ・テスト” について書く予定である。

|
|

« アメリカのレストランでの注文の心得 | トップページ | ポケモン スタンプラリー 2006 »

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

コメント

コメントを書く



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




トラックバック

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

この記事へのトラックバック一覧です: テスティング -テスターの心得-:

« アメリカのレストランでの注文の心得 | トップページ | ポケモン スタンプラリー 2006 »