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

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

테스터 여러분. 이 세상에서 제일 발견하기 힘든 결함은 무엇이라고 생각하십니까? 그 전에 과연 결함이란 무엇일까요? 요즘은 이슈라는 단어를 더 많이 사용하기도 하는데... 솔직히 저희가 힘들이고 고생해서 잡은 결함도 기획팀에서 '기획 의도이다.' 라고 하거나 개발팀에서 '수정할 필요가 없다.'  는 한마디로 무시당하는 경우도 많습니다. 결함이라는 것에 대해 서로 인식하고 있는 바가 틀리기 때문입니다. 과연 결함은 무엇이고 이 세상에서 제일 발견하기 힘든 결함은 과연 무엇일까요? 아래 그림을 보시면 요구사항과 구현한 제품이 100% 일치하는 아주 아름다운 경우입니다. 이런 경우에는 요구사항에 따라 작동하지 않는 것은 모두 결함이라고 생각할 수 있습니다. 하지만 많은 경우 실제 제품과 요구사항은 정도의 차이는 있지만 대략 아래와 같다고 생각해 볼 수 있습니다. 위와 같은 경우에 색칠이 된 영역은 결함일까요? 결함이 아닐까요? 요구사항에 정의되어 있지 않지만 구현이 되어 있는 부분(특히 정상적으로 작동하는 부분)은 과연 결함일까요? 결함이 아닐까요? 조금 더 극단적으로 생각해서 아래와 같은 경우를 생각해 봅시다. 테스트해야 될 대상이 요구사항에 따라 구현된 부분이 단 한군데도 없이 정말 쌩뚱맞은 제품이 나온 경우 과연 이 제품 전체를 결함으로 생각해야 하는 것일까요? 아니면 구현된 제품 중 정상적으로 구동이 되지 않는 부분만을 결함으로 생각해야 하는 것일까요? 하지만 위의 경우에서 생각해 볼 수 있는 결함들보다 더 찾기 어려운 결함이 있다면 믿으시겠습니까? 믿으십시오.. 있습니다. 바로 요구사항이 아예 누락되어 버린 결함입니다. 즉, 요구사항으로 정의되어서 구현되어야 할 부분이 아예 요구사항으로 정의조차 되지 못한 경우입니다. 누락된 요구사항이 가장 발견하기 어려운 결함인 이유는 우리가 결함을 찾기 위해 테스트 케이스를 설계하는 절차 자체의 시작점이 요구사항으로부터 출발하기 때문입니다. 기본적인 테스트 활동이 요구사항으로 기준을 삼고 그...