QA vs QC

QA와 QC의 차이

품질 활동은 QA(Quality Assurance)와 QC(Quality Control)로 구분된다. QA는 단위·통합 테스트를 통해 자체적으로 만든 산출물을 보증하는 활동이고, QC는 알파·베타 테스트처럼 외부에서 만든 결과물을 검사하는 활동이다.

제조업에서 협력사 부품을 받아 검사하는 과정을 떠올리면 이해가 쉽다. QA가 ‘만들면서 보증’한다면, QC는 ‘받아서 검사’한다는 점에서 주체와 시점이 다르다.

과정과 결과를 함께 본다

QA의 특징은 과정(process)과 산출물(product)을 함께 본다는 데 있다. 즉 점검(Inspection)과 테스트(Test)를 병행한다.

결과만 확인하는 것이 아니라 ‘어떤 과정으로 만들어졌는가’까지 보증하므로, 같은 결함이라도 재발을 막을 수 있다. 검수 단계에서는 필수 산출물로 과정을 확인하고, 기능은 결함률(인수 테스트)로, 비기능은 성능·보안(시스템 테스트)으로 결과를 검증한다.

PM은 지침을 세운다

여기서 중요한 점은 PM이 직접 테스트를 수행하지 않는다는 것이다. PM의 역할은 어떤 테스트를 누가, 어떤 환경에서, 어떤 절차와 기법으로, 어느 커버리지까지 수행할지에 대한 지침을 세우는 것이다.

테스트 기법은 구조 기반·명세 기반·경험 기반의 세 갈래로 나뉘고 세부적으로는 여러 기법이 있는데, 그중 무엇을 적용할지 결정하는 것이 관리자의 일이다.

커버리지로 객관화한다

‘테스트를 수행했다’는 진술만으로는 근거가 부족하다. 일곱 개 모듈 중 네 개만 검증했다면 커버리지는 그 비율로 산정된다.

테스트 케이스의 정합성 자체가 부정확할 수 있어, 커버리지 지표가 RFP에 명시되기 시작했다. 금융권의 경우 초기 20% 수준에서 40%까지 상향되었다.

PM은 ‘우리 프로젝트의 커버리지는 어느 수준인가’를 지속적으로 점검해 품질을 객관적 수치로 통제해야 한다.

기법과 데이터 검증까지

테스트의 깊이는 기법 선택에서 갈린다. 경계값 분석이나 동등 분할 같은 명세 기반 기법은 적은 케이스로 많은 결함을 잡는 데 효과적이다.

인터페이스 테스트에서는 실제 의존을 대체하는 Mock 테스트를 활용하고, 데이터 마이그레이션 구간에서는 데이터 검증과 정제(불필요 데이터 정리)를 반드시 챙겨야 한다. 이 영역은 수행사가 기존 업무를 알지 못해 발주사가 함께 보아야 하는 곳이다.

코드 인스펙션 도구로 소스 단위 품질까지 점검하면 보증의 깊이가 더해진다.

발주사와 수행사의 PM은 다르다

테스트와 품질에서 발주사의 PM과 수행사의 PM은 역할이 다르다. 수행사는 자신이 만든 것을 보증(QA)하는 데 집중하지만, 발주사는 그 결과를 검사(QC)하고 운영 관점의 위험까지 챙겨야 한다.

데이터 마이그레이션, 데이터 검증과 정제, 인터페이스의 Mock 테스트처럼 수행사가 기존 업무를 알지 못해 놓치기 쉬운 영역을 발주사 PM이 함께 보아야 한다. 결국 품질은 한쪽의 책임이 아니라, 만드는 쪽과 받는 쪽이 과정과 결과를 함께 보며 완성하는 것이다.

PM이 직접 테스트하지는 않더라도, 무엇을 어느 깊이로 검증할지 설계하고 그 결과를 객관적 수치로 통제하는 일은 온전히 PM의 몫이다.