[PM온보딩] 프로젝트 QA
Chapter 9.
QA
개발이 끝났다고 해서 바로 출시해도 될까요?
땡 ! 그렇지 않습니다.
서비스가 실제 사용자와 만나기 위해서는 QA(Quality Assurance) 과정을 꼭 거쳐야 합니다.
QA는 단순한 오류 점검이 아닌, 기획된 기능이 제대로 구현되었는지, 디자인이 일관되게 반영되었는지 검토하여 제품의 신뢰도를 확보하는 과정입니다.
개발 도중에는 보이지 않았던 이슈들이 QA에서 드러나기도 합니다.
예를 들어, 예상하지 못했던 흐름에서 오류가 발생하거나, 화면 일부가 반응형에서 깨지는 등의 문제들이 대표적입니다.
이러한 문제들을 발견하여, 출시 전에 수정할 수 있는 기회가 바로 QA입니다.
1. 사전 준비사항 – Test Case 작성
Test Case는 기능별로 "무엇을", "어떻게", "왜" 테스트해야 하는지를 정리한 문서입니다. 테스트 시 참고할 수 있도록 기준을 제시하는 역할을 합니다.
Test Case는 반드시 있어야 하는 건 아니지만, 있으면 QA의 속도와 품질이 모두 향상됩니다.
Test Case 작성 시 포함할 요소 : Notion, 구글 시트 등 팀의 작업 방식에 따라 작성합니다.
- 기능 명 : 회원가입
- 사용자 흐름 : 회원가입 버튼 클릭 > 인증 메일 수신 확인
- 기대 결과 : 인증메일이 정상적으로 발송됨
- 유효성 검사 : 중복 이메일 입력 시 오류 메시지 노출
- 테스트 결과 : O / X
- 비고
2. QA 진행 – 내부와 외부
QA 결과는 공유 가능한 형태로 정리하여, 누구나 현재 상태를 쉽게 확인할 수 있도록 관리합니다.
도구
Jira: 개발자 중심의 QA 이슈 트래킹
Notion: 문서 중심의 협업 툴, 디자인 QA에 유리
Google Sheet / Excel: 간편한 필터링과 태깅 관리에 적합
이슈 유형
버그 : 기능 오류 (우선순위)
디자인 불일치
개선 제안 (후순위)
내부 QA
PM과 디자이너가 중심이 되어 테스트를 수행합니다. (제가 소속된 에이전시의 경우, 별도의 전담 QA 인력이 없기 때문에 프로젝트 팀원들과 함께 QA를 수행해왔습니다.)
PM은 기능 흐름을 기준으로 단위 테스트를 진행합니다.
유효성 검증, 사용자 예외 흐름을 확인합니다.
디자이너는 디자인 정합성(간격, 색상, 반응형, 정렬 등)을 확인합니다.
Figma 등 디자인 산출물과 실제 결과물을 비교합니다.
브라우저/디바이스 별로 환경을 나눠 점검합니다. 예: Chrome, Safari 등
내부 QA 체크포인트
상호 협의된 기획대로 기능이 정상 작동하는가?
반응형/다양한 해상도에서도 디자인이 깨지지 않는가?
엣지 케이스(예외 상황, 오류 유도 등)도 고려되었는가?
외부 QA
클라이언트가 제품을 실제로 사용하며 확인하는 단계입니다.
QA 기간: 최소 5일이상 확보를 권장합니다.
내부 QA 완료 후 외부 QA를 요청합니다.
PM은 해당 과정에서 클라이언트의 피드백을 수집하여 기능 누락인지 / 오류인지 / 신규 제안인지 / 개선사항인지 확인하여 우선순위에 따라 구분하여 내부 팀원들에게 공유합니다.
외부 QA 시 주의할 점
클라이언트는 기획서를 보지 않은 상태에서 기능을 판단할 수 있습니다.
실제 사용 중 오류 보다도 불편사항, UX 개선, 기능 제안이 대거 발생할 수 있습니다.
초기 요구사항이 변경되거나 재정의되는 경우가 생길 수 있습니다.
특히 에이전시에서는 일정 리스크에 민감하므로, 클라이언트 요청에 대한 일정 영향을 파악하여 명확히 소통해야 합니다.
PM은 모든 피드백을 수용하는 것이 아니라, "이슈"인지, "개선 제안"인지, "기획 외 추가 요청"인지 구분하여, 필터 역할을 수행해야 합니다.
3. 실전 팁
실제로 QA를 진행하다 보면, 예상치 못한 곳에서 일정 지연이나 커뮤니케이션 오류가 발생하곤 합니다.
1. 버그인가, 추가 요청인가? – 피드백의 분류와 대응
클라이언트로부터 들어오는 피드백이 실제로 오류인지, 새로운 요구사항인지를 구분하여, 일정 지연, 커뮤니케이션 혼선, 개발 리소스 낭비를 막습니다.
판단 기준은 문서에 있습니다.
버그: 기능정의서, PRD, 디자인 산출물에 포함된 기능이 정상적으로 작동하지 않는 경우
추가 요청: 문서에는 없었던 기능이나 동작을 새롭게 요구하는 경우
PM은 기준에 따라 피드백을 분류하고, 팀원 및 클라이언트에게 설명해 주어야 합니다.
요청의 반영 여부는 일정과 난이도에 따라 판단합니다.
간단히 반영 가능한 개선 사항은 우선순위를 낮춰 후순위 작업으로 안내합니다.
기간 내 반영이 어려운 요청은 이유를 구체적으로 설명한 뒤, 출시 이후 유지보수 사항으로 검토하겠다고 안내합니다.
2. QA 기간은 버퍼를 포함합니다.
QA 피드백은 반드시 발생합니다.
"이슈가 없을 수도 있다"는 희망보다는, "수정이 필요할 것"이라는 전제로 일정을 짜는 것이 좋습니다.
실제 QA 반영 및 재확인까지 소요되는 시간 + 커뮤니케이션 시간을 고려합니다.
5일 이상의 QA 버퍼 확보를 추천합니다.
3. QA는 빠르게, 반복은 줄이기
QA는 1~2회 차로 끝내는 것이 이상적입니다.
같은 항목이 반복되거나 QA가 장기화되면 전체 일정이 밀릴 위험이 있습니다.
사전 체크리스트로 QA 항목 미리 점검
기능별 QA 담당자 지정 → 중복 피드백 방지
빠른 확인과 우선순위 조율을 통해 반복 줄이기
4. 피드백 공유는 슬랙 대신 ‘정리된 문서’로
Slack 이나 메세지로 전달된 QA는 잊히기 쉽고 트래킹이 어렵습니다.
Google Sheet, Jira, Notion 등 문서화된 공간에 모든 피드백을 기록
변경 이력, 상태, 담당자 지정 등을 함께 관리
PM은 QA 커뮤니케이션의 중심을 ‘문서’로 진행하고 상호 간에 효율적인 커뮤니케이션이 되도록 이끌어야 합니다.
QA는 단순히 오류를 찾는 과정이 아니라, 기획, 디자인, 개발의 완성도를 검증하고, 제품이 사용자에게 신뢰를 줄 수 있는 상태인지 점검하는 중요한 과정임을 기억해주세요.
