소프트웨어를 개발하기 위해서는 수많은 이해관계자가 협업을 하게 되어 있다.
대표적으로 개발자, 기획자, 디자이너, 테스터, 사용자 등을 들 수 있다.
그중에서 누가 누가 더 중요한가에 대해 얘기를 나누다 보면 결국에 테스터는 있어도 그만 없어도 그만이라는 식이 된다.
왜 테스터는 그런 대우를 받는 것일까?
이런 저런 이유가 많겠지만 가장 간단한 것은 역시나 성과가 눈에 보이는가에 따른 것이 아닐까?
'우리가 미처 알지 못한 소프트웨어 공학의 사실과 오해'라는 책에 보면 '단단한 것이 부드러운 것을 몰아낸다' 라는 옛 말을 소개하고 있다.
짧은 말이지만 아주 간단하게 우리의 인식의 범위를 설명하는 문구가 아닐 수 없다.
우리는 눈에 보이는 것, 측정 가능한 것만을 우선시 하는 경향이 강하다.
개발자는 개발 산출물 자체를 우리는 눈으로 학인할 수 있다. 디자이너의 화려한 그래픽 효과도 확인이 가능하다.
구현된 시스템은 기획자의 몫이 된다.
하지만 테스터는 어떨까? 테스터가 열심히 테스트를 해서 소프트웨어에 잠재되어 있던 1000개의 결함 중 출시 전에 800개를 해결했다.
하지만 그래도 아직 200개의 결함이 남아있다. 결함이 줄어든 것은 실제로 확인하기 어렵다. 확인 가능한 것은 어쨌든 아직까지 결함이 존재한다는 것이다.
품질은 측정하기 어렵다. 하지만 예산과 일정은 측정하기 상대적으로 쉽고 인식하기도 쉽다.
측정 가능한 것은 측정하기 어려운 것에 대한 관심을 사라지게 하는 효과가 있다.
그렇다면 우리가 테스팅에 대한 관심을 높이기 위해서는 어떻게 해야만 하는 것일까?
대표적으로 개발자, 기획자, 디자이너, 테스터, 사용자 등을 들 수 있다.
그중에서 누가 누가 더 중요한가에 대해 얘기를 나누다 보면 결국에 테스터는 있어도 그만 없어도 그만이라는 식이 된다.
왜 테스터는 그런 대우를 받는 것일까?
이런 저런 이유가 많겠지만 가장 간단한 것은 역시나 성과가 눈에 보이는가에 따른 것이 아닐까?
'우리가 미처 알지 못한 소프트웨어 공학의 사실과 오해'라는 책에 보면 '단단한 것이 부드러운 것을 몰아낸다' 라는 옛 말을 소개하고 있다.
짧은 말이지만 아주 간단하게 우리의 인식의 범위를 설명하는 문구가 아닐 수 없다.
우리는 눈에 보이는 것, 측정 가능한 것만을 우선시 하는 경향이 강하다.
개발자는 개발 산출물 자체를 우리는 눈으로 학인할 수 있다. 디자이너의 화려한 그래픽 효과도 확인이 가능하다.
구현된 시스템은 기획자의 몫이 된다.
하지만 테스터는 어떨까? 테스터가 열심히 테스트를 해서 소프트웨어에 잠재되어 있던 1000개의 결함 중 출시 전에 800개를 해결했다.
하지만 그래도 아직 200개의 결함이 남아있다. 결함이 줄어든 것은 실제로 확인하기 어렵다. 확인 가능한 것은 어쨌든 아직까지 결함이 존재한다는 것이다.
품질은 측정하기 어렵다. 하지만 예산과 일정은 측정하기 상대적으로 쉽고 인식하기도 쉽다.
측정 가능한 것은 측정하기 어려운 것에 대한 관심을 사라지게 하는 효과가 있다.
그렇다면 우리가 테스팅에 대한 관심을 높이기 위해서는 어떻게 해야만 하는 것일까?
저도 회사에서 지원을 원하면 성과를 보이라는 말을 자주 들었습니다만... 과연 '테스터가 보여줄 수 있는 성과란 무엇인가'와 '기업이 원하는 성과'가 일치할 수 있는 가에 대해서 고민해 볼 필요가 있을 것 같습니다.
답글삭제