QA ≠ TEST
QA에 대한 진실과 오해
안녕하세요. QA를 즐겁게 하고 있는 Eddy입니다.
우리가 IT라는 범주안에서 몇가지 수년간 변하지 않고 통상적으로 사용하고 있는 몇가지 문장이 있습니다.
예를 들어 본다면 가장 빈도가 높은 문장은 "QA중이에요", "QA해주세요" 입니다.
상당히 익숙한 문장들이죠? 하지만 사실은 QA와 TE(Test Engineer)의 역할을 혼용하는 데서 비롯된 작은 오해라는 사실, 알고 계셨나요?
오늘은 QA(Quality Assurance)에 대해 알아보고 Test Engineer와 어떻게 다른지 알아 보려 합니다.
우리가 알고 있는 QA, 빙산의 일각일 뿐이었다.
생각보다 많은 분들이 QA를 제품의 버그를 찾아내는 테스트 활동이라고 생각하고 계십니다.
하지만 이는 QA라는 거대한 빙산의 보이는 일각에 불과합니다.
우리가 흔히 "QA 해주세요"라고 요청하는 업무는 사실.... 검증(Testing)에 해당합니다.
검증(Testing)은 만들어진 제품의 기능이나 요구사항이 제대로 구현되었는지 확인하고 결함을 발견하는 데 집중하는 활동입니다.
그렇다면 수면 아래 잠겨있는 거대한 '품질 보증(Quality Assurance)'의 정체는 무엇일까요?
QA는 단순히 결함을 찾는 것을 넘어, 개발 전 과정에 걸쳐 품질 목표를 세우고, 이를 달성하기 위한 시스템과 프로세스를 구축하며 지속적으로 개선하는 총체적인 활동을 의미합니다.
품질 관리의 전문 영역: 각 역할과 임무
고객이 안심하며 사용하고 자주 찾을 수 있는 제품은 각 분야 전문가들의 시너지를 통해 탄생합니다. 품질을 책임지는 영역도 마찬가지로, 명확하게 구분된 여러 전문적인 역할들이 존재합니다.
이 역할들이 조화를 이룰 때 비로소 제품의 완성도가 높아집니다.
자 지금부터 어떤 역할이 있고 어떤 일을 하는지 알아볼까요?
- QA Engineer: 품질 전략을 설계하는 '설계자'
QA Engineer는 "어떻게 하면 처음부터 버그 없는 제품을 만들 수 있을까?"를 고민하며 품질 보증의 큰 그림을 그리는 전략가입니다.(버그가 없는 SW는 없다는건 비밀..)
> 주요 업무:
✅ 품질 목표 수립: 제품이 갖춰할 품질 기준(기능성, 신뢰성,사용성 등)을 정의합니다.
✅ 프로세스 설계: 결함 발생을 원천적으로 줄일 수 있는 정책 / 표준 / 절차를 구축하고 개선합니다.
✅ 위험 관리: 잠재적인 품질 이슈를 미리 식별하고 예방하는 전략을 수립합니다.
✅ 테스트 전략 총괄: 전체적인 테스트 방향 설정 및 활동 전발을 조율합니다. - Test Engineer: 기술로 검증 시스템을 만드는 '기술 전문가'
Test Engineer는 QA Engineer의 큰 그림을 현실로 만드는 기술 전문가로서, 자동화된 테스트 환경을 구축하고 최신 기술을 도입하여 테스트의 효율과 정확도를 극대화합니다.
> 주요 업무:
✅ 테스트 설계 및 계획: 제품의 특성과 위험도를 분석하여 수동 및 자동화를 아우르는 종합적인 테스트 계획과 상세 케이스를 설계합니다.
✅ 테스트 자동화 구축: 반복적인 검증 작업을 자동화하여 테스트의 효율성과 커버리지를 높입니다.
✅ 전문 테스트 수행: 성능, 부하, 보안 등 특수 목적의 테스트를 계획하고 실행합니다.
✅ 테스트 환경 및 도구 관리: 테스트에 필요한 환경을 구축하고 효율을 높이는 다양한 도구를 도입하거나 개발합니다.
✅ 결과 분석 및 보고: 테스트 결과를 바탕으로 제품의 현재 품질 상태를 종합하여 객관적으로 분석하여 이해 관계자에게 전달합니다. - Tester: 날카로운 눈으로 결함을 찾아내는 '실행자'
Tester는 설계된 계획과 시스템 위에서 실제 제품을 사용하며 마지막 방어선 역할을 합니다.
> 주요 업무:
✅ 테스트 실행: 작성된 테스트 케이스에 따라 수동 또는 자동으로 테스트를 수행합니다.
✅ 결함 보고 및 추적: 발견된 결함을 개발팀이 재현하고 이해하기 쉽도록 상세히 기록하고, 수정 여부를 확인합니다.
"QA 해주세요" 대신 "테스트 해주세요!" 💪
이제 QA ≠ TEST 공식이 명확해지셨나요?
우리가 무심코 "QA 해주세요"라고 말할 때, 그 의도는 대부분 개발된 기능이 잘 동작하는지 검증해달라는 테스트 요청입니다.
앞으로 "이 기능 테스트 부탁드립니다!" 라고 명확하게 말씀해 주시는 건 어떨까요?
이 작은 언어 습관의 변화는 단순히 용어를 바로잡는 것을 넘어, 각 역할의 전문성을 존중한다는 의미를 담고 있습니다.
명확한 테스트 요청은 Tester가 기능 검증에 온전히 집중하게 하고, QA 엔지니어는 잠재적 위험을 분석하고 프로세스를 개선하는 데 시간을 쓸 수 있게 해줍니다.
이것이 바로 '버그를 잡는 조직'에서 '버그를 예방하는 조직'으로 성장하는 첫걸음입니다.
마무리하며: 함께 만드는 품질 문화
QA Engineer는 품질의 설계자, Test Engineer는 검증 기술의 구현가, Tester는 제품의 최종 검증관입니다.
품질은 특정 팀의 전유물이 아니라, 우리 모두가 함께 만들어가는 문화입니다.
QA ≠ TEST 공식을 이해하고 서로의 전문성을 존중하는 문화를 통하여 우리는 고객에게 최고의 전기차 충전 경험을 제공하였으면 합니다.
생애 첫 블로그를 이렇게 써보았는데 다음에는 좀 더 실무에 가까운 주제를 가지고 돌아 오도록 하겠습니다.
지금까지 그동안 한번쯤은 이런 얘기를 해보고 싶었던 여러분의 친구 QA하는 Eddy 였습니다.
읽어주셔서 감사합니다.
