게임아카데미게임·웹툰·AI 진로 상담
테스트 케이스는 QA의 설계도입니다. 기능 하나를 확인하더라도 정상적인 사용, 경계값, 잘못된 입력, 다른 기능과의 충돌까지 빠짐없이 따져야 합니다. 수업에서…
빌드 버전과 테스트 환경
게임은 개발 중에 하루에도 여러 번 새 빌드가 나옵니다. 어제 빌드에서 생긴 버그가 오늘 빌드에서는 이미 고쳐졌을 수도 있고, 반대로 새로 생겼을 수도 있습니다. 빌드 버전이 없으면 개발자는 어느 코드에서 문제를 찾아야 할지 알 수 없습니다.
환경 정보도 같은 이유로 중요합니다. 모바일 게임이라면 기기 모델, 운영체제 버전, 화면 해상도, 네트워크 종류에 따라 결과가 달라질 수 있습니다. PC 게임이라면 그래픽 카드와 드라이버, 해상도와 창 모드 설정이 원인이 되는 경우가 많습니다. 리포트 양식에 이 칸이 따로 있다면 비워 두지 말고, 양식이 없다면 리포트 첫 부분에 정리하세요. 여러 기기에서 테스트했다면 버그가 난 기기와 나지 않은 기기를 함께 적는 것이 좋습니다. 특정 기기에서만 생기는 문제인지 모든 기기의 문제인지가 바로 구분되기 때문입니다.
서버가 있는 게임이라면 어느 서버에서, 어떤 계정으로 테스트했는지도 적습니다. 개발자가 서버 기록을 찾아볼 때 결정적인 단서가 됩니다.
전제 조건: 버그가 나기 전 상태
같은 행동을 해도 캐릭터 상태에 따라 버그가 생기기도 하고 안 생기기도 합니다. 특정 레벨 이상일 때, 특정 아이템을 장착했을 때, 퀘스트를 어느 단계까지 진행했을 때만 나타나는 버그가 많습니다. 이런 전제 조건을 빼먹으면 개발자는 처음부터 다른 상태로 테스트하게 되고, 버그를 재현하지 못합니다.
- 계정과 캐릭터의 레벨, 직업, 진행 단계
- 장착한 장비, 보유한 재화나 아이템 상태
- 게임 설정(언어, 그래픽 옵션, 조작 방식)
- 버그 직전에 했던 행동(로그인 직후, 다른 화면에서 돌아온 직후 등)
모든 정보를 다 적을 필요는 없지만, 버그와 관련 있어 보이는 상태는 꼭 적어야 합니다. 어떤 상태가 관련 있는지 모르겠다면 조건을 하나씩 바꿔 가며 다시 시도해 보세요. 그 과정에서 원인에 가까운 조건이 드러납니다. 찾은 조건은 리포트에 '이 조건에서는 발생하지 않음'처럼 함께 남겨 두세요.
재현 단계는 그대로 따라 할 수 있게
'상점에서 아이템을 사면 오류가 남'처럼 한 줄로 쓰면 어느 상점인지, 어떤 아이템인지, 어떤 방법으로 샀는지 알 수 없습니다. 재현 단계는 처음 게임을 켠 사람도 따라 할 수 있도록 번호를 붙여 순서대로 씁니다.
- 한 단계에 한 가지 행동만 적기
- 메뉴와 버튼 이름은 게임 화면에 보이는 그대로 적기
- 어디서 시작하는지 첫 단계에 분명히 밝히기
- 마지막 단계 뒤에 실제로 일어난 현상 적기
- 쓴 단계대로 직접 한 번 더 따라 해서 확인하기
마지막 항목이 특히 중요합니다. 기억에 의존해 쓴 단계는 중간 행동이 빠져 있는 경우가 많습니다. 쓴 순서대로 다시 해 보고 같은 버그가 나오는지 확인한 뒤 제출하세요.
재현율, 기대 결과, 실제 결과
재현율은 같은 단계를 반복했을 때 버그가 얼마나 자주 나오는지를 말합니다. 매번 나오는 버그와 열 번에 한 번 나오는 버그는 원인을 찾는 방법이 다릅니다. 시도한 횟수와 그중 버그가 난 횟수를 함께 적으면 개발자가 우선순위와 조사 방법을 정하기 쉬워집니다.
기대 결과와 실제 결과를 나눠 쓰는 것도 자주 빠집니다. '체력이 이상함'이라고만 쓰면 무엇이 정상인지 알 수 없습니다. '기대 결과: 포션 사용 시 체력이 회복되어야 함, 실제 결과: 포션이 사라지고 체력은 그대로임'처럼 나눠 쓰면 문제가 정확히 전달됩니다. 기대 결과의 근거가 기획서라면 해당 문서나 항목을 함께 적어 두세요. 기획 의도와 다른 것인지, 기획 자체가 빠진 것인지 판단하는 데 도움이 됩니다.
발생 시각, 첨부 자료, 제목
버그가 생긴 시각을 적어 두면 개발자가 서버 기록과 로그에서 그 순간을 바로 찾을 수 있습니다. 시각이 없으면 많은 기록을 뒤져야 합니다. 영상과 스크린샷도 큰 도움이 됩니다. 버그 직전부터 녹화된 짧은 영상은 글로 설명하기 어려운 순서와 타이밍을 한 번에 보여 줍니다. 로그 파일을 뽑을 수 있는 환경이라면 함께 첨부합니다.
| 항목 | 빠졌을 때 생기는 일 |
|---|---|
| 제목 | 목록에서 어떤 버그인지 알 수 없어 중복 리포트가 늘어남 |
| 빌드와 환경 | 다른 빌드에서 확인하다 재현 실패 |
| 재현 단계 | 확인 요청이 되돌아와 처리가 늦어지고 담당자 사이 대화가 길어짐 |
| 재현율 | 우선순위와 조사 방법을 정하기 어려움 |
| 첨부 자료 | 현상을 글로만 짐작해야 함 |
제목은 '어디에서, 무엇을 할 때, 어떤 문제가 생기는지'를 한 줄로 담습니다. 리포트 하나에는 버그 하나만 적는 것이 원칙입니다. 등록 전에는 같은 버그가 이미 올라와 있는지 검색해 중복을 줄이세요.
포트폴리오에서도 리포트 품질이 실력입니다
QA 직무 지원자에게 버그 리포트 샘플은 가장 직접적인 실력 증명입니다. 출시된 게임이나 직접 테스트한 게임에서 찾은 버그를 위의 항목을 갖춘 리포트로 정리해 두면, 면접에서도 구체적인 이야기를 할 수 있습니다. 버그를 찾은 과정, 즉 어떤 생각으로 그 조건을 시험해 봤는지를 함께 적으면 테스트 설계 능력까지 보여 줄 수 있습니다. 다만 회사 내부 자료나 비공개 테스트 내용은 공개하지 않도록 주의하세요.
내가 쓴 리포트에서 무엇이 부족한지 스스로 판단하기 어렵다면, SBS아카데미게임학원 게임QA 과정 상담에서 직접 작성한 리포트를 가져와 빠진 정보와 표현 방식을 함께 점검해 보세요.
자주 묻는 질문
심각도와 우선순위는 QA가 정하나요?
회사마다 다르지만 QA가 심각도를 먼저 제안하고, 우선순위는 개발 일정과 함께 팀이 정하는 경우가 많습니다. 어떤 기준으로 심각도를 정했는지 근거를 함께 적으면 협의가 쉬워집니다.
재현이 안 되는 버그도 리포트해야 하나요?
리포트하는 편이 좋습니다. 재현되지 않았다는 사실과 시도한 조건, 발생 시각, 남아 있는 영상이나 로그를 함께 적으면 나중에 같은 현상이 생겼을 때 원인을 찾는 단서가 됩니다.
가까운 캠퍼스에서 게임 QA 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.