제가 내보낸 것 중 가장 부끄러운 버그들에는 공통점이 하나 있습니다. 테스트 스위트가 전부 초록불이었다는 것. 코드는 스펙에 적힌 그대로 동작했습니다. 그 스펙이 사람들에게 실제로 필요한 것과 어긋나 있었을 뿐이죠. UAT는 바로 이 틈 때문에 있습니다.

내 기능을 내가 테스트할 수 없는 이유

#

기능이 완성될 때쯤이면 저는 그 해피 패스를 수백 번은 밟은 상태입니다. 어떤 버튼을 눌러야 하는지 다 알죠. 그 버튼을 만든 게 저니까요. 이 익숙함 때문에 저는 최악의 테스트 사용자가 되고, QA도 절반의 해결책에 그칩니다. QA는 여전히 스펙을 기준으로 테스트하니까요. “설계대로 동작하는가?“에서 “애초에 설계가 맞았는가?“로 질문이 바뀌는 단계는 UAT 하나뿐입니다.

UAT, QA, 베타 테스트는 서로 다릅니다

#

이 셋을 섞어 쓰는 경우가 많은데, 그러다 보면 누가 뭘 해야 하는지를 두고 실제로 혼선이 생깁니다.

UAT는 그 둘 사이에 있습니다. QA에서 아직 크래시가 나오고 있다면 UAT는 이릅니다. 사용자들이 라운드 내내 버그에 걸려 넘어지느라, 정작 답을 듣고 싶었던 질문까지는 가 보지도 못합니다.

라운드를 시작하기 전에

#

계획이 먼저입니다. 범위, 일정, 참여자, 그리고 “통과"의 정의. 성공 기준이 모호하면 UAT는 몇 주씩 늘어집니다.

진입 기준도 정해 둡니다. 이름은 거창하지만 사실 짧은 체크리스트입니다. QA를 통과했고 열려 있는 치명적 버그가 없을 것. 스테이징 환경에 “test test 123” 같은 계정이 아니라 실제와 비슷한 데이터가 들어 있을 것. 참여자들이 “시간 날 때"가 아니라 이 일을 위해 시간을 따로 빼 두었을 것. 이 마지막 게 가장 중요합니다. 본업 사이사이에 끼워 넣은 UAT는 제대로 된 관심을 10분 정도밖에 못 받습니다.

그다음은 실제 사용자와 닮은 사람을 고르는 일입니다. 개발에 관여하지 않은 동료도 괜찮고, 제품이 뭘 하려는 건지 이해하는 우호적인 외부 이해관계자 몇 명이면 더 좋습니다. 대부분의 기능은 5~8명이면 충분합니다. 그 이상이면 대개 같은 피드백이 반복될 뿐입니다.

따라 할 수 있는 시나리오 쓰기

#

시나리오는 엣지 케이스가 아니라 일상 업무를 중심으로 씁니다. 엣지 케이스는 QA가 이미 두들겨 봤으니까요. 좋은 UAT 시나리오는 스트레스 테스트가 아니라 평범한 화요일처럼 읽힙니다.

시나리오마다 목표와 출발점을 주고, 단계는 일부러 빼 둡니다. “‘새 인보이스’를 누른 다음 ‘고객 추가’를 누르세요"라고 쓰면 제품이 이해가 되는지가 아니라 지시를 잘 따르는지를 테스트하게 됩니다. 인보이스 기능이라면 시나리오는 이런 식입니다.

시나리오 4: 신규 고객에게 작업 일부 금액 청구하기

신규 고객인 하버 카페의 인테리어 공사 중 전반부를 막 끝냈습니다. 합의한 $12,000 중 50%를 결제 기한 14일로 청구하고, 고객의 회계 담당 이메일로 보내세요.

기대 결과: 고객이 기한이 올바르게 적힌 $6,000짜리 인보이스를 받고, 내 대시보드에는 미결제로 표시됩니다.

이런 시나리오 10~15개면 보통 기능 하나는 커버됩니다. 저는 처음 한두 세션에 같이 앉아서 말은 최대한 아끼고, 사람들이 어디서 머뭇거리는지 지켜봅니다. 버튼 앞에서 멈칫하는 그 순간이 피드백 양식에 적힌 어떤 말보다 많은 걸 알려 줍니다.

UAT 피드백 기록하기

#

라운드 중에는 사용자의 기대와 다른 건 전부 기록합니다. 기술적으로는 “의도된 동작"인 것까지요. 누군가 A를 기대했는데 B가 나왔다면, 스펙에 뭐라고 적혀 있든 그 자체가 정보입니다.

기록에 특별한 도구는 필요 없습니다. 공유 시트 하나나, 이미 쓰고 있는 이슈 트래커에 전용 보드 하나면 충분합니다. 단, 모든 항목에 같은 필드 몇 개가 들어가야 합니다.

