hirschkalb's blog

"I beseech you, in the bowels of Christ, think it possible that you may be mistaken."

001 ソフトウェアテストの憂鬱 software-testing blues

少なくとも日本国内のソフトウェア開発を行う中小企業において、ソフトウェアのテストが新入社員の担当となることはさほど珍しいことではない。よりマクロに見てみると、大手企業が自分より小さな企業にテストを依頼することが多い。端的にいえば、力関係の弱い側がテストを任されることが多いのである。


さて、新人や協力会社にテストをさせたほうがよいと思われているのはなぜだろう?

答え: 問題が「新人や協力会社にテストをさせたほうがよい理由」ではなく「......させたほうがよいと思われている理由」を問うていることに注意しよう。以下に述べる理由も「とされている」の括弧つきです。


(1) テストは容易だから(とされている)*1というのが第一の理由だろう。中小企業の新人のはじめの仕事はだいたい電話応対、お茶くみ、来客対応、郵便、掃除といったところだろう。


これは、会社業務の中では比較的やさしく、かつ新人の低い単価でこなしたほうが会社からみて合理的だからである。


(2) テスト後の市場での実運用で重大な欠陥が発覚した場合、その責任の所在を協力会社に求めることで本社のダメージを抑えることができることが第二の理由として挙げられる。


(3) 工程の遅れをテストのせいにすることができる。その際、原因は力関係の弱いものに求めたほうがよい。テストはその性質から製造に先立つことはできない(作る前にテストするのは不可能である)。したがって必ず開発工程のなかで最後に位置せざるを得ない。


前工程の市場調査・検討・デザイン・プログラミングが遅れても、一般的にあらかじめ定められたデッドラインは不変である場合が多い。この傾向は本社の力が強い企業においてほど顕著である。そうなると自動的にテストにかけられる時間は少なくなる。


さて、デッドラインが不変であることは先に述べたとおりだが、テストの量も多くのばあい不変である。品質保持・向上の名目のもと、いかに前の工程で時間が食いつぶされようと予定されていたテストは必ずすべて遂行されるべく要求されることは決して珍しいことではない。


本来あたえられていた時間内でちょうど実行可能なテストを設計していた場合(ふつうならばそうだろう)、その時間が削られたならば時間内で遂行不可能なことは自明である。したがって論理的帰結としてテストは当然おくれるのであるが、これは実は開発全工程の遅れでもある。テストは全工程の最後の工程だからだ。


開発工程の遅れの原因を問いただされたとき、直近の原因はこのようにしてテスト工程の遅れとされる。犯罪を犯したとき、その原因を犯人の中に求めるだろう。犯人の親、祖父母さらには曽祖父母にまで求めるようなことはないだろう。同様にして開発工程の遅れはテストの遅れとして回収される。


さて、テスタの役割は不具合を見つけることにあるが、不具合を見つけるとそれの改修が必要になる。改修にはそれなりの時間がかかる。不具合を見つけなければ時間内に終わらせることができたはずとされる場合、遅れの原因はアーキテクトやプログラマに求められず、テスタに求められがちである。


不思議なことであるが、テストにかかる時間の見積もりには、不具合が見つかった場合のレポート・改修・レグレッションテストの時間は含まれていない場合が多い。まさかと思う場合はスケジューラにたずねてみよう。


(4) 先に書いたとおり、テストとはある意味で不具合を見つけることである。不具合を見つけられた製造者は大抵、いい気分ではない。中には怒りを示すものもあろう。その敵意を受け止めるには力関係の弱いものが適切である。


(5) 繰り返しになるが、テストとは品質を請合うことである。不具合がユーザの手によって発見された場合、直近の責任者はテスタであろう。先に犯行の原因をその犯人の1、2親等までは求めないことを述べた。この手法がここにおいても適用される。


川に毒物を流すことを計画したのがAで、川に実際に毒物を流したのがPで、川下で毒を中和するのがTの仕事だったとしよう。最下流で川の水を飲んで具合の悪くなったユーザがあった。さてユーザは誰を非難するだろうか。この業界では圧倒的にTの非難されることが多い。

*1:以下「(とされている)」は省く。

広告を非表示にする