회귀 확인 습관
주제 목차 · 이전: 결함 재현과 원인 분석
이 문서의 결과: 수정 전후 케이스를 비교해 회귀 여부를 확인하고 릴리스 여부를 판단한다.
왜 회귀 확인이 필요한가
기능을 수정한 뒤에는 수정 전 실패했던 케이스와 정상이었던 케이스를 함께 재확인합니다. 하나를 고치다 다른 기능이 깨지는 것(회귀, Regression)을 막기 위해서입니다. 특히 07. dbclient SQL 계약의 SQL이나 08. transact 거래 계약의 계약처럼 여러 화면이 공유하는 파일을 고칠 때는 영향 범위가 생각보다 넓을 수 있습니다.
게시판 예제로 만드는 최소 회귀 목록
| 확인 항목 | 정상 기준 |
|---|---|
BOD010 조건 없는 조회 | 전체 목록이 나온다 |
BOD010 분류 조건 조회 | 해당 분류만 나온다 |
BOD011 필수값 누락 등록 | 저장되지 않고 경고가 뜬다 |
BOD011 정상 등록 | 저장되고 목록에 반영된다 |
BOD012 존재하는 글 조회 | 상세 내용이 채워진다 |
BOD012 없는 ID 조회 | 오류 없이 빈 결과 또는 적절한 안내가 나온다 |
BOD012 삭제 | 목록에서 사라진다 |
이 목록을 매번 손으로 기억하기보다, 실습 기록이나 체크리스트 문서로 남겨 두고 수정할 때마다 같은 목록으로 재확인하는 것을 권장합니다.
릴리스 여부 판단 기준
- 위 회귀 목록이 모두 기대한 대로 동작한다.
- 이번에 수정한 기능이 실제로 원래 문제를 해결했다.
- 새로 만든 오류 메시지나 로그가 12. 모니터링과 운영 인수인계에서 다룰 관측 기준과 충돌하지 않는다.
세 가지를 모두 만족할 때만 다음 단계(배포)로 진행합니다. 하나라도 확인하지 못했다면 "미실행"으로 기록하고 실제로 실행한 뒤 판단합니다.
완료 조건 확인
10. 테스트와 디버깅의 완료 조건을 확인한 뒤 11. 환경설정과 보안으로 이동합니다.