2015. 1. 4. 00:54

이번 글의 주제는 조금 자극적이게 뽑아 보았습니다. 지난 번 글과 다르게 조금은 지루할 수 있는 글이거든요. 


이번 글 역시 한국 QA업계의 문제점들을 짚어가기 위한 해설 중 하나입니다. 본 글은 많이들 궁금해 하시는 부분들에 대한 단편적인 이야기이며, 완전한 "QA 채용에 관한 팁(주제 미정)" 이라는 주제로 쓰는 글은 다시 정리하여 전문가의 리뷰 후 대한민국 소프트웨어 품질 연구소에 공개될 예정입니다.


(1) Checker와 Tester의 차이는 지난 번 글인 "품질관리 업의 확장과 빠른 시장 대응 가능성에 대한 괴상한 상상"에서도 언급하였지만, 외국의 저명한 품질관리 전문가들이 정의한 바를 참고하세요.

(2) 일단 필자는 QM/QE/QA/QC/Testing/Checking에 대한 구분을 하고 싶지만, 이 글을 읽으시는 분들이 그것부터 이해하기를 바라긴 힘들기 때문에 이 글에서는 일반적으로 회사들에서 사용하는 바와 같이 뭉뚱그려 "QA조직" 이라고 칭하겠습니다.


글 시작합니다.


당신의 QA 조직이 실패한 이유

(부제 : 효율적인 Tester 채용을 해 보자.)


여러 사람들, 특히 스타트업이나 신규 사업하시는 분들을 만나면 늘 듣는 이야기 중 하나는 "우리도 훌륭한 QA 필요한데..." 입니다. 그래서 그 회사의 구조를 보면 QA를 채용해서 Checker 정도로 운영하고 있는 업체가 대부분입니다.


사실 이야기는 굉장히 단순합니다. 거의 모든 업체에서 벌어지는 현상이 동일하기 때문입니다.


(1) 대부분의 업체들이 어느 정도 사업이 안정화되는 시점에는 품질경영으로 눈을 돌리기 시작하면서 '고객 관점의 검증'을 필요로 하게 됩니다.

(2) 그리고 Quality Assurance, 품질 보증이라고 하는 조직이 있다는 것을 알게 되고 조직을 꾸리고 채용을 시작 합니다.

(3) 그러고 나서는 대부분의 업체에서 이들을 고객 접점의 품질을 검증하는 Tester로 이용합니다. 사업/기획/개발에서 놓칠 수 있는 실수들을 잡아내려는 시도이지요.

(4) 그런데 인간이라는 것은 기댈 곳이 있으면 조금 나태해지기 마련입니다. 사업/기획/개발은 Tester들이 그들이 놓친 부분을 잡아 줄 것이라 생각하고 스스로 테스트하지 않기 시작합니다.

<그림 출처 - Jomit's blog - Test is dead>

(5) (사업/기획/개발에서 테스트에 참여하지 않기 때문에) 한정된 인력으로 모든 이슈를 잡아내기 힘든 Test 조직은 이내 덩치가 커지기 시작합니다. 그리고 그 늘어나는 수요를 감당하기 위해 대규모 팀이 되거나, 계약/파견/외주를 찾아 조직의 모습이 변하기 시작합니다.

(6) 그런데 말입니다, 프로세스의 끝에서 모든 이슈를 처리하는 것은 소프트웨어 공학에서는 ROI(Return on Investment) 측면에서 지양하고 있습니다. 가능한 QA를 사업단의 요구사항 분석까지 참여시키라고 말합니다. 그리고 앞서 말한 (5)번의 구조로는 Test를 위해 채용한 낮은 수준의 인력, 계약/파견/외주로는 이 부분을 해결하지 못합니다. 그래서 그들은 단순반복 업무의 굴레, 그 쳇바퀴를 돌리기 시작합니다.

(7) 결국 Tester들은 '단순 반복 테스트'의 굴레에서 벗어나기 위해 기획자가 되거나, 개발자가 되거나, 단순 테스트를 하지 않게 해줄 업체로 이동합니다. (인력 이탈이 시작되고, 남은 인력들은 개선의 의지가 없이 현실과 타협하고 일하는 인력들이 남게될 경우도 있지요.)

(8) 이 과정에서 대부분의 회사들은 프로세스 개선의 기회를 놓치고, 프로세스를 개선하기 위해 프로젝트 관리자를 뽑아 해결하려 하거나 애자일을 조직에 도입하여 해결하려고 합니다. 그리고 프로젝트 관리자나 스크럼마스터들이 프로젝트를 관리할 사람이지 품질을 관리할 사람이 아니라는 것을 이해하지 못한 채 "원래 소프트웨어 품질관리는 어려워" 라며 체질 개선에 실패하게 됩니다.


