한 장으로 끝내는 QA 보드:
시나리오–TC–버그 상태 정의

서론

실패를 먼저 적으면, 실패는 덜 일어난다.

한 장 보드에 시나리오–TC–버그 상태를 정리하면 출시 속도가 빨라집니다.

이 글은 핵심 여정 기준 시나리오(가입–탐색–구매–결제–취소), TC 템플릿(사전조건·단계·기대결과·우선순위·기기/브라우저), 버그 라이프사이클(Open–In Progress–Resolved–Verified–Closed)을 한 장의 QA 보드로 정리하는 실무 가이드입니다. 특히 “비번 9자 입력 시 가입 버튼 비활성 유지”처럼 실패 케이스를 먼저 적는 방법을 예시로 다룹니다.

📚 목차

1. 한 장 QA 보드가 필요한 이유
2. 시나리오 설계: 핵심 여정 5단계
3. TC 템플릿: 사전조건·단계·기대결과
4. 버그 라이프사이클: 상태와 규칙
5. 우선순위(P)·심각도(S) 매트릭스
6. 기기/브라우저 매트릭스
7. QA 보드 예시 레이아웃
8. 체크리스트 요약
9. 결론
10. FAQ

본론

1) 한 장 QA 보드가 필요한 이유

• 가시성: 시나리오–TC–버그 상태를 한 화면에서 추적.
• 속도: 담당/우선순위가 명확해 핸드오프 지연 감소.
• 일관성: 요구사항·화면·API와 용어/ID를 동일하게 유지.

2) 시나리오 설계: 핵심 여정 5단계

가입 → 탐색 → 구매 → 결제 → 취소 순으로 사용자 흐름을 커버

1. 가입: 유효성·권한·이메일/소셜 예외.
2. 탐색: 검색/필터/정렬/빈 상태.
3. 구매: 장바구니/쿠폰/포인트 경계값.
4. 결제: 3D 인증/취소/실패 복구.
5. 취소: 부분취소/환불 시점/수수료 정책.

팁: 각 시나리오에 실패 경로(네트워크 오류, 경계값, 권한)를 반드시 포함합니다.

3) TC 템플릿: 사전조건·단계·기대결과

재현 가능하고 단정적인 문장으로 작성

TC ID	시나리오	사전조건	단계(Steps)	기대결과	P/S	기기/브라우저
TC-JOIN-009	가입	신규 사용자, 쿠키 초기화	비밀번호 9자 입력 → 가입 버튼 클릭	가입 버튼은 비활성 유지, 오류 문구 표시	P1/S2	iOS/Safari, AOS/Chrome, PC/Chrome
TC-CART-012	구매	장바구니에 상품 1개	쿠폰 코드 만료값 입력 → 적용	적용 실패, COUPON_4001 노출	P2/S2	모바일/크롬

문장 규칙: “주어진 조건에서, 언제 무엇을 하면, 그러면 무엇이 보인다/일어난다.”

4) 버그 라이프사이클: 상태와 규칙

Open → In Progress → Resolved → Verified → Closed

• Open: 재현 스텝/환경/로그 포함해 등록.
• In Progress: 담당자 배정, 원인 범주 지정(요구/설계/개발/데이터/환경).
• Resolved: 수정 범위·릴리즈 노트·테스트 빌드 번호 기재.
• Verified: 재현 TC로 재검증, 회귀 영향 확인.
• Closed: 재발 방지 원인 기록 필수.

반려 규칙: 재현 불가/중복/설계 의도는 Reason과 증빙(캡처/로그) 첨부.

5) 우선순위(P)·심각도(S) 매트릭스

• 심각도(S): S1 치명(결제불가), S2 주요(핵심 플로우 차질), S3 경미(뷰/카피).
• 우선순위(P): P1 즉시, P2 스프린트 내, P3 다음 분기.
• 원칙: S는 영향도, P는 처리 시급도. 서로 독립적으로 판단.

6) 기기/브라우저 매트릭스

트래픽 기준으로 커버리지 정의

OS	브라우저	버전	해상도	필수/선택
iOS	Safari	최근 2메이저	390×844	필수
Android	Chrome	최근 3메이저	360×800	필수
Windows	Chrome	최근	1920×1080	필수
macOS	Safari/Chrome	최근	1440×900	선택

7) QA 보드 예시 레이아웃

시나리오 컬럼–TC 리스트–버그 상태 칼럼을 좌→우로 배치

• 좌: 시나리오(가입/탐색/구매/결제/취소)별 카드.
• 중: TC 표(필터: P/S, 상태: 준비/진행/완료).
• 우: 버그 칼럼(Open/In Progress/Resolved/Verified/Closed).

모든 항목에는 요구사항ID/화면ID/API/TC ID 링크를 병기해 추적성을 확보합니다.

8) 체크리스트 요약

• 시나리오에 실패 케이스를 먼저 적는다.
• TC는 사전조건·단계·기대결과·P/S·기기/브라우저를 포함한다.
• 버그 상태 전환 시 원인 분류·재발 방지를 남긴다.
• 기기/브라우저 커버리지를 명시한다.
• 요구사항/화면/API/TC 간 ID 링크를 유지한다.

결론

한 장 QA 보드는 속도와 품질을 동시에 올리는 최소 단위입니다. 핵심 여정 시나리오–TC–버그 상태를 같은 언어와 규칙으로 묶으면 QA가 묻지 않고, 릴리즈 전 마지막 방어선이 단단해집니다. 오늘 바로 템플릿을 만들고 팀에 공유해 보세요.

FAQ

Q시나리오는 몇 개가 적당한가요?

A 릴리즈 범위 기준 5~8개를 권장합니다. 여정의 끊김 없이 핵심 플로우를 커버하는지 확인하세요.

Q TC와 버그의 차이는?

A TC는 검증 계획, 버그는 검증 결과의 차이입니다. 각 TC는 하나 이상의 버그를 참조할 수 있습니다.

Q 실패 케이스는 얼마나 써야 하나요?

A 정상 1 : 실패 2 이상 비율을 권장합니다. 경계값, 권한, 네트워크 오류를 최소 포함하세요.

Q P/S 충돌 시 어떤 값을 우선하나요?

A 심각도(S)가 사용자·비즈니스 영향이 크면 우선 처리하되, 일정 영향과 위험도를 고려해 우선순위(P)를 최종 결정합니다.

Q 재현 불가 이슈는 어떻게 처리하나요?

A환경·데이터·시간 조건을 좁혀 다시 시도하고, 증빙 로그/영상이 없으면 Needs Info로 반려 후 재현 조건을 요청합니다.