Surviving the Top Ten Challenges of Software Testing: A People-Oriented Approach by William E. Perry and Randall W. Rice

0

Surviving the Top Ten Challenges of Software Testing: A People-Oriented Approach by William E. Perry and Randall W. Rice

의 일부분의 번역을 올린다. 내용은 테스팅 자체라기 보다는 그를 둘러싼 환경에 대한 얘기가 되겠다. ^^

CHALLENGE #7: EXPLAINING TESTING TO MANAGERS

OVERVIEW

경영진의 관심을 끄는 다른 시스템 활동 전부와 비교했을때, 전통적으로 테스팅은 한번도 경영진의 최고 관심사나 우선순위에 오른 적이 없다. 어떤 사람들에게 테스팅은 시스템이 첫날부터 잘 작동할 것이라는 기대를 가지고 있는 듯이, 프로젝트 막바지에 "모든 것이 잘 작동하는지만 확인하는" 사소한 활동으로 여겨졌다. 또 다른 사람들에게 테스팅은 전문가들만 알아들을 수 있는 협박조의 작업이었다.

진실은 테스팅이 정보 시스템의 배포와 제작의 일부분으로 통합되어야 한다는 것이다. 테스팅은 복잡하거나 효율적으로 만들기 어려운 것이 아니다. 대부분의 사람들은 그들이 기술적인 배경을 가지고 있던, 그렇지 않던간에 훌륭한 테스터들이 되기위한 교육을 받을 수 있다. 테스팅 또한 다른 시스템 개발 활동처럼 관리되어야 한다. 누군가는 프로세스 정의, 툴 선택, 테스트 활동의 촉진, 이슈 해결을 위해 테스터와 협업 등의 책임을 져야한다.

경영진의 지도와 방향제시가 없다면 테스팅은 무작정 진행되고 비효율적이 된다.

이 장에서는 정확한 테스팅의 관점과 어떻게 경영진이 테스팅에 대한 인식을 높일 수 있을지에 대해서 얘기해 보겠다. 경영진이 비효율적인 테스팅의 위험과 효율적인 테스팅을 위해 필요한 것을 인식할 때, 테스팅이 단순 기능적 측면에서 품질 제어의 필수적인 기능으로 자리매김하게 될 것이다.

결국, 프로젝트 시간의 반을 소모하는 어떤 활동도 관심을 가져야할 가치가 있는 것이다.

STATE OF THE PRACTICE

테스트 팀 리더인 조는 요즘 우울하다. 방금 개발 일정이 다시 한 번 늦어졌다는 소식을 들었기 때문이다. 테스트 팀은 계획된 6주의 테스팅 스케줄이 2주가 될때까지 소프트웨어를 테스트할 수 없을 것이다. 조가 두려워하는 것은 최종 인도일자는 그대로일 것이기 때문이다.

사실 그의 경영진은 이미 테스트 결과와 상관없이 약속된 일정에 고객에게 인도하기로 약속을 했다. 테스팅 동안에 그 프로젝트 팀의 역할은 테스트로 찾아낸 결점을 가능한 한 많이 수정하는 것이었다. 그 팀의 모토는 "중요한 부분에만 집중하고, 나머지 소소한 것들은 그대로 두자." 였다.

조는 경영진에 더 많은 테스터와 테스트 툴의 구매를 요청했지만 거부당했다. 경영진은 그 돈이라면 소프트웨어 패키지 디자인이나 프로젝트 팀 축하 파티에 쓰는 것이 더 낫다고 생각했다. 조는 그의 역할이 프로젝트 내에서 형식적이라고 느꼈다. 그는 그와 그의 팀이 경영진이 모든 프로젝트는 최소한의 테스트만 되어야 한다는 태도를 가지고 있기 때문에 최소한의 테스팅만 한다는 생각을 가졌다.

그날밤, 조는 시내를 가로질러 한 회사에 다니는 테스터인 그의 친구 펫과 얘기를 나누고 있었다. 그녀는 조를 동정했고, 과거에 그녀도 유사한 이슈로 고민했었다고 말했다. 하지만, 그녀 회사의 경영진이 테스팅에 대해서 혁신적인 접근법을 시도했기 때문에 그녀는 신이 난다고 했다. 그녀의 경영진은 제품보다는 프로세스에 집중하였다. 프로젝트 팀의 모든 사람들은 펫의 회사 내의 테스팅에 참여하게 되었다. 가장 눈에띄게 달라진 점중 하나는 테스팅 리더가 참여하는 프로젝트 조정 위원회가 만장일치로 제품의 출시를 승인하지 않으면, 출시되지 않는 것이었다. (One of the most significant changes is that if the project steering committee, including the leader of testing, does not unanimously agree the product is ready for release, it is not released.) 펫의 팀은 요청하는 모든 것을 얻을 수는 없었지만, 테스트 툴을 평가하는 과정에 있었고, 팀에 3명의 사람을 더 고용하도록 승인되었다. 바로 그때가 조가 갑자기 기회를 잡은 때였다. 이력서를 업데이트 하는 것이 좋을 것이다! (* 역자주: 다른 회사에 입사 지원함을 은유적으로 표현.)

