我がソフトウェア開発部には、単体テストグループというワークグループが存在します。
このグループでは社内の単体テストの品質を上げるための活動を行っており、
ようやくこの３月に単体テスト手順の改訂版を社内公開する運びとなりました。

これまでにも単体テスト手順や、単体テスト報告書（チェックシート）というのはあったのですが
それを社内に普及し、浸透させるという点では、まだまだという感が否めませんでした。

数年前までは、基本的に新人教育の一環としてプログラム応用の際に一緒にテスト手法も教える
というスタンスを取っていたのですが、社員数も増え、開発手法も多角化していくことで
単体テストの重要性が社内でも高まりました。
そのため開発者本人のテストに加え、作成者以外の単体テストも行うようになり、
２年ほど前から教育講習に単体テスト自体のコマも作ることとなりました。

しかしプログラマの方ならお分かりかと思いますが、プログラムを覚えたての頃というのは
とにかく作ることのほうが楽しくて、テストなどはついつい疎かになりがちなのですよね。
また教育だけで教えるのでは、楽しいことのみ覚えて、テスト手順など忘れてしまう、、、
人によってテストの仕方が違う、テスト項目に漏れがある、、、
プロとしてはあるまじきことですが、そんなことがありえてしまいます。

では、会社としてどのような対策を採るか？
そんなことを考えた時に、ではその通りの手順に沿ってテストを行えばよいという手順を作ろう
ということになりました。

しかしそこからがまた苦難の道でした。

なんとか漏れなく手順書を作ろうとすると、手順の中にやけに細かい内容まで書かれており、
読むだけで骨の折れる(中堅プログラマにとってはある意味無駄な)作業になります。
例えば、数値チェックなら「最大桁数を入れてみる」とか、「小数点を入れたらどうか」とか
「空白や文字列を入れてみる」とか。

しかし無ければ無いでそういったチェックが漏れてしまう可能性もあるのです。
そこで既に以前に作成されていた単体テスト報告書（チェックシート）へ細かい内容は移し、
手順書には実際の手順に沿ったことのみを記載するようにしたようです。

実際の手順というのは、例えば、OKであればレ点でチェックしていく、とか
NGであればハードコピーを取ってマーカーで色を付けていくなど
ある意味、こんなことまで紙に書いておくのは開発者として恥ずかしいのではないか？
という部分が無きにしも非ずといったところはあります。

しかしこういう手順を何度も繰り返し読んで実行することで、開発者として恥ずかしくない
テストの手法を身に付け、品質を上げてもらう。プロは自分の作品に責任を持つ。
そこを目指したいと思います。