테스트 케이스를 다 돌렸는데도, 왜 버그는 남을까? 🤔

테스트 케이스를 모두 수행했는데도 릴리즈 이후 새로운 버그가 발견되는 경우, 의외로 흔합니다.

QA를 하다 보면 이런 말도 자주 듣게 되죠.

 

“테스트 다 했잖아요. 근데 왜 이런 버그가 나왔죠?”

이 질문이 나오는 이유는 명확합니다.

테스트 케이스는 결국 ‘예상한 시나리오’만 검증하기 때문입니다.

문제는 사용자가 우리가 생각한 대로만 움직여주지 않는다는 점이죠 😅 버튼을 다른 순서로 누르고, 중간에 화면을 나갔다 들어오고, 개발자가 의도하지 않은 타이밍에 입력을 합니다.

이렇게 문서 밖에서 벌어지는 행동들은 테스트 케이스만으로는 잡기 어렵습니다.

그래서 필요한 것이 탐색적 테스팅(Exploratory Testing)입니다.

 

 

 

탐색적 테스팅(Exploratory Testing)

탐색적 테스팅은 테스트 케이스를 미리 촘촘하게 정의해두고 그대로 실행하는 방식이 아닙니다. 오히려 테스트를 하면서 시스템을 이해하고, 그 이해를 바탕으로 다음 테스트를 계속 확장해 나갑니다. 테스트를 하다 보니

“어? 이 상태에서 이 버튼을 누르면 어떻게 되지?” “여기서 화면을 나갔다 들어오면 상태가 유지될까?”

같은 생각이 자연스럽게 떠오르고, 그 생각 자체가 다음 테스트가 됩니다. 즉, 테스트 중에 얻은 정보가 곧 다음 테스트의 입력이 되는 것​​. 설계와 실행, 사고가 동시에 일어나는 테스트 방식이라고 보면 됩니다 🧠

​

물론 탐색적 테스팅이 아무 목적 없이 막 해보는 테스트는 아닙니다. 보통은 테스트를 시작하기 전에

짧고 명확한 테스트 미션(Charter)을 정해둡니다. 이번 세션에서는 어떤 기능 흐름을 볼 것인지, 어디에 리스크가 있다고 보는지, 어떤 부분을 중점적으로 확인할 것인지 정도만 정리합니다.

​

그리고 정해진 시간 동안 하나의 미션에 집중해 실제 사용자처럼 시스템을 직접 사용하며 테스트를 진행합니다.

이 과정에서 중요한 건 성공/실패 체크보다도 관찰입니다 👀 사용 흐름이 어색하지는 않은지, 화면을 이동했을 때 상태가 꼬이지는 않는지, 예외 상황에서 시스템이 너무 무책임하게 멈추지는 않는지 말이죠. 조금이라도 이상하다고 느껴지면 그 자리에서 바로 다른 입력과 경로로 다시 확인합니다. “아마 괜찮겠지” 하고 넘기지 않는 게 포인트입니다.

​

이렇게 탐색을 하다 보면 결함뿐만 아니라 여러 가지 정보가 함께 쌓입니다. 재현 가능한 버그 🐞, 당장은 문제 없어 보여도 불안한 지점, 다음에 꼭 다시 확인해봐야겠다는 영역, 그리고 테스트 중 떠오른 새로운 가설들까지 💡이 기록들은 단순한 메모가 아니라, 다음 테스트 세션의 방향을 정해주는 지도가 됩니다. 그래서 탐색적 테스팅은 한 번 하고 끝나는 테스트가 아니라 세션을 거듭할수록 더 똑똑해지는 테스트가 됩니다 📚

 

특히 사용자 행동이 다양하고, UX나 화면 흐름이 중요한 서비스 기능 간 의존성이 높은 화면 구조에서는

탐색적 테스팅의 효과가 더욱 분명하게 드러납니다 ✨ 테스트 케이스는 충분한데 비슷한 결함이 계속 반복된다거나, 릴리즈 후 CS에서 예상치 못한 이슈가 자주 나온다면 한 번쯤은 이 질문을 해볼 필요가 있습니다.

​

​

우리는 정말 사용자의 움직임을 테스트하고 있을까?

​

​

마지막으로 하나만 기억하면 좋겠습니다. 탐색적 테스팅은 테스트 케이스를 대체하기 위한 방법이 아닙니다.

정형 테스트로는 닿지 못하는 영역을 사람의 관찰과 사고로 메워주는 방식입니다. 모든 결함은 문서에 적혀 있지 않습니다.사용자가 실제로 움직일 때, 비로소 드러나는 문제들이 있습니다.

탐색적 테스팅은 그 마지막 빈틈을 메우는 테스트입니다.

​

​