[펌]소프트웨어 테스터와 프로그래머의 화합(和合)의 법칙

소프트웨어 테스터와 프로그래머.. 흠..
지금까지 개발을 해오면서 내가 만든 소프트웨어나 제품에 대해서 문제점을 지적해 주고 오류를 찾아 주는건 고맙다고 생각 한다.
하지만 오류와 문제점에 대한 지적만 할 뿐 그 과정에 대한 설명 없이 들이대는 분들을 종종 많이 보았다.
아래 글을 읽어 보면 알겠지만 모든 일에는 상호 존중과 이해를 기반하지 않고서는 서로 멱살 잡고 싸우기 일수가 아닐까 싶다.. (상호 존중과 이해 역시 담당자들의 실력이 뒷받침 되지 않는 다면 만들어 지지도 않겠지만.. )

배고픔 ㅡㅡ^

ref. http://www.ibm.com/developerworks/kr/library/dwclm/20080708/?ca=drs-kr

소프트웨어 테스터와 프로그래머의 화합(和合)의 법칙

이영석 stone@sqe.co.kr SOAP, 웹 서비스 등 XML 기반 기술과 BPM을 통한 프로세스 시스템 신봉자로 소프트웨어 품질에 대한 정통부 GS인증 업무를 수행하는 등 개발자 출신 QA라는 흔치 않은 경력을 가지고 있다. 현재 와이즈스톤(www.wisestone.kr) 대표이며, 소프트웨어 품질관리 교육 및 컨설팅 등을 하고 있다. 2008년 7월 8일

얼마 전 프로젝트 종료 후, 참여원들의 정보와 경험을 교환하는 클로징(closing) 회의 중 이런 얘기가 나왔다. "참여 프로그래머들이 같은 회사 사람들이니 다행이지, 서로 모르는 사이였다면 멱살잡고 싸웠을 겁니다." 모두 한참을 웃었다. 프로젝트에 참여한 프로그래머와 테스터 모두 크게 공감한다는 웃음이었다.

실제로 테스팅에 관한 많은 칼럼과 서적에서 빈번하게 언급되는 이슈가 '어떻게 서로 커뮤니케이션을 할 것인가'라는 의사소통에 관한 주제다. 그만큼 프로그래머와 테스터가 함께 참여하는 개발 프로젝트에서 의사소통 문제는 빈번하게 일어난다.

필자도 이전에 본 컬럼을 통해 이러한 문제에 대한 해결 방안의 하나로 BTS(Bug Tracking System) 같은 시스템 도입을 제안한 적이 있다. 서로 얼굴을 맞대고 문제를 논의하는 것보다는 시스템을 통해 감정을 배제한 의사소통이 효율적이라는 이유에서였다.

이번에는 평화로운(?) 의사소통을 위해 테스터와 프로그래머가 서로를 이해하는 데 도움이 될만한 '소프트웨어 테스팅 법칙 293가지'^[1]라는 책에 소개된 몇 가지 재미있는 이야기를 소개하고자 한다.

테스터 관점의 이야기이지만, 프로그래머들도 자신들을 이해하고자 하는 테스터의 노력을 이해하고, 테스터의 눈으로 투영되는 자신들의 모습을 되돌아보는 기회가 되기를 바란다. 서로를 이해하고자 하는 노력과 그 결실인 화합이야말로, 성공적인 프로젝트의 가장 기본 전제이며 왕도(王道)이기 때문이다.

법칙 1. 프로그래머들의 사고방식을 이해하라

프로그래머들은 대부분 전문적이다
프로그래머는 자신이 개발해야 하는 모듈과 컴포넌트에 집중하며, 맡은 업무에 대해서는 적어도 팀 내 최고의 전문가라 할 수 있다.
테스터의 업무적 관점은 다르다. 테스터는 테스트할 시스템에 대해 다방면의 정보를 알고 있어야 하고, 각 모듈의 전체적인 조화에 집중한다.

