테스트 케이스는 QA의 설계도입니다. 기능 하나를 확인하더라도 정상적인 사용, 경계값, 잘못된 입력, 다른 기능과의 충돌까지 빠짐없이 따져야 합니다. 수업에서…
심각도와 우선순위는 다른 질문입니다
처음 QA를 배울 때 가장 많이 섞이는 개념이 심각도와 우선순위입니다. 심각도는 '얼마나 나쁜가'를 묻고, 우선순위는 '언제 고칠 것인가'를 묻습니다. 심각도는 주로 QA가 버그의 영향을 보고 매기고, 우선순위는 기획자나 PM, 개발 리더가 일정과 사업 상황을 함께 보고 정하는 경우가 많습니다.
둘이 늘 같이 움직이지는 않습니다. 게임 로고의 철자가 틀린 버그는 기능에는 영향이 없어 심각도가 낮지만, 출시 첫 화면에 보이기 때문에 우선순위는 높을 수 있습니다. 반대로 아주 드문 조건에서만 생기는 멈춤 버그는 심각도는 높아도, 재현 조건이 까다로워 다음 패치로 미뤄지기도 합니다.
QA가 심각도를 정확하게 매겨 두면, 우선순위를 정하는 사람이 근거를 가지고 판단할 수 있습니다. 그래서 심각도는 QA의 감이 아니라 정해진 기준표에서 나와야 합니다.
네 단계 심각도 기준표 예시
| 등급 | 판단 기준 | 게임 속 예 |
|---|---|---|
| 치명 | 게임 진행 자체가 불가능하거나 데이터·재화에 손실이 생김 | 실행 즉시 종료, 저장 데이터 소실, 결제 후 상품 미지급 |
| 높음 | 핵심 기능이 막히거나 다수 유저가 정상 플레이를 못 함 | 메인 퀘스트 진행 불가, 특정 스킬 사용 시 서버 연결 끊김 |
| 보통 | 기능에 문제가 있지만 우회 방법이 있음 | 정렬 버튼 오작동, 일부 효과음 누락, 특정 메뉴에서 뒤로 가기 이상 |
| 낮음 | 기능에는 영향 없는 표시·문구 문제 | 오타, 아이콘 몇 픽셀 어긋남, 툴팁 줄바꿈 어색 |
회사마다 등급 수와 이름은 다릅니다. 다섯 단계로 나누는 곳도 있고, 영어 이름을 그대로 쓰는 곳도 있습니다. 처음 들어간 회사에서는 기존 기준표를 먼저 찾아 읽고, 예시 버그 몇 개를 직접 분류해 보며 감을 맞추는 것이 좋습니다.
등급을 가르는 판단 질문
기준표만으로는 애매한 버그가 꼭 나옵니다. 이럴 때 아래 질문을 차례로 던지면 등급이 비교적 분명해집니다.
- 유저가 게임을 계속할 수 없게 되는가?
- 유저의 데이터, 재화, 결제에 손해가 생기는가?
- 유저가 스스로 피해 갈 수 있는 방법이 있는가?
- 얼마나 많은 유저가 이 상황을 겪는가?
- 얼마나 자주, 어떤 조건에서 재현되는가?
앞의 두 질문 중 하나라도 '예'라면 치명이나 높음 쪽으로 봅니다. 세 번째 질문에서 우회 방법이 있으면 한 단계 내려갈 여지가 생기고, 네 번째와 다섯 번째 질문으로 최종 조정을 합니다. 단, 재화나 결제가 걸린 버그는 영향받는 유저가 적어도 높은 등급으로 두는 경우가 많습니다. 금전 피해는 신뢰 문제로 이어지기 때문입니다.
재현율도 함께 기록하세요. '열 번 중 두 번 발생'처럼 적어 두면 개발자가 원인을 찾을 때 큰 도움이 됩니다. 재현율이 낮다고 심각도를 낮추기보다는, 심각도는 영향 기준으로 매기고 재현율은 별도 항목으로 남기는 편이 정확합니다.
애매한 버그를 다루는 실전 사례
예를 들어 특정 보스전에서 화면 밖으로 캐릭터가 떨어지는 버그가 있다고 해 봅시다. 다시 접속하면 마을로 돌아오지만 보스 입장권은 사라집니다. 게임은 계속할 수 있지만 재화 손실이 있으므로, 우회 방법이 있어도 높음 이상으로 보는 것이 합리적입니다.
또 다른 예로, 설정 메뉴에서 언어를 바꾸면 일부 버튼 글자가 칸을 넘어 잘리는 버그가 있습니다. 기능은 동작하지만 무엇을 누르는 버튼인지 알 수 없다면 보통, 글자가 조금 잘려도 읽을 수 있다면 낮음으로 나눌 수 있습니다. 같은 현상이라도 유저가 얼마나 곤란해지는지에 따라 등급이 달라집니다.
판단이 정말 어렵다면 혼자 결정하지 말고 근거와 함께 두 가지 등급 후보를 적어 리더에게 묻는 것이 좋습니다. 이런 논의가 쌓이면 팀의 기준표에 새 예시로 추가되어 다음 사람의 판단을 돕습니다.
리포트에 심각도 근거를 적는 법
등급만 적고 근거를 쓰지 않으면, 읽는 사람은 왜 그 등급인지 다시 확인해야 합니다. 리포트의 현상 설명 아래에 '영향' 항목을 따로 두고 한두 문장으로 적어 두면 좋습니다. '보스 입장권 1장이 소모된 채 마을로 돌아옴, 유저가 다시 얻으려면 하루를 기다려야 함'처럼 유저 입장의 피해를 쓰는 것이 핵심입니다.
영향받는 범위도 함께 적습니다. 모든 기기에서 생기는지, 특정 운영체제나 해상도에서만 생기는지, 신규 계정에서만 생기는지를 구분해 두면 개발자가 원인을 좁히기 쉽고, 우선순위를 정하는 사람도 피해 규모를 가늠할 수 있습니다.
근거를 쓰는 습관은 면접에서도 강점이 됩니다. 버그를 찾는 것보다 그 버그가 왜 중요한지 설명하는 능력이 QA의 실력을 보여 주기 때문입니다.
팀 기준을 맞추고 유지하는 방법
- 등급마다 실제로 있었던 버그 예시를 두세 개씩 기준표에 붙여 둡니다.
- 새 테스터가 들어오면 지난 버그 목록을 함께 분류해 보는 시간을 갖습니다.
- 등급을 바꿀 때는 이유를 버그 리포트에 댓글로 남깁니다.
- 프로젝트 단계가 바뀌면(개발 초기, 출시 직전, 라이브) 기준을 다시 점검합니다.
마지막 항목이 특히 중요합니다. 개발 초기에는 그래픽 깨짐을 낮게 보던 팀도, 출시 직전에는 첫인상에 영향을 주는 표시 문제를 더 엄격하게 볼 수 있습니다. 기준표는 고정된 법이 아니라 프로젝트 상황에 맞춰 다듬는 약속입니다.
신입 QA가 심각도를 일관되게 매기면 버그 리포트의 신뢰도가 올라가고, 개발자와의 대화도 훨씬 매끄러워집니다. 연습 삼아 평소 즐기는 게임에서 발견한 문제를 기준표로 분류해 보세요. 내가 붙인 등급이 현업 감각과 얼마나 맞는지 궁금하다면, SBS아카데미게임학원 게임QA 과정 상담에서 분류해 본 버그 목록을 놓고 판단 근거를 함께 검토해 볼 수 있습니다.
자주 묻는 질문
버그 리포트에 심각도를 높게 써야 빨리 고쳐지지 않나요?
일부러 높게 쓰면 기준이 무너지고 QA 리포트 전체의 신뢰가 떨어집니다. 급하다고 생각되면 심각도는 정확히 매기고, 이유를 덧붙여 우선순위 조정을 요청하는 편이 맞습니다.
보안 문제나 핵 관련 버그는 어떤 등급인가요?
악용될 경우 재화나 공정성에 큰 피해가 생기므로 대개 가장 높은 등급으로 다루고, 공개 채널이 아닌 별도 경로로 보고하는 경우가 많습니다.
가까운 캠퍼스에서 게임 QA 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.