실제로 일을 하는 필드는 “기대한 것"입니다. 이게 없으면 “인보이스 화면이 헷갈려요” 같은, 아무도 손쓸 수 없는 피드백이 들어옵니다.

피드백 분류하기

#

매일 일과가 끝날 때, 작은 라운드라면 라운드가 끝날 때, 프로덕트 오너와 함께 기록을 훑으면서 모든 항목을 네 갈래 중 하나로 나눕니다.

버그는 뭔가 고장 난 것입니다. 합계가 틀렸다거나 에러 페이지가 뜬다거나. 심각하면 승인 전에 고치고, 아니면 일정을 잡습니다.

변경 요청은 스펙대로 동작하지만 스펙 자체가 틀렸던 경우입니다. 위에서 본 퍼센트 옵션처럼요. UAT가 찾아내려고 존재하는 피드백이 바로 이것이고, 다루기도 가장 어렵습니다. 고치려면 범위가 늘어나니까요. 결정은 프로덕트 오너가 합니다. 지금 고칠지, 아니면 받아들이고 일정에 넣을지.

문구·안내 문제는 기능은 멀쩡한데 사람들이 이해를 못 한 경우입니다. 라벨 하나, 힌트 하나, 도움말 한 줄로 해결되는 경우가 많습니다. 비용이 싸니 할 만한 일입니다.

수정 안 함(Won’t fix)은 범위 밖의 아이디어나, 다른 모두와 다른 한 사람의 취향 같은 것들입니다. 이유를 적어 두고, 제기한 사람에게 알려 주세요. 아무 답도 못 들은 테스터는 다음 라운드에서 피드백을 안 줍니다.

제가 가장 피하려고 하는 건 모든 항목을 출시 전에 고쳐야 할 버그로 취급하는 겁니다. 2주짜리 라운드가 두 달이 되는 게 바로 그렇게 해서입니다. UAT 피드백의 목표는 항목 0개가 아닙니다. 모든 항목에 결정이 붙어 있는 것입니다.

승인(사인오프)

#

끝나면 고쳐야 할 것을 고치고, 변경이 컸다면 잘 됐겠거니 넘기지 말고 짧은 라운드를 한 번 더 돌립니다. 그런 다음 처음에 합의한 기준에 따라 제대로 된 승인을 받습니다. 단톡방에 올라온 엄지척 이모지가 아니라, 정해진 담당자가 직접 “네, 출시하죠"라고 말하고, 미뤄 둔 항목 목록을 그 옆에 함께 남기는 것을 말합니다.

UAT를 돌리면서 제가 한 실수들

#

너무 늦게 돌렸습니다. 출시일이 정해져 있는데 그 이틀 전에 UAT를 시작하면, 모든 변경 요청이 출시를 미룰지 말지를 두고 벌이는 논쟁이 되고, 답은 늘 “아니요"입니다. 찾아낸 것에 대응할 여유를 남겨 두세요.

엉뚱한 사람들과 테스트했습니다. 제품을 너무 잘 아는 내부 직원은 개발자와 똑같이 행동합니다. 뭐가 어디 있는지 다 알거든요.

침묵을 승인으로 받아들였습니다. 테스터가 아무것도 기록하지 않았다면, 아마 제대로 테스트하지 않은 겁니다. 통과로 치기 전에 한번 확인해 보세요.

그리고 UAT가 스프린트 끝의 체크박스가 되도록 내버려 뒀습니다. 마지막 관문으로 대하는 편이 낫습니다. 출시 전에 내가 아닌 누군가가 이걸 써 보는 마지막 순간이니까요.

이걸로 얻는 것

#

가장 큰 건 문제가 아직 쌀 때 잡힌다는 점입니다. 출시 후 패치와 사과문이 아니라 출시 전에요. 조용한 이점도 있습니다. 플로우가 사람들이 실제로 일하는 방식과 맞으니 교육과 지원이 수월해집니다. 그리고 테스트에 참여한 이해관계자는 승인도 빠릅니다. 그 시점엔 절반쯤 자기 제품이 되어 있으니까요. 제가 본 릴리스 중 UAT를 제대로 거친 것들은 대체로 조용히 지나갔습니다.

정리하면

#

UAT는 출시 전에 실제 사용자가, 소프트웨어가 자기에게 필요한 일을 해 주는지 확인하는 단계입니다. QA가 깨끗해진 다음에 시작하세요. 사용자와 닮은 사람 5~8명을 부르고, 시나리오는 단계가 아니라 일상적인 목표로 쓰고, 기대한 것과 실제로 일어난 일 사이의 간극을 빠짐없이 기록하세요. 피드백 하나하나를 버그, 변경 요청, 문구 문제, 수정 안 함으로 나누고, 모든 항목에 결정을 내린 뒤, 담당자가 분명한 승인으로 마무리하세요.