테스트 케이스만 따라가다 보면 놓치는 결함들, 탐색적 테스트가 필요한 이유

AI와 자동화가 정형화된 테스트를 대체하는 시대, 사람만이 발견할 수 있는 결함은 어떻게 찾아야 할까요.

 

Pesticide Paradox와 Test Charter를 중심으로 정리했습니다.

---

같은 테스트 케이스를 반복할수록, 결함은 그 사이로 빠져나갑니다

 

테스트 케이스를 충실히 수행하는 것은 QA의 기본입니다.

 

하지만 같은 케이스를 반복해서 수행할수록 새로운 결함을 발견할 확률은 점점 낮아진다는 사실을 경험해본 분들이 많을 겁니다.

 

이미 알고 있는 길을 따라가는 테스트는, 그 길 위에 있는 결함은 한 번 잡아내면 그 다음부터는 더 이상 걸리지 않기 때문입니다.

 

이 현상을 소프트웨어 테스팅에서는 살충제 패러독스(Pesticide Paradox)라고 부릅니다.

 

같은 살충제를 계속 사용하면 해충이 내성을 갖게 되어 더 이상 효과가 없어지는 것처럼, 같은 테스트 케이스를 반복하면 그 케이스로는 더 이상 새로운 결함을 잡아낼 수 없게 된다는 의미입니다.

 

이 한계를 보완하는 방법이 바로 탐색적 테스트입니다.

 

 

AI와 자동화가 확산될수록, 오히려 사람의 역할이 명확해지는 영역

 

최근 QA 업무 환경에서는 자동화와 AI 기반 테스트 도구들이 빠르게 확산되고 있습니다.

 

정형화된 시나리오, 반복적인 회귀 테스트는 점점 더 자동화의 영역으로 넘어가는 추세입니다.

 

이런 흐름 속에서 QA 엔지니어에게 남는 질문은 명확합니다.

 

"자동화가 대체하기 어려운 영역에서, 나는 어떤 가치를 만들어낼 수 있는가."

 

탐색적 테스트는 바로 이 질문에 대한 답 중 하나입니다.

 

정해진 입력값과 예상 결과를 비교하는 작업이 아니라, "이 화면에서 사용자가 할 수 있는 예상치 못한 행동은 무엇일까"를 사람이 직접 탐색하며 발견해나가는 활동이기 때문입니다.

 

이런 맥락에서 탐색적 테스트는 단순히 "테스트 케이스를 안 쓰고 자유롭게 테스트하는 것"이 아니라, 품질을 바라보는 시야 자체를 정형화된 검증에서 리스크 중심의 사고로 넓히는 활동으로 이해하는 것이 출발점입니다.

 

 

탐색적 테스트와 Ad-hoc 테스트, 비슷해 보이지만 다른 이유

 

탐색적 테스트를 처음 접하면 "그냥 마음대로 클릭해보는 테스트"인 Ad-hoc 테스트와 혼동하기 쉽습니다.

 

실제로 둘 다 정해진 테스트 케이스 없이 진행된다는 공통점이 있습니다.

 

하지만 가장 큰 차이는 "구조화 여부"에 있습니다.

 

Ad-hoc 테스트는 별다른 계획 없이 즉흥적으로 진행되고, 그 결과 무엇을 테스트했는지, 무엇을 발견했는지가 기록으로 남기 어렵습니다.

 

반면 탐색적 테스트는 학습과 설계, 실행이 동시에 이루어지지만, 그 활동의 범위와 목표를 사전에 정의하는 Test Charter와, 활동 시간을 제한하는 Timebox라는 두 가지 장치를 통해 구조화됩니다.

 

즉, "이 화면의 결제 기능을 30분 동안, 입력값 검증과 에러 처리 관점에서 탐색한다"처럼 범위와 시간, 관점을 먼저 정해두고 시작하는 것이 탐색적 테스트입니다.

 

이렇게 하면 비정규적으로 흘러갈 수 있는 활동을, 누가 봐도 "무엇을, 왜, 얼마나" 진행했는지 설명할 수 있는 품질 활동으로 바꿀 수 있습니다.

 

Test Charter 작성해보기, 막연한 탐색을 목표가 있는 활동으로 바꾸는 법

 

탐색적 테스트를 실제로 적용해보는 가장 쉬운 방법은, 담당하고 있는 서비스의 화면 하나를 골라 짧은 Test Charter를 작성해보는 것입니다.

 

