QA는 개발 과정 전체를 가장 가까이에서 보는 직무라 기획, PM, 라이브 운영으로 진로를 넓히는 경우가 많습니다. 수업에서는 QA 실무와 함께 기획 문서 구…
고쳤는데 다른 곳이 깨지는 이유
게임의 여러 기능은 공통 코드와 공통 데이터를 나눠 씁니다. 예를 들어 데미지 계산 함수 하나를 일반 공격, 스킬, 함정, 펫이 모두 함께 쓰고 있다면, 스킬 버그를 고치려고 그 함수를 바꾼 순간 함정 데미지도 달라질 수 있습니다. 수정한 사람은 스킬만 확인하고 넘어가기 쉬워서, 이런 문제는 QA가 의도적으로 찾아야 드러납니다.
데이터 수정도 마찬가지입니다. 아이템 테이블에 새 줄을 추가하다 번호가 밀리면 기존 아이템의 아이콘이나 효과가 바뀌는 일이 생깁니다. 엔진이나 외부 라이브러리 버전을 올렸을 때도 예상치 못한 화면 깨짐이 생기곤 합니다.
회귀라는 말은 '되돌아간다'는 뜻입니다. 고쳤던 버그가 다시 살아나는 경우도 회귀에 포함됩니다. 그래서 회귀 테스트에는 기존 핵심 기능 확인과 함께, 과거에 고친 주요 버그가 다시 나타나지 않았는지 확인하는 항목도 들어갑니다.
회귀 테스트 묶음을 미리 나눠 두기
매번 회귀 대상을 처음부터 고르면 시간이 많이 들고 사람마다 결과가 달라집니다. 그래서 대부분의 팀은 크기가 다른 묶음, 흔히 테스트 스위트라고 부르는 목록을 미리 만들어 둡니다.
| 묶음 | 포함 내용 | 언제 돌리나 |
|---|---|---|
| 기본 점검 | 실행, 로그인, 튜토리얼 진입, 메인 화면, 저장·불러오기, 결제 화면 진입 | 모든 빌드마다 |
| 핵심 기능 | 전투, 성장, 상점, 우편, 친구, 주요 콘텐츠 한 바퀴 | 정기 업데이트 빌드 |
| 변경 영향 | 이번 수정과 연결된 기능 전체 | 해당 수정이 들어간 빌드 |
| 전체 회귀 | 모든 기능의 대표 케이스 | 대규모 업데이트, 엔진 교체, 출시 직전 |
기본 점검 묶음은 짧을수록 좋습니다. 빌드를 받자마자 짧은 시간 안에 돌려 '테스트를 계속할 만한 빌드인가'를 판단하는 용도라, 흔히 스모크 테스트라고도 부릅니다. 여기서 문제가 나오면 나머지 테스트를 멈추고 빌드를 다시 받는 것이 시간을 아끼는 길입니다.
각 묶음의 케이스에는 확인 방법과 기대 결과를 짧게 적어 둡니다. '상점 열기'만 적혀 있으면 사람마다 확인하는 깊이가 다르지만, '상점 열기, 첫 탭 상품 목록과 가격 표시, 구매 버튼 활성 확인'처럼 적혀 있으면 누가 돌려도 같은 결과가 나옵니다. 묶음별로 대략 걸리는 시간도 기록해 두면 일정 계산이 쉬워집니다.
이번 빌드의 회귀 범위를 정하는 순서
- 변경 목록을 받아 수정된 기능과 파일, 데이터 테이블을 확인합니다.
- 각 수정이 연결된 기능을 개발자와 함께 적어 '변경 영향' 묶음을 그때그때 만듭니다.
- 변경 규모를 보고 기본 점검, 핵심 기능, 전체 회귀 중 어디까지 돌릴지 정합니다.
- 과거에 같은 영역에서 고쳤던 주요 버그의 재발 확인 항목을 추가합니다.
- 인원과 시간에 맞춰 순서를 정하고, 위험도가 높은 묶음을 앞에 배치합니다.
- 결과를 기록하고, 새로 발견된 회귀 버그는 다음 묶음 개선에 반영합니다.
순서를 정할 때는 '가장 먼저 깨지면 곤란한 것'부터 보는 원칙을 지킵니다. 일정이 줄어들어 중간에 멈추더라도, 위험한 부분은 이미 확인된 상태가 되기 때문입니다.
버그 수정 확인과 회귀 확인은 함께 진행하는 경우가 많습니다. 고친 버그가 정말 사라졌는지 확인한 뒤, 같은 화면의 주변 기능까지 한 번 더 둘러보는 식입니다. 수정 확인만 하고 닫아 버리면 바로 옆에서 생긴 새 문제를 놓치기 쉽습니다.
회귀 묶음을 살아 있는 문서로 관리하기
회귀 묶음은 만들어 두면 끝이 아니라 계속 손봐야 합니다. 새 콘텐츠가 들어오면 그 콘텐츠의 핵심 케이스를 핵심 기능 묶음에 추가하고, 더 이상 쓰지 않는 기능의 케이스는 정리합니다. 묶음이 끝없이 길어지면 아무도 끝까지 돌리지 못하는 문서가 됩니다.
회귀 버그가 발견될 때마다 '이 버그를 미리 잡으려면 어떤 케이스가 있었어야 했나'를 묻는 것도 좋은 습관입니다. 그 답을 케이스로 추가하면 묶음이 점점 실제 위험에 맞게 다듬어집니다.
반복적으로 똑같이 돌리는 케이스는 자동화 후보입니다. 로그인, 기본 화면 진입, 상점 목록 표시처럼 결과가 분명한 항목은 자동화 테스트로 옮기고, 사람은 손맛이나 연출처럼 판단이 필요한 부분에 시간을 더 쓰는 방향이 일반적입니다.
회귀 테스트 계획에서 자주 하는 실수
- 변경이 작다는 말만 듣고 기본 점검까지 생략하는 경우
- 같은 테스터가 같은 순서로만 돌려 익숙한 경로 밖의 문제를 놓치는 경우
- 테스트한 빌드 번호를 기록하지 않아 어느 빌드에서 깨졌는지 추적이 안 되는 경우
- 통과한 항목은 기록하지 않고 실패만 적어 어디까지 확인했는지 알 수 없는 경우
특히 빌드 번호와 통과 기록은 사소해 보여도 중요합니다. 버그가 언제부터 생겼는지 알아야 어떤 수정이 원인인지 빠르게 찾을 수 있습니다. 담당자를 가끔 바꿔 돌리는 것도 같은 경로에 익숙해져 생기는 사각지대를 줄이는 방법입니다.
또 하나 흔한 실수는 회귀 시간을 일정에 넣지 않는 것입니다. 신규 기능 테스트만 계산하고 회귀를 남는 시간에 하려 하면, 출시 직전에 회귀 버그가 몰려 나옵니다. 계획 단계에서부터 회귀 묶음을 돌릴 시간을 따로 잡아 두세요.
연습 과제로는 좋아하는 모바일 게임 하나를 골라 기본 점검 묶음을 열 개 안팎의 항목으로 직접 만들어 보세요. 어떤 항목을 넣고 뺄지 고민하는 과정이 곧 회귀 계획 실력입니다. 만든 묶음을 포트폴리오 문서로 정리하는 방법까지 알고 싶다면, SBS아카데미게임학원 게임QA 과정 상담에서 테스트 문서 구성 방향을 문의해 보시면 됩니다.
자주 묻는 질문
회귀 테스트와 스모크 테스트는 같은 건가요?
스모크 테스트는 빌드가 기본적으로 돌아가는지 빠르게 보는 짧은 확인으로, 넓게 보면 회귀 테스트의 첫 단계에 해당합니다. 회귀 테스트는 그보다 범위가 넓습니다.
라이브 서비스 중인 게임은 회귀 테스트를 얼마나 자주 하나요?
업데이트 주기에 맞춰 반복합니다. 정기 업데이트마다 핵심 기능 묶음을, 긴급 수정에는 기본 점검과 변경 영향 묶음을 돌리는 식으로 운영하는 경우가 많습니다.
가까운 캠퍼스에서 게임 QA 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.