목표
✅ MVP 프로젝트 진행
🌟 목표 달성률 : 100%
특강
QA & UT 특강
튜터님 : 김단비 튜터님
Part 1. QA (Quality Assurance)
QA란?
제품이 기획 의도대로 작동하는지 배포 전에 확인하는 품질 보증 과정. 브라우저/디바이스별 오류, 이미지 미노출, 맞춤법, 기능 오류, 데이터 처리 오류 등을 점검한다.
MVP 기준에서 QA의 목표는 "완벽한 제품"이 아니라, 사용자가 핵심 가치를 경험하기 전까지 막히지 않는 상태를 만드는 것.
QA를 하는 이유
제품이 제대로 만들어지지 않으면 가설 검증 자체가 불가능하다.
- 비즈니스 목표 달성 여부를 판단할 수 없음
- 사용자 이탈이 기능 오류 때문인지 가설 실패 때문인지 구분이 안 됨
- MVP 검증 결과가 왜곡됨
→ QA는 검증 전 단계에서 "제품이 의도대로 만들어졌는가"를 확인하는 작업
PM과 QA의 관계
회사 규모에 따라 다르다. QA 전담팀이 있으면 PM은 참여 수준에 그치지만, 스타트업처럼 규모가 작을수록 PM이 직접 QA를 담당하는 경우가 많다. 어떤 조직에 속하든 대응할 수 있도록 알아두는 게 좋다.
QA는 기획 단계부터 준비
기획할 때부터 "이 기능의 결과값이 뭔지"를 생각하면서 설계하면 나중에 QA 리스트 작성이 훨씬 수월해진다.
기획 단계에서 고려할 것:
- 기능 목적: 무엇을 검증할지
- 사용 시나리오: 어떤 순서로 행동하는지
- 예외 조건: 오류, 빈 값, 중복 입력 시 처리
- 성공 기준: Pass/Fail 판단 기준
- 권한/데이터: 사용자 유형별 차이
CL (Checklist)
빠르게 누락을 방지하는 도구. Pass/Fail로 간단하게 확인.
MVP에서는 TC까지 작성하기 어려우니 CL 위주로 작성하는 걸 권장.
우선순위 높은 핵심 기능부터 리스트화해서 체크한다.
CL 작성 순서:
1. 기능별 우선순위 판단 (높음/중간/낮음)
2. 우선순위 높은 기능 위주로 항목 작성
3. 기능 케이스 + 예외 케이스 함께 포함
TC (Test Case)
제품을 잘 모르는 사람도 같은 방식으로 테스트할 수 있도록 재현 가능하게 작성하는 문서. CL보다 훨씬 정밀하고, 보통 최종 프로젝트 수준에서 작성.
TC에 포함할 항목:
- 사전 조건 / 입력값 / 실행 절차 / 기대 결과 / 실제 결과 / 상태(Pass/Fail)
TC 작성 기준:
- 기능을 Depth별로 계층 분해 (기능 → 방식 → 세부 채널)
- MECE 원칙 적용: 중복 없이, 누락 없이
예외 상황도 반드시 체크
| 예외 상황 | 확인할 것 |
|---|---|
| 필수값 미입력 | 사용자가 이해할 수 있는 안내 메시지가 나오는가 |
| 잘못된 형식 | 이메일·날짜·숫자 형식 오류를 알려주는가 |
| 중복 데이터 | 이미 등록된 계정·항목임을 알려주는가 |
| 결과 없음 | 빈 화면이 아니라 다음 행동을 안내하는가 |
| 권한 없음 | 로그인·소유자·관리자 권한을 구분하는가 |
| 네트워크 오류 | 실패 상태와 재시도 방법을 안내하는가 |
좋은 이슈 리포트
❌ "저장이 안 돼요."
✅ 마이페이지 > 닉네임 수정 / 로그인 → 닉네임 변경 → 저장 → 새로고침 / 기대: 변경된 닉네임 유지 / 실제: 기존 닉네임으로 돌아감 / 환경: iPhone/Safari
이슈 리포트에 필요한 것: 발생 위치 + 재현 단계 + 기대 결과 + 실제 결과 + 환경(기기/브라우저/OS) + 스크린샷 또는 화면 녹화
랜덤 QA (탐색적 테스트)
정해진 TC/CL 외에 예상 밖의 행동을 직접 시도해보는 방식.
뒤로가기, 반복 클릭, 이모지/특수문자 입력, 순서 바꾸기 등 실제 사용자가 할 법한 돌발 행동들을 직접 해보는 것.
Part 2. UT (Usability Test)
UT란?
사용자에게 과업을 주고 실제 행동을 관찰하는 테스트. "좋아하는지" 묻는 시간이 아니라 "스스로 완료하는지" 보는 시간.
UT vs 인터뷰
| 인터뷰 | UT | |
|---|---|---|
| 목적 | 생각·경험·의견 수집 | 실제 행동 관찰 |
| 주요 데이터 | 사용자의 말 | 클릭, 망설임, 실패 지점, 완료 여부 |
| 예시 질문 | "이 기능은 언제 사용하시나요?" | "원하는 상품을 찾아보세요." |
UT 진행 프로세스
목표 정의 → Task 설계 → 리크루팅 → 테스트 진행 → 결과 분석
Step 1. 목표 정의
- 어디서 막힐 것 같은지 예상되는 지점
- 관찰하고 싶은 행동
- 성공/실패 판단 기준
Step 2. Task 설계
Task 문장 구조: 참가자의 상황 + 제품에 들어온 맥락 + 달성해야 할 목표
예: "토요일 저녁 식사를 준비해야 합니다. 집에 있는 재료만으로 만들 수 있는 요리를 찾아보세요."
좋은 Task vs 나쁜 Task:
❌ "검색창에 키워드를 입력해보세요" → 정답을 리딩하는 Task
✅ "마음에 드는 상품을 찾아 구매 직전까지 진행해주세요" → 목표만 제시하는 Task
기능명, 버튼명을 알려주는 건 절대 금지. 유도하지 않는 것이 핵심.
Task 유형:
| 유형 | 정의 | 언제 쓰면 좋은가 |
|---|---|---|
| 시나리오 Task | 상황·목표를 포함한 미니 스토리 | 실제 사용 흐름 전체를 보고 싶을 때, 타겟 유저 섭외가 어려울 때 |
| 직접 Task | 무엇을 해야 하는지 직접 지시 | 특정 기능의 성공/실패를 빠르게 확인할 때 |
| 열린 Task | 최소 정보만 주고 탐색 자유도를 높임 | 어디를 먼저 보고 무엇에 끌리는지 알고 싶을 때 |
| 닫힌 Task | 명확한 완료 기준이 있는 과업 | 성공률, 소요 시간, 오류 빈도를 비교할 때 |
Step 3. 리크루팅
타겟군에 맞는 사람을 선별하는 것이 중요. 사전 설문을 통해 걸러내는 방법 추천.
MVP는 1~2명도 OK, 최종 프로젝트는 3~5명 권장.
Step 4. 테스트 진행
역할 분리:
- 진행자: 과업 제시, 흐름 관리. 사용자가 막혀도 절대 힌트 주지 않기
- 관찰자: 클릭, 망설임, 비언어적 반응 기록 (고개 갸우뚱, 특정 화면에서 5초 이상 머무름, 눈빛 변화 등)
1인 진행 시: 화면 녹화 + 타임스탬프 메모 필수. 후속 질문은 과제 종료 후에.
Step 5. 결과 분석
- UT 결과만으로 개선안 도출 금지 → 기존 정량/정성 데이터와 종합해서 판단
- 행동 증거(실제로 한 것)와 의견(나중에 말한 것)을 반드시 분리
- 여러 참가자에게 반복된 막힘 지점을 묶어서 우선순위화
MVP 프로젝트
진행 상황
- PRD 다듬기 ✅
- 기능 명세서 작성 ✅
참여 - 튜터님 인터뷰 ✅
참여 - 문제 콘텐츠 제작 ✅
- 와이어 프레임 제작 ✅
참여 - 디자인 시안 🔄
오늘의 회고
- 잘한 점: 기능명세서 작성을 완료 함
- 아쉬운 점: 팀 프로젝트 외에 아무것도 하지 못하고 있음
- 원인: 바쁨
- 개선 액션 아이템: 어쩔 수 없음 바쁨 킵 고잉~
💭 오늘의 한 줄 평 : 킵 고잉~ 킵 고잉~
