정상 동작하던 기능이 SW 수정 후 문제가 발생하는 회귀 결함의 유무를 확인하기 위해 이전 테스트 케이스를 다시 실행하며 확인하는 테스트 (Regression Test)
SW가 변경되면 기존에 통과했던 영역이 다시 깨질 수 있다는 가정에서 출발한다. 지속적 통합 관점에서는 매 커밋마다 돌려서 회귀를 조기에 차단하는 것이 표준.
재테스팅 vs 회귀 테스트
두 활동은 수정 후 확인이라는 공통점이 있지만 범위·목적이 다르다.
| 구분 | 재테스팅 (Re-Testing) | 회귀 테스트 (Regression Test) |
|---|---|---|
| 목적 | 발견된 결함이 정상 조치되었는지 확인 | 회귀 결함(수정으로 인한 부작용) 발생 여부 확인 |
| 범위 | 결함이 발생한 항목만 | 이전 테스트 케이스 전체 (또는 영향 분석 기반 선별) |
| 수행 주체 | 결함 발견자 (테스팅 담당자) | 테스팅 담당자 + 자동화 파이프라인 |
| 수행 시기 | 담당 개발자가 조치 완료를 전달했을 때 (예: JIRA Resolved → 결함 발견자에게 Assign) | 정기 (커밋·일·주 단위) |
회귀 결함을 유발하는 SW 수정
회귀는 다음 세 가지 수정 활동에서 주로 발생한다.
- 새로운 결함의 조치 — 버그 수정 과정에서 정상 코드 영향
- 리팩토링 — 기능 유지 전제이지만 구조 변경은 부작용 가능
- 새로운 기능의 추가 / 변경 — 공유 모듈 수정 시 기존 기능 영향
→ 살충제 패러독스는 같은 TC 반복 시 효과가 감소하는 별개 문제. 회귀 테스트는 이전 TC를 유지한다는 점에서 차이.
수행 방법
자동화 권고
수동 수행은 비용·인력·시간에 대한 제약으로 비현실적이므로 자동화된 스크립트 기반으로 진행한다.
주기 결정
프로젝트 규모에 따라 주기가 달라진다.
| 프로젝트 규모 | 실행 주기 |
|---|---|
| 작은 경우 | 신규 Commit 시 매번 실행 |
| 큰 경우 | 일 / 주 단위 실행 |
지속적 통합 연계
Jenkins 기반 CI 파이프라인에 회귀 테스트 스위트를 포함시키면, 커밋·병합 시점에 자동 실행되어 결함을 조기에 검출한다.
A-SPICE 4.0의 Regression Verification
A-SPICE 4.0은 SYS·SWE 우측 Verification 프로세스 전반에 걸쳐 회귀 검증을 검증 수단 선정(BP2/BP3) 단계에서 고려하도록 요구한다. 3.1에서는 상위 BP의 “전략 수립(Develop … strategy)” 안에 회귀가 포함되었으나, 4.0에서는 독립된 수단 선정 BP로 위치가 이동.
| 프로세스 | BP 번호 | 내용 |
|---|---|---|
| SYS.4 | BP2 | Select verification measures |
| SYS.5 | BP2 | Select verification measures |
| SWE.4 | BP2 | Select software unit verification measures |
| SWE.5 | BP3 | Select verification measures — 통합 단계별 회귀 검증 기준 문서화, 릴리즈 범위에 충분한 커버리지 |
| SWE.6 | BP2 | Select verification measures |
→ SWE.5 BP3 Note 4의 선정 기준 예시:
- 지속적 통합 / 지속적 개발에 따른 회귀 검증 필요성 (예: SW 아키텍처·상세 설계 변경)
- 제공될 제품 릴리즈의 의도된 사용 (test bench / test track / public road 등)
A-SPICE SWE.5 상세 참조.