이 시나리오에서 조와 펫은 유사한 책임을 맡고 있고 유사한 도전에 직면해 있다. 펫이 직업에 대한 비전을 가지고 더 효과적이 될 수 있었던 큰 차이점은 그녀의 경영진이 테스팅에 대해서 이해하고 있다는 점이다. (The main difference that causes Pat to be more effective with a healthier job outlook is that her management understands testing.) 펫의 경영진은 테스트 활동을 금전적으로만 지원하는 것이 아니라, 테스팅이 중요하며 올바로 되지 않은 경우 출시되어서는 안 된다고 보고 있었다.

펫의 조직은 다른 경영 문화를 가지고 있었으며, 그것은 품질을 믿으며 그 믿음대로 실행하는 것이었다. 이러한 문화는 지금부터 5-10년후의 프로젝트를 내다보는 것이다. 펫의 경영진은 소비자들이 겉만 번지르르한 소프트웨어를 참지 않으며, 뛰어난 품질의 제품을 선택할 것이라고 보았기 때문이었다.

이런 경영문화는 역시 사람에 큰 가치를 둔다. 회사를 경쟁 그룹으로 쪼개기 보다는 성공을 위해서는 상호간에 의존하도록 팀으로 조직한다.

IMPACT ON TESTING

우리가 조사한 조직들의 25%이상이 테스팅 활동의 매니저가 없었다. 사람들이 테스팅에 올바른 툴과 프로세스를 가지고 있는지 확인하는 역할을 가진 사람이 없었으며 심지어 테스팅이 전혀 수행되고 있지도 않았다! 테스팅 리더나 매니저가 없는 경우 사람들은 손쉽게 프로젝트에 적정해 보이는 테스팅 수준이 어떤 것이든간에 수행하는 경향이 있다. 마감일이 다가오면, 테스팅이 완전한 것으로 생각하게 되어, 출시 이후에 문제가 발생하면 관리자는 누군가 비난할 사람을 찾게된다.

An Unsupportive View of Test Management

조직 내의 다른 영역에서 이런 경우가 발생하면 어떻게 되는지 생각해 보자. 소프트웨어 개발 영역에 관리자가 없고, 인사 관리자가 없고, 영업 관리자가 없다면 아무것도 이루어지지 않을 것이다. 테스팅은 대부분의 조직에서 임의적으로 수행되는데, 단순히 테스팅을 효과적인 프로세스가 되게 하기 위한 시도와 인식이 없기 때문이다. 경영진이 테스팅을 지원하지 않으면 어떻게 될까? 아래의 반응들이 발생할 것이다.

• 테스팅은 사치이다.

테스팅은 소프트웨어에 대한 품질 제어이다. 맞다. 지켜야 할 마감일이 있고, 지켜야 할 약속이 있는 경우에 진실이다. 하지만, 실버 불릿이 발견되기 전까지는 테스팅은 고객이 결점을 발견하기 이전에 소프트웨어의 결점을 찾아내는 방법이다. 어떤 소프트웨어 개발 조직에서는 고객이 결점을 찾아내도 문제가 없다. 하지만, 항공사나 수혈 은행 같은 고위험군의 어플리케이션에서의 소프트웨어 결점은 매우 심각한 일이다. 테스팅은 소프트웨어 개발 또는 유지보수 프로세스의 일부로 간주되어야 한다. 마찬가지로 품질제어 또한 제조 프로세스의 일부로 통합되어야 한다. 품질있는 제품을 생산하는 회사들은 품질제어를 시행한다. 품질제어는 모든 방식의 단계마다 프로세스의 일부가 되며 이것은 사치가 아니다.

• 테스팅은 최후의 시간이 되면 무시할 수 있는 것이다.

경영진이 프로젝트 막바지에 테스팅 일정을 허락할 때는, 프로젝트가 최악의 실패에 직면했음을 의미한다. 프로젝트 막바지에 수많은 결점이 발견되고, 문제를 고립시킬 수 없으며, 수정 비용이 비싸게 들고, 마지막까지 수정하는 것이 다른 시스템 영역에 영향을 미친다. 추가적으로 막바지에 발견된 결점의 해결을 위한 정치적인 입장 차이가 주요한 이슈가 된다. 예를 들어, 회사는 시스템 성능이 떨어지는 문제에 대한 해결책이 수백만 불짜리 하드웨어를 구입하는 것외에 없는 것을 별로 좋아하지 않을 것이다.

