[번역] Part 4: 받아들이고, 조정하고 개선하라 – 바이오웨어의 애자일 QA 스타일

“받아들이고, 조정하고 발전시켜라(Adopt, Adapt and Improve)”는 1927년 영국 노리치(Norwich)에서 설립된 20대와 30대, 그리고 40대 초반의 남성을 대상으로 친목을 도모하고 자선 활동을 수행하던 단체의 모토다.

이 모토를 직장에 빗대어 해석한다면 아마 다음과 같을 것이다. “작업을 수행하면서 효과가 증명된 방법론을 받아들이고, 이를 시간이 흐를수록 변해가는 요구에 맞게 조정하고 가능하다면 이를 적용할 수 있는 모든 곳에서 발전시켜라.” 어디선가 많이 들어본 소리 아닌가?

만약 당신이 애자일 개발을 수행하고 있다면 이 말이 무슨 의미인지를 잘 알 것이다. 이  ‘계획 – 실행 – 확인’의 기본적인 원리는 바이오웨어 QA 철학의 핵심이다. 리사 크리스핀(Lisa Crispin)과 자넷 그레고리(Janet Gregory)가 2009년에 쓴 ‘애자일 테스팅’은 애자일 테스팅에 관해 훌륭한 가이드를 제공해 주고 있다. 이 책을 읽고 나서, 지금까지 바이오웨어에서 수행해 온 핵심적인 QA 원리가 소프트웨어 QA 커뮤니티에서 추천하는 표준과 정확하게 일치한다는 사실을 알고 놀랄 수 밖에 없었다. 한편으로는 놀라우면서도, 한편으로는 우리가 지금껏 잘해왔다는 자부심을 느끼게 해주었다.

우리가 지켜온 애자일 테스팅 10계명은 다음과 같다.

1.    고객에게 가치를 전달하라

바이오웨어 스튜디오에서 일하고 있는 QA는 사전에 결함을 방지하고, 개발자가 그들의 업무를 원활하게 수행할 수 있도록 도와주며, 리더들에게 가치 있는 비즈니스 정보를 제공해 적절한 의사 결정을 할 수 있도록 도와주는데 업무의 초점을 맞추고 있다. 또한 QA는 고객인 개발자와 이해관계자들에게 테스트 커버리지와 게임, 그리고 시스템과 관련된 중요한 지표와 데이터를 제공하고, 이를 통해 품질에 대한 정보도 제공한다. 훌륭한 QA 부서는 개발팀에게 그들이 만들고 있는 제품이 개발자들이 원하는 기준, 그리고 무엇보다 게임을 즐기는 사용자들이 원하는 기준을 충족시킬 수 있다는 자신감을 부여해 줄 수 있다. 

2.    팀에게 지속적으로 피드백을 전달하라

제품을 만드는 사람과 개발자, 그리고 당신이 속한 QA팀 스스로에게 지속적인 피드백이 전달되어야 한다. 가장 훌륭한 피드백은 근본적인 원인을 분석해 어떻게 리스크를 관리할 수 있는가에 관한 것이다. 또한 이는 모든 유관부서와 커뮤니케이션/피드백 채널을 열고 유지할 수 있어야 한다는 것을 의미한다. 얼마나 투명한 피드백이 제공되는지가 연관된 모든 팀의 성공을 좌우한다.

3.    좀 더 나은 커뮤니케이션을 수행하라

QA들은 다양한 방식으로 스스로가 스크럼 마스터나 퍼실리테이터인것처럼 행동한다. 개발팀과 QA만이 모든 핵심 개발 요소와 관련되어 커뮤니케이션 할 수 있는 두 핵심 부서이기 때문이다. 이들은 프로젝트 상에서 흩어진 점들을 이어서 큰 그림을 그리고 항상 이를 마음에 새겨둘 필요가 있다. 따라서 QA는 개발자들과 좀 더 나은 커뮤니케이션이 수행될 수 있도록 노력해야 하며, 아울러 팀 내부에서 표준과 품질 기대 수준에 대해 옳지 않은 커뮤니케이션이 수행되지 않도록 노력해야 한다.

4.    용기를 가져라

