만약 당신이 새로 부임한 QA 매니저라면…”
By James A. Whittaker
오늘 아침, 나는 한 독자로부터 아래 내용의 메일을 수신했다.
“나는 테스트 관리자(Test supervisor)로 일하다가 어제부로 QA 관리직(QA Management position)으로 임명되었습니다. 한편 흥분되기도 하지만 한편으로는 두렵기도 하네요. 이런 마음을 어떻게 정리해야 할 지 잘 모르겠습니다. 스타웨스트(StarWest)에 참가하고 나서, 그리고 또 당신의 블로그를 팔로잉하고 나서부터 나는 당신의 의견에 무척 흥미를 가지게 되었습니다.
만약 당신이 새롭게 QA 매니저가 되었다면, 그리고 당신이 지금 알고 있는 것들을 모두 알고 있다고 가정한다면, 가장 중점을 두어야 할 일 5 ~ 10 가지는 무엇일까요?”
나는 이 독자가 내개 보낸 신뢰로 인해 우쭐해지기는 했지만, 이런 질문을 나에게만 물어보는 것은 부적절하다고 생각했다. 나는 이 질문에 대해서 공개적으로 답변해, 독자 여러분들의 경험을 여기에 더 활용하고 싶다. 덧붙여 나 역시 매일 이런 흥분과 공포를 느껴봤었고, 나 스스로도 여러분의 의견을 활용할 수 있기 때문에 다른 사람들의 의견이 어떨지 더욱 궁금하다. 먼저 나의 의견 몇 가지를 여기에 제시하고, 추후의 포스트에서 몇 가지를 더하기로 한다(그렇지 않다면 다른 사람들이 먼저 포스팅을 해도 좋다).
당신의 제품을 직접 사용해보고 애착을 가져라
(Start living with your product, get passionate about it)
당신의 제품을 직접 구매해보라.[1] 그리고 제품의 광고 문구(Sales pitch)를 연상해보라. 당신 제품이 타사 제품과의 경쟁에서 이길 수 있는 장점을 생각해보라. 하지만 늘 테스터로서 갖춰야 할 회의론(skepticism)은 유지해야 한다. 테스트/QA 매니저들 역시 개발 관리자와 마찬가지로 제품에 대한 열정을 가지고 있어야 하지만, 그들과 달리 우리는 제품에 열정을 가질 만한 “증거(Proof)”를 가지고 있어야 한다는 것이 그들과 틀린 점이다. 테스트 팀은 광고 문구에 대응하는 제품의 기능성에 대한 테스팅을 멈추지 말아야 한다는 것을 기억하라.
여기에 더해, 스스로 당신 제품을 열성적으로 사용하는 사용자가 되어 실제 생활 속에서 당신의 제품을 사용해보라.
최근 나는 노트북 대신 크롬 OS가 설치된 넷북만을 사용해 나의 주된 업무 대부분을 처리하고 있다. 사람들이 복도에서 크롬 OS 넷북을 들고 다니면서 업무를 보는 나의 모습을 볼 때마다, 나는 사람들에게 매일 크롬 OS의 광고 문구를 떠올리게 하는 것이다. 훌륭한 사례다. 나는 또한 크롬 OS와 넷북 환경의 부족한 부분에 대해서도 잘알게 되었고, 이에 대해서 아직도 충족되지 않은 부족한 부분들은 기록으로 남기기도 한다. 이러한 기록들은 개발자나 다른 이해 당사자들과 논의할 만한 훌륭한 소재를 제공해 주며, 경쟁사 제품은 이런 부분을 어떻게 커버하고 있는지 궁금증을 유발하게 하기도 한다. 크롬 OS 넷북에서 어떤 중요한 일을 처리하지 못할 때, 경쟁사 제품을 사용해 봄으로써 사용자들이 우리 제품의 단점을 어떻게 받아들일지 알 수 있을 것이다. 아울러 우리 제품에 대해서 불평을 제기하는 고객들과 어떻게 진심으로 대화할 수 있을지에 대해서도 알게 될 것이다. 매일 매일 실제 사용자로서 내가 만든 제품에 깊이 빠져보라. 이는 새로운 제품을 만들기 시작하는 훌륭한 방법이 될 것이다.
테스트 계획에 집중하고 그 우선 순위를 높여라
(Really focus on the test plan, make it an early priority)
만약 당신이 현존하는 제품의 현존하는 테스트 매니저 직을 인계받았다면, 이미 기존의 테스트 계획이 존재하고 있을 것이다. 물론 그 계획이 충분하지 않을 가능성도 많다. 내가 당신의 전임자를 데려와 왜 그런지에 대해서 꼬치꼬치 캐물을 정도로 잔인한 사람은 아니다. 하지만 나는 대부분의 테스트 계획은 일시적인 것에 지나지 않는다는 것을 인정할 정도로 진실에 충실한 사람이기는 하다.
자, 이제 내가 말하려던 바를 좀 더 자세하게 알아보자. 테스터들은 불명확하게 디자인된 문서에 대해서 쉽게 불평을 쏟아내기 마련이다. 개발자들은 코딩을 시작하면서 급하게 디자인 문서를 만들기 시작하거나 다이어그램을 그리기 시작하고, 이렇게 시작한 설계는 코드가 생명을 가지기 시작하는 시점에서부터 부실해지기 십상이다. 곧 이어서 코드가 설계와 부합하지 않게 되고, 이로 인해 문서는 신뢰를 잃게 된다. 당신이 이런 경우를 겪어보지 않았다면 이는 정말로 축하할만한 일이다. 하지만 내 경험상, 문서가 지속적으로 업데이트 되는 경우보다 이런 경우가 더 일반적이었다.
이런 상황은 테스터들이 불평을 토해내기 딱 좋은 상황이다. “제품이 어떻게 동작하는지에 대해서 충분하게 설명되지도 않은 명세를 가지고 어떻게 제품을 테스트 할 수 있나요?” 라고 말이다. 그러나 우리 테스터들도 테스트 계획에 대해서 똑 같은 행동을 하고 있지 않는가? 우리 역시 급하게 테스트 계획을 작성하며, 테스트 케이스(자동이던 수동이던)는 작성을 시작하는 순간부터 테스트 계획과는 전혀 관계가 없는 나름대로의 새로운 생명을 가지게 된다. 우리가 새로운 개발 내용을 추적하고 우리가 경험한 것을 통해 테스팅에 대한 새로운 시각을 가지게 되면서 테스트 케이스는 기존의 테스트 계획으로부터 멀어지게 된다. 이 단계에서 테스트 계획은 바로 디자인 문서와 같아진다. 이미 완성되어버린, 과거 시점의 문서가 되어버리는 것이다.
만약 당신이 지금 새롭게 부임한 테스트 매니저라면, 이러한 문서들을 수정하는 것을 최우선 업무로 설정하라. 그럼으로써 당신은 당신 제품의 기능을 파악할 수 있을 뿐만 아니라, 현재의 테스트 인프라스트럭쳐에서 어느 부분이 보강이 필요한 지에 대해서도 알게 될 것이다. 여기에 더해, 이 작업은 당신이 개발 관리자들과 의사소통하게 되는 계기를 만들어 줄 것이며, 그들은 또한 이 작업을 통해 당신이 품질에 매우 열정적인 자세를 가지고 있다는 것을 알게 될 것이다. 구글의 개발 관리자들은 잘 짜여진 테스트 계획을 선호한다. 이렇듯 훌륭하게 짜여진 테스트 계획은 개발 관리자들에게 당신이 지금 하고 있는 일을 잘 파악하고 있다는 확신을 심어주게 된다.
당신이 속한 조직의 릴리즈 프로세스와 우선순위에 대해 이해하라
(Understand your orgs release process and priorities)
사이클 후반부의 프리-릴리즈 테스팅(Pre-release testing)은 전체 개발 사이클에서도 가장 신경쓰이는 부분 중의 하나다. 테스트 관리자는 적합한 테스팅을 수행하는 것과 릴리즈 일정을 준수하는 것 사이에서 균형을 유지해야 한다. 나는 모든 개발 회의에 테스트 관리자가 참석하는 것, 특히 릴리즈 일정이 다가올수록 하나의 회의도 빠짐없이 참석해야만 한다는 것을 권장한다. 개발자들이 걱정하고 근심하는 것들에 대해서 깊은 관심을 가져야만 한다. 악몽같은 시나리오는 늘 프로세스의 마지막 부분에서 무대에 등장하기 마련이다. 이러한 시나리오가 발생하지 않도록, 아무리 늦은 시점이라도 빌드 검증을 위한 테스트 스위트에 테스트 케이스를 추가하는 것을 두려워하지 마라.
여기서 핵심은 사이클 후반부의 프리-릴리즈 테스팅을 다른 사람들이 거부감없이 받아들이도록 해 장애없이 테스트가 진행되도록 하는 것이다. 개발자들은 그들이 노력을 쏟아부은 성과물이 허사가 될까봐 이러한 “최종” 테스트에 대해 겁먹을 수 있으므로, 당신의 프리-릴리즈 테스팅 계획이 가장 마지막 테스트 업무라고 이해시켜라. 어떻게 릴리즈 테스팅이 수행되었는지에 따라 개발팀이 움직이도록 하는 것이 아니라, 그들 자체를 아예 당신의 프리 릴리즈 테스팅 계획 속에 포함시켜 생각하라. 나는 구글에서 테스트 팀이 점점 수동 테스팅에 역량을 집중하는 것에 대해 개발자들이 이를 전폭적으로 환영하고 있다는 것을 알게 됐다. 당신의 개발팀이 안심할 수 있는 영역을 찾아내고, 충분한 시간을 가지고 적합한 수준의 테스팅을 수행하는 것과, 가능한한 마지막 몇 시간 혹은 며칠 동안을 걱정거리 없도록 만들어주는 것과의 사이에서 균형을 잡아야 한다.
당신의 테스팅 프로세스에 대해 의문을 가져보라
(Question your testing process)
모든 테스트 케이스를 읽어보고 모든 자동화 테스트를 리뷰하는 것에서부터 시작해보라. 테스트 케이스로부터 테스트 계획을 매핑시킬 수 있는가? 각 컴퍼넌트 당 얼마나 많은 테스트를 수행하는가? 기능에 대해서는? 테스팅 프로세스 외부에서 버그가 발견되었을 때 이를 위한 테스트 케이스를 추가하는가?
테스트 매니저로서 테스트가 어느 정도의 완성도와 철저함을 가지고 있는지에 대해 책임을 지는 것은 바로 당신의 몫이다. 비록 당신이 많은 테스트를 작성하거나 수행하지는 않더라도, 그들 모두를 머리 속에 담아두고 있어야 하며 변경 내역이나 현실과의 괴리를 인식할 수 있는 제일 첫 번째 사람이어야 한다. 아마도 이 일이 새로운 매니저가 부임했을 때 가장 먼저 달려들어야 할 일일 것이며 또한 오랫동안 시간을 소비해야 할 일일 것이다.
혁신할 수 있는 방법을 찾아라(Look for ways to innovate)
개발자들에게 좋은 평가를 받는 가장 쉬운 방법은 현상을 유지하는 것이다. 많은 개발 관리자들이 유순하고 그들에게 굴종하는 테스트 팀을 선호한다. 하지만 그들 역시 예측 가능하고 쉽게 이해할 수 있는 테스팅 사례를 좋아한다. 이로써 걱정거리 하나는 줄어든 셈이다(비록 명백하게 비효율적이기는 하지만, 익숙한 현재의 방법을 계속 사용하면 되니까).
새로운 매니저로서, 그렇게 쉽게 되도록 놓아두지 않는 것 또한 당신이 할 일이다! 당신은 당신이나 당신의 팀이 수행하기에 힘들거나 비효율적이라고 생각되는 프로세스의 부분들을 목록으로 만들어야 한다. 여기가 혁신을 적용해야 하는 지점이다. 개발자들로부터의 신경질적인 반응에 대비해야 한다. 당신이 직접 이런 업무를 수행하고 좋은 사례를 만듦으로써 테스팅 업계에 도움을 줄 수도 있으니 일정 기간 이 작업에 헌신해보라.
어떻게 최고의 혁신을 수행할 것인가라는 질문에 보편적으로 적용될 수 있는 답은 없다. 내가 사용했던 방법은 당신 팀 안에서 스타를 찾아내고 그 사람이 열정을 쏟아부을 수 있는 부분에 전념할 수 있도록 하는 것이었다. 이것이 관리자로서 생산성을 향상시키고 혁신을 배양하는 가장 중요한 일이라 할 수 있을 것이다.
[1] 역자 주: 원문 표현은 “Drink your product’s kool-aid”라고 되어있다. “Drink kool-aid”라는 표현은 사용자의 주관없이 제조사의 말만 믿고 덥석 제품을 사버리는 것과 같은 경우에 사용된다. 표현의 유래는 여기에서 참조.
댓글 없음:
댓글 쓰기