프로그래머는 시스템에 적용된 자신의 논리에 집중한다
프로그래머는 자신이 만든 모듈과 다른 프로그래머가 만든 모듈의 연관성에 대해 이해하고 있다. 또한 발생할 수 있는 오류 처리에 대한 방안도 준비한다. 이러한 이유로 테스터가 오류를 보고할 때 프로그래머들은 종종 그러한 오류가 발생한다는 사실을 믿지 못하고 의심한다. 그러므로 테스터는 프로그래머가 코딩 시 기획했던 데이터 처리의 논리를 염두에 두고 철저하게 증거를 수집해 결함을 찾아야 한다.

프로그래밍은 복잡한 행위다
얽히고설킨 복잡한 구조의 프로그래밍 작업은 집중이 필요로 한 일이다. 이러한 업무 중에 다른 신경 쓰이는 일이 생기는 상황이 유쾌하지는 않을 것이다. 테스터에게는 이러한 프로그래밍 업무에 대한 이해가 필요하다(물론 테스팅이라는 업무 역시 장시간 집중이 필요한 업무라는 것을 프로그래머도 알아야 할 것이다).

프로그래머는 종종 어려운 상황을 감수한다
프로그래머들은 잦은 요구사항 변화에 따른 코드 변경 요구, 버그에 대한 수정 요구 등 작업 집중에 방해되는 환경 속에서 업무를 수행한다.

많은 프로그래머들은 일상적인 반복 업무를 싫어하며, 주어진 반복 업무를 도구나 스크립트를 작성하여 자동화한다
이러한 업무 성향으로 인해 프로그래머들은 테스터들의 매뉴얼한 반복 작업을 비효율적이고 최적화되지 못한 작업으로 이해하기도 한다. 만약 작은 코드 개발에 참여해 프로그래머가 되어 볼 수 있는 기회를 갖는다면, 개발자들을 이해하는 데 좋은 경험이 될 것이다.

위로

법칙 2. 프로그래머와 신뢰를 쌓아라

테스트할 프로그램을 작성하는 프로그래머와 불필요한 적대 관계를 만들 이유가 없다. 프로그래머들과 함께 개발 계획, 요구사항 분석, 초기 프로토타입 등을 공유할 수 있다면 개발자들을 이해하는 데 도움이 될 것이다.

또한 테스터는 프로그래머들이 자신이 이미 아는 내용에 대해 듣고 싶어하는 것이 아니라는 것을 알아야 한다. 가령 예를 들어 개발 초기에 아직 작성하지 않은 오류 처리 방안이나 개발해야 하는 기능에 대해 듣고자 하는 것이 아니라는 것이다. 이러한 부분은 프로그래머가 몰라서 안 되어 있는 것이 아니라 아직 작업을 하지 않은 것뿐이다. 프로그래머가 각 상황에 따라 무엇을 듣고자 하는지에 대한 이해 역시 중요하다.

법칙 3. 서비스를 제공하라

다음 몇 가지 서비스를 제공하는 것으로 둘 사이의 신뢰에 큰 도움이 될 것이다.

• 서드파티 컴포넌트를 테스트하라. 테스트 결과를 공유함으로써 프로그래머들은 제품에 해당 컴포넌트를 사용할 것인지 여부를 결정할 수 있으며, 또한 어떻게 사용해야 하는지에 대한 정보를 얻을 수 있다.
• 프로그래머가 스스로 테스트할 수 있는 테스트 환경을 지원하라.
• 자신이 개발한 모듈을 테스트하기 위해 프로그래머가 부여 받은 테스트 지원 요구사항에 대해 검토하라. 프로그래머들은 애매모호한 요구사항 때문에 난처한 상황에 처하는 경우가 많으므로 테스터가 도와준다면 기뻐할 것이다.

