버그 태스크 처리절차 구축 요령

지난 마감은 프로젝트를 시작하고 나서 거의 처음으로 겪는 실제 빌드를 도출해 내는 마감이었습니다. 프로젝트와 팀을 새로 구축하면 이전에 당연하게 동작하던 여러 가지 과정을 새로 구축해야 합니다. 팀이 서서히 바뀌어 가는 이야기에 이야기한 것처럼 새 팀이 아니더라도 이런 일은 항상 일어납니다. 여기에는 지라 에픽 사용정책처럼 이런 정책이 당연하다고 생각해 신경 쓰고 있지 않으면 순식간에 이상하게 사용되는 사례를 포함합니다. 또 이런 일 중 하나는 버그 태스크 처리 절차를 만드는 일입니다.

좋은 게임을 출시하는 팀일수록 QA 부서가 강한 권한을 가지고 있습니다. 빌드에 품질이 확보되지 않은 이상 QA가 사인오프를 해 주지도 않고 사인오프 되지 않은 빌드는 완성되었다고 평가할 수도 없습니다. 때문에 개발 진행 중에도 계속해서 QA가 개입해 시스템에 대한 이해도를 높이고 미리 테스트 케이스를 준비하곤 합니다. 또 결함의 우선순위에 따라 마감 때 알려진 문제로 넘어갈 결함과 마감 전에 해결할 결함을 판단하는데 한 마디로 QA의 권한에 따라 우리가 집에 갈 수 있는지 없는지가 결정됩니다.

마감 때 빌드의 품질을 제어하기 위해서는 개발팀과 QA가 함께 사용할 버그 추적 시스템의 운용 정책을 정하고 이 정책에 맞게 시스템을 잘 설정해 놓아야 합니다. 프로젝트를 관리하는데 사용하는 지라 프로젝트나 워크플로우가 버그 이슈를 관리하는 지라 프로젝트나 워크플로우는 서로 달라야 합니다. 버그를 관리하는 태스크는 문제 상황, 재현 방법, 예상한 동작, 실제로 일어난 동작, 실행 환경, 중요도 같은 정보가 반드시 포함되어 있어야 합니다. 여기에 이 기능과 관계가 있는 기능의 에픽, 참고할 기획서와 테스트케이스, 이전에 발생한 비슷한 문제나 이 문제에 영향을 끼친 다른 문제 정보를 같은 태스크 안에서 모두 조회할 수 있어야 합니다. 물론 혼자서 이 모든 정보를 태스크에 모두 연결할 수 없을 수도 있어 버그 지라 이슈 처리에 관여하는 모든 사람들이 관련 정보를 연결해 놓아야 합니다.

버그 태스크는 대략 발생, 원인 파악, 수정, 빌드, 버전 별 재확인, 실제 환경에서 확인을 거쳐 완료되어야 합니다. 먼저 발생 단계에서는 우선 순수하게 예상하지 않은 동작 자체에 집중합니다. 원인 파악 단계는 주로 각 팀에서 빌드와 팀 내 워크플로우, 기능 별 주요 담당자를 잘 파악하고 있는 사람이 라우터 역할을 해 예상되는 원인을 파악해 담당자에게 할당합니다. 수정은 한 부서 이상을 거쳐야 할 수 있습니다. 팀 별 라우터가 예상한 원인과 실제 원인이 달라 담당자가 바뀌어야 할 수 있고요. 빌드 및 버전 별 재확인은 수정한 부서에서 먼저 수행하고 마지막으로 실제 환경에서 확인을 거친 다음에 태스크를 종료할 수 있게 됩니다.

버그 태스크를 처리하는 주요 과정에서 가장 중요한 부분은 반드시 마지막에 QA 담당자에게 태스크가 전달되어 동작을 확인한 다음 태스크를 종료해야 한다는 점입니다. 종종 문제를 수정한 부서에서 빌드를 걸고 태스크를 종료하기도 하는데 위험합니다. 수정 담당자 자리에서 테스트한 결과는 나머지 코드와 통합된 환경에서 테스트한 결과와 같지 않을 수 있습니다. 반드시 직접 빌드할 수 없는 환경에서 배포 받아 환경을 재구성한 다음 테스트 해야 합니다. 특히 개발하는 기계와 배포하는 기계가 다른 모바일 프로젝트 같은 경우에는 반드시 실제 기계에서 테스트를 거친 다음 태스크를 종료해야 합니다.

최근에 새 프로젝트의 첫 빌드 마감을 겪으며 이런 과정들이 느슨하게 돌아가는 과정을 지켜보고 또 스스로도 ‘이번은 괜찮겠지’ 하고 넘어가는 모습을 보며 늦지 않은 시점에 QA 담당자님께 이 과정을 강력하게 수행해 달라고 주문 하는게 좋겠다는 생각을 했습니다.