QA

QA 프로세스 구축#1

eddiej24 2025. 2. 18. 21:08

QA가 없는 조직에 입사 후 QA 프로세스를 구축해 나가는 이야기입니다.

기초적인 내용이므로 SQA를 준비하시는 분이나 1~2년차 분께 적합할 것 같습니다.

참고로 저는, QA 프로세스 구축을 이전 스타트업 회사에서 성공적으로 안착시킨 경험이 있고, 이번이 2번째입니다.


지피지기 백전불태.

우선, 나(QA)를 회사에서 왜 뽑았는지부터 알아야 합니다.

보통 회사에서 QA를 채용하는 이유는 테스트를 전문적으로 수행할 시기가 도래했기 때문일 겁니다.

 

채용공고 타이틀은 QA면서 JD(Job Description)는 테스터 업무만 적혀 있는 경우도 종종 보입니다.

QA와 테스터는 엄연히 다르지만, "QA = 테스터"라는 인식이 크다는 점은 부인할 수 없습니다.

QA와 테스터가 다르다는 점을 타인에게 설득, 이해시키기는 쉽지 않은 일입니다.

 

잡설이 길었습니다, 다시 회사가 QA 채용한 목적인 '테스트를 전문적으로 수행'을 어떻게 진행 중인지 말씀드리겠습니다.

QA 프로세스는 회사마다 다릅니다, 효율성과 간소화를 추구하는 저의 QA 프로세스임을 감안해주시길 바랍니다.

 

  1. 기획서 숙지
  2. 화면설계서, 기능명세서 숙지
  3. 체크리스트 작성
    • 체크리스트(CL, CheckList)
      : 기획된 기능, 화면 구현 여부를 파악하기 위한 문서입니다.
    • 테스트 시나리오(TS, Test Scenario)
      : '어떤 기능을 테스트할지?', 기능을 중심으로 테스트 수행 절차를 다룬 문서입니다.
    • 테스트 케이스(TC, Test Case)
      : TS + '어떻게?'가 포함된 문서입니다. 전제조건/입력값/기대결과/결과 등이 포함되어 있습니다.
  4. 테스트 수행(Dev 환경, Stag 환경, Master 환경)
    • Dev 환경
      : 개발자가 개발하는 환경입니다. 개발 서버가 별도로 있기도 하지만, 현회사는 개발자 로컬 PC를 의미합니다.
    • Stag 환경
      : QA가 테스트하는 환경으로써 사용자가 이용하는 Master 환경(운영 환경)에 배포 전 출시할 기능에 문제가 없는지를 확인합니다.
    • Master 환경
      : *사용자 환경입니다, Master 환경에 배포 후에도 테스트 수행, 모니터링을 통해 출시한 기능의 정상동작과 그 외 사이드이펙트는 없는지 확인합니다.
      ( * 사용자 환경 = Master 환경 = 운영 환경)
  5. 결함 관리
    • Notion
      : 현회사는 Notion을 이용중이라 기본 제공하는 칸반보드를 활용하여 하나의 페이지에서 관리하고 있습니다.

위 순서대로 진행해도 좋지만 저는

기획서 숙지(1번)와 체크리스트 작성(3번)을 병행하고, 그 다음에

화면설계서, 기능명세서 숙지(2번)와 체크리스트 작성(3번)을 병행하고 있습니다.

이후, 테스트 시 발견된 결함은 Notion 칸반보드에 등록하여 관리 중입니다.

 

체크리스트 작성 과정에서 기획서에 포함된 내용이 화면설계서, 기능명세서에는 미반영되었다는 사실 파악이 가능하고, 또 기획 의도와는 다르게 디자인된 화면이나 편의성을 고려한 제안 등을 반영하여 불필요한 개발 자원(resource)을 줄이는데 도움을 줄 수 있습니다.

또 추후 구두로 진행된 기획 추가/반영사항이 기획서에는 미반영되었으나 화면설계서와 기능명세서에는 반영되는 경우도 심심찮게 보이는데 이런 상황에서 저는 기획서 업데이트를 요청하기 보단, 화면설계서와 기능명세서 내용을 체크리스트에 반영하고, 이후 작성 완료된 체크리스트를 기획자에게 공유하여 테스트 수행 전에 내용을 확인 받고 있습니다.

Notion '댓글' 기능과 Figma 'Comments' 기능이 있는데, 이 기능을 통해 변경사항 이력 소통(update history communication)을 해도 좋을 것 같아 고민 중에 있습니다.


초기 계획은 체크리스트 > TS > TC 순으로 점진적으로 도입하려 했습니다, 하지만 현회사에서 진행하는 많은 프로젝트의 일정과 업무 문화에는 체크리스트가 적합하다고 생각하고 있습니다.

기획 추가 변경은 10차가 넘고, 통합테스트 기간은 1일, 장기 주요 프로젝트들을 병행해야하는 상황에서 TS, TC 구축은 쉽지 않은 일입니다. 구축하려면 하겠지만, 꼭 필요한지? 범용적인지? 두 가지 측면에서 비효율적이란 판단을 내렸습니다.

 

더불어, 일반적인  QA 프로세스에는 QA 요청서, 담당자 선정, 체크리스트 리뷰 등과 같은 부분도 있지만, 현회사에서는 이루어지지 않고 있습니다. 불필요하거나, 아쉬운 부분입니다.

 

 

이만 글을 마치겠습니다 :)

 

'QA' 카테고리의 다른 글

프로젝트 일정 산출 - QA  (0) 2025.02.24
QA 프로세스 구축#2 - Notion  (0) 2025.02.19
프로젝트 완성 기술  (0) 2025.02.16
킥오프 온보딩 차이  (0) 2025.02.15
프로젝트 산출물  (6) 2025.02.14