특강) QA&UT + 오늘의 Q&A

QA&UT란?

QA는 배포 전 내부 검증, UT는 배포 후 실사용자 대상 사용성 검증이다.

시점과 목적이 다르므로 혼용하면 안 된다.

MVP 단계 QA 기준은 완벽한 품질이 아니라 핵심 가치까지 막히지 않는 상태이고,

UT는 사용자가 '좋아하는지'가 아니라 '스스로 완료하는지'를 관찰하는 것이다.

[게시글 목차]

Part 1. QA(Quality Assurance / 품질보증)
1. QA란 무엇인가 / 하는 이유
2. QA는 기획 단계부터 준비(5요소)
3. QA 진행에 필요한 것(범·일·환·역·도·결)
4. CL(체크리스트) vs TC(테스트케이스)
5. TC 작성 순서 및 Depth / MECE
6. 이슈 리포트 작성법
7. QA의 한계와 랜덤 QA

Part 2. UT(Usability Test / 사용성 테스트)
8. UT vs 인터뷰 (특강에서 가장 강조된 구분)
9. UT 진행 프로세스(5단계)
10. 진행자 vs 관찰자
11. Task 유형
12. 결과 분석과 개선안 도출

오늘의 Q&A
Q1. QA 대상 기능의 사이드이펙트 범위는 어떻게 알고, 그 범위 전체를 검수해야 하는지
Q2. QA는 배포 전 내부 검증, UT는 배포 직후 실사용자 사용성 검증이라는 이해가 맞는지
Q3. UT·인터뷰 중 답변에 따라 질문을 추가해도 되는지(정량화 우려로 수정 대신 추가만이라도)
Q4. 인터뷰이 특성·배경에 따른 결과 치우침, 모수가 적을 때 밸런스 맞추는 법
Q5. UT 중 전혀 의도치 않은 행동을 했을 때, 멈추고 이유를 물어야 하는지
Q6. UT 결과가 기획 가설을 정면으로 부정할 때 넥스트 스텝

 

+) 오늘의 인사이트 / KPT 회고

 

---

 

Part 1. QA(Quality Assurance / 품질보증)

 

 

1. QA란 무엇인가 / 하는 이유

구분	내용
정의	품질 보증(Quality Assurance), 제품이 의도한 대로 작동하는지 확인하는 프로세스
확인 범위	브라우저·디바이스별 오류 / 이미지 미노출·맞춤법 / 기능 오류 / 데이터 처리 오류
MVP QA 기준	완벽한 제품이 아니라, 사용자가 핵심 가치를 경험하기 전까지 막히지 않는 상태
필요한 이유	제품이 의도대로 만들어져야 가설 검증·KPI 달성 여부 판단 가능. 안 그러면 이탈 원인이 기능 오류인지 가설 실패인지 구분 불가
PM 업무 흐름	문제 해결 → 제품 구현 → QA(선택) → 검증(MVP 검증 / KPI 달성 / 가설 검증)
담당 주체	회사 규모·QA 담당자 유무에 따라 다름. 스타트업·신사업 조직은 PM이 직접 담당하는 경우 많음

 

2. QA는 기획 단계부터 준비(5요소)

기능 목적	사용 시나리오	예외 조건	성공 기준	권한·데이터
무엇을 검증할지	어떤 순서로 행동하는지	오류·빈값·중복 입력	Pass/Fail 판단 기준	사용자 유형별 차이

 

🔹예시(회원가입 예외 조건)

 

예외 조건	▶	이미 가입된 이메일 입력	비밀번호 미입력	약관 미동의
기대 결과		이미 가입된 계정임을 안내	필수 입력 메시지 노출	가입 불가 + 약관 동의 안내

 

3. QA 진행에 필요한 것(범·일·환·역·도·결)

범위	일정	환경	역할	도구	결과
무엇을 테스트할지	언제 진행할지	어떤 URL·계정· 브라우저 (환경마다 결과값 달라질 수 있음)	누가 고치고 누가 확인할지	어디에 기록할지	결과를 어디에 남기고 어떻게 닫을지

 

