高コスト低リターンのテスト

低リターンのテストにやたらに体力を掛けてしまい、成果物の品質が悪くなる。そんなプロジェクトが珍しくありません。

なぜ低リターンのテストに体力が掛けられるような事態に陥ってしまうのか。その理由はプロジェクトが効率的に回っていないからです。

プロジェクトを効率的に回すためには、重要で効果の高いタスクに適切にリソースを配分し品質のよい仕事をさせることです。
重要な仕事を思いついてそこにリソースを回すくらい誰だって出来ます。だから効率的なプロジェクトとは、ちゃんと無駄な作業を定義しそれを行わないという判断ができるプロジェクトなのです。あるタスクを「行わない」とする判断こそが重要なのです。

言葉にすると簡単ですが、実行するのは実に難しい。普通のプロジェクトではタスクの優先付けをするのが精一杯だと思います。そこから一歩進めて「優先度の低いタスクを行わない」という意思決定ができるマネージャやリーダーはなかなかいません。それどころか「あれもこれも」とムダな作業を思いついてどんどんタスクを積み上げて行く人の方が多いくらいです。
人はとにかく作業に意味を見出したがりますし（そして大抵何らかの意味は見出せます）、自分の思いつきを他人から「意味がない」と言われることを嫌います。だからタスクは増える一方でなかなか減らない、ということになってしまいます。

話をテストに戻しましょう。
やるべきではないテストにはどのようなものがあるでしょうか。私が真っ先に思いつくのは以下の二つです。

１．OSのシステムクロック変更（時間を進めたり戻したりする）テスト
２．バッチ／オンラインカレンダー変更

まず１の時間を進めたり戻したりするテスト。

【無駄な理由１】システム的に無意味
まずシステムクロックは時間ではありません。UNIXを知っている方なら誰でもご存知かと思いますが、1970年1月1日、00:00:00からの秒単位のカウンターに過ぎません。
だから例えば「システムのカットオーバーが1年後だからシステム時刻を1年進めよう」という思いつきで時刻を進めたとしても、カウンターが数千万先に進んだ、というただそれだけの話なのです。しかも「カウンターを先に進める」というカットオーバー時にあり得ない設定変更を加えてテストをしている。
特にカウンターを意識してコーディングしなければ、プログラムはカウンターに依存せずに動きます。プログラムに関係のない設定変更をしてテストをするのは、全くのムダです。そんなことに体力を使うくらいだったらテストを2回した方がよほどましでしょう。

【無駄な理由２】時間の概念を全く考えていない
時間とは何でしょうか。昔から哲学者や物理学者が考えてきた深い問題です。生きられる時間。運動としての時間。物理学上のモデル化された時間。
時間というものを少し考えてみれば、システムクロックなどとは全く無関係であることにすぐ気がつくはずです。時間を進めることは人には不可能です。私にはこれほど自明なことはないと思えます。
システムクロックを先に進めて「今日は一年後だ」などと考えるのは、日めくりカレンダーを10枚めくって「10日たった」と考えるのにも等しい。進んだのは時刻ではない。単にカウンターを進めるというあり得ない操作をしただけです。あるいは日めくりカレンダーが10枚分余計にめくれた、それだけのことです。
これをテストの前提にするなど、全く意味がないと言えるでしょう。

【無駄な理由３】それこそ時間がもったいない
何台もあるサーバーの時間を変更する作業と、時間を戻してログをチェックする作業がもったいない。

２のバッチ／オンラインカレンダー変更。「明日は実際には水曜だけど日曜だ」というやつですね。それも人が勝手に思い込んでいるだけならいいのですが、システムに定義されているカレンダーを変更してまでテストをするから始末に悪い。

無駄な理由については先に述べたこととほとんど変わらないので割愛しますが、ようするに何をテストすべきかがちゃんと把握されていないために無駄なテストが行われてしまうことになるのです。

私はテストの計画時には以下の項目を押さえておくべきだと思います。

１．優先度を考慮すること
２．インターフェースを考慮すること
３．不安駆動や思いつき駆動になっていないか反省すること

１はテストに限らず重要なことです。無駄なテストは行わないこと。それによって時間と人という貴重なリソースを、例えばテストの結果照合やテスト手順の精緻化というもっと大事な仕事に回すことができます。それからテスト中に発生するであろう障害や問題に対応するための、余力も確保して計画しておくべきでしょう。

２はシステムに無関係なファクターをテストに持ち込まないことです。
オブジェクト指向という文脈でのインターフェースという言葉は、プログラミング以外のエリアでも有効です。すなわちインプットとアウトプットを明確に把握すること。システムに影響を与え得るファクター（＝インプット）は何か。そのファクターのうちでテストをしておくべきものは何か。そしてそのパターンは。期待されるアウトプットは何か。
システムクロックやカレンダーはほとんどのシステムではインプットにはなりません。そのような要素をテストに持ち込んでも意味はありません。

３は単なる思いつきや不安を、簡単にタスクに落としてはならないということです。不安のスコープと原因と解消、それぞれに道筋をつけた上で、さらに優先付けし、必要があれば切り捨てなければなりません。不安から生じた思いつきのタスクをいちいち持ち込んでも、現場が疲弊するだけなのです。

以上。今回はなんだか熱くなってしまいました・・・