1. Introduction
This question evaluates your understanding of regression testing versus confirmation testing based on test execution history across multiple software versions.
Note (EN/KR):
The key is to determine which test runs are re-tests of failed tests (confirmation) and which are regression tests.
핵심은 이전 실행에서 실패한 테스트를 다시 실행한 것(확인 테스트)과, 이전에 통과했던 테스트를 다시 실행하는 것(회귀 테스트)을 구분하는 것입니다.
2. Key Concepts
-
Confirmation Testing (Re-test) – re-running tests that failed in the previous execution to verify defect fixes.
확인 테스트(재테스트): 이전 실행에서 실패한 테스트를 다시 실행하여 결함 수정 여부를 확인합니다. -
Regression Testing – re-running tests that previously passed to check whether new changes introduced side effects.
회귀 테스트: 이전에 통과했던 테스트를 다시 실행하여 변경으로 인해 새로운 문제가 생기지 않았는지 확인합니다. -
Test execution history determines test classification.
테스트 실행 이력에 따라 회귀/확인 테스트가 결정됩니다.
3. Practice Question
❓ Question
You executed tests across three software versions. After each failed test, the team fixes all reported defects and provides a new build. Which execution numbers represent regression tests?
📄 Test Execution Table
| Execution | TC1 | TC2 | TC3 |
|---|---|---|---|
| Execution 1 | (1) Failed | (2) Passed | (3) Failed |
| Execution 2 | (4) Passed | (5) Failed | (6) Failed |
| Execution 3 | (7) Passed | (8) Passed | (9) Passed |
📌 Options
- a) Only 4, 7, 8, 9
- b) Only 5, 7
- c) Only 4, 6, 8, 9
- d) Only 5, 6
✅ Correct Answer: b) Only 5, 7
📘 Explanation (EN/KR)
-
Tests (4) and (6) are confirmation tests.
They re-execute failures from Execution 1: (1) and (3).
테스트 (4), (6)은 Execution 1에서 실패한 (1), (3)을 다시 실행한 것이므로 확인 테스트입니다. -
Tests (8) and (9) are also confirmation tests.
They re-execute failures from Execution 2: (5) and (6).
테스트 (8), (9)은 Execution 2에서 실패한 (5), (6)의 재실행이므로 확인 테스트입니다. -
Regression Test Identification:
– TC2 passed in Execution 1 → its next run (5) is regression testing.
– TC1 passed in Execution 2 → its next run (7) is regression testing.
회귀 테스트 기준:
– TC2는 Execution 1에서 통과 → 다음 실행 (5)은 회귀 테스트
– TC1은 Execution 2에서 통과 → 다음 실행 (7)은 회귀 테스트입니다.
✔ Therefore, the only regression tests are (5) and (7).
✔ 따라서 회귀 테스트는 (5), (7) 두 개뿐입니다.
📊 Summary Table
| Test No. | Why? | Test Type |
|---|---|---|
| 4 | Re-test of TC1 failure in (1) | Confirmation 확인 테스트 |
| 5 | TC2 previously passed in (2) | Regression 회귀 테스트 |
| 6 | Re-test of TC3 failure in (3) | Confirmation |
| 7 | TC1 previously passed in (4) | Regression |
| 8 | Re-test of TC2 failure in (5) | Confirmation |
| 9 | Re-test of TC3 failure in (6) | Confirmation |
4. Summary & Call to Action
This question strengthens your ability to analyze execution history to determine which test runs are confirmation tests and which are regression tests.
이 문제는 테스트 실행 이력을 분석하여 어떤 테스트가 회귀 테스트이고 어떤 테스트가 확인 테스트인지 판단하는 능력을 강화해 줍니다.
refer to : FL-2.2.3
Regression Testing vs Confirmation Testing – ISTQB 핵심 요약
1. What is Confirmation Testing?
Confirmation Testing (also called re-testing) verifies that a specific defect has been correctly fixed by executing the failed test again.
확인 테스트(재테스트)는 특정 결함이 제대로 수정되었는지 확인하기 위해 이전 실행에서 실패했던 테스트를 다시 실행하는 것입니다.
✔ Key Points
- Executed only on test cases that previously failed.
이전에 실패했던 테스트에만 수행됩니다. - Scope is narrow and specific.
범위가 좁고 특정 부분만 검증합니다. - Purpose: verify defect correction.
목적: 결함이 정말 고쳐졌는지 확인.
✔ Simple Example
Login fails with incorrect error handling → Developer fixes → Tester re-runs the same login test → This is confirmation testing.
로그인 기능에서 에러 처리 문제 발생 → 개발자가 수정 → 동일한 로그인 테스트를 다시 실행 → 이것이 확인 테스트입니다.
2. What is Regression Testing?
Regression Testing ensures that a change (fix, enhancement, or environment update) did not introduce new defects in unchanged parts of the software.
회귀 테스트는 수정·변경·환경 업데이트 후, 변경되지 않은 기존 기능에 새로운 문제가 생기지 않았는지 확인하는 테스트입니다.
✔ Key Points
- Executed on test cases that previously passed.
이전에 통과했던 테스트를 다시 실행합니다. - Scope is broad.
범위가 넓습니다. - Purpose: ensure no unintended side effects.
목적: 변경으로 인해 다른 기능이 망가지지 않았는지 확인.
✔ Simple Example
Developer fixes a bug in the shopping cart → Payment, order summary, and discount calculation are re-tested → This is regression testing.
장바구니 기능 결함을 개발자가 수정 → 결제, 주문 요약, 할인 계산 기능을 다시 테스트 → 이것이 회귀 테스트입니다.
3. Comparison Table
| Aspect | Confirmation Testing | Regression Testing |
|---|---|---|
| Purpose |
Verify a defect fix 결함 수정 확인 |
Ensure no new defects in unchanged code 변경되지 않은 기능의 부작용 방지 |
| Based On |
Previously failed tests 이전에 실패한 테스트 기반 |
Previously passed tests 이전에 통과한 테스트 기반 |
| Scope |
Very narrow (only failed tests) 매우 좁음 (실패 테스트만) |
Broad (related, impacted, important functions) 넓음 (연관 기능 전체) |
| When Executed |
After fixing a specific defect 결함 수정 직후 |
After any change to the system 시스템 변경 후 언제나 |
| Typical Question Trigger |
“Was the fix successful?” “고친 부분이 맞게 작동하나?” |
“Did the change break anything else?” “다른 것들은 안 망가졌나?” |
4. Quick Memory Tips
✔ Easy ISTQB Mnemonics
-
Confirmation = Fix Check
확인 테스트 = “고쳐졌나?” 확인 -
Regression = Side Effect Check
회귀 테스트 = “다른 건 멀쩡한가?” 확인
✔ Realistic Example
If login was broken and fixed → Confirmation. If homepage, search, or cart are re-tested afterwards → Regression.
로그인이 깨져서 고쳤다면 → 확인 테스트. 그 수정 후 홈, 검색, 장바구니도 테스트한다면 → 회귀 테스트입니다.
Related: More ISTQB Posts