• 테스팅으로 모든 결점을 발견해 낼 수 있다.

이 태도는 경영진이 테스팅으로 발견해내지 못한 결점에 대해서 나무랄 때 증명이 된다. 역설적으로 경영진은 테스팅을 불필요한 것으로 생각하기도 하면서, 모든 결점을 찾아내는데 테스팅을 기대하고 있는 것이다. (This attitude is evident when management blames the testers for a defect not found during testing. Paradoxically, management feels that testing is superfluous, yet it depends on it to find all of the defects.)

진실은 대부분의 소프트웨어에서 실행 가능한 테스트 케이스의 수가 천문학적이라는 것이다. 당신이 디자인한 테스트 케이스 전체에 대해서도, 누군가는 당신이 생각지도 못했던 것을 하나 이상 발견해 낼 수 있을 것이다. 개발 앞부분에 시행되는 기술 인스펙션과 같은 결점 제거 퍼센티지를 높이는 방법도 있다. 하지만, 여전히 소프트웨어의 복잡한 영역 밑에 결점이 자리잡고 있을 확률이 있다. 이러한 골치거리에 대한 논의를 보고 싶다면, 'Scuentific American' 잡지의 "The Risks of Software"를 읽어보라.

• 테스팅은 협박하는 것으로 인식된다.

테스팅 도전과제중 또 다른 영역은 종종 테스팅이 협박하는 영역으로 인식된다는 것이다. 사람들은 그들이 이해하고 있지 않은 것에 대해서는 불편함을 느낀다. 특히 경영진에 있어서는 사실이다. 경영진이 테스팅에 대해서 간섭하지 않는 정책을 취할때는 테스팅의 도전과제와 이슈에 대해서 그들에게 알려야 한다. 경영진으로 부터 자주 듣는 말은 다음과 같다. "왜 그것에 대해서 테스트하지 않았소?"

경영진은 효과적인 테스팅이란 툴, 프로세스, 사람의 지원이 필요하며, 기본적인 원칙들을 준수하는 문제라는 점을 이해할 필요가 있다. (Management needs to understand that effective testing is a matter of following basic principles and that support is needed for tools, processes, and people.) 경영진이 이러한 방식으로 이끌지 않는다면, 테스팅 활동은 효율성에 제약을 받을 수밖에 없을 것이다.

• 사람을 투입함으로써 테스트 툴의 부족을 보충할 수 있다.

경영진은 소프트웨어의 변경 때문에 테스팅이 종종 반복적으로 일어나는 정확한 활동이라는 점을 이해할 필요가 있다. 정확한 테스트의 반복성은 자동화된 툴을 사용해야만 달성할 수 있다. 경영진이 툴의 지원을 반대하고, 사람이 수동으로 테스트하는 것으로 대체하려고 할 때, 사람의 시간을 비효율적으로 사용하는 것에 비용을 지불하는 것이다. 많은 경우, 다른 팀들은 툴을 얻게되지만, 테스터들은 그렇지 못하다.

훌륭한 툴이 없는 경우도 있다. 종종, 기술적인 영역이나 다른 요인들은 상업적으로 이용 가능한 테스트 툴의 사용을 제한한다. 이런 경우, 방법은 계속 수동으로 테스트를 계속하거나 자신들만의 툴을 만드는 방법 밖에는 없다.

• 마감일이 테스트를 마쳐야하는 때를 알게 되는 유일한 지표이다.

많은 조직에서 마감일은 테스트를 완료하는 주요한 요인이다. 한가지 이유는 품질보다 정시에 출시하는 것이 중요하다고 생각하는 것이다. 하지만, 누군가 말했듯이 "쓰레기가 정시에 배달되어도 쓰레기는 쓰레기다." 라는 말이 있다.

마감일을 중시하는 테스팅의 또 다른 이유는 테스팅이 무계획적일 때이다. 이것은 '음악을 끝나자 마자 제한된 의자에 앉는 놀이'와도 같다. 음악이 끝나면 빈자리를 찾아 헤매고, 누군가 (이 경우에는 "무언가")가 나가는 것을 지켜보는 것이다. 사람들은 자신들에게 할당된 시간동안 무엇이든 테스트할 수 있으며, 고객이 발견할 수 있는 것들은 테스트되지 않은 것이다. 이런 접근방법의 또 다른 변종은 테스팅이 계획되었지만, 프로젝트 스케줄이 테스팅을 위한 시간을 고려하지 않은 것이다. 마감일을 지킬 것인가 아니면 품질 있는 소프트웨어를 출시할 것인가 사이의 선택은 경영진의 품질에 대한 신념을 재는 주요한 테스트 수단이다. (Making the choice between meeting the deadline and delivering quality software is a major test of management's commitment to quality.)

{중략}