법칙 1. 프로그래머들의 사고방식을 이해하라
프로그래머들은 대부분 전문적이다
프로그래머는 자신이 개발해야 하는 모듈과 컴포넌트에 집중하며, 맡은 업무에 대해서는 적어도 팀 내 최고의 전문가라 할 수 있다.
테스터의 업무적 관점은 다르다. 테스터는 테스트할 시스템에 대해 다방면의 정보를 알고 있어야 하고, 각 모듈의 전체적인 조화에 집중한다.
프로그래머는 시스템에 적용된 자신의 논리에 집중한다
프로그래머는 자신이 만든 모듈과 다른 프로그래머가 만든 모듈의 연관성에 대해 이해하고 있다. 또한 발생할 수 있는 오류 처리에 대한 방안도 준비한다. 이러한 이유로 테스터가 오류를 보고할 때 프로그래머들은 종종 그러한 오류가 발생한다는 사실을 믿지 못하고 의심한다. 그러므로 테스터는 프로그래머가 코딩 시 기획했던 데이터 처리의 논리를 염두에 두고 철저하게 증거를 수집해 결함을 찾아야 한다.
프로그래밍은 복잡한 행위다
얽히고설킨 복잡한 구조의 프로그래밍 작업은 집중이 필요로 한 일이다. 이러한 업무 중에 다른 신경 쓰이는 일이 생기는 상황이 유쾌하지는 않을 것이다. 테스터에게는 이러한 프로그래밍 업무에 대한 이해가 필요하다(물론 테스팅이라는 업무 역시 장시간 집중이 필요한 업무라는 것을 프로그래머도 알아야 할 것이다).
프로그래머는 종종 어려운 상황을 감수한다
프로그래머들은 잦은 요구사항 변화에 따른 코드 변경 요구, 버그에 대한 수정 요구 등 작업 집중에 방해되는 환경 속에서 업무를 수행한다.
많은 프로그래머들은 일상적인 반복 업무를 싫어하며, 주어진 반복 업무를 도구나 스크립트를 작성하여 자동화한다
이러한 업무 성향으로 인해 프로그래머들은 테스터들의 매뉴얼한 반복 작업을 비효율적이고 최적화되지 못한 작업으로 이해하기도 한다. 만약 작은 코드 개발에 참여해 프로그래머가 되어 볼 수 있는 기회를 갖는다면, 개발자들을 이해하는 데 좋은 경험이 될 것이다.
법칙 2. 프로그래머와 신뢰를 쌓아라
테스트할 프로그램을 작성하는 프로그래머와 불필요한 적대 관계를 만들 이유가 없다. 프로그래머들과 함께 개발 계획, 요구사항 분석, 초기 프로토타입 등을 공유할 수 있다면 개발자들을 이해하는 데 도움이 될 것이다.
또한 테스터는 프로그래머들이 자신이 이미 아는 내용에 대해 듣고 싶어하는 것이 아니라는 것을 알아야 한다. 가령 예를 들어 개발 초기에 아직 작성하지 않은 오류 처리 방안이나 개발해야 하는 기능에 대해 듣고자 하는 것이 아니라는 것이다. 이러한 부분은 프로그래머가 몰라서 안 되어 있는 것이 아니라 아직 작업을 하지 않은 것뿐이다. 프로그래머가 각 상황에 따라 무엇을 듣고자 하는지에 대한 이해 역시 중요하다.
법칙 3. 서비스를 제공하라
다음 몇 가지 서비스를 제공하는 것으로 둘 사이의 신뢰에 큰 도움이 될 것이다.
서드파티 컴포넌트를 테스트하라. 테스트 결과를 공유함으로써 프로그래머들은 제품에 해당 컴포넌트를 사용할 것인지 여부를 결정할 수 있으며, 또한 어떻게 사용해야 하는지에 대한 정보를 얻을 수 있다.
프로그래머가 스스로 테스트할 수 있는 테스트 환경을 지원하라.
자신이 개발한 모듈을 테스트하기 위해 프로그래머가 부여 받은 테스트 지원 요구사항에 대해 검토하라. 프로그래머들은 애매모호한 요구사항 때문에 난처한 상황에 처하는 경우가 많으므로 테스터가 도와준다면 기뻐할 것이다.
테스팅 업무는 서비스를 제공하는 성향의 업무이므로 테스터가 프로그래머가 필요로 하는 업무에 대해 적극적으로 서비스를 제공한다면 둘 간의 관계는 대립이 아닌 화합의 관계가 될 것이다.
법칙 4. 성실하고 능력을 갖춰야 존중을 받는다
테스터는 고객의 대변자다. 즉 테스터의 궁극적인 업무는 사용자가 겪을 문제점을 보고하는 일이다. 하지만 아무리 좋은 의도를 담은 행동이라도 잘못된 부분을 지적하는 결함에 대한 보고는 유쾌하다고 하기 어렵다. 훌륭한 보고를 위해 다음과 같은 사항을 고려해야 한다.
문제점을 명확하게 보고하라
불필요한 과정과 정보는 생략하고, 버그가 발생되는 운영 절차와 버그에 대한 현상만을 명확하게 기술해야 한다. 프로그래머가 이해하기 쉽고, 버그 발생 과정을 따라 해보기 쉽게 보고해야 한다. 프로그래머가 간결하고 명확한 보고서를 통해 시간을 아낄 수 있다면, 테스터의 시간도 소중하게 생각할 것이다.
제품에서 실제로 수행한 동작을 판단 기준으로 삼는다
프로그래머는 누구보다도 더 프로그램 내부를 잘 안다. 그러니 테스터는 직접 봤던 것에 대해서만 이야기하면 된다. 어떤 점이 문제를 일으켰는지에 대한 추측으로 시간을 낭비할 필요가 없다.
나쁜 소식은 직접 전달하라
프로그래머가 문제 상황을 인식하고 대처할 시간을 준 다음, 상급자에게 보고하라. 또한 이 문제를 상급자에게 보고할 것이라는 것을 개발자에게 이야기해 주어야 한다.
모르는 것을 아는 체 하지 말라
어설픈 추측이 문제 해결을 방해하는 장애물이 될 수 있다.
버그 리포트를 과대 포장하지 않는다
버그 보고는 사실 그대로를 정확하게 전달해야 한다. 발견한 버그를 과대 포장하지도, 과소 평가하지도 말아야 한다. 또 중요한 버그를 찾았다고 그것을 뽐내도 안 된다. 테스터와 프로그래머가 한배를 탄 운명 공동체라는 것을 명심해야 한다.
법칙 5. 사람이 아닌 작업에 집중하라
버그를 발견하면 '버그'를 보고하라. 프로그래머 아무개가 잘못했다는 식으로 보고해서는 안 된다. 문제가 있는 프로그래머를 보고하는 것이 자신의 업무라고 생각한다면, 모든 프로그래머는 여러분과 정보를 공유하지 않을 것이고, 여러분을 피하려고 할 것이다. 이렇게 된다면 신뢰는 깨진다. 테스터의 업무는 잘못하는 프로그래머를 찾는 것이 아니라, 버그를 찾는 것이다.
법칙 6. 프로그래머들은 자신의 일에 대해 이야기하는 것을 좋아한다. 궁금한 점이 있으면 직접 물어보라
프로그래머와 이야기를 통해 정보를 얻기가 어렵다고 말하는 테스터가 많다. 하지만 프로그래머들이 다루는 설계 문서를 이해하고 그것에 관해 이야기를 시작해보자. 가능하면 코드도 살펴보자. 프로그래머 관점에서 이해하고 그 용어를 가지고 개발자들의 화법으로 이야기하고자 한다면 프로그래머들이 얼마나 자기 일에 대해 이야기하기를 좋아하는지 알게 될 것이다.
이런 대화는 시스템을 구축하는 사람들의 마음속에 있는 전제조건을 알아내는 데 도움이 된다. 또한 시스템을 오동작하게 하는 방식을 찾아낼 수 있다. 테스터가 C++나 자바 등 개발 언어를 알고 있다면 좀 더 도움이 될 것이다. 프로그램이 멀티스레드로 동작한다면 스레드가 어떤 것인지 이해하는 것은 중요한 일이다.
어떻게 하면 제품에서 오류가 발생하도록 할 수 있는지에 대해 고민하는 것이 테스터의 업무라 생각할 수 있다. 그러나 팀의 일원으로 지금 만들고 있는 제품의 진정한 가치를 이해해야 한다.
법칙 7. 프로그래머는 테스트를 도와주고 싶어한다
대부분의 프로그래머는 자기가 작성한 프로그램을 테스트하고 싶어한다. 개발자들은 프로그램을 작성하는 중에 자신이 실수했을 수도 있다는 사실을 인정하며, 이러한 실수를 발견해 주기를 기대하고 있다.
테스터는 프로그래머에게 테스트를 쉽게 해주는 테스트 용이성(testability)을 요구하지만 쉽게 목적을 이루지 못한다. 테스트 용이성 확보를 위한 요청에는 다음 핵심 사항이 있어야 한다.
1. 프로그래머의 언어로 이야기하라.
2. 빨리 요청하라.
3. 현실적이어야 한다.
테스터의 요청이 어느 모듈의 어떤 인터페이스를 원하는지 구체적이라면 프로그래머는 훨씬 쉽게 테스터의 요청을 이해할 것이다. 또한 프로젝트 초기에 테스팅에 관한 요청이라면 개발 일정에 그러한 요구사항을 고려하여 일정을 계획할 수 있어 프로그래머의 업무 진행에 대한 부담이 줄어든다(빠듯한 개발 일정 중간에 테스팅을 위한 지원 요청은 프로그래머에게 정말 감당하기 힘든 스트레스가 된다). 테스트 지원을 위한 코드 추가가 제품을 만들기 위한 프로그래밍보다 부담이 된다면 그러한 요구 또한 옳지 못하다.
많은 테스터들이 프로그래머가 항상 핑계를 댄다고 말한다. '테스트를 위해 포함되는 그 코드가 소프트웨어 보안에 문제를 일으킬 것 같아요', '성능 저해 요인이 될 것입니다' 그러나 이러한 이야기는 오히려 개발자들이 테스트를 위한 코드에 관심이 많다는 의미일 수 있다.
테스터는 프로그래머로 하여금 테스터를 도와주는 것이 궁극적으로 자신에게 도움이 된다는 사실을 인식시키는 것이 무엇보다 중요하다!
소프트웨어 테스터와 프로그래머의 화합(和合)의 법칙 IBMDeveloperWorks 이영석님의 칼럼중에서 발췌한 내용입니다. 귀감이 되는 좋은 글이라는 느낌이 들었습니다. 테스터의 관점에서의 이야기라고는 하지만 다른 관점에서의 생각을 잘 이해하고 그러한 시각들의 조각을 잘 조합하고 여러가지의 의견을 조율하기 위해 노력한다면 진정 성공적인 프로젝트가 되는 지름길이 아닐까하네요. :-)
Bookmark this on Delicious
댓글을 달아 주세요