이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 테스트 자동화 커버리지를 처음 체계적으로 측정해봤습니다. pytest-cov로 커버리지를 측정하고 CI에 연결해서 PR마다 커버리지 리포트가 자동으로 생성되게 했습니다. 커버리지만 보다가 플래키 테스트(비결정적으로 실패하는 테스트)가 더 큰 문제라는 걸 알게 됐는데, 매번 결과가 달라지는 테스트가 팀 신뢰도를 깎는다는 걸 경험했습니다. 실패율을 추적하려고 테스트 이름과 결과를 JSON으로 저장하고 히스토리를 볼 수 있는 간단한 대시보드를 만들었습니다. 가시화는 별도 도구 대신 HTML 파일로 만들었는데, 팀원들이 쉽게 접근할 수 있는 형태가 더 중요하다는 걸 배웠습니다.
커버리지 숫자보다 플래키 테스트 제거가 팀 CI 신뢰도에 더 직접적인 영향을 주는 자리라는 걸 그때 알았습니다.
플래키 테스트를 발견하고 나서 어떻게 처리할지 기준을 만들어야 한다는 것을 경험했습니다. 처음에는 플래키 테스트가 실패할 때마다 재실행하는 방식으로 대응했는데, 이것은 근본 해결이 아니라 문제를 가리는 방식이었습니다. 이후 플래키 테스트를 별도 태그로 분류해 일반 CI에서는 실행하지 않고 별도 파이프라인에서만 실행하도록 격리했습니다. 이렇게 하면 CI가 안정적으로 유지되면서 플래키 테스트를 수정할 시간을 벌 수 있었습니다. 수정 우선순위는 비즈니스 흐름에서 중요한 경로를 커버하는 테스트를 먼저 고쳤습니다.
커버리지 숫자가 높아도 중요한 결제 흐름을 커버하는 테스트가 플래키하면 신뢰도는 낮다는 것을 이때 이해했습니다. 격리와 수정을 분리해서 접근하니 팀 CI 신뢰도가 회복되는 데 2주가 걸렸습니다. 테스트 품질 개선은 지표 수집에서 끝나지 않고 무엇을 먼저 고칠지 결정하는 데서 완성된다는 것을 이 경험에서 배웠습니다.
커버리지를 측정하는 것보다 추세가 나빠지는 것을 조기에 발견하는 것이 더 중요하다는 것을 경험했습니다. 라인 커버리지만 보면 새 코드가 추가됐을 때 전체 퍼센트가 내려가는지 올라가는지밖에 알 수 없었는데, 브랜치 커버리지를 추가로 추적하니 조건문의 분기가 제대로 테스트됐는지까지 볼 수 있었습니다. Codecov를 CI에 연동해서 PR마다 커버리지 변화량을 리포트하게 했는데, 새 코드에서 커버리지가 일정 수준 이하로 떨어지면 PR에 경고가 붙게 됐습니다. 이 구조에서 테스트 없이 복잡한 조건문이 추가되는 패턴을 조기에 감지할 수 있었습니다. 한계도 있었는데, 커버리지가 높아도 중요한 경계 조건이 빠져 있는 경우는 숫자로는 알 수가 없었습니다. 커버리지 수치보다 "이 비즈니스 규칙이 테스트됐는가"를 기준으로 삼는 것이 더 실질적이라는 것을 배웠습니다.
커버리지 지표는 테스트의 완성도가 아니라 회귀를 조기에 발견하기 위한 신호로 써야 한다는 것을 이 경험에서 얻었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 마이클 품질보증 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.