좋은 결함 리포트 쓰기: 재현 절차, 실제 vs 기대 결과, 증거자료

개념

결함 리포트는 보고서가 아니라 설득 문서다. 하는 일이 하나 더 있다 — 읽는 사람이 "이건 고쳐야 한다" 고 판단하게 만드는 것. 사실만 적혀 있어도 판단이 안 서면 그 결함은 목록에 남아 있다가 잊힌다.

병원에 가서 "아파요" 라고만 말하면 의사는 질문을 열 개 해야 한다. "어제 저녁부터 오른쪽 아랫배가 아프고, 누르면 더 아픕니다" 라고 하면 의사는 바로 다음 단계로 간다. 결함 리포트의 좋고 나쁨이 정확히 이 차이다.

나쁜 결함 리포트의 전형

"로그인이 안 돼요."

이 한 줄로는 개발자가 아무것도 할 수 없다. 어떤 계정으로, 어떤 브라우저에서, 무엇을 입력했을 때, 화면에 뭐라고 떴는지 전부 빠졌다. 개발자는 결국 리포트를 쓴 사람에게 되물어야 하고, 그 왕복에 걸리는 시간이 곧 버그 수정이 늦어지는 시간이다.

이 왕복의 비용은 생각보다 크다. 숫자로 보면 체감이 된다.

왕복 한 번이 반나절인 이유는 대화가 즉시 이뤄지지 않기 때문이다. 개발자가 질문을 남기고, QA가 그걸 보고, 환경을 다시 만들고, 답을 적는다. 각 단계마다 몇 시간이 비어 있다.

그래서 리포트를 쓰는 10분이 아까워 보여도, 그 10분이 이틀을 줄인다.

좋은 결함 리포트의 5가지 구성 요소

1. 제목(Title) — 한 줄로 무엇이 문제인지 요약. "로그인이 안 돼요"가 아니라 "이메일에 대문자가 포함되면 로그인 실패(비밀번호는 정상)"처럼 구체적으로.
2. 환경(Environment) — OS, 브라우저/앱 버전, 계정 종류, 서버 환경 (스테이징/운영) 등 재현에 필요한 조건.
3. 재현 절차(Steps to Reproduce) — 처음부터 끝까지, 번호를 매겨 순서대로. 누가 따라 해도 똑같이 재현되도록 빠짐없이 쓴다.
4. 실제 결과 vs 기대 결과(Actual vs Expected) — "무엇이 일어났는가"와 "무엇이 일어났어야 했는가"를 나란히 대비해서 쓴다. 이 대비가 없으면 읽는 사람이 "이게 왜 문제인지" 스스로 추론해야 한다.
5. 증거자료(Evidence) — 스크린샷, 화면 녹화, 콘솔·네트워크 로그 (모듈 5 레슨 4에서 배운 관찰 습관과 연결). "말"보다 "증거"가 항상 더 빠르게 신뢰를 얻는다.

제목 — 한 줄로 판단이 서게

제목은 목록에서 읽힌다. 수십 건이 나열된 화면에서 제목만 보고 심각도와 담당 영역이 짐작돼야 한다. 공식처럼 외워 둘 만한 틀이 있다.

[어디서] 무엇을 하면 무엇이 된다 (조건)

조건을 괄호에 넣는 습관이 특히 도움이 된다. "비밀번호 정상" 한 마디가 개발자에게 "인증 자체가 아니라 이메일 처리 쪽" 이라는 방향을 준다.

제목에 추측을 넣지 않는다. "캐시 문제로 보이는 목록 미갱신" 이라고 쓰면 그 추측이 틀렸을 때 개발자가 엉뚱한 곳을 먼저 본다. 현상만 적고 추측은 본문 맨 아래에 따로 적는다.

환경 — 무엇을 적어야 하나

"크롬에서 봤어요" 로는 부족하다. 재현에 영향을 주는 것만 골라 적는다.

계정 종류와 데이터 상태가 가장 자주 빠지고 가장 자주 원인이다. "저는 안 되는데 개발자는 된다" 의 대부분이 이 두 줄의 차이다.

