회귀 테스트

회귀 테스트(regression testing)는 변경으로 인해 원래 동작하던 무언가가 망가지지 않았는지 확인하는 테스트입니다. “회귀(regression)“란 이전 빌드에서는 동작했지만 이제는 동작하지 않는 기능을 말합니다. 버그 수정, 기능 추가, 리팩터링, 의존성 업그레이드, 설정 변경이 있을 때마다 기존 동작에 대한 테스트를 다시 실행해 회귀를 잡아냅니다.

예시

한 팀이 결제 화면에 “기프트카드로 결제” 옵션을 추가합니다. 새 기능에는 별도의 테스트가 작성됩니다. 회귀 테스트는 다른 질문을 던집니다. 카드 결제, 할인 코드, 세금 계산, 주문 확인 메일이 이전과 정확히 똑같이 동작하는가? 가격 계산 모듈의 공통 코드를 수정하면 새 코드 경로를 건드리지 않고도 이 중 어느 것이든 쉽게 망가질 수 있습니다.

무엇을 실행할지 고르기

모든 커밋마다 모든 테스트를 실행하는 것이 가장 단순한 전략이고, 자동화된 테스트 스위트가 빠르다면 대개 이것이 정답입니다. 전체 스위트가 너무 느리거나 일부가 수동이라면 팀은 다음 기준으로 범위를 선택합니다.

• 리스크 기준. 회원 가입, 결제, 데이터 내보내기처럼 비즈니스에 중요한 흐름은 항상 실행합니다.
• 영향도 기준. 변경 사항과 코드, 데이터, 서비스를 공유하는 영역을 실행합니다.
• 이력 기준. 과거에 회귀가 발생했던 모듈은 다시 회귀하는 경향이 있습니다.

흔히 쓰는 방식은 풀 리퀘스트마다 빠른 회귀 테스트 일부를 실행하고, 전체 스위트는 야간이나 릴리스 전에 실행하는 것입니다.

팀이 가장 먼저 자동화하는 이유

회귀 테스트는 같은 단계를 같은 기대 결과에 대해 반복해서 실행하며, 이는 자동화가 가장 잘하는 일입니다. 수동 회귀 테스트는 릴리스마다 늘어나지만 주어진 시간은 늘지 않으므로 가장 먼저 줄어듭니다. CI에 자동화된 회귀 테스트 스위트를 두면 “뭔가 망가뜨리지 않았나?“라는 질문이 일주일짜리 수동 점검에서 파이프라인 결과 하나로 바뀝니다.

흔한 실수

• 스위트를 추가만 하는 대상으로 여기기. 쓸모없어지거나 중복된 테스트는 모든 실행을 느리게 만듭니다. 정기적으로 검토하고 정리해야 합니다.
• 불안정한 테스트(flaky test) 방치하기. 실패할 때마다 통과할 때까지 재실행하는 습관이 생기면, 진짜 회귀도 재실행으로 묻혀 버립니다.
• UI로만 테스트하기. 회귀 커버리지 대부분은 단위 테스트와 API 수준에서 더 저렴하고 안정적으로 확보할 수 있습니다.