태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

QA팀은 없다고 생각하라

2010.10.11 18:41 by 전규현


잠시 후 Google blogger로 이동됩니다.






저는 여러 소프트웨어 회사를 접할 기회가 많기 때문에 우리나라의 소프트웨어 현실을 다양하게 보게 됩니다.

많은 회사들이 전문 QA팀없이 개발자가 테스트를 하곤합니다. 제가 접한 소프트웨어 회사들의 대략 70% 이상이 전문화된 QA가 없었습니다. 심지어는 대기업에 속한 회사들도 QA팀 없이 개발자나 팀장이 테스트를 하는 경우도 있습니다.

그 이유야 제가 이전에 여러번 언급했듯이 주먹구구식 개발이나 형식에 치우친 프로세스를 채용한 회사들은 개발자가 아니면 그 기능을 속속들이 잘 모르기 때문에 개발자나 팀장이 테스트를 할 수 밖에 없고 누가 좀 도와준다고 하더라도 Random 테스틑 밖에 수행을 하지 못합니다.

이 이슈는 차치하고 소수의 QA팀을 가지고 있는 회사들에서는 QA테스트가 제대로 이루어지고 있는지 확인을 해볼 필요가 있습니다. 제 경험에 의하면 많은 회사들이 QA팀이 있다고 하더라도 QA팀을 충분히 활요하지 못하고 있었습니다. 이런 경우들이 존재합니다.

- QA팀에게 개발자의 일을 떠넘기는 경우
QA팀이 무슨일을 하는 것인지 정확하게 모르는 경우입니다.

- QA팀에게 테스트를 할 수 있는 충분한 정보를 제공하지 않는 경우
QA팀이 있다고 해도 또 주먹구구식으로 테스트를 하거나 QA팀이 제품의 기능을 알아내기 위해서 제품을 일일이 써보는 수밖에 없는 경우입니다. 수박 겉핧기씩 테스트를 할 수 밖에 없고 많은 버그는 고객들이 찾아줍니다. 

- QA팀의 테스트 결과를 비난하는 경우
QA팀의 책임이 무엇인지 모르는 경우입니다.

이 중에서 첫번째에 대해서 얘기를 해보려고 합니다. 
소프트웨어 회사들이 QA팀 없이 개발을 하다가 QA팀이 생기고 또는 테스트 전담 인원이 생기면 개발팀의 자신들이 그동안 해 왔던 테스트를 QA팀에서 대신 해줄 것으로 착각을 하곤합니다.

엄밀히 말하면 이는 잘못된 생각입니다. 대부분의 개발자들이 하는 테스트는 QA테스가 아닙니다. 개발자들이 개발과정에서 당연히 해야할 유닛테스트와 통합테스트일 뿐입니다. 

개발자들은 자신들이 하던 테스트를 도와줄 사람이 생겼다고 생각하고 대충 구현을 해서 QA팀에 넘겨버립니다. 그러면 QA팀에서는 버그투성이인 제품을 테스트하느라고 시간을 낭비하곤 합니다. 그래서 정작 제대로 된 테스트는 해보기도 어려운 경우가 허다합니다. 이런 회사들의 특징은 개발자와 QA팀이 타이트하게 붙어서 개발자가 개발을 하는대로 바로바로 테스트를 해줍니다. 혹시 이런 형태로 개발을 하고 있다면 QA팀을 전문가로 생각하지 않고 개발팀의 심부름꾼 정도로 생각하고 제대로 활용하지 못하고 있고 생각할 수 있습니다.

개발자들은 QA팀이 없다고 생각하고 완벽하다고 생각하는 코드를 작성해서 QA팀으로 넘겨야 합니다. QA팀은 이렇게 만들어진 제품을 제대로 검증할 책임이 있습니다.

먼저 QA팀의 역할이 무엇인지 정확하게 이해해야만 QA팀이 제 역할을 할 수 있습니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
Image by episode8
 


저작자 표시 비영리 변경 금지
신고

