답변.

질문의 배경:

자동화 테스트 커버리지(test coverage)는 테스트 품질의 가장 중요한 지표 중 하나입니다. 커버리지 전략은 자동화 발전 초기부터 등장했으며, 이때 테스트 수가 급격히 증가하면서 수동으로 커버리지 없는 시나리오를 추적하는 것이 불가능해졌습니다. 이후 접근 방식은 직관적에서 엄격한 분석적 방법으로 진화하였고, 요구 사항 추적, 코드 커버리지 도구 및 테스트 피라미드 관리 기법이 포함되었습니다.

문제:

고르게 인지된 자동화 테스트 커버리지를 확립하는 것은 다양한 테스트 유형(단위, 통합, E2E), 실행 속도, 유지 관리 비용 및 ROI와 누락된 결함에 대한 위험을 균형 있게 고려해야 하기 때문에 복잡한 작업입니다.
커버리지 비율이 높다고 해서 모든 부분이 보호된다고 잘못 인식하는 경우가 많습니다. 이로 인해 비즈니스 논리 또는 사용자 시나리오의 "구멍"이 무시됩니다.

해결책:

다양한 기법의 조합을 사용해야 합니다: 코드 커버리지, 추적 행렬, 위험 기반 테스트.
실제 우선순위를 이해하기 위해 개발 팀 및 비즈니스와 전략을 조율하는 것이 중요합니다.
핵심 관행은 커버리지의 정기 감사(수동 및 자동), 우선순위 조정 및 "100% 코드 커버리지"라는 개념을 포기하고 더 의미 있는 시나리오 및 위험 기반 접근법으로 전환하는 것입니다.

주요 특징들:

여러 유형의 커버리지를 사용: statement, branch, condition, feature, requirements coverage.
최대 완전성을 위해 추적 행렬 및 코드 커버리지 기법을 통합합니다.
전략을 정기적으로 검토하고 자동 보고서를 생성합니다.

함정 질문들.

코드의 높은 커버리지가 제품의 품질을 완전히 보장할 수 있나요?

아니요, 그렇지 않습니다. 높은 코드 커버리지 비율(예: 95%)은 종종 코드의 일부만이 테스트되었음을 의미하지만, 이는 비즈니스 논리나 사용 시나리오의 정확성을 보장하지 않습니다.

항상 100% 코드 커버리지를 추구해야 할까요?

아니요. 100% 커버리지를 목표로 하면 유지 관리 비용이 증가하고, 때때로 의미 없거나 도달할 수 없는 부분을 위해 테스트를 작성해야 할 수 있습니다. 위험과 이점을 기반으로 우선 순위를 정하는 것이 더 좋습니다.

신뢰할 수 있는 커버리지를 보장하기 위해 단위 테스트만 사용하는 것으로 충분할까요?

아니요. 단위 테스트는 통합 시나리오와 구성 요소 간의 상호 작용을 커버하지 않습니다. 테스트 피라미드에 따라 다양한 유형의 테스트를 조합해야 합니다.

일반적인 실수 및 안티 패턴

높은 코드 커버리지 비율에 대한 맹목적인 욕망
사용자 시나리오와 요구 사항의 커버리지를 무시
커버리지 우선순위 결정에 비즈니스 팀의 참여 부족
모든 테스트 유형이 동일: 단위만 또는 E2E만

사례 연구

부정적인 사례

팀은 각 pull request에 대해 90% 테스트 커버리를 강제하는 파이프라인을 구현했습니다. 결과적으로 "빈" 테스트가 등장하여 줄을 커버했지만 시나리오는 커버하지 않았습니다. 비즈니스 논리의 오류가 발견되지 않았습니다.

장점:

형식적인 기준을 빠르게 충족함
더 많은 테스트를 작성하려는 동기 부여

단점:

테스트가 실제 버그를 잡지 못함
기술 부채가 증가하고 팀이 테스트에 대한 신뢰를 잃음

긍정적인 사례

팀은 추적 행렬과 위험 기반 테스트를 활용하여 커버리지 전략을 수립했습니다: 가장 중요한 기능은 E2E로 커버되고, 덜 중요한 기능은 단위 테스트로 커버됩니다. 매월 시나리오별로 커버리지 감사를 수행합니다.