[번역] QA는 테스터인가 아닌가

Patrick Prill 이 그의 블로그 Test Pappy에 올린 "QA People are not testers, or are they?"를 번역했습니다. 

QA라는 명칭의 정의에 대해, 그리고 소프트웨어 테스터와의 관계에 대해서는 국내에서도 오랫동안 논의가 되어 왔습니다. 역자 개인적으로도 QA와 테스터는 동일하지 않으며, QA가 품질 보증(Quality Assurance)보다는 품질 지원(Quality Assistance)에 가까운 역할을 수행하고 있지 않나라는 생각이 듭니다. 

이 글 말미에 링크로 표시된 "Testers: Get out of the Quality Assurance Business"도 일독해 보시기를 권장합니다. 

번역과 블로그 게제에 대해서는 원 저자의 승인을 받았습니다.  

 

 

수많은 소프트웨어 회사에 QA(Quality Assurance)라고 부르는 테스터와 테스트 부서가 존재한다. 지금까지 QA와 테스터가 같은 것이냐 아니냐를 두고 아주 오래된 논쟁이 진행되어 왔다. 짧게 정리하자면, 그들은 같은 사람들이 아니다! 하지만 QA로 일하는 사람들은 훌륭한 테스터가 갖추어야 할 다양한 스킬을 보유하고 있어야만 한다.

 

나의 공식적인 직함은 QA 리드이지만, 때로는 의도적으로 테스트 리드라는 명칭을 사용하기도 한다. 나는 사인을 할 때도 이름과 함께 이 직함을 자랑스럽게 표시한다. 그 이유는 이 명칭이야말로 내가 하고 있는 일을 보여주고 있는 것이며, 나의 JD(Job Description)에도 포함되어 있는 부분이기 때문이다. 소프트웨어 테스터들을 QA라고 부르는 것은, 품질을 보증할 수 있는 다양한 “생산” 프로세스가 존재한다는 것을 은연 중에 암시하고 있는 것이다. 하지만 이는 사실과 다르다!

 

‘품질 보증’이라는 단어는 제조업에서 유래한 것이다. 제조업에서 QA로 일하는 사람들은 생산 프로세스를 모니터링하고 검사한다. 또한 사전에 정의된 프로세스 모델, 즉 회사의 입장에서 최적의 방식으로 제품을 생산하기 위해 고안된 방식에 맞추어 일이 진행되고 있는지를 검사한다. 이런 방식을 통해 공장에서 출고되는 제품 각각의 품질이 가능한 비슷하며, 회사의 표준을 충족한다는 것을 입증할 수도 있을 것이다. 위키피디아에 올라와 있는 Quality Assurance 와 Software Quality Assurance 항목을 읽어보라.

 

이 주제에 대한 나의 의견은 다음과 같다. QA로 일하고 있는 사람들은 테스터이지만, 그들이 테스트하는 것은 소프트웨어나 제품이 아니라 프로세스와 프로세스 모델이다. 이를 제대로 수행하기 위해 훌륭한 테스터들이 보유하고 있는 스킬 셋과 유사한 스킬을 보유해야 하며, 때로는 그 이상의 것들이 필요하기도 하다(테스터들이 보유하고 있다고 해도 전혀 손해 될 것들이 아니다). 정보를 수집하고, 프로세스를 분석하고, 프로젝트를 조사하고 검사하며, 모델을 생성하고, 품질 관문을 모니터링하고, 수많은 질문을 던지고, 이해관계자들에게 당신이 발견한 현재의 상황을 보고하는 것들이 QA로서 당신이 해야 하는 일이다. 하지만 직접 소프트웨어를 테스트하지는 않는다.

 

소프트웨어 테스팅은 소프트웨어 개발 프로세스에서 하나 혹은 그 이상의 단계에 속하며, QA는 이런 단계들이 현재의 프로젝트에 포함되어 있는지, 그리고 프로세스에 따라 수행되고 있는지를 확인한다.

 

개인적인 의견으로는 제조업에서 유래한 단어와 역할을 그대로 IT 환경에 가져옴으로써 문제가 발생하고 있다고 본다. 소프트웨어 개발은 고유한 영역이다. 동일한 소프트웨어를 두 번 생산할 수 없다. 소프트웨어 개발, 혹은 이를 제품 개발이나 프로젝트 비즈니스라고 부를지라도, 이 모든 것들은 프로젝트라고 볼 수 있으며, 이 모든 프로젝트의 기반이 되는 법칙 중 하나는 바로 이들이 각각 고유하다는 것이다! 많은 경우 제조업에서 유래한 단어를 그냥 사용하는 것이 도움이 되지 않는데, 그 이유는 IT와 제조업이 서로 다르기 때문이다. QA라는 단어를 사용하게 되면 엄격하게 계획을 수립하고 꼼꼼하게 이를 관리함으로써, 혹은 우연하게라도 IT 프로젝트를 제조업처럼 관리 가능하다는 환상을 심어주게 되는 것이다. 프로세스 모델을 표준화하면 매번 바라는 결과를 얻을 수 있다고 믿는 것은, 개인적으로 위험한 발상이라고 생각한다.

 

소프트웨어 개발 프로세스는 수많은 단계와 다양한 역할, 프로젝트에 참가하는 집단에 의해 달라지기 마련이다. 사람들은 사전에 정의된 역할과 프로세스 모델, 표준이나 그 밖에도 준수해야 하는 여러 규칙에 따라 각 단계를 수행해야 하는 책임이 있다. 개발자들에게는 스타일 가이드나 명명 규칙(Naming conventions), 코드 리뷰나 유닛 테스트 작성 법칙과 같이 코드를 작성할 때 따라야 하는 일정한 규칙이 존재한다. 우선 이런 규칙을 지켜야 하는 책임은 바로 개발자들에게 있다. 하지만 일부 회사에서는 QA라고 부르는 부서의 사람을 정기적으로 보내 이런 프로세스가 제대로 지켜지고 있는지, 모든 규칙이 준수되고 있는지, 또한 그들이 수집한 피드백에 따라 프로세스가 개선되고 있는지를 지켜보도록 하고 있다.

 

앞서도 말했듯이 QA로 일하고 있는 사람들에게 필요한 스킬 셋은 테스터와 유사하다. 그들은 프로세스를 테스트하기 때문이다. 만약 당신의 직업이 소프트웨어를 테스트하는 것이라면, 당신은 QA 팀의 일원이라고 볼 수 없으며, 대신 QA 프로세스의 일부에 속한다고 볼 수 있을 것이다.

 

자, 나는 이제 이 글을 쓰도록 마음먹게 만든 블로그의 제목으로 이 글을 마무리하려고 한다.

 

테스터들이여, QA의 굴레에서 벗어나라!