디자이너가 QA하기

스타트업에서 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