버그가 수정되면 대부분의 팀은 정확히 실패했던 경로를 한 번 재테스트하고 다음 단계로 넘어갑니다.

그것은 이해할 수 있는 일이지만, 한 가지 공백을 남깁니다. 팀이 실제 실패로부터 무언가를 배웠음에도 불구하고, 그 배움을 재사용 가능한 회귀 테스트 커버리지 (Regression Coverage)로 전환하는 데 실패한다는 점입니다.

다음은 해결된 버그를 스프레드시트, Jira, TestRail, Qase, Xray, Zephyr 또는 기타 QA 워크플로 (Workflow)에 복사하여 사용할 수 있는 재사용 가능한 회귀 테스트 케이스로 전환하기 위해 제가 사용하는 가벼운 템플릿입니다.

CSV 필드

버그 수정 회귀 테스트를 위해 저는 다음과 같은 컬럼 (Column)들을 선호합니다:

• 테스트 ID (Test ID)
• 버그 ID (Bug ID)
• 기능 영역 (Feature Area)
• 회귀 시나리오 (Regression Scenario)
• 원래의 실패 상황 (Original Failure)
• 전제 조건 (Preconditions)
• 테스트 데이터 (Test Data)
• 단계 (Steps)
• 기대 결과 (Expected Result)
• 네거티브 체크 (Negative Check)
• 우선순위 (Priority)
• 회귀 리스크 (Regression Risk)
• 테스트 유형 (Test Type)
• 자동화 후보 (Automation Candidate)
• 참고 사항 (Notes)

이 구조는 모든 버그 수정을 무거운 테스트 계획 (Test Plan)으로 만들지 않으면서도 테스트를 재사용할 수 있게 하기에 충분합니다.

버그 예시

버그 ID:
BUG-1842

버그 제목:
관리자가 아닌 사용자가 워크스페이스 초대장을 다시 보낼 수 있었음.

원래의 실패 상황:
워크스페이스 멤버가 '대기 중인 초대장 (Pending Invitations)'을 열고 '재전송 (Resend)'을 클릭할 수 있었음. 원래는 소유자 (Owner)와 관리자 (Admin)만 초대 이메일을 재전송할 수 있어야 함.

수정 요약:
이제 재전송 초대 액션 (Action)은 이메일을 보내기 전에 사용자의 워크스페이스 역할 (Role)을 확인합니다.

회귀 테스트 케이스 예시

테스트 ID:
REG-BUG-1842-001

기능 영역:
워크스페이스 초대장 (Workspace invitations)

회귀 시나리오:
워크스페이스 멤버는 대기 중인 초대장을 재전송할 수 없음.

전제 조건:

• 워크스페이스에 최소 하나 이상의 대기 중인 초대장이 있음.
• 테스트 사용자는 워크스페이스 멤버이며, 소유자나 관리자가 아님.
• 사용자가 로그인되어 있음.

단계:

1. 워크스페이스 멤버로 로그인합니다.
2. 워크스페이스 설정 (Workspace Settings)을 엽니다.
3. 대기 중인 초대장 (Pending Invitations)으로 이동합니다.
4. 대기 중인 초대장을 찾습니다.
5. 재전송 (Resend) 액션이 보이는지 또는 사용 가능한지 확인합니다.
6. 만약 API를 통해 액션을 트리거할 수 있다면, 재전송 요청을 시도합니다.

기대 결과:
멤버는 대기 중인 초대를 재전송할 수 없습니다. UI는 해당 액션을 숨기거나 비활성화하며, API는 권한이 없는 재전송 시도를 거부합니다.

부정 테스트 (Negative Check):
제품 규칙(product rules)이 허용하는 경우, 소유자(owner) 또는 관리자(admin)는 여전히 초대를 재전송할 수 있는지 확인합니다.

우선순위:
높음 (High)

회귀 리스크 (Regression Risk):
권한 우회 (Permission bypass)

자동화 대상 여부:
예 (Yes)

AI 어시스턴트에 붙여넣을 수 있는 프롬프트

해결된 버그 수정 사항으로부터 회귀 테스트 케이스 (regression test cases)를 생성하는 시니어 QA 엔지니어 역할을 수행하세요.

먼저, 버그 리포트와 수정 요약(fix summary)을 검토하세요. 원래의 실패 경로, 영향을 받는 기능 영역, 사용자 역할, 데이터 상태, 권한 리스크, API 또는 UI 접점, 그리고 다시 깨질 수 있는 인접 워크플로우 (adjacent workflows)를 식별하세요.
...

가져오기 전 검토 사항

생성된 행(rows)을 테스트 관리 도구에 가져오기 전에 다음 사항을 확인하세요:

• 최소 하나 이상의 케이스가 원래의 정확한 실패 지점을 검증하는가?
• 기대 결과가 실제 제품 규칙과 일치하는가?
• 역할(roles)이 연관된 경우 권한 확인 (permission checks)이 포함되었는가?
• UI가 엔드포인트 (endpoint)를 호출할 때 API 확인이 포함되었는가?
• 테스트 데이터가 현실적이며 사용 가능한가?
• 우선순위가 사용자, 수익, 보안 또는 데이터 리스크를 기반으로 설정되었는가?
• 버그 티켓을 다시 읽지 않고도 나중에 실행할 수 있을 만큼 케이스가 구체적인가?

AI는 회귀 테스트 커버리지 (regression coverage)를 빠르게 초안 작성할 수 있지만, 해당 테스트가 올바른 동작을 보호하는지 확인하는 과정은 여전히 사람이 수행해야 합니다.

더 많은 CSV 필드 상세 정보와 예시를 포함한 더 긴 버전은 여기에서 확인할 수 있습니다:

https://payhip.com/aitestcasegenerator/blog/news/regression-test-case-template-for-bug-fixes-csv-fields-examples-and-ai-prompt