Testing Experience 3번째 호에 실린 "What Testing Cannot Do"라는 제목의 글이 눈길을 끌었다.
우리말로 하면 '테스팅이 할 수 없는 것들' 정도가 되지 않을까 싶다.
열정적인 테스터일수록 프로젝트가 막바지에 이르더라도 열심히 버그를 찾아내고 개발자들이 이를 수정하길 바란다. 나 또한 그랬고 지금도 그런 자세가 바람직하다고 생각한다.
하지만 소프트웨어 테스트 업계에 몸담고 있는 시간이 오래 될수록, 그리고 책이나 기타 소스를 통해 견문을 넓혀 나갈수록, 일정한 수준에서 그러한 열정을 잠재우고 합리적으로 테스팅을 중단해야 한다는 의견을 많이 접하게 된다.
문제는 어느 수준에서 테스팅을 그만두어야 하느냐는 것이다.
ISTQB와 같은 범용적인 기준에서는 단순히 돈과 시간, 프로젝트의 수익성을 고려해야 한다라고 말하고 있지만 사실상 어느 시점에서 테스팅을 그만두어야 하느냐는 테스터들에게 정말 쉽지 않은 문제다.
이 글은 짧지만 강력하게, 그리고 재미있게 어느 시점에서 테스팅을 그만두어야 하는지에 대해 이야기하고 있다. 재미삼아 한 번 읽어보시길.
What Testing Cannot Do
당신이 수 백만 달러짜리 물류 시스템을 만드는 프로젝트의 책임자라고 가정해보자. 당신 회사의 사장인 베니토 씨는 능동적인 사람이지만 어떤 경우엔 독선적이기도 하다. 심지어 그는 회의 석상에서 그가 원하는 수준의 답을 주지 않는 임원들을 바로 해고하는 것으로도 유명하다. 그는 하루라도 빨리 시스템이 완성되기를 간절하게 원하고 있다. 그런 베니토 씨가 당신에게 압력을 넣고 있는 중이다. 당신은 프로젝트 매니저에게 가서 “그 시스템 프로젝트가 어떻게 진행되고 있죠?”라고 물어볼 수 밖에 없을 것이다. 그런데 어이없게도 프로젝트 매니저가 “모르겠는데요”라고 답한다…
자, 이제 당신은 어떻게 할 것인가? 당신은 “모르겠는데요”라는 답 이상의 것을 간절히 원하고 있을 것이다. 당신이 원하는 답을 얻기 위한 여러 가지 방법이 있다.
a. 고문이 효과를 볼지도 모른다.
프로젝트 매니저의 손톱을 하나씩 뽑아보라. “아, 그래요!! 프로젝트가 어떻게 진행되는지 알고 있어요!!! 아주 잘돼가고 있어요!!!”라고 바로 대답할 것이다. 손톱을 다 뽑아도 원하는 대답을 말하지 않는다면, 발톱까지 뽑아라.
b. 승진은 어떤가?
모른다는 대답으로 일관하는 프로젝트 매니저를 지금 당장 해고하고, “난 알아요”라고 대답하는 사람을 그 자리로 승진시켜라. 적당한 사람이 나타날 때까지 이 과정을 반복하라.
c. 정보를 수집하는 것이 효과를 볼지도 모른다.
사람들이 실제로 프로그램을 사용하려고 할 때, 그 프로그램이 어떻게 동작하는지를 설명해 줄 수 있는 관련된 정보를 찾아보라.
사장에게 보고할 만한 믿을만한 정보를 얻기 원한다면, a 항목과 b 항목은 그 목적을 달성하기 힘들어 보인다. 하지만 c 항목은 최소한의 기회를 제공하고 있다. 실제로 프로그램이 어떻게 작동하고 있는지에 대한 구체적인 정보를 모으는 것은, 사람들이 소위 “테스팅”이라고 알고 있는 행동을 조금 다르게 설명하고 있는 것뿐이다.
리스크를 줄이는 데 정보가 필수적인 것은 아니다
Information doesn’t necessarily help reduce risk
소프트웨어 산업의 관리자들은 자주 위험한 결정을 내려야 한다. 하지만 다음의 질문에 대한 적절한 해답을 가지고 결정을 내린다면, 그러한 위험을 충분히 줄일 수도 있다.
l 지금 바로 제품을 출시해야 하는가? 더 늦어도 되는가? 벌써 출시했었어야 했는가?
l 프로젝트를 취소해야 하는가?
l 프로젝트를 계속하고 더 많은 리소스를 투입할 것인가?
l 프로젝트의 범위를 줄일 것인가?
l 제품을 더 확대된 시장에 판매할 것인가?
l 현재 버전의 제품을 더 낮은 가격으로 판매할 것인가?
물론, 이러한 결정들 역시 아무 정보 없이도 이루어 질 수 있다. 그리고 종종 그렇게 중요한 문제들이 결정된다. 중요한 결정을 내려야 할 사람들이 정작 고려되어야 할 정보들은 무시한 채, 그럴만한 가치가 없는 정보들만을 고려해 중요한 결정을 내리는 경우는 이보다 더 쉽게 찾아볼 수 있다. 테스팅은 정보를 수집하는 프로세스이기 때문에, 수집한 정보에 대해 더 많은 테스팅이 필요한가라는 의문이 항상 제기된다. 그것은 또 다른 결정의 문제다.
조직 내의 누군가는 필요한 정보를 가지고 있든, 혹은 그렇지 않든 간에 결정을 내려야 하는 위치에 있기 마련이다. 만약 그 사람이 어떤 추가적인 정보가 제공되든지 간에 상관없이 동일한 결정을 내린다면, 더 많은 정보를 수집하고 테스팅하는 것은 별 의미가 없다. 만약 베니토 씨가 새로운 물류 시스템을 현 상태 그대로 가져가기로 결정했다면, 왜 그에게 쓸데없이 더 많은 정보를 제공해 그를 귀찮게 만들 것인가?
왜 테스팅을 성가셔 하는가?[1]
사실, 무언가를 더 많이 테스팅하는 것은 그만큼의 위험을 더하는 것이나 마찬가지다. 만일 베니토 씨가 물류 시스템에 대해 더 많은 테스트를 수행하고 그 결과를 기다리기 위해 제품 출시를 늦추기로 결정했다면, 그는 시장에 너무 늦게 진입하는 것일 수도 있다. 혹은, 테스팅에 너무 많은 돈을 탕진하느라 파산할 수도 있다. 이러한 이유로, 무엇을 테스트 할 것인가를 결정할 때 항상 비용과 시간을 고려해야 하는 것이다. 테스팅은 순식간에 완성되는 것도 아니고 공짜로 이루어지는 것도 아니다.
때때로, 추가로 수집된 정보는 위험을 증가시킨다. 만약 개발자들이 제품의 어떤 부분이 정상적으로 동작하지 않는다는 정보를 알게 된다면, 가능한 한 어느 정도라도 시간을 들여 그 부분을 수정하려 할 것이다. 사장인 베니토 씨의 관점에서 보면, 이러한 행위들은 이미 사용하기에 충분할 정도로 잘 동작하는 제품을 망칠 수도 있는 위험한 행위로 비춰질 수 있다.
당신은 아마 당신이 제어할 수 없는 개발 조직을 실질적인 위험 요소라고 생각할 수도 있지만, 그 밖에도 위험 요소들은 수도 없이 많다. 사용자들이 당신이 개발하고 판매한 소프트웨어의 결함을 문제 삼아 당신을 고소한다면, 아마도 법원은 당신의 개발 프로세스 기록을 열람하길 바랄 것이다. 만약 테스터가 그 버그를 발견했음에도 불구하고 당신이 이를 수정하지 않았다는 것이 기록되어 있다면, 처음부터 버그가 발견되지 않았을 때보다 더 난처한 지경에 처하게 될 것이다. 때론 현실을 무시하는 것이 축복이 될 수도 있다.
이와 같은 “속 편한 무시(Blissful-ignorance)”의 원리가 고객 담당자에게도 적용될 수 있다. 이미 시장에 출시된 제품에 결함이 있고 담당자가 솔직하게 “난 몰랐습니다”라고 말하는 것이, 그 담당자가 문제가 있다는 것을 알면서도 아무런 조치를 취하지 않았던 것보다는 덜 심각한 파장을 가져올 것이다.
교훈: 어느 수준 까지가 과도한 정보인지, 혹은 적당한 정보인지에 대해 신중하게 고려해보라. 하지만 당신이 무엇을 목표로 하고 있으며 이를 위해 무엇을 가장 우선시 해야 하는지에 대해서는 더 신중하게 생각해보라. 당신은 성공한 제품을 만들려고 노력하는 것인가? 아니면 법적 소송을 피하기 위해서 일하는가? 그것도 아니면 단순히 개인의 경력을 위한 것인가?
- End -
'QA' 카테고리의 다른 글
| 저는 기획이 하고 싶습니다 (6) | 2009.08.30 |
|---|---|
| 스모크 테스트의 어원과 의미 (4) | 2009.07.26 |
| 이해할 수 없는 퀘스트 완료 조건 (4) | 2009.06.28 |
| 좋은 사람을 구하는 법 (0) | 2009.06.11 |
| IEEE 829-1998 중 테스트 요약 보고서 부분 번역 (0) | 2009.05.15 |
