나만의 테스트 루틴 만들기
완성도를 조금 더 높이기 위한 에센스 한 스푼
테스트 이전의 단계가 이론이라면, 테스트부터가 실전이다. 기획자라면 꼭 테스트를 해야 한다고 전에 언급한 적이 있다.
몇 년간 여러 번의 오픈을 거치며 테스트는 나름 할 만큼 했다고 하지만 그래도 놓치는 부분이 있다. 게다가 우리는 전문 테스트 교육을 받은 게 아니라 기획자니까 처음에는 놓치는 부분이 많을 수 있다. 테스트 시나리오에는 없는 아주 사소하지만 중요한 부분들. 프로젝트를 진행하며 고강도의 테스트 기간을 거치다 보니 어느 정도 루틴이 잡혔다. 그간의 경험을 토대로 추려본, 있으면 좀 더 오픈에 만전을 기할 수 있는 나의 방식을 정리해보았다.
테스트 루틴
1. 테스트 시나리오를 따라 진행
2. 기획서를 따라 진행
3. 등록한 결함의 현황 follow-up
테스트 시나리오가 있는 경우는 테스트 시나리오를 우선으로 한다. 다만 시나리오가 있어도 기획서와 일치하는지는 늘 비교하고 확인해보는 편이다. TC(테스트 케이스)를 짜는 사람도 실수할 수 있으니까. 확인은 꼼꼼할수록 좋다. 결함을 많이 발견하면 테스트를 잘하는 것 같으면서도 개발의 완성도가 떨어지는 것 같아 씁쓸한 느낌이 동시에 들곤 한다.
정말이지... 역대급 프로젝트오픈 전에 결함을 잘 찾아내는 것도 중요하지만, 진행 상황을 계속 체크하는 게 중요하다. 그래서 레드마인 같은 툴을 활용해서 결함의 우선순위와 일정 등을 잡아야 한다. 규모가 있는 프로젝트라면 매일 결함이 쏟아질 수도 있으니 매일 30분이라도 리뷰하는 시간을 가지기를 추천한다.
테스트할 때 중요하게 생각하는 점
1. 기획 의도와 기획서상 description에 맞게 구현됐는지
2. 기존 앱 정책 및 사용성에 위배되지 않는지
3. 기획과 실제 구동 간의 괴리가 느껴지지 않는지
이미 앞단에서 치열하게 싸워서 나온 정책은 테스트 단계쯤부터는 믿고 가야 한다. 따라서 기존의 의도대로 제대로 구현되었는지를 가장 먼저 확인한다. 2번 같은 경우도 기획에서 충분히 고려되었겠으나 세세한 부분에서 기존과는 좀 다르게 동작할 수 있다. 우리 앱의 경우 폼을 입력할 때 잘못된 값이 들어가면 폼의 테두리가 연한 회색에서 빨간색으로 바뀌는데, 그런 부분이 누락되었다던가 다른 디자인이 적용되었다던가 하는 작은 부분들도 해당된다. 저런 사소한 부분이 모여 우리 앱의 일관성을 만든다. 무시할 수 없는 부분이다. 3번이 기획단에서는 미처 생각지 못한 부분이다. 실전에서 튀어나와주는 문제들. 이럴 때는 머리를 맞대고 좋은 방향으로 고쳐나가면 된다. 그러라고 테스트하는 거니까.
결함이 자주 나와서 신경 쓰는 파트
1. 할 수 있는 한 다양한 기기에서 테스트해보기
누구나 손에 익은 게 편하다. 보통 아이폰을 쓰는 사람은 아이폰에서, 안드로이드를 쓰는 사람은 안드로이드에서 테스트하려고 한다. 규모에 따라 다르겠지만, 중요한 프로젝트라면 기기를 달리하며 테스트를 해보는 게 중요하다. 똑같은 기능이 OS에 따라, 기종에 따라, OS 버전에 따라 오류가 나는 경우가 있다. 아예 처음 테스트를 진행할 때부터 보통 아이폰과 안드로이드 기종을 하나씩 놓고 동시에 테스트를 진행한다. 여건이 된다면 기기를 바꾸기도 한다. 아이폰 프로에서 맥스로, 삼성에서 LG로. 결함을 전달할 때도 기종과 OS 버전을 전달하는 게 개발자에게도 쉽게 원인 파악을 할 수 있게 해 준다.
2. 웹과 앱에서 동시에 구동해보기
위에 같이 묶을까 하다가 엄밀히 결이 다른 얘기라. 앱과 웹에서 디자인이나 기능이 조금씩 다르게 구현되는 경우가 있다. 네이티브에서만 구현되는 거라 웹에서는 뺐을 수도 있고, 정책적인 이유일 수도 있고, 그냥 브라우저 문제일 수도 있다. 내 경우에는 사파리와 삼성 인터넷 등의 안드로이드 기종 기본 인터넷 앱을 사용한다. 웹에서 문제가 있는 경우 크롬이나 파이어폭스 등 다른 브라우저에서도 돌려보고, 어느 브라우저에서 어떤 문제가 일어나는지 파악한다. 간혹 PC에서 모바일 웹 버전을 켜서 점검하는 경우가 있는데 추천하지 않는다. 그건 퍼블리싱이나 GA를 점검할 때나 문제가 없지, FO 구동 테스트에는 적합하지 않다. 고객의 입장이 되어서 테스트하는 게 가장 중요하다.
3. 백 버튼 프로세스
앱 자체의 백 버튼, 안드로이드 물리키, iOS 스와이프 백. (쓰고 보니 개노답 삼형제 같다) 히스토리 이슈는 태반이 백버튼 관련이라 정말 눈물이 난다. 주문이나 컨텐츠 등록/수정/삭제 등 데이터가 변경되는 경우에는 히스토리 정책을 탄탄하게 잡아둬도 문제가 생긴다. 사용자마다 쓰는 방식이 다르고, OS에서 작동하는 방식이 다르고, 앱과 웹에서 또 다르고... 다 그게 문제죠... 아이폰에 물리키가 있고 안드로이드에서 스와이프 백이 동작했다면 좋았겠지만. 워낙 케이스도 다양한 문제라 여러 가지로 테스트해보고 가장 문제없게 잡아나가는 게 좋다.
4. 기존 운영 이슈 확인
이번 프로젝트에서 이런 이슈가 있다니; 하고 달려가 보면 꽤 잦은 빈도로 들려오는 대답이 있다.
이건 운영 이슈예요.
저 대답이 바로 나왔다면 보통은 못 잡는 이슈다. 운영팀에서 인지를 하고 있는데도 내버려 뒀다는 건 뭐가 많이 꼬였다는 뜻이다. 최대한 우회할 방법을 찾자. 때로는 운영팀에서 파악을 못하고 있던 운영 이슈를 찾을 때도 있다. 그럼 뭐 꿩 먹고 알 먹고죠. 결함이 나왔을 때 먼저 운영에 있는 비슷한 기능에서 똑같이 테스트를 돌려보면 운영에 뛰어가지 않아도 운영 이슈구나를 알 수 있는 수준이 된다. 운영팀에는 운영 이슈로 전달해줍시다.
테스트 잘한다는 칭찬을 좀 받아서 좀 뭔가, 되게 특별한 나만의 테스트 방법 이런 게 있는 줄 알았는데 적어 내려가다 보니 그건 아니었던 모양이다. 사용성이나 그런 것들은 기본 중의 기본이고. 결함도 별로 안 나와서 지루해지는 테스트 해보고 싶다... 고 하고 돌이켜보니 그럴 때는 안이해져서 또 기본을 놓치곤 했다. 적당한 결함은 업무에 적당한 긴장감을 불어넣어서 결과를 성공적으로 이끈다. 결함 만세.
