単体テスト仕様書を作るとき、テストケースをたくさん書けばよいというわけではありません。
私が実務で困ったのは、前提条件が書かれていないことと、テスト項目の粒度が粗いことでした。
前提条件が分からなければ、どの状態からテストを始めればよいのか判断しにくくなります。
また、1つのテスト項目に複数の操作や確認内容が含まれていると、どこまでを1つのテストとして扱えばよいのか分かりにくくなります。
そのため、私が単体テスト仕様書を作るときは、
- 前提条件がない場合でも「なし」と明記する
- テスト項目は「1動作1項目」を意識する
という点を特に意識していました。
この記事では、単体テスト仕様書について、私が実務で困ったことと、その経験から意識していた書き方を紹介します。
なお、単体テスト仕様書の形式や項目は、会社やプロジェクトによって異なります。ここで紹介するのは、私が業務システム開発で経験した範囲の内容です。
単体テスト仕様書とは
単体テストは、作成したプログラムが設計どおりに動作するかを、プログラム単位で確認する工程です。
そのときに、
- 何をテストするのか
- どのような条件で実施するのか
- どのような操作をするのか
- どのような結果になればよいのか
といった内容を整理するために使うのが、単体テスト仕様書です。
大阪市の「情報システム開発ガイドライン」でも、単体テストはプログラム（モジュール）の品質を確認する工程として位置付けられています。
また、「単体テスト仕様書作成」の項目では、正常系・異常系・境界値などのテスト観点を踏まえてテスト項目を洗い出し、テスト対象やテスト内容などを単体テスト仕様書へ整理する例が示されています。
ただし、単体テスト仕様書にどこまで書くか、どのような形式にするかは、開発現場によって異なります。
私が特に重要だと感じていたのは、その仕様書を読んだ人が、迷わずテストを実施できるかという点でした。
前提条件が書かれていないとテストを始めにくい
単体テストでは、テストを始める前の状態が結果に影響することがあります。
ところが、仕様書に前提条件が書かれていないと、
「この状態から始めればよいのか」
という部分を実施する側で判断しなければならなくなります。
私が扱った単体テスト仕様書でも、前提条件が十分に書かれておらず、テストを実施するときに困ることがありました。
テスト内容そのものが書かれていても、開始時点の状態が曖昧では、同じ条件でテストを実施できるとは限りません。
そのため、単体テスト仕様書では、操作手順や期待結果だけではなく、テストを開始するために必要な状態も分かるようにしておくことが重要だと感じています。
前提条件がない場合も「なし」と書いていた
前提条件について、私が意識していたのが、
前提条件がない場合でも、空欄にせず「なし」と書く
ことです。
空欄になっていると、
- 前提条件が本当にないのか
- 単に書き忘れているのか
を、仕様書を読む側では判断できません。
一方、「なし」と明記されていれば、少なくとも記載漏れではなく、前提条件が設定されていないことが分かります。
非常に小さな違いですが、テスト仕様書を別の人が読むことを考えると、このような曖昧さを減らすことは重要です。
これは私が実務で意識していた方法であり、すべての現場で同じルールというわけではありません。
私は、前提条件が存在しない場合にも「なし」と書くようにしていました。
テスト項目は「1動作1項目」を意識していた
もう一つ意識していたのが、1動作1項目です。
テスト仕様書を作るとき、1つの項目の中に多くの操作をまとめれば、項目数自体は少なくできます。
ただ、項目の粒度が粗くなると、テストを実施するときに分かりにくくなります。
そのため私は、1つのテスト項目に多くの動作を詰め込むのではなく、1つの動作を1つの項目として整理することを意識していました。
これは、すべてのプロジェクトで「必ず1動作1項目にすべき」という意味ではありません。
テスト仕様書の作り方は現場によって異なります。
あくまで私が実務でテスト仕様書を作る中で、分かりやすくするために意識していた方法です。
テスト項目の粒度が粗いと何が困るのか
テスト項目の粒度が粗いと、1つの項目の中で確認する内容が増えていきます。
すると、
- どの操作まで実施したのか
- どの部分で想定と違う結果になったのか
- 何を確認した項目なのか
が分かりにくくなる場合があります。
私自身、粒度の粗いテスト仕様書では実施しづらさを感じていました。
そのため、「1項目で何を確認するのか」が分かるように項目を分けることを意識していました。
テスト項目を細かくすればよいという単純な話ではありませんが、1項目に複数の目的を持たせすぎないことは、実施する人にとって分かりやすい仕様書につながります。
単体テスト仕様書では実施する人が迷わないことを意識する
単体テスト仕様書には、さまざまな書き方があります。
正常系や異常系、境界値など、どのようなテストを用意するかも重要です。
ただ、実際にテストを実施するためには、
何をテストするのか。
どの状態から始めるのか。
何を操作するのか。
どうなれば正しいのか。
が分かる必要があります。
内容が正しくても、実施する人が仕様書を読んで迷ってしまえば、確認や判断が必要になります。
まとめ：前提条件と粒度を曖昧にしない
私が単体テスト仕様書を使う中で特に困ったのは、前提条件が書かれていないことと、テスト項目の粒度が粗いことでした。
その経験から、単体テスト仕様書を作るときは、
- 前提条件がない場合も「なし」と明記する
- 1動作1項目を意識する
という点を大切にしていました。
もちろん、単体テスト仕様書の形式やテスト項目の分け方は、会社やプロジェクトによって異なります。
それでも、仕様書を作成した本人だけではなく、別の人が読んでも、どの条件で何を実施すればよいのか分かる状態にすることは重要です。
単体テスト仕様書を書くときは、項目数だけではなく、実際にその仕様書を使ってテストする人が迷わないかという視点も持っておくとよいと思います。