4. CL(체크리스트) vs TC(테스트케이스)

구분	CL(체크리스트)	TC(테스트케이스)
성격	빠른 누락 방지 도구	재현 가능한 검증 문서
기록 방식	항목별 Pass/Fail만	사전조건·입력값·실행절차·예상결과·실제결과·상태 (우선순위 포함)
작성 난이도	쉬움, 빠름	CL보다 꼼꼼하고 시간 소요
강사 권장	MVP 단계는 CL만으로 충분한 경우 많음	최종 프로젝트에서는 CL+TC 병행 또는 TC 필수 권장
특징	제품을 아는 사람 대상	제품을 모르는 사람도 동일하게 수행 가능하게 설계

 

5. TC 작성 순서 및 Depth / MECE

1	▶	2	▶	3	▶	4	▶	5
기능 범위 정의		상하위 계층 (Depth) 구조화		MECE 점검		기대 결과 작성		실제 결과·상태 기록

 

🔹Depth 예시(회원가입)

 

Depth1	Depth2	Depth3
회원가입	이메일 회원가입	-
회원가입	간편 회원가입	카카오 / 네이버 / 페이스북

🔹MECE 점검 질문

항목	확인 내용
중복 없이	동일 조건을 두 TC에서 반복 검수하고 있지 않은가
누락 없이	사용자가 선택 가능한 경로가 빠지지 않았는가
구분	정상 케이스와 예외 케이스가 구분되어 있는가
명확성	말단 항목마다 기대 결과가 명확히 작성되어 있는가

6. 이슈 리포트 작성법

구분	예시
나쁜 예	'저장이 안 돼요' → 위치·환경·재현 경로·기대 결과 없음, 원인 파악 불가
좋은 예	마이페이지 > 닉네임 수정 / 로그인 → 닉네임 변경 → 저장 → 새로고침 / 기대 : 변경된 닉네임 유지 / 실제 : 기존 닉네임 복귀 / 환경 : iPhone·Safari, 영상 첨부
※ 포함 항목 : 이슈 제목·발생 위치·재현 단계·기대·실제 결과·스크린샷 또는 녹화 + 테스트 일정·수행자·환경(OS/브라우저/기기)·URL 또는 계정·담당자와 처리 상태.

 

7. QA의 한계와 랜덤 QA

구분	내용
QA로 확인 가능	의도한 대로 구현됐는지, 정해진 절차대로 했을 때 결과가 맞는지
QA로 놓칠 수 있음	예상 못한 순서의 행동, 문구 안 읽고 조작, 뒤로가기·새로고침 반복
랜덤 QA 방식	다른 요소 눌러보기 / 틀린 값(30자·이모지·특수문자) 넣기 / 순서 바꿔보기 / 고객 역할극 / 탐색적 테스트(반복 클릭·새로고침)

 

 

---

 

Part 2. UT(Usability Test / 사용성 테스트)

 

 

8. UT vs 인터뷰 (특강에서 가장 강조된 구분)

구분	UT	인터뷰
목적	과업을 주고 실제 행동 관찰	생각·경험·의견을 언어로 묻기
주요 데이터	클릭, 망설임, 실패 지점, 완료 여부	사용자의 말과 설명
질문 예시	'원하는 상품을 찾아 구매 직전까지 진행해보세요'	'이 기능은 언제 사용하시나요?'
실무 팁	UT 진행 중엔 사용성 질문만, 인터뷰성 질문은 과업 종료 후에	-

 

9. UT 진행 프로세스(5단계)

순서	단계	내용
1	목표 정의	확인할 문제, 예상 막힘 지점, 관찰 항목, 성공·실패 기준
2	Task 설계	참가자 상황 + 제품 맥락 + 달성 목표 문장 구조
3	리크루팅	목표를 가장 잘 보여줄 참가자 섭외, 환경(공간·녹화·동의) 준비
4	테스트 진행	시나리오 제시 후 행동 관찰, 중립 질문
5	결과 분석	문제 공유, 반복 이슈 정리, 개선안 도출

 