재현 절차는 최소 재현 경로로

재현 절차를 쓸 때는 실제로 시도했던 모든 과정을 그대로 나열하지 말고, 결함이 재현되는 데 꼭 필요한 최소 단계만 남긴다. 불필요한 단계가 섞여 있으면 개발자가 "이 단계도 원인에 영향이 있나?"를 다시 확인해야 하는 시간 낭비가 생긴다.

나쁨: "로그인 페이지 갔다가 뒤로가기 눌렀다가 다시 로그인 페이지 가서 이메일 입력하고 비밀번호 입력하고 로그인 버튼 눌렀는데 안 됨"

좋음:

1. 로그인 페이지 접속
2. 이메일에 Test@example.com (대문자 T) 입력
3. 올바른 비밀번호 입력 후 로그인 버튼 클릭

절차를 쓸 때 지킬 네 가지

최소화 외에도 규칙이 있다. 지키면 되묻는 일이 거의 없어진다.

1. 시작점을 명시한다 — "로그아웃 상태로 메인 페이지 접속" 처럼. 어디서 출발했는지 모르면 중간 단계가 재현 안 된다
2. 한 단계에 한 동작만 — "이메일과 비밀번호를 입력하고 로그인" 은 세 동작이다. 어느 단계에서 어긋났는지 알 수 없다
3. 값을 그대로 적는다 — "대문자 포함 이메일" 이 아니라 Test@example.com. 값마다 결과가 다른 경우가 실제로 많다
4. 클릭 대상을 화면의 글자로 — "버튼 클릭" 이 아니라 "[결제하기] 버튼 클릭". 화면에 버튼이 셋이면 어느 것인지 모른다

절차를 줄이는 방법 — 한 단계씩 빼 본다

최소 재현 경로를 "감으로" 찾지 않는다. 기계적인 방법이 있다.

10단계가 3단계로 줄어드는 일이 흔하다. 그리고 줄이는 과정 자체가 원인에 대한 정보를 준다 — "뒤로가기를 빼면 재현이 안 된다" 를 알아내면 그것이 곧 단서다.

시간이 없을 때는 최소화하지 않은 절차라도 올리는 편이 낫다. 다만 "미최소화" 라고 적어 둔다. 완벽한 리포트를 쓰려다 안 올리는 것이 가장 나쁘다.

실제 결과와 기대 결과 — 기대의 근거를 적는다

실제 결과는 쓰기 쉽지만 기대 결과는 근거가 필요하다. 근거가 없으면 "그게 왜 문제죠" 라는 질문으로 돌아온다.

세 번째가 중요하다. 이전 버전에서는 됐다는 사실 하나로 결함은 회귀로 분류되고, 우선순위가 올라가며, 개발자는 최근 변경 목록부터 본다. 원인 찾는 시간이 크게 줄어든다.

문서가 아예 없어 기대 결과를 말할 수 없는 경우도 있다. 그러면 질문으로 올린다 — "현재 이렇게 동작하는데, 의도인가요?" 이것도 값진 리포트다. 답이 "의도다" 로 와도 문서 공백 하나를 찾은 것이다(레슨 1).

증거자료 — 무엇을 어떻게 남기나

스크린샷을 아무렇게나 찍으면 증거가 못 된다.

발생 시각을 초 단위로 적는 것이 의외로 강력하다. 개발자가 서버 로그에서 그 시점을 바로 찾을 수 있고, 그것만으로 원인이 드러나는 경우가 많다.

녹화는 30초를 넘기지 않는다. 3분짜리 영상을 붙이면 개발자가 결함 장면을 찾느라 시간을 쓰고, 결국 안 본다. 길면 발생 시점을 글로 적어 준다("0:12에 발생").

영향 범위를 함께 적는다

레슨 1에서 우선순위는 비즈니스가 정한다고 했다. 그 판단에 쓰일 재료는 QA가 준다.