전규현 개발조직 ,

  1. QA팀이 없다고 생각하지 않아도 실제로 없는게 참...
    좀더 많은 회사에서 제대로 된 QA팀이 운영되기를 바랍니다. ㅎㅎ

  2. 안녕하세요. 제주소년님
    회사의 규모가 얼마나 되나요? 개발자의 인원수에 따라서 QA팀을 운영하는 방법이 달라질 수 있습니다.

  3. QA팀이 개발자의 심부름꾼정도라.. 정말 동감이죠 'ㅅ'
    개발 하다가 나름 QA쪽의 비젼을 보게 되었고, 계속 개발 관련 공부도 하고 QA관련 공부도 계속하는데..

    현실은 답답하기만 하네요.
    적은 규모의 QA팀도 아니고 나름 조직 자체는 제대로 세팅되었다고 하는데..

    가장 큰 문제는 말씀해 주신대로 전체 조직의 인식인 것 같습니다.

  4. Noel님 반갑습니다.
    QA팀이 일단 세팅되면 또 새로운 도전이 시작됩니다. ^^

  5. Blog Icon
    qahuni

    반갑습니다.

    충분한 testbasis를 얻기 위해 개발프로세스와 QA의뢰절차를 개선하고 있습니다.
    개발조직에서는 문서쓰는 것을 힘들어 하고, 심지어 소비적으로 느끼고 있습니다.

    V-Model 등에서는 각 단계별로 testbasis가 산출되어야 하고, 테스트 후 testware가 산출되어야 한다고 정의합니다.

    개발조직에서는 요즘같이 빠르게 변모하고 있는 시대에 매우 뒤처질만한 행동이라고 반박합니다.

    저는 그래도, Agile이라 하더라도 정의되고 리뷰되어야 할 것들은 문서가 반드시 필요하다고 생각합니다.
    기능명세나, 기본설계서 정도는 필수라고 생각하지요.

    실제 다른 회사들은 이 문제를 어떻게 풀고들 계신지요?
    기능명세 없이 테스트를 기획할 순 없지 않을까요?

  6. 조직이 개발 Process 개선을 수행하고 계시는군요. 에자일이건 CMM이건 개발 Process의 중심은 개발하고자 하는 시스템의 유형입니다. 이것에 맞도록 구축되어야 합니다. 에자일 Process라는 분야는 아무리 봐도 정확한 철학이 없고 단지 빠른 개발이라는 마케팅 용어만 보이는데... 빨리 개발한다는 것은 그 안에 정확하게라는 단어를 포함하는 것으로 알아들어야 합니다. 그게 국제적인 관례인데, 우리는 빨리 개발한다고 하면 정말 빨리만 개발하려고 합니다. 이 부분에 대한 오해가 커질 수 있는게 우리 한국 개발문화입니다. 이 부분 진지한 대화가 필요한 분야이지요.

  7. Blog Icon
    KID

    좋은 글 잘 읽었습니다. 책 이외에서도 좋은 글을 접할 수 있었는데 모르고 살았네요..
    저희 조직도 품질이라는 것을 어떻게 해결해야하나 고민중이고. 테스트 엔지니어를 뽑고 면접을 보는 등의 진행이 되고 있습니다.

    한가지 문의 드리고 싶은 사항은 QA 담당자의 개발 경력은 필수인가 아닌가입니다.
    제가 품질 분야 지식이 약해서 우둔한 질문인듯 합니다만, 제 생각에는 개발 경력을 가진 사람이 품질쪽으로 경력이 쌓여져 왔다면 좋은 자원일 수 있다고 생각했습니다.

    하지만 현실에서는 개발 경력을 가지고 품질쪽 업무를 수행하는 사람을 찾기 어렵습니다.
    모집을 하면 말씀하신 것처럼 개발자의 테스트 업무를 대신 수행하는 역할을 주로 해온 분들이 대부분입니다.
    이 상황을 겪다 보니 QA는 개발 경력이 없어도 정말 업무 수행이 가능한건가? 라는 생각이 들었습니다. 개발 경력이 있어야 QA 역할을 더 잘 할 수 있을 것이라고 여기고 있었는데.. 실제 현실은 그렇지 않은것 같습니다.

    어떤 것이 맞는 것일지 고견을 부탁드립니다.

  8. 개발자 경력이 있다면 기획, QA, Tech support 심지어 경영까지 다 도움이 되겠지만, QA엔지니어에게 꼭 개발경력이 필요한 것은 아닙니다.

    개발경력이 있다면 QA엔지니어 업무에서 도움이 되는 경우도 있습니다. White box 테스트도 가능하고 테스트 관련 툴도 개발할 수 있고, 테스트 케이스를 작성하더라고 개발자 관점에서 좀더 넓은 커버리지로 작성이 가능합니다. 개발자 경력이 두루두루 도움이 될 수 있지만 필수는 아닙니다.

    하지만 개발 경력이 없어도 일반적인 QA업무는 수행이 가능합니다. 문제는 스펙이 제대로 작성되지 않았다면 QA업무 전체 프로세스가 어려워집니다. 정상적인 프로세스에서는 QA엔지니어가 테스트케이스를 작성하면 개발자들이 개발자 관점에서 리뷰를 해주기 때문에 중요한 테스트 케이스가 누락되거나 하지는 않습니다.

    하지만 현실은 전문적인 QA엔지니어를 찾기가 쉽지는 않습니다. 개발자의 엉성한 테스트를 도와주는 역할을 하는데 그치는 경우가 많습니다.

    QA엔지니어의 역량 문제는 아닙니다. 개발 전체 프로세스와 문화가 문제입니다. QA엔지니어가 제한된 역할밖에 못한다면 개발자 출신 QA를 뽑을 것이 아니라 프로세스와 개발 문화가 잘못되어 있는지 알아봐야 합니다.

