性懲りもなく暗い話題で、今日もソフトウェアの品質の話です。過去の経験(*)と試行錯誤の結果、「テストまでの距離感を近くすべし」というのが、今の結論です。これだけでは意味不明なので、説明します。

テストまでの距離感は、主に時間と人に関連します。

時間の距離感は、コードを書いてからテストをするまでの間隔です。これを短くすべし、というのは比較的受け入れやすい意見だと思います。実装終了後、翌日にテストされるのと1ヵ月後にテストされるのはどちらが良いかと聞けば、ほとんどの実装者は前者を選ぶはずです。この距離感を究極的に短くしたものが、コードを書いた後すぐに自動化された単体テストです。ここでは自動化されたテストはとりあえず置いておきます。品質改善の手段に関して言えば、テストを自動化できる部分はそもそも議論対象外だからです(手段ではなく実践の問題)。

実装からテストまでの距離感を短くすることの正しさが自明かと言うと、事はそう簡単ではありません。機能Aを実装してテストした後、機能Bを実装した時、機能Aが壊れているかもしれない、という場合、機能Aのテストをやり直す必要があります。少なくとも、壊れていないことをある程度確信できない限り、テストが必要です。これを聞くと、機能Aのテストは機能Bの実装後にした方が良い、と考える人がいても不思議はありません。一方、どうせ一回のテストで完全なバグの発見はできないので、最初に機能Aのテストをしっかりやって、機能Bの実装後にまた別の視点で機能Aのテストをすれば更に品質が良くなるはず、という考え方もできます。個別の話になれば、結局はトレードオフの問題になります。

このように距離感を詰めることの弊害はありますが、基本線としては、距離感を近くすべきだという意見です。経験上、距離感をあけてしまう弊害の方が大きいからです。

人の問題はもう少しデリケートです。正直、時々自信がなくなり自問自答しますが、それでも距離感を近くすべし、が結論です。人に関して距離感が最も近いのは、実装した人間が自分でテストをするパターンです。これだけが不十分なのは流石に自明で、これを良しと言う気はありません。「ソフトウェアテスト293の鉄則」(http://dev.ariel-networks.com/Members/inoue/software-testing)での一番の収穫「多様な視点の重要さ」は今回の記事とは直交して、依然として最重要な鉄則だからです。多様な視点は置いておいて、ここでは、実装者と良くコミュニケーションできている人ほど、より距離感が近いと定義します。最も距離感が遠いパターンが、いわゆるテスト責任者(とテストチーム)を置いて、各実装者がその人にお任せ状態になるパターンです。心理的には、どこかの誰かがバグを見つけてくれるだろう状態です。一方、テストをする人の距離感を近くするスタイルにも異論があります。距離感の近さは、実装者と同じような見落としや盲点を抱えこむ危険があるからです。

時間同様、それでも結論は、人に関しても、テストの距離感は近くすべし、です。経験上、距離感をあけてしまう弊害の方が大きいからです。

見て分かるように、実際には、両者とも距離が近ければ近いほど良いというほど単純な問題ではありません(**)。本当の正しい答えは、適切な距離感がある、なんだと思います。しかし、適切な距離感と言うだけでは、何のなぐさめにもなりません。なので、より近い距離感、という姿勢は、適切な距離感を導くためのプラクティスだと考えています。例えて言えば、現役時代の落合が内角高めの一番速い球にタイミングを合わせていたようなものです。

(*)ロータス時代までは自分の書いたコードにバグが無いかしか考えていませんでした。全体の品質なんて気にもしませんでした。Notesはバグが多いなあ、と思ってもそれは他人事でした。他人の書いたコードも含めてソフトウェア全体の品質をまじめに考えだしたのはアリエル以降です。そういう意味では、ソフトウェアの品質管理に関する経験は6年程度です。長いと言えば長いし、短いと言えば短い時間です。

(**)単純な問題でないことは初めから自明ですが。