1．概要
前回IEEE829のテストドキュメントを用いて、テスト計画書について説明いたしました。今回はテスト設計書について説明いたします。
ただ、IEEE829のテスト設計書は内容が薄いため、今回私の経験をもとに補足させていただきます。
2．IEEE829のテスト設計書とは？
テスト計画書と同じくテスト設計書もレベル別のドキュメントがあります。（単体テスト設計書、結合テスト設計書など）。
ただ、レベル別に作ることもありますが、テスト手法ごと（組み合わせテスト、性能テスト、セキュリティテストなど）に作成することもあります。
3．テスト設計書の考え方
テスト設計書はテストの最重要ドキュメントにあたり、「どのようにして」テストを行うのか決める工程でもあります。ここの良し悪しがその後にテストに大きく影響を与えるので、テスト担当者の腕の見せ所にもなります。
この工程で抜けや漏れが発生した場合、当然テストの抜け漏れにもつながるので、慎重に作成しなければなりません。
しかしながら、「どのようにして」テストをするかは以下の要因などに大きく左右されるので、フォーマット化が非常に難しいドキュメントでもあります。
※人によっても「どのようにして」テストするかは、だいぶ変わってきます…
- テストの実施期間 ⇒期間が短いとできるテスト・できないテストが出てくる
- テスト担当者のスキル ⇒スキルが低いと抜け漏れが発生しやすい
- 仕様などのドキュメントの有無 ⇒仕様はコードです！は読み解くにのに時間がかかる
そのため、IEEE829のテスト設計書では、重要であるにも関わらず記載する項目がテスト計画書と比べても非常に少なくなっています。以下にIEEE829のテスト設計書の2章部分を記載します。
2 レベルテスト設計詳細
2.1. テスト対象機能
2.2. アプローチの具体化 ←ここが重要だか「具体化」の一言しかない…
2.3. テスト識別子
2.4. 合否基準
2.5 テスト成果物
そのため、実際の具体化の方法については、私の経験をもとに解説いたします。
4．テスト設計書の作成方法
実際の現場では「どのようにして」テストを行うか決めているかというと、何かの参考書を見ながら決めていることが多いです。
例えば、
- ISO25010の品質特性（機能性、信頼性、使用性…）
- 過去に実施したテストドキュメント
- テスト技法の一覧表（組み合わせテスト、セキュリティテスト、性能テストなど）
- 具体的なテストケース一覧表（入力項目に「ああ」「*!"」「？」と入れる、など）
しかしながら上記は以下のようなメリット・デメリットがあるので、状況に応じて使い分けたり、組わせていることが多いです。
| 参考にする資料 | メリット | デメリット |
|---|---|---|
| ISO25010の品質特性 | テスト対象を広く浅くどのようにテストするのか考えることができる | 品質特性は抽象的であるため、具体的なテストケースに落とし込むのにかなりの技量がいる |
| 過去に実施したテストドキュメント | ものによってはそのまま流用できる | 新規開発では役に立たないことが多い |
| テスト技法の一覧表 | ISO25010より具体的なので、テストケースを作りやすい | セキュリティテストなどの特殊なテストを具体的にするのに技量がいる |
| 具体的なテストケース一覧表 | 項目が具体化してあるので、テストケースの作成が容易 | 一覧表が膨大になりやすく、目的のケースを見つけるのに時間がかかる |
5．まとめ
テスト設計書は「どのような」テストを実施するのか決めるドキュメントであるため、ここの作成がテスト担当者の腕の見せ所となります。
ただ、テスト担当者によって「どのように」テストをするのか考え方が違うことが多く、具体的なテスト設計書のフォーマットは作成されないことが多いです。（自由に記載していい「フリーフォーマット」だらけのドキュメントが多い）