【ISTQB /JSTQB FL 4.0解説】リテスト(再テスト)とリグレッションテストの違いを理解しよう

JSTQB Fundation Level 4.0

ソフトウェア開発では、バグ修正やコード変更が頻繁に行われます。

こうした変更の後に行うテストとして、「リテスト(再テスト/確認テスト)」と「リグレッションテスト(回帰テスト)」があります。

ISTQB Foundation Level(CTFL)では、これらを「変更に関連するテスト(Change-related Testing)」として扱います。

本記事では、ISTQB 4.0シラバス第2章「2.2 テストレベルとテストタイプ」の中から、

**リテスト(Confirmation Testing)リグレッションテスト(Regression Testing)**についてわかりやすく解説します。


🔹 リテスト(Confirmation Testing)とは?

リテストは、修正された不具合が正しく直っているかを確認するテストです。

一般的には「再テスト(Retesting)」とも呼ばれます。

リテストの流れ

  1. テスターがテスト実行中に不具合を発見

  2. 不具合を報告し、開発者が修正を行う

  3. 修正後のソフトウェアを再度テストして、不具合が解消されたかを確認

つまり、以前失敗した同じテストケースをもう一度実行して確認するのがリテストです。

ISTQBでの正式な呼び方

多くの企業では「Retesting(再テスト)」という言葉を使いますが、

ISTQBでは**「Confirmation Testing(確認テスト)」**という正式名称を使用します。

その理由は以下の通りです。

  • 「Retesting」は単に“再びテストする”という一般的な意味

  • 「Confirmation Testing」は“修正が成功したことを確認する目的を持つテスト”

つまり、ISTQBでは目的を明確にするために「Confirmation Testing」という言葉を採用しています。

実生活の例

たとえば、スマホのスピーカーが壊れて修理に出したとします。

戻ってきたスマホでまず音楽を再生してみる——これがリテストです。

修正された箇所(スピーカー)が正しく動作するかを確認する行為です。


🔹 リグレッションテスト(Regression Testing)とは?

リグレッションテストは、修正や変更によって他の機能に悪影響が出ていないか確認するテストです。

バグを直したり新機能を追加したりすると、

意図せず既存の機能に影響を与えてしまうことがあります。

そのような「副作用(Side Effect)」を検出するのがリグレッションテストです。

リグレッションテストの目的

  • 修正によって他の機能が壊れていないか確認する

  • 以前は正常に動作していた箇所が今も正常であることを保証する

リテストとの違い

比較項目

リテスト(Confirmation)

リグレッションテスト(Regression)

テスト目的

修正が正しく反映されたかを確認

修正による副作用がないか確認

実施対象

修正された箇所のみ

システム全体・関連機能

実施タイミング

バグ修正直後

修正後、全体のテストフェーズで実施

自動化適性

一般的には手動

自動化に最も適している

実生活の例

先ほどのスマホ例で言えば:

  • スピーカー修理後に音楽が再生できるか → リテスト

  • 修理後に通話・カメラ・Wi-Fiが正常に動作するか確認 → リグレッションテスト

つまり、「修正箇所の確認」がリテスト、「他の機能への影響確認」がリグレッションです。


🔹 リグレッションテストはいつ行う?

リグレッションテストは、次のような変更が発生したときに実施されます。

  • 不具合修正後

  • 新機能の追加

  • コードの修正・削除

  • 環境移行やアップグレード

つまり、何らかの「変更(Change)」が行われたすべてのタイミングで行う必要があります。


🔹 リグレッションテストと自動化

リグレッションテストは、繰り返し実行する必要があるため、

自動化の最有力候補とされています。

  • CI/CD(継続的インテグレーション)環境では、自動化テストが毎回実行される

  • 新しいコードがチェックインされるたびに、既存機能が壊れていないか確認できる

  • 開発スピードを落とさず品質を保てる

これにより、回帰による品質低下を早期に防止できます。


🔹 インパクト分析(Impact Analysis)の重要性

リグレッションテストの範囲を最適化するために、

まず「どの部分が影響を受ける可能性があるか」を調べる必要があります。

これをインパクト分析と呼びます。

影響範囲を把握すれば、テストの工数を削減しつつ、効果的に品質を保証できます。


🔹 まとめ

テストタイプ

主な目的

実施対象

自動化適性

リテスト(再テスト)

修正が正しいか確認

修正箇所

手動が多い

リグレッションテスト

他機能への影響確認

システム全体

自動化が有効

  • リテストは「修正箇所が直ったかを確認」

  • リグレッションテストは「修正が他の箇所に影響していないかを確認」

  • どちらも「変更に関連するテスト」であり、品質保証の基本です。


💡 ISTQBポイントまとめ

  • ISTQBでは「Retesting」ではなく「Confirmation Testing」という用語を使用

  • 両方ともあらゆるテストレベル(単体・結合・システム・受け入れ)で実施され得る

  • 回帰テストはCI/CD環境やDevOpsで特に重要

  • インパクト分析によってテスト範囲を最適化できる

コメント

タイトルとURLをコピーしました