システムテストの基本｜観点・エビデンス・品質改善

「テストケースはすべて実施したが、本当に十分なのか分からない」

「エビデンスを残したのに、レビューで結果が分からないと言われた」

システム開発におけるテストは、決められたケースを消化する作業ではありません。変更によってどのような問題が起こり得るかを考え、期待どおりに動くことと、問題が起きないことを確認する仕事です。

テスト件数が多くても、重要な観点が抜けていれば不具合を見逃します。また、正しくテストしていても、条件と結果が分からないエビデンスでは、第三者が合否を判断できません。

私も銀行システムの開発・保守に25年以上携わるなかで、テストの品質が本番の安定性を大きく左右することを実感してきました。テストで見つかった不具合は、単に修正して閉じるのではなく、設計やレビュー、開発手順を改善する材料にもなります。

この記事では、システムテストの基本を次の3つに分けて解説します。

1. リスクからテスト観点を組み立てる
2. 条件・操作・結果が分かるエビデンスを残す
3. 不具合とテスト結果を品質改善へつなげる

テストで大切なのは「何を保証したいか」を明確にすること

テストを始める前に、対象機能、変更内容、想定利用者、失敗した場合の影響を確認します。そのうえで、「このテストで何を確認し、どのリスクを減らすのか」を言葉にします。

確認対象	問いかけ	例
正常動作	期待した条件で正しく完了するか	入力内容が正しく登録される
異常動作	誤った条件を安全に拒否するか	入力エラーを表示し更新しない
境界	上限・下限の前後で正しく動くか	桁数の最大値と超過値
連携	前後の機能や外部システムとつながるか	後続バッチが対象データを取得する
非機能	性能、権限、障害時動作は適切か	権限外操作を拒否しログを残す

すべての観点を同じ深さでテストする必要はありません。影響が大きい処理、変更量が多い箇所、過去に不具合が多い箇所へ重点を置きます。

1．リスクからテスト観点を組み立てる

テスト観点は、仕様書の項目をそのままケースへ変換するだけでは不足することがあります。変更内容から起こり得る失敗を考え、利用者、データ、処理、環境の切り口で広げます。

正常系・異常系・境界値をそろえる

• 正常系：代表的な入力で処理が完了する
• 異常系：必須不足、形式不正、業務条件違反を適切に扱う
• 境界値：最小値、最大値、その前後を確認する
• 状態遷移：実行前後のステータスと再実行時の動作を確認する

たとえば入力桁数が10桁の場合、1桁、9桁、10桁、11桁、未入力を候補にします。ただし、すべてを機械的に増やすのではなく、仕様とリスクに合わせて選びます。

変更箇所の周辺と後続処理を見る

プログラムの一部を変更しても、共通部品、同じテーブルを使う機能、後続バッチ、外部連携へ影響する可能性があります。影響調査の結果をテスト観点へ反映します。

変更	追加で考える観点
画面項目追加	入力チェック、登録値、再表示、帳票、権限
SQL変更	0件・1件・複数件、NULL、重複、性能
API変更	正常応答、エラー応答、タイムアウト、再送、互換性
バッチ変更	対象件数、再実行、途中失敗、前後ジョブ、処理時間

テストデータと前提条件を具体化する

同じ操作でも、データ状態や権限によって結果が変わります。テストケースには、利用者権限、事前データ、システム日付、接続先、関連処理の実行状態などを記載します。

期待結果は「正しく表示される」ではなく、表示内容、更新値、件数、メッセージ、ログ、後続処理まで具体化します。第三者が読んでも合否を判断できる表現が基本です。

2．条件・操作・結果が分かるエビデンスを残す

テストエビデンスは、実施した事実と判定根拠を第三者へ示す記録です。画面のスクリーンショットだけでなく、事前条件、入力値、操作、結果、実施環境がつながっていることが重要です。

一枚の画像に頼らず、判定に必要な情報を残す

• テストケース番号と実施日時
• 対象環境、アプリケーションの版、利用者権限
• 入力値と事前データ
• 操作手順と画面上の結果
• データベース更新値、ログ、外部連携結果
• 期待結果との比較と合否

重要な箇所は枠や注記で示しますが、加工しすぎて元の情報が分からなくならないようにします。複数の画像を使う場合は、ケース番号と連番を付け、操作順が追えるようにします。