• 누가 겪나 — 전체 사용자 / 특정 브라우저 / 관리자만
• 얼마나 자주 — 항상 / 특정 조건에서만 / 10번 중 3번
• 우회로가 있나 — 없으면 심각도가 올라간다(레슨 1)
• 데이터가 상하나 — 틀린 값이 저장되면 되돌리기 비용이 크다
• 금전·개인정보가 걸리나 — 걸리면 별도 경로로 즉시 알린다

네 번째와 다섯 번째는 적혀 있지 않으면 아무도 모른다. 화면 오류는 보면 알지만, "잘못된 금액이 DB에 쌓이고 있다" 는 QA가 말해 주지 않으면 며칠간 계속 쌓인다.

추측과 사실을 섞지 않는다

원인을 짐작했다면 적는 것이 도움이 된다. 다만 자리를 나눈다.

현상 — 쿠폰 적용 후 수량을 2로 바꾸면 할인액이 1개 기준으로 유지됨

참고(추측) — 수량 변경 시 할인 재계산이 호출되지 않는 것으로 보입니다. 네트워크 탭에 /cart/recalculate 요청이 없습니다.

"참고(추측)" 라는 표시가 있으면 개발자는 그것을 단서로 쓰고, 틀려도 방향을 잃지 않는다. 표시 없이 섞어 쓰면 추측이 사실처럼 읽혀 엉뚱한 곳을 먼저 파게 된다.

전체 예시 — 이렇게 모이면

지금까지의 요소를 한 장으로 모은 모습이다.

제목  [장바구니] 쿠폰 적용 후 수량 변경 시 할인액이 1개 기준으로 유지됨
 
환경  운영 / v2.14.3 / Chrome 141 / macOS 15
      일반 계정(주문 이력 없음), 10% 할인 쿠폰 1장 보유
 
절차  1. 로그인 후 상품 A(10,000원) 장바구니에 담기
      2. [쿠폰 적용] → 10% 쿠폰 선택 → 할인액 1,000원 표시 확인
      3. 수량을 2로 변경
 
실제  합계 19,000원 (할인액 1,000원 유지)
기대  합계 18,000원 (할인액 2,000원)
근거  쿠폰 정책 문서 3.2 "할인은 적용 대상 금액 전체에 비례"
 
재현  10/10 (항상)
영향  쿠폰 사용자 전체. 우회로 없음. 결제 금액이 실제보다 높게 청구됨
 
증거  screenshot-cart.png, recording.mp4 (0:12 발생)
      네트워크 탭: 수량 변경 시 /cart/recalculate 호출 없음
 
참고(추측)  수량 변경 핸들러에서 할인 재계산이 빠진 것으로 보입니다

"영향" 한 줄이 이 리포트의 무게를 정한다. "결제 금액이 실제보다 높게 청구됨" 이 적혀 있으면 우선순위 논의가 필요 없다.

템플릿을 팀에 두기

매번 기억으로 쓰면 바쁜 날에 빠진다. 이슈 추적 도구의 템플릿 기능에 위 틀을 넣어 두면 빈칸이 보여서 안 빠진다(레슨 4).

템플릿은 짧아야 쓰인다. 항목이 15개면 사람들이 빈칸으로 남기고, 빈칸이 많은 템플릿은 없는 것과 같다. 필수는 제목·환경·절차·실제/기대· 증거 다섯 개로 두고 나머지는 선택으로 둔다.

재현 안 되는 결함도 정직하게 기록한다

모듈 5(레슨 12)에서 배운 원칙 — 재현이 안 되는 버그를 "재현 안 되니까 없던 일로" 덮지 않는다 — 은 결함 리포트에도 그대로 적용된다. 재현율이 낮다면 리포트에 "10번 중 3번 재현됨"처럼 정직하게 기록하고, 재현에 성공했을 때의 조건(네트워크 속도, 특정 데이터 상태 등)을 함께 남긴다. "재현 안 됨"이라는 이유로 리포트 자체를 안 남기면, 그 정보 자체가 사라진다.

사례 — 왕복 4번이 0번이 된 리포트