블로그 호스팅을 Google Blogger로 이전합니다.

최근에 블로그에 보안 문제가 발생하여 좀더 안정적으로 블로그를 운영하기 위해서 Google Blogger로 이전합니다. 기존에 http://allofsoftware.net 과 http://www.allofsoftware.net..

한국어(한글) 코드 이야기 (8)

유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코..

유니코드 영토 전쟁의 승리자는? (7)

이번에는 유니코드의 코드 체계에 대해서 간단하게 알아보고자 한다. 소프트웨어 국제화를 필요로 하는 개발자라면 자주는 아니지만 유니코드 내부 코드 체계를 알아야 할 때가 있다. 다양한 플랫폼에서 개발을 할 때 폰트 등과 관련하..

유니코드는 어떻게 탄생했을까? (6)

소프트웨어 국제화를 이해하기 위해서는 유니코드에 대해서 필수적으로 잘 알아야 한다. 유니코드란 말을 들어보지 않은 개발자는 없지만 관련 용어가 매우 많아서 종종 헷갈린다. 게다가 유니코드가 탄생한지 20년도 더 넘었지만 아직..

직원을 잠재적인 도둑 취급하는 회사

필자는 몇 년 전 A그룹에 강연을 하러 갔다가 곤란한 일을 겪은 적이 있다. 한국 대부분의 대기업이 그렇듯이 보안이 매우 엄격한 회사였다. 나는 직원들의 안내대로 메모리, 외장하드를 모두 빼놓고 회사로 들어갔다. 하지만 강연..

외국에서 팔리는 소프트웨어의 아키텍처 디자인 원칙 (5)

김과장은 그 동안 한국어만 지원하는 소프트웨어 A를 개발해 왔는데 최근에 사장님이 A의 일본어 버전을 만들라고 했다. 그리고 개발 기간도 한달 밖에 주어지지 않았다. 그래서 기존 소스코드를 복사해서 한국어가 들어 있는 모든 ..

소프트웨어 개발자 성장에 꼭 필요한 리뷰

우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있..

외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4)

10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서..

독일어 버전 소프트웨어란 말이 잘못된 이유 (3)

본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다. 경영자..

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든..