はじめに
これまで開発プロジェクトを経験する中で、チームメンバーのテスト設計・テスト結果のレビューをする機会が多くありました。レビューでは似たような指摘も発生しており、手間に感じている部分もありましたので、まとめてしまいたいと思いました。
当記事ではレビュイーが設計書レビューに向かう前の事前チェック資料、もしくはレビュアーがレビューをするための参考資料となるような一覧整理資料を目指しています。アプリケーション開発する際、品質の向上に繋がれば嬉しく思います。なお、この記事については随時、更新すると思います。
チェック観点
当資料は、単体テスト設計書および結合テスト設計書の両方で利用できる、汎用的な内容を含んでおりますので、各設計書のフォーマット独自に設定された項目については対象外としています。
設計書全般に関するチェック事項
誤字・脱字について全体を見返して確認したこと
変更履歴（設計書ヘッダに記載項がある場合は併せて）に、プロジェクト管理に関する情報の記載漏れがないこと
提供されている記述ルールに従って記述していること
言い切りの形で記述していること（できないこと、しないことを明確にするため）
捉え方が異なる表現方法を使用していないこと（特に、二重否定は使用しない）
5W1Hハッキリと記述していること
設計の際、仕様が不明瞭なものについては、関係者にQAを実施し回答を刈り取っていること
設計の際、関係者にQAを実施し、回答を刈り取ったものについて、証跡を一覧として提示できること
単体テスト設計書について、レビュアに対して詳細設計書との対照箇所を説明できること
結合テスト設計書について、レビュアに対して基本設計書との対照箇所を説明できること
使用する言葉は各シートで統一していること
ペンディングとなっている箇所を明記し一覧化していること
ペンディングとなっている箇所に日付と内容を記載していること
レビュー後に仕様変更が発生している場合、変更管理表に記載されていること
レビュー後に仕様変更が発生している場合、設計書の変更履歴へ管理番号を更新していること（ver.1.00→1.01等）
レビュー後に仕様変更が発生している場合、設計書の変更履歴へ変更内容の概要を記載していること
レビュー後に仕様変更が発生している場合、設計書の変更箇所が分かるように赤字にする、または同行の枠外に「ver.1.01 修正」等の記載をしていること
エビデンス取得時のチェック事項
以下、一般的なエビデンス取得方法として、スクリーンショット（画面打鍵結果、デバッグ結果、テストコード実行結果等）を想定して記載しています。
テスト環境が分かること
テストデータを残していること
テストケースが網羅されていること
テストケースとエビデンスの紐づきを分かりやすくすること（シート名「No.5」、そのシート内で「No.5-1」～「No.5-7」と記載する等）
エビデンスが漏れているテストケースがないこと
エビデンスと補足事項を記述していること
エビデンスで着目すべき箇所が分かりやすいこと（赤枠オブジェクトを貼る 等）
デバッグテストにデバッグコードをプログラム上に記載して実行していないこと
おわりに
単体テスト設計書と結合テスト設計書で分けて書いていたんですが、似たような内容となってしまったので集約しました。受託開発だと設計書を作成する作業はどうしても多いと思うので、参考になれば嬉しいです。