良い試験項目の作成方法について

アイスケットでは中小企業向けのシステム開発を行なっているのですが、いつも苦労するのが試験項目の作成と評価です。

実装者は無意識にバグを避けた試験表を作ってしまう

以前務めていた会社では、プロジェクトのメンバーが複数人いたこともあり、仕様書作成(＆実装)チームと試験表作成チームで作業を分業し、試験項目は仕様書をベースに機能を抽出し、機能の内容に基いて試験項目を抽出していました。そして評価も別チームが実施していました。

作業を分けている理由は実装する人は良い試験表を書けないからです。実装者はバグが出るのを嫌うため、試験表を書いても無意識にバグを避けた試験表を作成してしまう傾向があるのです。リリース後にバグなんて出ようものなら、まずデグレが発生しないように修正には細心の注意が必要だし、バグを直した後には上司に報告書を書いたりなどと面倒な作業が山積みだからです。「バグが出る→作業が増える→残業確定」という流れがあるため、バグが出ないような試験表を作りたくなってしまうのも仕方ありません。

よって、試験は試験専門のメンバーが行い、情け無用の試験を行う必要があるのです。そして、その発見したバグの扱いも重要です。それは、開発メンバー全員に公開すること(Webで管理できるバグ管理システム（影舞、Bugzilla、Tracなど、私はRedmineを利用していました。）が便利)です。そうすることによって、バグの存在が誰の目にも明らかになり、実装者はそのバグと真正面から向き合わなければならなくなります。メンバーの中にはバグを試験者からこっそり教えてもらって、こっそり修正したり、闇に消し去ったりする人もいるので、バグを公開するのは良い試験を行う必須条件です。（そういうこっそりとしたことをするメンバーは上司からの評価をやたら気にするタイプや、自分は出来る人間だと勘違いしているタイプに多いです。気を付けてください。）

1人で試験表を作成するために

前置きが長くなりましたが、ではアイスケットの場合は社員は私1人です。どのようにして良い試験を実施すべきか悩みました。1人で仕様書作成、実装、試験を全て行わなければならず、先程述べたような無意識にバグの発見を避けた試験表を作成してしまうというリスクを潜在的に抱えているわけです。

それを回避する方法として、私が採用しているのはとてもシンプルなものになりました。機能を細分化していき、もうこれ以上分離することができない単機能にまで絞り込みます。その絞り込んだ1つの機能に対して、試験項目数を最低10つ作り出すというものです。かなり細分化しているので、10つの項目を導き出すのは苦労しますが、なんとしても10つ考えてやろう！と、ゲーム感覚で試験表の作成に取り組めています。簡単に10つの試験が考えられた時は、機能の絞り込みが完了していないと判断し、機能の分割を行えないか検討します。分割ができない場合は、試験数を20つに設定するようにしています。

試験のプロの方から見れば、なんだそれ？といった試験項目の作成方法です。しかしながら、ゲーム感覚で試験と向かい合うようにすることで、客観的な試験項目を作り上げることに成功しているのも事実です。

数の設定を行うというのがポイントで、このようにすると、なぜかバグを回避しようとする潜在意識を取り払うことができるのです。あらゆる角度から客観的に機能と向き合わなければ10つという試験項目数を導きだすことはできないからです。

現在、実装が完了し、試験中のシステムもこの試験項目作成手法にすごく助けられています。自分で試験表を作りながら、「あー、このパターンは実装漏れしてる！」って言ってしまうことが良くあります。

まとめ

今回は試験表を作成するということと、1人で試験表を作成する時の私の作成方法をご紹介しました。私がやっている方法はあくまで1つの方法であって、他にも良い試験表を作成するための手法が数多くあります。「私はこうやって1人で実装と試験表の作成も行なっているよ！」という方がいらっしゃいましたら、ぜひ紹介して頂ければと思っています。

品質の高い、便利なシステムをたくさんの方に使って頂き、本来力を入れるべき仕事に十分に能力を発揮できる仕事環境をITという側面からサポートするのがアイスケットの使命だと考え、日々精進しています。これからも宜しくお願い致します。