テスト計画書サンプル

架空のプロジェクト「スポーツなどの勝敗予想サイト構築」のテスト計画書を書きました。

本書について

本書は「勝敗予想サイト」の開発のテスト計画である。ステークホルダーが共通の認識に立ち計画を遂行できるよう、テスト関連の必要事項を明確化することを目的とする。

テスト目的

勝敗予想サイトの利用者が使うフロント、管理者が使う管理ツールがテスト対象となる。

リリース直後のアクセスや会員数は少ないと見ており、アクセス数やデータ数を監視しつつ増加傾向が顕著になったらスケールアウトなどを考える。

そのため、性能テストや負荷テストは不要だが、監視は必要。

セキュリティにおいても個人情報を取得しない方針であり、コストはかけない。

本プロジェクトはアジャイルで進めるため「工程」という概念を持たない。

品質特性

テスト対象／対象外

以下にテスト実施における対象／対象外を示す。
対象外とは、システム上の連携は行うがデータの妥当性および挙動の責任を負わず、テスト実施を行わないものを言う。

テスト対象

・フロント

・管理ツール

テスト対象外

・SNS OAuth（外部システム）

対象OS・ブラウザ

テスト方針

テスト環境

新規開発なのでステージング環境をそのまま本番環境とする。

ステージング環境と本番（プロダクト）環境の分離は予算の都合上、リリース後に対応する。

スケジュール

アジャイル（イテレーション）単位でテストするためにテストスケジュールは開発スケジュールと同様

テスト体制

基準と予測

バグ管理

バグ種別

・要件考慮漏れ

・設計考慮漏れ

・実装漏れ（実装者認識齟齬、単なるプログラミングミスも含む）

・仕様変更（対応漏れ含む）

・デグレート

・環境（環境設定誤りなど）

・外部システム要因（インターフェース仕様相違も含む）

・OS/端末/ブラウザ依存

チケット起票ルール

● 前提

・1バグ：1チケット

・バグと疑われるものはチケット化（テスト仕様書不備・設計書不備などは後で分類）

・チケット管理はRedmineを使う

・優先度は「高め」「通常」「低め」を使い、「急いで」「今すぐ」は緊急事態のみに利用

● タイトル

画面ID 事象の概要

● 本文

下記を簡潔に記載すること

・前提条件

権限や前画面など前提条件を記載

・期待値

仕様書に記載している期待値を記載

・事象

テスターの疑問点など忌憚なく書く

・テスト仕様書

ファイル名、シート名、行数を記載します

・エビデンス

動画エビデンスが望ましい（尺は短めに）

複雑な事象でなければ静止画像でもOK

・バグ種別

バグ種別を参照

● 優先度

・「重要度」と「緊急度」に分けて考え、優先度は3段階とする

・「高め」「通常」「低め」を使い、「急いで」「今すぐ」は極力使わない

・「重要度」と「緊急度」が高いは「高め」

　このバグがあるとテストが進まない

　利用者が不利益を被る可能性が高い

・「重要度」が高く、「緊急度」が低い場合か、「重要度」が低く、「緊急度」が高い場合は「通常」。緊急度は「期日」で表現する

　バグだが代替手段がある

　利便性が下がるがシステムは使える

・「重要度」と「緊急度」が低いのは「低め」

　誤字・脱字程度

　バグが起きても影響が極めて少ない。

● 期日

必ず入れる。悩んだら下記とする。テストマネジメントは開発側と相談し期日を調整する

・優先度が「高め」：翌営業日

・優先度が「通常」：1週間後

・優先度が「低め」：テスト終了日

● 担当者

起票時は無条件にテストマネジメントとする

● バグチケットステータス

1. テスターがチケットを起票

2. テストマネジメントが仕分け・分類

　1. バグかテスト仕様書・設計書不備かを仕分け

　2. 優先度と期日を調整し優先順位を確定

　3. バグを画面単位、機能単位、類似性、同じソースコードファイルで分類

3. 開発側に渡す（担当者を開発チームに変更）

4. 開発側が修正し、マージリクエスト承認時にユニットテストを回す

5. 動作確認

　1. 開発初期であればユニットテストのみで良い

　2. 開発後期（結合テストや総合テスト）であればテストチームが動作確認

6. チケットクローズ

7. 定期的に棚卸し

テスト仕様書結果

総合テスト 判定基準

出荷判定基準

・ユニットテストカバレッジ 85%

・ユニットテストオールグリーン（APIテスト含む）

・UIテストオールグリーン

・テストケース数が予測の±20%

　テストケースが多い場合はスケジュールとコストを考慮し妥当性があればよしとする

　テストケースが少ない場合はNG

・バグ数が予測の±20%

　バグ数が少ない場合はユニットテストなどの施策の妥当性を検証

　バグ数が多い場合は探索テストなどの施策を打つ

・テストケースを全て消化

　テストケースNTがあってもいいが、理由を明確にする

・バグチケット

　優先度「高め」はゼロ

　優先度「通常」「低め」は20チケット以下

　チケット単位で終了予定が明確であること

・バグ収束曲線が妥当であること

・リスク対策をしていること

・リリース前に優先度「高」のバグが発生した場合は総合テストやり直し

総合テスト開始条件

ユニットテストカバレッジ 85%

ユニットテストオールグリーン（APIテスト含む）

UIテストオールグリーン

テストケース数が予測の±20%

　テストケースが多い場合はスケジュールとコストを考慮し妥当性があればよしとする

　テストケースが少ない場合はNG

これまでのバグ数が予測の±20%

　バグ数が少ない場合はユニットテストなどの施策の妥当性を検証

　バグ数が多い場合は探索テストなどの施策を打つ

　残バグが5営業日以内に収束すること

これまでの課題とテストできていない項目の対策が明確化されていること

これまで検出したバグの修正と確認が完了していること

総合テスト実施環境（テストデータ・機能改修など）の準備が完了していること

　※五月雨で実施を進める場合は優先順位と準備のスケジュールが決まっていること

中断条件（協議条件）

協議の結果、テスト進行不全となった場合はテストを中止し、バグ修正に集中する。

・総合テストの予測バグ数の半分を超えた場合に関係者で対策協議

・1日あたりのテストケース数消化が半分以下が3日続いた

・ブロッキングバグが多発しテストの実施が行えない

・大幅な仕様変更がありテストの実施が行えない

再開条件

・バグチケットを全て消化

・テスト準備が整っている

・総合テストは初めからやり直し

リスク

チケット管理する