10. 진행자 vs 관찰자

방식	특징
1인 진행	준비 단순하지만 질문·관찰·기록 동시 수행이라 놓치기 쉬움. 화면 녹화·타임스탬프 메모 필수
2인 진행(권장)	진행자 : 안내·과제 제시·중립 유지 / 관찰자 : 클릭·망설임·발화·비언어적 반응 기록. 최소 2~3명 권장

 

11. Task 유형

유형	정의	사용 상황
시나리오 Task	캐릭터·상황·목표 포함 미니 이야기	실제 사용 맥락, 자연스러운 흐름 확인
직접 Task	무엇을 해야 하는지 직접 지시	특정 기능 성공·실패 빠르게 확인
열린 Task	최소 정보만 주고 탐색 자유도 높임	어디를 먼저 보는지, 무엇에 끌리는지 확인
닫힌 Task	하나의 정답·명확한 완료 기준	성공률·소요시간·오류 빈도 비교
※ Task 문장 구조 : 참가자 상황 + 제품 맥락 + 달성 목표 (ex. '토요일 저녁 식사를 준비해야 한다. 집에 있는 재료로 만들 수 있는 요리를 찾아보라.') → 표현 원칙 : 답을 유도하는 단서 배제 / 현실적이되 애매하지 않게 / 필요한 디테일은 충분히. 리크루팅이 극히 어려운 도메인(특강 ex. 성병 관련 서비스)은 가정 시나리오형 Task로 대체 가능.

 

12. 결과 분석과 개선안 도출

단계	내용
관찰 공유	테스트 직후 바로 팀원과 공유(당일 공유가 중요, 미묘한 차이는 빨리 잊힘)
행동/의견 분리	참가자의 무의식적 행동과 종료 후 언어화된 의견을 분리해서 봄. 우선순위는 행동 증거 기준
반복 이슈 묶기	여러 참가자에게 반복된 막힘 지점을 묶어 우선순위화. 강사 권장 인원 : 최소 3명(가능하면 5명 이상)
ex. 참가자 다수가 CTA 지나침 → 버튼 가시성 부족(해석) → 문구·위치 조정(개선안)

 

 

---

 

오늘의 Q&A

 

 

Q1. QA 대상 기능의 사이드이펙트 범위는 어떻게 알고, 그 범위 전체를 검수해야 하는지

• 특정 기능만 개선했다면 그 기능만 테스트.
• 제로투원으로 전체 서비스를 만들었다면 이후 플로우까지 넓게 볼 수도 있음.
• 범위는 케이스마다 다르며, 새 기능이라고 무조건 전체를 다 테스트하는 건 아님.
• 연계가 강하면 넓게, 현실적으로 어려우면 해당 기능만 — 이 판단은 PM/QA 담당자의 영역
  (강사도 스타트업 시절 속도를 위해 만든 기능 단위로만 QA).
• 참고로 백엔드 로직 변경 시엔 범위를 더 넓게 잡아야 한다는 보완 의견도 있었음

Q2. QA는 배포 전 내부 검증, UT는 배포 직후 실사용자 사용성 검증이라는 이해가 맞는지

• 정확히 맞음.
• QA는 MVP 테스트 전 단계에서 제품이 잘 작동하는지 확인,
  UT는 개발·릴리즈 이후 사용자가 플로우를 잘 따라가는지 확인 — 시점 자체가 다름

Q3. UT·인터뷰 중 답변에 따라 질문을 추가해도 되는지(정량화 우려로 수정 대신 추가만이라도)

• 꼬리 질문(후속 질문)은 적극 권장 — 더 원하는 인사이트를 얻을 수 있음.
• 반응이 안 좋으면 질문을 뺄 수도, 필요하면 추가할 수도 있음.
• 참고로 질문이 많으면 Task 종료마다 묻고, 질문이 적으면(2~3개)
  전체 진행 후 몰아서 묻는 게 집중도 저하를 줄이는 데 유리

