“QA는 무슨 일을 하나요?” PO와의 커피챗에서 받은 9가지 질문

반응형

2025년 7월 24일, ‘정리습관’ 김윤희 PO님과 함께 “QA는 어떤 일을 하고, 어떻게 협업하면 좋을까?”를 주제로 커피챗을 진행했습니다.
동료인 웨이드(PM)의 소개로 자리를 갖게 되었고, 1년차 PO 입장에서 실무에서 QA에 대한 궁금증들을 하나씩 나눠보는 유익한 시간이었습니다.

아래는 커피챗 중 오갔던 주요 질문과 답변을 정리한 내용입니다.

---

🧩 [정의] QA는 어떤 역할인가요?

Q1. QA가 정확히 무슨 일을 하나요?

QA는 서비스의 품질을 전반적으로 책임지는 역할입니다.
기능이 의도대로 동작하는지, 요구사항이 명확한지, 릴리스 전 어떤 리스크가 있는지 검토합니다.
개발, 기획, 운영 등에서 놓칠 수 있는 품질 요소를 찾아내고, 문제가 생기지 않도록 사전에 방지하거나 예측하는 것이 핵심입니다.

 

추가로, QA 역할은 포커스에 따라 다양하게 나뉩니다

Test Engineer	테스트 설계 및 수행
Test Automation Engineer	테스트 자동화 설계 및 구현
QA Specialist	품질 기준 및 프로세스 준수 모니터링
QA Assistant	테스트 일정 및 품질관리 보조
QC (Quality Control)	결과물에 대한 품질 검증 (제조업 중심)

---

Q2. PO와 개발자 사이에서 QA는 어떻게 소통하나요?


QA는 단순히 테스트하는 사람이 아니라, 품질 기준을 정립하고 커뮤니케이션의 시작과 끝을 책임지는 역할입니다.
갈등을 중재하는 것이 아니라, 근거 기반으로 각자의 R&R(역할과 책임)을 명확히 정리합니다.

🧪 예시 1

• PO: “리스트는 최신순으로 정렬되어야 합니다.”
• 개발자: “기획서에 정렬 조건이 없어서 레거시 그대로 개발했어요.”
• QA: “기획서에 명시가 없었고, 요구사항도 모호했습니다. 다만 UX 관점에서 최신순 정렬이 타당해 보입니다. 이번 배포에서는 제외하고, 다음 릴리즈에 반영할 수 있도록 기획서를 보완해 주세요.”

🧪 예시 2

• QA: A 기능 테스트 중 B 기능과 연결된 조건이 빠진 것을 발견 → 이슈 등록
• PO: “그 조건은 제외하기로 했어요.”
• 개발자: “처음엔 포함이었는데, 제외된다는 얘기는 못 들었어요.”
• QA: 변경된 히스토리를 PO 측에 확인하고 → 기획서 수정 요청 → 이슈 Close
  → "단순 누락인가, 스펙 변경인가"를 명확히 정리하는 것이 핵심입니다.

---

Q3. 기획/디자인 단계에서 QA에 도움이 되려면 어떤 점을 고려하면 좋을까요?


다음 항목들이 정리되면 QA가 더 효과적으로 테스트 케이스를 설계할 수 있습니다.

• 정상 케이스 정의
• 엣지 케이스 및 비정상 케이스 정의
• 상태별 UI 처리
• 주요 조건 명시
• 전체 플로우 흐름 연결

QA가 기획 리뷰 단계에서 흐름만 함께 점검해도, PO-디자인-QA 간 싱크를 맞추는 데 큰 도움이 됩니다.

 

---

 

Q4. 개발자는 기획자나 디자이너보다 더 많은 걸 고려하나요?


“누가 더 많이 고려하냐”는 관점보다, 각 직무가 어떤 성격의 요소를 고려하는지가 더 중요합니다.

• 기획/디자인은 사용자 관점에서 기능의 목적과 UI 흐름을 고민
• 개발은 실제 구현 시, 성능/보안/서버 리소스/DB 부하/롤백 전략 등 기술적 리스크를 종합적으로 고려

즉, 서로의 고려 포인트는 다르고, 책임 구조 또한 다릅니다.
PO 입장에서 이를 이해하면 문제 상황에서 더 빠른 판단과 조율이 가능합니다.

 

 

---

Q5. 어느 단계까지 작업이 되어야 테스트케이스가 보이기 시작하나요?


QA 입장에서 실제 테스트케이스를 설계하려면 디자인까지 확정되고, 그에 따른 흐름이 정의되어야 합니다.
적어도 다음 항목은 갖춰져야 합니다:

• 기능의 목적
• 전체 흐름
• 상태 변화
• 조건

이전 단계에서는 QA가 방향성 검토는 가능하지만, 구체적인 테스트케이스 작성은 어렵습니다.

(단, 제품 숙련도나 사람마다 다르긴 합니다.)

 

---

📄 [문서화와 QA 관점]

Q6. 제품을 만들 때 QA 관점의 목록은 초반부터 정리해야 하나요?


가능한 한 빠를수록 좋습니다. QA는 문제를 사전에 방지하는 조직이기 때문에,
초기에 스펙을 보며 복잡하거나 리스크가 있는 기능을 체크리스트화 해두면
의사결정도 빠르고 커뮤니케이션도 원활해집니다.

 

 

---

Q7. 테스트케이스는 어떻게 써야 빠짐없이 커버할 수 있나요?


하나의 테스트 케이스에는 최소한 다음 요소가 포함되어야 합니다:

• 어떤 기능을 확인하려는가? → 목적 정의
• 사용자는 어떻게 사용할까? → 시나리오
• 조건에 따라 달라지는 동작은? → 상태 및 분기
• 엣지 케이스는 정의되어 있는가? → 선택 항목이지만 중요

※ “성공 조건”과 “실패 조건”만 명확히 알아도 전체 테스트의 90%는 설계할 수 있습니다.

 

---

Q8. 문서는 누가 작성하나요?


문서는 각 역할에 따라 다음과 같이 나뉘는 경우가 많습니다:

PO	PRD, 플로우, 요구사항 정의
PD	화면 및 UI, 상태별 화면 정의
개발자	API 명세, 기술 사양
QA	테스트케이스, 리포트, 이슈 히스토리 정리 등

 

문서의 핵심은 ‘누가 작성하느냐’보다 ‘왜 작성하는가’, 즉 목적에 맞는 형태로 남기는 것입니다.

 

 

---

💡 [꿀팁] 기획/디자인 단계에서 꼭 해주면 좋은 것

Q9. 기획/디자인 중 이런건 꼭 해줘야 한다 싶은게 있을까요?

기획/디자인 단계에서 아래 항목만 명확하게 챙겨주셔도 QA 입장에서 정말 큰 도움이 됩니다:

• 기능의 목적
• 조건 (어떤 상황에서 발생?)
• 흐름 (유저가 어떤 행동을 하면 어떤 결과가 나오는가)
• 엣지 케이스 / 예외 처리
• UI 상태별 정의
• 결과에 따른 행동 정의

---

 

✍️ 맺으며

짧은 대화였지만, 역할에 대한 이해가 쌓이고
서로의 고민을 공유하며 좋은 인사이트를 주고받을 수 있는 시간이었습니다.

QA는 단순히 테스트를 수행하는 역할이 아니라,
‘문제를 예방하고 품질을 보장하는’ 책임을 가진 중요한 파트입니다.
이 글이 QA와 협업해야 하는 분들, 특히 주니어 PO분들께 조금이나마 도움이 되길 바랍니다.

728x90