테스팅 업무는 서비스를 제공하는 성향의 업무이므로 테스터가 프로그래머가 필요로 하는 업무에 대해 적극적으로 서비스를 제공한다면 둘 간의 관계는 대립이 아닌 화합의 관계가 될 것이다.

법칙 4. 성실하고 능력을 갖춰야 존중을 받는다

테스터는 고객의 대변자다. 즉 테스터의 궁극적인 업무는 사용자가 겪을 문제점을 보고하는 일이다. 하지만 아무리 좋은 의도를 담은 행동이라도 잘못된 부분을 지적하는 결함에 대한 보고는 유쾌하다고 하기 어렵다. 훌륭한 보고를 위해 다음과 같은 사항을 고려해야 한다.

문제점을 명확하게 보고하라
불필요한 과정과 정보는 생략하고, 버그가 발생되는 운영 절차와 버그에 대한 현상만을 명확하게 기술해야 한다. 프로그래머가 이해하기 쉽고, 버그 발생 과정을 따라 해보기 쉽게 보고해야 한다. 프로그래머가 간결하고 명확한 보고서를 통해 시간을 아낄 수 있다면, 테스터의 시간도 소중하게 생각할 것이다.

제품에서 실제로 수행한 동작을 판단 기준으로 삼는다
프로그래머는 누구보다도 더 프로그램 내부를 잘 안다. 그러니 테스터는 직접 봤던 것에 대해서만 이야기하면 된다. 어떤 점이 문제를 일으켰는지에 대한 추측으로 시간을 낭비할 필요가 없다.

나쁜 소식은 직접 전달하라
프로그래머가 문제 상황을 인식하고 대처할 시간을 준 다음, 상급자에게 보고하라. 또한 이 문제를 상급자에게 보고할 것이라는 것을 개발자에게 이야기해 주어야 한다.

모르는 것을 아는 체 하지 말라
어설픈 추측이 문제 해결을 방해하는 장애물이 될 수 있다.

버그 리포트를 과대 포장하지 않는다
버그 보고는 사실 그대로를 정확하게 전달해야 한다. 발견한 버그를 과대 포장하지도, 과소 평가하지도 말아야 한다. 또 중요한 버그를 찾았다고 그것을 뽐내도 안 된다. 테스터와 프로그래머가 한배를 탄 운명 공동체라는 것을 명심해야 한다.

위로

법칙 5. 사람이 아닌 작업에 집중하라

버그를 발견하면 '버그'를 보고하라. 프로그래머 아무개가 잘못했다는 식으로 보고해서는 안 된다. 문제가 있는 프로그래머를 보고하는 것이 자신의 업무라고 생각한다면, 모든 프로그래머는 여러분과 정보를 공유하지 않을 것이고, 여러분을 피하려고 할 것이다. 이렇게 된다면 신뢰는 깨진다. 테스터의 업무는 잘못하는 프로그래머를 찾는 것이 아니라, 버그를 찾는 것이다.

법칙 6. 프로그래머들은 자신의 일에 대해 이야기하는 것을 좋아한다. 궁금한 점이 있으면 직접 물어보라

프로그래머와 이야기를 통해 정보를 얻기가 어렵다고 말하는 테스터가 많다. 하지만 프로그래머들이 다루는 설계 문서를 이해하고 그것에 관해 이야기를 시작해보자. 가능하면 코드도 살펴보자. 프로그래머 관점에서 이해하고 그 용어를 가지고 개발자들의 화법으로 이야기하고자 한다면 프로그래머들이 얼마나 자기 일에 대해 이야기하기를 좋아하는지 알게 될 것이다.

이런 대화는 시스템을 구축하는 사람들의 마음속에 있는 전제조건을 알아내는 데 도움이 된다. 또한 시스템을 오동작하게 하는 방식을 찾아낼 수 있다. 테스터가 C++나 자바 등 개발 언어를 알고 있다면 좀 더 도움이 될 것이다. 프로그램이 멀티스레드로 동작한다면 스레드가 어떤 것인지 이해하는 것은 중요한 일이다.