같은 결함을 두 번 등록한 기록이 남아 있다. 첫 번째는 반려됐고 두 번째는 당일 고쳐졌다.

첫 번째 리포트

제목: 알림이 안 와요 내용: 댓글 달았는데 알림이 안 옵니다. 확인 부탁드립니다.

결국 "재현 불가" 로 반려됐다. 네 번째 질문이 핵심이었는데 그 답을 받기까지 이틀이 걸렸다.

두 번째 리포트 — 같은 결함, 다시 쓴 것

제목: [알림] 다른 사용자가 댓글을 달면 푸시 알림이 오지 않음 (이메일은 정상)

환경: 운영 / iOS 앱 v3.2.1 / 알림 설정 전체 ON / 계정 A의 글, 계정 B가 댓글

절차: 1. 계정 A로 글 작성 → 2. 계정 B로 그 글에 댓글 → 3. 계정 A의 기기 확인

실제: 푸시 없음 / 기대: 푸시 수신 (이메일은 정상 수신됨)

재현: 5/5 / 영향: 푸시를 주 알림으로 쓰는 사용자 전체

질문이 하나도 오지 않았고 당일 고쳐졌다. 원인은 다른 사용자의 댓글에서 수신자 식별이 빠진 것이었다.

두 리포트의 차이는 정보량이 아니라 두 줄이다. "계정 B로" 와 "이메일은 정상" — 이 두 마디가 원인 범위를 푸시 발송 경로로 좁혔다. 첫 번째 리포트를 쓴 사람도 그 사실을 알고 있었지만, 적지 않았다.

실무에서 왜 필요한가

QA와 개발자가 실제로 주고받는 커뮤니케이션 대부분이 결함 리포트를 통해 이뤄진다. 리포트 하나의 품질이 곧 그 버그가 얼마나 빨리, 정확하게 고쳐지는지를 결정한다. 부실한 리포트는 "재현 안 됨"으로 반려되거나, 왕복 질문으로 수정 시간을 몇 배로 늘린다. 채용 면접에서 결함 리포트 작성 능력을 직접 평가하는 회사가 많은 이유도 여기에 있다 — 이건 QA의 가장 기본적이면서도 가장 자주 평가받는 실무 스킬이다.

리포트 품질이 결함 통계를 결정한다

레슨 1에서 본 재오픈율·반려율이 리포트에서 결정된다.

결함 관리 지표가 나쁜 팀의 원인이 대개 도구나 절차가 아니라 리포트에 있다. 레슨 5에서 지표를 다룰 때 이 연결을 다시 본다.

QA의 평판은 리포트로 쌓인다

개발자가 QA를 신뢰하는지는 리포트를 열었을 때의 느낌으로 정해진다. 읽으면 바로 재현되는 리포트를 쓰는 사람의 결함은 우선 처리되고, "또 애매한 거 올라왔네" 라는 평가가 붙으면 똑같이 심각한 결함도 밀린다.

공정하지 않게 들리지만 자연스러운 일이다. 그리고 고치기 쉬운 쪽이 리포트다. 레슨 3에서 다룰 소통 방식과 함께, 이것이 QA가 조직에서 영향력을 얻는 가장 빠른 길이다.

채용시장에서의 위치

결함 리포트는 면접에서 글로 평가받는 거의 유일한 QA 스킬이다. 과제 전형에서 "이 버그를 리포트로 작성하세요" 가 나오는 회사가 많고, 그 자리에서 실력 차이가 분명히 드러난다.

영향과 추측 분리가 지원자를 가장 잘 가른다. 앞의 네 줄은 템플릿을 외우면 채워지지만, 뒤의 두 줄은 결함이 조직에서 어떻게 처리되는지 아는 사람만 쓴다.

면접 질문으로는 이런 것들이 온다.

