게임아카데미게임·웹툰·AI 진로 상담
QA의 핵심 결과물은 버그 리포트입니다. 어떤 상황에서, 어떤 순서로 했을 때, 무엇이 기대와 다르게 나왔는지 누구나 다시 재현할 수 있게 써야 합니다. 수업…
QA 면접에서 '게임을 좋아한다'만으로 부족한 이유
게임 QA를 지원하는 많은 사람이 게임을 많이 해 왔다는 점을 강점으로 내세웁니다. 물론 다양한 게임 경험은 도움이 됩니다. 하지만 QA는 게임을 즐기는 일이 아니라, 같은 기능을 수없이 반복하며 정해진 기준과 다르게 동작하는 지점을 찾고 기록하는 일입니다. 면접관은 이 차이를 지원자가 알고 있는지 확인하고 싶어 합니다.
그래서 '왜 QA를 지원했나요'라는 질문에는 게임을 좋아한다는 이야기에서 멈추지 말고, 게임을 하며 버그를 발견하고 기록해 본 경험, 문제가 왜 생겼을지 추측해 본 경험처럼 QA 업무와 이어지는 장면을 말하는 것이 좋습니다. 반복 작업에 대해 어떻게 생각하는지 묻는 질문에도 솔직하게, 반복 속에서 작은 차이를 찾는 일에 흥미를 느끼는 이유를 구체적으로 말하면 됩니다.
버그 리포트에 대한 질문
'버그 리포트를 쓸 때 무엇을 넣나요'는 거의 반드시 나오는 질문입니다. 면접관이 즉석에서 화면이나 상황을 보여 주고 리포트를 말로 작성해 보라고 하는 경우도 있습니다.
| 항목 | 담을 내용 |
|---|---|
| 제목 | 어디서 무엇이 어떻게 잘못되는지 한 줄 |
| 환경 | 기기, 운영체제, 빌드 버전, 계정 상태 |
| 재현 단계 | 누구나 따라 할 수 있는 순서대로 번호를 붙여 |
| 기대 결과 | 기획 의도나 정상 동작 |
| 실제 결과 | 실제로 일어난 일 |
| 재현율과 첨부 | 몇 번 중 몇 번 발생했는지, 스크린샷이나 영상 |
답변 방향은 항목을 나열하는 데서 끝내지 않고, 각 항목이 왜 필요한지까지 말하는 것입니다. 재현 단계가 모호하면 개발자가 같은 현상을 만들지 못해 수정이 늦어지고, 빌드 버전이 빠지면 이미 고쳐진 버그를 다시 확인하느라 시간을 쓰게 됩니다. 제목만 봐도 문제를 짐작할 수 있게 쓰는 것이 왜 중요한지도 함께 설명하면 좋습니다.
심각도와 테스트 범위에 대한 질문
'이 버그의 심각도를 어떻게 판단하겠나요'라는 질문에는 판단 기준을 말해야 합니다. 게임이 멈추거나 진행이 불가능한지, 유저의 재화나 데이터에 손실이 생기는지, 많은 유저가 겪는지, 우회 방법이 있는지, 단순히 보기 불편한 수준인지 같은 기준입니다. 같은 오타라도 결제 화면의 가격 표시라면 심각도가 높아질 수 있다는 식으로, 위치와 영향에 따라 판단이 달라진다는 점을 보여 주면 좋습니다.
'이 기능을 테스트한다면 무엇을 확인하겠나요'라는 질문도 자주 나옵니다. 예를 들어 상점 구매 기능이라면 정상 구매뿐 아니라 재화가 부족할 때, 인벤토리가 가득 찼을 때, 구매 버튼을 빠르게 여러 번 눌렀을 때, 구매 도중 네트워크가 끊겼을 때 같은 경계 상황과 예외 상황을 함께 떠올리는 것이 중요합니다. 정상 경로, 경계값, 예외 상황으로 나눠 말하면 체계적으로 생각한다는 인상을 줍니다. 여러 기기에서 확인해야 하는 이유도 함께 말할 수 있으면 좋습니다.
재현이 안 되는 버그와 소통에 대한 질문
- 한 번 발생했는데 다시 재현되지 않는 버그는 어떻게 하나요?
- 개발자가 버그가 아니라고 하면 어떻게 대응하나요?
- 출시 일정이 촉박해 모든 버그를 확인할 수 없을 때는요?
- 수정된 버그를 확인할 때 무엇을 함께 보나요?
재현이 안 되는 버그는 발생 당시의 상황을 최대한 기록하고, 조건을 하나씩 바꿔 가며 재현을 시도한다고 답하면 됩니다. 재현하지 못했더라도 기록과 함께 공유해 비슷한 현상이 다시 보이면 연결할 수 있게 한다는 점도 덧붙이세요. 개발자와 의견이 다를 때는 기획 문서나 기준을 근거로 함께 확인하고, 판단이 어렵다면 기획자에게 의도를 확인한다는 순서를 말하면 됩니다. 일정이 촉박할 때는 심각도가 높은 버그와 핵심 기능부터 확인하는 우선순위 기준을 말하세요.
수정 확인 질문에는 해당 버그만 보는 것이 아니라 관련된 기능에 새 문제가 생기지 않았는지 함께 확인하는 회귀 테스트를 언급하는 것이 좋습니다. 이 개념을 알고 있다는 것만으로도 QA 업무를 이해하고 있다는 신호가 됩니다.
피해야 할 답변
'버그를 찾으면 바로 개발자에게 말하면 돼요'처럼 기록과 절차 없이 전달하겠다는 답은 피해야 합니다. QA의 결과물은 결국 기록이기 때문입니다. '게임을 오래 하는 건 자신 있어요'도 좋은 답이 아닙니다. 오래 하는 것보다 정해진 기준으로 꼼꼼하게 보는 것이 중요합니다. 개발자와의 갈등 질문에 '제가 맞으면 끝까지 주장하겠다'고 답하는 것도 협업 태도에서 좋지 않은 인상을 줄 수 있습니다.
QA를 기획자나 개발자로 가기 위한 잠시 거쳐 가는 자리로만 표현하는 것도 조심하세요. 장기적인 목표를 솔직하게 말하는 것은 괜찮지만, 지금 지원한 QA 업무에서 무엇을 배우고 기여하고 싶은지가 먼저 나와야 합니다.
면접 전에 직접 리포트를 써 보기
면접 전에 즐겨 하는 게임에서 버그나 어색한 동작을 몇 개 찾아, 위 항목대로 리포트를 직접 써 보세요. 간단한 기능 하나를 골라 테스트 케이스를 정상, 경계, 예외로 나눠 정리해 보는 것도 좋습니다. 이 자료를 포트폴리오로 정리해 가져가면 면접에서 말로만 설명하는 것보다 훨씬 설득력이 생깁니다.
내가 쓴 버그 리포트와 테스트 케이스가 실무 기준에서 충분히 정확한지 확인하고 싶다면, SBS아카데미게임학원 게임QA 과정 상담에서 작성한 자료를 함께 보며 면접 전에 다듬을 부분을 정리할 수 있습니다.
자주 묻는 질문
QA 면접에서 실기 테스트를 보기도 하나요?
회사에 따라 실제 게임이나 빌드를 주고 정해진 시간 동안 버그를 찾아 리포트를 쓰게 하는 경우가 있습니다. 평소 리포트 양식에 맞춰 빠르게 쓰는 연습을 해 두면 좋습니다.
프로그래밍을 몰라도 QA 면접을 볼 수 있나요?
수동 테스트 중심의 직무라면 필수는 아닙니다. 다만 자동화 테스트나 로그 확인에 관심이 있다는 점을 보여 주면 성장 가능성으로 평가받을 수 있습니다.
가까운 캠퍼스에서 게임 QA 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.