이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 크로스 브라우저 테스트를 처음 제대로 해봤을 때, 크롬에서 멀쩡하던 레이아웃이 모바일 Safari에서 깨지는 문제를 겪었습니다. 그때부터 플랫폼마다 렌더링 엔진이 다르다는 점을 실제로 체감했고, CSS 속성 일부는 caniuse.com 지원 표를 확인하는 습관이 생겼습니다. 모바일 테스트에서 특히 주의하는 건 터치 이벤트와 클릭 이벤트의 발화 순서인데, 이를 혼용하면 의도치 않은 동작이 생기는 경우가 있었습니다.
overflow: hidden으로 숨겨진 콘텐츠가 화면이 좁아지면 접근 불가 상태가 되는 문제도 직접 경험했습니다. 이후로 QA 단계에서 디바이스 다양성을 먼저 체크리스트로 정의하는 것이 테스트 공수를 오히려 줄여준다는 걸 알게 됐습니다.
모바일 테스트를 수동으로 진행하다 보면 어떤 기기에서 버그가 나왔는지 기억에만 의존하게 되는 문제가 생겼습니다. 같은 문제가 몇 달 뒤 다른 기기에서 다시 발견된 적도 있었습니다. 재발 방지를 위해 팀과 함께 커버리지 기준 기기 조합 목록을 만들었습니다. Android는 OS 버전별 2~3대, iOS는 직전 2세대 기기를 최소 커버 대상으로 정하고, 발견된 버그는 해당 조합을 체크리스트에 반영하는 방식으로 이어갔습니다.
BrowserStack 같은 클라우드 기기 팜의 필요성도 이 시점에 이해했습니다. 실기기로 모든 조합을 커버하는 것은 비용이 크고, 팀이 커질수록 다 사기도 어렵기 때문입니다. 한 번 발견된 버그가 재발하지 않으려면, 버그가 발생한 환경 조건을 시스템에 남겨야 한다는 것을 이 경험에서 배웠습니다.
모바일 앱 테스트에서 Wi-Fi 환경에서만 검증하다 3G·LTE 전환 구간에서 오류가 생긴 경험이 있습니다. 지하철에서 앱을 쓰다 네트워크가 끊기는 순간 크래시했는데, 개발 환경에서는 재현이 되지 않았습니다. 이후 네트워크 조건 시뮬레이션을 테스트 항목에 추가했습니다. iOS 개발자 도구의 Network Link Conditioner로 3G 속도와 패킷 손실을 흉내 냈고, 네트워크 끊김·재연결 시 앱이 정상 회복하는지를 별도로 검증했습니다. 확인해보니 재시도 로직이 없어 최초 요청 실패 시 빈 화면을 보여주는 것이 원인이었습니다. 대기 화면과 재시도 버튼을 추가한 뒤 해당 시나리오는 안정화됐습니다.
모바일 테스트는 기능 동작뿐 아니라 네트워크 불안정 상황까지 체크리스트에 포함해야 한다는 것을 직접 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 라인 품질보증 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.