프로덕트 Test
테스트 조율
PM입장에서 테스트는 많이 하면 할수록 좋다. 업데이트하기 전에 다양한 상황에 대해서 많은 테스트하고 문제를 수정하고 나가는 것이 매우 중요하기 때문이다. 하지만 무작정 테스트 때문에 일정을 다 할애할 수는 없다. 인력 리소스와 다른 프로젝트 일정이나, 마케팅, 사업적 타이밍들이 있기 때문에 조율해서 해야 한다. 이 조율의 역할이 프로젝트를 책임지는 PM의 중요한 역할 중 하나라고 생각한다.
QA와 테스트 일정을 잘 협의해야 한다. 테스트 방법은 다양하고, 주로 QA에서 테스트를 담당하지만 무지성으로 QA에만 믿고 있다가는 큰일 난다. QA는 보통 기능 테스트 위주이기 때문에 충분한 일정과 리소스가 확보되지 않는다면 거진 기본기능성만 테스트하고 끝낼 경우가 많기 때문이다. 출시 QA처럼 대규모로 몇 개월씩 Full QA가 한다면 그나마 믿을 만 하지만 매번 마일스톤 할 때마다 Full QA는 매우 비효율적이기 때문이다. 기능뿐 아니라 사용성에 대해서 기능의 콘셉트와 사용의도 등을 QA와 잘 협의해서 기본기능뿐 아니라 사용성에 대해서 테스트가 이루어질 수 있게 해야 한다.
버전이 업데이트되면 그 즉시 테스트해야 한다. SW든 HW든, 둘다든 새롭게 기능이 업데이트가 되면 무조건 PM은 그 즉시 테스트해봐야 한다. 아무리 콘셉트를 잘 잡고, 문서를 잘 만들고, 커뮤니케이션을 잘했더라도 의도와 맞지 않는 기능으로 만들어질 수 있다. 나의 '아'가 다른 이들에게는 '어'라고 느낄 수 있기 때문이다. 여하튼 즉시 확인하고 가장 중요한 의도 몇 가지에 대해서 검수하고 다음 프로세스로 넘어가도록 해야 한다. 만약 다른 프로세스 중간에 핵심적인 문제가 발생한다면 수정한 이후에 처음부터 다시 해야 하는 상황이 발생할 수도 있기 때문이다. 또한 나중에 테스트하면 다 잊어버리고, 수정하려고 해도 버전 확인이 잘 안돼서 혼란이 가중될 수 있다. 따라서 즉시 PM이 검수하는 게 가장 안전하고 좋다고 생각한다.
필드테스트를 할 수 있다면 무조건 해야 한다. 내부에서 개발, 기획, 관련자들이 테스트를 많이 한다. 하지만 말 그대로 만든 사람들이 의도대로 테스트하기 때문에 특이 케이스와 실제 현장의 이슈 예측이 부족할 수 있다. 가능하면 실제 사용할 유저군의 테스트가 가장 좋다. 사실 운영 중인 매장이나 필드에 마일스톤을 설치하고 몇 달 동안 테스트하는 게 가장 좋기는 하나, 현실적으로 모든 프로젝트를 하기에는 불가능하기 때문에 선별해서 진행해야 한다. 가령 골프데이터에 대한 기능이 개선이 된다고 하면, 프로골퍼나 피터 등 골프 전문가를 초빙해서 테스트를 하는 것도 좋은 방법이다.
미국 법인과 테스트했던 적이 있었다. 물리적으로 떨어져 있다 보니, 테스트 타이밍이 항상 맞지 않았다. QA 들어갈 버전을 미리 전달하고, 테스트 후 이슈 있는지 확인해 달라고 했었다. 하지만 깜깜무소식이라서 QA를 진행했다. 제법 업데이트가 많아서 6주 동안 QA가 진행되었고, 나름 내부에서도 테스트를 진행하였다. 하지만 미주 직원들의 사용방향과 의도가 충분하지 않아서 불안하긴 했었다. 아니나 다를까 업데이트 일주일 전에 세부적인 것들을 개선 요청했다. 미리 테스트해 보고 의도를 이야기해 줬으면 좋으련만 다른 업무로 인해 바빠서 볼 수 있는 여력이 없었다고 했었다. 업데이트 일정을 일주일 연기시키고 수정하여 힘들게 대응했었던 기억이 있다.
테스트는 아무리 많이 해도 과하지 않다. 하지만 테스트는 시간과 리소스가 매우 많이 드는 프로세스이기 때문에 목적과 사용성에 기반으로 잘 조율해서 진행하지 않으면 문제가 생긴다. 초기에 이슈들을 잘 잡지 않는다면 필드에서 이슈 발생 시 리콜이나 롤백 등 사업적으로도 이슈가 발생할 수 있다. 즉, 호미로 막을 일을 가래로도 못 막게 되는 경우가 생긴다. PM은 어떠한 경우라도 항상 일정과 리소스를 효율적으로 생각하고 프로세스를 진행해야 한다고 생각한다.
*요약
호미로 막을 일을 가래로 막지 않도록, 품질의 무게와 시간의 속도 사이에서 최적의 균형을 찾아내는 저울질이 PM의 진정한 역할이다.