Test Charter는 거창한 문서가 아니라, 다음 세 가지를 한두 줄로 정리하는 것에서 시작합니다.

 

먼저 어떤 영역을 탐색할 것인지(대상), 어떤 관점이나 리스크에 집중할 것인지(목표), 그리고 얼마나 시간을 쓸 것인지(Timebox)를 정합니다.

 

예를 들어 회원가입 화면을 대상으로 한다면, "회원가입 화면에서 입력값의 경계값과 특수문자 처리를 중심으로 15분간 탐색한다"처럼 작성할 수 있습니다.

 

이렇게 작성된 Charter는 그 자체로 "왜 이 시간을 썼는지"에 대한 설명이 되고, 이후 발견한 내용을 정리할 때도 기준점이 됩니다.

 

직접 해보는 탐색적 테스트, 30분 Timebox로 시작하는 법

 

이론을 이해했다면, 이제 실제로 본인이 담당하는 서비스(또는 익숙한 웹·앱 서비스)의 화면 하나를 골라 30분짜리 탐색적 테스트를 직접 진행해볼 수 있습니다.

 

먼저 타이머를 30분으로 맞추고, 위에서 작성한 Test Charter를 손이 닿는 곳에 적어둡니다.

 

탐색을 시작하기 전에, 평소 테스트할 때는 잘 시도하지 않았던 행동들을 떠올려보는 것이 도움이 됩니다.

 

예를 들면 입력창에 의도적으로 매우 긴 문자열을 넣어보거나, 숫자만 입력해야 하는 필드에 문자를 입력해보거나, 필수 입력값을 비워둔 채 다음 단계로 넘어가려고 시도하는 식입니다.

 

탐색하면서는 발견한 내용을 그 자리에서 짧게 메모하는 것이 중요합니다.

 

"이상하다고 느꼈지만 일단 넘어간" 부분들은 시간이 지나면 기억에서 사라지기 쉽기 때문입니다.

 

메모는 "어떤 입력을 했을 때, 어떤 결과가 나왔는지"를 한 줄로 적는 정도면 충분합니다.

 

30분이 끝나면, 메모한 내용을 다시 살펴보면서 결함으로 이어질 수 있는 항목과, 단순히 UX 개선 아이디어로 남길 항목을 구분합니다.

 

이 과정에서 자연스럽게 우선순위가 정리되고, 결함으로 판단된 항목은 앞서 다뤘던 증거 기반 리포트 형식으로 정리해 전달할 수 있습니다.

 

실무에 적용할 때, 어떤 화면부터 시작하면 좋을까

탐색적 테스트를 실무에 적용하려면, 처음부터 전체 서비스를 대상으로 하기보다는 특정 영역을 좁게 잡는 것이 효과적입니다.

 

새로운 기능이 배포된 직후의 화면, 혹은 최근 사용자 문의나 결함이 자주 발생했던 화면은 탐색적 테스트의 대상으로 우선적으로 고려할 만합니다.

 

또한 정기적인 회귀 테스트 일정 사이에, 짧은 Timebox의 탐색적 테스트를 끼워 넣는 방식도 운영해볼 수 있습니다.

 

예를 들어 매 스프린트마다 새로 배포된 기능 하나를 골라 30분씩 탐색적 테스트를 진행하고, 그 결과를 팀과 공유하는 루틴을 만들면, 정형화된 테스트 케이스로는 잡히지 않던 결함들이 점차 누적되어 발견되는 경험을 하게 됩니다.

 

자동화가 채워주지 못하는 빈틈을 메우는 활동

 

자동화와 AI가 빠르게 발전하고 있는 지금, 오히려 "사람이 직접 탐색하며 발견하는" 활동의 가치는 더 선명해지고 있습니다.

 

정해진 입력과 예상 결과를 빠르고 정확하게 비교하는 일은 도구가 점점 더 잘하게 되겠지만, "사용자가 이렇게도 할 수 있겠다"는 가능성을 떠올리고 직접 시도해보는 일은 여전히 사람의 영역입니다.

 

탐색적 테스트를 단순히 "여유 시간에 하는 자유 테스트"가 아니라, Test Charter와 Timebox라는 구조 안에서 운영되는 품질 활동으로 자리매김시키는 것. 그 작은 변화에서부터, QA가 만들어낼 수 있는 차별점이 시작된다고 생각합니다.

 

 

테스트차터_양식_공유.xlsx

0.02MB

 

 

 

---