노무현 대통령 배너


오늘 ZD Net에 실린 칼럼 하나가 눈에 띕니다.

[칼럼] SW 품질관리와 테스트에 대한 단상

최근 문제가 되는 전산 시스템의 총체적 이슈를 해결하기 위해서는 테스트가 필요하다. 그래서 테스트에 대한 잘못된 인식과 필요성을 설명하겠다는 논지의 글입니다. 몇가지 논지를 집어보려 합니다.
하지만 위에 얘기한 것처럼 기획/설계 단계에서부터 테스트 컨설턴트가 함께 참여했다면 제 3자에 의한 단위테스트가 가능하며, 이렇게 개발과 테스트의 분리는 기존 개발자들이 테스트에 뺏기는 시간과 비용을 줄여서 원래의 목적인 개발에 집중할 수 있도록 도와준다.
단위테스트를 굳히 제3자가 하도록 하는게 필요한지 의문입니다. 오히려 개발자의 테스트 역량을 키워서 개발자가 제대로 하게 하는게 맞지 않나 하는 생각이 들구요.
애자일 방법론에서 추구하는 가장 이상적인 테스팅은 개발과 테스팅이 동시에 완료되는 구조다. 소위 말하는 테스트 주도 개발(TDD: Test Driven Development)이 이런 방식이다. 많은 SI 조직에서 애자일 방법론에 대해서 비현실적이라고 말한다. 하지만 TDD만큼은 애자일 방법론에서 가장 SI에 적합한 방법론이라고 생각한다. 많은 프로젝트에서 개발조직과 테스트조직은 좋은 관계를 유지할 수 없다. 하지만 TDD의 경우 개발자가 테스터고 테스터가 곧 개발자이기 때문에 감정이 상할 일이 많지 않다. 물론 개발기간이 좀 늘어날 수는 있겠지만 이제는 일단 만들어놓고 보자 식의 개발은 지양되어야 할 것이다.
SI 프로젝트에서 일하는 테스트조직은 테스트 엔지니어가 아니라 테스터인 경우가 많습니다. 둘 간의 차이를 저는 엔지니어링 역량으로 봅니다. 쉽게 말해 개발자 만큼 코드를 이해하고 자동화된 테스트 환경이나 테스트 코드를 짤 수 있느냐죠. 대부분이 테스터인 상황에서 가능할지가 의문입니다.

SI에도 TDD가 필요하다는 의견에는 동감합니다. Early Testing을 아무리 강조해도 잘 먹히지 않는 SI 현실에 자동화된 테스트를 가능하게 하는 거의 유일한 방법이 아닐까 생각되네요. 하지만 TDD가 개발조직과 테스트조직간에 관계 향상이 도움이 된다는 말은 이상합니다. 테스트 엔지니어는 TDD를 도와주는 사람이 아니라 테스트 자동화를 지원하는 역할을 하고, 단위테스트 보다 상위레벨의 통합테스트, 인수테스트를 자동화하는 사람이 되어야 하지 않나 하는 생각입니다.

테스트가 아직도 크게 인정을 못 받는 현실에서도 묵묵히 테스트 역할을 하고 계신분들에게 테스트 엔지니어로 거듭나시라는 이야기를 드리고 싶습니다.
저작자 표시 비영리 변경 금지