테스트 업계에는 여러 논쟁이 있다.
그중에 하나가 테스트와 품질보증의 관계이다. 이 논쟁은 마치 무안단물마냥.. 잊어버릴만한면 쪽쪽 빨아먹을수 있어서 좋다.
혹자는 테스트가 곧 품질보증이라 말한다.
혹자는 테스트와 품질보증은 다르다 말한다.
국내에도 분명 테스터도 많아지고 테스트 팀도 많아졌지만 적어도 내 경험상으로는 아직도 많은 테스트팀이 QA팀이라 불리는게 현실이 아닌가 싶다.
정작 하는 일은 테스트팀이면서 팀명은 QA라 붙어 있는 팀, 게임업게의 Fun QA라 불리는 조직들을 바라보는 내 시각은 허영에 쩔어있는 복부인을 바라보는 시각 그 이상도 아니고 그 이하도 아니다.
나는 QA와 테스트는 구분된다는 논지를 견지하는 사람이다. 난 외부에 내가 품질 보증에 관한 일을 할 수 있다고 얘기하지 않는다. 난 테스트를 하는 사람이고 품질을 개선하는데 약간의 도움을 줄 수 있다고 말한다.
물론 품질보증 활동의 상당한 부분을 테스트가 담당하므로 테스트가 품질보증 활동을 한다고 착각할 수 있지만 난 두 활동은 엄연히 다르다고 생각한다.
그럼 어떻게 다른것일까?
예를 들면 아래와 같은 요구사항(기능리스트)가 있다고 가정해보자.
1) 내연기관
2) 고무타이어가 달린 네개의 바퀴
3) 엔진과 구동 바퀴를 연결하는 트랜스미션
4) 금속 골격위에 설치된 엔진과 트랜스미션
5) 운전대
테스터에게 위와 같은 요구사항만 전달되어도 테스트를 하는데는 별다른 문제가 없다.
하지만 QA는 다르다.
위의 요구사항에 아래와 같은 목표가 더해지면 어떻게 될까?
6) 잔디를 쉽고 빠르게 자를 수 있음
7) 앉아 있기 편안함
위와 같은 목표가 더해진다고 해도 테스터의 입장에서는 별반 크게 달라지는 내용은 없다. 자동차와 잔디 깍는 기계의 차이는 크냐? 작냐? 의 차이일 뿐 테스트 하는 방법에서는 큰 차이가 없다.
하지만 QA라면 우리가 생산하는 제품이 정말 사용자가 원하는 제품인지 반드시 확인하고 그러한 제품이 전달될 수 있도록 개발 조직을 이끌어야 한다.
그리고 생산되는 제품들이 고객이 원하는 어떤 조건들을 지속적으로 충족시키도록 모든 제품이 동일한 품질을 가지도록 이끌어야 한다.
다른 예를 들면,
지금 여러분의 장바구니에 아래와 같은 재료들이 있다고 가정해보자.
1) 밀가루
2) 설탕
3) 우유
4) 계란
위의 재료를 가지고 무엇을 만들지를 결정하는 것은 기획의 영역이다.
어떤 과정을 거쳐 그 무엇인가를 만들지 설계하는 것은 아키텍처의 영역이다.
그리고 그것을 실제로 만들어내는 것은 개발자의 영역이다.
그 모든 것이 제대로 수행되었는지 확인하는 것은 테스터의 영역이다.
하지만 위의 모든 것을 아울러 고객이 정말로 원하는 것을 이끌어내는 것은 QA의 영역이다.
고객이 칼국수를 원할지? 빵을 원할지? 는 아무도 알지 못한다.
물론 고객이 원하는 제품을 전달하는 것이 QA의 책임만은 아니다.
모든 이해관계자가 잘 협업할 수 있어야 진정 고객이 원하는 제품이 나오게 될 것이다.
내가 생각하는 QA는 그렇게 목표를 제시하고 모두가 잘 협업할 수 있도록 이끌어주는 것이 QA라고 본다.
이것은 모든 과정이 잘 진행되어 원하는 결과물이 나오고 있는지 확인하는 테스터와는 분명 다르다고 본다.
적어도 나는 그렇게 생각한다.
(물론, 최근의 테스터라면 사용자의 목표에 맞는 테스트를 수행할 수 있어야 한다. 특히, 사용성과 같은 테스트를 수행하는 테스터라면 더욱 그러하다. 그렇다고 해도 난 테스터와 QA는 구분 된다고 생각한다.)
그중에 하나가 테스트와 품질보증의 관계이다. 이 논쟁은 마치 무안단물마냥.. 잊어버릴만한면 쪽쪽 빨아먹을수 있어서 좋다.
혹자는 테스트가 곧 품질보증이라 말한다.
혹자는 테스트와 품질보증은 다르다 말한다.
국내에도 분명 테스터도 많아지고 테스트 팀도 많아졌지만 적어도 내 경험상으로는 아직도 많은 테스트팀이 QA팀이라 불리는게 현실이 아닌가 싶다.
정작 하는 일은 테스트팀이면서 팀명은 QA라 붙어 있는 팀, 게임업게의 Fun QA라 불리는 조직들을 바라보는 내 시각은 허영에 쩔어있는 복부인을 바라보는 시각 그 이상도 아니고 그 이하도 아니다.
나는 QA와 테스트는 구분된다는 논지를 견지하는 사람이다. 난 외부에 내가 품질 보증에 관한 일을 할 수 있다고 얘기하지 않는다. 난 테스트를 하는 사람이고 품질을 개선하는데 약간의 도움을 줄 수 있다고 말한다.
물론 품질보증 활동의 상당한 부분을 테스트가 담당하므로 테스트가 품질보증 활동을 한다고 착각할 수 있지만 난 두 활동은 엄연히 다르다고 생각한다.
그럼 어떻게 다른것일까?
예를 들면 아래와 같은 요구사항(기능리스트)가 있다고 가정해보자.
1) 내연기관
2) 고무타이어가 달린 네개의 바퀴
3) 엔진과 구동 바퀴를 연결하는 트랜스미션
4) 금속 골격위에 설치된 엔진과 트랜스미션
5) 운전대
테스터에게 위와 같은 요구사항만 전달되어도 테스트를 하는데는 별다른 문제가 없다.
하지만 QA는 다르다.
위의 요구사항에 아래와 같은 목표가 더해지면 어떻게 될까?
6) 잔디를 쉽고 빠르게 자를 수 있음
7) 앉아 있기 편안함
위와 같은 목표가 더해진다고 해도 테스터의 입장에서는 별반 크게 달라지는 내용은 없다. 자동차와 잔디 깍는 기계의 차이는 크냐? 작냐? 의 차이일 뿐 테스트 하는 방법에서는 큰 차이가 없다.
하지만 QA라면 우리가 생산하는 제품이 정말 사용자가 원하는 제품인지 반드시 확인하고 그러한 제품이 전달될 수 있도록 개발 조직을 이끌어야 한다.
그리고 생산되는 제품들이 고객이 원하는 어떤 조건들을 지속적으로 충족시키도록 모든 제품이 동일한 품질을 가지도록 이끌어야 한다.
다른 예를 들면,
지금 여러분의 장바구니에 아래와 같은 재료들이 있다고 가정해보자.
1) 밀가루
2) 설탕
3) 우유
4) 계란
위의 재료를 가지고 무엇을 만들지를 결정하는 것은 기획의 영역이다.
어떤 과정을 거쳐 그 무엇인가를 만들지 설계하는 것은 아키텍처의 영역이다.
그리고 그것을 실제로 만들어내는 것은 개발자의 영역이다.
그 모든 것이 제대로 수행되었는지 확인하는 것은 테스터의 영역이다.
하지만 위의 모든 것을 아울러 고객이 정말로 원하는 것을 이끌어내는 것은 QA의 영역이다.
고객이 칼국수를 원할지? 빵을 원할지? 는 아무도 알지 못한다.
물론 고객이 원하는 제품을 전달하는 것이 QA의 책임만은 아니다.
모든 이해관계자가 잘 협업할 수 있어야 진정 고객이 원하는 제품이 나오게 될 것이다.
내가 생각하는 QA는 그렇게 목표를 제시하고 모두가 잘 협업할 수 있도록 이끌어주는 것이 QA라고 본다.
이것은 모든 과정이 잘 진행되어 원하는 결과물이 나오고 있는지 확인하는 테스터와는 분명 다르다고 본다.
적어도 나는 그렇게 생각한다.
(물론, 최근의 테스터라면 사용자의 목표에 맞는 테스트를 수행할 수 있어야 한다. 특히, 사용성과 같은 테스트를 수행하는 테스터라면 더욱 그러하다. 그렇다고 해도 난 테스터와 QA는 구분 된다고 생각한다.)
댓글
댓글 쓰기