사이트를 이 잡듯이 뒤지는 단계,
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 경험 기준으로 요소들을 정리해보았습니다.
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. 중요도
중요도는 최상, 상, 중, 하, 최하 중에 선택합니다. 버튼에 링크 값이 없다던가, 콘텐츠/이미지가 노출되지 않는다던가, 인터렉션 시에 팅기는 현상이 있는 등 사이트가 정상적으로 구동되는 것에 있어서 문제가 되는 것들일수록 상위 중요도이며, 사소한 맞춤법이나 띄어쓰기와 같은 요소들 일수록 하위 중요도로 분리합니다. 중요도를 표기해두면 이슈 처리 담당자가 작업 시에 우선순위에 따라 작업을 처리해나갈 수 있습니다.
구글 시트를 활용하여 중요도를 적을 때 적은 단어에 따라 해당하는 셀의 색을 바뀌게 설정해놓으면 처리 담당자가 중요도를 한눈에 파악하기에 더 용이해집니다.
2-2-5. 페이지(또는 발생 위치), URL
문제가 발생한 페이지명과 발생 위치를 표기하고 해당 페이지의 URL을 표기하여 어디서 문제가 발생했는지를 구체적으로 표기합니다.
2-2-6. 테스트 브라우저
앞서 합의한 테스트 브라우저 중에서 어떤 브라우저에서 이슈가 발생했는지를 표기합니다. 이 부분은 구글 시트 내 드롭다운 목록 만들기로 미리 항목들을 목록화해놓으면 시트를 더 편리하게 작성할 수 있고, 합의되지 않은 브라우저에서 테스트를 하는 것을 방지할 수 있습니다.
2-2-7. 발생상황(AS-IS), 기대효과(TO-BE)
구체적으로 어떤 이슈가 발생했고 어떻게 표기되고 있는지를 AS-IS에 적고, 이것이 어떻게 개선되어야 하는지를 TO-BE에 적습니다.
2-2-8. 참고 이미지/영상
텍스트로만 AS-IS 상황, TO-BE 상황을 텍스트로만 전달하기 어려운 경우, 참고 이미지나 영상을 첨부합니다. 이미지는 셀 내에 삽입해야 행이 더 추가되는 경우 밀림 현상을 방지할 수 있습니다. 이미지가 이슈사항과 바로 보이는 것이 이슈를 확인하기에 더 용이하지만, 한 시트에 많은 이미지가 첨부되는 경우 로딩 시간이 길어질 수 있으니 이미지를 확인할 수 있는 링크를 표기하는 것이 좋습니다. 이미지 링크는 주로ImgBB를 이용하거나 구글 드라이브에 업로드 후 링크를 공유하는 방식을 사용합니다.(구글 드라이브에 업로드 후 링크를 공유하는 방식을 사용할 땐, '링크가 있는 인터넷상의 모든 사용자가 볼 수 있음' 상태로 설정한 후 공유하는 것을 잊지 말아야 합니다!)
2-2-9. 코멘트
이슈사항을 기재하는 것 이외에 따로 추가하고 싶은 코멘트를 적기도 하고, 처리 진행 상황과 같은 현황을 코멘트하기도 합니다. 코멘트를 남길 때는 작성자, 작성일을 명확하게 표기하여 히스토리를 남기는 것이 좋습니다.
2-2-10. 마크업/개발 코멘트
마크업/개발팀에서 코멘트를 남기는 영역입니다. 주로 수정 완료 또는 반영하였습니다 등의 코멘트가 달립니다. 이슈 작성자는 이 코멘트를 확인하고 테스트 URL에 적용된 것을 다시 한번 확인해서 이슈가 해결됐는지를 확인해야 합니다.
2-2-11. 처리 현황
작성자가 테스트 URL에 이슈사항이 처리된 것을 확인하면 처리 현황에 '완료'라고 표기해줘야 합니다. 처리 현황 예시는 다음과 같습니다.
처리 현황 예시
- 완료(회색) : 처리했으며, 작성자가 반영/완료를 확인한 이슈
- 재발생(빨간색) : 처리/완료했으나, 작성자가 재발생을 확인한 이슈
- 보류(노란색) : 담당자가 판단했을 때 처리 단계가 아닌 이슈
구글 시트에서 처리현황 입력 시 행 전체의 색을 바뀌도록 수식을 설정하여 이슈 처리 상황을 명확하게 표기해놓는 것이 좋습니다. 행 전체 색을 바꾸는 방식은 아래의 블로그에 잘 정리되어 있으니 참고하면 좋을 것 같습니다. 완료 처리되어 회색으로 바뀐 행은 맨 아래로 이동시켜 진행 중인 이슈사항만 상단에 노출되도록 정렬합니다.
참고 : 구글 스프레드시트 팁(Tip) 조건부서식으로 행 전체 색깔 변경하기
+
다른 회사에서는 QA시트를 어떻게 만들었을까?
앞서 언급했듯이 회사마다 진행하고 있는 프로젝트의 성격에 따라 QA 시트를 다르게 운영하고 있습니다. 하단의 사례로 가져온 회사들에서 운영하고 있는 서비스가 보다 더 복잡한 구조에 사용자에게 발생할 수 있는 케이스도 많기 때문에 테스트 시나리오, 재현 경로, 체크리스트 등 더 상세하게 체크할 수 있는 요소들로 구성이 되어있는 것을 확인해볼 수 있었습니다.
- 스타일쉐어
- 브랜디
최선을 다했다, 이제 릴리즈!
QA 기간이 다 끝나면 이제 릴리즈를 하게 됩니다. 실제로 라이브 되는 사이트를 한 번씩 더 보면서 큰 이슈가 없는지를 확인합니다. 이미 릴리즈가 된 상황이기 때문에 제발 이슈가 발견되지 말아라!라는 마음으로 사이트를 살펴보지만 아주 딱 1번! 큰 이슈가 발견적도 있었습니다. 이러한 경우에는 바로 이슈 처리 담당자를 찾아가서 구두로 설명하고 빠르게 반영할 수 있도록 해야 합니다. 하지만 이런 일은 모두에게 번거로운 일이 되기 때문에 이런 불상사를 방지하기 위해서라도 QA 기간에 더 예민하게 이슈를 탐지해야 합니다.
가끔 QA 기간이 끝났어도 시트에 이슈사항이 업로드되는 경우도 있습니다. 이를 방지하기 위해 시트 내에 이후 시간부터는 반영되지 않는다는 사실을 표기해놓거나 메일로 QA 종료 공지를 하는 것이 좋습니다.
팀원들과 함께 QA시트를 제작하고 사용하고 업데이트하면서 어떤 요소들이 왜 포함되면 좋을지, 시트를 어떻게 효율적으로 운영할 수 있을지에 대한 경험을 공유해보았습니다. 많은 회사들이 이미 사용해오고 있는 시트가 있을 것으로 예상되기 때문에, 이렇게 해볼 수도 있구나 정도로 생각하실 수 있는 계기가 되었으면 좋겠습니다. 읽어주셔서 감사합니다!:^)
