프로젝트 막바지, PM이나 상사가 QA에게 묻습니다. “테스트는 얼마나 진행되었나요? 이제 릴리즈해도 괜찮을까요?”
이때 “많이 테스트했습니다” 또는 “거의 다 한 것 같습니다”와 같이 모호하게 대답한다면, 전문성을 의심받을 수 있습니다. 테스트의 진행 상황과 충분성을 객관적인 ‘숫자’로 증명하는 지표, 그것이 바로 ‘테스트 커버리지(Test Coverage)’입니다.
Q. 테스트 커버리지, 정확히 무엇인가요?
‘테스트 커버리지’는 준비된 테스트 케이스가 ‘전체 요구사항’ 또는 ‘전체 소스 코드’ 중 얼마나 넓은 범위를 검증했는지를 나타내는 품질 측정 지표입니다.
- 비유: 건강검진과 같습니다. ‘머리부터 발끝까지’ 모든 항목을 검사했다면 커버리지가 100%에 가깝고, ‘혈액검사’만 했다면 커버리지가 낮은 것입니다. 커버리지가 낮다는 것은, 아직 검사하지 않은 곳에 질병(버그)이 숨어있을 확률이 높다는 의미입니다.
Q. 테스트 커버리지는 어떻게 계산하나요?
크게 두 가지 관점에서 측정할 수 있습니다.
1. 요구사항 기반 커버리지 (블랙박스 관점)
QA 엔지니어가 가장 흔하게 사용하는 방법입니다.
- 계산법:
(실행한 테스트 케이스 수 / 전체 테스트 케이스 수) x 100 - 의미: 전체 기능 요구사항 중 몇 퍼센트를 테스트했는지를 나타냅니다. 예를 들어, 테스트 케이스가 총 100개인데 80개를 실행했다면, 커버리지는 80%입니다.
- 장점: 이해하기 쉽고, 현재 테스트 진행률을 직관적으로 파악할 수 있습니다.
2. 코드 커버리지 (화이트박스 관점)
개발자나 SDET가 자동화 도구를 사용하여 측정합니다.
- 계산법:
(실행된 코드 라인 수 / 전체 코드 라인 수) x 100 - 의미: 우리의 테스트가 실제 소스 코드의 몇 퍼센트를 실행시켰는지를 나타냅니다.
- 장점: 아무도 실행해보지 않은 ‘죽은 코드(Dead Code)’나 테스트되지 않은 로직 분기를 정확하게 찾아낼 수 있어, 잠재적인 버그의 위험을 파악하는 데 매우 효과적입니다.
Q. “커버리지 100%면 버그가 없는 건가요?”
아닙니다. 이것이 바로 ‘커버리지의 함정’입니다.
- 커버리지 100%의 의미: “적어도 모든 코드 라인을 한 번씩 실행은 해봤다” 또는 “모든 테스트 케이스를 한 번씩 수행은 해봤다”는 뜻입니다.
- 함정:
- 테스트 케이스 자체의 품질이 낮거나, 요구사항 분석이 잘못되었다면 커버리지가 100%여도 치명적인 버그를 놓칠 수 있습니다.
- 모든 코드 라인을 실행했더라도, 특정 데이터 조합이나 순서에서만 발생하는 복잡한 버그는 발견하지 못할 수 있습니다.
결론적으로, 테스트 커버리지가 낮으면 품질이 낮다고 확신할 수 있지만, 커버리지가 높다고 해서 품질이 높다고 보장할 수는 없습니다.
결론: 품질을 위한 ‘나침반’
테스트 커버리지는 품질을 보장하는 ‘만능 열쇠’가 아닙니다. 하지만 우리에게 중요한 정보를 알려주는 ‘나침반’ 역할을 합니다.
- 우리가 어디에 있는지 알려줍니다: 현재 테스트가 얼마나 진행되었고, 목표까지 얼마나 남았는지 객관적으로 보여줍니다.
- 우리가 어디로 가야 할지 알려줍니다: 테스트가 부족한 영역, 즉 커버리지가 낮은 부분을 명확히 보여주어 다음에 무엇을 테스트해야 할지 방향을 제시합니다.
테스트 커버리지를 맹신해서는 안 되지만, 이를 현명하게 활용하여 테스트의 약점을 보완하고, 이해관계자들과 객관적인 데이터를 기반으로 소통하는 것은 모든 전문 QA 엔지니어가 갖춰야 할 중요한 역량입니다.