2015년 12월 1일 (화) 09:08 판

QA 관점에서 흥행한 게임의 PLC를 분석하다 보면 한가지 결론으로 귀착된다.

"유저의 피드백을 빠르게 적용하고 개선해 나가는 게임"

이러한 결론은 현재 성공한 게임들에서 공통으로 찾을 수 있는 모습이다. 개발QA 즉 개발단계에서 QA를 잘해서 서비스하는 게임은 물론이고 잘 못 했어도 서비스 단계에서 유저의 피드백을 빠르게 적용하면 제품의 라이프 사이클을 길게 유지하면서 매출을 올릴 수 있는 경우가 많다.

그래서 열린 개발에 대한 이슈를 개발단계에서 하는 방법을 포스팅 한 적이 있지만 이 개발방법을 비슷하게나마 사용하는 경우를 본 적이 없다. 성공 확률을 높이는 개발방법이지만 무슨 이유에서인지 이러한 열린 개발방법을 사용하는 개발사는 내가 아는 선에서는 없는 것 같다.

본론으로 들어가서 유저의 피드백을 빠르게 적용하려면 QA는 어떠한 방법을 써야 하는지 생각해 보아야 한다. 원리 원칙을 고수해서 품질 기준을 세우고 기준을 통과하기 위한 테스팅을 수행해서 Sign Off를 내리는 것이 과연 유저에게 빠른 피드백을 줄 수 있느냐의 문제다. 결론은 모든 업데이트 때마다 전통적인 방법의 QA를 고수하는 것은 옳지 않다.

그럼 어떠한 방법이 있을까? QA도 상황에 맞게 "Rapid QA"를 진행해야 한다. 리스크가 있을 수 있는 요소를 파악하고 기준을 세우고 빠른 테스트와 Sign Off를 내리는 것이다. Accept를 결정한 이후 QA로서 중요한 것은 버전 문제가 발생 시 QA도 같이 책임을 지는 모습을 보이는 것이다.

Rapid QA의 핵심은 개발 내용을 파악하고 테스트 범위를 정할 때 그 개발 내용만 테스트해서 결과를 정리하는 것이 아니라 관련기능까지 꼼꼼하게 테스트 범위에 넣는 것이다. 사실 이 부분은 개발자가 더 잘 알 수 있기 때문에 테스트 범위를 빠르게 정리해서 개발자에게 리뷰를 받는 것이 바람직하다.

그리고 버전 배포(패치) 이후에 즉시 전체에 대한 QA를 진행해서 유저보다 먼저 문제를 발견하고 대응할 수 있도록 해야 한다. 그 버전에 QA가 종료되는 시기는 버전을 배포 후 끝나는 것이 아니라. 이후부터가 본격적인 시작인 것이고 이후 진정한 버전 Sign Off를 선언할 수 있다.

Rapid QA를 따르다 보면 QA 업무의 정체성이 흔들릴 때가 온다. 이러한 것을 잘 극복해야 한다. 또한, 방법적인 것을 더 고민하다 보면 일반적인 게임QA의 방법론을 적용 할 수 있는 노하우도 찾을 수 있다. QA로 보수적인 태도도 필요할 때가 있고 그렇지 않을 때가 있는데 이러한 것을 잘 상황에 맞게 결정하는 것이 인정받는 게임QA의 모습이 아닐까 생각한다.

핵심 1. 개발 범위를 파악하고 관련 테스트를 꼼꼼히 체크하고 진행한다.

핵심 2. 버전 배포 후 전체 QA를 진행해서 유저보다 먼저 문제를 발견해야 한다.

오늘도 업계에서 불철주야 고생하시는 게임QA인들 "화이팅" 입니다.

출처

http://www.itester.co.kr/2014/02/rapid-qa.html