관리 메뉴

ITGeine

QA 직군에 대한 개인적인 생각 본문

QA/QA

QA 직군에 대한 개인적인 생각

Nick9 2020. 7. 31. 18:54

 TE, TL, QA, QE, QC, QM 등 유난히 QA에는 수많은 직군들이 있다. 그리고 각 직군별로 경계도 너무나 불명확하며, 같은 직군이라도 기업별로 수행하는 업무와 포지션도 가지각색이다. Quality 보증 이라는 명확한 산출물이 없는 결과를 내기 위해 다양한 역할이 필요하고 이들을 모두 QA 직군으로 포함하기 때문이다.

 그런데 이런 직군과는 별개로 보통 QA = TE 로 인식되는 것 같다.  보편적으로 생각하는 품질이란 제품을 사용함에 있어 결함, 소위 말하는 버그가 없는 것이고 그것을 위해 테스트를 수행하는 일이 주여서 그런 인식이 생긴것 같다.

 하지만 QA가 단순 테스터라고 하기엔, 경력자를 찾을 이유가 없다. (테스트 케이스만 있다면 정해진 스텝대로 절차를 수행하고 기대 결과와 비교하는 일은 누구나 할수 있다고 생각한다. 물론 보안이나 성능 테스트 등은 예외) QA는 단순 테스트를 넘어서 품질을 위해 무엇인가를 할수 있어야 한다.

 

 그 '무엇인가' 에 따라서 QA 직군이 분류된 것이 아닌가 싶다.

 - TE : Test Engineer, 보통 우리가 부르는 테스터가 여기에 속한다. 결함을 찾고 테스트를 수행하는 역할을 한다. 이 직군의 역량은 경험 기반으로 이슈를 빠르게 확인 / 문제의 원인 추측 / 이슈를 얼마나 파악해서 명확하게 전달하는지이다.

 - TL : Test Leader, 테스트 방법론에 의해 테스트를 설계하고 테스트 산출물, 수행 인원을 관리한다.

 - QE : Quality Engineer. 품질 자동화. 원래는 계획-개발-테스트-배포 등 프로세스에 대한 전체 자동화를 의미하지만, 거의 대부분 테스트를 자동화하는 것에 그친다. (Unit 테스트 자동화나 CI/CD 는 개발 지식에 대한 한계 때문인지 주로 개발팀에서 수행하는것 같다)

 - QM : Quality Manager, QA 와 많이 혼용되는듯 하다. 

 

 그러나 보통 이러한 직군을 세분화하지 않고 QA로 뭉뚱그려서 채용하기 때문에, 자동화도 조금 하고(QE) / 테스트 인력관리도 하고 (TL~QA 의 중간 어디쯤) / 가끔 테스트 난이도가 높은 도메인이거나 개발을 해야하는 경우 or 인력이 없는 경우 테스트도 하고 (TE) / 품질 지표를 뽑거나 서버 로그를 분석하기도 한다. (QA? QC?) 

 지금 내가 하고 있는 업무도 그러한데 입사 초기에는 다양한 업무를 경험해볼수 있다는 점에서는 좋겠지만, 전문화를 위해서는 직군을 정해 깊이있게 공부하고 실무에도 적용이 필요하다고 생각한다.