품질에 관한 리스크가 있다는 것을 제안하고 상기시켜라. QA는 문지기도 아니고 그렇다고 병목이 되어서는 더더욱 안 된다. 우리가 하는 일은 품질을 소유하는 주체인 개발과 관계된 유관 부서에게 필요한 정보를 제공하는 것이다. 피드백을 통해 개발자들이 목표에 다다를 수 있도록 도와주며, 좀 더 효과적으로 행동할 수 있도록 해줄 것이다. 또한 QA는 최종 사용자들의 입장을 최대한 대변해 주어야 한다. 비록 이 역할 때문에 사람들의 심기를 다소 불편하게 만들더라도, 이를 통해 개발자들이 스스로의 방향을 잡을 수 있도록 도와줄 수 있기 때문이다.

5.    단순하게 가자! (Keep it simple!)

6.    지속적으로 발전을 도모하라

라운드 테이블의 모토를 다시 상기하자 – 사례와 프로세스를 조사하고, 수정하고, 유지보수 하라.

7.    변화에 반응하라

모든 상황에 적합한 단 하나의 솔루션은 존재하지 않는다. 프로젝트에서 최선의 방책을 수행하며 이를 위해 현재의 전략을 수정하고, 기회가 될 때마다 그리고 문제를 해결할 수 있을 때마다 혁신적인 아이디어를 도출해내야 한다. 게임 개발에서 명확한 사실은 오직 한 가지다. 항상 무엇인가 변한다는 것이다. QA로서 우리는 변화에 신속하게 대응하고 그로 인한 피해를 줄일 수 있도록 항상 이를 수용할 수 있는 자세를 가져야만 한다.

8.    스스로를 조직화하라

바이오웨어에서 QA는 QA 스스로와 개발의 작업 효율 및 워크플로우를 향상시키기 위해 항상 새로운 툴과 프로세스를 개발하고 스킬을 연마하도록 장려 받고 있다. 새로운 툴과 자동화를 개발하는 일을 QA 프로그래머만 수행하는 것은 아니다. 우리는 우리의 애널리스트들에게 이런 기회가 제공될 수 있도록 훈련을 제공하고 있다.

9.    사람에 집중하라

결국엔 QA가 어떤 기능을 수행해야 하는지를 정의하고 이해하는 것이 핵심이다. 다양한 타이틀을 거쳐 우리가 보유하고 있는 경험을 통해 이를 달성할 수 있을 것이다.  

10.  즐겨라!

게임의 재미 요소를 평가하는 것은 결코 쉬운 일이 아니다. 하지만 동시에 이는 충분히 재미있는 일이기도 하다. QA는 제품과 혼연일체가 되어야 한다. 끊임없이 제품을 사용해보고 제품에서 발생하는 변화도 숙지하고 있어야 한다. 항상 부정적인 면을 직시해야 하기 때문에 유머 센스를 잃지 않는 것이 중요하다. 이를 통해 마인드를 긍정적으로 유지하고, 다른 사람들이 그들에게 관심을 두고 있다는 것을 느끼게 만들기 때문에 여러 모로 유용하다. 만약 업무가 어떤 도전이나 과제도 없이 늘 반복적이라면, 현실에 안주할 가능성이 크고 그로 인해 실수를 저지르게 된다.

개인적으로 비밀로 유지하고 있는 11번째 항목이자, 우리 QA 부서의 슬로건은 바로 이것이다. “Keep calm and continue testing”. 수많은 우리 개발자들이 QA가 항상 최악의 것들을 접하고 있음에도 불구하고 묵묵히 그리고 혼란에 빠지지 않고 일하고 있다는 것에 진심 어린 감사를 표하고는 한다. 이로 인해 개발자들은 게임을 재미있게 만드는 일에만 열과 성의를 다할 수 있게 되는 것이다!

10년전 게임에 스크럼을 도입하고 소개했던 클린턴 키스(Clinton Keith)는 이렇게 말했다. “스크럼은 프로세스를 넘어서서 사람에 관한 것이다 – 창조적인 사람들을 이끄는 훌륭한 리더는 기계적으로 프로세스를 수행하는 사람이 아닌, 오히려 정원사에 가까운 존재다”.

프로젝트에 무엇이 필요하고 어떻게 구성되어야 하는가에 따라 쉽게 변경되는 유기적인 조직이라는 점에서 바이오웨어의 QA팀은 항상 애자일 하다고 말할 수 있다. 하지만 그럼에도 불구하고 우리의 목적은 변하지 않는다. 개발자가 만들어내는 모든 산출물이 양질의 품질을 가지도록 보장하는 것이다.

