유저는 어떻게 할까?

게임 QA의 중요 덕목, 상상력

언젠가 퍼블리셔로부터 유저의 버그 재현을 부탁받은 적 있다. 퍼블리셔 CS로 들어온 경우다. 무조건 우리에게 떠넘긴 것은 아니다. 그들도 오랜 시간에 걸쳐 재현을 위해 노력했다. 그러나 실패했다. 그래서 개발사로 넘어온 경우다. 몇몇 건의 경우 현재도 재현하지 못해 남아 있는 케이스도 있다. 이런 경우는 중요도가 다소 떨어져서 인력을 집중시키지 못하는 이유가 있다.     

버그를 고치기 위해선 버그 재현 스텝이 필수다. 문제를 해결해야 하는 개발자 처지에서 상황이 정확하게 구현되지 않는다면 버그를 고칠 수 없다. 내부 개발과정에선 이 재현 스텝을 곧잘 찾을 수 있다. 보통은 QA 본인들이 하는 업무 중에서 발생하기 때문에 이전 상황을 어렵지 않게 기억해낸다. 로그 등 다른 방법도 충분히 활용할 수 있다.     

정말 어려운 경우는 이렇게 제보에 의한 경우다. 정보가 턱없이 부족하다. 버그 사진이나 동영상, 사용 컴퓨터 정보 정도만 받는다. 그 어떤 로그 기록이나 정확한 스텝, 기타 사항에 대해 알 수 없다. 증거가 부족하니 추리하는 것도 여간 어려운 게 아니다. 무턱대고 이렇게 저렇게 해봐야 한다. 이래서 QA의 중요한 덕목 중 하나가 상상력이다.      

개발과정에서 유저의 반응, 유저 입장에서 재미 등도 상상력에 기반해야 한다. 나는 소위 ‘변태’처럼 플레이하는 유저들을 흉내 내려고 노력한다. 항상 버그는 예상치 못한 유저의 움직임에서 많이 나온다. 어릴 때 몇몇 FPS 게임을 하면서 많이 느꼈다. 사람들을 세워서 담을 넘거나 건물 위로 올라가는 거를 보면 감탄이 절로 나왔다. 이처럼 사람들의 생각은 정말 다양하다.    

 

항상 고객의 입장에서 생각하는 태도가 필요하다. QA뿐만 아니라 다른 직군도 마찬가지다. 꼭 버그가 아니더라도 하나의 이미지나 문구 등을 통해 고객의 마음을 상하게 할 수 있다. 대상을 여러 각도로 보기 위해 노력해야 한다.     

PS) 나도 평소에 특정 앱이나 게임을 했을 때 버그 같은 현상을 본다. 가끔 해당 회사 CS를 통해 제보한다. 받는 사람으로서는 사진이나 영상, 기기 정보를 넘어 구체적으로 ‘어떻게 했더니 이런 현상이 발생했다’라는 메시지를 받는 게 좋다. 빈도도 있으면 정말 감사하다. 100%가 아닌 경우라면 대략적으로도 숫자를 적으면 좋다.