by
Oct 28. 2020
웹사이트 구축의 마지막 단계, QA를 진행해보자.
QA (Quality Assurance) 시트에는 무엇이 들어가야 할까?
사이트를 이 잡듯이 뒤지는 단계,
QA를 진행해보자.
웹사이트 구축 프로젝트에서 기획/설계 > 디자인 > 퍼블리싱 > 개발까지 완료가 되면 서비스 구축의 마지막 단계, QA를 시작하게 됩니다. QA는 Quality Assurance의 약자로 위키 백과에 따르면 '일정한 효율과 품질이 보장되어야 하는 활동 또는 제품에 대하여 보증을 부여하기 위하여 필요한 증거를 제공하는 것을 이른다.'라고 설명하고 있습니다. 웹사이트를 런칭하는 경우, 사이트를 릴리즈 하기 전 안정적으로 구동되고 있는지 문제 될 만한 사항이 없는지 모든 브라우저에서 잘 구동되고 있는지 등 꼼꼼하게 살펴보는 단계입니다.
웹사이트가 잘 작동되지 않거나, 이미지 미노출, 맞춤법 오류, 내용 오류 등의 문제가 발생하게 되면 사이트를 방문한 사용자들에게 부정적인 경험을 주게 되고 이는 서비스/제품의 인식에도 부정적인 영향을 줄 수 있기 때문에 QA는 오류를 찾아내기 위해 정말 이 잡듯이 사이트를 뒤져야 합니다. 그래서 QA 기간에는 여기저기서 '눈알이 빠질 것 같다'라는 이야기가 들려오기도 합니다.(사실 제가 제일 많이 하는 말입니다.)
QA 시트 만들기
첫 구축 프로젝트에 참여하여 책임님의 도움을 받아 첫 QA시트를 만들고, 이 시트로 4번의 QA를 진행하면서 과거의 저처럼 처음 QA 시트를 만드는 상황에 있는 분들에게 경험을 공유하면 어떨까라는 마음으로 글을 쓰게 되었습니다.
QA 시트를 만드는 것은 QA의 기본 틀을 잡는 것이기 때문에 중요합니다. QA 시트는 개발이 마무리되어갈 즈음에 UX팀이 세팅합니다. 저희 회사의 경우에는 프로젝트를 진행한 각 부서의 실무진들과 클라이언트 측의 담당자 모두가 참여하여 QA를 진행하고 있기 때문에 모두가 접근하기에 편리한 구글 스프레드 시트를 사용하여 QA를 진행하고 있습니다. 많은 이해관계자들이 참여하기 때문에 시트를 만들기 전에 미리 협의를 한 후에 시트를 만들어야 합니다. 이에 따라 우리가 고려해야 하는 사항은 다음과 같습니다.
0. 시트를 만들기 전, 협의해야 하는 사항
0-1. 담당자 배정
설계, 디자인, 퍼블리싱, 개발 각 부서별로 어떤 담당자가 맡아서 이슈를 해결할 것인지 정해야 합니다. 보통 모든 실무진의 이름이 리스트업 되지만, 프로젝트 진행 현황에 따라 QA에는 추가/제외되는 인원이 있을 수 있기 때문에 정리하고 넘어가는 것이 좋습니다.
0-2. 테스트 브라우저 협의
어떤 브라우저로 테스트할 것인지 각 부서 사이에 협의가 되어야 합니다. 보통 스탯카운터의 통계 자료를 참고하여 협의합니다. QA를 진행할 사이트가 외국을 타깃으로 하고 있다면, 해당 국가의 통계 자료를 참고하여 협의 후 포함시키기도 합니다. 보통 PC의 경우 윈도우 맥 각각 크롬, 사파리, 엣지, 익스플로어 11등을 (내년부터 IE는 서비스가 종료된다고 합니다 오예! 참고: 25살 익스플로러, 내년 굿바이) 위주로 테스트하고, 모바일의 경우 AOS, IOS 별로 크롬, 사파리, 삼성 인터넷, 네이버 인앱 브라우저 등을 테스트합니다.
- 웹 트래픽 분석 사이트, 스탯카운터
그래서 QA시에는 각 담당자들 앞에 맥북/아이맥, 윈도우 노트북, 아이폰, 갤럭시 등 각종 장비들이 펼쳐져 있는 광경을 목격할 수 있습니다.
재택근무 시에 진행했던 QA 때 모습_사진은 갤럭시로 찍었습니다 ㅎㅎ담당자들끼리 논의되는 사항을 다 협의했으면 이제 시트에 어떤 요건들을 넣어야 할지 정리해야 합니다. 시트에 포함되어야 하는 요소들은 각 회사별, 프로젝트 별로 다르지만 저희 회사에서 진행하는 기준, 제가 참여했던 브랜드 웹사이트 QA 경험 기준으로 요소들을 정리해보았습니다.
1. 시트 분리하기
보통 QA 시트는 PC QA, 모바일 QA 시트로 분리하여 사용합니다. QA를 진행하는 사이트의 범위가 크다면 이슈별로 시트를 분기하는 것이 이슈 처리 담당자가 작업을 하기에 편리합니다. 여러 이슈가 섞여있는 경우, 텍스트 이슈 수정하다 다시 이미지 수정하다 또다시 텍스트로 돌아가는 등 작업자가 정신이 없을 수 있기 때문입니다. (e.g. 텍스트 이슈 시트, 이미지 이슈 시트, 인터렉션 이슈 시트 등) 하지만 범위가 작다면 한 시트로 진행하는 것이 작업자가 확인하기에 더 편리합니다.
2. QA 시트의 구성 요소
2-1. 기본정보 기입 영역
2-1-1. 000 브랜드 웹사이트 QA (MM.DD.~MM.DD. N시)
타이틀과 함께 노출되어야 하는 가장 중요한 부분은 QA 진행 시간입니다. 릴리즈 예정 시간에 맞춰 QA 종료 시간을 명시해두어야 QA 진행에 혼선이 없습니다.
2-1-2. Test URL
QA 시작과 함께 공유된 Test URL을 시트에 표기해놓으면, QA 참여자들이 쉽게 테스트 사이트에 접근할 수 있습니다.
2-1-3. 이슈 등록 가이드라인
등록 가이드라인에는 시트를 어떻게 사용해야 하는지를 명시해놓습니다.
가이드라인 예시
- 최신 등록 이슈는 상단으로, 완료 처리된 이슈는 하단으로 옮겨놓을 것
- 이미지는 샐 내에 삽입하여 행이 추가로 생성될 시 밀림 현상을 방지할 것
- 이슈 할당 부서와 담당자를 명시할 것
- 본인 담당 이슈가 아닌 이슈가 배정될 시 작성자에게 문의 또는 재할당할 것 등
2-1-4. 이슈별 담당자
앞서 합의한 이슈별 담당자를 시트 상단에 표기해 놓으면 QA 추가 투입 인원이 있는 경우, 빠르게 담당자를 확인할 수 있습니다.
2-1-5. 이슈 업데이트 사항
QA를 진행하면서 발생한 업데이트 사항을 참여자들이 모두 파악할 수 있도록 표기해놓습니다.
이슈 업데이트 사항 예시
- 퍼블리싱 담당자와 개발 담당자의 할당 범위 이슈
- 클라이언트 측의 요청 사항
- 수정된 내부 협의 사항 등
2-2. QA 작업 진행 영역
2-2-1. 작성자, 등록일
이슈를 찾아낸 작업자와 등록 일시로 가장 중요한 부분이기 때문에 첫 번째 열에 입력합니다.
2-2-2. 1차 이슈 할당 및 담당자
이슈 작성자는 발생한 이슈를 해결할 수 있는 부서와 담당자를 지정합니다.
2-2-3. 2차 이슈 할당 및 담당자
퍼블리싱/개발 이슈인 경우 1차 이슈에서 해결될 수 있지만, 1차 이슈가 디자인인 경우 2차 이슈 할당을 퍼블리싱/개발 부서로 다시 배정해야 합니다.
2-2-4. 중요도
중요도는 최상, 상, 중, 하, 최하 중에 선택합니다. 버튼에 링크 값이 없다던가, 콘텐츠/이미지가 노출되지 않는다던가, 인터렉션 시에 팅기는 현상이 있는 등 사이트가 정상적으로 구동되는 것에 있어서 문제가 되는 것들일수록 상위 중요도이며, 사소한 맞춤법이나 띄어쓰기와 같은 요소들 일수록 하위 중요도로 분리합니다. 중요도를 표기해두면 이슈 처리 담당자가 작업 시에 우선순위에 따라 작업을 처리해나갈 수 있습니다.
구글 시트를 활용하여 중요도를 적을 때 적은 단어에 따라 해당하는 셀의 색을 바뀌게 설정해놓으면 처리 담당자가 중요도를 한눈에 파악하기에 더 용이해집니다.
출처: Google Support2-2-5. 페이지(또는 발생 위치), URL
문제가 발생한 페이지명과 발생 위치를 표기하고 해당 페이지의 URL을 표기하여 어디서 문제가 발생했는지를 구체적으로 표기합니다.
2-2-6. 테스트 브라우저
앞서 합의한 테스트 브라우저 중에서 어떤 브라우저에서 이슈가 발생했는지를 표기합니다. 이 부분은 구글 시트 내 드롭다운 목록 만들기로 미리 항목들을 목록화해놓으면 시트를 더 편리하게 작성할 수 있고, 합의되지 않은 브라우저에서 테스트를 하는 것을 방지할 수 있습니다.
출처: Google Support