스타트업에서 QA 프로세스를 체계적으로 구축하고 제품의 완성도를 높이는 것은 쉽지 않은 과제입니다.

회사에서는 개발된 기능을 개발 서버에서 테스트했지만, 실제 서버 배포 후 예상치 못한 버그로 인해 고객 문의가 급증하는 경우가 종종 발생했습니다.

개발 속도가 가속화되고 더 많은 기능을 구현해야 하는 상황에서 QA의 중요성이 점점 더 부각되었습니다.

QA 전담 인력을 바로 채용하기는 어려워, QA담당자로 재직중인 지인의 도움을 받아 QA 프로세스를 학습하게 되었습니다.

아래는 제가 전수받은 QA 프로세스입니다.

QA 전문가분들께서 이 내용을 읽게 되신다면, 개선이 필요한 부분 댓글로 알려주세요!

--------------------------------------------------------------------------------------

1️⃣ 릴리즈 일정이 정해지면 기획 리뷰 진행

2️⃣ 신규 기능에 대한 TC(Test case) 작성

테스트 케이스 작성은 가장 시간이 많이 소요되는 단계입니다. 이 과정에서는 사용자 인터페이스(UI)의 모든 세부적인 동작을 빠짐없이 문서화해야 합니다.

예를 들어, 드롭다운 메뉴가 선택 시 제대로 펼쳐지는지와 같은, 당연해 보이는 기능까지도 꼼꼼히 기록해야 합니다.

TC 작성 방법

1. 화면의 depth 정의: 해당 케이스를 확인하기 위한 정확한 위치를 적어주기

1 depth: 화면명 (로그인 페이지, 설정 페이지, 모달 등)
2 depth: 페이지 내 영역 (GNB, LNB 등)
3 depth: 컴포넌트 (버튼, 인풋 등)
4 depth: 드롭다운 등 컴포넌트의 하위 (필요하다면 작성)

2. TC 타이틀 적기: '무엇을 확인하고자 하는지'를 적습니다.

   • 예: 버튼 작동 여부 확인

   • 동일한 TC 타이틀이 있다면 괄호로 몇 개의 중복 TC가 있는지 개수를 적어줍니다.

     • 예: 버튼 작동 여부 확인(3)

3. 사전 조건 작성: 이 TC를 확인하기 위해 충족되어야 하는 조건이 있다면 적어줍니다.

   • 예: 권한, 스위치 on/off 여부

4. 절차 작성: TC를 확인하기 위해 실행되어야 하는 절차를 적습니다.

   • 예: 1. 필터 클릭 2. 필터 변경

5. 기대 결과 작성: 절차를 완료하면 수행되어야 하는 액션을 적습니다. 기획의도가 포함됩니다.

   • 예: 설정한 필터로 테이블 필터링 됨

6. 우선순위 작성: P0,P1,P2,P3 순으로 비즈니스 관점에서 중요 정도로 선택합니다. (우선순위 정의는 기억이 잘 나지 않아 perplexity에게 물어봐 작성했습니다.)

P0 (최고 우선순위)
- 즉각적인 조치가 필요한 가장 중요한 작업
- 시스템 전체에 영향을 미치는 심각한 문제
- 제품 출시를 지연시킬 수 있는 수준의 중요도
- 예: 앱이 실행 즉시 충돌하는 경우

P1 (높은 우선순위)
- P0 다음으로 중요하며 빠른 해결이 필요한 작업
- 주요 기능의 오작동 또는 많은 사용자에게 영향을 미치는 문제
- 일반적인 업무 일정 내에서 긴급하게 처리해야 함

P2 (중간 우선순위)
- 중요하지만 즉각적인 조치가 필요하지 않은 작업
- 소수의 사용자에게 영향을 미치는 minor한 기능 오류
- 다른 이슈들과 함께 우선순위를 고려하여 처리

P3 (낮은 우선순위)
- 긴급하지 않고 중요도가 낮은 작업
- 일상적인 업무의 일부로 처리 가능한 수준
- 장기적인 목표에 기여하는 작업

7. 결과 작성

   • 결과를 PASS,FAIL,N/A중 하나를 선택합니다. (N/A는 환경적인 요인으로 케이스 확인이 불가할때 기입합니다.)

8. Bug ticket no. 작성

   • 노션이나 지라 등 버그 이슈를 취합하는 툴의 링크를 입력합니다.

9. 코멘트 (필요시 작성)

추가적으로 고려할 수 있는 사항:
- 테스트 환경 (예: 브라우저, 운영체제, 디바이스 등)
- 테스트 데이터
- 테스트 수행자
- 테스트 일자

3️⃣ QA일정 확정

QA일정 확정 후 릴리즈 일정을 확정합니다.

4️⃣ dev서버 테스트

TC 테스트 & 리그레이션 테스트 (이전에 고쳤던 버그가 발생하지는 않는지)

5️⃣스테이지서버 테스트

dev 서버에서 버그 픽스 후, 스테이지서버에 올려 실서버와 동일한 환경에서 테스트를 진행합니다.

6️⃣ 잔존이슈 확인

이전에 픽스한 버그가 또 발생하지는 않는지 확인합니다.

7️⃣ 사인오프

공식적으로 QA가 완료되었다는 것을 공유합니다.

8️⃣ 릴리즈 테스트

실서버 릴리즈 후에는 모든 테스트 케이스(TC)를 확인하기보다는, 주요 기능과 기획 의도에 부합하는 핵심적인 테스트에 집중합니다

9️⃣ QA종료

--------------------------------------------------------------------------------------

이 QA 프로세스를 적용하면서 우리는 이전에 발견하지 못했던 숨겨진 버그들을 찾아낼 수 있었습니다.

특히 여러 화면에서 공통으로 사용되는 컴포넌트의 경우, 새로운 기능 개발로 인해 기존 기능이 영향을 받아 오작동하는 사례를 발견할 수 있었습니다.

테스트 케이스(TC) 작성은 시간과 노력이 많이 드는 작업이지만, 완성 후 QA를 수행할 때는 마치 숨은그림찾기를 하는 것 같이 흥미로웠습니다.

만약 여러분의 제품이 릴리즈 후 예상치 못한 버그로 고민하고 계시다면, 이 글에서 소개한 QA 프로세스가 도움이 되길 바랍니다.

아래 링크에서 테스트 케이스 예시를 확인하실 수 있습니다. 필요하시다면 참고해 주세요.

https://docs.google.com/spreadsheets/d/1KdvBIpkZy778CgN1Fiux3yPMMA1goZySMXZxii6Tkrk/edit?gid=0#gid=0