테스팅 히치하이커를 위한 안내서

우리는 더 나은 품질을 가진 제품을 만들기 위해 노력합니다. 우리는 더 빠른 시간안에 제품을 출시하기 위해 노력합니다. 우리는 더 적은 예산으로 제품을 개발하기 위해 노력합니다. 우리는 고객이 진정 원하는 제품을 개발하기 위해 노력합니다. 그러기 위해서 우리는 많은 부분에서 개선을 위해 노력하고 있고 수많은 방법론을 시도하고 있습니다. 하지만, 성공하는 경우는 매우 드물고, 많은 프로젝트가 계획된 일정을 어기고 더 많은 리소스를 사용합니다. 고객이 원하는 제품이 인도되는 경우도 드물고 끊임없는 유지보수 요구에 시달리고 있으며, 출시 후 쏟아지는 결함에 철야를 할 때도 있습니다. 왜 개선은 일어나지 않고 매번 이런 일이 반복되는 것일까요? 이러한 이유는 여러가지를 생각해 볼 수 있지만 개선을 수행하고 주도해야할 당사자의 입장에서 본다면 크게 2가지를 생각해 볼 수 있습니다. 통제권 과 취약성 이 두가지가 해결되지 않는다면 개선은 이루어질 수 없다고 생각합니다. 만약 어떤 개선안에 대하여 저항이 없다면 조직이 그 개선안을 통제권과 기득권에 대한 위협이라고 느끼지 않기 때문일 것입니다. 통제권과 취약성은 비슷한 듯 보이지만 그 주체가 다릅니다. 통제권은 개선의 대상이 되는 조직의 관리자들이 주체입니다. 취약성은 개선의 대상이 되는 조직이 주체입니다. 우리는 회사와 조직의 정책과 신념, 가치관이 있지만 사실 이런건 허울 좋은 말장난에 불과한 경우가 많습니다. 한층 더 밑으로 내려가 본다면 회사는 정치 체제와 마찬가지라는 것을 우리는 이미 알고 있습니다. 정책의 결정과 실행 그 모든 것은 권력을 행사하는 것이고 권력은 곧 정치적인 행위를 야기시키는 것으로 회사 역시 정치에서 자유롭지 못합니다. 이런 상황에서 관리자들에게 통제권은 매우 중요한 요소가 됩니다. 많은 관리자들은 겉으로는 조직의 생산성과 효율성을 얘기하지만 그들에게 정작 중요한 것은 통제권입니다. 통제권을 유지할 수만 있다면 어떠한 손실이라도 감당할 준비가 되어 있는 것입니다. 즉, 애자일 프로세스와 같이 최...

결함은 왜 생기는 것일까요? 많은 경우 우리는 결함은 개발자 때문에 생긴다고 생각합니다. 어떤 조직에서는 개발자 별로 결함율을 측정하여 인사고과를 매기는 곳도 있습니다. 그런데 과연 결함은 개발자 때문에 생기는 것일까요? 이 질문에 대답하기 전에 생각해 볼것은 결함이란 무엇인가? 하는 질문입니다. 결함은 무엇일까요? 답을 확인 하기 전에 한번 꼭 생각해 보시기 바랍니다. 펼쳐두기.. 결함은 에러로 인하여 발생할 수 있는 장애나 어떤 사건을 실제로 확인한 경우 결함이라고 부릅니다. 에러는 인간의 실수로 발생합니다. 정리하면 결함은 소프트웨어 개발 중 사람의 실수로 인하여 소프트웨어가 기대한 결과와 다르게 작동하거나 장애를 발생시킬 수 있는 상황을 발견한 것이라고 할 수 있습니다. 하지만 결함이 모두 장애를 일으키는 것은 아닙니다. 여기서 중요한 것은 사람의 실수 입니다. 여기서 말하는 사람은 꼭 개발자만을 지칭하는 것이 아니라는 것이 중요합니다. 소프트웨어 개발에는 매우 많은 사람이 참여합니다. 기획자, 사용자 분석가, 개발자, 그래픽 디자이너, 테스터, 마케터 등등 적게는 10여명부터 많게는 수백명이 넘는 사람이 소프트웨어 개발에 참여합니다. 이 모든 사람이 하는 실수는 곧 에러가 되고 이러한 에러가 결함이 됩니다. 때문에 결함이 꼭 개발자 때문에 생기는 것은 아닙니다. 사용자가 자신이 원하는 기능을 잘 정의하지 못하는 경우도 결함이 될 수 있으며, 사용자의 요구사항을 잘못 설계하는 경우도 결함이 될 수 있고, 테스터가 요구사항이나 기능 명세를 잘 못 분석하여 설계한 테스트 케이스 때문에 결함이 생길 수도 있습니다. 즉, 결함은 누구나 만들어 낼 수 있기 때문에 소프트웨어 개발에 참여하는 사람들은 그러한 사실을 인지하고 늘 조심해야 합니다. 그러기 위해서 모든 구성원이 기초적인 테스트 지식을 가지고 있는 것이 좋습니다. 그런데 문제는 이것 뿐만이 아닙니다. 결함은 사람 때문에 생깁니다. 아마 소프트웨어가 지상에 존재하는 한 절대로 결함이 없는...

