이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 자동화 테스트와 수동 QA를 병행하는 구조를 처음 경험했습니다. 자동화는 회귀 케이스와 경계값 검증에 강했는데, UX 흐름이나 모바일 터치 반응처럼 사람이 직접 써봐야 발견되는 문제는 자동화로 잡기 어려웠습니다. 수동 QA 담당자와 협업할 때는 테스트 케이스 문서를 공유하고 자동화가 커버하는 범위를 명시해뒀는데, 이렇게 하니 중복 작업이 줄고 수동 테스터가 집중해야 할 영역이 명확해졌습니다.
자동화와 수동 테스트는 대체 관계가 아니라 서로 다른 리스크를 커버하는 보완 관계라는 걸 이 경험에서 배웠습니다. 지금도 테스트 전략 설계 시 자동화로 못 잡는 케이스를 먼저 식별하는 방향으로 접근합니다.
수동 QA 담당자와 협업하면서 상대가 원하는 것을 제대로 파악하지 못했던 초기 실수가 있습니다. 자동화 테스트로 어느 부분을 커버한다고 설명했는데, QA 담당자가 궁금했던 건 커버 범위가 아니라 자동화 테스트가 실패했을 때 어떻게 알 수 있는지였습니다. 알림이 없으면 자동화 테스트가 실패해도 QA 담당자가 모르고 중복 테스트를 하게 된다는 것을 이때 알았습니다. CI 실패 시 슬랙 알림이 가도록 설정하고 실패 원인을 요약한 리포트 링크를 함께 보내게 했습니다. 양보한 부분도 있었는데, QA 담당자가 특정 플로우를 매번 수동으로 확인하고 싶다고 하면 자동화가 이미 있더라도 그 흐름은 수동 체크리스트에도 남겨두는 방식을 받아들였습니다. 자동화가 완벽하지 않다는 것을 상대도 알기 때문에 이중 확인이 주는 안도감을 무시할 수 없다는 것을 이해했습니다.
협업에서는 내가 만든 것이 상대에게 어떻게 보이는지를 먼저 파악해야 한다는 것을 이 경험에서 배웠습니다.
자동화 테스트와 수동 QA의 경계를 명확히 정의하지 않으면 서로 상대방이 커버할 거라 기대하는 공백이 생긴다는 것을 경험했습니다. 자동화가 안 되는 영역, 예를 들어 신규 기기에서 처음 실행할 때의 UX나 여러 단계를 넘나드는 탐색적 테스트는 체계적으로 수동 QA에 전달하는 절차가 없었습니다. 이후 릴리스마다 자동화 커버 범위와 수동 테스트 필요 영역을 명시한 테스트 계획서를 같이 작성하는 방식을 제안했습니다. QA 담당자가 어디서 시작해야 할지 알 수 있고, 자동화 개발자도 어떤 영역이 수동 의존인지 인식할 수 있었습니다. 이 과정에서 QA 담당자의 관점이 자동화 테스트 설계를 개선하는 데 도움이 된다는 것도 배웠습니다. 수동 QA가 자주 발견하는 패턴은 자동화로 흡수할 수 있는 신호였습니다.
자동화와 수동 QA 협업은 역할 분리가 아니라 서로의 관점을 흡수해 테스트 전략을 개선하는 과정이라는 것을 이 경험에서 얻었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 마이클 품질보증 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.