기획자,PM 입장에서 본 QA

유,무선을 막론하고 인터넷 서비스를 오픈하기 전 내부적으로 검수를 받는 QA (Quality Assurance)
서비스나 회사 특성상 내부 조직에서 할 수도 있고 별도의 외부 전담부서에서 진행할 수도 있습니다. 대상이나 방법론 역시 각 서비스마다 고유한 양식을 갖고 있을 겁니다. QA는 서비스 품질 관리상 필수적인 절차이면서도 버그가 발견되면 오류 수정과 그로 인한 실서버 적용 일정에 차질을 빚을 수 있으므로 (즉, 일정 연기의 부담 또는 부득이한 야근 등) 서비스 실무부서에서는 심한 스트레스를 받는 과정이기도 합니다.
QA를 진행하는 부서, 테스터 입장이 아닌 QA를 받는 기획, PM 입장에서 그동안 겪은 QA를 바탕으로 몇가지 생각을 정리해 봅니다. 위에서도 말했지만 QA는 회사마다,서비스마다 규모와 절차가 다르니 아래 내용은 읽는 분의 상황에 따라 맞지 않을 수도 있음을 염두에 둬 주세요.
1. QA 전

• TC(Test Case) 작성
  테스터들이 실제로 테스트를 진행해야하는 각각의 항목을 명시한 표를 말합니다. TC는 서비스 규모에 따라 적게는 수십개 항목에서 많게는 수백개, 수천개가 되기도 합니다.
• TC를 작성할 때는 테스트 하는 내용과 규모에 따라 다릅니다만 보통 서비스의 핵심 과업 및 메뉴구조에 따라 서비스가 제공하는 기능과 화면 메세지, 오류 처리 방법을 명시합니다. 메뉴를 사이트맵이나 트리구조처럼 늘어놓고 각각의 메뉴에서 제공하는 기능과 메세지를 정리하여 빠지는 기능이 없도록 TC를 작성합니다. 물론 개선,변경된 부분이 있으면 그 부분에 대해서만 QA를 할 수도 있고 그 부분 때문에 다른 쪽에서 오류가 발생할 수도 있기 때문에 전체를 다 QA하는 경우도 있습니다.
• 명확한 테스트 케이스와 결과 표시
  TC를 작성하면서 자주 저지르기 쉬운 오류는 TC의 내용과 결과물을 명확하게 서술하지 않는 것입니다. 기획자나 개발,운영 등 해당 서비스에 관여하고 있는 사람이 서비스를 이해하는 정도와 QA조직에서 해당 서비스를 이해하는 정도는 서로 다릅니다. 예를 들어 “A라고 써 있는 버튼을 눌렀을 때 ㄱ의 세부 내용이 잘 표시되는가?” 라고 쓰면 테스터들은 “잘 표시”가 어떤 내용이 어떤 방식으로 화면의 어디부터 어디까지 얼마동안 표시되어야하는지 알 수가 없습니다. 오랫동안 서비스를 들여다본 사람 입장에서는 당연하다고 생각하는 항목이 다른 사람에게는 전혀 그렇지 않을 수 있지요. 예를 들어 화면에 텍스트를 표시할 때 화면을 넘치는 글을 줄바꿈할지, 점(…)으로 표시할지, 왼쪽으로 천천히 스크롤 시킬지, 그냥 잘라내버릴지, 어떤 화면이 과연 “잘” 나오는 것인지 알 수 없습니다. 올바른 출력 예를 화면 캡춰그림과 함께 보여주면 좋습니다.
• 테스터용 환경 셋업 (네트워크, 위치정보, 로그인 정보, 호스트 정보 )
  테스터들이 사용할 장비, 네트워크, 프로그램, 로그인 계정, 호스트 정보들을 미리 정리하여 테스트에 문제가 없도록 준비해야 합니다. 특히 QA조직이 다른 네트워크, 다른 위치에 있는 경우는 각별히 조심해야 합니다. 대부분의 개발서버는 외부에서의 접근을 차단 또는 제한하고 있으므로 테스터가 QA도중 서비스 접속이 안되거나 잘못된 서버로 연결되어 엉뚱한 결과를 얻을 수 있습니다. QA조직에서는 그래서 QA 전날 또는 당일 오전 일찍 QA환경점검을 하기도 합니다만 이 단계에서 전체적인 서비스 테스트 환경을 모두 체크하기는 어렵습니다. 서비스의 구조와 동작방식을 알고 있는 서비스팀과 개발조직에서 테스터들의 QA환경에서도 문제가 없는지 미리 점검해야 합니다.
