QA팀은 없다고 생각하라

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

많은 회사들이 전문 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팀이 제 역할을 할 수 있습니다.

우리는 개발자가 테스트도 다 해요.

별도의 테스트팀이 없는 회사는 정말 많습니다.

별도의 테스트팀이 없이 개발자가 또는 팀장이 테스트에 참여하는 이유는 개발자가 아니면 제품의 기능을 속속들이 알 수 없어서 테스트를 하기가 어렵기 때문입니다. 이렇게 되는 이유는 제품의 스펙이 따로 문서화되어 있지 않기 때문에 개발자가 아니면 스펙을 알지 못하기 때문입니다.

하지만, 개발자는 인건비도 비쌀 뿐더러 테스트를 잘 하지도 못합니다. 그리고 아무리 테스트 능력이 있는 개발자라고 할지라도 자신이 작성한 기능을 테스트 하는 것은 좋은 방법이 아닙니다. 본인은 내부 동작방식을 잘 알기 때문에 기능이 정상적으로 동작하는 방식 위주로 테스트를 하기 마련입니다.

테스트는 반복적이고 전문적인 작업이기 때문에 개발자가 담당하고 있는 이상 정상적으로 이루어지고 있다고 보기 힘듭니다. 

테스트팀을 따로 두기 위해서는 기본적으로 제품의 스펙이 있어야 합니다. 그렇지 않다면 테스트 팀은 그냥 Random 테스트를 마구 해주는 아르바이트생 수준의 역할 밖에 할 수가 없게 됩니다. 실제 수많은 테스트 팀들이 그 정도 수준에서 밖에 테스트를 할 수 없는 열악한 상황에서 일을 하고 있습니다.

기본적으로 제품에 스펙이 존재를 해야 이를 토대로 테스트케이스를 만들어 낼 수 있고, Regression Test가 가능해 집니다. 그리고 테스트팀이 있다면 테스트 자동화에 대해서 좀더 연구를 하게 되고 테스트 효율성을 높이기 위한 작업들을 진행할 수 있습니다.

테스트팀을 두는 것이 비용을 줄이면서도 제품의 품질을 높일 수 있는 방법입니다. 개발 조직을 효율적으로 운영하고 싶으면 전문 테스트팀에 대해서 심각하게 고려해봐야 합니다.

누가 소스코드를 몰래 바꿔놨다.

누군가 몰래 여러분 회사의 소스코드를 바꿔놓는 일이 가능한가요? 진짜 이런 일이 일어 날 수 있는 환경이라면 당장 고쳐야 합니다.

실제로 이러한 걱정을 하는 회사도 많이 있습니다. 

영화 슈퍼맨3를 보면 한 프로그래머가 은행 이자의 우수리 돈을 자신의 계좌로 몰아서 스포츠카를 사는 장면이 나옵니다. 또, 퇴사하는 직원이 악의를 품고 소스코드를 몰래 바꿔놓지 않을까 걱정을 하기도 합니다.

정상적인 시스템과 프로세스를 갖춘 회사라면 이러한 걱정을 할 필요가 없으나 그렇지 못한 대부분의 소프트웨어 회사들에서는 언제든지 일어날 수 있는 일입니다.

정상적인 경우라면 소스코드의 모든 변경은 기록에 남게 됩니다. 또 소스코드를 변경하기 위해서는 버그ID(또는 이슈ID)가 있어야 합니다. 이것이 소스코드 변경 승인의 역할을 대신하기 때문에 소스코드를 변경 시 버그 ID가 없다면 소스코드 변경이 차단되도록 되어 있는 경우도 있습니다.

또, 버그ID도 가짜로 만들어서 등록을 했다고 하더라도, Peer review에서 이상한 코드는 발견이 되게 됩니다. Peer review를 통과 했다고 하더라도, Build팀에서 빌드를 하면서 바뀐 소스코드와 버그ID를 체크하는 과정에서 가짜 버그 ID가 발각 될 수 있습니다. 여기까지 통과를 하였다고 하더라도, 테스트에서 걸리게 되어 있습니다. 이것도 통과를 하였다고 하더라도, 모든 변경의 이력은 기록이 남아 있고, Log가 존재하므로 추후 추적이 가능해집니다.

제대로 시스템과 프로세스가 갖추어져 있다면 누가 소스코드를 마음대로 바꾸지 않을까 걱정할 필요가 없습니다. 이를 걱정하고 온갖 프로텍트 장치를 해 놓는 것은 오히려 개발 효율성을 떨어뜨리게 됩니다.

모든 것이 다 Open되어 있고 허술한 것 같아 보이지만, 이렇게 하는 것이 오히려 더 안전하고 투명하게 개발이 진행되며 생산성을 훨씬 더 높이는 방법입니다.