많은 회사들이 전문 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팀이 제 역할을 할 수 있습니다.
QA팀이 없다고 생각하지 않아도 실제로 없는게 참...
답글삭제좀더 많은 회사에서 제대로 된 QA팀이 운영되기를 바랍니다. ㅎㅎ
안녕하세요. 제주소년님
답글삭제회사의 규모가 얼마나 되나요? 개발자의 인원수에 따라서 QA팀을 운영하는 방법이 달라질 수 있습니다.
QA팀이 개발자의 심부름꾼정도라.. 정말 동감이죠 'ㅅ'
답글삭제개발 하다가 나름 QA쪽의 비젼을 보게 되었고, 계속 개발 관련 공부도 하고 QA관련 공부도 계속하는데..
현실은 답답하기만 하네요.
적은 규모의 QA팀도 아니고 나름 조직 자체는 제대로 세팅되었다고 하는데..
가장 큰 문제는 말씀해 주신대로 전체 조직의 인식인 것 같습니다.
Noel님 반갑습니다.
답글삭제QA팀이 일단 세팅되면 또 새로운 도전이 시작됩니다. ^^
반갑습니다.
답글삭제충분한 testbasis를 얻기 위해 개발프로세스와 QA의뢰절차를 개선하고 있습니다.
개발조직에서는 문서쓰는 것을 힘들어 하고, 심지어 소비적으로 느끼고 있습니다.
V-Model 등에서는 각 단계별로 testbasis가 산출되어야 하고, 테스트 후 testware가 산출되어야 한다고 정의합니다.
개발조직에서는 요즘같이 빠르게 변모하고 있는 시대에 매우 뒤처질만한 행동이라고 반박합니다.
저는 그래도, Agile이라 하더라도 정의되고 리뷰되어야 할 것들은 문서가 반드시 필요하다고 생각합니다.
기능명세나, 기본설계서 정도는 필수라고 생각하지요.
실제 다른 회사들은 이 문제를 어떻게 풀고들 계신지요?
기능명세 없이 테스트를 기획할 순 없지 않을까요?
QA 팀은 없다고 생각하라라는 글을 읽다보니 문득 어린 시절 소프트웨어 QA의 추억이 떠오른다. 아무 것도 모르는 어린 시절이었지만 항상 기본으로 돌아가서 보는 것을 습관 삼는 것도 괜찮겠..
답글삭제좋은 글 잘 읽었습니다. 책 이외에서도 좋은 글을 접할 수 있었는데 모르고 살았네요..
답글삭제저희 조직도 품질이라는 것을 어떻게 해결해야하나 고민중이고. 테스트 엔지니어를 뽑고 면접을 보는 등의 진행이 되고 있습니다.
한가지 문의 드리고 싶은 사항은 QA 담당자의 개발 경력은 필수인가 아닌가입니다.
제가 품질 분야 지식이 약해서 우둔한 질문인듯 합니다만, 제 생각에는 개발 경력을 가진 사람이 품질쪽으로 경력이 쌓여져 왔다면 좋은 자원일 수 있다고 생각했습니다.
하지만 현실에서는 개발 경력을 가지고 품질쪽 업무를 수행하는 사람을 찾기 어렵습니다.
모집을 하면 말씀하신 것처럼 개발자의 테스트 업무를 대신 수행하는 역할을 주로 해온 분들이 대부분입니다.
이 상황을 겪다 보니 QA는 개발 경력이 없어도 정말 업무 수행이 가능한건가? 라는 생각이 들었습니다. 개발 경력이 있어야 QA 역할을 더 잘 할 수 있을 것이라고 여기고 있었는데.. 실제 현실은 그렇지 않은것 같습니다.
어떤 것이 맞는 것일지 고견을 부탁드립니다.
개발자 경력이 있다면 기획, QA, Tech support 심지어 경영까지 다 도움이 되겠지만, QA엔지니어에게 꼭 개발경력이 필요한 것은 아닙니다.
답글삭제개발경력이 있다면 QA엔지니어 업무에서 도움이 되는 경우도 있습니다. White box 테스트도 가능하고 테스트 관련 툴도 개발할 수 있고, 테스트 케이스를 작성하더라고 개발자 관점에서 좀더 넓은 커버리지로 작성이 가능합니다. 개발자 경력이 두루두루 도움이 될 수 있지만 필수는 아닙니다.
하지만 개발 경력이 없어도 일반적인 QA업무는 수행이 가능합니다. 문제는 스펙이 제대로 작성되지 않았다면 QA업무 전체 프로세스가 어려워집니다. 정상적인 프로세스에서는 QA엔지니어가 테스트케이스를 작성하면 개발자들이 개발자 관점에서 리뷰를 해주기 때문에 중요한 테스트 케이스가 누락되거나 하지는 않습니다.
하지만 현실은 전문적인 QA엔지니어를 찾기가 쉽지는 않습니다. 개발자의 엉성한 테스트를 도와주는 역할을 하는데 그치는 경우가 많습니다.
QA엔지니어의 역량 문제는 아닙니다. 개발 전체 프로세스와 문화가 문제입니다. QA엔지니어가 제한된 역할밖에 못한다면 개발자 출신 QA를 뽑을 것이 아니라 프로세스와 개발 문화가 잘못되어 있는지 알아봐야 합니다.
조직이 개발 Process 개선을 수행하고 계시는군요. 에자일이건 CMM이건 개발 Process의 중심은 개발하고자 하는 시스템의 유형입니다. 이것에 맞도록 구축되어야 합니다. 에자일 Process라는 분야는 아무리 봐도 정확한 철학이 없고 단지 빠른 개발이라는 마케팅 용어만 보이는데... 빨리 개발한다는 것은 그 안에 정확하게라는 단어를 포함하는 것으로 알아들어야 합니다. 그게 국제적인 관례인데, 우리는 빨리 개발한다고 하면 정말 빨리만 개발하려고 합니다. 이 부분에 대한 오해가 커질 수 있는게 우리 한국 개발문화입니다. 이 부분 진지한 대화가 필요한 분야이지요.
답글삭제