• 주요 오류에 대한 사전 점검
  TC 작성과 아울러 QA전에 충분한 사전 테스트를 하는 것이 매우 중요합니다. 각 메뉴별로, 각 기능별로는 물론 주요 사용자 스토리별로도 테스트를 해봅니다. 서비스를 개편했거나 기능을 개선한 것이면 해당 기능 자체는 물론 영향을 받을 수 있는 다른 기능에 대해서도 주의를 기울여 살펴봐야 합니다. 이 점에 대해서는 개발자에게 사전에 의견을 들어보는 것이 좋겠지요.
• 놓치지 말고 체크해야할, 자주 나오는 오류케이스
  • 입력칸에 잘못된 값(html태그, 특수문자, 비정상적으로 긴 문자열, 빈 공백, 큰 이미지 첨부 등)을 넣었을 때에 대한 처리를 빼먹었을 때
  • 브라우저 메뉴에서 뒤로와 앞으로를 반복할 때 페이지의 전체 또는 일부 영역이 제대로 표시되지 않는 경우 (폼 입력값 위주로)
  • 사용자가 URL을 직접 치고 들어 올 때에 대한 준비 미흡
  • 초기에 아무런 데이타도 들어 있지 않은 경우와 서비스에 오류가 났을 때 출력할 화면 준비 미흡. (오류시 서버가 내뱉는 오류메세지를 그대로 화면에 출력하는 경우를 “내장이 튀어나왔다”고 할 정도로 부끄러워하는 기획자들도 있습니다.)
  • 레이어가 서로 잘못 얹혀지거나 위 레이어가 아래 레이어 영향을 끼쳐 기능이나 화면 표시가 겹치거나 가리는 현상

2. QA 진행중
QA중엔 테스트 중 문제가 보고되진 않는지 만약 그렇다면 어떤 문제인지에 대해 여러 부서. 담당자와 시간을 다투며 문제를 파악하느라 정신이 없습니다. 일시적인 문제일 수도 있고 개발이나 디자인 과정에서의 오류가 있을 수도 있습니다. 그러나 짜증내고 누구를 질책할 일이 아닙니다. QA에서 나오는 오류에 대한 책임은 꼼꼼하게 챙기지 못한 기획자와 PM에게 있다고 생각합니다. 손발은 바쁘지만 마음은 도를 닦는 자세로 침착하게 상황을 판단하고 이슈들을 정리해나가시길 바랍니다.

• 기능 질의에 대한 대답
  테스터들은 기획서와 TC를 참고로 테스트를 합니다. 그런데 실제로 서비스를 만들다보면 애초 기획서와 달라지는 부분이 생길 수 있습니다. 이걸 다시 기획서에 반영을 해놓으면 좋은데 그러지 못하는 경우가 종종 있죠. 이러면 테스터들은 기획자에게 해당 현상을 문의하게 됩니다. 기획서에는 디자인 한겹 올린 예쁜 오류메세지가 그려져 있는데 실제로는 시스템 기본 경고 오류상자가 나온다든가 말이죠. 이게 오류인지 아니면 일정상 또는 기술적인 문제로 제외된 기능 (이른바 Spec out이라고 하는) 것인지에 대해 바로바로 대답을 해주어야 합니다. 물론 그보다는 QA전에 미리 이러한 점에 대해 정리를 해서 테스터들에게 공유를 하는 편이 더 좋습니다. 마치 책 오탈자에 대해 뒷표지 안쪽에 정오표를 첨부하는 것 처럼.
• 진짜 문제가 나타났다.
  이렇게 현상에 대해 설명 또는 정의를 하면 되는 간단한 경우외에 진짜로 문제가 생기는 경우들이 있습니다.
  QA중 이상 현상이 나오면 테스터는 재현되는 현상인지를 확인한 후에 PM에게 직접 또는 QM이라는 QA책임자를 통해 담당기획자에게 이 현상에 대한 문의를 하게 됩니다. 기획자(또는 PM)은 이 현상의 원인을 파악하여 알려줘야 하는데, 원인을 찾는 과정이 쉽지 않습니다. 기획단계에서 그렇게 동작되도록 한 것인지 아니면 정말 오류인지, 오류라면 프로그램상의 문제인지 API 문제인지 네트워크 문제인지 그것도 아니면 또 다른 문제인지를 파악하기 위해서 해당 서비스의 기획자,개발자, 디자이너,UI개발자, 네트워크 엔지니어 등과 빠르게 문제점을 파악하여 회신하여야 합니다. 이것은 테스트에 소요되는 시간에 대한 문제이기도 하고 오류판정의 등급에도 영향을 끼치는 일입니다. 이 과정 때문에 QA가 진행되는 시간 동안에는 서비스에 관계된 실무자나 실무책임자와 계속 연락이 되는 상태를 유지해야 하고 그러기 위해선 미리부터 QA일정을 통보하고 이에 대한 협조를 구해야 합니다. 만약 PM이 이들에게 QA 일정에 대한 공유를 하지 않았다면 당사자가 QA날에 휴가를 냈어도 할 말이 없는거죠.

