本記事では「単体テスト仕様書」についてご紹介します。
「単体テスト仕様書の書き方・作り方を知りたい」「仕様書の自動化・テンプレート化を検討したい」という方はぜひご一読を。高品質な単体テスト実行に繋げていただければ幸いです。
単体テスト仕様書の目的
単体テスト仕様書の目的とは、
- 単体テストの業務効率化し、有意義にする
- テスト手順の記載により新人を含め、誰が担当しても正しくテストを実施できるようにする
- 第三者視点によるレビュー獲得により、網羅性のチェックを可能にする
- テスト項目の明確化により、テスト作業のゴールを明確に設定可能にする
というものです。
単体テスト仕様書は、実行に際して活用するドキュメントです。
テスト対象・観点、条件などを予め明確化した内容を基に作業を進めます。
単体テストでは、システムにおける最小単位ユニットをテスト対象とし、個々の機能が正常に動作しているかを確認します。
主に、開発工程におけるプログラミング後のフェーズにて実施されます。
単体テストが不十分になると、「的確な修正対応ができない」などのリスクが高まります。
また、単体テストは個々の機能を対象とするため実施回数の多い工程です。
テストに慣れていない新人が担当する場合も多々あります。
以上の点から、単体テストをいかに効率的に十分行えるかが、「テスト仕様書にかかっている」
と言っても過言ではありません。
単体テスト仕様書の書き方のサンプル
テスト仕様書・計画書作成の方法やガイドをまとめた資料はこちら。 巻末に項目のサンプルも用意しています。
単体テスト仕様書に最低限必要な項目は、以下の通りです。
仕様書作成を担う際は、以下を必ず記載しましょう。
単体テスト仕様書に最低限必要な項目
- 開発プロジェクトのタイトル
- システム・ソフトウェアの名前
- 仕様書のタイトル
- テスト対象となる機能・プログラム
- 仕様書の作成日・作成担当者
- 仕様書の更新・改訂日、更新担当者
- テスト項目
- 検証内容
- 確認する項目
- 期待値・想定結果
- 実施手順
- 確認結果（想定結果の合否）
- テスト結果を確認した日
- テスト実行担当者名
単体テスト仕様書の作り方
単体テスト仕様書作成の手順は、以下の通りです。
単体テスト仕様書作成の流れ
- テストすべき機能・動作を洗い出す
- 機能や動作ごとにテスト観点を設定する
- テストケースを設定する（テスト方法を明確にする）
- 条件パターンを網羅する
今回は、「単体テスト仕様書作成の手順」を上記４つのステップに分けてご紹介します。
1：テストすべき機能・動作を洗い出す
単体テスト仕様書を作る際にはまず「要件定義書」を基に、抜け漏れなく洗い出しを行います。
洗い出す機能や動作の具体例は以下の通りです。
例：とあるサービスの個人情報登録画面に単体テストを行う場合
| 単体テストの対象 | 機能（または動作） |
|---|---|
| 個人情報登録画面のプログラム | 初期画面の表示（メニューボタン押下時） |
| 入力チェック(○○ボタン押下時) | |
| 画面移行(完了ボタン押下時) | |
| 終了画面(終了ボタン押下時) |
このステップでの注意点
- 記載する項目に抜け漏れがないかを確認
- 誰が担当しても問題がないよう、曖昧な記載・表現は避ける
- 単体テストの対象、テストすべき機能・動作を明確化
2：機能や動作ごとにテスト観点を設定する
つぎは、「機能・動作ごとにテスト観点を設定」します。
テスト観点とは「機能・動作を検証するための切り口」を指します。
単体テスト及び仕様書の質を向上するためには、「適切なテスト観点の網羅」が大切です。
以上をふまえ、今回は「テスト観点の具体例」をご紹介します。
とあるサービスの個人情報登録画面に単体テストを行う場合
テスト観点の例：「入力チェック」機能に関するもの
| 単体テストの対象 | 機能(または動作) | テスト観点 |
|---|---|---|
| 個人情報登録画面の プログラム |
初期画面の表示 |
|
| 入力チェック |
|
|
| 画面移行 |
|
|
| 終了画面 |
|
このステップでの注意点
- テスト観点を明確に記載し、曖昧な表現は避ける
3：テストケースを設定する（テスト方法を明確にする）
つづいて、「テストケースの設定」します。
テストケースを設定する際には「実際のテスト実行で用いる方法を明確化」します。
このフェーズでは主に、単体テストの手順や得られる結果の成否や判断基準について、誰がテストを担当しても同結果が出るテストケースを設定することが重要になります。
そこで今回は「テストケースとして考えられる例」をご紹介します。
とあるサービスの個人情報登録画面に単体テストを行う場合
テストケースの例：「入力チェック」機能にて「空白の場合の動作を確認する」場合
- 入力内容の不備、空白を知らせるアラート文が、誤字脱字なく表示されるかを確認
- 表示されたメッセージに文字化け・文字切れがないかを確認 など
代表的なテスト方法
- ホワイトボックステスト
条件網羅：
対象プログラムに含まれる「条件分岐」に着目するテスト方法。
個々の条件が真・偽になる場合を最低1回は含む。
命令網羅：
網羅的に全条件の処理を最低1回は通すテスト方法。
分岐網羅：
主に「分岐先」に着目し、あるテスト条件を全て最低1回は通すテスト方法。
複数条件網羅：
テスト条件の分岐に対し、全ての組み合わせを網羅的にテストする方法。
- ブラックボックステスト
境界値テスト：
出力が同様になる入力を各グループに分け、グループが隣接する境界や前後の値をテストする方法。
同値テスト：
出力が同様になる入力を各グループに分け、グループの中から代表値を選択しテストする方法。
異常値テスト：
想定外の負荷を意図的にかけることで、それらに対処することが可能かをテストする方法。
また、この時にはどのような方法でテストを行うのかを明確にしておくことが望ましいです。
このステップでの注意点
- 単体テストは作業完了の定義が明確でないため、実施するテスト数のバランスを考慮
- 不具合・修正などの履歴を管理できるよう、テストケース設定の段階で整備
4：条件パターンを網羅する
このあと、「条件パターンを網羅」します。
単体テスト＝個々の機能（モジュール）を対して検証を行うため、
テスト条件の網羅性が問われます。
では、どうすれば漏れなく条件パターンを網羅できるのでしょうか？
そこで今回は、「デシジョンテーブル作成」の具体例をご紹介します。
デシジョンテーブル作成例
レストラン予約サービスの情報登録画面に単体テストを行うとする。
テストケース：「入力チェック」機能にて、空白の場合の動作を確認する場合
条件パターンの例：入力する項目
「食事の予約（朝食・昼食・夕食の3パターン）」と
「人数（2人席～８人席の７パターン）」だとする。
尚、これらが各組み合わせにより結果が変わる場合、
・・・３×７＝２１パターン分全てのテストケースを用意する必要があります。
このステップでの注意点
- 全てのテスト条件を網羅できているかを確認
- イレギュラーな挙動・その対処法も考慮しておく
- 担当者によって認識のズレが生じないように各条件は、明確にわかりやすく記載
単体テストの仕様書を作成するときのポイント
「単体テスト仕様書のポイント」をご紹介します。
単体テスト仕様書作成の注意点
- テスト観点が漏れないようにする
- テスト観点を明確にわかりやすくする
単体テストは仕様書の記載事項を基に進められるため、これらの注意点は最低限おさえておきましょう。
では、具体的にどのような方法をとることが望ましいのでしょうか？
ここからは、上記それぞれについて解説します。
テスト観点が漏れないようにする
単体テスト仕様書作成においては、「テスト観点の洗い出し」も重要になります。
なぜならば、テスト観点の漏れは不具合・トラブルの残存による品質低下に繋がるからです。
テスト観点抜け漏れを防ぐ方法
- デシジョンテーブルの活用
- 要件定義書の作成担当（顧客側）や関係者などの第三者視点によるレビュー など
テスト仕様書は、テスト作業及びシステムそのものの品質を左右する重要な文書です。
そのため、記載項目に漏れがないよう、できるだけ多角的な視点を用いた上で
「網羅性の高い単体テスト」を設計・実行していきましょう。
テスト観点を明確にわかりやすくする
単体テスト仕様書の作成者とテスターが異なる場合には特に、「仕様書の明確さ」が重要です。
テスト観点を明確にするには？
- テスト観点をわかりやすく記載
- 各テスト観点に注釈をつけ、曖昧な表現は避けて記載
- 第三者によるレビュー
【記入例】
- OK例)空白の場合○○というメッセージが表示されるか確認
- NG例)空白の場合の動作を確認（←何が正解かわからないので改善が必要）
単体テスト仕様書作成を効率的におこなう方法
最後に、「単体テスト仕様書を効率的に作る方法」をご紹介します。
単体テストだけでなく、ソフトウェアテスト工程は効率性が重視されます。
単体テストの仕様書作成を効率的に行う方法
- 仕様書をテンプレート化
- 以前行った開発工程を参考にする
- Excel作業の煩雑化を改善するツール導入 など
仕様書をテンプレート化する
単体テストでは、仕様書・レビューの作成工数が比較的多くなるため、
テンプレート化によりスキル依存を回避し、時間的コストを削減できます。
また、テンプレートを使う際には、あらかじめメンテナンスコストを考慮し、
プロジェクトの規模・特性に応じた業務効率化を心掛けましょう。
テクバンの「ソフトウェアテストサービス」とは？
テクバンでは、上記を含めた「ソフトウェアテストサービス」をご提供しております。
「仕様書作成のノウハウ・人的リソースが不足している」といった企業様は
ぜひ一度、当社コンサルタントにご相談ください。
テクバンの「ソフトウェアテスト」とは？
- 専門チームがテスト業務を内部監査
- プロジェクト立ち上げ～品質改善コンサルまで対応
- 徹底したヒアリングで品質業務の最適化
当社在籍のテストエンジニアがお客様のご要望や、システム・ソフトウェアの特性などをヒアリングした上で、効果的なテスト設計～実行までを全面サポートさせていただきます。
詳しくは、こちらのリンクをご覧ください。
まとめ
最後までお読みいただき、ありがとうございました。
今回は「単体テストの仕様書」に注目し、目的・書き方をサンプル付きで深掘りしつつ、作成時の注意点・効率的な方法についてご紹介しました。
今回ご紹介したポイントをおさえ、正しい手順で誰が担当しても同結果に到達できるよう、「網羅性・効率性の高い単体テストの設計・実行」に繋げていただければ幸いです。
