제가 지금까지 내보낸 것 중 가장 부끄러운 버그들에는 공통점이 있습니다. 테스트 스위트가 전부 초록불이었다는 것. 코드는 스펙대로 정확히 동작했고, 문제는 그 스펙이 사용자에게 실제로 필요한 것과 어긋나 있었다는 거죠. 사용자 인수 테스트(UAT)는 바로 이 틈을 메우기 위해 존재합니다. 출시 전에 실제 사용자가 소프트웨어를 직접 써 보면서, 유닛 테스트와 QA가 답할 수 없는 질문에 답하는 단계입니다. 이게 정말 쓸 사람들에게 제대로 동작하는가?
내 기능을 내가 테스트할 수 없는 이유#
기능이 완성될 때쯤이면 저는 그 해피 패스를 수백 번은 밟은 상태입니다. 어떤 버튼을 눌러야 하는지 다 알죠. 그 버튼을 만든 게 저니까요. 이 익숙함 때문에 개발자는 최악의 테스트 사용자가 됩니다. QA도 절반의 해결책일 뿐입니다. QA는 어디까지나 스펙을 기준으로 테스트하니까요. “설계대로 동작하는가?“에서 “애초에 설계가 맞았는가?“로 질문이 바뀌는 건 UAT뿐입니다.
한 라운드를 실제로 돌리는 법#
계획이 먼저입니다. 범위, 일정, 참여자, 그리고 “통과"의 정의. 성공 기준이 모호하면 UAT는 몇 주씩 늘어집니다.
다음은 실제 사용자와 닮은 사람을 고르는 일입니다. 개발에 관여하지 않은 동료도 좋고, 제품의 목적을 이해하는 우호적인 외부 이해관계자 몇 명이라면 더 좋습니다. 시나리오는 엣지 케이스가 아니라 일상 업무를 중심으로 씁니다. 엣지 케이스는 QA가 이미 두들겨 봤을 테니까요. 좋은 UAT 시나리오는 스트레스 테스트가 아니라 평범한 화요일처럼 읽힙니다.
라운드 중에는 참여자가 시나리오를 따라 진행하고, 기대와 다른 것은 전부 결함으로 기록합니다. 기술적으로는 “의도된 동작"이라도요. 끝나면 피드백을 모아 고치고, 변경이 컸다면 잘 됐겠거니 넘기지 말고 한 라운드 더 돌립니다. 마지막으로 처음에 합의한 기준에 따라 정식 승인을 받습니다.
이걸로 얻는 것#
가장 큰 건 문제가 아직 쌀 때 잡힌다는 점입니다. 출시 후 패치와 사과문이 아니라 출시 전에요. 조용한 이점도 있습니다. 플로우가 사람들이 실제 일하는 방식과 맞아서 교육과 지원이 수월해지고, 테스트에 참여한 이해관계자는 승인도 빠릅니다. 그 시점엔 이미 절반쯤 자기 제품이 되어 있거든요.
회사에서도 UAT를 제대로 돌린 릴리스일수록 조용히 지나간다는 느낌을 받습니다. UAT를 스프린트 끝의 체크박스로 취급하고 싶어지지만, 마지막 관문으로 대하는 편이 낫습니다. 출시 전에 내가 아닌 누군가가 이 기능을 써 보는 마지막 기회니까요.