제 1장 테스터의 역할
법칙 1. 테스트는 프로젝트의 전조등이다.
테스터는 여행하는 자동차의 전조등과 같다. 현재의 위치와 상황을 알려줘야 한다.
법칙 2. 임무에 따라 행동이 결정된다.
다음은 테스터의 역할을 정의할 수 있는 요구 사항들이다. 어떤 요구 사항을 기대하고 있는가?
- 중요한 버그를 신속하게 찾아낸다.
- 제품 품질에 대한 일반적인 평가를 수행한다.
- 제품이 지정된 표준을 만족하는지를 확인한다.
- 제품의 품질과 테스트 기능을 향상시킬 수 있도록 고객을 돕는다.
- 제품 책임 표준에 따라 테스트 프로세스가 진행되었음을 보장한다.
- 고객에게 테스트 업무 및 테스트와의 업무 처리 방법을 가르친다.
- 특정 방법론이나 규칙을 따른다.
- 지원 비용을 예측하고, 이를 제어한다.
- 고객의 업무가 향상될 수 있도록 돕는다.
- 비용이나 시간, 또는 달갑지 않은 부작용을 최소화하는 방향으로 업무를 수행한다.
- 특정 고객을 만족시키기 위하여 필요한 모든 일을 한다.
법칙 3. 테스터는 많은 고객들에게 서비스를 제공한다.
테스트는 서비스의 일종이다.
고객들은 모두 자기 나름대로의 요구사항을 가지고 있으며, 그 요구사항들이 반드시 하나로 일치되지는 않는다.
- 프로젝트 관리자.
프로젝트 관리자는 프로세스에 대해 알고 있어야 하며, 프로세스에 영향력을 미칠 수 있다. 테스터는 관리자를 마족시키기 위하여 프로젝트 관리자가 요청하는 대로 진행 상태를 보고하고, 중요한 문제점을 신속하게 보고하며, 프로젝트에 병목지점이 발생하지 않도록 방지해야 한다. 프로젝트의 진행방향을 결정하는 것은 프로젝트 관리자의 특권이다. 프로젝트 관리자가 프로젝트의 현재 상황이나 주어진 조건에 따라 판단을 내릴 수 있도록 자신이 할 수 있는 일이 무엇이며, 할 수 없는 일이 무엇인지, 프로젝트에 영향을 줄만한 요소는 무엇인지 관리자에게 아렬주는 것이 바로 테스터가 해야 하는 일이다.
- 프로그래머.
버그 보고서를 신속하게 제출함으로써 프로그래머들의 작업을 더욱 쉽게 만들 수 있다. 프로그래머들이 실수나 사소한 문제점 때문에 시간을 낭비하지 않도록 관련 기술과 해당 제품을 알려고 노력해야 한다. 이를 통해 프로그래머들에게 더 많은 신뢰를 얻을 수 있고, 격국 그들의 지지와 영향력을 이끌어내게 된다.
- 테크니컬 라이터.
테크니컬 라이터는 테스터와 마찬가지로 제품에 대한 불완전한 정보를 획득하여 사용 설명서와 온라인 도움말을 작성한다. 테스터는 제품이 실제로 어떻게 동작하는지를 테크니컬 라이터들이 이해할 수 있도록 도와줄 수 있으며. 문서화 과정에서의 오류를 미리 알려줄 수 있다. 테크니컬 라이터 역시 테스터를 도와줄 수도 있다. 테크니컬 라이터들이 제품에 대한 연구를 수행하고, 사용자가 문서를 읽고 제품을 사용하는 과정에서 테스터가 알지 못했던 사실을 알아 낼 수도 있다. 테크니컬 라이터들과 좋은 관계를 맺고 있다면 그들이 새로운 기능, 새로운 사용법, 테스트 계획의 허점, 그들이 찾아낸 버그를 알려줄 것이다. 이러한 버그들 중 일부는 특정 테스터가 해당 영역에 관심을 가지고 있다는 사실을 테크니컬 라이터가 모른다면 절대 보고되지 않는 버그들이다.
- 기술 지원팀.
제품에 남아 있는 문제점이 무엇이든 간에 이는 결국 기술 지원을 해야 하는 사람들에게는 부담이 된다. 사용자들이 어려움을 겪고 있을 제품의 요소들을 기술 지원팀에게 알려줌으로써 이들을 만족시킬 수 있다. 만약 개발 기간동안 기술 지원팀과 함께 일을 하게 된다며 종종 기술 지원팀이 반드시 고쳐져야 하는 버그가 발생하는 경우를 알려줄 것이다. 또한 테스터는 기술 지원팀이 현장에서 볼수 있는 어려운 문제점을 조사하는 과정을 도와줄 수 있다. 이렇게 함으로써 기술 지원팀과 밀접한 관계를 맺을 수 있으며, 결국 고객과도 더욱 친밀한 관계를 맺게 된다.
- 마케팅팀.
마케팅팀은 고객에게 제공될 제품의 중요한 장점에 대해 모순되는 부분은 없는지를 알고싶어 한다. 프로그래머에게 사소하게 보이는 버그가 마케팅을 담당하는 사람에게는 치명적일 수도 있다. 마케팅 담당자는 고객들이 중요한 작업을 할 때 이 버그가 얼마나 작업을 어렵게 마들 것인지를 알고 있다. 또한 마케팅 계획 문서나 서류를 검토하고, 제품의 기능들에 대하여 정확히 설명해 줌으로써 마케팅 업무진행을 도와줄 수 있다.
- 최고경영자와 주주.
우리는 기업을 위해 일을 해야 한다. 그렇기 때문에 이성적으로 행동하는 사람이 아니라 품질에 열광하는 사람처럼 느껴지거나 그렇게 행동하지 않도록 조심해야 한다. 특히 프로젝트의 종료시점이 가까워지면 회사의 장,단기 이해관계를 고려하며서 업무를 수행해야 한다. 테스트 상태를 보고할 때 의미가 명확한 경영 용어를 사용함으로써 경영진들이 긍정적으로 결정을 내릴 기초 토대를 가지고 있다고 느끼게 해야한다.
- 사용자.
테스터는 제품을 사용할 사람들을 만족시켜야 한다. 당연히 사용자의 만족이야말로 프로젝트에서 가장 큰 관심사이다. 그러나 주요 사용자들이 프로젝트팀을 지지핟록 만들기 위한 특별한 경우도 있다.
법칙 4. 고객이 가치 있다고 생각하는 "버그"를 발견하라.
고객이 정의한 가치 기준에 따라 제품의 가치를 위협하는 모든 사항을 고객에게 알려주는 것도 테스트 그룹의 임무에 포함된다. 만약 제품이 원하는 대로 동장하더라도 가치가 없는 제품이라고 생각되면, 이러한 사항도 보고해야 하는 것이 바로 테스터의 의무이다.
법칙 5. 중요한 버그를 신속하게 찾아내라.
- 동일한 제품에서 변경된 부분을 테스트 한다. 수정되었거나 바뀐 부분이 있다는 사실은 새로운 위험을 의미한다.
- 일반 기능보다 핵심 기능을 먼저 테스트 한다. 제품이 동작하기 위하여 중요한, 널리 사용되는 기능을 테스트한다. 제품을 제품답게 마들어 주는 기능을 테스트 한다.
- 신뢰성보다 우선적으로 기능성을 테스트한다. 매우 다양한 조건에서 특정 기능을 얼마나 잘 수행하는지는 자세히 살펴보기 전에 각 함수들이 모두 동작하는지 부터 테스트 해야 한다.
- 복잡한 조건보다 일반적인 조건을 우선적으로 테스트 한다. 널리 사용되는 데이터와 시나리오를 사용한다.
- 발생 가능성이 적은 위험보다 일반적인 위험에 대해 테스트 한다. 가장 많은 스트레스를 줄 것 같은 오류 상황을 먼저 테스트 한다.
- 영향력이 작은 문제보다는 영향력이 큰 문제부터 테스트 해야 한다. 문제가 발생했을 경우 제품에 매우 큰 손실을 입힐 것 같은 부분을 먼저 테스트 한다.
- 요청되지 않은 영역보다 가장 많이 원하는 영역부터 먼저 테스트 한다. 팀 내부 사람들이 특별한 관심을 가지는 문제부터 테스트 한다.
법칙 6. 프로그래머와 함께 진행하라.
프로그래머를 지원하는 것도 테스터의 임무중 중요한 한 부분이다.
가능한 가장 신속하게 피드백을 돌려주는 데에 테스트의 중점을 두자.
법칙 7. 모든 것에 의문을 가져라 그러나 밖으로 크게 드러내지는 마라.
법칙 8. 테스터가 실패에 초점을 맞추면 고객은 성공에 초점을 맞출 수 있다.
법칙 9. 모든 버그를 찾아 낼 수는 없다.
중요한 버그를 발견하여 이를 보고해야 하낟. 그러나 모든 버그를 찾아낼 수는 없다. 모든 버그를 찾아내려면 버그가 될 수 있는 모든 부분을 조사하고, 발생할 수 있는 모든 조거을 고려해야 하며, 버그가 발생했을 경우 모든 종류의 버그를 식별할 수 있는 간단한 방법이 필요하다. 실제로 이런 일이 가능하다고 생각한다면 지금 여러분은 매우 단순한 제품을 테스트하고 있거나 망상을 하고 있는 것이다.
법칙 10. "완전히" 테스트한다는 말을 조심하라.
테스트 완료가 의미하는 바를 한번 생각해보자.
- 제품에 포함된 버그들을 모두 발견하였다.
- 제품의 모든 측며에 대한 검사를 마쳤다.
- 유용한, 비용대비 수행 효과가 뛰어난 테스트를 수행하였다.
- 최선을 다하여 프로젝트의 기술된 목표를 모두 수행하였아.
- 협약사항에 대한 테스트를 수행하였다.
- 테스트 할 수 있는 모든 항목을 모든 조건에서 수행하였다.
- 해야 할 방법을 모두 수행하였다.
- 어떤 부분이든 간에 맡은 테스트 부분을 완료하였다.
- 제품에 대한 광범위한, 그러나 상세하지는 않은 테스트를 완료하였다.
- 제품에 대한 한가지 테스트를 완료하였다.
- 테스트에 할당된 시간과 기간이 끝났다.
"완료하였다", "마쳤다", "수행하였다"의 의미를 명확하게 하는데 조금 더 신경을 쓴다면 나중에 걱정할 일이 생기지 않을 것이다. 자신에게 주어진 작업을 수행하지 않았다는 비난을 받지 않게 될 것이며, 만약 비난을 받는다고 하더라도 자신을 더욱 잘 변호할 수 있을 것이다. "완전"이라는 용어가 프로젝트의 시작 단계에서는 명쾌하게 정의되어질 수 있는 용어가 아니라는 점을 주의해야 한다. 프로젝트가 진행되면서 새로운 테스트 작업이 등장할 때마다 다시 한번 이 의미를 고려해 보아야 한다.
법칙 11. 테스트를 통해서 품질을 보장할 수는 없다.
법칙 12. 문지기가 되지는 마라!
제품 출시에 대하여 거부 권한을 가졌으면 하는 바람을 가진 테스터들이 있다. 이러한 권한을 부여받게 된다면 이와 동시에 책임도 부여받게 된다는 점을 명심해야 한다. 문제는 테스터들이 출시 여부를 통제하게 되면 제품의 품질에 대해서도 모든 책임을 져야 한다는 사실이다. 아마도 나머지 팀월들은 매우 느긋해질 수 있을 것이다. 테스터가 어떤 버그를 발견하지 못한 채 배포 되었다면 나머지 팀원들은 "왜 테스터들이 그러한 버그가 있는 제품을 최종적으로 출시했는가?" 라고 말하며서 테스터를 비난할 것이다. 결국 프로젝트를 제어하는 사람이 책임을 져야 한다.
법칙 13. 테스트에서 "내 업무가 아니야"의 논리를 조심하라.
법칙 14. 프로세스 개선 그룹이 되는 것을 조심하라.
법칙 15. 테스트를 잘 수행하기 위하여 필요한 항목들을 모든 사람들이 이해할 것이라고 기대하지 마라.
작업을 효과적으로 수행하기 위하여 필요한 것들이 무엇인지를 고객에게 알려주는 것도 여러분의 몫이다.
법칙 1. 테스트는 프로젝트의 전조등이다.
테스터는 여행하는 자동차의 전조등과 같다. 현재의 위치와 상황을 알려줘야 한다.
법칙 2. 임무에 따라 행동이 결정된다.
다음은 테스터의 역할을 정의할 수 있는 요구 사항들이다. 어떤 요구 사항을 기대하고 있는가?
- 중요한 버그를 신속하게 찾아낸다.
- 제품 품질에 대한 일반적인 평가를 수행한다.
- 제품이 지정된 표준을 만족하는지를 확인한다.
- 제품의 품질과 테스트 기능을 향상시킬 수 있도록 고객을 돕는다.
- 제품 책임 표준에 따라 테스트 프로세스가 진행되었음을 보장한다.
- 고객에게 테스트 업무 및 테스트와의 업무 처리 방법을 가르친다.
- 특정 방법론이나 규칙을 따른다.
- 지원 비용을 예측하고, 이를 제어한다.
- 고객의 업무가 향상될 수 있도록 돕는다.
- 비용이나 시간, 또는 달갑지 않은 부작용을 최소화하는 방향으로 업무를 수행한다.
- 특정 고객을 만족시키기 위하여 필요한 모든 일을 한다.
법칙 3. 테스터는 많은 고객들에게 서비스를 제공한다.
테스트는 서비스의 일종이다.
고객들은 모두 자기 나름대로의 요구사항을 가지고 있으며, 그 요구사항들이 반드시 하나로 일치되지는 않는다.
- 프로젝트 관리자.
프로젝트 관리자는 프로세스에 대해 알고 있어야 하며, 프로세스에 영향력을 미칠 수 있다. 테스터는 관리자를 마족시키기 위하여 프로젝트 관리자가 요청하는 대로 진행 상태를 보고하고, 중요한 문제점을 신속하게 보고하며, 프로젝트에 병목지점이 발생하지 않도록 방지해야 한다. 프로젝트의 진행방향을 결정하는 것은 프로젝트 관리자의 특권이다. 프로젝트 관리자가 프로젝트의 현재 상황이나 주어진 조건에 따라 판단을 내릴 수 있도록 자신이 할 수 있는 일이 무엇이며, 할 수 없는 일이 무엇인지, 프로젝트에 영향을 줄만한 요소는 무엇인지 관리자에게 아렬주는 것이 바로 테스터가 해야 하는 일이다.
- 프로그래머.
버그 보고서를 신속하게 제출함으로써 프로그래머들의 작업을 더욱 쉽게 만들 수 있다. 프로그래머들이 실수나 사소한 문제점 때문에 시간을 낭비하지 않도록 관련 기술과 해당 제품을 알려고 노력해야 한다. 이를 통해 프로그래머들에게 더 많은 신뢰를 얻을 수 있고, 격국 그들의 지지와 영향력을 이끌어내게 된다.
- 테크니컬 라이터.
테크니컬 라이터는 테스터와 마찬가지로 제품에 대한 불완전한 정보를 획득하여 사용 설명서와 온라인 도움말을 작성한다. 테스터는 제품이 실제로 어떻게 동작하는지를 테크니컬 라이터들이 이해할 수 있도록 도와줄 수 있으며. 문서화 과정에서의 오류를 미리 알려줄 수 있다. 테크니컬 라이터 역시 테스터를 도와줄 수도 있다. 테크니컬 라이터들이 제품에 대한 연구를 수행하고, 사용자가 문서를 읽고 제품을 사용하는 과정에서 테스터가 알지 못했던 사실을 알아 낼 수도 있다. 테크니컬 라이터들과 좋은 관계를 맺고 있다면 그들이 새로운 기능, 새로운 사용법, 테스트 계획의 허점, 그들이 찾아낸 버그를 알려줄 것이다. 이러한 버그들 중 일부는 특정 테스터가 해당 영역에 관심을 가지고 있다는 사실을 테크니컬 라이터가 모른다면 절대 보고되지 않는 버그들이다.
- 기술 지원팀.
제품에 남아 있는 문제점이 무엇이든 간에 이는 결국 기술 지원을 해야 하는 사람들에게는 부담이 된다. 사용자들이 어려움을 겪고 있을 제품의 요소들을 기술 지원팀에게 알려줌으로써 이들을 만족시킬 수 있다. 만약 개발 기간동안 기술 지원팀과 함께 일을 하게 된다며 종종 기술 지원팀이 반드시 고쳐져야 하는 버그가 발생하는 경우를 알려줄 것이다. 또한 테스터는 기술 지원팀이 현장에서 볼수 있는 어려운 문제점을 조사하는 과정을 도와줄 수 있다. 이렇게 함으로써 기술 지원팀과 밀접한 관계를 맺을 수 있으며, 결국 고객과도 더욱 친밀한 관계를 맺게 된다.
- 마케팅팀.
마케팅팀은 고객에게 제공될 제품의 중요한 장점에 대해 모순되는 부분은 없는지를 알고싶어 한다. 프로그래머에게 사소하게 보이는 버그가 마케팅을 담당하는 사람에게는 치명적일 수도 있다. 마케팅 담당자는 고객들이 중요한 작업을 할 때 이 버그가 얼마나 작업을 어렵게 마들 것인지를 알고 있다. 또한 마케팅 계획 문서나 서류를 검토하고, 제품의 기능들에 대하여 정확히 설명해 줌으로써 마케팅 업무진행을 도와줄 수 있다.
- 최고경영자와 주주.
우리는 기업을 위해 일을 해야 한다. 그렇기 때문에 이성적으로 행동하는 사람이 아니라 품질에 열광하는 사람처럼 느껴지거나 그렇게 행동하지 않도록 조심해야 한다. 특히 프로젝트의 종료시점이 가까워지면 회사의 장,단기 이해관계를 고려하며서 업무를 수행해야 한다. 테스트 상태를 보고할 때 의미가 명확한 경영 용어를 사용함으로써 경영진들이 긍정적으로 결정을 내릴 기초 토대를 가지고 있다고 느끼게 해야한다.
- 사용자.
테스터는 제품을 사용할 사람들을 만족시켜야 한다. 당연히 사용자의 만족이야말로 프로젝트에서 가장 큰 관심사이다. 그러나 주요 사용자들이 프로젝트팀을 지지핟록 만들기 위한 특별한 경우도 있다.
법칙 4. 고객이 가치 있다고 생각하는 "버그"를 발견하라.
고객이 정의한 가치 기준에 따라 제품의 가치를 위협하는 모든 사항을 고객에게 알려주는 것도 테스트 그룹의 임무에 포함된다. 만약 제품이 원하는 대로 동장하더라도 가치가 없는 제품이라고 생각되면, 이러한 사항도 보고해야 하는 것이 바로 테스터의 의무이다.
법칙 5. 중요한 버그를 신속하게 찾아내라.
- 동일한 제품에서 변경된 부분을 테스트 한다. 수정되었거나 바뀐 부분이 있다는 사실은 새로운 위험을 의미한다.
- 일반 기능보다 핵심 기능을 먼저 테스트 한다. 제품이 동작하기 위하여 중요한, 널리 사용되는 기능을 테스트한다. 제품을 제품답게 마들어 주는 기능을 테스트 한다.
- 신뢰성보다 우선적으로 기능성을 테스트한다. 매우 다양한 조건에서 특정 기능을 얼마나 잘 수행하는지는 자세히 살펴보기 전에 각 함수들이 모두 동작하는지 부터 테스트 해야 한다.
- 복잡한 조건보다 일반적인 조건을 우선적으로 테스트 한다. 널리 사용되는 데이터와 시나리오를 사용한다.
- 발생 가능성이 적은 위험보다 일반적인 위험에 대해 테스트 한다. 가장 많은 스트레스를 줄 것 같은 오류 상황을 먼저 테스트 한다.
- 영향력이 작은 문제보다는 영향력이 큰 문제부터 테스트 해야 한다. 문제가 발생했을 경우 제품에 매우 큰 손실을 입힐 것 같은 부분을 먼저 테스트 한다.
- 요청되지 않은 영역보다 가장 많이 원하는 영역부터 먼저 테스트 한다. 팀 내부 사람들이 특별한 관심을 가지는 문제부터 테스트 한다.
법칙 6. 프로그래머와 함께 진행하라.
프로그래머를 지원하는 것도 테스터의 임무중 중요한 한 부분이다.
가능한 가장 신속하게 피드백을 돌려주는 데에 테스트의 중점을 두자.
법칙 7. 모든 것에 의문을 가져라 그러나 밖으로 크게 드러내지는 마라.
법칙 8. 테스터가 실패에 초점을 맞추면 고객은 성공에 초점을 맞출 수 있다.
법칙 9. 모든 버그를 찾아 낼 수는 없다.
중요한 버그를 발견하여 이를 보고해야 하낟. 그러나 모든 버그를 찾아낼 수는 없다. 모든 버그를 찾아내려면 버그가 될 수 있는 모든 부분을 조사하고, 발생할 수 있는 모든 조거을 고려해야 하며, 버그가 발생했을 경우 모든 종류의 버그를 식별할 수 있는 간단한 방법이 필요하다. 실제로 이런 일이 가능하다고 생각한다면 지금 여러분은 매우 단순한 제품을 테스트하고 있거나 망상을 하고 있는 것이다.
법칙 10. "완전히" 테스트한다는 말을 조심하라.
테스트 완료가 의미하는 바를 한번 생각해보자.
- 제품에 포함된 버그들을 모두 발견하였다.
- 제품의 모든 측며에 대한 검사를 마쳤다.
- 유용한, 비용대비 수행 효과가 뛰어난 테스트를 수행하였다.
- 최선을 다하여 프로젝트의 기술된 목표를 모두 수행하였아.
- 협약사항에 대한 테스트를 수행하였다.
- 테스트 할 수 있는 모든 항목을 모든 조건에서 수행하였다.
- 해야 할 방법을 모두 수행하였다.
- 어떤 부분이든 간에 맡은 테스트 부분을 완료하였다.
- 제품에 대한 광범위한, 그러나 상세하지는 않은 테스트를 완료하였다.
- 제품에 대한 한가지 테스트를 완료하였다.
- 테스트에 할당된 시간과 기간이 끝났다.
"완료하였다", "마쳤다", "수행하였다"의 의미를 명확하게 하는데 조금 더 신경을 쓴다면 나중에 걱정할 일이 생기지 않을 것이다. 자신에게 주어진 작업을 수행하지 않았다는 비난을 받지 않게 될 것이며, 만약 비난을 받는다고 하더라도 자신을 더욱 잘 변호할 수 있을 것이다. "완전"이라는 용어가 프로젝트의 시작 단계에서는 명쾌하게 정의되어질 수 있는 용어가 아니라는 점을 주의해야 한다. 프로젝트가 진행되면서 새로운 테스트 작업이 등장할 때마다 다시 한번 이 의미를 고려해 보아야 한다.
법칙 11. 테스트를 통해서 품질을 보장할 수는 없다.
법칙 12. 문지기가 되지는 마라!
제품 출시에 대하여 거부 권한을 가졌으면 하는 바람을 가진 테스터들이 있다. 이러한 권한을 부여받게 된다면 이와 동시에 책임도 부여받게 된다는 점을 명심해야 한다. 문제는 테스터들이 출시 여부를 통제하게 되면 제품의 품질에 대해서도 모든 책임을 져야 한다는 사실이다. 아마도 나머지 팀월들은 매우 느긋해질 수 있을 것이다. 테스터가 어떤 버그를 발견하지 못한 채 배포 되었다면 나머지 팀원들은 "왜 테스터들이 그러한 버그가 있는 제품을 최종적으로 출시했는가?" 라고 말하며서 테스터를 비난할 것이다. 결국 프로젝트를 제어하는 사람이 책임을 져야 한다.
법칙 13. 테스트에서 "내 업무가 아니야"의 논리를 조심하라.
법칙 14. 프로세스 개선 그룹이 되는 것을 조심하라.
법칙 15. 테스트를 잘 수행하기 위하여 필요한 항목들을 모든 사람들이 이해할 것이라고 기대하지 마라.
작업을 효과적으로 수행하기 위하여 필요한 것들이 무엇인지를 고객에게 알려주는 것도 여러분의 몫이다.
