TC 검토 워크플로우
목차
- 진행 체크리스트
- 규율
- 철칙
- 거부 우선 (전제 조건 게이트)
- 1단계 — 두 출처를 그대로 로드 [중간 자유도]
- 2단계 — 추적 매트릭스 구축 [중간 자유도]
- 3단계 — 행 품질 검사 [중간 자유도]
- 3b단계 — 'PO/보고자에게 문의' 전 출처 검색 (필수) [낮은 자유도]
- 4단계 — Good vs Need Improve 보고 [중간 자유도]
- 5단계 — 프로젝트의 TC-review 채널에 알림 [낮은 자유도]
- QA 마무리 ('완료' 전 필수) [낮은 자유도]
- 스킬 구성
- 범위 외
- MUST / NEVER
- 필독 파일
- 의존성
누군가 이미 작성한 테스트 케이스 문서를 검토합니다. 이 워크플로우는 테스트 케이스를 직접 설계하거나 편집하지 않습니다. 한 가지 질문에 답합니다: 이 문서는 작성된 그대로 티켓의 AC/EC 및 비즈니스 규칙이 검증될 것임을 증명하는가?
슬래시 명령 단축키 (명령어를 지원하는 런타임): /tc-review → commands/tc-review.md.
진행 체크리스트
실행이 시작될 때 이 블록을 응답에 복사하고 각 줄이 완료될 때마다 체크하세요. 게이트 실패 시 되돌아가기: 행에 지정된 단계로 돌아갑니다. 해당 지점부터 체크를 해제하세요.
TC 검토 진행:
- [ ] 거부 우선 (전제 조건 게이트)
- [ ] 1단계 — 두 출처를 그대로 로드
- [ ] 2단계 — 추적 매트릭스 구축
- [ ] 3단계 — 행 품질 검사
- [ ] 3b단계 — 'PO/보고자에게 문의' 전 출처 검색 (필수)
- [ ] 4단계 — Good vs Need Improve 보고
- [ ] 5단계 — 프로젝트의 TC-review 채널에 알림 (스레드만 질문)
- [ ] QA 마무리 ('완료' 전 필수)
규율
shared-preamble.md 및 shared-must-never.md를 따르세요.
철칙
양쪽 모두 인용된 출처 없이 결론 내리지 않음
모든 결론은 이번 세션에서 실제로 열어본 두 가지, 즉 TC 문서 자체 텍스트와 티켓 자체의 AC/EC/비즈니스 규칙 텍스트(또는 Figma/PRD와 같은 설계 출처. 단, 실제로 열어본 후에만)를 비교합니다. 일반적인 품질 감각으로 'TC가 불완전해 보인다'는, 티켓 자체 문구가 옆에 인용되지 않은 상태에서는 결론이 아닙니다. 티켓을 읽은 후 판단하세요. 이번 세션에서 실제로 열리지 않은 출처에 대한 설계 출처 주장(정확한 텍스트 복사, 정확한 UI 상태)도 결론이 아닙니다. 추측하지 말고 '확인되지 않음 — {출처}를 열 수 없음'이라고 말하세요.
이는 일반적으로 완료된 작업에 대해 catch-ai-workflow가 실행하는 것과 동일한 규율입니다. 이 워크플로우는 실행 후가 아닌 전에 실행되는 TC별 인스턴스입니다.
거부 우선 (전제 조건 게이트)
다음 두 가지가 모두 없으면 시작하지 않아야 합니다:
- TC 문서 — 이 세션에서 접근 및 읽기가 가능한 시트, CSV 또는 마크다운 파일;
- 해당 티켓 — AC/EC를 포함하는 Jira 이슈 키 또는 URL(또는 사용자가 명시적으로 명명한 동등한 사양 출처).
🔴 중지 — 둘 중 하나라도 누락되면 skill-rules-style.md에 따라 한 메시지로 중지하세요.
교차 조직/교차 사이트 티켓: 티켓이 연결된 MCP에 액세스 권한이 부여되지 않은 Atlassian 사이트에 있는 경우 그렇게 말하고 사용자에게 액세스 권한을 부여(또는 AC/EC를 직접 붙여넣기)하도록 요청하세요. 클라우드 ID를 추측하거나 읽기 위해 브라우저 로그인에 의존하지 마세요.
1단계 — 두 출처를 그대로 로드 [중간 자유도]
- TC 문서 — 있는 그대로 읽으세요. 로드하는 동안 단어를 다시 입력하거나, 요약하거나, '정리'하지 마세요. 정확한 출처(시트 ID + 탭/gid, 파일 경로 또는 URL)를 기록하여 이후의 모든 인용이 이를 가리킬 수 있도록 하세요.
- 티켓 — 티켓 자체 필드(설명, 사용자 정의 필드 — 일부 프로젝트는
description외부에 콘텐츠를 보관하므로 둘 다 확인)에서 AC, EC 및 모든 비즈니스 규칙/재확인 목록 섹션을 가져오세요. AC/EC 레이블과 텍스트를 정확히 작성된 대로 인용하세요. 유사한 티켓을 기억하여 의역하지 마세요. 어느 곳에서도 AC/EC를 찾을 수 없음 → 거부 우선 게이트에 따라 중지하세요. 사양 텍스트는 발견되었지만 항목에 AC/EC 레이블이 없는 경우 → 🔴 중지 — 발견된 텍스트를 표시하고 사용자에게 2단계 전에 번호를 매기는 방법을 물어보세요. 레이블을 절대 만들지 마세요. 티켓 또는 TC 문서 가져오기 오류, 시간 초과 또는 부분 콘텐츠 반환(텍스트 잘림, 필드 누락, 로드되지 않는 탭) → 사용자에게 정확한 오류 또는 누락된 내용을 알리고, 부분적인 AC/EC 또는 부분적인 TC 문서로 매트릭스를 구축하지 말고, 실패를superpowers:systematic-debugging에 전달하고, 전체 텍스트가 로드된 후에만 1단계를 재개하세요. - 설계 출처(Figma, PRD)가 링크되어 있고 사용자가 교차 확인을 원하는 경우 이 세션에서 여세요. 열 수 없는 경우(세션 없음, 액세스 권한 없음, 렌더링된 콘텐츠가 없는 보기 전용) 그 사실을 명확히 기록하세요. 관련 결론 옆에 '확인되지 않음' 메모가 되며, 절대 조용히 건너뛰지 않습니다.
2단계 — 추적 매트릭스 구축 [중간 자유도]
티켓의 모든 AC 및 EC에 대해 해당 내용을 다루는 TC 행을 나열합니다:
| AC/EC | 주장 행 | 상태 |
|---|---|---|
AC_01 | TC_003 | covered(적용됨) |
AC_05 | — | no TC — gap(TC 없음 — 공백) |
AC_02 | TC_007 | mis-tagged(잘못 태그됨) — TC_007의 예상 결과가 AC_04와 일치함 |
EC_01 | TC_010, TC_011 | inconsistent tag(일관성 없는 태그) — 형제 행 TC_012가 태그 없이 동일한 요소를 테스트함 |
상태는 고정된 목록입니다 — 행당 정확히 다음 네 값 중 하나를 사용하고 표시된 대로 ID를 지정하세요:
covered · no TC — gap · mis-tagged — <TC> matches <AC/EC> · inconsistent tag — <TC ids>.
여러 문제가 있는 행은 covered 이후 해당 순서로 먼저 적용되는 문제를 사용합니다. 티켓 자체 AC 목록의 구멍은 매트릭스 행이 아닌 사양 수준의 공백입니다. Need Improve에서 사양 질문으로 보고하세요(MUST / NEVER 참조).
취소선 처리된 AC/EC는 계산하지 않습니다. 티켓에서 삭제된 행(예: -AC_07-, 종종 중복으로 표시됨)은 범위를 벗어납니다. 매트릭스와 보고서에서 완전히 제외하세요. '올바르게 적용되지 않음'으로도 언급하지 마세요.
비즈니스 규칙 및 티켓 댓글은 컨텍스트이지 추가 AC가 아닙니다. AC/EC의 의미를 이해하고 TC가 올바른 것을 테스트하는지 판단하는 데 읽으세요. AC/EC와 충돌하는 경우에만 비즈니스 규칙 또는 댓글 항목을 보고하고, 모순되는 AC/EC를 명시하세요. TC는 없지만 어떤 AC/EC와도 모순되지 않는 규칙이나 댓글은 결론이 아닙니다. Need Improve에서 제외하고 이를 위한 '사양 참고 사항' 섹션을 추가하지 마세요.
행/AC ID를 명시하여 다음을 표시하세요:
- TC가 하나도 없는 AC/EC;
- 예상 결과가 태그된 AC와 다른 AC와 검증 가능하게 일치하는 TC;
- 동일한 테마(예: 공유 UI 요소)가 형제 행 간에 일관성 없이 태그됨 — 일부는 AC를 가지고 있고 일부는 명시된 이유 없이 가지고 있지 않음.
3단계 — 행 품질 검사 [중간 자유도]
tc-quality-standards.md를 모든 행에 적용하여 다음과 같은 검토별 실패 패턴을 읽으세요(작성 품질과 구별됨 — 이것은 다른 사람이 작성한 문서에 관한 것이므로 질문은 우아함이 아닌 신뢰성입니다):
| 신호 | 중요한 이유 |
|---|---|
| 단계가 제목이 주장하는 상태에 도달하지 않음. '학습자가 X를 봄'이라고 제목이 지정된 행의 단계가 메인 페이지에서 중단되어 실제로 X를 열지 않음. | 해당 케이스가 검증한다고 주장하는 바를 검증할 수 없음. |
| 예상 결과가 AC의 문장을 그대로 복사하여 분해하지 않음. 티켓이 해당 AC 아래에 여러 구체적인 하위 항목(필드, 상태, 버튼 변형)을 나열할 때 AC 문장만 반복하는 예상 결과는 테스터가 행별로 확인할 항목을 제공하지 않음. | 합격/불합격이 추측이 됨. |
| AC가 명명된 케이스/상태를 열거함(예: '케이스 1–6', '로딩 / 비어 있음 / 필터' 상태) 그리고 문서에는 이 모든 것에 대한 일반 행이 하나만 있음. | 열거된 상태의 대부분이 행이 완료로 표시되었음에도 테스트되지 않은 채로 남음. |
| AC에 특정 값이 필요한 곳에 테스트 데이터에 구체적인 값이 없음(경계 개수, 특정 날짜 관계, 명명된 필터 옵션). | 행을 작성된 대로 실행할 수 없음 — 테스터가 누락된 값을 만들어야 함. |
| 행이 AC의 표현과 다른 조건을 테스트함. AC가 '이미 스크롤 지나감'이라고 하지만 행은 '끝까지 시청함'을 사용함. AC가 '게시된 항목만'이라고 하지만 예상 결과는 상태를 확인하지 않음. | 행이 통과할 수 있지만 AC 자체 조건은 테스트되지 않은 채로 남음. |
| 예상 결과가 행 자체 테스트 데이터가 허용하는 것보다 모호함. 테스트 데이터가 답(점수, 개수, 공식)을 계산하는 데 필요한 모든 입력을 제공하지만, 예상 결과는 '올바르게 정렬됨'이라고만 함. | 테스터가 실행 중간에 예상 값을 알아내야 하므로 잘못된 순서도 합격으로 표시될 수 있음. |
| 행의 열이 서로 모순됨. 전제 조건이 '항목 4개'라고 하지만 테스트 데이터는 3개를 나열함. 제목이 '상태'라고 하지만 예상 결과는 순서만 확인함. | 테스터가 어떤 열을 따르든 다른 열이 잘못됨. |
| 티켓 전제 조건이 모든 행에서 누락됨(예: '사용자가 로그인함'). | 모든 행이 명시되지 않은 설정 단계를 상속함. |
| 설정이 방법을 제공하지 않고 이름만 지정함('요청을 실패하게 하는 방법이 있음', '충분한 데이터를 준비하세요'). | 두 명의 테스터가 서로 다른 두 가지 방법으로 설정함. |
케이스를 신뢰할 수 있는지 여부에 영향을 미치지 않는 테스트 케이스 스타일 선택(명명 규칙, 열 순서, 우선순위 레이블)은 사용자가 특별히 스타일 검토를 요청하지 않는 한 플래그를 지정하지 마세요. 이는 tc-quality-standards.md를 여기서 재정의합니다: 사용자가 스타일 검토를 요청하지 않는 한 우선순위 속성 및 '우선순위 할당됨' 검토 게이트를 무시하세요.
3b단계 — 'PO/보고자에게 문의' 전 출처 검색 (필수) [낮은 자유도]
이 워크플로우는 제품 판결을 내리지 않지만 사양 수준의 공백과 질문을 제기합니다. 결론이 'PO/보고자에게 문의' 또는 '사양 불명확'이 되기 전에 result-quality-gate.md의 레이어 14에 있는 출처 검색을 실행하세요: 경로:줄이 있는 기본 브랜치의 제품 코드, 해당 인라인 주석 및 git log -L / git blame; 메인 티켓 및 모든 댓글; 주변 티켓(상위/에픽, 연결됨, 동일한 화면 또는 API의 형제, 커밋 메시지가 명명하는 티켓); 회귀 결과; 그리고 설계 노드. 발견한 내용 옆에 읽은 내용을 인용하세요. 출처가 이미 답을 제공하는 질문은 질문이 아닌 출처가 있는 결론입니다.
제품 클론 누락 또는 읽을 수 없음(dependencies.md의 {MONOREPO} 확인 실패): 검토를 중지하지 말고 자동으로 코드 레이어를 건너뛰지 마세요. 코드 레이어가 답변했을 모든 질문 옆에 코드 확인 안 됨 — 클론 없음을 작성하고, 나머지 출처로 검색을 계속하고, 그러한 질문을 검색 완료로 제시하지 마세요. 해당 메모를 가지고 4단계로 이동합니다.
항목별 출력: 결론(또는 남은 질문) + 위치(경로:줄, 티켓 키 + 댓글, 회귀 행, 설계 노드)가 있는 인용 출처, 또는 코드 레이어를 실행할 수 없을 때 코드 확인 안 됨 — 클론 없음 메모.
되돌아가기: 검색이 답변한 질문은 출처가 있는 결론으로 2단계 또는 3단계로 돌아갑니다. 어떤 출처도 답변하지 않은 질문만 '개발자/PO와 확인'으로 4단계로 이동합니다.
4단계 — Good vs Need Improve 보고 [중간 자유도]
두 개의 짧은 목록, 각 항목은 행 ID, AC ID 또는 인용된 텍스트에 고정되어야 합니다. 절대 고정되지 않은 의견이어서는 안 됩니다.
**Good (좋음)**
- {TC/AC ID 또는 인용문이 있는 결론}
**Need Improve (개선 필요)**
- {TC/AC ID 또는 인용문이 있는 결론}
→ Suggest: {수정 방법}
모든 Need Improve 항목에는 '→ Suggest:' 줄이 있어 수정 방법을 알려줍니다. 수정 방법이 없는 문제는 TC 작성자를 추측하게 만듭니다. 각 제안은 출처에서 가져와야 하며, 절대 만들어낸 값이 아니어야 합니다:
- 행 자체 데이터에서 계산됨: 테스트 데이터에 이미 입력값이 있는 경우 값을 계산하여 제공하세요(예: 각 계산된 점수와 함께 예상 순서). 작성자가 확인할 수 있도록 숫자를 표시하세요.
- AC/EC 문구에서 가져옴: 예를 들어 잘못된 조건을 AC 자체 문구로 바꾸거나, AC 자체 텍스트를 사용하여 누락된 예상 결과 절을 추가하세요.
- 값을 제공하는 출처 없음(티켓이 명시하지 않은 임계값, 개수 또는 타이밍): 값을 추가할 것을 제안하고 누가 확인하는지 말하세요('개발자/PO와 개수 확인'). 절대 숫자를 만들어내지 마세요.
각 항목을 간결하게 유지하세요. 제안은 무엇을 변경할지 말할 뿐, 행을 다시 작성하지 않습니다. 사용자가 범위를 좁히려는 경우(예: 'X에 관한 모든 것을 삭제'), 해당 범주를 제거하고 2-3단계에서 목록을 다시 생성하세요. 수동으로 산문을 반응적으로 편집하지 마세요. 그렇지 않으면 동일한 범주가 다음에 다른 표현으로 다시 나타날 수 있습니다.
언어: 기본적으로 티켓/TC 문서 자체 언어와 일치시킵니다. 혼합됨 = 티켓의 AC/EC와 TC 문서가 다른 언어로 작성된 경우 → 사용자에게 검토를 작성할 언어를 한 번 물어보세요. Helix 메뉴 및 접수 질문은 user-communication.md에 따라 영어를 유지합니다. 검토 콘텐츠 자체는 대상 문서의 언어를 따릅니다. 이는 해당 문서가 이미 가지고 있는 것과 동일한 예외입니다.
검토는 5단계 전송 전에 채팅에 게시하세요. 외부 메시지는 채팅 메시지와 달리 보내기를 취소할 수 없습니다. 5단계 스레드 질문이 진행을 허락하는 신호입니다. 별도의 '보낼까요?' 질문을 추가하지 마세요.
5단계 — 프로젝트의 TC-review 채널에 알림 [낮은 자유도]
모든 실행은 완료된 검토를 TC-review 채널(또는 프로젝트의 project-config.md에 지정된 해당 채널)로 보냅니다. 클라이언트의 Slack 또는 Teams MCP가 대상 채널을 찾을 수 없는 경우, 정확한 오류를 알리고 사용자에게 채널을 지정하거나 메시지를 대신 게시하도록 요청하세요. 채널 이름을 추측하지 마세요.
검토를 전송하기 전에 사용자에게 원하는 스레드(있는 경우)를 물어보세요:
- '이 TC 검토를 작업 스레드에 게시할까요, 아니면 TC 검토 스레드에 게시할까요? 새 스레드를 만들어야 하나요?'
- 사용자가 선택하거나 새 스레드를 요청할 때까지 기다리세요.
- 사용자가 스레드를 지정하면 거기에 검토 메시지를 게시하세요.
QA 마무리 ('완료' 전 필수) [낮은 자유도]
qa-closing.md를 적용하세요. 특히:
- 최종 대화 내용을 확인하세요:
- 모든 게이트가 통과되었습니까? 아니요 → 관련 단계로 돌아가세요.
- 사용자가 검토를 승인했습니까? 아니요 → 피드백을 기다리거나, 요청된 대로 조정하세요.
- 5단계 메시지가 전송되었습니까? 아니요 → 전송하세요.
- 최종 확인은 출력의 일부가 아닙니다. 마지막에 '완료'라고 말하세요.
스킬 구성
| 단계 | 자유도 |
|---|---|
| 거부 우선 (전제 조건 게이트) | 낮음 |
| 1단계 — 두 출처를 그대로 로드 | 중간 |
| 2단계 — 추적 매트릭스 구축 | 중간 |
| 3단계 — 행 품질 검사 | 중간 |
| 3b단계 — 'PO/보고자에게 문의' 전 출처 검색 (필수) | 낮음 |
| 4단계 — Good vs Need Improve 보고 | 중간 |
| 5단계 — 프로젝트의 TC-review 채널에 알림 | 낮음 |
| QA 마무리 ('완료' 전 필수) | 낮음 |
범위 외
이 스킬은 다음에 사용하지 않아야 합니다:
- 새 테스트 케이스 작성 (
tc-fe-prep-workflow/tc-api-prep-workflow); - 티켓 실행 (
testing-ticket-workflow); - 녹화된 증거 클립 검토 (
review-result-workflow); - 버그 수정 재테스트 (
retest-bug-workflow); - 테스트 케이스 내보내기 또는 가져오기 (범위 외);
- 테스트 실행 결과 분석 (범위 외).
MUST / NEVER
MUST:
- 모든 결론을 행 ID, AC ID 및 인용된 출처 텍스트에 고정하세요.
- 티켓에서 AC/EC 레이블과 텍스트를 정확히 사용하세요. 의역하지 마세요.
- 3b단계 출처 검색을 완료한 후에만 'PO/보고자에게 문의' 결론을 표시하세요.
- 검토 언어에 대해 물어볼 필요가 없는 한 검토를 티켓/TC 문서 언어로 작성하세요.
NEVER:
- 출처를 인용하지 않고 결론을 내리지 마세요. '보기에...'로 시작하는 문장은 허용되지 않습니다.
- AC/EC 레이블을 만들지 마세요. 발견된 텍스트에 없는 경우 사용자에게 번호를 매기는 방법을 물어보세요.
- 취소선 처리된 AC/EC를 보고하지 마세요. 완전히 생략하세요.
- 비즈니스 규칙 또는 댓글을 AC인 것처럼 취급하지 마세요. 충돌이 있는 경우에만 언급하세요.
- 실행되지 않은 코드 레이어를 '통과됨'으로 표시하지 마세요. '코드 확인 안 됨' 메모를 사용하세요.
- 사용자가 명시적으로 요청하지 않는 한 스타일 문제를 플래그로 지정하지 마세요.
- 5단계 알림 전에 채팅 외부로 검토를 보내지 마세요.
필독 파일
이 워크플로우를 실행하기 전에 항상 읽고 숙지하세요:
- shared-preamble.md
- shared-must-never.md
- skill-rules-style.md
- tc-quality-standards.md
- result-quality-gate.md
- qa-closing.md
- user-communication.md
- project-config.md (프로젝트별 채널 매핑용)
의존성
- Jira MCP — 티켓 데이터 가져오기용.
- Google Sheets MCP (또는 동등한 것) — 시트 기반 TC 문서 읽기용.
- Slack / Teams MCP — 5단계 검토 알림 전송용.
- 파일 시스템 액세스 — CSV, 마크다운 및 로컬 파일 읽기용.
- Git (제품 클론) — 3b단계 출처 검색용.
의존성을 사용할 수 없거나 실패하면 해당 단계를 건너뛰지 말고 사용자에게 보고하고 계속 진행(가능한 경우) 또는 중지하세요.