최근에는 반복 테스트를 자동화 도구로 처리하는 회사가 늘고 있습니다. 수업에서는 수동 테스트 기본기를 충분히 다진 뒤, 자동화 도구로 반복 작업을 줄이는 기초…
연습 대상은 기능 하나로 좁힙니다
게임 전체를 테스트하겠다고 시작하면 무엇부터 해야 할지 몰라 결국 아무 데나 눌러 보는 것으로 끝납니다. 대신 우편함, 친구 추가, 상점 구매, 옵션 설정, 인벤토리 정렬처럼 화면 한두 개로 끝나는 기능 하나를 고르세요. 범위가 작을수록 정상 동작, 경계값, 예외 상황을 빠짐없이 다뤄 볼 수 있습니다.
처음에는 실제 재화가 들지 않는 기능을 고르는 것이 좋습니다. 옵션 설정은 특히 좋은 첫 연습 대상입니다. 음량, 화질, 언어, 조작 설정처럼 바꿀 수 있는 값이 많고, 바꾼 값이 저장되는지, 다시 실행해도 유지되는지 등 확인할 것이 분명하기 때문입니다. 익숙해지면 여러 기능이 얽힌 우편함이나 상점으로 넓혀 갑니다.
테스트 케이스는 이 칸들로 씁니다
| 칸 | 적는 내용 |
|---|---|
| 번호와 분류 | 기능 이름과 순번, 정상·경계·예외 구분 |
| 사전 조건 | 테스트를 시작하기 전 필요한 상태(로그인, 보유 아이템 등) |
| 절차 | 누가 해도 똑같이 할 수 있도록 번호 붙인 단계 |
| 기대 결과 | 기획 의도대로라면 나와야 할 결과 |
| 실제 결과 | 직접 해 본 결과 |
| 판정과 비고 | 통과, 실패, 확인 불가와 그 이유 |
가장 신경 써야 할 칸은 절차와 기대 결과입니다. '설정을 바꾼다'처럼 모호하게 쓰면 사람마다 다르게 실행합니다. '옵션 화면에서 배경음 막대를 가장 왼쪽으로 옮긴 뒤 닫기 버튼을 누른다'처럼 구체적으로 씁니다. 출시 게임은 기획서를 볼 수 없으니, 기대 결과는 게임 안의 안내 문구나 공지, 일반적인 사용 경험을 근거로 추론해서 적고 근거를 비고에 남깁니다.
정상, 경계, 예외 상황을 고루 만듭니다
초보가 쓴 테스트 케이스는 대부분 정상 동작만 확인합니다. 버튼을 누르면 창이 열리는지, 아이템을 사면 인벤토리에 들어오는지 같은 것입니다. 실무에서 버그가 많이 나오는 곳은 그 바깥입니다. 값의 가장 작은 끝과 가장 큰 끝, 그 바로 안쪽과 바깥쪽을 확인하는 경계값 테스트를 꼭 넣으세요.
- 경계값: 인벤토리가 한 칸 남았을 때, 꽉 찼을 때 아이템 받기
- 입력 예외: 닉네임에 허용되지 않는 문자나 아주 긴 글자 넣기
- 순서 예외: 구매 버튼을 빠르게 여러 번 누르기
- 환경 예외: 진행 중 네트워크가 끊기거나 앱을 내렸다 올리기
- 상태 예외: 같은 계정으로 다른 기기에서 동시에 같은 기능 쓰기
예외 케이스를 생각할 때는 플레이어가 실수할 만한 행동과, 의도적으로 이상하게 쓰는 행동을 함께 떠올려 보세요. 같은 입력을 성격별로 묶어 대표 값 하나씩만 확인하는 방법(동등 분할)도 함께 쓰면 케이스 수가 지나치게 늘어나지 않습니다.
실행하고 기록하는 방법
케이스를 다 쓴 뒤에 실행합니다. 쓰면서 바로 실행하면 이미 본 결과에 맞춰 기대 결과를 쓰게 되기 쉽습니다. 실행할 때는 기기 종류, 운영체제, 게임 버전, 네트워크 환경을 기록해 두세요. 같은 케이스라도 환경에 따라 결과가 달라질 수 있기 때문입니다. 실패한 케이스는 화면 녹화나 캡처를 함께 남깁니다.
문제를 찾았다면 버그 보고서 형식으로 한 번 정리해 봅니다. 제목만 보고 무슨 문제인지 알 수 있게 쓰고, 재현 절차, 기대 결과와 실제 결과, 발생 빈도, 심각도를 적습니다. 한 번만 일어난 현상이라도 같은 절차로 여러 번 다시 해 보고 몇 번 중 몇 번 일어났는지 적는 것이 중요합니다. 재현 절차가 정확할수록 좋은 보고서입니다. 감정이 섞인 표현이나 추측은 빼고, 본 것만 사실대로 적는 연습도 함께 하세요. 읽는 사람은 개발자라는 점을 기억하면 됩니다.
연습 결과를 정리할 때는 통과한 케이스와 실패한 케이스의 비율보다, 어떤 관점으로 케이스를 설계했는지가 더 중요합니다. 분류별로 케이스가 고르게 들어갔는지 마지막에 한 번 훑어보세요.
기능 하나를 일주일에 끝내는 루틴 예시
- 첫날: 기능을 자유롭게 써 보며 화면과 버튼, 값의 범위를 메모
- 둘째 날: 정상 동작 케이스 작성
- 셋째 날: 경계값과 예외 케이스 작성
- 넷째 날: 모든 케이스 실행과 결과 기록
- 다섯째 날: 실패 케이스 재확인과 버그 보고서 정리
- 주말: 빠진 관점이 없는지 훑어보고 다음 주 기능 고르기
첫날의 자유 탐색은 생각보다 중요합니다. 기능을 충분히 이해하지 못한 채 케이스를 쓰면 정작 중요한 분기를 놓칩니다. 버튼 하나를 눌렀을 때 나올 수 있는 모든 결과를 메모해 두면, 둘째 날과 셋째 날 케이스를 쓰는 속도가 크게 빨라집니다. 기능을 바꿔 가며 몇 주 반복하면 케이스를 떠올리는 관점이 점점 넓어지는 것을 느낄 수 있습니다.
연습할 때 지켜야 할 선
출시 게임으로 연습할 때는 이용 약관을 지키는 것이 기본입니다. 서버에 부담을 주는 반복 요청, 다른 플레이어에게 피해를 주는 행동, 외부 프로그램을 쓰는 테스트는 하지 않습니다. 재화가 복사되거나 결제와 관련된 심각한 문제를 발견했다면 그 방법을 공개하지 말고, 게임의 공식 고객 문의 창구로 알리는 것이 올바른 방법입니다.
포트폴리오에 넣을 때도 발견한 문제를 악용할 수 있는 방식으로 쓰지 않아야 합니다. 대신 어떤 기능을 어떤 관점으로 테스트했는지, 케이스를 어떻게 분류했는지를 보여 주면 충분합니다. 몇 개 기능으로 연습한 케이스 문서가 실무 QA 기준에 맞는지 확인하고 싶다면, SBS아카데미게임학원 게임QA 과정 상담에서 작성한 문서를 함께 보며 보완점을 짚어 볼 수 있습니다.
자주 묻는 질문
테스트 케이스는 어떤 프로그램으로 쓰나요?
연습할 때는 엑셀이나 구글 스프레드시트로 충분합니다. 회사에서는 테스트 관리 도구를 쓰는 경우도 많지만, 칸 구성의 원리는 비슷합니다.
버그를 찾지 못하면 연습이 실패한 건가요?
아닙니다. 출시 게임은 이미 많은 테스트를 거쳤기 때문에 버그가 적은 것이 정상입니다. 케이스를 빠짐없이 설계하고 실행한 과정 자체가 연습의 결과입니다.
가까운 캠퍼스에서 게임 QA 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.