最終更新日：2026年8月28日
fe fe-management system-audit testing
まず結論
システムテストの監査では、テストが要件を十分に確認できる内容になっているか、適切な手続で実施・承認・記録されているかを確認します。
基本情報技術者試験では、次の観点で選択肢を切ると判断しやすくなります。
要求事項を網羅したテストケース
→ 適切
特定の担当者だけで承認・実施
→ 不適切になりやすい
本番環境そのものでテスト
→ 不適切になりやすい
特に、「だけ」「必ず本番環境で」などの極端な表現には注意します。
直感的な説明
監査は、テスト担当者の代わりにテストをすることではありません。
監査では、テストの進め方そのものが適切かを確認します。
例えば、次のような問いで考えると分かりやすいです。
必要な機能を漏れなく試せている？
↓
テストケースの網羅性
勝手にテスト計画を決めていない？
↓
計画・承認
本番システムへ影響しない？
↓
テスト環境
実施結果を後から確認できる？
↓
記録・証跡
つまり、監査の視点は 「適切に計画され、適切に実施され、後から確認できるか」 です。
定義・仕組み
システムテストは、完成したシステム全体が要求事項を満たしているかを確認する工程です。
その監査では、単に「テストを実施した」という事実だけではなく、次のような管理面も確認します。
| 確認項目 | 監査で見るポイント |
|---|---|
| テストケース | 要求事項を十分に網羅しているか |
| テスト計画 | 実施内容・担当・日程・判定基準が明確か |
| 承認 | 適切な責任者による承認があるか |
| テスト環境 | 本番へ不要な影響を与えないよう分離されているか |
| 実施体制 | 特定の一人だけに偏らず、必要な関係者が関与しているか |
| 記録 | 実施結果、不具合、修正、再確認の記録が残っているか |
テストケースの網羅性
監査では、システム要件や要求事項に対して、必要なテストケースが設定されているかを確認します。
要求事項A → テストケースあり
要求事項B → テストケースあり
要求事項C → テストケースなし
この場合、要求事項Cを確認できないため、テストが十分とは言えません。
したがって、要求事項とテストケースを対応付けて漏れを確認することが重要です。
テスト計画と承認
テスト計画は、担当者だけの判断で進めるのではなく、組織のルールに従って適切な責任者のレビューや承認を受けます。
試験では、
利用者側の責任者だけで承認
のように、特定の立場だけに限定する表現は疑います。
テスト環境
システムテストでは、本番業務へ影響しないように、通常は本番環境と分離したテスト環境を利用します。
本番環境
→ 実際の業務に使用
テスト環境
→ 本番への影響を避けて検証
本番と同等の条件を再現することは重要ですが、実際の本番環境でそのままテストすることとは別です。
実施記録と証跡
監査では、後から確認できる記録も重要です。
例えば、
- どのテストケースを実施したか
- 実施結果はどうだったか
- 不具合が見つかったか
- 修正後に再テストしたか
といった記録を残します。
監査では、口頭で「問題ありませんでした」と説明するだけではなく、客観的に確認できる証跡があるかを見ます。
公式の出題範囲やシラバスは、IPA：基本情報技術者試験 から確認できます。
科目Aでどう出る？
科目Aでは、システムテストの監査において適切な確認事項を選ばせる問題が出ます。
まず、次の4点を確認します。
1. 要求事項を網羅しているか
2. 適切な責任者の承認があるか
3. 本番に不要な影響を与えないか
4. 実施結果を記録しているか
選択肢を切る判断基準
| 選択肢の表現 | 判断 |
|---|---|
| 要求事項を網羅したテストケースを設定する | 適切 |
| テスト計画を特定の担当者だけで承認する | 疑う |
| 本番環境そのものでテストする | 疑う |
| 利用者側の担当者だけで実施する | 疑う |
| テスト結果や不具合の記録を残す | 適切 |
特に、次のような表現は注意します。
〜だけで行う
〜だけが承認する
必ず本番環境で行う
監査では、役割分担・承認・独立性・証跡を重視するため、一人や一部門だけに任せる極端な選択肢は不適切になりやすいです。
どんな場面で使う？
システムテストの監査は、開発したシステムを本番稼働へ移す前に、テスト工程が適切に管理されているかを確認するときに役立ちます。
例えば、次のような流れです。
システム要件を確認
↓
テストケースとの対応を確認
↓
テスト計画・承認を確認
↓
実施結果を確認
↓
不具合と修正結果を確認
↓
証跡が残っているか確認
テストの種類そのものを整理したい場合は、ソフトウェアテストの種類とは？単体・結合・システム・負荷・退行を切り分けるも合わせて見ると、「何をテストするか」と「そのテストが適切に管理されているか」の違いがつながります。
よくある誤解・混同
監査人がテストケースを作成する
誤りです。
監査人は、テスト担当者の代わりにテストを設計・実施するのではなく、テスト計画や実施結果が適切かを独立した立場から確認します。
本番に近い環境なら、本番環境でテストする
同じ意味ではありません。
本番に近い条件を再現することは重要ですが、本番業務へ影響しないように本番環境と分離したテスト環境を使うのが基本です。
利用者が参加していれば十分
利用者の参加は重要ですが、利用者側だけで全てを行えばよいわけではありません。
システムテストでは、開発側やテスト担当者など、必要な関係者が役割に応じて関与します。
テストを実施した記録だけあれば十分
実施記録だけでなく、要求事項を網羅したテストケースになっているかも重要です。
たくさんテストした
≠
必要な要求事項を漏れなくテストした
件数ではなく、要件との対応を見るのがポイントです。
まとめ（試験直前用）
- システムテストの監査では、テストが適切に計画・実施・記録されているかを見る
- 最重要は 要求事項を網羅したテストケースになっているか
- テスト計画は適切な責任者によるレビュー・承認を受ける
- 本番環境へ影響しないよう、テスト環境を分離する
- 特定の担当者・部門「だけ」に任せる選択肢は疑う
- テスト結果、不具合、修正、再テストの証跡を残す
- 監査はテストを代行するのではなく、テスト工程の適切性を確認する