QA팀의 프로세스 정립기

들어가며

안녕하세요, 노머스 QA팀의 박온유 입니다. QA 관련 자료를 찾아보면, 이미 체계가 갖춰진 상태에서 고도화하는 사례는 많지만 초기 QA 프로세스를 어떻게 만들어가는지에 대한 이야기는 잘 보이지 않더라고요. 그래서 이번 글에서는 저희 팀이 제로에서 시작해 프로세스를 정립해온 과정을 공유해보려 합니다.

1. QA팀이 생기기까지

처음에는 회사에 QA팀이 없었습니다. 개발, 기획, 디자인 담당자들이 함께 모여 테스트를 진행하는 방식이었죠.
하지만 서비스가 성장하면서 점점 이런 방식에는 한계가 보이기 시작했습니다. 테스트 범위가 넓어지고, 담당이 명확하지 않아 누락되는 케이스도 생기기 시작했거든요.
그렇게 QA의 필요성이 점차 커졌고, 마침내 QA팀이 생기게 되었습니다.

2. 프로세스 없이 시작된 QA

QA팀이 생겼지만 초기에는 명확한 테스트 기준이나 문서가 없었습니다.
기획서를 기반으로 탐색적 테스트를 시작했지만, 어디까지 테스트했는지 불분명했고 테스트 커버리지를 장담하기 어려웠어요.

그래서 QA팀에서는 현재 상황에서 할 수 있는 다양한 시도를 해보았습니다.

• QA 개요 문서 → 점차 작성 범위가 커지고 그에따라 리소스 과다
• 자유 형식 체크리스트 → 일정 수준의 커버리지는 가능했지만 테스트 기준이 불명확함
• 자유 형식 TC → 일관성 부족

많은 시행착오를 통해 저희는 아래와 같은 TC 포맷을 도입하게 되었습니다.

3. 우리가 사용하는 TC 포맷

TC 포맷을 정의한 이유는 QA팀 구성원들 간에 TC 작성 방식을 통일하여, 협업을 원활히 하기 위함입니다.

항목은 다음과 같습니다.

TC ID	대분류 (페이지)	중분류 (영역)	소분류 (요소)	Test context (테스트 컨텍스트)	Preconditions (사전조건)	Test procedure (테스트 절차)	Expected result (기대 결과)	우선순위	테스트 결과

• TC ID: 테스트 케이스 고유 식별자
• 대분류 / 중분류 / 소분류: 페이지 > 영역 > 요소 단위로 분류
• Test Context: 유저 시나리오 기준 묶음
• Preconditions: 테스트 전 사전 조건
• Test Procedure: 실제 테스트 단계
• Expected Result: 기대되는 시스템 반응
• 우선순위: 테스트 우선 진행 기준 (기능 중요도 + 테스트 흐름 기준)
• 테스트 결과: 케이스 실행 결과 (PASS/FAIL/NA/NT)

특히 Test Context는 기존에 없던 항목이었지만, 저희가 정의한 TC 작성 방식에 편의성을 더하기 위해 새롭게 추가된 항목입니다. 자유 형식으로 TC를 작성하던 시기에는 시나리오 순서대로 테스트 케이스를 구성했습니다.

하지만 이 방식은 특정 유저 시나리오에 매몰되기 쉬워, 한 요소에서 발생할 수 있는 다양한 케이스를 놓치는 문제가 있었어요.

이를 개선하기 위해, 이제는 요소 기준으로 케이스를 작성하고, 이후 테스트 편의를 위해 유저 시나리오 흐름에 따라 케이스를 묶어주는 역할로 Test Context를 활용하고 있습니다.

덕분에 누락되는 케이스는 줄고, 테스트 효율은 높아지게 되었습니다.

4. 현재의 QA 프로세스

TC 포맷을 정리하고, QA 프로세스도 다음과 같이 정립했습니다.

1. QDR(QA Decision Record) 작성 시작 (QA팀) – 기획 초안과 함께 시작
2. TC 작성 완료 (QA팀)
3. Dev-QA 수행 및 이슈 수정 (개발팀) - 코드 완료 시점
4. 개발 완료 전환 (개발팀) – 모든 이슈 해결 시점
5. 정식 QA 진행 (QA팀)
6. Stage QA + SST (QA팀) – 운영 배포 전 최종 검증
7. 마켓 제출 / 운영 오픈 (개발팀)

5. Dev-QA? 정식 QA?

새롭게 정립된 QA 프로세스에서 Dev-QA와 정식 QA는 뭘까요?

기존에는 개발이 완료되면 곧바로 QA가 시작되었지만, 최근 ‘Dev-QA’라는 단계를 새롭게 도입하게 되었습니다.

이제는 단순히 ‘개발 완료’만으로 QA가 시작되는 것이 아니라,
코드 완료 후 Dev-QA까지 마친 상태여야 정식 QA를 진행할 수 있도록 변경되었습니다.

그렇다면 Dev-QA는 왜 필요했을까요?
저희가 기대한 바는 다음과 같습니다.

Dev-QA

• 스쿼드 담당자들이 직접 TC 기반으로 테스트하며
  → 주요 흐름 검토 및 크리티컬 이슈 사전 확인 가능
• 개발자가 테스트를 직접 수행하며
  → 이슈를 빠르게 인지하고 즉시 대응 가능
• 정식 QA 단계에서 크리티컬한 이슈로 인해 발생하는 일정 지연 감소

이러한 기대효과를 보기 위해 QA 프로세스에 Dev-QA를 적용하게 되었고,
Dev-QA에 참여하는 스쿼드 담당자분들의 노력으로 기대한 바를 이루고 있는 것 같습니다.


Dev-QA를 완료한 후, 정식 QA는 이렇게 진행하고 있습니다.

정식 QA

정식 QA는 각 프로젝트의 QA 담당자가 진행하며, 아래와 같은 순서로 진행됩니다.

1. 1차 QA: Dev-QA 이슈 재확인 + 탐색적/엣지 케이스
2. 2차 QA: 리그레션 및 추가 테스트
3. Stage QA: 운영과 유사한 환경에서 리그레션
4. SST: 전체 서비스 안정성 테스트 (로그인, 결제 등)

1차 QA에서는 Dev-QA 에서 발견된 이슈를 재 확인하고, 메인 시나리오와 더불어 Dev-QA에서 보지 못한 엣지 케이스 위주로 테스트를 진행합니다.

그리고 2차 QA와 Stage QA를 거치면서 혹시 모를 사이드 이펙트들에 대해서 점검합니다.

마지막으로 운영 배포 전 최종 단계인,
SST(Service Stability Test)를 통해 주요 기능들(로그인, 결제 등)에 대해서 다시 한번 점검합니다.

여기까지가 기본적인 QA 프로세스이고, 프로젝트의 성격이나 상황에 따라 언제든 유동적으로 변화할 수 있습니다.
저희 QA팀은 현재의 방식에 안주하지 않고, 매 순간 가장 적절한 프로세스를 고민하며 개선해 나가고 있습니다.

마무리하며

초기에는 아무런 기준 없이 시작했던 QA팀이 이제는 명확한 프로세스와 테스트 케이스 체계를 갖추게 되었습니다.
아직 완벽하진 않지만, 지속적인 리뷰와 개선을 통해 더 나은 품질 확보를 목표로 나아가고 있습니다.
앞으로도 변화하는 서비스 속도에 맞춰 유연하면서도 단단한 QA 시스템을 만들어갈 예정입니다.