• "재현이 안 되는 결함은 어떻게 처리하세요?" → 재현율을 적어 올리고, 성공했던 조건을 남긴다(레슨 1·모듈 5 레슨 12)
• "개발자가 재현 안 된다고 하면요?" → 환경·계정·데이터를 맞춰 다시 시도하고, 같은 화면에서 함께 본다
• "리포트를 쓸 시간이 없을 때는요?" → 최소화하지 않은 절차라도 올린다. 안 올리는 것이 가장 나쁘다

세 번째 답이 의외로 점수를 받는다. 완벽함보다 기록을 택하는 판단이 실무 감각으로 읽힌다.

실습 과제

과제 1 — 나쁜 리포트 고쳐쓰기 (15분)

다음 리포트를 5가지 구성 요소를 갖춘 좋은 리포트로 다시 써본다.

"장바구니에서 수량을 늘렸는데 이상하게 나와요. 크롬에서 확인했어요."

(수량 입력란에 소수점을 넣으면 가격 계산이 깨진다고 가정하고, 재현 절차·실제 결과·기대 결과를 직접 구체적으로 만들어 채운다.)

제목  [장바구니] 수량에 소수점을 입력하면 합계가 NaN으로 표시됨
 
환경  스테이징 / v2.14.3 / Chrome 141 / macOS 15
      일반 계정, 장바구니 비어 있는 상태에서 시작
 
절차  1. 로그인 후 상품 A(10,000원) 장바구니에 담기
      2. 수량 입력란을 클릭해 기존 값 지우기
      3. `1.5` 입력 후 입력란 밖 클릭
 
실제  합계가 "NaN원" 으로 표시되고 [결제하기] 버튼이 활성 상태로 남음
기대  소수점 입력이 거부되거나 1로 보정되고, 합계는 10,000원
근거  장바구니 정책 문서 2.1 "수량은 1 이상의 정수"
 
재현  10/10 (항상)
영향  전체 사용자. 우회로는 새로고침. **결제 버튼이 눌리면 어떻게 되는지
      미확인** — 확인 후 추가 보고 예정
 
증거  screenshot-nan.png / 콘솔: Uncaught TypeError (quantity.parse)

과제 2 — 최소 재현 경로 줄이기 (10분)

"상품 목록 페이지 → 검색창에 아무 단어 입력 → 지우기 → 필터 클릭 → 다시 검색창 클릭 → 특정 키워드 입력 → 엔터 → 결과 0건인데 실제로는 상품이 있음"이라는 절차에서, 결함 재현에 실제로 꼭 필요한 최소 단계만 남겨 다시 정리한다.

1. 상품 목록 페이지 접속
2. 검색창에 `무선 이어폰` 입력 후 엔터
3. 결과 0건 표시

과제 3 — 영향 범위 한 줄 쓰기 (10분)

아래 세 결함에 대해 영향 한 줄을 쓴다. 누가·얼마나·우회로·데이터 손상 여부를 담는다.

1. 비밀번호 재설정 메일의 링크가 24시간이 아니라 1분 만에 만료된다
2. 상품 상세 화면에서 리뷰 별점 평균이 소수 둘째 자리에서 반올림이 틀린다
3. 주문 취소 시 재고가 복구되지 않는다

자가 체크리스트

• 결함 리포트의 5가지 구성 요소를 순서대로 설명할 수 있다
• 재현 절차를 최소 단계로 줄여서 쓸 수 있다
• 실제 결과와 기대 결과를 명확히 대비시켜 쓸 수 있다
• 재현율이 낮은 결함도 정직하게 기록해야 하는 이유를 설명할 수 있다
• 증거자료(스크린샷·로그)가 왜 신뢰를 빠르게 얻는 수단인지 설명할 수 있다
• 제목을 [어디서] 무엇을 하면 무엇이 된다 (조건) 틀로 쓸 수 있다
• 환경에서 가장 자주 빠지는 두 항목(계정 종류·데이터 상태)을 안다
• 절차를 쓸 때의 네 규칙(시작점·한 동작·값·화면 글자)을 말할 수 있다
• 한 단계씩 빼 보며 최소 재현 경로를 찾는 절차를 설명할 수 있다
• 기대 결과에 붙일 근거 다섯 종류를 들 수 있다
• "이전 버전에서는 정상이었다" 가 왜 강한 정보인지 설명할 수 있다
• 영향 한 줄에 담을 다섯 가지를 말할 수 있다
• 추측을 별도 표시로 분리해야 하는 이유를 설명할 수 있다
• 리포트 품질이 재오픈율·반려율로 이어지는 경로를 설명할 수 있다

