Software Testing Foundations - The Psychology of Testing

Software Testing Foundations의 "테스팅의 심리" 부분을 발췌, 번역해 본다.

2.3 테스팅의 심리

사람들은 실수를 한다. 하지만, 그들은 그것을 허용하는 것을 좋아하지 않는다! 소프트웨어를 테스팅하는 한가지 목적은 소프트웨어나 그 명세 또는 고객의 필요 간의 불일치를 밝혀내는 것이다. 발견된 실패들은 개발자에게 리포트되어야 한다. 이 장은 어떻게 심리적인 문제들을 처리할 것인지를 서술한다.

소프트웨어 개발 작업은 종종 건설적인 액션으로 보인다. 문서나 소프트웨어를 점검하는 작업은 파괴적인 액션으로 보인다. 이러한 인식만으로는 이미 그 작업에 포함된 사람의 작업에 대한 태도가 다르다고 볼 수 있다. 하지만, 이러한 차이는 정당하지 않다. 왜냐하면, "테스팅은 극도로 창의적이며, 지적인 도전 과제"이기 때문이다[Myers 79, p.15].

"개발자가 자기 자신의 프로그램을 테스트할 수 있나?"는 중요하고 자주 질문받는 내용이다. 모든 경우에 유효한 답변은 존재하지 않는다. 테스터가 또한 프로그램의 저자라면, 그 자신도 본인의 작업에 대해서 매우 비평적으로 검사해야 한다. 아주 소수의 사람들만이 자신이 작업한 제품과 필요한 거리를 둘 수 있다. 자신의 작업에 오류가 있다는 것이 증명되는 걸 진정을 좋아할 사람이 있을까? 자기 자신의 소스코드가 아주 잘 작동한다고 보여주는데 더 흥미를 가질 것이다.

개발자 테스트의 가장 큰 약점은 자기 자신의 프로그램 파트를 테스트하는 모든 개발자가 너무나 낙관적인 경향을 보인다는 점이다. 개발자는 테스팅 보다 프로그래밍에 더 관심을 보이거나 피상적으로만 테스트하기 때문에, 이성적인 테스트 케이스들을 잃어버릴 위험이 있다.

만일 개발자가 기본적인 디자인 오류를 범했다면, 예를 들어 그가 개념적인 공식을 잘못이해 했다면, 자신의 테스트로는 발견하기가 불가능하다. 심지어 적절한 테스트 케이스가 떠오르지 않을 수 있다. 이러한 "자신의 문제에 대해서 둔감함"의 문제를 감소시킬 한 가지 가능성은 짝을 지어 작업하거나, 동료에 의해 프로그램이 테스트되도록 하는 것이다.

한편, 자기 자신의 테스트 대상에 대해 많은 지식을 가진다는 장점도 있다. 테스트 대상에 대해서 배울 필요가 없으며, 따라서 시간이 절약된다. 관리자는 (프로그래머가) 자신의 오류에 둔감한 약점과 시간을 절약하는 장점간에 결정을 해야 한다. 그 결정은 테스트 대상의 심각성과 관련된 실패 리스크를 바탕으로 이루어져야 한다.

독립적인 테스팅 팀은 테스트에 대한 이해와 품질을 높이려는 경향이 있다. 테스터는 테스트 대상을 왜곡없이 바라볼 수 있다. 그것은 "그"의 제품이 아니며, 개발자의 잘못된 이해와 (잘못된) 가정이 테스터의 잘못된 이해와 (잘못된) 가정이라고 여길 필요가 없다. 테스터는 테스트 케이스를 작성하기 위해서 테스트 대상에 필요한 지식을 획득해야 한다. 이것은 시간이 드는 작업이다. 하지만, 테스터는 개발자가 처음부터 가져야 하는 또는 가지지 않은, 깊은 테스트 노하우를 가지고 있다(또는 필요한 시간이 가끔은 주어지지 않기 때문에, 사전에 획득해야 하는).

테스터의 작업은 관찰된 불일치와 실패를 저자나 관리자에 보고하는 것이다. 이렇게 하는 방식은 개발자와 테스터 간에 협력적이 되거나, 이 두 그룹간의 중요한 의사 소통에 부정적인 영향을 미치는데 기여한다. 다른 사람의 오류를 증명하는 것은 쉬운 작업이 아니며, 수완과 솜씨가 필요하다. (To prove other peoples' errors is not an easy job and requires diplomacy and tact.)

테스팅 동안에 발견된 실패가 개발 환경에 있는 개발자에게 재현되지 않는 문제가 가끔 있다. 실패의 상세한 설명외에, 테스트 환경 또한, 상이한 동작의 원인이 될 수 있는 환경에서의 어떤 차이점을 추적하기 위해서 상세히 기록되어야 한다.

사전에 무엇이 실패나 불일치를 구성하는지 정의되어야 한다. 만일 요구사항이나 명세에서 명확하게 알 수 없다면, 고객이나 관리자에게 결정하도록 요청한다. (프로젝트에) 포함된 인력, 개발자 그리고 테스터간의 논의는 이것이 결함인지 아닌지에 대해서 도움이 되지 않는다. 또한 자주 듣는 어떤 코멘트에 대한 개발자의 반응인 "이것은 버그가 아닙니다. 기능입니다!"는 매우 도움이 되지 않는다.

그들 각자의 작업에 대한 상호 이해는 테스터와 개발자 간의 협력에 도움이 된다. 개발자는 테스팅의 기초를 이해하고 있어야 하며, 테스터는 소프트웨어 개발의 기본적인 지식을 가지고 있어야 한다. 이것은 상호간의 작업과 문제들에 대해서 이해하기 쉽게 한다.

개발자와 테스터 간에 존재하는 것으로 보여지는 충돌은 유사하게 관리자 레벨에서도 있을 수 있다. 테스트 관리자는 프로젝트 관리자에게 테스트 결과를 리포트해야 하며, 그렇게 해서 종종 나쁜 소식의 전달자가 된다. 그러면 프로젝트 관리자는 여전히 데드라인을 맞출 기회가 있는지, 알려진 문제를 안고 배포하는 것이 가능한지, 배포가 지연되고 수정을 위해 추가적인 시간이 필요한지에 대해서 결정하는 작업을 한다. 이러한 결정은 실패의 심각도와 소프트웨어의 결점을 회피할 가능성이 있는지를 바탕으로 해서 이루어져야 한다.