게임 QA 테스터 포트폴리오에는 그림도, 코드도 없어 무엇을 넣어야 할지 막막하다는 이야기를 많이 듣습니다. QA의 결과물은 문서입니다. 어떤 게임을 어떤 계획으로 테스트했고, 무엇을 찾았고, 그것을 어떻게 전달했는지를 문서로 보여 주는 것이 핵심입니다.

QA 포트폴리오의 기본 구성

하나의 게임을 대상으로 이 네 문서를 연결해 보여 주면, 테스트의 처음부터 끝까지를 경험했다는 점이 분명하게 드러납니다.

문서 앞쪽에는 포트폴리오 전체를 한눈에 볼 수 있는 요약 페이지를 두면 좋습니다. 대상 게임, 테스트 기간, 작성한 테스트 케이스와 리포트의 수, 주요 발견 사항을 한 페이지에 정리하면 읽는 사람이 어디부터 볼지 쉽게 정할 수 있습니다.

어떤 게임을 대상으로 할까

이미 출시된 게임을 대상으로 하는 경우가 많습니다. 지원하는 회사의 게임이나 비슷한 장르의 게임을 고르면 관심과 이해도를 함께 보여 줄 수 있습니다. 팀 프로젝트나 인디 게임 테스트에 참여했다면 개발 중인 빌드를 테스트한 경험이므로 더 실무에 가까운 자료가 됩니다.

게임 전체를 다루기보다 상점, 우편함, 강화, 튜토리얼처럼 기능 하나를 정해 깊이 있게 테스트하는 편이 완성도 높은 문서를 만들기 좋습니다. 출시된 게임에서 발견한 문제를 공개할 때는 악용될 수 있는 내용(결제 우회, 아이템 복사 등)은 상세 재현 방법을 빼는 등 주의가 필요합니다.

테스트 케이스 문서 작성 요령

• 항목마다 번호를 붙이고, 한 항목에는 한 가지 확인만 담습니다.
• 사전 조건(어떤 상태에서 시작하는지)을 적습니다.
• 정상 동작뿐 아니라 경계값, 예외 상황 항목도 포함합니다.
• 결과 칸에 통과, 실패, 보류를 기록하고 실패 항목은 버그 리포트 번호와 연결합니다.

테스트 케이스가 많을수록 좋은 것은 아닙니다. 기능의 핵심을 빠짐없이 다루면서도 중복이 없는지가 중요합니다. 항목을 분류해 정리하면 읽는 사람이 구조를 쉽게 파악할 수 있습니다.

버그 리포트 예시 고르기

포트폴리오에는 직접 작성한 리포트 가운데 성격이 다른 예시 몇 개를 골라 넣습니다. 화면 표시 오류, 기능 오류, 진행 불가 오류처럼 종류와 심각도가 다른 사례를 고르면 판단 범위가 넓다는 점을 보여 줄 수 있습니다.

각 리포트에는 스크린샷이나 짧은 영상을 첨부하고, 심각도를 어떻게 판단했는지 한 줄로 덧붙입니다. 재현이 어려운 버그를 여러 번 시도해 재현 조건을 좁혀 간 과정이 있다면 따로 설명하면 좋습니다. 끈기와 분석력을 동시에 보여 주는 사례가 됩니다.

결과 분석 보고서

테스트를 마친 뒤 결과를 정리한 보고서는 QA 포트폴리오에서 차별점을 만드는 부분입니다. 발견한 버그를 기능별, 심각도별로 분류해 표나 그래프로 보여 주고, 어떤 영역에 문제가 몰려 있었는지, 그 원인이 무엇으로 보이는지를 정리합니다.

마지막에 개선 제안을 덧붙이면 단순히 버그를 찾는 사람이 아니라 품질을 함께 고민하는 사람이라는 인상을 줄 수 있습니다. 예를 들어 '튜토리얼 안내 문구가 실제 버튼 위치와 달라 혼란을 줄 수 있다'처럼 사용성 관점의 제안도 좋습니다.

제출 전 점검

• 문서 사이 번호와 참조가 서로 맞는가
• 맞춤법과 용어가 일관되게 쓰였는가
• 스크린샷과 영상이 선명하고 문제 지점이 표시되어 있는가
• 악용 가능한 상세 정보가 공개되지 않았는가

SBS아카데미게임학원 게임QA 과정은 실제 게임 빌드를 활용한 테스트 환경 운영, 테스트 리포트 작성, QA 분석 포트폴리오 제작 단계를 두고 있어 이 글의 문서 구성을 직접 만들어 볼 수 있습니다.

자주 묻는 질문