자, 앞서 말 한 바와 같이 위의 과정은 지금 이 글을 읽으시는 분들의 회사에서만 발생하는 일이 아니라, 대부분의 대한민국 소프트웨어 업체에서 발생하는 일이라고 이해하시면 됩니다. ('구글은 이렇게 테스트한다' 라는 책의 서문에 보면 심지어 구글도 10년 전에는 그랬다고 합니다.) 위의 흔한 시나리오에는 몇 가지 주목할만한 방점들이 존재하는데, 일단 그 부분들을 짚고 넘어가야 이후에 필자가 하려는 말들이 이해가 되실겁니다.


첫 번 째 문제는 21세기 소프트웨어 서비스의 대부분은 '고객 관점에서' 검증하는 것이 상당히 어렵다는 점입니다. 그 이유는 소프트웨어가 복잡해져서가 아니라, 고객의 니즈(needs)가 다변화되었고, 예전에는 기능품질(functional quality)로 분류되던 요소들이 비기능품질(non-functional quality)로 이동되어 개발 시 재-고려되어야 하기 때문입니다.


두 번 째 문제는 Test 조직을 뽑아 사업/기획/개발에 투입된 인력들의 Test 시간을 줄이고 그들이 보직에 맞는 일만 진행하면 품질이 나아질 것이라 착각하는 부분입니다. 그렇게 회사의 구성원들은 (4)번에 익숙해지기 시작합니다. 앞에서 간단히 막을 수 있는 일들을 정상적으로 관리하지 못해서 프로세스의 뒷단까지 연결되면, 그 일은 단순히 처리하지 못할 일로 변모하게 됩니다. 즉, 정말 효율적인 방법은 사업/기획/개발 등 각 단계에서 선행 테스트를, 각 담당자들이 먼저 진행해야 한다는 점이지요.


세 번 째는 QA든, 프로젝트 관리자이든, 스크럼마스터이든간에 좋은 '사람을 뽑아 놓으면 품질을 저절로 보장될 것'이라는 막연한 "품질에 대한 무지", 그에 대한 문제입니다. '우리 회사의 품질이 무엇인가' 에 대한 정의를 세우지 못하는 부분이 사실은 이 모든 사안들의 근본적인 문제입니다. 품질이 어디에서 오는지, 우리 회사의 품질은 무엇인 지에 대해 고민하지 않고, 이를 단순히 품질조직에 맡겨버리는 경우가 많습니다. 품질에 대한 정의는 최고 경영자가 언급 해야 하는 것입니다. (물론 경영진들이 품질 전문가가 아니기 때문에 전문가인 품질조직에 의뢰하는 것은 옳습니다.)


그 외에도 짚고 넘어가야할 부분들이 많지만 이번 포스팅에서는 위의 세 가지 정도로만 짚어 가도록 하겠습니다. 사실 QA가 프로젝트 내에서 정상적인 역할을 찾지 못하는 이 모든 문제들은 소프트웨어 시장에 소프트웨어 프로젝트 관리를 정상적으로 하는 PjM(Project Manager)들이 많지 않다는 점에서 기인합니다. PMBOK(Project Management Body of Knowledge) 한 번 안 읽어보고 PjM이 된 사람들도 많을 뿐더러, PMP(Project Management Professional) 자격증 공부를 한 뒤에도 '이론과 실무는 다르다'는 아집에 사로잡혀 공학을 현실 적용하려고 들지 않기 때문에 발생하는 여러가지 문제들로 인해 도출되는 결과가 품질관리 이슈입니다.


'이론과 실무는 다르다' 라고 생각하시는 분들은 "과학과 공학의 차이(Science vs Engineering)"에 대해 먼저 공부하시길 바랍니다. 검색 엔진에서 한글, 또는 영문으로 검색해 보세요.


<출처 - Science VS. Engineering>


너무 난해한 이야기들을 했던 것 같네요. 조금은 이해하기 쉬운 실-사례를 들어 보겠습니다. QA조직의 채용을 진행할 때는 먼저 자사의 품질 특성, 기술 특성들을 파악해야 합니다. 실제 예제를 보시죠.


QA 사전 평가 문제 예제


[ 상 황 ]

(1) 프로젝트 : Android용 모바일 App 테스트 프로젝트

- 프로젝트 세부내용 : Rails로 구성된 서버에서 푸싱(pushing)으로 DB에서 정보를 전달받는 서비스, 모바일 뷰 내에서 웹뷰를 사용하는 페이지가 존재하는 하이브리드앱 개발

(2) 개발 접근 방법 : 폭포수 방식으로 개발이 진행되고 있는 모바일 개발 환경

(3) 테스트 환경 : 서로 사양이 다른 Android Device 4대

(4) 인력 : 자신 포함 3인 (자신 : Lead)

(5) 할당된 작업 기간 : 2주

(6) 문서 : 존재하지 않음


[ 문 제 ]

(1) 본 프로젝트의 테스트에 필요한 가능한 모든 수행 방법들을 시작부터 종료까지 작성하시오.

