개념
웹에는 없는 "앱의 상태"
모듈 13(레슨 7)에서 배운 것처럼 Appium은 웹 자동화 표준을 재사용하지만, 모바일 앱은 웹 페이지와 근본적으로 다른 특성이 있다 — 앱은 화면에 보이지 않을 때도 계속 존재한다. 웹 브라우저 탭을 닫으면 그 페이지는 그냥 사라지지만, 앱을 홈 버튼으로 빠져나가도 앱은 메모리에 남아 백그라운드에서 대기한다.
앱 생명주기(App Lifecycle)
실행되지 않음(Not Running)
→ 포그라운드(Foreground) — 화면에 보이고 조작 가능
→ 백그라운드(Background) — 화면엔 안 보이지만 메모리에 남아있음
→ 일시 중단(Suspended) — 완전히 멈춤, 필요시 OS가 강제 종료모듈 9(레슨 4)에서 배운 프로세스 개념이 여기서 다시 등장한다 — 앱을 백그라운드로 보냈다가 다시 열었을 때, 정확히 하던 작업이 이어지는지, 아니면 처음부터 다시 시작되는지는 테스트해야 할 중요한 지점이다.
인터럽트(Interrupt) 상황
모바일 기기는 앱 사용 도중 예고 없이 끼어드는 일들이 일상적이다.
- 전화가 걸려온다
- 다른 앱의 알림이 화면 위로 뜬다
- 배터리 부족 경고가 뜬다
- 화면이 자동으로 잠긴다
- Wi-Fi에서 모바일 데이터로 네트워크가 전환된다모듈 5(레슨 6)에서 배운 "순서 바꾸기, 중간에 멈추기" 같은 탐색적 테스팅 기법이 모바일에서는 일상적으로 일어나는 정상 시나리오로 격상된다. "결제 진행 중 전화가 걸려오면 어떻게 되는가?"는 예외적인 엣지 케이스가 아니라, 반드시 확인해야 하는 핵심 시나리오다.
왜 이게 특히 중요한가
> "장바구니에 상품을 담고 결제 정보를 입력하던 중 전화가 걸려왔다.
> 통화를 마치고 앱으로 돌아왔더니 입력했던 정보가 전부 사라져있었다."이런 결함은 기능 테스트(모듈 1~10)만으로는 절대 못 잡는다 — "결제 폼이 정상적으로 입력된다"는 것과 "인터럽트 후에도 그 상태가 유지된다"는 것은 완전히 다른 검증이다.
상태 저장과 복원
앱이 인터럽트나 백그라운드 전환에서 살아남으려면, 개발자가 현재 상태를 저장하고, 다시 돌아왔을 때 복원하는 로직을 갖춰야 한다. QA가 확인해야 할 질문은 이렇다.
- 백그라운드로 갔다가 몇 초 뒤 돌아오면 상태가 유지되는가?
- 백그라운드에 오래(예: 몇 시간) 있다가 돌아오면 어떻게 되는가?
(OS가 메모리 확보를 위해 앱을 강제 종료했을 수도 있다)
- 강제 종료 후 재실행 시, 사용자가 하던 작업이 얼마나 복구되는가?실무에서 왜 필요한가
"기능 테스트는 다 통과했는데 실제 사용자들이 결제 중 이탈했다는 불만이 많다"는 상황의 원인이, 알고 보면 인터럽트 상황에서 데이터가 사라지는 문제인 경우가 실무에서 드물지 않다. 모바일 QA가 앱 생명주기와 인터럽트 시나리오를 테스트 계획(모듈 4)에 명시적으로 포함시키는 습관은, 웹 중심 QA가 놓치기 쉬운 결함을 미리 잡아내는 핵심 역량이다.