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

테스트는 결함이 있음을 증명하는 활동이다. 테스터는 결함이 있음을 증명해야 한다. 결함이 있음을 증명하기 위해서는 무엇이 결함인지를 알아야하며, 어떤 현상이 결함인지 아닌지에 대하여 판단을 내릴 수 있어야 한다. 그러기 위해서는 결함이 무엇인지를 알아야한다. ISTQB 등에서는 결함이 사람의 실수 즉, 오류에 의해 발생한다고 설명되어 있다. 즉, 결함을 정확히 이해하기 위해서는 우선 오류가 무엇인지 그리고 사람의 실수가 무엇이며 사람이 왜 실수를 하는지에 대한 이해가 있어야 한다고 할 수 있다. (물론 모든 결함이 사람에 의해 발생하지는 않는다.) 자, 그럼 오류란 무엇일까? 사람의 실수란 무엇일까? 오류에는 여러가지 형태가 있다.(여기서 잠깐, 매번 글을 적으면서 느끼는건데 난 통일된 문체를 유지하지 못하는 신기한 특성이 있다. '다' '나' '까' 로 끝나다가 '습니다'와 같은 문체가 같은 글에 반복되더라도 글을 읽으시는 분들은 양해를 해주시기를 바랍니다.) 여러가지 형태의 오류를 크게 두가지로 구분하자면 실수와 착오로 구분할 수 있다. 우리가 흔히 실수라고 부르는 mistake 는 사실 착오이다. 실수는 slip 으로 불린다. 착오와 실수는 어떻게 다른 걸까? 실수는 실수를 한 사람이 그것을 인지하지 못한다. 실수는 우리가 어떤 목적을 달성하기 위해서 수행하는 무의식적이고 자동적인 행동에서 발생한다. 예를 들면 우리가 계단을 올라갈때 왼발 들어올리고 다음 계단 확인하고 왼발 디디고 오른발 들어올리고 다음 계단 확인하고 오른발 디디는 과정을 면밀하게 관찰하고 생각하면서 수행하지는 않는다. 우리가 계단을 올라가는 과정은 전적으로 자동으로 진행된다. 생각이라는 것 자체를 잘 하지 않는다. 하지만 우리가 계단을 올라가는 도중에 이쁜 여자(?)를 쳐다보거나 스마트폰 삼매경에 빠져있을 때 계단이 없음에도 올라가는 행동을 하다가 발을 헛디딘 경험을 해본 분들이 계실 ...

일전에 경로 의존성에 대해 이야기 한적이 있었다. 경로 의존성에 대한 것은 이전 포스팅 을 읽어보시기 바란다. 한번 한 얘기 두번 하는거 생각보다 쉽지 않습니다. 갑자기 웬 경로 의존성이냐? Extreme Programming 2판을 읽으면서 소프트웨어 테스팅이 왜 개발 과정에서 중요한 대우를 받지 못하는지, 왜 소프트웨어 개발의 성공율이 획기적으로 개선되지 못하는 가에 대한 경로 의존성을 생각하게 되었다. 인류의 짧으면서도 짧지 않은 역사 속에서 가장 먼저 시작된 프로젝트는 무엇일까? 그것은 아마도 건축이 아닐까? 싶다. 지금도 이집트나 세계 곳곳에서 수천년동안 그 위용을 자랑하는 수많은 건축물들이 남아 있다. 고고학자들은 지금의 기술로도 불가능할거라는 건축물들도 있다. 어쨌든 수많은 프로젝트에서 건축이 인류가 시작한 가장 오래된 프로젝트의 유형 중 하나라는 데는 별다른 큰 이견이 없을 것이라고 생각한다. 건축은 그 오래된 역사 속에서 많은 방법들이 시도되었고 그 수많은 방법과 경험, 실패 속에서 정제되어 최근에 있어서는 그 신뢰성은 믿을만한 수준에 도달했다. 물론 무너지는 건물도 있긴 하지만.. 가장 신뢰성 높은 관리 방법론을 가지고 있는 프로젝트인 것은 확실한 듯 하다. 그리고 건축은 그 오래된 역사속에서 다른 종류의 프로젝트 관리 방법론에 많은 영향을 끼쳤고 많은 프로젝트관리 방법론이 건축에 관한 메타포를 근본으로 하고 있는 경우가 많다. 최근에 많이 논의되고 있는 Pattern 도 그 시작은 건축이었다. 어쨌든 건축의 프로젝트 관리 방법론을 기반으로 하는 수많은 관리 방법론들은 실제로 커다란 문제를 일으키는 경우는 많지 않다. 그런데, 우리가 한가지 간과하고 있는 것이 하나 있다. 우리 주변의 많은 프로젝트들은 물리적인 세계를 관리하는 경우가 많다는 것이다. 건축은 분명 우리가 쉽게 인식할 수 있는 물리적인 것이다. 철강, 선박 등 많은 것들은 우리가 쉽게 인식할 수 있는 물리의 세계에 속해 있다. 그런데 소프트웨어는 어떨까? 소프트웨어 프로세스의 많...

육하 원칙을 모르는 분은 아마 없을 것입니다. 어떤 상황에 대해 논리적으로 구술할 때 가장 먼저 배우는 것이 육하 원칙이죠. 육하 원칙은 5W 1H라 하여 '누가'(who), '무엇을'(what), '언제'(when), '어디서'(where), '왜'(why), '어떻게'(how) 로 구성됩니다. 아래에 쓸 글은 이 육하 원칙을 이용해서 현재 논의되는 소프트웨어 테스팅의 흐름에 대한 제 개인적인 생각으로 실제와 틀릴 수도 있으며, 저와는 의견을 다르게 가지고 계실 분도 계시리라 생각합니다. 언제나처럼 댓글과 트랙백은 환영합니다. 하나씩 살펴볼까요? '누가'에 대한 것은 최근에는 누구나 한다가 최근 흐름이라고 생각합니다. 소프트웨어 개발에 관련된 모든 사람들이 테스팅에 대한 기본적인 개념을 가져야 한다는 것이 최근의 흐름이라고 볼 수 있습니다. 국내 사정은 글쎄요? 저도 여기저기 얘기를 하고 다니지만 아직은 아닌 것 같습니다. 지난 몇년간 많은 인식 개선이 있었지만 아직은 아닌 것 같습니다. '무엇을'은 테스팅의 대상을 선정하는 문제입니다. 많은 분들이 이건 우리는 정말 잘한다라고 말씀들을 하시지만 제가 볼때는 아직도 저 하늘의 구름과 같이 애매모호한 대상을 선정하시는 분들도 많습니다. 많은 분들이 소프트웨어 테스팅은 돈과 시간을 잡아먹는 필요악 정도로 생각하시는 분들이 많은데 그 이면에는 대체로 이 '무엇을'에 대한 고민이 깊이 없는 경우가 많습니다. 테스팅을 의뢰하는 쪽은 정확히 '무엇을' 테스트 해주기를 명확하게 정의할 필요가 있습니다. 애매모호하게 잘 되나 봐주세요.. 라든지.. 그냥 다 해주세요... 이런건 곤란합니다. 테스트 계획 문서의 가장 처음에 들어가는 요소 중 하나로 매우 중요한 요소 중 하나라고 할 수 있습니다. '언제'에 대한 것은 최근에 꽤 널리 테스팅은 소프트웨어 개발 초기부터 수행...