야너두 QA 할 수 있어! QA 개꿀팁 방출

글에 들어가기에 앞서 저는QA 직군이 아님을 밝힙니다.

 

그렇다면 QA도 아닌 게 무슨 QA 관련 포스팅?이라고 생각할 수도 있겠지만,

대부분의 스타트업 환경에는 QA 직군을 채용하기엔 어려운 환경에 놓여 있다고 생각합니다.

그래서 사내 IT 종사자들이 QA를 하는 경우가 더러 있는데,

이 포스팅에서는 QA를 하면서 얻은 러닝과 경험을 공유합니다.

검색을 통해 이 포스팅에 흘러들어온 독자분들에게 도움이 되길 바라는 마음으로 작성하게 되었습니다.

 

 

 

상황에 맞는 QA시트 수정하기.

1. QA 시트를 작성하기 전에 시나리오 기본 틀을 잘 잡자.

- 전문 QA 시트를 보면 depth1,2,3 분기되어 있고, 정말 세세하게 분리되어 있다.

- 이것을 사내 QA에 그대로 적용하기엔 QA시트 작성하는데 하루이틀 걸릴 문제가 아니었다.(나는 백엔드 개발자임)

- 이에 따라 depth 없애고, 시트를 내 입맛에 맞게 수정했다.

 

나의 경우는

진입점, 영역, 케이스, 체크리스트, 반영사항체크, 비고, UI-발생상황, UT-기대효과

라는  타이틀을 정했다.

 

- 진입점: 접근한 화면 view

- 영역: 화면 내에서 클릭하게 될 영역 

- 케이스: 조건이라고 이해하면 되는데 일반적인 경우, 특정 조건의 경우, 예외케이스의 경우를 포함한다. 다른 QA시트에서 depth로 쪼개지는 부분을 케이스로 통합했다. 

- 체크리스트: QA 검수 내용

- 반영사항체크: 시트기반 동작 체크 

- 비고: 기타 내용

- UI-발생상황: QA검수 시 발견된 내용(AS-IS)

- UI-기대효과: QA 검수 수정되어야 할 내용(TO-BE)

 

내가 QA 시트를 작성할 때 중요시 했던 것은 행이 너무 길어지지 않는가?이다. 

행이 길어지면 시트 자체를 읽기 어려워지기 때문이다. 

최대한 간략하게 가자.

 

화면 뷰 마다 동일한 동작이라도 '공통-이하동일'로 처리하지 말자.

1. '공통'이라고 처리해버리고 싶은 비슷한 동작이 너무도 많을 것이다.

하지만 각 화면 뷰 마다 액션이 이뤄지고 업데이트 상태라던지, 화면 페이지 이동이라던지 '한 끗'이 다르게 동작하는 경우가 있으므로 

동일한 동작이라도 모두 시트에 작성하도록 하자.

 

2. 또한 시트를 보는 제삼자의 입장에서는 '공통'이라고 작성한 시트를 보면서 더 헷갈릴 것이다.

 

에러케이스에 대해 체크하자

네트워크 에러라던지, 데이터가 없을 경우라던지, 회원이 탈퇴한 경우에 대한 에러케이스에 대해 체크하도록 하자.

주로 QA는 해피패스(정상동작범위에서만 체크하는 케이스)가 주이기 때문에 놓치는 경우가 허다하다.

참고로 이 영역은 프런트, 백엔드 개발자의 의견을  구하도록 하자.

 

디바이스 비율을 체크하자.

우리 서비스는 주 고객의 연령층이 많아서 QA시 디바이스 비율을 체크하자고 의견을 냈다.

버그제보에 올라온 버튼 클릭이 되지 않던 이슈가 있었는데, 디바이스 비율을 키우고 사용하던 유저에게서 발생되었다.

물론 모든 디바이스를 체크할 순 없지만 z-플립이나 일반 핸드폰의 화면 비율을 키워서 체크하도록 하자.

 

 

최상의 앱 상태여야 한다는 것을 생각하자.

팝업 이미지 로딩 느린 현상을 QA를 하면서 다른 지원분이 발견해 주었는데, 나는 전혀 이상하다고 생각을 못했다.

(아~ 이미지라 늦게 뜨는 거구나~ 하고 넘어감)

항상 앱은 최상의 상태여야 한다는 것을 생각하면서 QA에 임하도록 하자.

 

QA서버와 메인서버의 DB 구조를 알고있자.

내 서비스의 QA DB는 하나의 DB에서 read, write를 하고 있는 구조여서 QA시 문제가 되지 않았다.

하지만 메인서버에 올리고 엄청난 버그 이슈가 트래킹 되었는데 그 이유는 

main 서버 DB가 2대로 분기되어 있었고, read DB, write DB 사이에서 통신 중 ms초 차이로 상태가 맞지 않아 발생했었다. 

강제 업데이트 시 반영 안 되는 케이스(feat. 리모트 컨피그)

리모트 컨피그를 이용해 강제 업데이트를 하는 경우가 있는 분들은 꼭 알고 있으면 좋겠다.

리모트 컨피그 버전별 문제가 있어서 유저 전체에 강제업데이트가 되지 않는 경우가 있었다. 

강제업데이트 내부화를 하던가, DB에 업데이트 이전 앱 버전의 해당 유저를 찾아서 해결했다.

 

안드로이드 하단 디바이스 시스템 뒤로 가기 버튼의 영역 차지하는 문제가 존재.

 

 

 

안드로이드에서 뒤로가기 할 땐 아무런 문제가 되지 않았는데, 

아이폰에서 백스와이프로 뒤로 가기 할 때 인풋 버튼이 비활성화되는 문제가 있다. 

 

안드로이드, 아이폰의 앱 동작 방식이 다르므로 안드로이드, 아이폰 각각 체크해야 한다.

 

 

QA는 예상 완료 시간 *3배를 해야 한다.

그냥 이렇게 알고 있자.

 

앱 배포 시 아이폰은 긴급 배포 정책이 존재한다.

이렇게 최대 3번 긴급 수정사항이 있어 알아본 결과 3번 정도 긴급으로 앱 배포를 해준다

 

여건이 된다면 단계적 출시를 적용하는 것을 고려해 보자.

https://www.theteams.kr/teams/866/post/64573

소규모팀에 적합한 QA 프로세스 구축기(스타일쉐어팀의 QA방식) by 스타일쉐어(StyleShare)

 

 

 

0~90을 찍는 시간과 90~100을 찍는 시간은 동일하게 걸린다.

QA의 시작부터 90%단계까지 많은 시간을 들여 QA를 했다고 '아 정말 최선을 다했어!' 라고 생각했다면 안타까운 말씀을 드리고 싶다.

고객은 그런거 알 바도 아니고, 하나의 문제라도 있으면 안되는게 서비스다. 

QA를 하다보면 끊임없이 케이스가 발견되고, 사이드 이펙트로 되던 동작이 안되기도하고, 점점 늘어나는 시간과 압박 속에서 많이 지칠것이다.

그런 상황에서 엣지 케이스들을 잡아가고 90~100을 찍기 위해 걸리는 시간은 0~90 찍기 위해 걸리는 시간과 동일하게 걸린다는 것을 명심하길 바란다. 

 

 

 

 

 

글 재미나게 보셨으면 좋아요 눌러주고 가세요

관심받는 거 좋아합니다