3. QA를 마치고

• 판정 등급에 대한 검토와 어필
  QA가 끝나면 QA과정에서 발견된 문제점을 정리하고 이 문제가 심각한 문제인지 아니면 사소한 문제인지 QA담당부서에서 등급을 매겨 옵니다. 화면에 나와야할 글자가 나오지 않았다면 CSS 오류일 수도 있고 DB 입출력에 문제가 있을 수도 있고 아니면 API에서 값을 못 불러왔을 수도 있겠지요. 사실 사용자 입장에서 보면 글씨가 나오지 않았다는 것이 중요하지 우주전쟁으로 외계인이 데이타센터에 들어와서 서버운영요원들을 납치해가는 바람에 장애가 생겼는지는 상관할 바가 아니긴 하지요. 테스터들은 그 문제가 생긴 원인의 심각성 보다는 사용자 입장에서 겪는 오류와 주요 과업의 실패에 대해 중요하게 생각하는 듯 합니다.
  그런데 이 오류라는 것의 심각성이 QA담당자가 생각하는 정도와 기획자가 생각하는 정도가 서로 다를 수 있습니다. 예를 들어 입력칸에 아무것도 넣지 않고 글 작성 완료 버튼을 눌렀는데 “내용을 입력해주세요”라는 오류메세지 없이 그냥 제목없는 결과물이 나왔다고 칩시다. 테스터들 입장에서는 이 오류를 심각한 오류로 판단할 수 있습니다. 일반적인 경우에선 오류일 수 있습니다. 그러나 새로운 모든 서비스들이 기존 서비스들의 평균적인 인터페이스를 제공해야만 하는 것은 아닙니다. 예를 들어 비공개 개인 다이어리에서 제목이 없는 경우 본문의 앞부분을 제목처럼 사용하는 기능을 도입했을 수 있습니다. 이 경우에는 오류가 아니겠지요. 스마트폰에서 사진등을 자기 자신에게 메일 첨부파일로 보내는 경우가 있는데 이렇게 자신에게 메일 첨부를 보낼 때에 한해서 제목없는 메일에 대한 경고문 없이 바로 보내는 경우도 생각해 볼 수 있습니다. 기획자는 “우리 서비스에서는 이러저러한 이유로 그렇게 하기로 했다”고 이야기할 것이고 QA에서는 “고객이 혼란스러울것이다.(또는 오류라고 볼 것이다, 또는 실수할 수도 있을 것이다.) 그러니 제목없이 작성완료 버튼을 눌렀을때에는 경고창을 띄우는 것이 좋겠다.”고 제안을 할 수 있을 것입니다.
  합당한 제안이라면 수락하면 될 것이고 그보다 더 중요하게 생각하는 명분이나 실익이 있다면 다시 설득을 해 볼 수 있겠지요. 적당한 선에서 포기하느냐, 다른 절차를 밟아서 이를 관철 또는 조정하느냐는 각각 회사마다, 경우에 따라 또 사람에 따라 다를 것이기 때문에 어떻게 하는게 맞다고 말하긴 어렵습니다. 경험상 QA 마무리 단계에서 의견충돌이 있기 마련이고 조정 과정에서 극심한 스트레스를 겪게 되곤 하더군요. 그러나 서로 회사로부터 부여받은 권한과 의무에 따라 각자의 일을 하고 있는 것임을 잊지말고 공식적인 절차에 따라 (쉽진 않지만) 차분하게 설명하고 우아하게 설득하는 자세가 필요합니다.

곰곰히 생각해보면 기획자,PM으로서 QA를 할 때 가장 중요한 것은 서비스와 기능에 대한 충분한 이해와 문서화 능력, 그리고 각 QA 및 유관부서 담당자와의 원활한 대화능력이라고 생각합니다.
QA는 필요악이 아니라 반드시 필요한 당연한 과정입니다. 다만 내가 검토해서 오류가 없다고 확신한 항목, 또 미처 살펴보지 못한 부분에 대한 오류들이 검출되고 또한 서비스를 만들면서 옳다고 생각했던 세계관에 대한 반론이 들어오는 것에 대한 대응 과정이 상당히 스트레스 받고 피곤한 과정이어서 힘든 것입니다.
서비스가 세상에 나오기 전 마지막 산고 단계인 QA과정, 스트레스 어차피 받으시겠지만 그러려니 하고 모든 실력과 품성을 최고조로 발휘해서 즐겁게 잘 하시기 바랍니다. ^^;