조직에서 테스터의 자질은 무엇으로 평가되어야 할까요? 품질은 어떤 지표로 측정해야 하는 걸까요? 테스트의 결과는 무엇을 측정해서 제출해야 하는 걸까요? 개인적으로 테스터 개개인을 측정하는 것에는 반대하는 입장이다. 도데체 테스터의 가치를 단순한 숫자로 정의 내릴 수 있다는 생각은 누가 한 것일까? 개개인을 단순한 숫자로 측정하는 것은 관리자의 편의성을 생각해 볼때 이만한 해결책 이상은 있을 수가 없다. 하지만 내가 테스터 개개인의 측정을 반대하는 것은 측정 자체가 아니라 어떤 기준에 맞춰 모든 테스터가 그 기준을 상회해야한다는 그 어이없는 믿음에 반대하는 것이다. 예를 들면, 테스트 케이스의 갯수, 결함 발견 갯수 등등으로 테스터의 능력치를 측정합니다. 그런 이면에는 모든 사람이 슈퍼맨이길 바라는 관리자의 헛된 야망이 숨어있습니다. 하지만 모든 사람이 다 슈펴맨이 가능한 걸까요? 슈퍼맨이 된다고 해도 그런 슈퍼맨들만 모인 팀의 생산성이 과연 높은 것일까요? 예전에 히딩크 감독이 멀티 플레이를 주장했다 하지만 그렇다고 해서 축구에서 진영이나 포지션이 없어진 것은 아니다. 그리고 날고 긴다는 사람들만 모아놓은 대표팀이라고 해서 언제나 어디서나 승리하는 것은 아니라는 것을 알고 있다. 테스터 개개인의 능력을 측정하는 것은 필요로 하는 일이다. 하지만 테스터가 모든 분야에서 특정 기준 이상이어야 한다는 믿음에는 동의할 수 없다. 조직원의 특성을 파악하고 그 특성을 조화롭게 이끌어 내어 팀의 생산성을 높일 수 있는 관리자가 필요하다. 다양한 척도를 이용해서 테스터의 생산성을 측정하겠다는 가장 큰 약점이라면 테스터가 측정값을 속이기 쉽다는 것이다. 테스트나 품질 그 자체보다는 성과와 인사고과만을 위해 일하는 바보같은 테스터가 양산되어 버린다. 예를 들어 테스트 케이스 갯수를 가지고 생산성을 측정한다면 테스터는 의도적으로 의미없는 테스트 케이스 갯수를 늘릴 가능성이 매우 높다. 단순히 결함의 갯수만으르 가지고 측정한다면 테스터는 오타와 같은 쓸모없는 결함만을 양산해 낼 가...