テスト仕様書の書き方のまとめ
（なぜ、そんなのを書くのかは聞かないでくれ。書きたくなったからだ）
＜＜何を書くべきか（目的）＞＞
テスト仕様書の目的は、テストをしてもらうために書くことという意味はもちろんあるのだけれど、そんなことより
・後で見たとき、テストが網羅されていることがわかること（他人が確認できること）
・その仕様書に書かれているテストの目的と、そのためのテストの操作の妥当性が、ほかの人が見ても（コンピューターのことを知らない弁護士や裁判官、国の仕事なら会計検査院の人が見ても）確認できること
が必要になる。これがないと、品質がわからないので、プログラムを作りっぱなしと同様と、ユーザーやシステム監査人、裁判官に判断されても、また、「会計検査院が、予算を適正に使っているかどうか、確認できないって言われちゃうジャン！」と、こっぱ役人にいわれても、「反証ができない」。
後者の、だれからみても、確認できるということから、
・一通りにしか解釈できない操作手順
前者の網羅性から
・なにを調べているか、その調査項目と確認方法、確認ポイント
が明確になっていないといけないことになる。
＜＜何を書くか（項目）＞＞
したがって、ふつう、試験仕様書には、
・調査項目（大分類、中分類、小分類と別れている場合がある）
・確認方法（目視、ログ、ほかエビデンスの指示）
・確認箇所と、どうなっていればいいかということ
・操作方法
が、最低限書かれる。
ただし、テスト仕様書が１枚のシートになっていればいいが、そうでなく、テスト項目の台帳みたいな形式に書く場合がある。その場合、操作方法が書ききれない。
また、手作業で書いていたんでは、実際、終わらない。そこで、テスト仕様書の自動化をするわけなんだけど、その話のまえに、調査項目について
＜＜調査項目＞＞
調査項目をみて、テストが網羅されていることがわかるようにかくということと、
調査項目と、確認内容がつながっている必要性がある。
調査項目は、仕様書が、大項目、中項目、小項目のように別れている場合、タイトルですべてを表さないといけない場合、文章中に書く場合、さまざまな形式がある。
ここでは、大項目、中項目、小項目のように別れている場合についてふれる。ほかの形式の場合には、これらから、適当に言葉をとって、つなげてくれ。
テスト項目は、大きく、以下のように分かれる
■■ ホワイトボックステストの場合
（あ）どのモジュールの（プログラムＡのメソッドＢの、３番目のＩＦ文の結果）
（い）どこの部分を、（変数Ａが）
（う）どういうふうになっているかテスト（値が正しく入っている＝正常系の値チェック）
■■ ブラックボックステストの場合
（あ）どこの部分（帳票・画面）の （発注画面の）
（い）どの項目の（商品名の）
（う）何チェックか（桁数チェック）
■■ シナリオや、契約に基づくテスト
（あ）どのシナリオの（シナリオＮｏ３２１）
（い）何の部分が（発注金額が）
（う）どうなっていればいいの（大きすぎると入力できない）
そして、この調査項目の結果から、正常系と異常系にわかれる。
これの組み立て方に関しては、以前、マトリックスをかく方法で、このブログのどこかにかいておいた。
（あ）が大項目、（い）が、中項目、（う）が小項目になる
＜＜網羅性について＞＞
ブラックボックスについては、たいてい、ログでしらべる。
なので、必要な値について、全部のケースをしらべているかどうか、ログの箇所と、ソースを見比べて、かくにんできる。
ホワイトボックステストに関しては、全項目について、必要なテストをしているかどうかが確認できればよい。なので、（い）が、すべての項目がでているかどうか、（う（について、項目が（い）のとき、考えられるテストを全部しているかを確認することになる。
＜＜確認内容とのつながり＞＞
これは説明するまでもなく、（い）の項目の（う）をしらべているので、それが、そうなっているかどうかを調べる旨を、書いておけばよい。この記述がないと、調べるポイントが散漫になる（ために書いてる人もいるけど）だけでなく、せっかく網羅性があっても、網羅してるかどうかわからない。
で、操作方法（一通りにしか読めない操作方法）の書き方と、手抜きの仕方、テスト仕様書の自動生成、については、またこんど。
PS：２０１５年１０月２８日
１０年くらい経って、古くなったので、この記事をアップデートした内容を書いています。
テスト仕様書の書き方というか、手抜きのしかたというか。。（2015 Update）
http://blog.goo.ne.jp/xmldtp/e/1156bb825857eea0e5ccc28683602e4c
です。
アクセス
トータル
ランキング