흔한 실수

• 제목에 "안 돼요"류의 모호한 표현만 쓴다. 제목만 보고도 대략 무슨 문제인지 알 수 있어야 한다.
• 재현 절차에 불필요한 단계를 다 나열한다. 최소 재현 경로를 찾는 것도 QA의 몫이다.
• 실제 결과만 쓰고 기대 결과를 생략한다. "왜 이게 문제인지"는 기대 결과와 대비했을 때만 명확해진다.
• 증거자료 없이 글로만 설명한다. 스크린샷 한 장이 문단 하나보다 빠르고 정확하게 전달된다.
• 제목에 추측을 넣는다. "캐시 문제로 보이는…" 이 틀리면 개발자가 엉뚱한 곳을 먼저 본다. 현상만 적고 추측은 따로 표시한다.
• 계정 종류와 데이터 상태를 안 적는다. "저는 안 되는데 개발자는 된다" 의 대부분이 이 두 줄의 차이다.
• 한 단계에 여러 동작을 몰아 쓴다. 어느 동작에서 어긋났는지 알 수 없다.
• 값을 설명으로 대체한다. "긴 이름 입력" 이 아니라 실제로 넣은 문자열을 적는다. 값마다 결과가 다른 경우가 많다.
• 기대 결과에 근거를 안 붙인다. "의도된 동작" 으로 반려되고 다시 설명하게 된다.
• 영향을 안 적는다. 특히 데이터가 상하고 있다는 사실은 적지 않으면 아무도 모른 채 며칠간 쌓인다.
• 녹화를 3분 붙인다. 아무도 안 본다. 30초로 자르거나 발생 시점을 글로 적는다.
• 발생 시각을 안 적는다. 초 단위 시각 한 줄로 서버 로그에서 원인이 바로 나오는 경우가 많다.
• 완벽하게 쓰려다 안 올린다. 최소화하지 않은 절차라도 "미최소화" 를 적어 올리는 편이 낫다.
• 모든 결함의 영향을 크게 적는다. 작은 것을 작게 적는 사람의 "심각하다" 가 힘을 가진다.

참고 자료

• ISTQB Glossary — Defect Report — 결함 리포트의 공식 정의와 구성 요소
• Cem Kaner, Testing Computer Software — 결함 리포트 작성 원칙을 다룬 고전
• Simon Tatham — How to Report Bugs Effectively — 버그 리포트 글쓰기의 고전적인 안내문

이 커리큘럼 안에서

• 모듈 6 레슨 1 — 심각도·우선순위. 영향 한 줄이 그 판단의 재료다
• 모듈 6 레슨 3 — 비난 없는 소통. 같은 사실을 어떤 말로 전하는가
• 모듈 6 레슨 4 — 이슈 추적 도구. 템플릿으로 빈칸을 보이게 만든다
• 모듈 6 레슨 5 — 품질 지표. 리포트 품질이 재오픈율·반려율로 나타난다
• 모듈 5 레슨 4 — 관찰 습관. 콘솔·네트워크 증거를 어디서 얻는가
• 모듈 5 레슨 11~12 — 세션 노트와 재현 불가. 재현율을 정직하게 적는 법
• 모듈 9 — 개발 지식. 로그와 요청·응답을 읽을 수 있으면 증거가 달라진다

한 줄 정리 — 리포트는 설득 문서다. 제목으로 판단이 서게 하고, 절차는 값까지 그대로 적고, 기대 결과에는 근거를 붙이고, 영향을 한 줄로 주고, 추측은 분리한다. 그리고 완벽하게 쓰려다 안 올리는 것이 가장 나쁘다.