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

개념

나쁜 결함 리포트의 전형

"로그인이 안 돼요."

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

좋은 결함 리포트의 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. 올바른 비밀번호 입력 후 로그인 버튼 클릭

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

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

실무에서 왜 필요한가

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

실습 과제

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

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

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

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

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

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

자가 체크리스트

• 결함 리포트의 5가지 구성 요소를 순서대로 설명할 수 있다
• 재현 절차를 최소 단계로 줄여서 쓸 수 있다
• 실제 결과와 기대 결과를 명확히 대비시켜 쓸 수 있다
• 재현율이 낮은 결함도 정직하게 기록해야 하는 이유를 설명할 수 있다
• 증거자료(스크린샷·로그)가 왜 신뢰를 빠르게 얻는 수단인지 설명할 수 있다

흔한 실수

• 제목에 "안 돼요"류의 모호한 표현만 쓴다. 제목만 보고도 대략 무슨 문제인지 알 수 있어야 한다.
• 재현 절차에 불필요한 단계를 다 나열한다. 최소 재현 경로를 찾는 것도 QA의 몫이다.
• 실제 결과만 쓰고 기대 결과를 생략한다. "왜 이게 문제인지"는 기대 결과와 대비했을 때만 명확해진다.
• 증거자료 없이 글로만 설명한다. 스크린샷 한 장이 문단 하나보다 빠르고 정확하게 전달된다.

참고 자료

• ISTQB Glossary — Defect Report — 결함 리포트의 공식 정의와 구성 요소
• Cem Kaner, Testing Computer Software — 결함 리포트 작성 원칙을 다룬 고전