QA QC 차이

한 사람이 둘을 겸하면 왜 구멍이 같나

만든 사람은 빠진 것을 잘 안 본다. 케이스 작성자와 방식 점검자를 나누는 것이 최소다.

개발자가 자기 화면의 케이스를 쓰고 돌리면, 행복한 경로만 남는다. 전담 시험자가 케이스를 써도, 그 사람이 시험 계획까지 승인하면 같은 편향이 남는다.

QA vs QC를 직함으로 나누기 어려우면 산출물이라도 나눈다. 케이스와 수행 기록은 A, 시험 계획과 커버 리뷰는 B.

B가 A의 상사일 필요는 없다. 같은 주간 다른 눈이면 된다.

눈이 하나면 검수 전 리허설도 같은 구멍으로 통과한다.

QC가 닫는 것, QA가 닫는 것

QC는 결함과 조치. QA는 계획, 추적, 잔여 위험. 둘 다 합격이어야 고객 검수로 간다.

QC의 닫힘은 이번 빌드의 결함이 조치됐거나 잔존으로 분류된 상태다. QA의 닫힘은 그 빌드가 시나리오와 비기능과 회귀를 돌릴 계획이 있었고, 실제로 돌렸는지 추적되는 상태다.

QC만 닫히면 잘 잰 일부다. QA만 닫히면 계획만 좋은 상태다.

고객 검증(Validation)은 그 다음에 연다. 순서를 건너뛰면 현업이 QC 역할을 대신한다.

현업이 QC를 대신하는 검수는 감정의 검수다.

애자일 스프린트에서 이 구분이 사라지나

사라지지 않는다. 스프린트 리뷰가 Validation에 가깝고, 정의된 완료가 QA에 가깝다.

애자일 현장에서 QA를 문서주의로 미루는 말이 있다. 짧은 주기일수록 방식 점검이 더 필요하다.

매 스프린트 완료 정의에 시나리오 한 줄, 회귀 범위, 비기능 측정 여부를 넣는다. 리뷰는 현업이 그 한 줄을 보는 자리다.

리뷰에 데모만 있고 완료 정의가 없으면, 빠른 QC만 있는 팀이다. 빠른 QC는 빠른 재작업을 만든다.

커버리지 숫자를 품질로 읽지 마라

라인 커버리지 80%는 경로의 일부다. 업무 시나리오 40개 중 몇 개가 돌았는지가 검수 숫자다.

RFP에 커버리지 80%가 적히면 도구 숫자로 맞추기 쉽다. 그 80%가 시나리오 40개와 무관하면 검수는 그대로 위험하다.

QA가 볼 숫자는 시나리오 수행률과 비기능 측정 여부다. QC가 볼 숫자는 열린 결함과 재시험 횟수다.

두 숫자를 한 그래프에 섞어 올리면 주간보고는 예쁘고 내용은 없다. 그래프를 둘로 나눈다.

외주 시험에서 발주가 남길 한 줄

시나리오 선정권은 발주에 둔다. 수행사가 고른 케이스는 쉬운 경로가 많다.

시험 외주를 줘도 시나리오 선정까지 넘기면 발주는 눈을 판 것이다. 선정권과 합격 기준만 남겨도 QA 역할의 반은 남는다.

나머지 반은 주 1회 커버 리뷰다. 리뷰 없이 결함 건수만 받으면, 건수가 줄어드는 것이 품질 향상인지 분류 변경인지 모른다.

분류 변경으로 줄어든 건수는 검수 날 되살아난다. 외주 주간보고에 열린 결함, 재시험 횟수, 시나리오 수행률 세 칸을 요구하면 분류 장난이 드러난다.

세 칸이 없는 보고는 건수 그래프만 예쁘다.