변경별 회귀 테스트 범위 결정 워크북

회귀 범위의 출발점은 변경한 파일 수가 아니라 달라진 요구와 그 영향입니다. 변경 번호와 이유, 변경 전후 요구의 버전, 대상 빌드와 테스트 버전을 먼저 적습니다. 화면 문구를 바꾼 것인지, 사용자의 권한이나 데이터 해석을 바꾼 것인지가 드러나야 합니다. 여러 변경을 한 번에 내보낸다면 각각의 변경 번호와 공통으로 건드리는 경계를 연결합니다. 출시 기한과 환경 제약은 함께 기록하되 위험이 낮다는 근거로 사용하지 않습니다.

이 워크북의 결과는 실행할 테스트와 제외한 이유입니다. 선정표를 채웠다고 테스트가 수행되거나 출시가 승인된 것은 아닙니다. 변경의 위험으로 범위를 고르는 논리는 회귀 테스트 범위 인사이트에서 설명합니다. 여기서는 그 판단을 변경 브리프, 영향 후보, 범위 결정, 실행·제외 기록과 인계표에 적용합니다.

같은 권한 정책을 여러 화면과 API가 쓰거나 하나의 파일을 여러 시스템이 읽는다면 수정한 위치 밖에서도 실패할 수 있습니다. 변경 요구에서 구현과 테스트를 따라가고, 구현에서 호출자와 사용자 행동을 거꾸로 확인합니다. 권한 정책, 저장 규칙, 검색과 내보내기, 공통 설정과 외부 연동은 별도로 살펴볼 경계입니다. 영향 후보표에는 연결 근거와 확인할 실패 상황, 검토 결과와 담당을 적습니다.

테스트와 요구가 연결돼 있다는 사실만으로 현재 버전의 영향 검토가 끝나지는 않습니다. 요구가 바뀐 뒤 기대 결과도 갱신됐는지 확인합니다. 연결이 없으면 영향 없음으로 처리하지 말고 미확정으로 남겨 확인할 사람과 시점을 정합니다. 요구사항 변경과 테스트 추적성은 영향 후보를 찾는 연결의 관리 방법을 다룹니다. 후보를 찾는 일과 그중 어떤 테스트를 실행할지 고르는 일은 구분합니다.

범위 결정표는 영향의 도달 범위, 변경의 불확실성, 실패 영향, 탐지와 되돌리기 조건을 기록합니다. Focused는 확인된 독립 경계와 인접 흐름을, Expanded는 여러 역할·연동·데이터 소비자에 걸친 흐름을, Broad 또는 Release-level은 릴리스의 중요한 공통 실패 경계를 함께 검토하는 수준입니다. 이 이름은 테스트 개수나 통과 기준을 자동으로 정하지 않습니다.

공통 권한 변경 하나가 범위를 넓힐 근거라면 다른 축의 낮은 점수 여러 개와 평균내지 않습니다. 반대로 코드 수정량이 많더라도 영향이 독립된 모듈에 머문다는 증거가 있으면 관련 없는 전체 테스트를 선택할 이유는 적습니다. Broad도 모든 테스트의 무조건 실행을 뜻하지 않습니다. 관련성이 낮은 항목은 근거를 남겨 제외할 수 있습니다. 중요한 시나리오를 시간이나 계정 부족으로 못 돌린다면 범위를 낮게 다시 이름 붙이지 않고 미검증 조건으로 남깁니다.

다음 사례는 작성 연습용 가상 변경이며 실제 고객의 수정이나 실행 결과가 아닙니다. A는 조회·검색·다운로드에서 사용하는 공통 문서 권한 정책의 변경입니다. 여러 역할과 조직 경계에 닿는다는 가정 아래 Broad 범위를 선택하고 다른 조직의 문서 조회, 검색 결과의 노출과 다운로드 권한을 함께 후보로 둡니다. 독립 통계 화면의 문구는 해당 정책이나 데이터와 연결되지 않았음을 확인한 경우에만 제외합니다.

B는 두 소비자가 읽는 내보내기 파일에 필드를 추가하는 변경입니다. 파일 생성만 확인하지 않고 두 소비자의 필드 해석과 이전 형식 호환성을 포함하는 Expanded 범위를 검토합니다. 소비자 목록이 낡았다면 미확정 항목을 남기고 확인 전까지 영향 검토가 끝났다고 표시하지 않습니다. C는 식별값·저장값·공통 로직을 바꾸지 않는 독립 표시 문구의 수정입니다. 그 조건을 확인했다는 가정에서 Focused 범위로 표시와 인접 조작을 선택합니다.

실제 C의 문구가 업무 코드나 검색 키로도 사용된다면 가정이 깨집니다. 같은 범위 수준을 복사하지 말고 영향 후보를 다시 봅니다. 예제의 핵심은 어떤 수준을 선택했는가보다 그 선택을 가능하게 한 조건이 무엇인가입니다. 선택한 테스트의 결과 칸은 실제 실행 전까지 비워 둡니다.

범위 수준을 정한 뒤에는 테스트 번호, 선정·제외·미확정 구분, 판단 근거와 실행 준비를 적습니다. 예제 A의 다른 조직 문서 조회를 선정했다면 조직별 계정과 대상 문서가 필요합니다. 계정이 없다는 이유로 관련성이 낮다고 적으면 안 됩니다. 준비할 항목과 담당, 실행할 시점을 기록하고 출시 담당에게 미검증 위험을 전달합니다. 독립 통계 문구를 제외할 때는 권한 정책과 데이터 연결을 확인한 자료를 참조합니다.

과거 결함을 발견한 테스트와 실제 사용 흐름도 선정 근거로 활용합니다. 과거 결함 기록이 없다는 사실만으로 위험이 낮다고 판단하지는 않습니다. 연동과 데이터 상태를 함께 봐야 의미가 있는 검증도 있습니다. 공통 규칙을 더 빠르고 재현하기 쉬운 계층에서 확인할 수 있다면 방법을 바꿀 수 있지만, 사용자 화면에서만 관찰되는 위험까지 사라졌다고 보면 안 됩니다. 제외 이유를 다른 담당자가 읽고 같은 경계를 이해할 수 있는지 확인합니다.

실행·재검토 인계표에는 선정 테스트와 회차, 대상 빌드·환경·실행 번호, 결과·결함·미검증 조건과 다음 담당을 연결합니다. PASS·FAIL·BLOCKED·NOT RUN은 실제 실행 결과에 쓰고 아직 계획만 한 항목을 통과로 표시하지 않습니다. 빌드·요구·설정이 바뀌면 변경 브리프를, 새 의존성이나 결함이 발견되면 영향 후보와 선정 근거를 다시 검토합니다. 이전 통과 기록이 새 변경을 설명하는지도 확인해야 합니다.

출시 회의의 READY·READY WITH CONDITIONS·HOLD는 합의한 기준과 실제 결과, 미검증 범위와 잔여 위험을 검토한 별도 판단입니다. 결과는 릴리스 판정 메모·시나리오 결과표로 연결합니다. 제공 PDF와 작성용 Excel은 한국어판입니다. 변경 목록과 현재 테스트 카탈로그, 미확정 영향과 출시 제약을 준비하면 IXC의 QA 프로세스 구축 또는 QA 아웃소싱에서 실행 범위와 역할을 구체적으로 상담할 수 있습니다.