画面だけでなく内部結果も確認する

画面に完了メッセージが表示されても、データベースが正しく更新されているとは限りません。更新テーブル、件数、ステータス、タイムスタンプ、後続処理の対象など、仕様で求められる内部結果を確認します。

一方、個人情報や認証情報をエビデンスへ残す場合は、プロジェクトのルールに従います。不要な情報は取得せず、必要に応じてマスキングし、保管場所と閲覧権限を適切に設定します。

再現できる情報を残す

「テスト環境A、ビルド1.2.3、一般利用者権限で実施。取引番号12345を入力し登録ボタンを押下。完了メッセージを確認し、対象テーブルのステータスが01から02へ更新されたためOKと判定」

このように条件と判定根拠がつながっていれば、レビュー担当者が結果を確認でき、後日同じテストを再実施することもできます。

3．不具合とテスト結果を品質改善へつなげる

不具合を修正して再テストが通れば、そのケースは完了します。しかし、同じ種類の不具合を減らすには、発生原因と見逃し原因を振り返る必要があります。

発生原因と流出原因を分けて考える

原因	問いかけ	改善例
発生原因	なぜ不具合を作り込んだか	設計記載、実装規約、レビュー観点の改善
流出原因	なぜ前工程で見つからなかったか	テスト観点、データ、エビデンスの改善
影響拡大要因	なぜ影響が広がったか	入力防御、監視、切り戻し手順の改善

「担当者の確認不足」で終わらせず、確認しやすい仕組みになっていたかを見ます。チェックリスト、レビュー手順、自動テスト、静的解析など、再現性のある改善へつなげます。

件数だけでなく傾向を見る

テスト進捗を実施件数だけで評価すると、品質上の問題を見落とすことがあります。機能別、原因別、重大度別、検出工程別に不具合を整理し、偏りを確認します。

• 特定機能へ不具合が集中していないか
• 仕様理解の誤りが繰り返されていないか
• 異常系や境界値の不具合が多くないか
• 修正によるデグレードが発生していないか
• テスト終盤でも重大不具合が出続けていないか

傾向が見えたら、残りのテストへ観点を追加する、重点確認範囲を広げる、設計レビューへ戻るなど、実施中の品質改善へ反映します。

テストで避けたい3つの失敗

1．手順どおり操作することが目的になる

期待結果と実際の結果を比較し、周辺への影響も確認します。少しでも違和感があれば、仕様とログ、データを確認します。

2．エビデンスの量を増やしすぎる

画像が多すぎると、判定に必要な情報が埋もれます。何を証明するためのエビデンスかを決め、必要な情報へ絞ります。

3．不具合を個別修正だけで閉じる

類似箇所への横展開、テストケースの追加、設計書やレビュー観点の更新まで検討します。

テスト実施メモのテンプレート

【テストの目的】
確認する仕様：
減らしたいリスク：

【実施条件】
環境・ビルド：
利用者・権限：
事前データ：

【操作】
入力値：
操作手順：

【期待結果】
画面：
データベース：
ログ・外部連携：

【実際の結果】
確認内容：
エビデンス：
判定：

【不具合・気付き】
事象：
類似箇所：
追加確認：

若手SE向けテストチェックリスト

• テストで減らしたいリスクを説明できる
• 正常系、異常系、境界値、状態遷移を検討した
• 変更箇所の周辺機能と後続処理を確認した
• 事前条件、入力値、期待結果を具体化した
• 画面だけでなくデータ、ログ、連携結果を確認した
• 第三者が合否を判断できるエビデンスを残した
• 不具合の発生原因と流出原因を振り返った

まとめ：テストは品質を確認し、次の改善へつなげる

システムテストでは、ケース数を増やすことより、重要なリスクを適切な条件で確認し、その結果を説明できることが大切です。

• 観点は仕様とリスクから組み立て、周辺・後続処理まで確認する
• エビデンスは条件、操作、結果、判定根拠をつなげて残す
• 不具合の傾向を分析し、設計・レビュー・テストの改善へ反映する

テスト中の小さな違和感を見過ごさず、仕様やデータへ戻って確認する習慣が、重大な不具合を防ぐ力になります。

現場で役立つ開発・保守の基本へ戻る