이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
온오프라인 서비스 테스트 자동화 전략에서 가장 먼저 한 것은 자동화 대상의 우선순위를 정하는 것이었습니다. 전체 케이스를 한꺼번에 자동화하려 하면 유지비용이 급증하기 때문에, 회귀 가능성이 높고 수동으로 반복 실행되는 흐름부터 자동화했습니다.
온라인 채널은 UI 자동화와 API 레벨 자동화를 레이어별로 구성했습니다. UI 테스트는 시각적 흐름 검증에, API 테스트는 비즈니스 로직과 통합 동작 검증에 초점을 맞추면서 레이어별로 커버리지를 나눴습니다.
오프라인 채널 연동 테스트는 실제 디바이스나 POS 에뮬레이터를 활용했습니다. 온라인 테스트 환경과 달리 하드웨어 의존성이 있는 경우 모킹 한계가 있어, 핵심 흐름은 실 디바이스에서 정기적으로 검증하는 방식을 병행했습니다.
테스트 자동화 파이프라인이 자리를 잡고 나서 가장 큰 문제가 된 건 간헐적으로 실패하는 테스트였습니다. 원인을 보지 않고 재실행하면 통과하는 케이스가 늘면서 팀이 테스트 결과를 신뢰하지 않게 됐습니다. 그래서 제가 Flaky Test를 별도 태그로 분류하고 별도 스테이지에서 돌리는 구조를 직접 만들었습니다.
pytest-rerunfailures로 최대 2회 재시도를 설정하고, 재시도 후에도 실패한 케이스는 자동으로 이슈가 생성되도록 연결했습니다. 2주 동안 추적하니 Flaky 원인의 70%가 외부 API 타임아웃과 테스트 간 공유 상태였습니다. 원인별로 고치고 나니 파이프라인 실패율이 눈에 띄게 줄었고, 팀이 CI 결과를 다시 신뢰하기 시작했습니다. 테스트 전략에서 Flaky Test 관리를 별도 공정으로 두지 않으면 쌓인다는 걸 그때 배웠습니다.
테스트 커버리지를 90% 이상으로 올리는 것을 목표로 잡았다가 오히려 의미 없는 테스트가 늘어난 경험이 있습니다. 숫자를 채우려다 보니 실제 비즈니스 로직보다 단순한 getter·setter 위주로 케이스가 추가됐고, 정작 중요한 엣지 케이스는 빠진 상태였습니다. 그 분기에 고객 영향이 있는 버그가 3건 발생했는데, 모두 커버리지가 높았던 모듈에서 나왔습니다. 이후 지표를 테스트를 얼마나 가졌나에서 테스트가 실제 결함을 얼마나 잡았나로 바꿨습니다. QA 단계에서 발견한 결함 중 자동화 테스트가 미리 잡은 비율을 매 스프린트마다 측정했습니다.
처음 두 스프린트는 30%였는데, 중요 시나리오 위주로 케이스를 재설계하니 60%대로 올랐습니다. 커버리지는 수단이지 목표가 아니라는 걸 수치로 확인한 경험이었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.