프로토타입이나 프리-프러덕션을 만들 때는 QA 애널리스트들이 테스트 해야 할 애셋이 많지 않은 시점에서부터 시스템을 검증하기 시작한다. 이 애널리스트들은 우리가 일반적으로 ‘테크 QA’라고 부르는 사람들이며, 컨텐츠를 구현하는데 필요한 시스템을 잘 이해하고 있는 사람들이다.

툴과 시스템, 워크플로 상에서 식별된 이슈들은 프로그래밍 팀의 지원을 받아 해결한다. 또한 우리는 레벨 아트, 레벨 디자인, 시네마틱 디자인, 게임 플레이와 내레이션에 집중하는 컨텐츠 QA라고 부르는 전문가들도 보유하고 있다.

QA 애널리스트들은 종종 스크럼 팀에 합류해 함께 일한다. 때로는 한 사람의 애널리스트가 여러 스크럼을 동시에 지원하기도 한다. 프로젝트가 시작되면 점점 더 많은 컨텐츠가 테스트되기 위해 몰려들고 다양한 플랫폼이 가동되기 시작한다. 시간이 지남에 따라 개발이 진행되면서 시스템과 산출물은 점점 더 복잡해진다. 이로 인해 추가된 기능과 툴에 대한 테스트도 늘어나기 시작한다. 새롭게 추가된 기능이 앞서 만들어진 어떤 것에도 영향을 미치지 않는다는 것을 확인하기 위한 리그레션 테스팅에 점점 더 많은 시간이 할애된다.  

제품이 만들어지는 동안 비록 워크플로에는 맞지 않더라도 QA가 풀(pool)제로 운영되는 것이 훨씬 효율적이라는 결론을 얻을 수 있었다. 최근에는 여러 가지 다양한 임베디드 시스템과 풀 제를 시험적으로 운용해보고 있다. 또한 래피드 소프트웨어 테스팅(Rapid Software Testing)과 같이 색다른 팀 구성과 기법도 적용해 보고 있다.

우리는 우리 프랜차이즈 간에 QA 프로세스를 집대성하려고 한다. 이렇게 서로 다른 프랜차이즈 간에 서로 다른 게임 팀이 병렬로 구성되어 얻을 수 있는 이점은 다른 팀의 성공과 실패에서 쉽게 교훈을 얻을 수 있다는 것이다. 학습을 통해 이를 신속하게 체득하고, 이를 통해 지속적으로 우리 조직과 사람들이 발전할 수 있다.

RPG와 QA라는 관점에서 우리 스튜디오 안에 구성된 각기 다른 유형의 지원 업무와 전문적인 업무들에 대해 언급하자면 아마 끝이 없을 것이다. 이를 한 편의 글에서 다루기는 쉽지 않다. 이후에 기회가 된다면 이 블로그를 통해 다루기로 하겠다.

나는 테스터를 수문장에 비교하는 것에서 벗어나 테스터를 군 정보부에 비유하는 것을 더 선호한다. 여러 면에서 테스터의 목적과 정보기관의 목적이 비슷하다. 이에 대해서는 시리즈의 앞선 2부에서 우리의 미션을 언급하면서 다루었다. 

테스터는 개발자와 이해관계자들이 그들의 일을 좀 더 잘 할 수 있고 올바른 결정을 할 수 있도록 유용한 정보를 제공한다. 군 정보부가 적과 직접 싸우지 않는 것처럼, 테스터들 역시 직접 버그를 수정하지는 않는다.

우리는 개발자들이 항상 최전선에 서있을 수 있게 도와준다. 개발자가 아니라는 것이 곧 QA가 복잡하고 기술적인 직업이 아니라는 이야기는 아니다!

QA는 종종 우리 게임을 실제로 즐길 사용자들이 생각할 수 있는 색다르지만 현실적인 시나리오들을 고민하고 시뮬레이션 해야 한다. 때로는 불충분한 정보를 가지고 가정을 해야 하고, 실제 필드에서는 발생할지 안 할지도 모르는 리스크를 구구절절이 설명해야 하는 경우도 있다.