어떻게 하면 제품에서 오류가 발생하도록 할 수 있는지에 대해 고민하는 것이 테스터의 업무라 생각할 수 있다. 그러나 팀의 일원으로 지금 만들고 있는 제품의 진정한 가치를 이해해야 한다.

법칙 7. 프로그래머는 테스트를 도와주고 싶어한다

대부분의 프로그래머는 자기가 작성한 프로그램을 테스트하고 싶어한다. 개발자들은 프로그램을 작성하는 중에 자신이 실수했을 수도 있다는 사실을 인정하며, 이러한 실수를 발견해 주기를 기대하고 있다.

테스터는 프로그래머에게 테스트를 쉽게 해주는 테스트 용이성(testability)을 요구하지만 쉽게 목적을 이루지 못한다. 테스트 용이성 확보를 위한 요청에는 다음 핵심 사항이 있어야 한다.

1. 프로그래머의 언어로 이야기하라.
2. 빨리 요청하라.
3. 현실적이어야 한다.

테스터의 요청이 어느 모듈의 어떤 인터페이스를 원하는지 구체적이라면 프로그래머는 훨씬 쉽게 테스터의 요청을 이해할 것이다. 또한 프로젝트 초기에 테스팅에 관한 요청이라면 개발 일정에 그러한 요구사항을 고려하여 일정을 계획할 수 있어 프로그래머의 업무 진행에 대한 부담이 줄어든다(빠듯한 개발 일정 중간에 테스팅을 위한 지원 요청은 프로그래머에게 정말 감당하기 힘든 스트레스가 된다). 테스트 지원을 위한 코드 추가가 제품을 만들기 위한 프로그래밍보다 부담이 된다면 그러한 요구 또한 옳지 못하다.

많은 테스터들이 프로그래머가 항상 핑계를 댄다고 말한다. '테스트를 위해 포함되는 그 코드가 소프트웨어 보안에 문제를 일으킬 것 같아요', '성능 저해 요인이 될 것입니다' 그러나 이러한 이야기는 오히려 개발자들이 테스트를 위한 코드에 관심이 많다는 의미일 수 있다.

테스터는 프로그래머로 하여금 테스터를 도와주는 것이 궁극적으로 자신에게 도움이 된다는 사실을 인식시키는 것이 무엇보다 중요하다!

위로

후기

대다수의 프로그래머들에게 테스터를 존중하는 마음이 부족한 것이 사실이다. 테스터들을 자신들의 생산품인 프로그램의 '옥의 티'와 같은 흠을 찾아내 닦아주는 흡사 도우미(maid) 정도로 생각한다.

그렇다면 테스터는 이러한 인식을 가진 프로그래머에 대해 어떤 생각을 가지겠는가. 사람 마음은 인지상정(人之常情)이라 똑같지 않을까? 자신을 존중하지 않는 상대에게 좋은 감정을 갖기는 어려울 것이다. 어쩌면 테스터들 눈에는 결점 가득한 프로그램을 만든 프로그래머가 그 코드처럼 결점투성이의 부족한 사람으로 보일 수도 있을 것이다.

원론적인 결론이지만 서로 업무를 존중하고, 개인적인 친분을 위해 노력하는 것이 원만한 상호 관계를 유지하는 방법이라 할 수 있을 것이다. 성서에도 있지 않은가. 사람이 목숨을 유지하기 위해서는 눈, 코, 입, 손, 발 중 하나만 있어서 되는 것이 아니라, 중요한 것은 모두의 화합이라고.

위로

주

^[1] Cem Kaner, James Bach, Bret Pettichord, 소프트웨어 테스팅 법칙 293가지(LESSON LEARNED IN SOFTWARE TESTING: A CONTEXT-DRIVEN APPROACH), 정보문화사, 2004