기획자의 QA
서비스 기획자의 기록 #4
진행 중인 이커머스 프로젝트에서 이제 어느 정도 QA를 마무리하고 오픈을 준비하고 있다! (이전 글 참고: https://brunch.co.kr/@dragonattack/3) 그동안 종합해 본 QA의 완성도를 높이는 방법에 대해정리해 본다.
*QA란?
웹사이트를 런칭하는 경우, 사이트를 릴리즈 하기 전 안정적으로 구동되고 있는지 문제 될 만한 사항이 없는지 모든 브라우저에서 잘 구동되고 있는지 등 꼼꼼하게 살펴보는 단계이다. 웹사이트가 잘 작동되지 않거나 이미지 미노출, 맞춤법 오류, 내용 오류 등의 문제가 발생하게 되면 사이트를 방문한 사용자들에게 부정적인 경험을 주게 되고 이는 서비스/제품의 인식에도 부정적인 영향을 줄 수 있기 때문에 QA는 오류를 찾아내기 위해 정말 이 잡듯이 사이트를 뒤져야 한다. 그래서 QA 기간에는 여기저기서 '눈알이 빠질 것 같다’라는 이야기가 들려오기도 한다.
1. 작업 스페이스 구축하기
QA를 체계적으로 진행하기 위해서 첫 번째로 작업 양식과 스페이스를 만든다. 보통 회사에서는 jira 로 많이 하지만, 우리는 규모 20명 이상의 사이드프로젝트이므로 slack과 notion 으로 진행했다.
특히 notion에서 통일된 양식을 만드는 게 중요하다. 그래야 서로 리포팅하고 소통하기 편하기 때문이다.
각 페이지 안에는 문제상황과 요청사항을 쓰고, 사진 또는 url 을 첨부한다. 이슈에 따라 화면녹화가 필요할 경우 같이 업로드한다.
노션에서 제공하는 프로젝트 로드맵 템플릿도 있다.진행 상황을 진행전, 진행 중, 진행 완료로 나누고 담당자를 정확히 assign한다. 기능별 백엔드, 프론트엔드 담당자를 정리해둔 문서가 있으면 헷갈리지 않고 지정할 수 있다.
특히 노션으로 진행할 때 위 사진과 같이 전체 작업 상황을 시각적으로 한눈에 볼 수 있어서 좋았다. 시간이 지남에 따라 진행 완료에 옮겨진 티켓이 더 많아지는 것을 보니 설레기도 했다.
2. User journey 를 고려해서 가능한 모든 경우를 테스트해 본다.
오픈 후 사용자들이 마주할 모든 상황들에서 기능이 제대로 돌아가는지 보기 위해서는 꼼꼼하게 작업하는 게 가장 중요하다.
이때 유용한 문서가 user journey이다. 유저의 사용 패턴을 흐름에 따라 작성해둔 문서이기 때문에 이를 기반으로 테스트를 진행하면 많은 케이스를 확인할 수 있다.
user flow 예시 c. Figma예컨대 검색 기능 사용 시 추천 키워드로 뜨는 걸 눌러볼 수도 있고, 키워드를 1단어로 검색하거나 4단어로 검색할 수도 있다. 또한 검색 결과를 보고 바로 원하는 상품을 찾을 수도 있고, 찾는 상품이 안 나올 수도 있다. 또는 기획사항과는 다르게 관련이 없는 상품이 뜰 수도 있다. 이런 다양한 경우에 대해 요구사항대로 작동하는지, 에러는 없는지 확인한다.
3. 데이터 테스트
QA 기간 중 가장 복잡하고 중요한 게 데이터 테스트라고 생각한다. 이커머스인 만큼 노출되는 상품 정보가 중요했는데, 기획의도와는 다른 느낌의 상품들이 노출되는 경우가 있었다. 특히 메인페이지에 덜 매력적인 상품이 노출될 경우, 웹사이트 진입 초기부터 매력도를 떨어뜨리고 이탈을 가속화할 수 있어 치명적이다. 따라서 DB를 보고 기존의 상품 로직을 개선하는 작업을 했다. 데이터베이스 구조를 정리해둔 ERD문서를 바탕으로 SQL로 쿼리를 작성하여 리뷰 수나 카테고리로 조건을 걸어 리턴되는 상품 데이터를 보고, 더 매력적인 상품이 노출되도록 정책을 수정했다.
데이터베이스 구조 예시 c.MySQL요새 기획자에게 SQL 역량이 필요할 수밖에 없는 이유를 QA를 통해 직접 쿼리를 뽑아 데이터를 살펴보면서 실제로 알게 된 계기였다. 데이터의 경우, 서버 개발자나 백엔드 개발자와 긴밀하게 얘기하면서 보완해 나가는 것이 좋다. 결국에 방대한 데이터베이스를 가장 가까이서 관리하고 있는 이들이기 때문에 기획사항에 대한 좋은 아이디어들을 제안하는 등의 시너지 효과를 낼 수 있다.
4. 웹사이트 외부에서 접속해 본다.
구글 검색 결과를 통해 웹사이트에 들어오는 사용자 경험도 고려해야 한다. 이때도 여러 이슈가 발견되었는데, 품절이나 판매중지된 상품페이지로 들어간 경우가 있었다. 이경우 예외 케이스를 어떻게 처리하는 게 좋을지 재검토할 수 있다.
추후 seo 작업을 고도화시키기 위한 단서를 얻을 수도 있다.
물론 회사에서 진행하는 QA는 정식 론칭 이전까지 도메인을 연결하지 않는다고 알고 있다. 하지만 우리 팀은 검색 결과에 노출되어도 크게 상관없어서 일찍 연결하게 되었다.
5. 여러 도메인 계정으로 로그인하여 테스트해 본다.
소셜 로그인할 때 google, Naver, KaKao 등 계정에 따라 다른 이슈가 발생할 수 있다.
소셜 로그인처음에 나는 gmail로만 로그인해서 테스트했는데, 메일로 알림이 안 와서 메일 알림 기능 전체에 문제가 있는 줄 알았다.
그런데 Naver 계정으로 테스트한 다른 분은 정상적으로 작동했다. 이런 식으로 도메인 별 오류도 꼼꼼하게 확인한다.
QA를 진행하다 보니 아무래도 요청사항을 계속 부탁하는 기획자 입장에서 너무 많이 요청하는 건 아닐까 하는 생각이 종종 스쳐지나갔다. 일을 시키는 사람이 된 기분이랄까 ..
그래도 전반적인 일을 마무리한 지금은 너무 자잘한 게 아니면 바로 리포트하는 게 맞다는 생각이다. 지인들에게 웹사이트를 보여줬을 때 태그 네임이 이해가 안 된다는 의견이 많았다. 이경우 시스템 이해에 큰 영향을 미치므로, 툴팁박스를 만들어 태그를 설명할 것을 요청했다.
이 밖에 자잘한 개선사항들도 잡아야 될 이슈이지만 우선순위에 따라, 오픈 이후에 차차 수정해도 된다. 결국 오픈 일정과 작업 리소스에 따라 어느 정도의 이슈까지 처리할지 우선순위를 결정하는 게 기획자에게는 중요하다.
그렇게 대략 4달 넘게 작업한 웹사이트가 이번 주 중으로 오픈을 앞두고 있다! 오픈 이후 블로그에 다시 소개하러 오겠다. ㅎㅎ
