개념
리뷰의 목적은 결과물이 아니라 기준이다
리드가 팀원의 테스트 케이스를 리뷰할 때 두 가지 목적이 섞여 있다. 하나는 지금 이 결과물을 고치는 것, 다른 하나는 다음 결과물이 처음부터 좋게 나오게 하는 것 이다. 첫 번째만 하면 리드는 영원히 같은 코멘트를 반복한다. 두 번째가 되려면 코멘트가 사람의 기억이 아니라 문서화된 기준 에 연결되어야 한다.
그래서 리뷰의 첫 산출물은 코멘트가 아니라 리뷰 체크리스트 다. 체크리스트가 있으면 팀원은 제출 전에 스스로 점검하고, 리뷰어가 바뀌어도 같은 판단이 나오고, 코멘트는 "체크리스트 4번"처럼 짧아진다.
테스트 케이스 리뷰 체크리스트
| 번호 | 항목 | 확인 질문 |
|---|---|---|
| TC-1 | 추적성 | 요구사항 또는 위험 항목 ID가 연결되어 있는가 |
| TC-2 | 설계 근거 | 적용한 설계 기법(동등 분할·경계값·결정표·상태 전이 등)이 명시되어 있는가 |
| TC-3 | 사전 조건 | 계정·데이터·환경 상태가 재현 가능하게 적혀 있는가 |
| TC-4 | 단계의 원자성 | 한 단계에 한 동작만 있는가 |
| TC-5 | 기대 결과 | 측정 가능한 기대 결과인가("정상 동작" 금지) |
| TC-6 | 화면 밖 확인 | 필요한 경우 API·DB·로그 확인이 포함되어 있는가 |
| TC-7 | 부정 경로 | 오류·예외·경계 밖 입력 케이스가 있는가 |
| TC-8 | 중복 | 같은 조건을 다른 이름으로 두 번 확인하지 않는가 |
| TC-9 | 우선순위 | 위험 기반 우선순위가 부여되어 있는가 |
TC-5가 가장 자주 걸린다. "정상적으로 처리된다", "올바르게 표시된다"는 기대 결과가 아니다. "주문 상태가 PAID로 바뀌고, 결제 금액 12,900원이 영수증에 표시되며, orders 테이블의 paid_at이 기록된다" 가 기대 결과다.
결함 보고서 리뷰 체크리스트
| 번호 | 항목 | 확인 질문 |
|---|---|---|
| BR-1 | 제목 | 제목만 읽고 어디서 무엇이 잘못됐는지 알 수 있는가 |
| BR-2 | 재현 절차 | 처음 보는 사람이 그대로 따라 재현할 수 있는가 |
| BR-3 | 실제/기대 | 실제 결과와 기대 결과가 분리되어 있고, 기대 결과의 근거(요구사항 ID 등)가 있는가 |
| BR-4 | 환경 | 빌드 번호·OS·브라우저·기기·계정 유형이 있는가 |
| BR-5 | 증거 | 스크린샷·영상·로그·요청/응답이 첨부되어 있는가 |
| BR-6 | 재현율 | 항상 재현인지, 10번 중 몇 번인지 적혀 있는가 |
| BR-7 | 심각도 근거 | 심각도 판단의 근거(영향 범위·우회 가능성)가 있는가 |
| BR-8 | 어조 | 사람이 아니라 현상을 기술하는가 |
결함 보고서 리뷰는 개발팀의 반려율 과 직결된다. 반려 사유를 한 달간 모아 보면 대개 BR-2(재현 불가)와 BR-3(기대 결과 근거 없음)가 절반 이상이다. 이 두 항목만 강화해도 반려율이 눈에 띄게 줄어든다.
자동화 코드 리뷰 체크리스트
자동화 코드는 개발자 코드 리뷰 관습을 따르되, 테스트 코드 고유의 항목을 더한다.
| 번호 | 항목 | 확인 질문 |
|---|---|---|
| AT-1 | 검증 존재 | 동작만 하고 검증(assert)이 없는 테스트는 아닌가 |
| AT-2 | 독립성 | 다른 테스트의 실행 순서나 결과에 의존하지 않는가 |
| AT-3 | 대기 | 고정 sleep 대신 조건 대기를 쓰는가 |
| AT-4 | 선택자 | 역할·레이블·테스트 ID 같은 안정적인 선택자를 쓰는가 |
| AT-5 | 데이터 | 테스트 데이터를 스스로 만들고 정리하는가 |
| AT-6 | 실패 메시지 | 실패했을 때 무엇이 틀렸는지 메시지만으로 알 수 있는가 |
| AT-7 | 이름 | 테스트 이름이 검증하는 행동을 설명하는가 |
코멘트는 세 종류로 구분한다
모든 코멘트가 같은 무게로 보이면 팀원은 무엇부터 고쳐야 할지 모른다. 코멘트 앞에 표시를 붙인다.
| 표시 | 뜻 | 처리 |
|---|---|---|
| [필수] | 체크리스트 위반, 이대로면 결함을 놓치거나 재현 불가 | 고쳐야 승인 |
| [권장] | 더 좋게 만들 수 있지만 지금도 쓸 수 있음 | 작성자 판단 |
| [질문] | 리뷰어가 이해하지 못한 부분 | 답변 후 필요하면 수정 |
[필수] TC-5: "결제 완료 화면 표시"는 측정 가능한 기대 결과가 아닙니다.
주문 상태, 금액, DB paid_at 기록을 기대 결과로 적어 주세요.
[권장] TC-8: 7번과 12번 케이스가 같은 경계(9,999원)를 확인합니다. 하나로 합쳐도 됩니다.
[질문] 쿠폰과 포인트를 동시에 쓰는 조합이 없는데, 정책상 불가능한 조합인가요?[질문] 표시가 특히 중요하다. 리뷰어가 틀릴 수도 있다는 것을 인정하는 표시이고, 팀원이 도메인을 더 잘 아는 경우 대화를 열어 준다.
리뷰 유형 고르기 — ISO/IEC 20246
ISO/IEC 20246(작업 산출물 리뷰)은 리뷰를 형식 수준에 따라 구분한다. 팀 상황에 따라 고른다.
| 유형 | 형식 | 언제 쓰나 |
|---|---|---|
| 비공식 리뷰 | 기록 최소, 대화 중심 | 일상적인 케이스 리뷰, 페어 작업 |
| 워크스루 | 작성자가 설명하며 진행 | 새 팀원의 첫 결과물, 지식 공유 |
| 기술 리뷰 | 전문가들이 기술적 타당성 검토 | 자동화 프레임워크 구조, 성능 시나리오 |
| 인스펙션 | 역할(진행자·기록자 등)과 체크리스트, 지표 기록 | 규제 산업의 테스트 명세, 안전 관련 케이스 |
의료기기·기능안전처럼 리뷰 기록 자체가 규제 증거가 되는 도메인에서는 인스펙션 수준의 기록이 필요하다(모듈 35, 40). 일반 웹 서비스에서는 비공식 리뷰와 워크스루를 주로 쓰고, 체크리스트만 공식화해도 충분하다.
리뷰 부담 조절 — 표본·페어·자가 점검
리드 혼자 모든 결과물을 리뷰하면 병목이 된다. 부담을 나누는 방법이 있다.
- 자가 점검 먼저 — 제출 전에 작성자가 체크리스트를 채운다. 리드는 체크 안 된 항목과 고위험 영역만 본다
- 표본 리뷰 — 숙련된 팀원의 결과물은 전체가 아니라 고위험 기능과 무작위 20%만 본다
- 페어 리뷰 — 팀원끼리 서로 리뷰하게 하고, 리드는 페어 리뷰 코멘트의 질을 본다
- 신규 팀원은 전체 리뷰 — 처음 한두 달은 전부 보고, 반려율이 기준 아래로 내려가면 표본으로 전환한다
리뷰를 측정한다
리뷰가 효과가 있는지는 지표로 본다.
| 지표 | 정의 | 해석 |
|---|---|---|
| 재작성률 | [필수] 코멘트를 받은 결과물 비율 | 높으면 기준 공유가 부족 |
| 결함 반려율 | 개발팀이 반려한 결함 비율 | 결함 보고서 품질의 대리 지표 |
| 리뷰 소요 시간 | 제출부터 승인까지 | 길면 리뷰가 병목 |
| 탈출 결함의 리뷰 연관 | 운영에서 발견된 결함 중 리뷰에서 잡을 수 있었던 비율 | 체크리스트에 빠진 항목의 신호 |
마지막 지표가 체크리스트를 진화시킨다. 운영 결함이 나올 때마다 "리뷰 체크리스트에 무엇이 있었다면 잡았을까"를 묻고 항목을 추가한다.
실무에서 왜 필요한가
리뷰 기준이 없는 팀에서는 같은 기능을 누가 테스트했느냐에 따라 품질이 달라진다. 운영 장애가 났을 때 "그 기능은 누가 테스트했어?"라는 질문이 나오는 팀은 기준이 사람에게 붙어 있는 팀이다. 체크리스트는 이 질문을 "우리 기준의 어느 항목이 빠져 있었나?"로 바꾼다.
또 리뷰는 리드가 팀원의 성장을 관찰하는 가장 좋은 창이다. 재작성률이 줄어드는 팀원은 표본 리뷰로 전환해 자율을 넓히고, 특정 항목이 반복되는 팀원에게는 그 부분을 코칭한다(레슨 3).
채용시장에서의 위치
리드 면접에서 "리뷰를 어떻게 하셨나요"라는 질문에 체크리스트 한 장과 재작성률 변화를 보여 줄 수 있으면 강하다. 체크리스트는 기밀이 적어 포트폴리오에 넣기도 쉽다.