(2) 테스트 수행 시 고려해야 할 사항들과 해결 가능한 방법들을 기술하시오.



위의 사전 평가 문제는 문제를 낸 사람이 지원자에게 어떤 기술 능력을 보고 싶은 지에 대해 기술합니다. 위의 문제는 다음의 지식과 경험들을 물어 보기 위한 문제입니다.

  • Android 모바일 App의 특성에 대한 지식
  • Rails 서버의 특징에 대한 지식
  • Pushing과 Polling에 대한 차이
  • Database가 Mobile에서는 어떻게 작동하는 지
  • Mobile View와 Webview에 대한 지식
  • Hybrid App과 Native App, Web App에 대한 차이
  • 폭포수 개발 접근 방식에 대한 이해 (혹은 지원자가 자신은 애자일만 경험해 봤다고 하면 기술하도록 할 것.)
  • 모바일 디바이스 테스트 환경에 대한 이해
  • 인력 배분 및 활용에 대한 이해
  • 작업기간 내 할 수 있는 테스트 활동들을 계획할 수 있는 지에 대한 역량
  • 테스트 계획/분석/설계/구현/수행/검증/종료 등 테스트의 세부 단계에 대해 이해
  • 문서나 정보가 존재하지 않을 때 탐색적 테스팅을 통해 제품의 요구사항을 역-도출, 분석, 설계하고 테스트 계획/케이스 구현을 도출할 수 있는 지에 대한 역량 (일반적으로 공부안하는 테스터들은 탐색적 테스팅이 경험에 기반한 케이스 도출이라고만 알고 있기 때문.)


QA조직의 채용을 진행할 때 사전 평가 문제를 보내는 것은 몇가지 장점이 있습니다.

(1) 지원하는 회사의 도메인을 명확히 알고 있는 가에 대해 물어 보는 것이며, 보유한 경력과 맞지 않는 도메인의 경우 짧은 시간 안에 해당 도메인을 어느 정도나 파악할 수 있는 지 능력을 평가해 볼 수 있습니다.

(2) 같은 도메인의 업체라 하더라도, 업체마다 QA조직을 활용하는 방법이 다릅니다. 지원자가 과거 어떤 경험을 해왔는 지 답변을 통해 파악해 볼 수 있습니다.

(3) 또한, 면접 진행 시 지원자에게 쓸데 없는 질문으로 시간을 끄는 것이 아닌, 사전 평가 문제의 답변을 기준으로 면접의 본질인 역량 평가에 쉽게 다가갈 수 있습니다.


몇 가지 팁을 드리자면 이런 방식의 사전 평가는 온라인으로 접수 시 제출되는 것이 좋습니다. 필자 역시 온라인 제출과 면접 당일 출시 등 몇 가지 방법을 진행해 보았는데, 면접 당일 문제를 출시하면 지원자들의 멘탈이 면접 전에 붕괴되어 버립니다. 같은 이유겠지만 온라인으로 제출 시 지원자가 자신의 길이 아니라고 생각하면 중도 포기하는 경우가 많았습니다. 즉, 면접관으로써 면접 시간을 줄이는 데에도 한 몫하는 방법입니다.


노파심에 주의사항을 한 가지 드리자면, 사전 질문에 대한 답변으로 사람을 판별해선 안되며 사전 질문에 대한 답변은 면접 시 지원자와의 원활한 질답을 위해서 사용해야 합니다. 쉽게 말해 이력서 리뷰 후 면접을 볼 가치가 없다고 생각되면 사전 평가도 진행하지 않으면 됩니다. 왜냐하면 정말 기술적으로 실력이 있는 사람이 단순히 문서 정리를 못하거나 표현을 못할 수 있기 때문입니다. 문서만으로 사람을 판단하는 오류를 범하지 않도록 하세요.


이 방식을 어떻에 이용하는 지는 오프라인 술자리의 안주거리로 미뤄두고, 결국 이런 문제를 내기 위해서는 자신의 회사에서 사용하는 기술과 품질에 대한 정의가 되어 있어야 한다는 말씀만 드리고 글을 마무리하려 합니다. 이런 정의는 각 조직과 제품의 특징에 따라 기능품질만으로 이루어져 있을 수도 있고, 비기능품질이 고려되었을 수도 있습니다. 그리고 이에 대한 고려 시에는 사용하고 있는 개발환경과 형상관리에 대한 개념까지 잡아 두는 것이 가장 좋습니다.


오늘은 관련된 분야의 배경지식 없이 읽으시기기에는 조금 난해한 이야기임을 알고 있습니다. 게다가, 원래 쓰려고 했던 글의 중간 부분만 빼내어 쓰다보니 결론이 두서 없이 정보 전달만 한 채 끝마치게 되네요. 일단 글을 맺습니다. 다들 행복한 2015년 시작하세요.



Posted by 『 Lv8+の 꽃怪獸 』 천년나무