소프트웨어 개발 분야에 처음 발을 들이면 ‘QA’와 ‘테스팅’이라는 용어를 자주 접하게 됩니다. 많은 주니어 개발자나 기획자, 심지어 QA 신입조차 ‘QA는 그냥 테스트하는 일 아닌가요?’라고 생각하곤 합니다. 두 용어가 혼용되어 쓰이는 경우가 많기 때문입니다.
하지만 이 둘은 목표와 범위가 명확히 다른, 별개의 개념입니다. 좋은 품질의 소프트웨어를 만들기 위해서는 이 차이점을 명확히 이해하는 것에서부터 모든 것이 시작됩니다.
이 글에서는 QA와 테스팅의 본질적인 차이점과, 체계적인 테스트를 위해 반드시 알아야 할 ‘소프트웨어 테스트의 4가지 레벨’에 대해 알아보겠습니다.
과정(Process) vs. 활동(Activity): QA와 테스팅의 본질적 차이
가장 핵심적인 차이를 한 문장으로 정의하면 다음과 같습니다.
- QA(Quality Assurance, 품질 보증)는 ‘결함이 생기는 것을 예방’하는 사전적이고 과정 중심적인 활동입니다.
- 테스팅(Testing)은 ‘이미 발생한 결함을 찾아내는’ 사후적이고 제품 중심적인 활동입니다.
아직 와닿지 않으실 수 있습니다. 자동차 공장에 비유해 보겠습니다.
‘테스팅’이 ‘완성된 자동차의 브레이크가 잘 작동하는지, 에어백이 터지는지 직접 검사하는 활동’이라면, ‘QA’는 ‘애초에 브레이크가 고장 나지 않도록 부품 설계도를 검토하고, 에어백이 항상 터지도록 조립 라인의 표준 절차를 만들고 교육하는 과정’과 같습니다.
| 구분 | QA (Quality Assurance) | 테스팅 (Testing) |
| 목표 | 결함 예방 (Defect Prevention) | 결함 발견 (Defect Detection) |
| 관점 | 과정 중심 (Process-oriented) | 제품 중심 (Product-oriented) |
| 시점 | 사전적 (Proactive) | 사후적 (Reactive) |
| 역할 | 품질 표준 수립, 프로세스 개선, 위험 관리 | 테스트 케이스 실행, 결함 보고, 결과 분석 |
| 질문 | “어떻게 하면 더 좋은 제품을 만들 수 있을까?” | “이 제품에 문제는 없는가?” |
즉, QA는 테스팅을 포함하는 더 넓은 개념의 품질 활동 전체를 의미합니다. 테스팅은 그 QA라는 큰 우산 아래에 있는, 품질을 검증하기 위한 매우 중요한 ‘활동’ 중 하나인 셈입니다.
나무가 아닌 숲을 보는 법, 4단계 소프트웨어 테스트 레벨
그렇다면 테스팅 활동은 어떻게 이루어질까요? 단순히 완성된 제품을 처음부터 끝까지 눌러보는 것만으로는 부족합니다. 체계적인 소프트웨어 개발 프로세스에서는 보통 4가지 단계의 테스트 레벨을 거치며 품질을 점검합니다. 이는 마치 작은 나사부터 시작해 엔진을 조립하고, 최종적으로 자동차 전체를 시험 운행하는 과정과 같습니다.
레벨 1: 단위 테스트 (Unit Test)
가장 작고 기본적인 테스트 단계입니다. 소프트웨어를 구성하는 가장 작은 단위, 즉 함수(Function)나 메소드(Method), 클래스(Class) 같은 코드 조각(단위)이 개별적으로 올바르게 동작하는지를 검증합니다.
- 대상: 코드의 가장 작은 단위 (함수, 메소드 등)
- 주요 수행자: 개발자
- 목표: 각 부품이 설계된 대로 정확히 작동하는지 확인. 다른 코드와 연결되기 전에 부품 자체의 완결성을 보장하는 것이 목적입니다.
레벨 2: 통합 테스트 (Integration Test)
단위 테스트를 통과한 여러 개의 코드 조각(단위)들을 하나로 합쳤을 때, 이들이 서로 상호작용하며 잘 동작하는지를 검증합니다. 부품들을 모아 엔진이라는 하나의 모듈로 조립했을 때, 각 부품이 충돌 없이 매끄럽게 돌아가는지 확인하는 단계입니다.
- 대상: 여러 단위가 결합된 모듈 또는 컴포넌트 간의 인터페이스
- 주요 수행자: 개발자, QA 엔지니어
- 목표: ‘회원가입’ 기능과 ‘로그인’ 기능이 데이터를 정상적으로 주고받는지, A 모듈이 B 모듈을 호출할 때 문제가 없는지 등 컴포넌트 간의 결합에서 발생하는 오류를 찾아냅니다.
레벨 3: 시스템 테스트 (System Test)
모든 부품과 모듈이 결합된, 완성된 소프트웨어 전체 시스템을 대상으로 테스트합니다. 이 단계에서는 내부 코드 구조는 보지 않고, 실제 사용자의 입장에서 요구사항 명세서에 따라 기능이 올바르게 동작하는지를 검증합니다. 우리가 흔히 ‘QA 테스트’라고 부르는 활동이 대부분 여기에 속합니다.
- 대상: 완전히 통합된 소프트웨어 시스템 전체
- 주요 수행자: QA 엔지니어
- 목표: 자동차 한 대가 완성된 후, 운전자의 입장에서 엑셀을 밟으면 앞으로 가는지, 방향 지시등을 켜면 불이 들어오는지 등 시스템 전체가 사용자의 요구사항을 만족하는지 종합적으로 평가합니다.
레벨 4: 인수 테스트 (Acceptance Test)
소프트웨어를 사용자나 고객에게 전달하기 전, 최종적으로 ‘이 제품을 인수해도 되는가?’를 확인하는 단계입니다. 실제 사용자가 실제 데이터를 가지고 사용 환경에서 테스트를 진행하며, 제품이 비즈니스 요구사항과 계약 조건을 충족하는지 판단합니다.
- 대상: 배포 직전의 소프트웨어 시스템
- 주요 수행자: 실제 사용자, 고객, 또는 이들을 대변하는 QA팀 (UAT: User Acceptance Test)
- 목표: “이 차를 우리가 주문한 사양대로 잘 만들었으니, 이제 돈을 지불하고 인수하겠습니다”를 결정하는 최종 관문입니다.
결론: 품질은 모두의 책임이다
QA와 테스팅은 다르지만, 결국 ‘더 나은 제품’이라는 하나의 목표를 향해 나아갑니다. QA가 아무리 훌륭한 프로세스를 만들어도, 테스팅을 통해 제품의 상태를 확인하지 않으면 의미가 없습니다. 반대로 테스팅으로 수백 개의 버그를 찾아내도, QA 활동을 통해 근본적인 원인을 개선하지 않으면 같은 버그는 계속 반복될 것입니다.
또한, 단위 테스트부터 인수 테스트까지 각 레벨의 테스트는 개발자, QA 엔지니어, 그리고 사용자 모두의 참여를 통해 완성됩니다. ‘품질은 특정 팀의 전유물이 아니라, 프로젝트에 참여하는 모두의 책임이다’라는 말을 기억하는 것이 좋은 SQA의 진정한 첫걸음일 것입니다.