소프트웨어 테스터로서 겪는 딜레마 중 하나가 도데체 얼마나 테스트를 해야 충분한가?에 대한 문제입니다. 경영진을 포함해서 많은 사람들이 테스트 결과 보고서를 보면서 말합니다. 테스트가 충분히 진행되었나요? 결함은 없나요? 출시해도 괜찮은거죠? 이 질문들에 확신에 찬 대답으로 '물론입니다'라고 대답할 수 있는 테스터가 과연 있을수가 있기나 한지 의문이 듭니다. 이런 문제는 소프트웨어가 형체가 정의되지 않은 불확정성을 내포한 상태이기 때문이라고 생각합니다. 예를 들어, 하드웨어라 한다면 우리가 테스트를 해야할 범위와 한계가 명확해집니다. 우리가 먹는 식품이라면 구성 성분들이 인체에 유해한지 검사하고 그 과정 전체를 관리 감독하는 것이 불가능하지 않을 것입니다. 재료의 선정부터 출시까지 일관된 기준으로 검사와 관리가 가능합니다. 하지만 소프트웨어는 어떨까요? 요구사항을 수집, 분석, 정의해서 나온 산출물과 아키텍처가 설계한 산출물, 개발자의 코드, 디자이너들의 산출물 어느 하나 공통된 것이 없습니다. 다양한 형태의 산출물간의 추적성 설정조차 어려울 지경입니다. 과연 이 모든것들을 일관된 기준으로 검사와 관리가 가능하긴 한걸까요? 소프트웨어란 도데체 무엇일까요? 저는 소프트웨어를 아래 3가지 구성요소로 정의합니다. 이 정의는 테스터로서 바라보는 소프트웨어에 대한 정의입니다. 소프트웨어란 입력값(Input) 과 출력값(Output) 그리고 데이터(Data) 로 구성된 논리적 집합체 이다. 그렇다면 우리가 충분한 테스트를 했는가는 소프트웨어에 입력해야 할 값과 출력되어 나오는 값 그리고 그 과정에 사용되는 데이터를 모두 테스트 했는가로 추적해 볼 수 있다고 생각합니다. 대부분의 설계 기법이 이 과정에 대한 논리식과 데이터 생성에 초점이 맞추어져 있습니다. 경계값 분석이나 동등분할은 입력값 또는 출력값의 데이터 검증에 초점이 맞추어져 있습니다. 결정 테이블, 원인 결과 그래프, 상태 전이, 시