카테고리 없음

[아티클] QA & UT

j-node 2026. 7. 24. 21:16

QA(만든 게 의도대로 작동하는가)UT(사용자가 실제로 어떻게 쓰는가)

1. QA 노하우 : 초보 기획자/PM을 위한 가이드

초보 기획자 혹은 PM을 위한 QA 가이드 | 요즘IT

1. 시나리오별 계정을 미리 세팅한다
 Test Case가 요구하는 조건에 맞는 계정을 미리 분류해 둔다.

예를 들어 구매 내역이 없는 구매자 / 있는 구매자 / N개 이상인 구매자, 상품이 없는 판매자 / 있는 판매자 / 구매자→판매자로 전환된 사용자처럼.

시나리오에 안 맞는 계정으로 QA하다가 "구매내역에 아무것도 안 떠요"라며 엉뚱한 버그 리포트를 남기는 사고를 막기 위함.

2. 테스트 서버와 실서버 연동 여부를 먼저 확인한다
서버가 제대로 분리되지 않으면 테스트 활동이 실서버에 영향을 줄 수 있다.

글쓴이 팀은 QA 서버에서 단 댓글이 실서버 유저에게 실제 알림으로 발송된 사례가 있었다고. → 실서버에 영향 줄 수 있는 활동이 있는지 미리 점검.

3. 랜덤 QA로 시나리오의 한계를 보완한다
Test Case는 사람이 작성하므로 "의도한 것"만 담긴다. 의도하지 않았는데 발생 가능한 케이스는 못 잡는다. 그래서 일부러 벗어나 본다: 회원가입 화면에서 뜬금없이 뒤로가기/로고 눌러보기, 아이디에 30글자·이모지·한자 넣어보기, 특정 유형의 고객이 된 것처럼 플로우 쭉 밟아보기. 

4. 의존성을 고려한 누적 QA를 한다
기획상 서로 무관해야 할 기능이 개발 중간엔 엮여 있을 수 있고(A 해야 B가 됨), 반대로 당연히 의존하는 순서를 놓칠 수도 있다. 그래서 1~30번 테스트하고 며칠 뒤 31~50번만 보는 게 아니라, 이전에 통과한 부분도 다시 포함해 누적으로 검수한다.

5. QA는 팀 전원이, 그리고 팀 밖도 참여시킨다
PM/기획자만의 일이 아니다. 개발자는 코드 너머 실제 운영을 이해하게 되고, 디자이너는 퍼블리싱·정책을 재확인하고, 요청자는 기능 반영 여부를 직접 보고, VoC/운영은 고객 문의를 미리 대비한다. 교차 확인으로 놓친 부분을 잡는 효과.

 


2. UT 진행기: 유아이볼의 첫 사용성 테스트

유아이볼 | 유아이볼의 UT, 어떻게 진행됐을까?

유아이볼(UI/UX 패턴 사이트)이 서비스 개선 인사이트를 얻기 위해 진행한 첫 UT 사례.

UT 설계 (테스트 전)

  • 목적 먼저 설정: 유아이볼은 빨리 만들어져 사용자 불편을 확인할 기회가 없었다. "UI/UX 패턴 학습 방식과 사용성 문제 파악"을 목적으로 잡음. 목적이 명확해야 태스크 설계 때 중심을 안 잃는다.
  • 테스트 대상 선정: 주요 타겟인 20~30대, 서비스 이해도 높고 자주 접속(최소 3일 1회), 패턴을 주로 쓰는 사용자. 구글폼으로 인적사항·직업·사용빈도·주 이용 콘텐츠를 물어 리크루팅.
  • 시나리오(태스크) 작성: 기능별로 태스크를 나누고, 몰입을 위해 상황을 가정해 제시. 태스크끼리 자연스럽게 이어지도록(Task1이 끝난 화면에서 Task2 시작) 흐름을 설계.
  • 사전 인터뷰 설계: 신규 기능 방향성을 위해 "이런 기능 있으면 어떨까요?"가 아니라 참가자의 연관 경험과 선호를 파고드는 질문으로 구성.
  • 그 외: 개인정보 수집·녹화 동의서, 장소/장비 세팅, 대본 작성.

UT 진행

  • 파일럿 세션(리허설): 본 테스트 전 모의 진행. 모호한 태스크, 연속 태스크로 인한 혼란을 미리 개선하고 진행 감을 익힘.
  • 진행 원칙: 힌트가 될 직접적 용어 사용 자제, 참가자 수행에 개입하지 않기. "정답 없으니 편하게" 분위기 조성. 즉석 꼬리질문에서 큰 인사이트가 나오므로 끝까지 집중.

UT 결과 분석

Task 1(카테고리 → 서비스 선택 → 북마크) 관찰에서 나온 공통 결과:

  1. 진행자가 '뉴스'라고 말하자 동일 명칭을 우선 탐색 → 해당 유형이 없어 당황, 분류에 모호함을 느낌.
  2. 원하는 유형이 안 보이면 검색으로 이동 → 검색이 서비스명만 지원한다는 걸 몰랐고, 사용자는 카테고리 검색을 기대하고 있었음.

→ 도출된 인사이트 3가지: 카테고리 분류 유형 변경, 정렬 방식 변경, 검색 기능 개선.


오늘의 인사이트, 느낀 점

  • Test Case는 "의도한 것이 의도대로 작동하는가"만 검증한다. 그래서 QA의 완성도는 오히려 의도하지 않은 것(랜덤 QA)과 누적 QA을 얼마나 챙기느냐에서 갈릴 것 같다.
  • UT의 핵심은 "말하게 하기"가 아니라 "행동을 관찰하고, 그 자리에서 왜?를 파고드는 것". 진행자가 무심코 쓴 단어('뉴스')가 참가자 행동을 유도해버리는 걸 보고, 개입을 최소화하는 게 왜 원칙인지 이해할 수 있었음.
  • 에이타니 퀴즈 개념 복습에서 주관식 open question이 공부에 진짜 도움 된다.. 능동적으로 생각해보게 됨.
  • 내부 데이터 볼 수 없음 + 공개 데이터 적은 도메인 → 과제에서 타겟 유저 설정, 가설 수립 어렵다.. 논리를 잘 짜야겠지.