テスト実施と不具合管理の業務手順書テンプレート（受託開発・情報システム）
テスト仕様書に沿ってテストを行い、結果を記録し、不具合を起票して修正を確かめるまでの流れです。手順書にすると、結果の記録漏れや、修正の確認をしないまま完了にする事態を防げます。
この手順書の範囲
- 目的
- テストの実施と記録の方法をそろえ、品質を数字で説明できるようにします。
- 範囲
- テスト仕様書のレビュー完了から、テストの完了判定までです。
- 始まるきっかけ
- 結合テスト・総合テストの工程に入ったとき
- 頻度・量の目安
- 工程ごと・テストケース数百〜数千件
- 使う書類・システム
- テスト仕様書、テストデータ、テスト環境、不具合管理表（課題管理表）
担当と役割
テスト担当
テストの実施、結果の記録、不具合の起票
開発担当
不具合の調査と修正
テストリーダー
消化状況の管理、完了判定
手順（11ステップ）
- 準備テストリーダー・目安 1日
1. テスト仕様書のレビュー結果を確かめる
要件・設計の各項目に対応するテストケースがあるかを確かめます。
- 確かめること
- 非機能要件（性能・権限）のテストも入っている。
- できあがるもの
- レビュー済みのテスト仕様書
2. テストデータを用意する
正常系・異常系・境界値のデータを用意します。
- 確かめること
- 本番の個人情報をそのまま使わない。使う場合は加工・承認の手順を通す。
- できあがるもの
- テストデータ
- 準備テストリーダー・目安 30分
3. テスト環境の版を確かめる
テスト対象のプログラムの版、データベースの状態、外部連携の接続先を確かめます。
- 確かめること
- 本番の外部サービスにつながっていない。
- できあがるもの
- 環境確認の記録
4. テストケースを実施する
手順に沿って操作し、期待結果と実際の結果を比べます。
- 確かめること
- 期待結果と少しでも違えば NG とし、自分の判断で OK にしない。
- できあがるもの
- テスト結果
- 記録テスト担当・目安 1件2分
5. 結果と証跡を記録する
実施日、実施者、OK/NG、画面のキャプチャやログを記録します。
- 確かめること
- 証跡のファイル名にテストケース番号を入れる。
- できあがるもの
- 結果と証跡
6. 不具合を起票する
再現手順、期待結果、実際の結果、環境、重要度、証跡を不具合管理表に入れます。
- 確かめること
- 他の人が同じ手順で再現できる書き方になっている。
- できあがるもの
- 不具合票
- 修正開発担当・目安 案件による
7. 不具合の原因を調べて修正する
原因、修正内容、影響範囲を不具合票に書きます。
- 確かめること
- 仕様の解釈の違いが原因なら、PM に回して仕様変更か判定する。
- できあがるもの
- 修正済みのプログラム
- 確認テスト担当・目安 15分
8. 修正を確かめる
起票した手順で再テストし、合わせて影響範囲のテストを行います。
- 確かめること
- 起票者または別のテスト担当が確かめる。修正した開発担当が自分で完了にしない。
- できあがるもの
- 確認済みの不具合票
9. 消化状況と不具合の状況を報告する
予定件数・実施件数・OK/NG件数、重要度別の未解決件数を日次または週次で報告します。
- 確かめること
- 予定に対して遅れている機能を明示する。
- できあがるもの
- テスト状況の報告
- 分析テストリーダー・目安 1時間
10. 不具合の傾向を分析する
機能別・原因別の件数を集計し、不具合が多い機能のテストを追加します。
- 確かめること
- 同じ原因の不具合が続く場合、設計のやり直しを検討する。
- できあがるもの
- 不具合分析の結果
- 判定テストリーダー・目安 1時間
11. テストの完了を判定する
全ケースの実施、重要度の高い不具合が0件、残った不具合の扱いの合意を確かめます。
- 確かめること
- 完了の基準をテスト計画で事前に決めておく。
- できあがるもの
- テスト完了報告書
締めのチェックリスト
- 要件・設計の各項目に対応するテストケースがある
- テストデータに本番の個人情報をそのまま使っていない
- テスト環境の版と接続先を確かめた
- 全ケースに実施日・実施者・結果がある
- NG の結果に不具合票がある
- 不具合票に再現手順と証跡がある
- 修正を別の人が確かめた
- 重要度の高い未解決の不具合が0件
- 残った不具合の扱いを合意した
よくあるミスと防ぎ方
期待結果と違うのに OK にする
「たぶん仕様どおり」と判断して OK にすると、不具合が本番に出ます。迷ったら NG にして、仕様の確認を起票します。
再現手順が書かれていない不具合票
開発担当が再現できず、やり取りが何度も往復します。手順・データ・環境を書く欄を必須にします。
本番の個人情報をテストに使う
テスト環境の管理は本番より甘くなりがちです。加工したデータを使い、本番データを使う場合は承認と削除の記録を残します。
測っておきたい指標
- テストの消化率（予定比）
- 重要度別の未解決不具合の件数
- テスト工程での不具合の検出密度
関係する法令・規格
個人情報保護法
テストに個人情報を使う場合の安全管理措置と、委託を受けたデータの目的外利用の禁止に関わります。
民法（請負）
請負契約では、テスト工程の完了と検収が成果物の完成の判断に関わります。
無料ダウンロード
業務手順書テンプレート集（IT・受託開発・10業務）
- 「テスト実施と不具合管理」を含む10業務の手順書を、1業務1シートで書き換えられるExcel
- 手順ごとに担当・確かめること・できあがるもの・目安時間の列。自社のやり方に合わせて行を足せます
- 締めのチェックリストと改訂履歴のシートつき。A4横で印刷できます
フォームを送信すると、すぐにダウンロードできます
11手順のうち4つは、自動化の候補です
よくある質問
- テストの証跡はどこまで残しますか。
- 合否を後から確かめられる程度に、画面のキャプチャやログを残します。発注者との取り決めがあればそれに従います。
- テストを自動化できますか。
- 回帰テストのように同じ操作を繰り返すテストは自動化に向いています。画面の変更が多いと自動テストが壊れやすいため、壊れにくい仕組みを選びます。
- 不具合の重要度はどう決めますか。
- 業務が止まる・データが壊れるものを高、回避策があるものを中、表示の崩れなどを低とするなど、基準をテスト計画で決めておきます。