単体テストをする際、
最初に仕様書を読み、テストの計画を立てます。

ここでいう「計画」とは、
どのようなデータでテストを行うか、
条件を網羅できるようなテストパターンはどんなもので、
何種類あるか、といったようなことです。

簡単なマスタメンテナンス画面や、
入力条件が少ない照会画面など、
仕様書を読むことで理解できるものであれば、
最初に計画を立て、テストを行った方が効率的です。

しかし、仕様書を読んでも、
あまりぴんとこないようなプログラムや、
条件が複雑すぎるプログラムもあります。

そんな時、私ならどうやって計画を立てるかを、ご紹介します。
（SEさんに確認をする場合以外で）

私の場合、とにかく、
プログラムを動かしてみることにしています。

DBの更新処理がある場合は、もちろんDBのバックアップを取った上で、
データをいくつか作成してみます。

もちろん、この段階で障害を発見することもありますので、
漫然と操作するのではなく、自分なりに手順を統一します。

たとえば、データのでき方を見たいだけの場合は、
必ずMaxLength以内の文字数で、タブが移動する順番に入力し、
更新ボタンは一回しか押さない、など。

基本的には、いわゆる「普通」の動かし方をします。

次に、作成したデータをDBレイアウトと見比べます。
そうすることで、どのようなデータを登録してみればよいのかがわかります。

このとき、特に仕様書を読んで、
理解しきれなかったところを重点的に動かしてみると、
だんだん、プログラムやデータの特徴がわかってきます。

そうなれば、後はその流れに基づいて、テスト計画を立てるだけです。

テスト計画を立てたら、手順に沿って、テストを行います。

前述しましたが、最初にテスト計画が立ててしまえれば理想的ですが、
テスト計画が立たない、といって悩むよりは、
少しフライング気味でも、自分で画面を操作したり、データを見て、
仕様を理解してしまう方が、時間が短縮できると思います。

自分で動かせば動かすほど、画面の動きやデータも理解できます。
また、その部分が理解できていないと、
結局はテスト漏れにつながってしまいます。

ただし、ここで、
「さっき動かしたからこのパターンはもう良いや」
などと飛ばしてしまうと、テスト漏れにつながってしまうので、
計画を立て終わり、さあテストを始めるぞ！というときには、
最初から、手順に沿って、テストしてください。

テストを始めた後で、パターンが足りないことに気づいたら、
もちろんそれも追加してテストしてください。

二度手間になるかもしれませんが、
単体テストに慣れないうち、
データの作り方や、パターンが作れない、という人は、
試してみてください。