나는 개인적으로 우리 팀원들이 군 정보부보다는 닌자로 불리기를 좋아한다는 것을 알고 있다. 또한 그들은 스스로를 제품을 만드는 개발자와 프로듀서를 지원하는 일을 하는 ‘네트워크 닌자’라고 생각하는 것을 즐긴다는 것도 알고 있다. 우리 팀의 QA 닌자들은 게임을 만들어내는 시스템과 게임의 컨텐츠, 기술이 가지는 목표를 숙지하고 있다. 또한 게임의 기능성과 주관적인 품질을 보고하고, 가능한 최고의 정보를 제공해 팀의 다른 인원들로 하여금 최선의 선택을 하도록 도와준다.

RPG 게임의 주요한 기능들을 예로 들어보자. 탐험, 전투, 진행과 스토리는 게임이라는 기계의 기어와 같은 역할을 하고 있다. 만약 이런 기어의 하나가 제대로 동작하지 않는다면, 다른 기어들 역시 망가지기 시작할 것이다. 예를 들어 게임에 스토리 요소가 없다면, 플레이어들은 더 이상 게임을 진행하고 싶은 욕구를 느끼지 못할 것이다. 이 경우 QA 닌자들이 윤활유 역할을 해 다른 기어들이 서로 매끄럽게 돌아갈 수 있도록 만들 것이다. 우리 스튜디오의 모든 곳에 QA의 도움의 손길이 필요한 것이다.

예측 가능성은 성공을 좌우하는 아주 중요한 요소다. 특히나 프러덕션 과정에서 이는 더욱 중요하다. 이론적으로 더 많은 지식과 경험을 가지고 있을수록, 양질의 게임을 더 빨리 출시할 수 있다. 따라서 지식이야말로 당신의 스튜디오가 만들어 낼 수 있는 가장 값진 자산인 것이다!

지금까지 이 글은 모두 QA의 관점에서 작성된 것이다. 이 글에서도 언급하고 있는 협력 관계의 일환으로, 나는 바이오웨어 애드몬튼에 있는 몇몇 개발자에게 우리의 임베디드 QA에 대한 의견을 묻고 공유해 주기를 요청했다. 그들의 의견으로 이 글을 마무리하고자 한다.

“임베디드 QA는 여러 그룹이 함께 일하면서 새로운 기능을 만들어내는 바이오웨어에서 현재 택하고 있는 애자일 방법론에 아주 적합하다. 해당 기능의 검증은 모든 것을 만든 다음에 수행하는 것이 아니라, 새로운 기능을 만들어내는 과정의 하나로 간주된다. 나는 임베디드 QA를 우리 게임 개발 방법론의 핵심이라고 생각한다. 오히려 더 많은 것들을 이런 식으로 처리해야 한다고 생각한다.” [테크니컬 디렉터]

“다양한 프로젝트에 걸쳐 개발 기간 내내 QA팀 구성원들이 함께 일함으로써 오디오 영역을 포함해 다양한 QA ‘전문가’의 영역이 만들어졌다. 그들은 스스로 무엇을 하는지 잘 알고 있으며, 우리 게임의 리뷰 스코어에 그들이 한 일이 반영되고 있는 것이다. 그들이 우리의 시간을 빼앗는 것이 결코 아니다. 그들은 진심으로 게임 개발에 필요한 아트를 돌보고 있는 것이다.” [리드 사운드 디자이너]

“QA는 버그 리스트를 포함한 다양한 정보를 제공하고, 빌드 실패와 같은 일이 발생했을 때 즉각적인 도움을 주며, 실제 버그를 수정하는 것을 넘어서 게임을 발전시키기 위한 다양한 제안을 주고 있다.” [테크니컬 디렉터]

“나는 QA가 프로젝트 전반에 걸쳐 객관적인 시각을 제공해준다고 믿고 있다. 우리의 프로젝트는 점점 규모가 커져가고 있어 우리가 전념하는 일부에 국한된 시각을 가질 수 밖에 없다. QA는 이와 관련된 ‘잃어버린 고리(missing link)’를 제공해 주는 것이다. 나는 그들이 컨텐츠를 만드는 것에 관여하지 않음으로써 여기에 집착하지 않는 것이 그저 고마울 따름이다. 이로 인해 다른 팀이 QA에게 감사하는 것이며, 컨텐츠를 만드는 사람이 아닌 소비자의 입장에서 프로젝트를 비판할 수 있게 만드는 점이다.” [오디오 아티스트]

 

PS: 몬티 파이슨에서 언급된 “Adopt, Adapt and Improve”의 비디오

http://www.youtube.com/watch?v=zt8PDTUNyPE J