매번 힘들고 부담스러운 QA, 덜 헤맬 수는 없을까?
QA 진행 시 주니어가 알아두면 좋을 수도 있는 마이크로 Tip
안녕하세요.
지금까지 제가 디자인 에이전시에서 약 1년 반 정도 UX 디자이너로 일하면서 QA를 꽤 여러 차례 경험하게 되었는데요.
처음에는 QA 일정이 잡히면 시작 전부터 부담스럽고 막막했지만, 이제는 좀 하다 보니 어느 정도 익숙해진 것 같습니다.
여러 차례 QA를 진행하다 보니, '아 이랬으면 더 효율적으로 QA 할 수 있었을 텐데...'하고 아쉬워하는 일이 계속 생겨서 아쉬웠던 부분들과 그에 대한 대응법이나 팁을 정리해두면 추후에 유용할 것 같다고 생각했습니다.
그래서 제 개인적인 경험뿐만 아니라 QA 때마다 합을 맞춰온 분들(Yunnie님, 기정환님, 프론트믽님)께 추가 내용을 전달받아 정리해봤습니다.
저희가 QA 하는 방법이 궁금하시다면, 일전에 저희 팀 Yunnie님께서 써주신 글을 보시면 될 것 같습니다.
https://brunch.co.kr/@yuneuichoi/19
목차
1. 대응 범위 및 진행 프로세스 명확히 하기
2. 효율적으로 업무 분담하기
3. 이슈 할당 정확히 하기
4. 이슈를 찾아낼 때 가져야 할 마음가짐
5. QA를 진행하면서 신경 써야 할 것들
6. 오픈 직후에 반드시 체크해야 하는 것
1. 대응 범위 및 진행 프로세스 명확히 하기
Yunnie님께서 작성하신 글 내용 중, QA 시트를 만들기 전에 담당자 배정과 테스트 브라우저 협의를 한다고 되어 있습니다.
그와 함께 PM이 담당자들에게 대응 범위 및 진행 프로세스, 종료 시점에 대해 명확한 공지를 하는 것 역시 필요합니다.
대응 범위의 경우, 사소하게는 맞춤법부터 레이아웃 대응 등의 주요 체크 항목을 정하는 것이고, 진행 프로세스는 크게 QA 기간 중에 1일 차에는 무엇을 주로 체크하고 2일 차에는 어떤 걸 주로 체크할지 정하는 겁니다.
QA가 종료되었는데도 시트에 이슈를 등록하는 경우가 가끔 있는데요.
치명적인 버그 혹은 반드시 대응해야 하는 이슈라면 QA 종료 이후여도 대응하는 것이 맞지만, 간혹 그렇지 않은 경우들이 문제가 되곤 합니다.
기존에 전달한 문안이 마음에 들지 않아서 QA 시트에 문안 변경을 요청하는 경우들이 대표적인 사례이죠.
이를 방지하기 위해선 해당 사이트의 실무자 및 이해관계자 모두에게 종료 시점과 종료 후에 등록되는 이슈들은 대응하지 않겠다는 것을 인지시켜야 합니다.
제일 좋은 방법은 QA 시작 전에 대응 범위, 진행 일정, 종료 후 등록되는 이슈는 반영하지 않겠다는 내용을 담은 QA 공지 메일을 해당 사이트의 실무자 및 이해관계자 모두에게 보내는 것입니다.
그리고 QA 종료 후 종료 공지 메일까지 보내면 더할 나위 없이 좋을 것입니다.
2. 효율적으로 업무 분담하기
QA 업무 내 역할 그룹은 크게 '이슈를 찾아내는 사람'과 '이슈를 수정하는 사람'으로 나뉩니다.
이슈의 원인이 무엇이냐에 따라 내가 이슈를 찾아내기도 하고 그 이슈를 수정해야 하지만, 대개 비 개발 직군이 개발적 이슈를 찾아내 개발 직군에 전달하는 것이 주를 이룹니다.
이슈를 수정하는 그룹의 경우엔 어느 정도 QA 업무가 꽤 명확하게 분담되어 있으나, 이슈를 찾아내는 그룹은 보통 불명확한 상태로 시작하게 되며 모두가 같은 이슈를 자꾸 중복으로 찾아내 시트에 기재하는 등의 사소한 문제가 종종 생기곤 합니다.
이런 사소한 문제를 방지하려면 이슈를 찾아내는 그룹에 속한 담당자들끼리 업무를 잘 분담하는 것이 좋습니다.
일단 QA시 테스트해야 할 브라우저를 대략 나열해보면 아래와 같습니다.
PC
OS 공통 - 크롬, 웨일(파이어폭스랑 오페라도 있지만 일단 모른척합니다...)
Mac - 사파리
Win - 엣지, 익스플로러(곧 사라진다고 하지만, 아직 사용하는 사람이 꽤 있어 종종 대응해야 합니다...)
Mobile
OS 공통 - 크롬, 네이버
IOS - 사파리
Android - 삼성 인터넷
하하하... 꽤 많죠? 우리는 PC와 모바일로 시작해 OS 및 브라우저별로 다양한 환경에서 테스트를 반복 진행해야 하기 때문에 사전에 업무 분담에 관해 협의하지 않으면 약간 힘들어집니다...
같은 이슈를 계속 중복으로 찾게 되거나, 아무도 체크하지 않는 부분이 생겨 오픈 후에 발견되거나 등의 문제가 생기기 쉽죠.
그렇기에 QA를 진행하는 인원끼리 각자 어떻게 업무를 분담할 것인지 상의하는 것이 중요합니다.
먼저 크게 두 가지로 나눌 수 있을 것 같습니다.
1. 기기, OS, 브라우저별로 나눠 담당하기
EX) 기획팀 000은 PC 윈도우의 엣지/익스, 디자인팀 000은 맥 사파리 및 크롬 맡아서 이슈 찾기
2. 디자인, 기능, 텍스트(문안)로 나눠 담당하기
EX) 기획팀은 텍스트 오류 및 기능적 버그 찾기, 디자인팀은 레이아웃/이미지/인터랙션 위주의 이슈 찾기
위와 같이 협의한 후에 내가 담당한 부분이 아닌 이슈를 첫 번째로 발견한 경우에는 일단 체크하여 QA 시트에 기재합니다.
그리고 해당 이슈를 대응해야 하는 담당자에게 메모를 남기거나 메신저로 '해당 이슈를 발견하여 기재했으니, 반영 및 완료 여부를 추후에 체크해달라고 요청하면 됩니다!
3. 이슈 할당 정확히 하기
보통 QA 전에 각 부서별로 담당자를 정하고, 각자의 파트에 해당하는 이슈를 해결하도록 합니다. (종종 고객사에서도 참여하기도 합니다)
하지만 QA를 처음 경험해보는 경우 혹은 다른 부서의 업무 범위를 잘 모르는 경우에는 찾은 이슈를 어느 팀에 할당해야 하는지 몰라 곤혹스러워하기도 하고 다른 팀에 잘못 할당하는 실수로 이어지기도 합니다.
대개 '퍼블리싱과 개발 중 어느 부서에 할당하지?' 하고 고민하는 경우가 많지요...
이런 문제들은 평소 각 팀의 업무 범위만 잘 알더라도 거의 발생하지 않을 문제지만... 의외로 그게 또 잘 안 되는 것 같아, QA 업무 진행 시 각 파트에 할당해야 하는 문제들을 다음과 같이 정리해보았습니다.
기획 - 설계상의 문제
디자인 - (퍼블리싱만의 문제가 아닌) 디자인 파일의 문제
퍼블리싱 - 텍스트 오류, 이미지 오류, 레이아웃, 인터랙션 문제
개발 - 400, 500 서버 에러를 포함한 링크 값 오류, 콘텐츠 오류, 사이트 내 기능 작동에 관련된 문제
고객사 - (고객사에서 참여하는 경우) 문안 및 정책 문제
대략 이 정도로 알고 계시면 아마 '왜 이걸 저한테 할당하신 거예요?'라는 얘기는 나오지 않을 것입니다.
그리고 퍼블리셔와 프론트엔드 개발자가 구분되어 있는 경우를 상정하여 위와 같이 적었는데, 만약 그렇지 않은 경우에는 퍼블리싱에 해당하는 내용을 개발(프론트엔드)쪽에 할당하면 됩니다.
(제가 몸담고 있는 곳은 프로젝트마다 퍼블리셔님이 참여하기도 하고 프론트엔드 개발자님께서 혼자 다 처리하기도 하는데, 이는 프로젝트 킥오프 시점에서 참여 인력 리소스를 확인해보거나 디자인이 종료되고 개발 단계로 넘어갔을 때 미리 체크해보시기 바랍니다)
혹시나 만약 퍼블리셔와 프론트엔드 개발자가 뭐가 다른지, 왜 이렇게 구분되었는지 궁금하시다면 아래 블로그 글을 참고하시면 좋습니다.
https://emptydream.tistory.com/3923
4. 이슈를 찾아낼 때 가져야 할 마음가짐
제가 어릴 때 겟앰프드라는 온라인 격투 게임을 했었습니다.
그 당시에 유저들끼리 모여 온갖 테스트를 하며 버그를 찾아내는 '버그 방'이 있었는데, 이 버그 방의 목적은 여러 가지 테스트를 하다가 게임 플레이에 유리한 버그를 찾아내 핫픽스 전까지 본인들이 사용하기 위함이었죠.
이는 게임 회사에서 하는 QA 방법을 유저들이 다른 목적으로 했던 것인데, 제가 갑자기 게임 얘기를 한 이유는 유저들이 '온갖 테스트를 했다는 것'에 있습니다.
개발 단계에서 "사용자가 A와 B란 동작을 하면 C란 결과가 나온다"와 같은 시나리오를 세우고 이에 따라 프로그래밍하곤 하는데 시나리오를 벗어나는 케이스가 발생하면 버그가 발생하기도 합니다.
기억하십시오...'사용자들은 절대 우리가 상상한 대로 서비스를 이용하지 않습니다.문제는 해당 사이트를 이용할 수많은 이용자를 대응할 수 있을 정도로 시나리오를 촘촘하게 세울 수 없다는 것이죠... 그렇기에 우리는 개발 단계에서 놓친 부분들을 QA 단계에서 향후 큰 문제가 될 버그들을 최대한 찾아내야 합니다.
하지만 단순히 이미지가 잘 나오고 텍스트가 제대로 입력되어 있는지, 페이지 링크 값이 제대로 되어 있는지 등만 체크해서는 숨겨진 버그를 찾을 수 없습니다.
아래 사례는 제가 경험했던 버그 중에 증상 발현 과정이 복잡하고 발현되었을 때 좀 치명적이었던 것인데, 정말 사이트를 마구 굴리다가 우연히 발견하여 급히 개발팀에서 대응했었습니다.
1. 상품 리스트 페이지에서 10번째 상품을 선택하여 상세 페이지 진입 - (버그 트리거1)
2. [뒤로 가기]를 눌러 상품 리스트 페이지로 이탈 - (버그 트리거2)
3. 4번째 상품까지 스크롤 업한 뒤 선택 - (버그 트리거3)
4. 해당 상품의 상세페이지에 이전 상품이 함께 노출되며 레이아웃 틀어짐 - (버그 발생)
위와 같은 사례가 종종 일어나곤 하니 QA를 하게 되면 이미지/텍스트/링크 값/인터랙션 체크와 같이 당장 눈에 보이는 이슈들을 처리한 후에는 사이트를 이리저리 테스트하여 숨겨진 버그들을 찾아내 개발자님들의 디버깅에 도움이 되도록 합시다.
5. QA를 진행하면서 신경 써야 할 것들
5-1. 쿠키 및 캐시 자주 지우기
먼저, 쿠키와 캐시에 대한 정보는 아래 블로그 글을 참고하시면 될 것 같습니다.
특정 브라우저에서 텍스트 혹은 이미지 오류 등의 이슈를 발견하여 수정 요청을 드렸고, 그게 반영되었는지 확인할 때 먼저 쿠키와 캐시를 꼭 삭제하고 나서 '강력한 새로고침'을 해주셔야 합니다.
그렇지 않으면 반영 안 된 상태로 노출될 가능성이 매우 큽니다!
그리고 아래와 같은 대화 내용이 오가고 사실 이미 제대로 반영 완료된 상황인데도 한 번 더 체크하는 상황이 벌어지면서 안 그래도 금쪽같은 시간을 낭비하게 됩니다.
A: "00님 xx이슈 반영해주셨다고 했는데, 아직도 그대로예요."
B: "어? 반영했는데요...? 일단 다시 확인해볼게요"
(잠시 후...)
B: "제대로 반영되었는데, 혹시 캐시랑 쿠키 안 지우셨나요?"
A: "?!!! 앗... 지워볼게요!"
A: "지우고 다시 확인하니 반영되었네요!"
그러니 QA 진행 시 주기적으로 쿠키와 캐시를 삭제하여 수정 요청 올린 사항이 제대로 반영되었는지 체크해주셔야 1분 1초라도 덜 낭비하고 효율적으로 진행하실 수 있습니다.
5-2. Android 삼성 인터넷 다크 모드 이슈
삼성 갤럭시 스마트폰을 쓰는 유저에 한정된 이슈인데요.
기기 설정에서 다크 모드를 설정한 경우, 구축하는 웹사이트가 다크 모드를 지원하지 않더라도 삼성 인터넷 브라우저에서 강제로 변환합니다.
모든 것이 알아서 잘 변환되면 문제가 없겠지만... 등록된 이미지의 색을 강제로 반전시키거나 로고 컬러가 변하지 않는 등의 문제가 대부분 있었습니다.
그렇기에 만약 구축하는 웹사이트가 다크 모드를 지원하지 않는다면, 내부에서 빠르게 의사결정을 하여 삼성 인터넷 대응을 할지 말지 정해야 합니다.
다만, 계획에 없던 다크 모드에 대응하려면 새롭게 모든 컴포넌트를 개발해야 하니, 시간적인 여유가 없고 너무 크리티컬 하지 않다면 일단은 넘어가는 것을 추천드립니다.
5-3. 익스플로러 대응 시 감안해야 할 사항 - CSS, JS
윈도우 익스플로러 대응을 해야 한다면 감안해야 하는 사항들이 있습니다.
CSS 속성 중에 다른 브라우저들은 지원하지만 익스플로러만 지원하지 않는 것들이 있고, JS 코드 측면에서도 문법 미대응 등의 이슈가 있기 때문이죠.
아래에 그 내용들을 프론트믽님의 도움을 받아 정리해봤습니다.
익스플로러에서 미 지원하는 CSS 속성 사례
display: grid
편리하게 그리드를 짤 수 있도록 도와주는 속성으로 지원한다고 하시는 분들도 계시지만, 익스플로러는 다른 브라우저만큼 완벽하게 지원하지 않는 것 같습니다.
object-fit
이미지 혹은 비디오의 미디어 요소들을 컨테이너에 맞게 크기를 조정하는 방법을 지정하는 것으로 익스플로러에서는 지원되지 않습니다.
대체하는 방법이 있긴 한데, 내용이 약간 길어 아래 링크를 참고해주시면 될 것 같습니다.
https://hyeonseok.com/blog/862
text-stroke
해당 속성을 익스플로러가 지원하지 않지만, text-shadow로 대체하여 사용할 수 있습니다.
하지만 아래 이미지처럼 익스플로러의 경우 다른 브라우저와 같이 깨끗하게 보이도록 구현할 수 없습니다.
만약 디자인된 화면에 스트로크 폰트를 쓰셨다면 익스플로러 대응 시 이 정도가 최선이라 생각하고 넘어가시면 됩니다.
filter, mix-blend-mode
mix-blend-mode: overlay와 filter: blur 속성 역시 익스플로러에서 지원하지 않아, 최대한 비슷하게 보이려면 이미지로 대체해야 합니다.
이 외에도 어떠한 CSS 속성이 익스플로러에서도 적용 유무가 궁금하시다면, 아래 링크에서 검색 가능합니다.
개발자 입장에서 QA 진행 시 익스플로러를 나중에 진행하면 좋은 이유 - JS
자바스크립트는 ES6 문법으로 작성합니다.
익스플로러의 경우 위 문법을 전혀 대응하지 않기 때문에 코드를 변환해야 합니다.
개발 서버에서는 원본 소스를 항상 유지하고, 실서버에는 변환된 파일로 업로드하는 과정을 거칩니다.
시간이 없을 경우엔 이것도 시간이 소요되기 때문에, 다른 브라우저에서 검수가 끝나갈 때쯤 익스플로러 QA를 진행하는 편이 좋습니다.
가끔 QA 하실 때 익스플로러에서 아무 화면도 안 나오는 경우를 보신 적이 있을 텐데요. 위 과정을 거치지 않은 경우입니다.
6. 오픈 직후에 반드시 체크해야 하는 것
6-1. SEO 적용 검토하기
QA가 종료되고 사이트 오픈 직전, 해당 업무 담당자께서 미리 정해둔 타이틀/디스크립션/키워드를 입력하여 검색 엔진 최적화 작업을 하실 겁니다.
이때 설정한 메타 타이틀/디스크립션/태그가 구글/네이버에서 제대로 노출되는지 잊지 말고 체크하는 것이 좋습니다.
사이트를 리뉴얼한 경우에는 리뉴얼 이전에 수집된 데이터가 새로 반영할 데이터와 섞여서 오류를 일으키기도 해서 의도하지 않은 방향으로 오픈된 사이트가 노출될 수 있기 때문이죠.
만약 문제가 있는 경우, 입력한 메타 타이틀/디스크립션/태그가 문제없는지 체크해보고 페이지 정보 재수집 요청을 해야 합니다.
그리고 체크도 하고 페이지 정보 재수집 요청을 했는데도 수정되지 않는다면 입력한 메타 타이틀/디스크립션/태그를 수정하고 사이트 웹마스터 도구를 통해 다시 등록해보는 것을 추천드립니다.
구글의 경우엔 meta 태그 내용보다 본문 내용이 더 정확한 설명을 제공할 수 있다고 판단하면 본문 내용을 수집해서 보여주기도 하는데 이 과정에 노출되는 내용이 달라질 수 있기 때문입니다.
QA 때 문제가 없더라도 유저가 처음으로 사이트를 마주하는 검색 화면에서부터 좋지 않은 경험을 하게 할 수 없으니, 잊지 말고 반드시 체크해보시기 바랍니다.
사이트 웹마스터 도구
아래의 각 링크를 통해 사이트 소유주 확인 후에 SEO와 관련된 사이트 전반 내용을 관리할 수 있습니다.
구글 - google search console
네이버 - 웹마스터 도구
6-2. 링크 프리뷰와 오픈 그래프 확인하기
카톡에 공유된 브런치 작가 링크 브리뷰 (미리 보기 이미지가 원했던 느낌이 아니라 슬픕니다...)먼저, 링크 프리뷰와 오픈 그래프에 대해 더 자세하고 정확하게 알고 싶으시다면 아래 링크를 참고하시면 될 것 같습니다.
검색 결과에 이어서 하나 더 확인해보셔야 하는 것이 바로 링크 프리뷰와 오픈 그래프입니다.
링크 프리뷰는 특정 사이트의 링크를 페이스북이나 카톡 같은 곳에 공유했을 때, 이미지와 제목, 디스크립션 등이 노출되어 직접 들어가지 않아도 대략적인 사이트의 정보를 알 수 있게 해주는 것을 말합니다.
그리고 오픈 그래프는 링크 프리뷰 화면을 구성할 수 있도록 해주는 메타 태그 규약으로, 오픈 그래프 프로토콜 기능을 지원하는 경우엔 링크 프리뷰에 노출할 메타데이터를 정리하여 입력하면 원하는 정보를 프리뷰에 노출시킬 수 있는 것이죠.
여기서 저희가 링크 프리뷰가 제대로 되는지를 체크해봐야 하는 이유는 바로 링크 프리뷰가 뜨지 않거나 잘 정리되어 있지 않을 때 링크를 공유받은 대상이 해당 링크에 접근하기 꺼려할 수도 있다는 것입니다.
그래서 서비스가 사용자들 사이에서 공유되기 전에 미리 자체적으로 링크 공유를 통해 제대로 정보가 노출되는지 등을 체크해야 합니다.
체크 후 기대와 다르게 노출이 된다면 html에서 오픈 그래프 수정을 해야 하며, 수정한 후에 캐시 삭제 디버거를 이용해여 업데이트된 내용을 확인해보시면 됩니다.
아래의 각 링크를 통해 채널별로 오픈 그래프를 체크해볼 수 있으며, 캐시 삭제 디버거도 함께 이용할 수 있습니다.
오픈 그래프 체크 & 캐시 삭제 디버거
카카오 - https://developers.kakao.com/tool
페이스북 - https://developers.facebook.com/tools/debug/
트위터 - https://cards-dev.twitter.com/validator
네이버 밴드 - https://developers.band.us/developers/ko/docs/share/debugger
라인 - 별도로 지원하지 않으며, 캐시 수집 주기는 아래와 같습니다.
URL Content : 1일 / URL Thumbnail : 10일 (2019년 7월 기준)
오늘은 지금까지 QA를 진행하며 느낀 아쉬웠던 점과 늘 비슷한 이유로 발생했던 이슈들에 대응하는 팁을 가볍게 적어보았습니다.
제 디자이너 생활이 끝날 때까지 QA는 계속될 것이고, 그때마다 QA 방법을 개선할 것들이 생겨날 것입니다.
그때마다 개선 사항과 대응법들을 기록하고 정리하여 틈틈이 공유해 드리겠습니다.
감사합니다.
도움을 주신 분들
도움 주셔서 다시 한번 감사드립니다.
