게임 QA 포트폴리오에서 자주 보이는 실수 7가지

이 글과 연결된 과정게임 QA 과정 알아보기

최근에는 반복 테스트를 자동화 도구로 처리하는 회사가 늘고 있습니다. 수업에서는 수동 테스트 기본기를 충분히 다진 뒤, 자동화 도구로 반복 작업을 줄이는 기초…

실수 1: 플레이 경력만 있고 검증 결과물이 없다

첫 번째 실수는 포트폴리오를 플레이한 게임 목록과 플레이 시간, 랭킹 기록으로 채우는 것입니다. 게임을 깊이 해 본 경험은 분명 도움이 되지만, 그것만으로는 테스트를 설계하고 문제를 기록할 수 있는 사람인지 알 수 없습니다. 평가자에게 필요한 것은 그 경험을 품질 검증으로 바꾼 결과물입니다.

고치는 방법은 게임 하나를 정해 직접 테스트한 기록을 만드는 것입니다. 테스트할 기능을 고르고, 테스트 케이스를 작성하고, 실행한 결과와 발견한 문제를 버그 리포트로 정리하세요. 이 흐름 하나가 플레이 경력 열 줄보다 QA 역량을 훨씬 분명하게 보여 줍니다. 플레이 경험은 자기소개서에서 짧게 언급하면 충분합니다.

실수 2·3: 재현이 안 되는 리포트, 구분 없는 심각도

두 번째 실수는 버그 리포트에 재현 절차가 분명하지 않은 것입니다. '전투 중에 가끔 캐릭터가 멈춤'처럼 쓰면 개발자는 언제, 어떤 조건에서 문제가 생기는지 알 수 없어 다시 물어봐야 합니다. 좋은 버그 리포트는 처음 보는 사람이 그대로 따라 했을 때 같은 문제를 볼 수 있어야 합니다.

리포트마다 테스트 환경, 사전 조건, 재현 단계, 기대 결과, 실제 결과, 재현 빈도를 나눠 적으세요. 재현 단계는 번호를 붙여 한 줄에 행동 하나씩 쓰는 것이 좋습니다. 가끔 생기는 문제라면 몇 번 시도해 몇 번 재현되었는지도 함께 적어야 합니다.

세 번째 실수는 모든 버그를 같은 무게로 다루는 것입니다. 게임이 강제로 종료되는 문제와 글자 하나가 잘못된 문제는 처리해야 할 순서가 다릅니다. 심각도와 우선순위를 구분해 표시하고, 왜 그 등급을 매겼는지 짧은 근거를 붙이면 문제의 영향을 판단할 줄 아는 지원자로 보입니다.

실수 4: 정상적인 경로만 테스트했다

네 번째 실수는 테스트 케이스가 기능이 원래 의도대로 쓰이는 경우만 다루는 것입니다. 예를 들어 상점에서 아이템을 사는 기능을 테스트할 때 재화가 충분한 상태에서 한 개를 사는 경우만 확인하는 식입니다. 실제 버그는 재화가 딱 모자랄 때, 가방이 가득 찼을 때, 구매 버튼을 빠르게 여러 번 눌렀을 때처럼 경계와 예외에서 많이 나옵니다.

• 값이 최솟값, 최댓값, 그 바로 바깥일 때
• 필요한 조건이 하나만 빠졌을 때
• 같은 행동을 빠르게 반복하거나 동시에 했을 때
• 진행 중에 네트워크가 끊기거나 앱이 백그라운드로 갔을 때
• 다른 기능과 겹쳐서 실행될 때

테스트 케이스를 쓸 때 이런 관점을 기능마다 하나씩 대입해 보세요. 정상 경로와 예외 경로가 균형 있게 들어간 케이스 목록은 평가자에게 테스트 설계 능력을 보여 주는 가장 좋은 자료입니다.

실수 5·6: 근거 자료가 없고 개수만 강조했다

다섯 번째 실수는 버그 리포트에 스크린샷이나 영상 같은 근거 자료가 없는 것입니다. 글로만 설명된 문제는 개발자가 상황을 파악하는 데 시간이 걸립니다. 문제가 생긴 순간의 화면, 재현 과정을 담은 짧은 영상, 사용한 기기와 버전 정보를 함께 첨부하는 습관이 필요합니다.

여섯 번째 실수는 찾은 버그의 개수를 강조하는 것입니다. 백 개를 찾았다는 숫자보다, 그중 영향이 큰 문제를 얼마나 정확하게 기록했는지가 더 중요합니다. 비슷한 문제를 여러 개로 나눠 적었거나, 이미 알려진 문제를 다시 적은 리포트가 섞여 있다면 오히려 정리 능력이 부족해 보일 수 있습니다. 대표 리포트 몇 개를 골라 완성도 있게 보여 주는 편이 좋습니다.

같은 버그라도 이렇게 쓰면 달라진다

앞의 실수들을 고치면 버그 리포트가 어떻게 바뀌는지 항목별로 비교해 보면 이해가 쉽습니다. 아래는 상점 구매 기능에서 생긴 문제를 두 가지 방식으로 기록했을 때의 차이입니다.

다듬은 리포트는 길어 보이지만, 개발자가 다시 묻지 않고 바로 확인할 수 있어 전체 작업 시간은 오히려 줄어듭니다. 포트폴리오에 이런 비교를 직접 넣어 두는 것도 리포트 작성 기준을 이해하고 있다는 좋은 증거가 됩니다.

실수 7: 발견만 하고 분석은 없다

일곱 번째 실수는 버그를 나열하는 데서 멈추는 것입니다. 실무 QA는 문제를 찾는 것뿐 아니라 어떤 영역에 문제가 몰려 있는지, 어떤 유형의 버그가 자주 생기는지 분석해 개발팀에 전달하는 역할도 합니다. 이런 분석은 다음 테스트에서 어디를 더 집중해서 볼지 정하는 근거가 됩니다.

포트폴리오 마지막에 테스트 결과 요약을 한 장 넣어 보세요. 테스트한 범위, 발견한 문제의 영역별 분포, 가장 위험하다고 판단한 부분, 다음 테스트에서 집중할 부분을 정리하면 됩니다. 이 한 장이 단순히 버그를 찾는 사람이 아니라 품질을 관리하는 사람으로 보이게 해 줍니다.

지금 쓴 버그 리포트와 테스트 케이스가 실무 기준에서 어떻게 읽힐지 확인하고 싶다면, SBS아카데미게임학원 게임QA 과정 상담에서 리포트 구성과 테스트 설계 방향을 함께 점검해 보세요.

자주 묻는 질문

가까운 캠퍼스에서 게임 QA 알아보기

사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.

함께 읽으면 좋은 글