테스팅(Testing)과 체킹(Checking)

근래 +Draco Kim 님의 고객님 고객님 시리즈만 연속으로 올리다보니..

블로그가 너무 무미건조해지고.. 명색이 SW 테스팅 전문 블로그라는데 테스팅 관련 글은 1년에 몇차례 가뭄에 물방울 떨어지는 듯 하여..

오랜만에 테스팅 관련 글 한편 올려보고자 합니다.

오늘의 주제는 여러분은 테스팅과 체킹을 구분하실 수 있습니까?

여러분은 체킹을 하고 계십니까? 테스팅을 하고 계십니까?

일반적으로 우리가 테스팅이라 하면 명세를 기반으로 제품을 실행해보고 명세와 제품이 일치하지 않는다면 결함이라 판단하고 결함보고서를 쓰는 일련의 행위를 말합니다.

그런데, 이게 전부일까요?

단순히 어떤 정의된 명세가 있고 그 명세에 따라 제품이 정상적으로 동작하는지 여부를 확인하는 것이라면 TDD와 같이 코드 단위에서부터 테스트를 수행할 수도 있고, 수많은 자동화 도구를 통해서도 확인해볼 수 있습니다.

명세에 따라 제품을 실행해보고 명세 준수 여부를 확인하는 것도 분명 테스트이긴 합니다. 하지만 이것은 아주 좁은 의미의 테스트입니다.

사실 이것은 테스트라기보다는 체킹에 좀 더 가깝다고 할 수 있습니다.

사람이 직접 제품을 사용하면서 제품의 정상동작 여부를 판단하는 행위에는 단순히 명세를 참고하는 행위 이상의 행위가 있습니다.

우선 제품이 어떻게 동작하는지에 대하여 추론을 할 것이고, 그러한 추론에는 테스터의 경험과 선입관 그리고 감정이 섞이게 됩니다.

그런데, 이러한 추론, 선입관, 감정 등에는 여러가지 문제가 있습니다.

가장 큰 문제는 테스트의 신뢰성을 저하시킨다는 점입니다.

실제로 우리가 테스트를 수행하면서 발견하는 결함에는 테스트 케이스(즉, 명세로 정의된 내용)로는 확인할 수 없는 여러 다른 유형의 결함도 있습니다.

문제는 이러한 결함은 결함이 아닌 논란의 소지가 있는 이슈로 취급된다는 것이고, 이러한 논란은 많은 경우 이해관계자간의 감정의 골을 깊게 하거나 제품의 품질을 개선하는데는 아무 도움도 되지 않는 단순한 감정의 분출로 인한 자원 낭비를 가져오는 경우가 많다는 것입니다.

테스트에 있어 가장 중요한 것은 무엇일까요?

저는 개인적으로 테스트 오라클, 즉 결함 여부를 판단할 기준, 고객이 원하는 품질 수준이라고 봅니다.

명세는 아주 좋은 테스트 오라클입니다.

그리고 우선 눈에 보이기 때문에 모두가 선호하는 테스트 오라클입니다.

하지만 단순히 명세만을 가지고 제품의 정상 동작 여부를 판단하기는 부족합니다. 명세만을 가지고 제품의 정상 동작 여부만 확인하는 것은 테스팅이라기보다는 체킹에 가깝다고 봅니다.

우리가 진정 테스팅을 한다고 말하기 위해서는 저는 테스터는 테스트 오라클의 수집과 분석 정의에 좀 더 많은 노력을 기울여야 한다고 봅니다.

단순히 자신의 경험, 선입관, 감정을 이입시켜 제품을 테스트 하는 것이 아니라 논리적인 검증과 고객이나 이해관계자의 암묵적인 요구사항을 충분히 반영하여 제품을 올바르게 테스트하는 것이 중요하다고 봅니다.

단순히 누군가가 작성한 테스트 케이스만을 열심히 수행하거나 명세만 가지고 제품을 체킹하는 것이 아니라 테스트를 수행하는 테스터가 되기 위해 많이 고민하는 사람들이 많아졌으면 하는 마음입니다.