이 세상에서 제일 발견하기 힘든 결함은 무엇일까?

테스터 여러분. 이 세상에서 제일 발견하기 힘든 결함은 무엇이라고 생각하십니까?

그 전에 과연 결함이란 무엇일까요? 요즘은 이슈라는 단어를 더 많이 사용하기도 하는데...

솔직히 저희가 힘들이고 고생해서 잡은 결함도 기획팀에서 '기획 의도이다.' 라고 하거나 개발팀에서 '수정할 필요가 없다.'  는 한마디로 무시당하는 경우도 많습니다.

결함이라는 것에 대해 서로 인식하고 있는 바가 틀리기 때문입니다. 과연 결함은 무엇이고 이 세상에서 제일 발견하기 힘든 결함은 과연 무엇일까요?

아래 그림을 보시면 요구사항과 구현한 제품이 100% 일치하는 아주 아름다운 경우입니다. 이런 경우에는 요구사항에 따라 작동하지 않는 것은 모두 결함이라고 생각할 수 있습니다.

하지만 많은 경우 실제 제품과 요구사항은 정도의 차이는 있지만 대략 아래와 같다고 생각해 볼 수 있습니다.

위와 같은 경우에 색칠이 된 영역은 결함일까요? 결함이 아닐까요?
요구사항에 정의되어 있지 않지만 구현이 되어 있는 부분(특히 정상적으로 작동하는 부분)은 과연 결함일까요? 결함이 아닐까요?

조금 더 극단적으로 생각해서 아래와 같은 경우를 생각해 봅시다.

테스트해야 될 대상이 요구사항에 따라 구현된 부분이 단 한군데도 없이 정말 쌩뚱맞은 제품이 나온 경우 과연 이 제품 전체를 결함으로 생각해야 하는 것일까요? 아니면 구현된 제품 중 정상적으로 구동이 되지 않는 부분만을 결함으로 생각해야 하는 것일까요?

하지만 위의 경우에서 생각해 볼 수 있는 결함들보다 더 찾기 어려운 결함이 있다면 믿으시겠습니까?

믿으십시오.. 있습니다.

바로 요구사항이 아예 누락되어 버린 결함입니다. 즉, 요구사항으로 정의되어서 구현되어야 할 부분이 아예 요구사항으로 정의조차 되지 못한 경우입니다.

누락된 요구사항이 가장 발견하기 어려운 결함인 이유는 우리가 결함을 찾기 위해 테스트 케이스를 설계하는 절차 자체의 시작점이 요구사항으로부터 출발하기 때문입니다.

기본적인 테스트 활동이 요구사항으로 기준을 삼고 그 요구사항에 따라 제품이 정상적으로 구현되어 동작하는지 확인하는 활동이기 때문입니다.

그런데 요구 사항이 없다면 명세서에도 나타나지 않을 것이고 명세서에 없다면 테스트 케이스를 만들 수 없기 때문에 우리는 그것을 찾기 어렵게 되는 것입니다.

그렇다면 이렇게 누락되어버린 요구사항은 어떻게 찾을 수 있을까요?

요구사항에 기반한 접근법으로는 확실하게 발견할 확률이 거의 없다고 볼 수 있습니다. 왜냐하면 개발자들도 개발 과정에서 무엇인가가 누락되었다는 것은 어렴풋이 알고 있습니다.

하지만 빡빡한 일정에서 그런 것을 생각할 여유가 없기 때문에 우선 바이패스를 만들어서 해결해 버립니다.

그런데 이런 바이패스는 요구사항에 기반한 테스트로는 정상적인 동작을 하기 때문에 바이패스가 존재한다고 해서 이것을 바이패스라고 인식하기가 어렵습니다.

저는 이렇게 누락된 요구사항(또는 로직이라고도 부릅니다.)을 찾는 방법으로 탐색적 테스팅 접근법과 제약이론의 사고 프로세스,결정 테이블 테스팅 기법, 상태 전이 테스팅 기법등을 적절하게 섞어서 찾고 있습니다.

일부에서는 리뷰를 강조하기도 합니다.

(하지만 실제적으로 초기 테스트의 중요성과 초기 테스트에서 요구사항의 리뷰가 중요하다고 주장하는 사람들 안에서도 이런 결함에 대해서 논의하는 경우는 많이 보지 못했습니다. 사실 저는 이런 결함들에 대해 어렴풋이 개념만 가지고 생각하고 있었는데, '우리가 미처 알지 못한 소프트웨어 공학의 사실과 오해'에도 이미 소개되어 누군가는 이미 알고 있었던 결함이었습니다.)

그런데 이러한 결함을 찾는다고 해도 가장 큰 난관은 바로 요구사항을 수집하고 분석하는 기획자와 같은 사람들입니다.

그들은 어떤 로직이나 요구사항이 누락되었다는 것을 인정하기 보다는 그것이 누락된 것은 '기획의도다!' 라는 한마디로 넘어가기 때문입니다.

여러분은 누락되어버린 요구사항이나 로직을 찾아내신 적이 있으신가요?

있으시다면 어떤 방법으로 찾아보셨나요?