11장. QA 리포트는 문제를 고치게 만드는 문서다

QA 리포트는 기록물이 아닙니다. 문제가 존재한다는 사실을 남기는 문서도 아닙니다. QA 리포트의 목적은 단 하나, 문제를 실제로 고치게 만드는 것입니다.

리포트가 아무리 많이 쌓여도 수정으로 이어지지 않는다면, 그 리포트는 실패한 문서입니다.

---

나쁜 리포트는 판단으로 시작한다

다음과 같은 문장은 현장에서 자주 보입니다.

“플레이가 너무 불편합니다.” “밸런스가 완전히 망가졌습니다.” “이대로 출시하면 안 됩니다.”

이 문장들의 공통점은 문제를 설명하지 않고, 결론부터 말한다는 점입니다. 판단이 먼저 나오면, 읽는 사람은 방어적으로 변합니다.

나쁜 리포트는 문제를 고치기 전에, 대화를 막습니다.

---

좋은 리포트는 재현으로 시작한다

좋은 리포트는 항상 동일한 구조를 가집니다.

• 어떤 조건에서
• 어떤 행동을 했을 때
• 어떤 결과가 발생했는가

이 세 가지가 명확하면, 문제는 이미 절반 이상 전달된 상태입니다. 개발자는 감정이 아니라 재현 가능한 현상을 보고 판단할 수 있습니다.

---

현상과 해석을 분리하라

QA 리포트에서 가장 중요한 태도는 구분입니다.

현상: “특정 스킬 사용 후 이동 입력이 일정 시간 무시됨”

해석: “조작감이 나빠짐”

좋은 리포트는 현상을 먼저 제시하고, 해석은 그 다음에 덧붙입니다. 이 순서가 뒤바뀌면 리포트는 의견서가 됩니다.

---

우선순위는 QA가 정리한다

모든 문제를 같은 무게로 던지면, 아무 문제도 중요해지지 않습니다.

QA는 리포트에서 다음을 함께 제시해야 합니다.

• 유저에게 미치는 영향
• 발생 빈도
• 수정 비용 대비 리스크

이 정보가 있을 때, 개발과 기획은 선택할 수 있습니다.

---

리포트는 설득의 문서다

QA 리포트는 중립적이어야 하지만, 무색무취여서는 안 됩니다.

왜 이 문제가 중요한지, 왜 지금 다뤄야 하는지, 왜 방치하면 위험한지를 구조로 설득해야 합니다.

좋은 리포트는 지시하지 않습니다. 대신 판단에 필요한 재료를 제공합니다.

---

템플릿보다 중요한 것

리포트 양식은 도구일 뿐입니다. 형식이 완벽해도 내용이 빈약하면 아무 소용이 없습니다.

스크린샷, 영상, 로그는 현상을 보조하는 수단입니다. 핵심은 언제나 글입니다.

QA는 ‘보여주는 사람’이 아니라, 설명하는 사람입니다.

---

이 장을 마치며

QA 리포트는 잘 쓰는 글이 아닙니다. 고치게 만드는 글입니다.

문제를 발견하는 것보다 어려운 일은, 그 문제를 모두가 이해하게 만드는 일입니다. 이 역할을 해낼 때, QA는 단순한 테스터를 넘어 팀의 의사결정을 움직이는 존재가 됩니다.