QA 및 스프린트 병목 시뮬레이터: 개발자가 테스트 역량을 앞지를 때

업계 경영 분석

공식 및 방법론 설계도

이 모델은 정상 상태의 월 단위로 계산합니다. 개발자 산출은 개발자 수에 각자의 기능 수를 곱한 값이고, QA 역량은 테스터 수에 각자의 기능 수를 곱한 값입니다. 출시되는 기능은 둘 중 작은 쪽입니다. 대기열은 매달 그 차이만큼 커지며, 6개월 기간의 평균 대기열은 그 증가분의 6배의 절반입니다. 지연 비용은 평균 대기열에 지연 비용을 곱한 값입니다. 개발자는 대기 중인 기능 하나당 시간의 1%를 컨텍스트 전환으로 잃으며 상한은 20%입니다. 새어 나가는 결함은 과부하와 함께 늘어납니다.

개발자 산출

P = 개발자 × 개발자당 기능

매달 완료해 QA에 넘기는 기능 수입니다.

출시된 기능

S = min(P, 테스터 × 테스터당 기능)

파이프라인은 테스트가 검증한 것만 릴리스할 수 있습니다.

대기열

Q = max(0, P − 역량) × 3

대기열이 선형으로 커지므로 6개월 기간 동안 대기하는 평균 기능 수입니다.

유출 비용

E = S × (3% + 15% × 과부하) × 4,000

QA가 과부하될수록 고객에게 도달하는 결함이 늘며, 건당 비용은 4,000입니다.

파이프라인 결과

Net = S × 가치 − 인건비 − Q × 지연 비용 − E − 컨텍스트 전환 비용 − QA 초과근무

월 결과입니다. 손익분기 부하는 이 값이 0이 되는 지점입니다.

연쇄 탄력성

개발자 산출과 QA 역량 사이의 격차는 대기열, 지연, 컨텍스트 전환, 유출을 동시에 움직이므로 가장 민감한 요소입니다. 기능당 가치는 출시 산출에 곧바로 비례합니다. 인건비는 선형이며 기준선처럼 작용하므로, 테스터 한 명을 추가하면 그 비용의 몇 배로 되돌아오는 경우가 많습니다.

실제 사례 세 가지

업계 벤치마크 매트릭스

변수와 레버

이 시뮬레이터 사용 방법

1. 1개발자 수와 각자 한 달에 끝내는 기능 수를 입력하세요.
2. 2테스터 수와 각자 검증할 수 있는 기능 수를 설정하세요.
3. 3출시된 기능의 가치와 기능당 월 지연 비용을 추정하세요.
4. 4다섯 개의 도미노를 보고 QA 부하가 100%를 넘는 시점을 확인하세요.
5. 5평행 우주 탭에서 테스터 추가 계획과 비교하고 링크를 공유하세요.

피해야 할 실수

• 개발자를 끝낸 기능 수로 평가하는 것. 테스트를 기다리는 작업은 산출이 아니라 재고입니다.
• 긴 기간에 걸쳐 평균을 내는 것. 매달 커지는 대기열은 초반에는 작아 보이고 나중에는 커 보입니다.
• 테스터를 줄여야 할 비용으로 취급하는 것. 병목 상황에서는 테스터의 역량이 파이프라인에서 가장 값진 역량입니다.
• 지연 비용만 세는 것. 새어 나간 버그와 컨텍스트 전환이 그것을 넘어서는 경우가 많습니다.

자주 묻는 질문