실패율을 집요하게 줄여낸 Android UI 자동화

29CM QA 팀은 앱 배포 전 BVT(Build Verification Test) 용도로 Android UI 자동화를 운영했고, 2023년 하반기에는 시나리오 완성 이후에도 다수의 실패가 발생해 유지보수 비용이 커졌다.

가장 먼저 부딪힌 문제는 빌드 과정에서 id 누락이나 path 변경이 생기면서 기존 탐색 요소가 깨지는 일이었다. 이 경우에는 변경된 path를 바로 반영하거나, 누락된 id가 있으면 개발팀에 확인해 재빌드한 뒤 다시 자동화를 수행했다.

더 오래 끌었던 문제는 WebView 전환 시 window handler가 올바르게 잡히지 않는 현상이었다. 네이티브에서 웹뷰로 넘어갈 때 마지막 핸들러만 쓰면 된다고 봤지만, 실제로는 여러 핸들러가 중첩된 상태로 쌓였고 시나리오마다 위치도 달라져서 단순한 규칙으로는 제어가 되지 않았다.

이 문제를 줄이기 위해 여러 번 접근법을 바꿨다.

• 마지막 핸들러가 아니라 마지막에서 2번째 핸들러를 쓰는 방식 시도
• 시나리오별로 고정된 handler 위치를 지정하는 방식 시도
• 일부 시나리오 후 앱 재실행으로 handler 히스토리를 초기화하는 분리 작업 시도

이 과정에서 실패율은 내려갔지만, 시나리오가 중간에 실패하면 다시 handler 제어가 불가능해지는 문제가 남았고, 슬랙 알림도 최대 6개까지 쪼개져 노출되는 부작용이 생겼다. 결국 시나리오를 더 독립적으로 분리하고, 종료 시 앱을 재실행해 히스토리를 지우며, 알림 구조도 다시 하나로 합치는 방향으로 구조 리팩토링을 진행했다.

또 다른 축은 CI/CD 파이프라인과 로컬 실행의 차이였다. STF로 로컬에서는 잘 돌던 시나리오가 파이프라인에서는 화면 요소 탐색 실패나 앱 종료로 이어졌고, 특히 최초 시나리오와 화면 전환 직후에 문제가 자주 발생했다.

원인은 드라이버가 화면 로딩 완료보다 요소 탐색을 먼저 시도하는 속도 차이였다. 이를 줄이기 위해 액션 사이에 잠시 대기 시간을 넣어 동작 속도를 조절했고, 로컬 실행, STF 연결, 실제 연결 PC의 3단계로 확인하면서 문제 지점을 다시 검증하는 절차를 만들었다.

이런 반복적인 수정과 검증을 거치며 초기보다 fail률을 현저히 낮췄고, 현재도 유지보수와 시나리오 보강, 실행 시간 단축을 계속 추적하고 있다.