ソフトウェア開発部の部ブログにも
月に１度はテストに関する記事が投稿されるようになりました。
皆さんもテストの重要性が身にしみて実感してきていることと思います。

さて、本題に入ります。

明確に統計を取ったわけではありませんが、
プログラマ・テスターが見落とすバグには以下の内容が多様な気がします。

・更新処理
・初期表示時のフォーカス
・更新後の再表示
・連続操作によるバグ
　（クリアミスや再表示、更新処理も含む）
・テスト漏れ

きっとテストを行う時、
『明示的に記載された箇所のテストを行う』事に関しては
しっかり実施されていることでしょう。
残念ながらそれでもバグは発生してしまいます。

そのためにはどうしたらよいでしょうか。
私は、社内の財産である単体テスト報告書（チェックシート）の活用と
本当にしっかり仕様書の内容を確認すれば、
ひとまず単体テストレベルのバグは95%くらいは潰せると思っています。

特に、仕様書の確認がポイントになります。
皆さんはどのように仕様書の確認をしているでしょうか。

[用意するもの：色つきボールペン]
私は、仕様書にボールペンでなんでも書き込みします。
あらゆる情報を書いてしまいます。
できれば色は最低２色使うことをおすすめします。

１色は、単にチェック用にします。
もう１色は重要な箇所やバグが発生した箇所に
目立つように印をつける用にします。
仕様書のどの部分のバグかを一目で分かるようにするのも
有効なテスト時間の使い方の一つです。
仕様書の枚数が多いときにどの箇所のテストだったかな、と
探す時間と手間が大変もったいないです。

[テスト方法の例：デシジョンテーブル]
例えば、条件が複数ある場合には
全てのパターンを仕様書に書き出してしまいます。
『デシジョン・テーブル』という方法を使うことをおすすめします。
複数の条件を組み合わせをマトリクスで表現した表にして、予想される結果を書きます。

その考えた全てのパターンのデータを実際に流してみて
結果も○×で残しておきます。
（もちろんここで画面のハードコピーやデータのバックアップもとっておきます）

こうしておけば、後で再度テストしたい場合にどのようなパターンをテストしたかを
容易に確認し、テスト漏れも減少させる事ができるでしょう。

『テストって一体どこまで行えばよいか』
もしかすると永久に追求し続けなければならない事かもしれません。
でも、そう言って悩んでもテストは必ずやらなければなりません。
期限はどんどん迫ってきます。
手を動かさなくてはバグを見つけることはできないのです。
効率よくテストして強いシステム作りをしていきたいですね。