측정·검토·품질 개선

“버그가 10개 줄었다”는 보고는 이전에 몇 개를 어떤 방법으로 찾았는지 알려 주지 않습니다. 지표는 질문에 답하기 위해 관찰값을 정의하고 계산한 값입니다. 질문과 분모를 빼면 같은 숫자로 다른 결론을 내릴 수 있습니다.

지표의 정의부터

결함 밀도를 비교하려면 발견 결함의 정의·기간·검사 방법과 규모 단위를 맞춥니다. 테스트 통과율을 비교하려면 어떤 사례를 실행했는지, 사용자 과업 완료율을 비교하려면 어떤 참여자·과업·환경을 사용했는지에 관한 정보가 필요합니다. 코드 줄 수와 결함 수를 동일한 품질로 해석하지 않습니다.

examples/ch9.mjs의 completionRate는 완료 / 시도를 계산하고 0 이하 분모나 불가능한 완료 수를 거절합니다. 가상 자료 8/10은 0.8입니다. 이 값은 관측한 연구 결과가 아니라 계산용 자료라고 출력합니다.

const first = { completed: 8, attempted: 10 };
const second = { completed: 80, attempted: 100 };
console.log(first.completed / first.attempted === second.completed / second.attempted);

같은 0.8이어도 표본과 사용자 구성·과업 난도·측정 환경이 다르면 같은 확실성을 가진 결과가 아닙니다. 비율 하나만으로 모든 사용자의 성공을 추정하지 않습니다. 측정 대상을 지표가 좋은 숫자로 보이게 바꾸면 개선 증거가 약해집니다.

실행 전 검토의 역할

워크스루는 작성자가 산출물을 설명하며 질문·피드백을 받는 검토입니다. 인스펙션은 역할·준비·결함 기록 등 더 체계적인 절차를 갖는 검토로 설명할 수 있습니다. 정적 분석은 코드를 실행하지 않고 규칙·흐름·타입 등의 문제를 도구로 찾습니다. 각각의 명칭보다 실제 절차와 발견 범위를 기록합니다.

모임 코드를 검토할 때 “이름이 예쁜가?”보다 R3/R4 우선순위, 실패 상태 보존, 복원 자료의 중복 ID 처리, 오류 안내와 계약 일치를 확인합니다. 실행 테스트는 이 검토를 대체하지 않고 검토도 런타임 오류를 모두 찾아 주지는 않습니다.

검토 질문: CLOSED에서 취소하면 모임이 다시 열리는가?
근거: R6은 취소 후 마감 상태 유지.
확인 대상: cancel 구현, 안내 문구, 회귀 테스트.
발견 기록: 문구는 재개 안내, 코어는 CLOSED 유지 → 문구 수정 필요.
완료 증거: 문구 검토와 마감 취소 시나리오 재검증.

프로세스 성숙도는 다른 질문

원자료의 CMM은 역사적으로 초기·반복·정의·관리·최적화 수준으로 조직의 프로세스 발전을 설명합니다. 후속 CMMI의 용어와 판본을 CMM의 표에 그대로 섞지 않습니다. SPICE와 ISO/IEC 15504의 프로세스 평가도 역사적 맥락과 후속 ISO/IEC 330xx 계열을 구별합니다. 특정 조직의 평가를 수행하려면 채택한 모델·판본·평가 범위와 증거를 별도로 확인해야 합니다.

프로세스 개선의 목적은 표를 외우는 것이 아니라 재현 가능하게 일하고 결과를 관찰해 개선하는 것입니다. “요구 검토에서 정책 충돌을 찾는다→회귀 사례를 추가한다→다음 변경의 재발 여부를 본다”가 작은 개선 반복입니다. 조직 수준의 인증·평가와 이 교재의 코어 테스트 통과는 서로 다른 증거입니다.

독립 문제: 좋은 숫자가 만든 나쁜 선택

테스트 통과율을 높이려고 실패한 저장 복원 테스트를 실행 목록에서 제외했습니다. 보고된 통과율은 100%가 됐습니다. 무엇이 잘못됐으며 보고를 어떻게 바꿔야 할까요?

개선 기록은 변경 기준선에 묶어 다음 담당자가 같은 증거를 찾을 수 있게 합니다.