1일1개 (75) - QA는 테스터인가 ?

1일 1개념정리 24.08.09.금 ~ 

 

큰 결정에 큰 동기가 따르지 않을 때도 있다. 하지만 큰 결심이 따라야 이뤄낼 수 있다.

무조건 무조건 1일 1개의 개념 정리하기 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!

---

#75. QA는 테스터인가 ?

오늘은 어떤 CS 개념이라기보다, 내가 관심있는 직무 중 하나인 QA에 대해 써보려고 한다. 보통은 테스팅 업무를 하는 사람 정도로 이해하는데, 더 구체적으로 어떤 일을 하는지 알아보자. 특정 개념을 정리한 것은 아니니까, 칼럼 한편이라고 생각하고 읽어봅시다.

 

 

# QA와 QC

품질보증 Quality Assurance의 줄임말고, 보통 테스팅쪽은 QA과 QC(= Quality Control, 품질관리)로 나뉜다. QA가 하는 주 업무는 SW Test라고 할 수 있지만, 단순히 개발을 넘겨받아 테스팅만 하는 사람은 아니다.

사실 엄밀히 말하면... 테스팅은 QC의 영역이고, QC는 교정(수정) 중심 작업이다. 그리고 QC와 QA는 서로 다르고, QA는 예방의 관점에서 업무를 진행한다. 즉, QC는 제품중심의 교정, QA는 프로세스 중심의 예방이라고 배웠다. (ISTQB에서 ...) 하지만 뭐 이런 것을 엄밀히 나누는 게 엄청 중요한 것은 아니라고 본다.

 

# QA의 역사

사실 QA의 역사 자체가 길지는 않다. 얼핏 보더라도 개발자가 SW 테스팅은 어느정도 자체적으로 해서 나오기도 하고, 그렇기에 굳이 테스팅 팀 자체를 따로 두진 않는다. 그래서 QA업무는 보통 대기업에 있거나, 아니면 사용자 경험이 매우 중요한 게임업계 같은 곳에서 주로 찾아볼 수 있었다.

나는 보통 SW QA만 관심 있지만, QA 자체만의 역사를 놓고 보더라도 짧다. 1980년대에 처음으로 QC직무가 국내에 대두된 것으로 보이고, SW QA는 그보다도 더 이후에 등장했다.

 

# QA는 only 테스터가 아니다.

먼저 이야기할 것은, QA는 테스팅 업무만 하는 것이 아니라는 것이다. ISTQB를 공부할 때도 나왔지만, QA는 서비스의 기획단계부터 관여하며 개발과 배포 그리고 출시 후까지 모든 단계에서 품질과 관련된 risk를 찾아내는 업무이다. 어떻게 보면 개발자와 가장 긴밀하게 협력할 수 있는 친구같은 역할로 보인다.

1. 기획 단계

기획자, 디자이너, 개발자 등과 협력하며 요구사항을 분석하고, 초기부터 품질 보증에 필요한 요소들을 점검한다. 이것이 일종의 조기 테스팅이 되는데, 이때 잘 해놓으면 추후에 테스팅 할 것들이 줄어들 수 있다.

2. 개발 단계

개발 후에는 코드리뷰, 테스트케이스 작성 및 검토, 자동화 테스트 등이 이루어진다. 

3. 배포 단계

실제 환경에서 제대로 동작하는지 검증하기 위해 여러 시나리오로 테스트한다.

4. 사용자 피드백 단계

피드백을 받아 새로운 기능, 업데이트가 어떤 영향을 주고 있는지 모니터링 하고 이를 반영한다.

 

# QA에게 중요한 것은 ?

내 생각엔 .... QA라는 업무는 정확히 원하는 결과물이 무엇인지 알고 테스팅하는 것, 그리고 원하는 결과물이 나오더라도 이것이 사용자 경험을 저해하지 않는지 확인하는 것이 중요하다고 생각한다. 여러 테스트 용법과 툴을 익히는 것도 중요한데, 이런 디테일한 면을 챙겨야 좀 더 좋은 테스팅이 될 수 있어보인다.

개인적으로, 나는 인간 공학적인 측면을 조금 더 중요하게 본다. Test를 거치고 오류를 발견하고 이를 관련 부서에 전달할 때에도 "이거 너네가 잘못. 고쳐주세요."라고 전달할 것이 아니라 원만히 전달하는 능력도 중요하다고 한다. 아무래도 테스팅 업무 자체가 언제나 부정적인 이야기를 많이 하다보니, 그런 커뮤니케이션 역량을 중요하게 보는듯 하다.

그게 아니더라도 위에서 보듯이 여러 유관부서와 협력할 일이 많으니, 이런 사람들과 긴밀히 협력할 수 있는 능력도 중요한듯 하다.