by
Jun 20. 2020
내가 자주 놓치는 모바일앱 테스트 체크리스트
도그냥의 기억을 정리하는 시간:)
2014년에 갑자기 모바일팀으로 발령이 났었다.
PC 서비스와 백오피스 중심으로 일하다가 모바일을 다루게 되었다는 사실에 신난 것도 잠시,
달랐다.
웹은 웹인데 달랐고.
웹과 네이티브 앱은 달랐다.
요즘에야 아예 첨부터 모바일로 시작해서
PC서비스는 모바일을 기반으로 설계하기 때문에
이런 차이가 더 어색하게 느껴질지 모르겠지만
당시에 PC 웹 기획에 몇년간 익숙해진 나에게
우습게 봤던 모바일은 당황스럽고 어려웠다.
하지만 생경한 덕에 배운 것이 많았다.
가끔 느끼지만 무언가 당연해질수록 놓치는 것이 있기마련이라 오랜만에 기억을 끄집어내볼까 한다.
실무에서 모바일 서비스 테스트시 놓치기 쉬운 점들이다.
1.터치영역의 크기를 점검하자
작은 체크박스와 레이블이 함께 있는 경우, 어디를 체크해도 박스가 체크되도록 하는 것은 굉장히 당연해 보이지만 빠뜨리기 쉬운 부분이다.
체크박스와 레이블은 동시에 넓게 터치영역을 잡아줘야한다특히 웹으로 만들어진 하이브리드앱의 경우는 모바일용이라고 해도 기존의 웹개발을 위한 HTML파일로 퍼블리싱하기 때문에 신경쓰지 않으면 이 부분을 놓치기 쉽다. PC처럼 체크박스와 글씨의 터치 영역이 분리되어 있어도 터치 편의성이 너무 떨어진다.
넓은 범위의 버튼이 아닐 때는 아예 화면설계서에 터치영역을 표시해 주는 것도 방법이다.
스와이프 배너 영역의 터치 영역은 더 세심하게 잡아줘야한다스와이프 배너 영역을 만들 때 보통 테스트를 하면서 스와이프기능으로 배너 넘기는 것에만 집착하여 테스트하게된다, 그러다보면 페이징 인디케이터와 화살표부분의 터치영역을 잘 신경쓰지 못한다.
화살표 이미지나 페이징 동그라미에만 터치영역을 주면 터치하기 정말 어려워진다. 넓은 범위의 터치 영역에 대한 정의를 해줘야한다. 그런 정의는 테스트하면서 조절해야한다.
2. 랜드스케이프와 포트레이트 전환시 깨지지 않는지 테스트한다.
모바일에서는 포트레이트를 기본으로 다루고, 일부의 앱들의 경우에만 랜드스케이프시점에 특수한 UI를 만든다. 예를 들어 동영상 전체화면정도??
앱은 아예 포트레이트로 고정시켜놓는 경우도 많다. 폰의 화면이 커지면서 점점 더 랜드스케이프를 다루는 경우는 점차 줄어드는 것 같다. 그런데 모바일웹이 중요한 경우는 여전히 랜드스케이프와 포트레이트 전환에 대한 테스트가 필요하다.
웹을 반응형 또는 적응형 웹으로 만들면 디바이스의 가로해상도는 웹의 레이아웃 마크업을 결정하는 기준이 된다. 즉 포트레이트에서 랜드스케이프로 바뀌었을 때 어떤 때는 화면 레이아웃 기준이 바뀔 수 있다는 말이다.
가장 자주 발생하는 경우는 포트레이트에서 랜드스케이프로 전환할 때 리로드가 안되는 경우다. 리로드가 안된 상태에서 가로 해상도가 늘어나면 못생기게 늘어나거나 심한 경우 가로 정렬 UI유닛들과 중앙정렬 UI유닛들이 서로 벌어져서 와장창 깨져보인다.
이 경우에 제일 문제가 되는 것 중하나는 팝업레이어다.
중앙팝업 레이어는 보통 포트레이트 기준으로 디자인 작업이 이루어진다. 웹버전 퍼블리싱할 경우 중앙위치에 레이어를 고정시키는 것에는 2가지 방법이 쓰인다.
1)위에서부터 픽셀을 고정해서 위치를 잡아서 띄우는 경우
2) 무조건 보이는 화면에서 중앙에 위치시키는 경우
이 두 가지 경우 모두 랜드스케이프로 바꿨을 때 문제가 있을 수 있다.
첫번째 케이스의 경우 화면에 스크롤이 없으면 배너가 무조건 픽셀만큼 내려가 버려서 배너가 아예 안보이는 경우도 있고
두번째 케이스처럼 무조건 보이는 화면에서 중앙에 위치시키면 배너가 위아래로 화면 밖으로 나가버리는 현상도 생긴다.
결국 대안이 없어서 랜드스케이프일 때 아예 레이어팝업을 빼버린 적도 있다.
3. 키보드가 올라올 때와 아닌 때를 테스트한다.
모바일에서 키보드는 화면을 가리며 등장한다. 때문에 모든 입력필드에서 키보드가 올라왔을 때에 대한 정책이 필요하다.
보통은 키보드에 의해서 브라우저 사이즈의 heigt가 확 줄어든다. 하단에 고정시켜놓은 UI가 딸려 올라오기 마련인데 잘 못 정해진 높이값은 입력창과 액션바 사이에서 갈피를 잃는다.
자칫하면 입력창이 중첩되어 쓸 곳이 없어져서 문장도 하나 안보이게 될 수도 있다. 이 부분은 포트레이트와 랜드스케이프도 고려해야한다.
브런치 글쓰는 모습, 포트레이트에서 액션바가 위로 올라가서 입력창이 작아진다. feat.글속에 글속에 글랜드스케이프에서는 동일한 기준으로 적용하면 입력창이 딱 한줄 보일 수도 있다. 액션바와 헤더의 거리가 더 좁아져버린다. 이럴 때는 입력창을 누르면 키보드를 띄우는게 아니라 아예 입력하는 화면을 분리하여 UI가 가리지 않도록 하는 것도 방법이다.
4. 안드로이드 back 버튼에 대한 처리
경험상 높은 확률로 기획자들은 아이폰을 쓴다. 이유는 다양한 것 같긴한데 제일 큰 이유는 아마도 트래디셔널 힙이랄까. 어쨌든 그래서 불행히도 안드로이드 갬성 테스트가 잘 안되는 경우들이 있는데..
안드로이드 유저는 뒤로가는 화살표가 습관이 안되어 있다. 왜냐면 고정 BACK키가 있었으니까! 그런데 하이브리드 앱에서 사용되는 웹뷰를 아이폰으로만 테스트하다가는 놓치는 경우가 보통 이 부분이다. (물론 두 앱을 각 디바이스에서 각각 테스트해야하지만 아이폰 유저에게 안드로이드 갖다줘도 back키를 안쓰는 걸 보게된다. 습관의 힘은 무섭다)
안드로이드에서 네이티브앱의 영역은 레이어 하나도 back키로 열었다가 닫히지만 웹뷰로 되어있는 경우는 페이지 단위로 제어가 되기 때문에 사용자와 만든 사람의 생각이 다를 수 있다. 보통 상품상세에서 하단에 구매하기 누르고 오픈된 옵션레이어 닫으려고할 때 이 때 많이 문제가 생긴다.
지그재그의 경우는 z페이를 쓰는 곳은 네이티브 앱 영역이기 때문에 back키로 레이어만 닫히지만, z페이를 쓰지 않는 곳의 경우 이때 상품상세 전체가 닫히고 리스트로 돌아가 버린다. 같은 앱 내에서 구조적 차이로 경험이 달라져버리는 것이다.
웹뷰인걸 알고 있는 개발자는 당연히 페이지가 뒤로 넘어가는거 당연하다하고, 생각한 것과 다른 동작에 고객은 왜 다시 첨부터 옵션선택 해야하냐고 뭐라고 한다.
직접만든 웹뷰라면 이런 경우도 방법은 있다. 레이어 열때 강제로 history를 하나 생성하면 웹뷰에서도 back키로 닫히도록 제어가 가능하다. 이 부분은 경험에 의해 알게된 부분으로 테스트를 성실히 해봐야 아는 부분이다.
Back키 뿐아니라 모든 히스토리 back에서 영향주는 부분은 리스트와 상세 이동시에도 있다. 보통 검색결과나 상품 리스트는 비동기식 리스트 호출을 해서 끊어서 상품수를 가져온다. 더보기를 한 10번쯤 해서 상품에 갔다가 돌아왔는데 다시 리스트의 맨 처음 상품만 보인다면 그것보다 허탈한 것도 없다.
꼭 테스트시에 대안을 마련해야한다.리스트를 불러오는 방식은 여러가지가 있는데, 개발에서 전체를 다 긁어온, 다음에 끊어서 뿌리는 경우와 정말로 끊어서 조회해오는 경우가 있다. 문제는 2가지 다 생긴다.
전자는 첫로딩이 느린대신에 이미 불러왔기 때문에 잘 제어해두면 페이지가 넘어갔다가 다시 제 위치를 재빨리 찾을 수 있다. 후자는 어떤 경우 앞에 불러왔던 것을 다시 다 불러와야 원래 위치를 찾는 경우가 많다. 두더더덕하면서 노출이 되면서 제 위치를 찾는다. 이 부분도 테스트 시에 꼭 체크해야한 포인트다.
5. 디바이스 기본폰트 적용여부
개조끝에 순정이라고 폰 사용량이 많은 우리 업자들은 디바이스 폰트에 손을 잘 대지 않는다. 그런데 여성 이용자들 중에는 런처 등을 통해 예쁜 폰에 대한 욕구가 있는 경우가 있다. 글씨 사이즈를 줄여놓거나 폰트에 막 하트가 들어간 글씨로 해놓는다. (갤럭시 무료 폰트중 팅커벨은 고객 오류신고때도 종종 등장한다)
문제는 우리 서비스가 디바이스 폰트 설정에 영향을 받느냐다.
위에처럼 디바이스 기본폰트나 사이즈를 바꾸면 웹폰트가 적용되어 고정되지 않은 경우, 프로덕트의 형태에 영향을 미친다는 점이다. 글씨자수 같은 것으로 화면을 고정해놓은 경우 글자크기나 자평이 달라지면 영향을 받는다. 가장 안전한 방법은 웹이고 앱이고 명확한 폰트를 아예 고정시키는 방법이다.
도그냥은 추상적인 이야기를 한다?
