テスト実施の時点で泣かないように

はじめに

テストしてもしてもバグがなくならないし、どんどんテストケース（パターン）が際限なく増えて終わらないし、あれこれ言われて挙句の果てに全部テストしてとか言われて破綻するようなことありませんか？

僕はありますｗｗ

そんな困ったときには、テストの種類をまとめて条件を書いてみると自分の考えも整理ができて本当にテストが必要なのか判断しやすくて、「全部」テストしなくてもいいじゃないのってわかってきます。

テストを楽にするというか、イライラせず安心してテストをするヒントとなればと思いました。

テスト設計

仕様書が確定するまでテストができないと思っていませんか？
テストは要求や仕様を決める段階からでも始めれるものです。

例えばテキストファイルを読み込んで保存ができる Windows標準の某テキストエディタのようなものを作るっていうとき。

まずは「テキストファイルを読み込む」ってことが必要ですよね？
読み込む文字コードに限って考えるのであれば、簡単にですが以下のように分割していけます。

読みこめる文字コード	化ける文字コード
UTF-8	EUC
UTF-16（BE,LE）	そのほか色々
Shift-JIS（MS932）

正常に動作するものを「有効同値」、（エラーになったり）動作しないものを「無効同値」とか言って「同値分割」というテスト技法のひとつです。

これぐらいであれば、完全な仕様書や動作するものがなくてもできると思います。
（実際には、もっといろんな条件があったり組み合わせがあったりしますが）

実施するテストの選定

さてさて、「有効同値」、「無効同値」をあげてテスト設計を進めていくのですが、「全文字コードの確認したの？」って言われる時がありますが。。。

素直に全部やるのか（考えるのか）というと『やらない』です。

「全部やれ」ということになった時には、逆に「読みこめる文字コード」以外はちゃんとエラー処理をしているのかを聞いてみましょう。
（というか、エラー処理入れろやゴルァ！って言いますけど）

テスト設計すると、動作してほしい／してほしくないところが限定されてくると思いますので、実際に動作するものが出来上がるまで待たなくてもできる作業なのです。

なので、開発している最中に「できること」、「できないこと」を分けて考え開発チームにフィードバックしておくと、あとあとテストが楽になってきますよ

おわりに

そのほか、境界値分析や組み合わせなど、様々なテスト技法があるので、それらも駆使してテストする範囲や条件を限定していくことができます。

「全部テストをして」とか「バグ全部発見して」とかいう無茶なことを言われて、あまり意味のないテストに時間がとられて、結局バグがとれず最終的に、これテストしたの？って言われないように、効率よく的を射たテストができますように。