Q4. 인터뷰이 특성·배경에 따른 결과 치우침, 모수가 적을 때 밸런스 맞추는 법

• 모수가 적을수록 억지로 다양성을 확보하기보다,
  타겟 페르소나와 최대한 유사한 특성·배경의 참가자로 좁혀서 리크루팅.
  ex. (성병 서비스)에서는 실제 경험자 대신 페르소나와 동일한 인구통계(20~30대 여성)로만 진행

Q5. UT 중 전혀 의도치 않은 행동을 했을 때, 멈추고 이유를 물어야 하는지

• 즉시 멈추기보다 행동이 자연스럽게 멈추는 시점을 기다렸다가 '왜 그렇게 행동했는지' 질문.
• 대개 사용자가 오해 지점을 스스로 설명해 줌.
  다만 다수가 설계한 흐름 자체에 실패하는 심각한 오류라면 중단 후 개선 → 재진행도 가능

Q6. UT 결과가 기획 가설을 정면으로 부정할 때 넥스트 스텝

• 무엇이 부정됐는지에 따라 갈림 : 문제 정의 자체가 틀렸다면 피봇(나쁜 게 아니라 포트폴리오·면접에 좋은 경험).
• 문제 정의는 맞고 솔루션만 틀렸다면 솔루션만 재기획.
• 결과가 긍정적이면 고치는 게 아니라 기존 기능을 강화하는 방향으로 다음 단계 설정

 

---

 

오늘의 인사이트

 

QA와 UT를 실행하는 목적과 방식 자체가 달랐다는 점이 새로웠다.

막연하게 비슷한 거 아닌가...? 싶었는데

특강 전에는 UT 하면서 겸사겸사 QA도 하면 되는 거 아닌가?라는 생각도 했었다.

(뭘 몰라서 그랬으니 함 봐주자)

그 모호함이 이번 특강으로 명료하게 나뉘었다...!

 

항상 특강 때마다 질문 달라고 하시는데...

일단 GO 해보고 어라? 싶으면 그때 찾아보는 성격이라ㅋㅋㅋㅋㅋㅋ

(좀 똥인지 된장인지 굳이 굳이 찍어먹어 보고 몸이 고생해야 기억하는 타입)

당시에는 딱히 없어서 멈칫하게 된다.

그때 생기는 어색한 침묵이 날 괴롭게 해...

하지만 짜내도 질문이 안 나오는걸요.

쥐어짜 내서 뭐라도 물어볼라치면

당연한 답변 or 케바케라는 답변이 나올만한 내용밖에 없어서 곤란하다.

(내면에서 벌어지는 질문과 자체 답변으로 종결됨

그리고 사전 질문을 준비해도 특강 들으면 대체로 궁금증이 해결됨)

 

암튼 그런 관계로 강의 중에는 시끄러운 편인데

(그래도 강의 흐름에 방해 안 되도록 나름 자중하는 편이랍니다..허허)

막상 질문하라면 조용하니까 얘 뭐지...? 싶으실 수도.

원래 그런 앤갑다 해주십쇼.

 

 

---

 

오늘의 KPT 회고

 

Keep	• QA와 UT의 목적·방식 차이를 특강을 통해 명확히 구분 지음 • 모르는 부분은 일단 진행해보고 막히는 지점에서 찾아보는 실행 중심 학습 방식 유지
Problem	• 질문을 억지로 짜내도 당연한 답변·케바케 답변에 그칠 것 같아 질문 설계 자체가 막힘 • 특강 전까지 QA와 UT를 겸사겸사 병행 가능한 것으로 오해하고 있었음
Try	• 질문 준비 시 '당연한 답'이 나오는 원론 질문 대신, 실무 엣지케이스·케바케 상황 중심으로 질문 설계 • MVP 프로젝트에서 QA(CL·TC 중 선택)와 UT를 시점 구분해서 실제로 적용하는 계획 수립